1. 도커와 쿠버네티스티스의 개요

'15단계로 배우는 도커와 쿠버네티스' 기반으로 내용 정리하였습니다.

1. 쿠버네티스란?

• 컨테이너화의 의의와 쿠버네티스의 개요

1.1 쿠버네티스의 개요

쿠버네티스(Kubernetes) : 컨테이너화된 애플리케이션을 효율적로 배포하고 운영하기 위해 설계된 오픈 소스 플랫폼

구글의 사내 운영 시스템인 Borg를 오픈 소스로 만든 것이며, 크게 다음과 같은 기능을 제공한다.

[ 쿠버네티스 기능 ]

배포 계획에 맞춰 애플리케이션을 신속하게 배포할 수 있다.

• 컨테이너 개수, CPU 사용률, 메모리 사용량을 설정 가능

• 저장 공간, 네트워크 접근 제어, 로드밸런싱 기능 설정 가능

가동 중인 애플리케이션을 스케일 업/다운할 수 있다.

• 요청이 많을 때는 컨테이너 수를 늘려서 처리 능력을 높임

• 요청이 적을 때는 컨테이너 수를 줄여서 자원 점유율이나 요금을 줄임

새로운 버전의 애플리이션을 무정지로 업그레이드할 수 있다.

하드웨어 가동률을 높여 자원 낭비를 줄인다.

쿠버네티스는 서비스 운영에서 발생하는 다양한 부담을 줄이는 것을 목표로 하여 다음과 같은 특징을 가진다.

[ 쿠버네티스 특징 ]

다양한 환경에서 쿠버네티스 사용 가능

• 퍼블릭 클라우드(Public Cloud)

  • 고객들 간에 공유하는 대신 저렴하고 신속한 운영이 가능한 인프라 환경
  • 자체 인프라가 없거나 빈약한 스타트업, 중견기업이 주로 사용

• 프라이빗 클라우드(Private Cloud)

  • 독점적으로 사용하여 보안을 높일 수 있는 인프라 환경(기업이 직접 클라우드를 구축하고 내부 활용)

• 멀티 클라우드 (Multi Cloud)

  • 여러 퍼블릭 클라우드를 함께 사용하는 경우

• 하이브리드 클라우드(Hybrid Cloud)

  • 온프레미스/퍼블릭 클라우드와 퍼블릭 클라우드를 함께 사용하는 경우

• 온프레미스(On-premise)

  • 자사 설비를 이용해 애플리케이션에 특화된 운영을 하는 경우

[ On-premise와 Private Cloud 차이 ]

• 온프레미스(On-premise) : 물리적인 서버 위에서 직접 어플리케이션이 실행된다.
• 프라이빗 클라우드(Private Cloud) : 물리적인 서버+기업 내에서 직접 클라우드를 구축(IaaS)을 해서 어플리케이션이 실행된다.

계속되는 변화를 전제로 설계된 높은 유연성과 확장성

• 마이크로 서비스화된 애플리케이션에 최적화된 실행 환경
• 느슨한 결합에 의한 유연성, 교체 용이성
• 다양한 스펙의 서버가 혼재하는 클러스터 구성에 사용 가능
• 서버(노드)의 정지, 추가, 제거가 용이
• 저장소나 로드밸런서의 동작 프로비저닝
• 퍼블릭 클라우드 API와 연동한 쿠버네티스 조작

고가용성과 성능 관리

• 서버 정지 시 애플리케이션 재배포 자동화
• 애플리케이션의 이상 종료 시 자동 재기동
• 필요한 인스턴스의 개수를 유지
• 높은 부하에서 자동 스케일

1.4 쿠버네티스가 해결하는 과제

• 과제 1 : 애플리케이션의 빈번한 출시

쿠버네티스의 롤아웃과 롤백 기능은 새로운 기능을 빈번하게 출시하고 버그 수정을 긴급 투입하는 것과 같은 민감한 작업을 안전하게 자동화 해준다. 이를 사용하면 정식 운영 중인 서비스의 애플리케이션 컨테이너를 무정지로 교체할 수 있다. 또한, 교체 중에 발생하는 성능 저하와 프로그램 충돌로 인한 서비스 정지를 막기 위해 컨테이너 교체 정책을 설정할 수 있다. 그리고 롤아웃을 취소하고 롤백하는 것도 가능하다.

• 과제 2 : 무정지 서비스

쿠버네티스의 자기 회복 기능은 무정지 서비스 운영을 도와준다. 응답이 없어진 컨테이너를 재기동하며, 쿠버네티스 클러스터 내에 지정한 수 만큼 컨테이너가 돌도록 관리한다.

• 과제 3 : 초기 비용을 낮추고 비지니스 상황에 맞게 규모를 조정

K8s 클러스터의 각 노드들이 똑같은 스펙일 필요는 없다. 따라서 비즈니스의 초기 단계에서는 스펙이 낮고 저렴한 가상 서버를 사용하다가, 비즈니스가 확대되면 고성능의 가상 서버나 물리 서버를 투입시키는 전략을 취하여 초기 비용을 낮출 수 있다.

• 과제 4 : 쿠버네티스와 외부 서비스 연동

쿠버네티스는 외부 서비스를 내부 DNS에 등록하는 기능을 제공한다.

• 과제 5 : 개발 환경과 운영 환경의 분리

쿠버네티스에서 클러스터를 여러 개의 가상 환경으로 분리하는 것이 가능하다. 그리고 각각의 가상 환경에 설정 파일, 보안이 필요한 인증서나 비밀번호를 저장할 수 있다.

• 과제 6 : 온프레미스와 클라우드 위에 구축

대형 클라우드 업체들은 EKS, AWS, IKS와 같은 쿠버네티스 서비스를 제공한다. 쿠버네티스는 인프라의 복잡성을 감추며, 일관된 인터페이스로 다룰 수 있도록 설계되었다. 따라서 온프레미스와 클라우드 환경에서 동일한 인터페이스로 조작하며 운영할 수 있다.

• 과제 7 : 애플리케이션 중심의 오케스트레이션

쿠버네티스는 애플리케이션 중심의 운영이라는 흐름을 더욱 가속화하고 있다. 애플리케이션 개발자가 YAML 파일을 기술하여 쿠버네티스에 제출하면 로드밸런서, 저장소, 네트워크, 런타임 등의 환경이 구성된다.

• 과제 8 : 특정 기업에 종속되지 않는 표준 기술

170여 개의 회사가 참가하고 있기 때문에 특정 회사에 종속되지 않은 표준 기술로 자리잡았다고 볼 수 있다.

• 과제 9 : 서버들의 가동률 높이기

쿠버네티스에서 사용되는 컨테이너 기술은 애플리케이션이 정해진 서버에서 돌지 않아도 된다는 자유를 제공한다.
또한, CPU 사용 시간이나 메모리 요구량도 간단히 제어하여 서버 가동률을 높일 수 있다.

1.5 쿠버네티스의 아키텍처

1. 마스터(Kubernetes Master)

쿠버네티스 마스터(Kubernetes Master)는 쿠버네티스 클러스터 전체를 컨트롤 하는 시스템이다.
관리자만 접속할 수 있도록 보안 설정을 해야 하고 마스터 서버가 죽으면 클러스터를 관리할 수 없기 때문에 보통 3대를 구성하여 안전성을 높인다.

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

1-1. API서버(kube-apiserver)

쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데, 그 중심이 되는 서버가 API서버이다.
쿠버네티스의 모든 기능들을 REST API로 제공하고 그에 대한 명령을 처리한다.
kubectl의 요청 뿐 아니라 내부 모듈의 요청도 처리하며 권한을 체크하여 요청을 거부할 수 있다.
노드에서 실행중인 컨테이너의 로그를 보여주고 명령을 보내는 등 디버거 역할도 수행한다.

1-2. etcd
API서버가 명령을 주고 받는 서버라면, etcd는 쿠버네티스 클러스터의 데이터베이스 역할을 하는 서버로 RAFT 알고리즘을 이용한 key-value 저장소이다.
여러개로 분산하여 복제할 수 있기 때문에 안전성이 높고 속도가 빠르다.
단순히 값을 저장하고 읽는 기능 뿐 아니라 watch 기능이 있어 어떤 상태가 변경되면 바로 체크하여 로직을 실행할 수 있다.

클러스터의 모든 설정, 상태 데이터는 여기 저장되고 나머지 모듈은 stateless하게 동작하기 때문에 etcd만 잘 백업해두면 언제든지 클러스터를 복구할 수 있다.
etcd는 오직 API서버와 통신하고 다른 모듈은 API서버를 거쳐 etcd데이터에 접근한다.

1-3. 스케쥴러(kube-scheduler)
스케쥴러는 Pod, 서비스 등 각 리소스들을 적절한 노드에 할당하는 역할을 한다.

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

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

2. 노드(Kubernetes Node)
쿠버네티스 노드(Kubernetes Node)는 마스터에 의해 명령을 받고 실제 워크로드를 생성하여 서비스 하는 컴포넌트이다.
실제 컨테이너들이 생성되는 곳으로 수백, 수천대로 확장할 수 있다.
각각의 서버에 라벨을 붙여 사용 목적(GPU 특화, SSD 서버)을 정의할 수 있다.
노드에는 Kubelet, Kube-proxy, cAdvisor 그리고 컨테이너 런타임이 배포된다.

2-1. Kubelet
노드에 배포되는 에이전트로, 마스터의 API서버와 통신을 하면서, 노드가 수행해야 할 명령을 받아서 수행하고, 반대로 노드의 상태 등을 마스터로 전달하는 역할을 한다.

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

2-3. Container runtime(컨테이너 런타임)
Pod를 통해서 배포된 컨테이너를 실행하는 컨테이너 런타임이다.
컨테이너 런타임은 보통 도커 컨테이너를 생각하기 쉬운데, 도커 이외에도 rkt(보안이 강화된 컨테이너), Hyper container 등 다양한 런타임이 존재한다.

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

3. 애드온(Addons)
애드온은 클러스터 내부에서 필요한 기능들을 위해 실행되는 포드(Pod)들이다.
애드온에 사용되는 포드들은 디플로이먼트, 리플리케이션컨트롤러등에 의해 관리된다.
애드온에 사용되는 네임스페이스는 kube-system이다.

애드온에는 몇가지 종류가 있다.

3-1. 네트워킹 에드온
쿠버네티스는 클러스터 내부에서 가상 네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 애드온을 사용한다.
AWS, Azure, GCP 같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않더라도 각 클라우드 벤더에서 구현하고 있으니 신경쓰지 않아도 된다.
하지만 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려면 네트워킹 관련 애드온을 설치해서 사용해야한다.
네트워킹 애드온의 종류는 ACI, Calico, Cilium, CNI-Genie, Contiv, Flannel, Weave Net 등이 있고, OCI의 CNI(Container Network Interface)를 구현하고 있다면 다른 애드온들도 사용할 수 있다.

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

3-3. 대시보드 애드온
쿠버네티스를 사용할 때 대부분 kubectl이라는 CLI(command Line Interface)를 많이 사용한다.
하지만 웹 UI가 필요한 경우 사용할 수 있는 대시보드가 있다.

3-4. 컨테이너 자원 모니터링
클러스터 내부에서 실행중인 컨테이너의 상태를 모니터링 하기 위해서는 cpu, 메모리 같은 필요한 메트릭 데이터를 시계열 형식으로 저장하고 볼수 있는 방법을 제공하는데 필요한 애드온이다.
kubelet안에 cAdvisor라는 컨테이너 모니터링 도구가 포함되어 있으며, 이 데이터들을 수집해서 사용할 수 있는 힙스터(heapster)를 이용하면 손쉽게 필요한 데이터들을 수집해서 모니터링에 이용할 수 있다.

3-5. 클러스터 로깅
클러스터 내의 각 개별 컨테이너에서 나오는 로그와 쿠버네티스 구성요소들에서 나오는 로그들을 중앙화된 로그 수집 시스템에서 모아서 볼 수 있다.
이것 역시 클라우드 서비스를 이용중이라면 각 클라우드 벤더에서 제공해주는 로깅 서비스들과 잘 연동이 되어 있겠지만, 직접 쿠버네티스를 설치해서 사용할 때는 고려해야 할 요소다.
클러스터 내 각 노드에 로그를 수집하는 포드를 실행해서 한곳으로 로그를 수집해야 하며, 로그를 수집해서 제공해주는 역할로는 ELK(ElasticSearch, Logstash, Kibana)를 많이 사용한다.