[0] 쿠버네티스: 역할 및 생겨난 이유, 사용 목적

https://www.youtube.com/watch?v=Ia8IfowgU7s

서버를 관리하다보니 도구의 필요성이 대두되었어

-> 이걸 써보니까 서로 다른 애플리케이션 버전이 충돌이 나고 그러는거야

아 이거 좀 불편한데...

 

그래서 나온게 가상 머신이야 (VM)

좀 느리고 관리도 불편하지만, 좋아!

 

근데 특정 벤더에 종속되고 현재 클라우드 환경에 좀 맞지 않다.

 

그래서 나온게 Docker야

 

컨테이너의 특징

* VM과 비교해서 컨테이너 생성이 쉽고 효율적

* 배포와 롤백이 간단

* 언어나 프레임워크와 상관없이 애플리케이션을 동일한 방식으로 관리

* 개발, 테스팅, 운영 환경은 물론 로컬 피시와 클라우드까지 동일한 환경을 구축

* 특정 클라우드 벤더에 종속적이지 않음. 오픈 소스거든.

 

모든 애플리케이션에 컨테이너화가 돼.

 

점점 컨테이너의 숫자가 늘어나게 돼.

그래서 수십 수백 수천개의 컨테이너를 관리해야될 필요성이 생기게 된거야.

도커가 좋기는 한데, 여러 개를 관리하려다보니 또 손이 가게 된거야.

 

새로운 기술의 필요성이 대두되는거지.

 

이것봐. 엄청 번거롭지?

 

이때, 어느 서버의 컨테이너가 비어있는지 확인하려면 ssh로 서버 하나 하나씩 접속해서 확인해야 돼.

v1을 배포를 했어. 그리고 하나 하나 접속해서 v2로 업데이트 했어.

근데 배포한 소스에 문제가 생겼어.

그럼 롤백을 해야되잖아.

그럼 다시 모든 컨테이너에 접속해서 롤백을 하나씩 다 해줘야 하는거야.

 

2. 서비스 검색은 어떻게 할까?

 

서비스가 많아질수록, 프록시 - 웹 사이에 로드 밸런서를 둬야하고,

그럴 때마다 프록시 서버의 아이피와 로드 밸런서의 아이피도 바꿔줘야 하는거야.

손이 많이 가는거지.

 

 

3. 서비스 노출은 어떻게 할까? (Gateway)

퍼블릭 영역에 nginx같은 프록시 서버를 하나 두고, 거기에 들어오는 호스트가 뭐냐에 따라

Private에 있는 Container로 연결해줌

근데 애플리케이션이 하나씩 늘어날 때마다 nginx에 서버 관리자가 하나씩 추가해줘야 되는거야

이것도 상당히 번거로운거지

 

4. 서비스 이상, 부하 모니터링은 어떻게 할까?

갑자기 서비스에 이상이 생기면 어떡해?

App1의 경우 앱이 정상적으로 됐다 안됐다 할거고, App4의 경우 앱이 아예 작동 안하겠지.

그럼 부랴부랴 Container log를 보고 죽은 Container를 다시 살려야 할텐데,

그것도 손이 가는거야.

 

만약 App2에 부하가 많이 걸리면? Scale out을 해줘야 하는데, 그것도 자동화 해줄 필요가 있는거야.

 

그래서 나온게

 

Container Orchestration

많은 컨테이너, 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구

 

= 서버 관리자인 나 대신 일해줘!

 

기존 서버 관리자의 역할을 대신하는거지.

 

1. CLUSTER

 

기존에는 서버 관리자가 1번 서버는 CPU가 3GHz, 램은 8기가

2번 서버는 CPU가 듀얼코어 2.4GHz, 램은 16기가

각 서버에는 어떤 애플리케이션이 설치 되어있지.

 

라는걸 서버 관리자는 다 알고 관리 하는거야.

 

근데 노드가 많아지게 되면, 클러스터로 묶어서 (하나로 합쳐서) 관리해야 하는거지.

 

글구 묶은 클러스터의 각 노드들을 ssh로 접속해서 하나씩 관리할 수 없으니, 앞단에 master node를 두는거야

master node에 명령어를 던지면, master node가 각 node에 명령어를 보내는거야.

 

클러스터 내에 있는 node들끼리는 네트워크로 연결이 되어있어.

 

그리고 이 노드의 갯수가 수 천개, 수 만개가 되어도 잘 작동해야돼.

그래서 처음 설계가 잘 되어야해.

 

2. STATE

 

replicas 값을 바꾸면 서버의 갯수로 그대로 반영되는거야.

 

만약 저 3개의 컨테이너중 하나가 죽으면, 그 컨테이너를 죽이고 새로 띄우는 것까지 담당.

 

3. SCHEDULING

APP1을 추가로 띄우고 싶어. 그럼 서버 관리자는 실시간으로 각 서버의 유휴 자원이 얼마나 있는지

파악해야 되거든?

그것도 번거롭잖아.

그러니까 대신 해주는거야.

 

아 3서버가 좀 널널하구나. 거기서 띄우자! 하구.

 

만약 여기서 서버를 하나 더 띄우고 싶다면?

새로운 서버를 하나 만들고 거기서 띄우는 이런 기능도 지원해.

 

4. ROLLOUT & ROLLBACK

 

버전을 올리고 다시 내리는 이런걸 원래 직접 하나씩 해줘야 되는데

중앙에서 해주는 그런 기능도 지원해

 

5. SERVICE DISCOVERY

 

어떤 서비스를 등록했어. 그럼 걔네들을 조회하는 절차가 있었잖아.

웹이 100번으로 떴어. 그럼 중앙 서버에 "100번 떴어!" 라고 등록 하는거야.

101번이 뜨면, "101번 떴어!"라고 등록 하는거지.

 

이걸 사용하는 프록시 서버가 있을텐데, 얘는 이 저장소를 관찰해서 변경이 있을 때마다 설정 변경 & 프로세스 재시작을 해줘.

그럼 관리자가 하나 하나 아이피를 바꿔줄 필요가 없겠지?

 

6. VOLUME STORAGE

 

각 노드에 필요한 볼륨을 마운트해야될 필요가 있을 수 있어.

이때 손으로 하나씩 다 할 수 있지만, 그러면 번거롭잖아.

설정으로 관리하면 좋겠지?

그래서 그런 역할도 해줘.

 

 

컨테이너 오케스트레이션이라는건 개념이란말야.

이걸 구현하는 방법은 많겠지?

그래서 초반에 많은 오케스트레이션 도구가 생겨났어.

 

컨테이너 관리도구 춘추전국시대가 열리게 된거지.

그때 다행히 쿠버네티스가 표준처럼 등장하게 돼.