[K8s] 기계는 죽지 않는다, 다만 다시 뜰 뿐

Kubernetes 아키텍처

쿠버네티스를 처음 접하면 보통 이렇게 생각한다. “이게 대체 뭐야...?”
컨테이너를 띄우는 건 알겠는데, 그게 왜 이렇게 복잡하게 생겼는지 감도 안 온다. 그러나 한번 구조를 뜯어보면, 꽤 치밀한 설계와 자동화의 미학이 보이기 시작한다. 요컨대, 사람이 손대지 않아도 ‘어떻게든 굴러가게’ 해주는 구조다.

이름하여, 제어와 실행의 분업 사회

쿠버네티스는 크게 두 부분으로 나뉜다. Control Plane, 그리고 Worker Node. 전자는 “야 거기 Pod 좀 띄워봐”라고 명령하는 사무실 과장님이고, 후자는 땀 흘리며 진짜로 띄우는 현장직이다.

Control Plane의 핵심은 kube-apiserver. 이놈은 모든 요청이 거쳐 가는 관문이다. 사람이든 기계든 말 걸려면 여기부터 통과해야 한다. kube-scheduler는 빈 자리를 보고 어디에 새 Pod를 놓을지 정하고, controller-manager는 “야 아직도 두 개야? 셋이라니까 셋!” 하며 상태 유지를 외친다. 모든 정보는 etcd에 저장된다. 클러스터의 흑역사까지 포함해서.

반면 Worker Node는 실제 일을 한다. kubelet은 명령을 받고 Pod를 실행한다. container runtime은 실질적인 컨테이너 실행기다. 예전엔 다들 Docker만 쓰더니 요즘은 containerd로 갈아타는 추세다. 마지막으로 kube-proxy는 통신 경로를 설정한다. 일종의 클러스터 내 우체국. 그런데 꽤 똑똑하다.

그림으로 보면, 조금 덜 무섭지 않고 더 무서움 ㅋㅋ

그림까지 봐야 이해가 간다니, 뭔가 배신감이 든다. 하지만 쿠버네티스는 원래 그런 것이므로..

네트워크는 마법처럼 작동하지만, 사실은 기본 기술

각 Pod는 고유한 IP를 갖는다. 같은 노드든 다른 노드든 상관없이 서로 직접 통신할 수 있다. 서비스 리소스를 만들면 로드밸런싱도 된다. 마치 그냥 되는 것처럼 보이지만, 사실 내부에서는 iptables랑 ipvs가 식은땀을 흘리고 있다.

쿠버네티스의 철학: 말해라, 그러면 이루어지리니

Kubernetes는 ‘선언적 제어’를 추구한다. 사용자는 원하는 상태를 선언하기만 하면 된다. 시스템은 실제 상태를 그에 맞춰 조정한다. 컨트롤러들은 이를 위해 오늘도 야근 중이다.

replicas: 3

3개가 되라고 하면, 죽었다 살아나서라도 3개가 된다. 좀비 시스템이 따로 없다.

직접 해보면 안다

• kubectl get componentstatuses — “Control Plane 다 살아 있니?”
• kubectl get nodes -o wide — “지금 우리에겐 몇 명의 일꾼이 있는가”
• kubectl describe node — “이 노드는 뭘 숨기고 있을까”
• kubectl get --raw="/healthz?verbose" — “그냥 아픈 곳 말해봐”

운영이란 결국 귀찮음을 감내하는 예술이다.

마무리

쿠버네티스를 쓰다 보면 점점 시스템이 아닌 철학을 다루는 기분이 든다. 설계를 잘 해두면 손댈 일이 없다. 잘못 해두면, 손도 못 댄다. 모든 건 kube-apiserver를 중심으로 돌아간다. 구조만 이해하면 나머지는 자동으로 정리된다. 단, 구조를 이해하는 데 시간이 꽤 걸린다는 게 함정.