쿠버네티스 시작하기 - 1 (최소한 알아야 할 것들)

쿠버네티스 시작 전 최소한 알아야 할 것들이 있다.
뭔가 명령어가 나와서 따라 치긴 하는데 도무지 뭘 하는건지 알 수 없는 상황이 반복되다보면 문제가 생겼을 때 해결이 어렵고, 마지막 희망 GPT 형님마저 헛소리를 해대면 도무지 방법이 없다.

결국 빠른 문제 해결을 위해선 어디서부터 접근해야하는지 알기 위해 동작 원리를 배워야한다. 말이 빠른 해결이지 자칫 나 혼자 공부, 포트폴리오 같은 것은 트러블 슈팅이 길어지면 포기하기 십상이다.

Contents hide

쿠버네티스 아키텍처

감격스럽다. 정말 간단 명료한 아키텍처 도식화라고 생각된다.
지난 포스팅에서 kubectl, kubeadm, kubelet 을 설치하고 클러스터를 만들었는데 아무런 설명을 하지 않았기 때문에 우선 위 도식을 기준으로 각 구성요소를 설명하려 한다.

쿠버네티스 클러스터를 관리하는 핵심 컴포넌트를 모아서 컨트롤 플레인이라고 부르며 Master Node(마스터 노드)에 설치된다.

API Server: 클러스터 내의 모든 명령을 관리한다. kubectl, kubeadm 클라이언트는 API 서버와 통신하여 클러스터를 제어한다.
Scheduler: 새로운 Pod를 생성할 때 적절한 워커 노드를 선택하는 역할을 수행한다.
Controller Manager: 클러스터의 상태를 지속적으로 모니터링하며 사용자가 정의한 설정을 유지하기 위한 동작을 한다.
etcd: 클러스터의 모든 현재 상태 정보를 Key-Value 형태로 저장, 보관한다.

그림의 worker1은 워커 노드에 해당한다. 실제로 컨테이너가 실행되는 곳이다.

kubelet: 각 노드에서 실행되며, API 서버와 통신하여 지정된 Pod가 제대로 실행되고 있는지 확인한다. Pod의 상태를 주기적으로 확인하고, 필요한 작업을 수행한다.
kube-proxy: 클러스터 내부의 네트워킹을 관리하는 네트워크 프록시. 외부에서 들어오는 트래픽을 적절한 Pod로 라우팅한다.
Pods: 워커 노드에서 실행되는 가장 작은 단위로, 컨테이너가 이 안에서 동작한다. 각 Pod에는 하나 이상의 컨테이너가 포함될 수 있다.
CRI(Container Runtime Interface): 그림에서 docker1이라고 명시된 컨테이너 런타임. 이 런타임이 실제로 컨테이너를 실행시키는 역할을 한다. 과거엔 Docker 를 컨테이너 런타임으로 사용했지만 현재는 Containerd, CRI-O 를 사용한다.

kubectl을 통해 API 서버에 명령을 내린다.
kubectl은 API 서버의 /api/v1/nodes 엔드포인트에 HTTP GET 요청한다.
API 서버는 kubectl로부터 받은 GET /api/v1/nodes 요청을 처리한다. 상태 정보를 저장한 etcd에서 모든 노드의 정보를 조회, 응답한다.
kubectl 클라이언트가 응답을 포맷팅하여 사용자에게 보여준다.

명령에 따라 사용자 설정을 etcd에 저장하고, 스케줄러가 생성할 파드를 적절한 노드로 결정하며 컨트롤러 매니저가 결정된 설정에 따라 워커 노드의 kubelet에 파드 생성 명령을 내린다.

kubectl을 통해 내린 거의 대부분 명령은 API 서버로 요청을 보낸다.

당연히 알아두면 좋을 것은 엄청나게 많다. 하지만 글이 길어지면 받아들이기 쉽지 않다는 것을 안다. 마치 이 글만 보면 될 것처럼 말했었지만 추가 포스팅을 통해 좀 더 알아야 할 내용을 적어야겠다.