[kubernetes] 쿠버네티스 아키텍처

쿠버네티스 클러스터의 전체 구조

쿠버네티스 클러스터는 크게 두 종류의 서버로 구성한다.

 

1. 클러스터를 관리하는 마스터

etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker 등의 컨테이너가 실행된다.

 

2. 실제 컨테이너를 실행시키는 노드

kubelet, kube-proxy, docker

 

마스터는 보통 고가용성을 만족하고자 서버 3대 정도 구성해서 운영한다.

평소 실제 클러스터를 관리하는 마스터는 1대고 나머지 2대는 대기한다.

리더 마스터에 장애가 발생하면 자연스럽게 나머지 2대 중 1대가 리더 역할을 맡는다.

 

실제 사용하는 컨테이너 대부분은 노드에서 실행된다.

 

각 컴포넌트의 중심에 kube-apiserver가 있다.

쿠버네티스의 모든 통신은 kube-apiserver가 중심이다.

kube-apiserver를 거쳐 다른 컴포넌트가 서로 필요한 정보를 주고 받는다.

특히 etcd에는 kube-apiserver만 접근할 수 있다.

 

etcd는 컨테이너가 아니라 별도의 프로세스로 설정되어 있다.

마스터와 노드 모두 kubelet으로 도커를 관리한다.

노드의 kubelet은 마스터의 kube-apiserver와 통신하면서 파드의 생성, 관리, 삭제를 담당한다.

 

쿠버네티스 주요  컴포넌트

쿠버네티스 컴포넌트는 세 가지로 구분한다.

마스터용 컴포넌트, 노드용 컴포넌트, 애드온용 컴포넌트

마스터용 컴포넌트

etcd

• 코어OS에서 개발한 고가용성을 제공하는 키-값 저장소이다.
• 분산 시스템에서 노드 사이의 상태를 공유하는 합의 알고리즘 중 하나인 raft 알고리즘을 구현한 것이다.
• 쿠버네티스에서는 필요한 모든 데이터를 저장하는 데이터베이스 역할을 한다.
• etcd는 서버 하나당 프로세스 1개만 사용할 수 있다.

kube-apiserver

• 쿠버네티스 클러스터의 API를 사용할 수 있도록 하는 컴포넌트
• 클러스터로 온 요청이 유효한지 검증한다.
• 예) 쿠버네티스 API 스펙에 맞춰 클러스터의 특정 네임스페이스와 자원을 대상으로 요청을 실행할 권한이 있는지 검사하고 권한이 있다면 디플로이먼트 목록을 조회하여 되돌려준다.
• 쿠버네티스는 마이크로 서비스 아키텍처이므로 서로 분산된 컴포넌트 여러 개로 구성되어 있다.
• 쿠버네티스에 보내는 모든 요청은 kube-apiserver를 이용해서 다른 컴포넌트로 전달한다.

kube-scheduler

• 현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새롭게 만든 파드를 실행한다.
• 파드는 처음 실행할 때 여러 가지 조건을 설정하며, kube-scheduler가 조건에 맞는 노드를 찾는다.
• 조건에는 하드웨어 요구사항, 함께 있어야 하는 파드들을 같은 노드에 실행하는 어피니티와 파드를 다양한 노드로 분석해서 실행하는 안티어피니티 만족 여부, 특정 데이터가 있는 노드에 할당 등이 있다.

kube-controller-manager

• 쿠버네티스는 파드들을 관리하는 컨트롤러
• 갯수를 보장해주는 역할
• 컨트롤러 각각은 논리적으로 개별 프로세스지만 복잡도를 줄이려고 모든 컨트롤러를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행된다.
• kube-controller-manager는 컨트롤러 각각을 실행하는 컴포넌트이다.
• 쿠버네티스는 Go 언어로 개발되었는데, 클러스터 안에서 새로운 컨트롤러를 사용할 때는 컨트롤러에 해당하는 구조체를 만든다.
• 이 구조체를 kube-controller-manager가 관리하는 큐에 넣어서 실행하는 방식으로 동작한다.

cloud-controller-manager

• 쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해 관리하는 컴포넌트이다.
• 관련 컴포넌트의 소스코드는 각 클라우드 서비스에서 직접 관리한다.
• 보통 네 가지 컨트롤러 컴포넌트를 관리한다.
  1. 노드 컨트롤러 : 클라우드 서비스 안에서 노드를 관리하는 데 사용
  2. 라우트 컨트롤러 : 클라우드 서비스 안의 네트워크 라우팅을 관리하는데 사 사용
  3. 서비스 컨트롤러 : 클라우드 서비스에서 제공하는 로드밸런서를 생성, 갱신, 삭제하는 데 사용
  4. 볼륨 컨트롤러 : 클라우드 서비스에서 생성한 볼륨을 노드에 연결하거나 마운트하는 등에 사용

노드용 컴포넌트

쿠버네티스 실행 환경을 관리한다.

대표적으로 각 노드의 파드 실행을 관리하는 것이 있다.

kubelet

• 클러스터 안 모든 노드에서 실행되는 에이전트이다.
• 파드 컨테이너의 실행을 직접 관리한다.
• kubelet은 파드스펙이라는 조건이 담긴 설정을 전달받아서 컨테이너를 실행하고 컨테이너가 정상적으로 실행되는지 헬스 체크를 진행한다.
• 단, 노드 안에 있는 컨테이너라도 쿠버네티스가 만들지 않은 컨테이너는 관리하지 않는다.

kube-proxy

• 쿠버네티스 클러스터 안에 별도의 가상 네트워크를 설정하고 관리한다.
• kube-proxy는 이런 가상 네트워크의 동작을 관리하는 컴포넌트이다.
• 호스트의 네트워크 규칙을 관리하거나 연결을 전달할 수도 있다.

컨테이너 런타임

• 컨테이너 런타임은 실제로 컨테이너를 실행시킨다.
• 가장 많이 알려진 런타임으로는 도커가 있고 containerd, runc 같은 런타임도 지원한다.
• 보통 컨테이너 표준을 정하는 OCI의 런타임 규격을 구현한 컨테이너 런타임이라면 쿠버네티스에서 사용할 수 있다.

애드온

애드온은 클러스터 안에서 필요한 기능을 실행하는 파드이다.

네임스페이스는 kube-system이며 애드온으로 사용하는 파드들은 디플로이먼트, 레플리케이션 컨트롤러 등으로 관리한다.

네트워킹 애드온

• 쿠버네티스는 클러스터 안에 가상 네트워크를 구성해 사용할 때 kube-proxy 이외에 네트워킹 에드온을 사용한다.
• 아마존 웹 서비스, 애저, 구글 클라우드 플랫폼 같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 제공하니 신경 쓰지 않아도 된다.
• 하지만 쿠버네티스를 직접 서버에 구성한다면 네트워킹 관련 애드온을 설치해서 사용해야 한다.
• 쿠버네티스를 직접 서버에 구성할 때 가장 까다로운 부분이기도 하다.

DNS 애드온

• DNS 애드온은 클러스터 안에서 동작하는 DNS 서버이다.
• 쿠버네티스 서비스에 DNS 레코드를 제공한다.
• 쿠버네티스 안에 실행된 컨테이너들은 자동으로 DNS 서버에 등록된다.
• 주로 사용하는 DNS 애드온에는 kube-dns와 CoreDNS가 있다.
• 쿠버네티스 초기에는 kube-dns를 기본 DNS 애드온으로 이용했는데 여러 가지 버그 등 문제가 많았다.
• 최근에는 CoreDNS를 기본 DNS 애드온으로 사용한다.

대시보드 애드온

• 쿠버네티스는 kubectl 이라는 CLI를 많이 사용한다.
• 하지만 웹 UI로 쿠버네티스를 사용할 필요도 있을 것이다.
• 이 때 쿠버네티스에서 제공하는 대시보드 애드온을 사용할 수 있다.

컨테이너 자원 모니터링

• 클러스터 안에서 실행 중인 컨테이너의 상태를 모니터링하는 애드온이다.
• CPU 및 메모리 사용량 같은 데이터들을 시계열 형식으로 저장해서 볼 수 있다.
• kubelet 안에 포함된 cAdvisor 라는 컨테이너 모니터링 도구를 사용한다.
• cAdvisor에서는 자원 사용량 데이터를 수집하는 메트릭 서버를 손쉽게 모니터링에 이용한다.

클러스터 로깅

• 클러스터 안 개별 컨테이너의 로그와 쿠버네티스 구성 요소의 로그들을 중앙화한 로그 수집 시스템에 모아서 보는 애드온이다.
• 클러스터 안 각 노드에 로그를 수집하는 파드를 실행해서 로그 중앙 저장 파드로 로그를 수집한다.
• 클라우드 서비스를 이용 중이라면 네트워킹 애드온처럼 클라우드 서비스에서 제공하는 로깅 서비스들과 잘 연동되겠지만 직접 쿠버네티스를 설치해서 사용할 때는 애드온 사용을 고려해야 한다.