쿠버네티스란

도커가 이미지를 컨테이너에 올려 돌아가게 만드는 가상화 플랫폼이라고 하면 쿠버네티스는 이 컨테이너들을 관리하는 플랫폼이라고 생각하면 된다.

컨테이너의 생태계를 관리한다고 나는 이해했다.

죽으면 살리고 배포할 때 어떻게 띄울 것이며 카나리 전략을 사용할 수 있게 해주는 일종의 분산 컨테이너를 관리하는 툴이라고 생각하면 편한 것 같다.
로깅과 모니터링도 가능하다고 한다.

마스터

마스터(Kubernetes Master)는 쿠버네티스 클러스터 전체를 컨트롤 하는 시스템이다.

AWS EKS같은 경우 마스터를 AWS 자체 관리하여 안정성을 높였고(마스터에 접속 불가), 개발 환경이나 소규모 환경에선 마스터와 노드를 분리하지 않고 같은 서버에 구성하기도 한다.

마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있으며, 크게 API서버, 스케쥴러, 컨트롤러 매니저, etcd로 구성되어 있다.

1. API 서버

쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데, 그 중심이 되는 서버가 API서버이다. 쿠버네티스의 모든 기능들을 REST API로 제공하고 그에 대한 명령을 처리한다.

노드에서 실행중인 컨테이너의 로그를 보여주고 명령을 보내는 등 디버거 역할도 수행한다.

2. etcd

API서버가 명령을 주고 받는 서버라면, etcd는 쿠버네티스 클러스터의 데이터베이스 역할을 하는 서버로 RAFT 알고리즘을 이용한 key-value 저장소이다.

3. 스케쥴러

스케쥴러는 Pod, 서비스 등 각 리소스들을 적절한 노드에 할당하는 역할을 한다.

4. 컨트롤러 매니저

컨트롤러 매니저는 컨트롤러(Replica Controller, Service Controller, Volume Controller, Node Controller 등)를 생성하고 이를 각 노드에 배포하며 이를 관리하는 역할을 한다.

5. DNS

쿠버네티스는 리소스의 엔드포인트(EndPoint)를 DNS로 맵핑하고 관리한다. Pod나 서비스 등은 IP를 배정받지만 동적으로 생성되는 리소스이므로 컨테이너 기동/삭제에 따라 IP주소가 변경되기 때문에, 그 리소스에 대한 위치정보가 필요하다. 내부 위치정보를 DNS 서버를 두고 관리한다. 새로운 리소스가 생기면 그 리소스에 대한 IP와 DNS 이름을 등록하여, DNS 이름 기반으로 리소스에 접근할 수 있도록 한다.

노드

노드는 컨테이너화 된 어플리케이션을 실행하는 단위 클러스터의 노드! 라고 생각하면 편하다 클러스터 내에서 분산되어서 일하는 단위 인거다.

1. 파드

파드는 애플리케이션이 실행중인 하나 이상의 컨테이너들을 관리하는 작은 단위이다. 노드내의 파드들은 격리가 적용되고 파드내의 컨테이너들도 각각 하위격리가 적용된다. 쿠버네티스의 특징중의 하나는 컨테이너를 개별적으로 하나씩 배포하는 것이 아니라 Pod 라는 단위로 배포하는데, Pod는 하나 이상의 컨테이너를 포함한다.

• apiVersion은 이 스크립트를 실행하기 위한 쿠버네티스 API 버전이다 보통 v1을 사용한다.

• kind 에는 리소스의 종류를 정의하는데, Pod를 정의하려고 하기 때문에, Pod라고 넣는다.

• metadata에는 이 리소스의 각종 메타 데이타를 넣는데, 라벨(뒤에서 설명할)이나 리소스의 이름등 각종 메타데이타를 넣는다

• spec 부분에 리소스에 대한 상세한 스펙을 정의한다.

  • Pod는 컨테이너를 가지고 있기 때문에, container 를 정의한다. 이름은 nginx로 하고 도커 이미지 nginx:1.7.9 를 사용하고, 컨테이너 포트 8090을 오픈한다.

2. Kube-proxy

노드로 들어오는 네트워크 트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱 등 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고, 노드와 마스터간의 네트워크 통신을 관리한다.

각 노드에서 실행중인 네트워크 프록시 바깥 네트워크 세상과 노드 내부를 연결해주고 파드랑도 연결해 준다.

3. Kubelet

노드에 배포되는 에이전트로, 마스터의 API서버와 통신을 하면서, 각 노드의 에이전트, 파드에서 컨테이너가 제대로 실행될 수 있도록 한다. 반대로 노드의 상태 등을 마스터로 전달하는 역할을 한다.

4. Container runtime

Pod를 통해서 배포된 컨테이너를 실행하는 컨테이너 런타임이다.

5. cAdvisor

cAdvisor는 각 노드에서 기동되는 모니터링 에이전트로, 노드에서 기동되는 컨테이너들의 상태와 성능 등의 정보를 수집하여, 마스터 서버의 API 서버로 전달한다. 주로 모니터링에 사용됨.

애드온

애드온은 클러스터 내부에서 필요한 기능들을 위해 실행되는 포드들이다.

1. 네트워킹 에드온

쿠버네티스는 클러스터 내부에서 가상 네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 애드온을 사용한다.
(AWS, Azure, GCP 같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않더라도 각 클라우드 벤더에서 구현하고 있으니 신경쓰지 않아도 된다.)

쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려면 네트워킹 관련 애드온을 설치해서 사용해야한다.

2. DNS 애드온

DNS 애드온의 경우 실제로 클러스터 내에서 작동하는 DNS서버이다. 쿠버네티스 서버들에 DNS 레코드를 제공하는 역할을 한다. 내부에서 실행된 컨테이너들은 자동으로 DNS서버에 등록된다. (kube-dns , core-dns)

3. 대시보드 애드온

kubectl이라는 CLI(command Line Interface)를 많이 사용한다. 하지만 웹 UI가 필요한 경우 사용할 수 있는 대시보드

4. 컨테이너 자원 모니터링

실행중인 컨테이너의 상태를 모니터링 하기 위해서는 cpu, 메모리 같은 필요한 메트릭 데이터를 시계열형식으로 저장하고 볼수 있는 방법을 제공하는데 필요한 애드온이다.

kubelet안에 cAdvisor라는 컨테이너 모니터링 도구가 포함되어 있으며, 이 데이터들을 수집해서 사용할 수 있는 힙스터(heapster)를 이용하면 손쉽게 필요한 데이터들을 수집해서 모니터링에 이용할 수 있다.

5. 클러스터 로깅

클러스터 내의 각 개별 컨테이너에서 나오는 로그와 쿠버네티스 구성요소들에서 나오는 로그들을 중앙화된 로그 수집 시스템에서 모아서 볼 수 있다. 로그를 수집해서 제공해주는 역할로는 ELK(ElasticSearch, Logstash, Kibana)를 많이 사용한다.

Helm Chart

업무상 많이 나오는 단어로 처음에 몰라서 행차트..? 라고 검색했던 기억이 난다...일반적으로 Kubernetes Manifest 파일은 정적인 형태이다. 따라서 데이터를 수정하기 위해선 파일 자체를 수정해야 한다. 잘 관리를 한다면야 큰 어려움은 없겠지만, 문제는 CI/CD 등 자동화된 파이프라인을 구축해서 애플리케이션 라이프사이클을 관리할 때 발생합니다.

보통 애플리케이션 이미지를 새로 빌드하게 되면, 빌드 넘버가 변경됩니다. 이렇게 되면 새로운 이미지를 사용하기 위해 Kubernetes Manifest의 Image도 변경되어야 합니다. 하지만 Kubernetes Manifest를 살펴보면, 이를 변경하기 쉽지 않다는 것을 깨닫게 됩니다. Image Tag가 별도로 존재하지 않고 Image 이름에 붙어있기 때문입니다. 이를 자동화 파이프라인에서 변경하려면, sed 명령어를 쓰는 등의 힘든 작업을 (눈물의 똥꼬쇼를)해야 합니다.

이 외에도 배포하는 이름에 따라 ConfigMap을 바꿔주고, 또 배포할 때마다 큰 틀은 같지만 조금씩 다른 형태로 데이터를 배포해야 할 때, 매번 Manifest를 수정하는 것은 너무나 비효율적입니다.

Helm Chart는 이런 어려움을 단번에 해결해줍니다. 물론 차트를 처음 만들 때는 번거롭긴 합니다. 필요로 하는 데이터를 template 형태로 작성해서 관리하고 있어야 하고, 단순히 배포만 하면 끝나던 것이 아니라, Helm 차트 자체를 관리해야 하는 노고도 추가됩니다. 그럼에도 불구하고 Helm Chart는 훌륭한 도구이며, 개인적인 의견으론 반드시 사용해야 하는(!) 도구라고 생각합니다.