해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

Docker와 컨테이너에 대한 개념이 없다면 이전 글을 참고하자.

---

1. 등장 배경

• 젠킨스를 통해 여러 컨테이너들을 다루는데 빌드, 배포에 필요한 모든 명령어를
  각 컨테이너마다 모두 작성해 주었다.

• 그런데 만약 배포될 서버가 추가된다면 해당 서버에 맞는 스크립트를 추가해줘야 한다.

• 게다가 배포 방식이 바뀐다면? 배포 스크립트를 일일이 찾아서 수정해줘야 한다.

• 인프라 관리의 편리함으로 도커를 도입했지만 컨테이너가 점점 많아지면 결국 다시 관리는 어려워진다. 이를 해결하려는 툴이 바로 오케스트레이션 툴이다.

1-1. 오케스트레이션 툴

• 가상머신을 생성하거나 제거하는 등의 관리를 수행하는데 흔히 GCP에서 인스턴스를 만들거나 삭제할 때 구글에선 해당 요청을 오케스트레이션 툴로 처리한다.

• 도커 같은 컨테이너들을 전문적으로 오케스트레이션 하는 툴이 있는데 이를 컨테이너 오케스트레이션 툴 이라고 한다. 이중 가장 대표적인게 쿠버네티스(Kubernetes) 이다.

---

2. 쿠버네티스(Kubernetes)

• 쿠버네티스(Kubernetes)란 배의 키를 잡는 사람인 조타수(항해사)의 그리스어 단어이다.

• 때문에 로고가 배의 키 모양이며, 주로 k8s라고 부르는데 그 이유는 k와 s사이에 있는 글자가 8개여서 k8s라고 부른다.

• 원래 구글 내부에서 컨테이너 오케스트레이션 툴로 사용하던 프로젝트였는데 오픈소스화 한 것이다.

---

3. 쿠버네티스(Kubernetes) 구성 요소

• 해당 내용은 공식 문서에도 잘 나와있다. Docker나 쿠버네티스(Kubernetes)나 공식문서가 정말 잘 되어있으니 학습할 때 참고하면 좋을 것 같다.

3-1. 클러스터

• 클러스터는 워커 노드와 마스터 노드로 이루어져 있다.

• 각 노드는 물리적인 서버일 수도 있고 가상의 서버일 수도 있다.
  어쨋든 네트워크로 구분되는 하나하나의 서버이다.

3-2. 노드

• 마스터 노드

  • 마스터 노드는 클러스터 전체를 관리한다.

  • 해당 그림에서 마스터 노드는 한 개로 나와 있지만 워커 노드의 수에 따라 3~7개 까지 정도로 달라지며 반드시 홀수여야 한다.

  • 이유는 클러스터를 관리할 때 상태값에 대한 합의를 진행하는데 짝수인경우 합의가 되지 않는 경우를 방지하기 위함이다.

  • 애플리케이션이 직접 실행되는 노드가 아니다. 각 워커노드에서 실행된다.

• 워커 노드

  • 마스터 노드의 관리를 받아 애플리케이션을 실행시키는 노드이다.

  • 개수의 제한은 없지만 쿠버네티스(Kubernetes)에서 제공하는 네트워크 플러그인에 따라 수백에서 수천개까지 워커노드의 수가 제한된다.

3-3. 디플로이먼트(Deployment)

• 마스터 노드에 생성이 되며 워커 노드에 컨테이너화된 애플리케이션이 떠있는지 모티너링 한다.

• 만약 노드가 다운되거나 삭제되어 애플리케이션이 동작하지 않는 경우 다른 노드에 애플리케이션을 생성한다.

• 위와 같이 yaml 파일로 간단하게 설정할 수 있다.

3-4. 파드(Pod)

• 그림에서 실제 애플리케이션 컨테이너는 containerized app이라고 되어있는 부분이다.

• 하나의 파드에는 여러개의 애플리케이션이 뜰 수 있다.

• 쿠버네티스(Kubernetes)에서 파드부터는 클러스터 내부 IP를 가지게 된다.

• 하지만 여기까지는 실행중인 애플리케이션을 클러스터 외부로 서비스 할 수 없다.
  외부에서 서비스 하기위해 서비스(Service)가 필요하다.

3-5. 서비스(Service)

• 서비스는 파드를 묶어 외부에 노출시킨다.

• 서비스 들에게 이름을 부여할 수 있다.

• 하지만 서비스만으로는 정말 간단한 라우팅만 지원한다.

• 쿠버네티스(Kubernetes)로 클러스터를 구성하다보면 정말 다양한 애플리케이션을 띄우게 되는데 이 때 로드밸런싱이나 https같은 처리가 필요한 경우에는 인그레스(ingress)를 사용한다.

3-6. 인그레스(ingress)

• 클러스터 외부에서 트래픽을 받아서 라우팅 룰에따라 서비스에 라우팅을 수행한다.

• 마치 이전에 Nginx로 로드밸런싱 환경을 구성했을 때와 비슷하다.

• 간단히 Nginx가 해주는 역할과 인그레스의 역할이 거의 비슷하다고 보면 된다.

3-7. 파드의 스케일링

• 쿠버네티스(Kubernetes)의 구성요소는 아니지만 파드의 기능 중 하나이다.

• 스케일링 되는 단위는 파드기준이며 오른쪽 그림처럼 파드는 서비스로 묶여있다.

• 왼쪽에서 오른쪽으로 스케일 아웃이 될 수도 있고 반대로 스케일을 줄일 수 도 있다.

• 쿠버네티스(Kubernetes)에서는 오토스케일링 기준을 정해 줄 수 있는데 이때 기본적으로
  CPU와 메모리 사용량으로 기준을 정해 줄 수 있다.

---

4. 이제 쿠버네티스에서 도커 못쓰지 않나요?

결론부터 말하면 아니요 라고 답할 수 있다. 블로그에서도 위와같은 코멘트를 볼 수 있다..ㅎㅎ

이전 글에서도 다뤘던 내용이지만 다시 한번 말하면 이 이야기가 나오게 된 배경이 2020년 12월 2일에 쿠버네티스 공식 블로그에 게시된 내용 때문이다.

쿠버네티스(Kubernetes)에서 돌아가는 도커 컨테이너를 실행시키기 위해서는 도커를 실행시킬 주체인 컨테이너 런타임(cri)이 존재해야 한다. 쿠버네티스(Kubernetes)에서 지원하던 컨테이너 런타임은 dockershim, containerd, CRI-O가 있었는데 이 중 표준으로 사용하는 것은 containerd이다.
이 때 docker가 더이상 업데이트를 하지 않으면서 더이상 컨테이너 런타임 인터페이스의 표준을 지키지 못하게 되었다. 그래서 쿠버네티스(Kubernetes)가 도커를 containerd와 같은 인터페이스로 맞춰주기 위해 dockershim이라는 추가적인 도구를 계속 유지보수해주고 있었다.
그런데 이제는 더 이상 표준을 지키지 않는 도커를 지원 안하겠다고 하면서 dockershim을 더 이상 쿠버네티스(Kubernetes)의 컨테이너 런타임으로 사용하지않겠다고 선언했다.

결론적으로 내가 쿠버네티스(Kubernetes) 클러스터를 관리하며 현재 dockershim을 사용하는 사람이 아니라 단순 Docker 컨테이너로 애플리케이션을 띄우고 사용하는 사람이라면 전혀 상관 없는 이야기이다.