이번 시리즈에서는 쿠버네티스의 내부 구조를 자세하게 알아보겠다.
목차
- 쿠버네티스 시스템 아키텍쳐와 제어 평면
1-1. 쿠버네티스의 시스템 아키텍처와 컴포넌트들의 상호작용
1-2. kube-apiserver의 요청 처리 파이프라인
1-3. etcd와 데이터 일관성 모델 - 오케스트레이션과 리소스 격리
2-1. kube-scheduler의 선정 알고리즘
2-2. Controller Manager과 Reconciliation Loop
2-3. 리눅스 커널을 기반으로 한 리소스 격리 (Cgroup & Namespace) - 노드 실행 환경과 네트워킹 (The Node & Connectivity)
3-1. kubelet과 Pod 생명주기
3-2. kube-proxy와 서비스 추상화
3-3. CNI 원리와 데이터 평면 가속화 - 운영 안정성과 데이터
4-1. 클러스터의 Obsercability와 Storage
4-2. CSI(Container Storage Interface)와 볼륨 프로비저닝 - 보안과 확장성
5-1. 보안 아키텍처와 입장 제어
5-2. Operator 패턴과 Custom Controller 구현
이제 본격적으로 들어가기 전에, 이 시리즈를 집필하는 이유에 대해 언급하고 가겠다.
왜 내부 구조인가?
얼마 전, bare-metal 클러스터에 Cilium을 올리다가 worker 노드의 cilium-agent가 기동 직후 계속 죽는 상황을 겪었다. 로그엔 SIGTERM이 찍혀 있었고, kubelet이 외부에서 프로세스를 종료하고 있다는 걸 알기까지 꽤 시간이 걸렸다. kubectl describe만 봐서는 알 수 없었고, 결국 /var/log/pods 아래를 직접 파서 kubelet의 동작 방식을 이해하고 나서야 원인을 추적할 수 있었다.
나는 쿠버네티스라는 툴을 사용할 줄만 알지 내부 구조를 제대로 모른다는 사실을 깨달았고, 나중에 운영을 할 때도 최적화를 할 수 없을것이라는 결론을 내렸다.
이런 이유로 내부 구조에 대한 시리즈를 집필하게 되었다.
쿠버네티스는 사실상 현대 인프라의 표준이 되었지만, 나를 포함한 일부의 개발자들은 kubectl로 리소스를 던지면 알아서 돌아가는 툴 정도로 알고 있는 사람들이 있을 것이다. 물론 추상화라는게 내부 구조를 몰라도 사용할 수 있게 하기 위해서 존재한다지만, 장애 상황에서는 그러한 추상화가 오히려 독이 되기도 한다.
- 왜 이 Pod가 스케쥴링되지 않지?
- 왜 API 서버 응답이 이 타이밍에 느려지는거지?
- 네트워크 패킷이 어떤 경로를 거쳐 목적지에 닿지?
이러한 질문들에 답하려면 쿠버네티스의 내부 원리를 알고 있어야 하며, 그저 작성한 YAML만 알고 있어서는 안된다.
이 시리즈의 방향성
Control Plane 컴포넌트들이 서로 어떻게 통신하는지, kubelet이 컨테이너를 실제로 어떻게 만들어내는지, 리눅스 커널이 프로세스를 어떻게 격리하는지, 그리고 네트워크 패킷이 Pod에서 Pod으로 이동하는 실제 경로를. 가장 거시적인 아키텍처에서 시작해서, 회차를 거듭할수록 커널 수준까지 내려갈 것이다.
서론은 여기까지 마치고, 이제 여정을 시작해 보자. 끝을 볼 수 있으면 좋겠다.
