전체적으로 느낀 점

Kubernetes는 단순히 "컨테이너를 관리하는 도구"가 아니라, 전체 인프라의 상태를 코드로 정의하고 자동화하는 시스템이라는 걸 알게 되었다. 복잡하게 보였던 구성 요소들이 실제로는 잘 분리된 역할을 가지고 있다는 점이 인상 깊었고, 배울수록 실전에서 유용하겠다는 확신이 들었다.

배운 내용 요약

컨트롤 플레인과 클러스터 구조

• Control Plane은 클러스터의 두뇌로, 모든 오브젝트를 정의하고 감시하고 조율한다.

• etcd는 상태 저장소, Scheduler는 파드를 노드에 배치, Controller Manager는 상태를 지속적으로 유지.

• 워커 노드는 kubelet, kube-proxy, containerd 등의 구성 요소로 작동하며, 컨테이너 실행은 Kubernetes가 직접 하는 게 아니라 런타임에게 요청한다는 구조가 흥미로웠다.

오브젝트 vs 컨트롤러

• 오브젝트는 Pod, Service, PVC, ConfigMap처럼 기능 단위의 리소스

• 컨트롤러는 이들을 자동화·유지·복구하는 역할 (Deployment, HPA 등)

• 두 개념을 명확히 나눈 덕분에 Kubernetes의 확장성과 유연성이 보였다.

ConfigMap과 Secret

• ConfigMap: 설정값을 파드 외부에서 관리 → 환경별로 유연하게 구성 가능

• Secret: 민감정보 저장 (Base64 인코딩, 메모리 마운트)

• 특히 Secret이 노드 메모리에 저장되고, 수정 시 kubelet이 주기적으로 반영하는 구조는 실제 운영환경에서 고려할 보안 요소가 많다는 걸 보여줌

Service

• 서비스는 파드 IP가 변해도 고정된 접근점을 제공하는 추상화 계층

• ClusterIP, NodePort, LoadBalancer, ExternalName 타입마다 용도가 다르고,

• 내부 DNS 기반의 이름 접근(서비스 디스커버리)은 마이크로서비스 아키텍처의 핵심

Probe (Liveness, Readiness, Startup)

• 컨테이너가 살아있는지(Liveness), 준비됐는지(Readiness), 시작 중인지(Startup) 체크 가능

• Kubernetes가 단순 배포 도구가 아닌, 운영과 회복 기능까지 내장하고 있다는 걸 실감함

• 설정에 따라 서비스 유입 제한, 자동 재시작 등 운영자가 손 쓸 필요 없는 자동화 처리가 가능

HPA (Horizontal Pod Autoscaler)

• 설정된 기준(CPU 등)에 따라 파드 수를 자동으로 조절

• 이상적인 스케일링과 현실적인 지연 시나리오를 비교하면서, HPA는 전능한 도구가 아니라 보조적인 수단임을 인지하게 됨