인프라 엔지니어를 위한 쿠버네티스(Kubernetes) 핵심 개념 정리

전통적인 서버 관리 업무가 클라우드 기반의 컨테이너 오케스트레이션으로 이동하면서, 쿠버네티스는 인프라 엔지니어에게 선택이 아닌 생존을 위한 필수 지식이 되었습니다. 하지만 방대한 개념과 복잡한 아키텍처 때문에 어디서부터 손을 대야 할지 막막한 경우가 많습니다.

쿠버네티스를 이해하기 위해 반드시 알아야 할 핵심 구조와 실무에서 자주 쓰이는 핵심 오브젝트들을 중심으로 개념을 정리해 드립니다.

쿠버네티스 아키텍처: 제어판과 노드

쿠버네티스는 크게 전체 시스템을 관리하는 **컨트롤 플레인(Control Plane)**과 실제 컨테이너가 실행되는 **워커 노드(Worker Node)**로 나뉩니다. 컨트롤 플레인의 API 서버는 사용자의 요청을 받고, 스케줄러는 컨테이너를 어느 노드에 배치할지 결정하며, etcd는 클러스터의 상태 데이터를 저장합니다.

인프라 엔지니어는 각 컴포넌트 간의 통신이 원활한지, 노드 자원이 효율적으로 배분되고 있는지를 모니터링하고 최적화하는 역할을 수행하게 됩니다.

Pod, Deployment, Service: 기본 오브젝트의 이해

가장 작은 배포 단위인 **Pod(파드)**는 하나 이상의 컨테이너를 포함합니다. 하지만 실무에서 파드를 직접 생성하는 일은 드뭅니다. 대신 **Deployment(디플로이먼트)**를 통해 파드의 개수를 유지하고 업데이트(Rolling Update) 전략을 관리합니다.

이렇게 생성된 파드들은 유동적인 IP를 갖기 때문에, 안정적인 접속 주소를 제공하는 Service(서비스) 오브젝트가 필요합니다. 로드 밸런싱 역할을 수행하는 서비스와 외부 노출을 담당하는 **Ingress(인그레스)**를 결합하여 안정적인 네트워크 환경을 구축하는 것이 인프라 설계의 핵심입니다.

선언적 명령과 상태 유지(Self-healing)

쿠버네티스의 가장 큰 매력은 '선언적(Declarative) 방식'입니다. 엔지니어가 "파드 3개를 유지해줘"라고 명세(YAML)를 던지면, 쿠버네티스는 어떤 상황에서도 그 상태를 유지하기 위해 노력합니다. 파드가 죽으면 자동으로 다시 살리고(Self-healing), 트래픽이 몰리면 늘립니다(Auto-scaling).

이러한 자동화 메커니즘을 정확히 이해하고 장애 상황을 시뮬레이션해보는 과정이 중요합니다. 인프라를 수동으로 만지는 것이 아니라, '코드로 관리되는 인프라(IaC)' 위에서 쿠버네티스를 제어하는 역량을 기르는 것이 미래형 엔지니어로 가는 길입니다.