Docker 2. What is Kubernetes?

서문

이번에 기업협업을 하게 된 회사가 도커 컨테이너를 관리하는 kubernetes를 모니터링하는 프로메테우스와 관련된 솔루션(??????) 회사라 도커에 대해 수박 겉핥기 식이나마 공부를 하게 되었다. 도커가 세상에 배포된지는 7년 정도밖에 안됐지만, 요즘 기업들 중 도커 안쓰는 곳을 찾기가 힘들 정도로 개발자들 사이에서는 대중화가 되었다.

이렇듯 너도나도 쓰는 기술이지만 필자와 같이 초보 단계인 사람들에게는 사전에 알아야 할 개념도 많고, 들어도 이해가 안되는 부분이 많을 것이다. 이 글을 쓰면서도 틀리는 부분이 분명 나올 것이라는 확신이 있지만 최대한 이해하기 쉽게 정리해보고자 한다.

이번 글은 도커와 컨테이너에 대한 기본적인 지식이 있어야 이해가 가능하므로 아직 도커와 컨테이너가 뭔지 모른다면 이 글을 확인하거나 검색을 통해 학습한 후 읽는 것을 추천한다.

1. Kubernetes?

보통 기업의 채용공고에 필수/우대사항에 도커가 있다면 십중팔구 쿠버네티스도 함께 있다. 쿠버네티스가 뭐길래 도커와 세트로 다니는 것일까?

도커의 컨테이너 가상화 기술을 통한 배포는 하나의 컨테이너를 각각 배포해야 하고, 배포한 후의 관리와는 거리가 멀었다. 그런데 구글과 같은 세계적인 기업은 하루에도 수 억개의 컨테이너를 생성/관리해야 하고, 작은 기업이라도 하나의 컨테이너로 끝나지는 않는다.

컨테이너 가상화를 통한 배포가 일상화되고 다수의 컨테이너를 활용해야 함에 따라 컨테이너를 관리(Container Orchestration)해 줄 도구의 필요성도 생겨났다. 물론 컨테이너 가상화가 예전부터 있던 기술인 만큼 관리 도구도 있었고, 도커가 유행하면서 도커를 위한 컨테이너 관리 도구(Docker Swarm등)도 존재했다.

그런데 여기서 구글이 내부 컨테이너 서비스인 borg를 오픈소스화 해서 배포했는데, 이것이 쿠버네티스이다. 앞에서 컨테이너 관리 도구는 이미 존재하고 있었다고 했지만, 갓구글 + 글로벌 it 기업들이 참여한 쿠버네티스가 등장하면서 춘추전국시대는 끝나고 거의 쿠버네티스로 일원화 되고 있다.

쿠버네티스가 컨테이너를 관리한다고 했는데 그것만으로는 정확히 무슨 일을 하는지 알기 어렵다. 쿠버네티스가 하는 일 중 굵직한 몇 가지만 열거해보자면,

1. Load Balancing: 컨테이너의 트래픽이 늘어나면 그에 맞추어 컨테이너 숫자를 늘리고, 트래픽이 줄어들면 컨테이너 숫자도 알아서 줄여 준다.
2. 자동화된 bin packing: 쿠버네티스에서는 컨테이너를 실행시키기 위해 노드에 컨테이너를 넣는데, 사용자가 각 컨테이너가 CPU, RAM을 얼마나 필요로 하는지 알려주면 쿠버네티스가 컨테이너를 노드에 맞추어 가장 효율적으로 사용할 수 있게 해준다.
3. self-healing: 컨테이너가 실패하면 다시 시작하고 응답하지 않는 컨테이너는 죽인 후 새 컨테이너를 생성해준다.

2. 기본 구조

2-1. 클러스터와 노드

쿠버네티스에서 관리하는 가장 큰 단위를 클러스타고 하며 그 안에는 노드가 존재한다. 노드가 실질적으로 컨테이너를 돌리는 기본적인 단위이며, 노드의 개수에는 제한이 없다. 또한 이 노드들을 관리하는 마스터가 존재한다.

2-2. 파드(Pod)

쿠버네티스가 관리하는 컨테이너는 바로 노드 안에 들어가는 것이 아니라 파드 안에서 여러 개의 컨테이너를 묶어서 관리한다. 여러 컨테이너를 관리하기 위해 파드는 컨테이너 간의 데이터 공유와 통신을 지원한다.

2-3. 서비스

파드 집합에서 실행되고 있는 애플리케이션을 네트워크 서비스로 추상화하는 것을 서비스라고 한다. 그런데 쿠버네티스에서 파드는 일회성으로, 생성/추가될 때마다 IP주소가 바뀐다. 그렇기 때문에 파드가 생성될 때 고유한 IP주소를 가짐에도 이 IP주소를 사용해 위치를 파악하는 것은 불가능하다.

그렇다면 서비스는 어떻게 파드를 관리할까?
정답은 파드의 레이블을 사용해 관리한다. 사실 파드를 처음 생성할 때 메타데이터 부분에 파드의 레이블을 설정할 수 있다. 그리고 서비스에서는 아래와 같이 레이블 셀렉터를 통해 관리할 파드를 규정할 수 있다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

2-4. Deployment

디플로이먼트는 '배포'라고 정의할 수 있는데, 여기서는 이미 배포된 디플로이먼트의 새로운 버전을 배포하는 것도 포함된다. 새로운 ReplicaSet을 생성하는 디플로이먼트를 정의하거나, 기존 디플로이먼트를 제거하고 모든 리소스를 새 디플로이먼트에 적용할 수 있다.

우선은 디플로이먼트 없이 Replication Controller(RC)를 사용해서 업데이트를 하는 방법을 소개하면,

1. 블루/그린 배포
   기존버전(블루)과 새 버전(그린)이 있을 때, RC에 새 템플릿으로 그린 버전의 파드를 생성한 후 문제가 없다면 서비스를 블루에서 그린으로 옮기는 방법이다.
2. 롤링 업그레이드
   새로운 RC를 생성한 다음 기존 RC에서 replica를 하나 줄이고 새 RC에서 replica를 하나 늘린다. 이 과정을 반복해 기존 RC에서 파드가 사라지고 그만큼 새 RC에서 파드가 늘어나게 한다.

위와 같은 과정은 결국 RC를 항상 하나 더 만들어야 하고 파드의 수도 수동으로 조정해야 하기 때문에 불편하다. 그래서 나온 것이 디플로이먼트이고, 배포를 추상화 & 자동화할 수 있으므로 공식문서에서도 ReplicaSet를 단독으로 사용하지 말고 디플로이먼트를 사용하는 것을 권장하고 있다.

참조한 글
https://subicura.com/2019/05/19/kubernetes-basic-1.html
https://kubernetes.io/ko/docs/concepts/overview/components/
https://bcho.tistory.com/1256?category=731548
https://deveric.tistory.com/103
https://baek.dev/post/5/