쿠버네티스(Kubernetes, K8s) 란 무엇일까?

---

🏗️ 1. 쿠버네티스 아키텍처의 심장: 컨트롤 플레인(Control Plane)의 유기적 동작

쿠버네티스를 이해한다는 것은 단순히 명령어를 외우는 게 아닙니다. 우리가 kubectl apply -f deployment.yaml이라는 명령을 내렸을 때, 내부에서 어떤 '사건'들이 연쇄적으로 발생하는지를 아는 것이 핵심입니다.

① API Server: 모든 통신의 게이트웨이

모든 구성 요소(Scheduler, Controller, Kubelet 등)는 서로 직접 대화하지 않습니다. 무조건 API Server를 통해서만 소통합니다. 이것이 쿠버네티스가 거대한 시스템임에도 불구하고 고도의 유연성을 유지하는 비결입니다. API Server는 요청이 들어오면 권한을 확인(Authentication/Authorization)하고, 그 내용을 etcd에 기록합니다.

② etcd: 클러스터의 유일한 '진실의 원천'

etcd는 분산 키-값(Key-Value) 저장소입니다. 여기에 저장된 데이터가 곧 클러스터의 현재 상태입니다. 만약 etcd가 날아가면 클러스터는 뇌사 상태에 빠집니다. 그래서 고가용성(HA) 구성이 필수적입니다. etcd는 Raft 알고리즘을 통해 여러 노드 간의 데이터 일관성을 유지합니다.

③ Scheduler와 Controller Manager의 협업

• Controller Manager: "현재 파드가 2개네? 사용자는 3개를 원하시는데(Desired State)!"라며 차이점을 발견하고, 새로운 파드를 생성하라는 명세를 API Server에 보냅니다.
• Scheduler: API Server에 등록된 '아직 노드가 배정되지 않은 파드'를 발견합니다. 각 노드의 리소스 상황(CPU, RAM)을 계산해서 가장 적합한 노드를 점지해 줍니다.

④ Kubelet: 노드의 현장 관리자

자신이 관리하는 노드에 새로운 파드가 할당되었다는 소식을 API Server로부터 듣게 되면, Kubelet은 즉시 컨테이너 런타임(Docker 등)에 명령을 내려 컨테이너를 띄웁니다. 그리고 그 상태를 다시 API Server에 보고하죠.

---

🎡 2. 쿠버네티스의 철학: 선언적 API(Declarative API)와 제어 루프(Control Loop)

쿠버네티스는 '명령'을 받는 게 아니라 '의지'를 전달받습니다.

① 선언적 API vs 명령형 API

• 명령형: "파드 1개를 더 띄워줘." (일회성 명령)
• 선언적: "이 시스템에는 항상 파드가 3개 있어야 해." (상태 선언)

쿠버네티스는 사용자가 준 YAML 파일에 적힌 상태를 '희망하는 상태(Desired State)'로 설정합니다.

② Reconciliation Loop (조정 루프)

쿠버네티스 내부에서는 무한 루프가 돌고 있습니다.

1. 관찰(Observe): 현재 상태가 어떤가? (현재 파드 2개)
2. 차이 발견(Diff): 희망 상태(3개)와 현재 상태(2개)가 다르네?
3. 조정(Act): 부족한 1개를 더 띄우자!

이 단순해 보이는 루프가 수천 개가 모여 쿠버네티스의 강력한 자가 치유(Self-healing) 능력을 만듭니다. 서버 한 대가 불타 없어져도, 이 루프가 동작하여 다른 서버에 똑같은 환경을 즉시 재건하기 때문입니다.

---

📦 3. 파드(Pod): 왜 컨테이너를 직접 안 쓰고 '파드'로 감싸는가?

쿠버네티스의 최소 단위는 컨테이너가 아니라 파드(Pod)입니다.

• 왜? 현실의 서비스는 컨테이너 하나로만 돌아가지 않기 때문입니다. 주식 데이터를 수집하는 메인 컨슈머 컨네이너가 있다면, 옆에서 로그를 수집하거나 설정을 동기화해 주는 보조 컨테이너(Sidecar)가 필요할 때가 있습니다.
• 공유 자원: 파드 안에 있는 컨테이너들은 같은 IP 주소를 공유하고, 같은 디스크(Volume)를 공유합니다. 마치 한 대의 로컬 호스트 컴퓨터 안에서 여러 프로세스가 통신하는 것과 같은 환경을 만들어 줍니다.

---

💡 1차 요약: 인프라의 뇌와 근육

쿠버네티스는 etcd(기억)와 API Server(신경망)를 중심으로, Controller(판단)와 Kubelet(실행)이 끊임없이 대화하며 사용자가 선언한 '이상적인 세계'를 유지하기 위해 분투하는 시스템입니다.

---

🚀 꼬리 질문

쿠버네티스의 뇌 구조를 알았으니, 이제 실제로 이 녀석들에게 일을 시키기 위한 '설계도'를 그려볼 차례입니다.

"그럼 우리가 원하는 상태를 정의하는 YAML 파일의 구조는 어떻게 되어 있고, 그 안의 Deployment와 Service는 구체적으로 어떤 역할을 수행해?"