Kubernetes 기초 - 동작 원리

1. 쿠버네티스란
2. 동작원리

---

참고로 그림을 그릴 손재주가 없어서 글밖에 없다.

필요하면 '쿠버네티스 아키텍처'를 검색해보길 바란다.

 

 

1. 쿠버네티스(Kubernetes)란

쿠버네티스는 그리스어로 조타수라는 의미다.

마치 선박을 운행하는 조타수가 컨테이너들을 싣고 원하는 곳으로 항해를 하듯이 쿠버네티스는 컨테이너들을 배포 및 확장, 관리하는 오케스트레이션을 수행한다.

 

 

컨테이너란

 

요약 : 가볍다.

 

컨테이너는 어떠한 소프트웨어(애플리케이션)를 실행하기 위한 격리된 환경을 제공하는 운영체제 수준 경량 가상화 기술이다.

컨테이너는 가상 머신과 같이 동작을 하지만 가상 머신보다 더 가벼운 용량을 가진다.

일반적으로 가상 머신은 하드웨어 가상화 기술로 하이퍼바이저 위에서 운영체제가 개별 설치되어 그 운영체제 위에서 소프트웨어를 실행한다.

운영체제는 가볍지 않다.

아무리 가벼운 운영체제라고 해도 2GB는 넘어가기에 이 가상 머신을 실행시키고 그 안에서 소프트웨어를 실행시키기에는 상당한 시간이 소요된다.

예를 들어, 만약 어떤 회사의 웹 서버가 가상 머신에서 실행되고 있다고 가정해보면 다음과 같은 문제가 발생한다.
웹 서버를 운영하던 중 예기치 않은 장애로 인해 웹 서버가 불능이 되었을 경우 이를 빠르게 복구해야 사용자들에게 서비스를 원활하게 제공할 수 있다.
하지만 가상 머신 특성상 무게가 상당하여 빠르게 웹 서버를 올리는데 어느 정도의 시간이 소요가 된다.
만약 많은 사용자들이 이용하는 네이버, 구글과 같은 서버들이라면 소요되는 시간으로 인한 파급효과가 엄청날 것이다.
물론 대형 포털사이트의 경우 웹 서버가 하나만 존재하는 것은 아니지만 빠른 서비스 복구와 사용자가 급격하게 증가하여 추가적인 서버를 더 개설해야하는 경우 빠른 서버 배포는 필연적이다.

 

이를 보완하기 위해 생겨난 솔루션이 컨테이너다.

컨테이너는 소프트웨어를 실행시키는데 필요한 프로그램이나 라이브러리, 종속성만을 포함하는 경량 가상화 기술이다.

가상 머신과 달리 컨테이너는 운영체제가 없기에 호스트 운영체제의 커널을 공유하여 사용한다.

그래서 컨테이너를 경량화 기술이라 부르며 가볍기 때문에 추가적인 서버가 더 필요한 경우 빠른 배포가 가능한 것이다.

컨테이너는 위와 같은 경우를 포함하여 리소스 사용량, 이식성과 확장성 등 다양한 장점을 가지고 있다.

 

엄밀하게 말하면 컨테이너 이미지는 기본 런타임 즉, 컨테이너가 실행되기 위해서 최소한의 기능을 갖춘 경량화 된 운영체제(베이스 이미지 : Alpine Linux, BusyBox 등)가 들어가기 때문에 컨테이너에 운영체제가 완전히 없다고 말할 수는 없다.

하지만 최소한의 기능을 갖춘 운영체제라고해도 커널의 대부분 요소들은 존재하지 않기에 호스트 운영체제의 커널을 공유하여 사용한다.

 

쿠버네티스

 

쿠버네티스는 위와 같은 컨테이너를 활용하여 다양한 작업을 수행한다.

도커와 역할이 겹치는 것 아니냐는 생각을 할 수도 있겠지만 도커는 주로 컨테이너 이미지 생성, 단일 이미지 배포 등의 역할을 수행한다.

그러나 쿠버네티스는 컨테이너 운영, 배포, 관리 등의 역할을 수행하며 서비스들 간의 유기적인 연결을 통해 다수의 컨테이너 관리를 최적화하는 역할을 수행한다.

 

쿠버네티스는 아래와 같은 작업을 수행한다.

• 컨테이너 오케스트레이션(자동 배포/복구, 파드 스케줄링)
• 서비스 디스커버리 및 로드밸런싱
• 설정 관리 및 스토리지 관리
• 롤링 업데이트 및 롤백
• 모니터링 및 로깅
• 보안 및 인증
• 다중 클러스터 및 멀티 테넌시

위 기능들을 통해 컨테이너를 효율적으로 운영, 관리할 수 있다.

 

 

 

---

2. 동작 원리

쿠버네티스는 Control Plane과 Worker Node로 구성된다.

Control Plane는 Master Node에 위치하는데 Control Plane이 Worker Node에 파드를 배포한다.

Control Plane에는 크게 네가지 컴포넌트가 존재한다.

 

• Control Plane (Master) 
  • kube-apiserver : 클러스터의 API 서버로서, 쿠버네티스 API에 대한 모든 요청을 처리합니다.
  • etcd : 분산된 키-값 저장소로서, 클러스터 상태 및 구성 정보를 안전하게 저장합니다.
  • kube-scheduler : 새로운 Pod이 어느 노드에서 실행될지 결정하는 스케줄링을 관리합니다.
  • kube-controller-manager : 여러 컨트롤러를 실행하여 클러스터 상태를 제어하고 관리합니다.

• Node
  • kubelet : 마스터에서 할당된 Pod의 상태를 유지하고, 컨테이너 런타임에 컨테이너를 시작하거나 중지하는 역할을 합니다.
  • kube-proxy : 서비스의 네트워크 트래픽을 로드 밸런싱하고, Pod 간의 네트워크 통신을 관리합니다.
  • 컨테이너 런타임 : 실제 컨테이너를 실행하는 소프트웨어 (예: containerd, Docker, runc).

 

기본 동작 시나리오

 

아래의 동작 시나리오를 보자.

API 서버는 관리자 및 시스템이 요청하는 모든 내용에 대해 유효성을 체크하여 처리하는 역할을 한다.

1. kubectl run pod web --image=nginx 같은 명령을 입력하면 이 명령이 문법적으로 올바른지 권한이 존재하는지 검증 후 etcd 저장소에 있는 상태 정보를 확인한다.
2. web이라는 파드 이름이 중복이 있는지 검증 후 없는 것을 확인하면 API가 scheduler 요청을 보낸다.
3. scheduler는 etcd에 저장된 상태 정보를 기반으로 여러 node들 중에서 어디가 가장 좋은지 판단한다.
4. 만약 node2가 좋다고 판단되면 scheduler가 API에게 알려주고 API는 해당 노드로 접속하여 해당 노드의 kubelet에게 요청한다.
5. kubelet은 컨테이너를 실행하기 위해 런타임과 통신을 수행하며 런타임이 nginx 서비스에 대한 버전이 있는지 확인하고 있으면 컨테이너를 동작시킨다.

 

에러 발생 시나리오

 

위 시나리오를 통해 파드는 1개 배포되었으며 controller-manager는 이를 유지하기 위해 노력한다.

1. node2가 에러가 발생하여 실행되던 파드가 죽어버렸다.
2. controller는 실행 중인 파드의 수를 점검하다가 파드 개수가 맞지 않음을 발견하여 API에게 다시 요청을 보낸다.
3. API는 scheduler를 통해 다시 정보를 얻어 적합한 노드에 다시 접속하여 kubelet에게 요청을 보낸다.
4. 런타임과 통신을 하여 다시 새로운 nginx 컨테이너를 실행시켜 파드를 생성한다.

 

이런 시나리오로 동작한다.

 

 

---

 

 

 

API서버, etcd, controller 의 상호작용

 

controller는 어떻게 파드가 부족하다는 걸 인지할까?

그럼 노드들의 상태정보는 어떻게 저장될까?

 

잠깐 알아보자.

 

먼저 각 노드는 kubelet이라는 데몬을 하나씩 가지고 있다.

이 kubelet데몬에는 cAdvisor를 포함하고 있는데 쿠버네티스 클러스터에서 각 노드에 자동으로 배포되어 사용자가 추가적인 설정 없이도 컨테이너 및 시스템 성능을 모니터링할 수 있도록 도와준다.

이를 통해 사용자는 자원 사용량, 성능 이슈, 이벤트 및 로깅 등을 신속하게 파악할 수 있다.

 

1. 이 상태 정보들을 kubelet이 control plane의 API서버에게 전송한다.
2. API서버는 받은 정보를 etcd저장소에 키-값 형태로 저장한다.
3. controller는 API서버를 주기적으로 폴링하여 정보를 확인하는데 이 때 etcd에 저장된 정보를 기반으로 클러스터의 상태를 이해한다.
4. controller는 Desired State와 Current State를 비교하여 차이가 나면 API서버에게 이를 알린다.
5. API서버는 scheduler에게 파드를 어디에 배치할 것인지 물어본다.
6. scheduler는 etcd와 직접 통신하여 노드의 리소스 상태, 파드의 요구사항, 노드의 Healthy상태를 점검하여 API서버에게 적합한 노드를 알려준다.
7. API서버는 해당 노드에 접속하여 kubelet에 파드 생성을 요청한다.

중복이 있을 수도 있지만 기재하지 않은 부분은 위 메커니즘과 동일하다.

 

 

kubelet의 역할

• 컨테이너 리소스 사용량 모니터링 : cAdvisor는 호스트 시스템에서 실행 중인 컨테이너의 CPU, 메모리, 디스크, 네트워크 등의 리소스 사용량을 실시간으로 모니터링합니다.
• 퍼포먼스 지표 수집 : CPU 사용률, 메모리 사용량, 네트워크 입출력 등과 같은 퍼포먼스 지표를 수집하고 이를 시각적인 형태로 제공합니다.
• 컨테이너의 세부 정보 제공 : 각 컨테이너에 대한 세부 정보를 제공합니다. 이는 컨테이너의 실행 ID, 시작 시간, 라벨, 환경 변수 등과 같은 정보를 포함합니다.
• 이력 및 이벤트 기록 : 컨테이너의 이력과 이벤트에 대한 정보를 기록합니다. 이를 통해 컨테이너의 생명주기 동안 어떤 일이 발생했는지 추적할 수 있습니다.
• 웹 기반 UI 제공 : cAdvisor는 웹 기반 사용자 인터페이스를 제공하여 사용자가 컨테이너 및 시스템의 성능 데이터를 시각적으로 확인할 수 있게 합니다.
• 쿠버네티스 통합 : 쿠버네티스 클러스터에서는 cAdvisor가 모든 노드에서 실행되어 각 노드의 컨테이너 및 노드 수준의 성능 데이터를 수집합니다. 이 정보는 쿠버네티스 마스터 노드에서 활용되며, Kubernetes Dashboard 등에서도 확인할 수 있습니다.

 

기타 컴포넌트

 

쿠버네티스에는 여러 컴포넌트들이 있고 각각의 역할을 수행함으로 컨테이너 관리가 가능하게 된다.

이 외에도 CoreDNS와 같은 쿠버네티스 클러스터 내에서 동작하는 네임 서버도 있고 calico, flannel, weave와 같은 CNI 애드온 컴포넌트, kube-proxy같은 DNS이름 해석, 로드밸런싱, 네트워크 규칙 관리의 역할을 하는 컴포넌트도 있다.

 

이러한 컴포넌트들의 조합으로 현재의 쿠버네티스가 되었다.

 

지금부터 철저하게 공부한다.

 

 

---

 

 

추가 정보

 

우리가 쓰는 쿠버네티스는 CNCF(Cloud Native Computing Foundation) 프로젝트 중 하나다.

 

CNCF에서 CKA와 같은 쿠버네티스 공인 자격증도 취득할 수 있으니 알아보면 좋을 듯하다.

 

https://www.cncf.io/

Cloud Native Computing Foundation