제 6 장: 쿠버네티스 아키텍처 이해

이전까지 클라우드 네이티브의 큰 그림과 컨테이너 기술을 살펴보았다면, 이제부터는 쿠버네티스라는 강력한 오케스트레이션 도구의 내부를 깊숙이 들여다볼 차례입니다. 특히 제 3 부에서는 쿠버네티스를 이해하고 활용하는 데 있어 가장 핵심적인 ‘오브젝트’라는 개념을 중심으로 이야기를 풀어갈 것입니다.

그 첫 단추인 제 6장: 쿠버네티스 아키텍처 이해에서는 쿠버네티스가 어떤 구조로 이루어져 있고, 어떻게 동작하는지에 대한 근본적인 원리를 파헤쳐 봅니다. 마치 정교한 시계의 내부를 분해하여 각 부품의 역할과 상호작용을 배우는 것처럼, 이 장을 통해 쿠버네티스의 동작 방식에 대한 명확한 그림을 그리실 수 있을 것입니다. 이는 앞으로 배울 모든 쿠버네티스 기능의 튼튼한 토대가 되어 줄 것입니다.

먼저 6.1 쿠버네티스 클러스터 구성 요소에서는 쿠버네티스라는 거대한 시스템을 이루는 핵심 부품들을 하나하나 살펴봅니다.

6.1.1 컨트롤 플레인(Control Plane)은 쿠버네티스 클러스터의 ‘두뇌’와 같은 역할을 합니다. 클러스터 전체의 상태를 관리하고, 사용자의 요청을 받아 결정을 내리며, 모든 작업이 원하는 대로 진행되도록 지휘하는 곳이죠. 여기에는 API 서버, 분산 데이터 저장소인 etcd, 워커 노드에 파드를 배치하는 스케줄러, 그리고 클러스터 상태를 지속적으로 모니터링하고 조정하는 다양한 컨트롤러 매니저들이 포함됩니다. 이 구성 요소들의 역할을 이해하는 것은 쿠버네티스의 의사결정 과정을 이해하는 첫걸음입니다.
6.1.2 워커 노드(Worker Nodes)는 실제 컨테이너화된 애플리케이션들이 실행되는 ‘일꾼’들입니다. 컨트롤 플레인의 지시를 받아 컨테이너를 실행하고 관리하는 역할을 수행하죠. 각 워커 노드에는 컨트롤 플레인과 통신하며 컨테이너 생명주기를 관리하는 Kubelet, 네트워크 프록시 역할을 하는 Kube-proxy, 그리고 실제 컨테이너를 실행하는 컨테이너 런타임(예: containerd, CRI-O)이 존재합니다. 이 워커 노드들이 모여 애플리케이션을 실행할 수 있는 강력한 컴퓨팅 파워를 제공합니다.
6.1.3 애드온(Add-ons)은 쿠버네티스의 핵심 기능은 아니지만, 클러스터의 기능을 확장하고 사용 편의성을 높여주는 중요한 부가 요소들입니다. 예를 들어, 클러스터 내부의 DNS 서비스를 제공하거나, 웹 기반의 대시보드를 통해 클러스터를 관리하고, 클러스터의 로깅 및 모니터링 시스템을 구축하는 등의 기능을 애드온을 통해 구현할 수 있습니다. 어떤 애드온들이 있는지 아는 것은 쿠버네티스 생태계를 더 풍부하게 활용하는 데 도움이 됩니다.

다음으로 6.2 쿠버네티스 오브젝트 모델에서는 쿠버네티스와 소통하는 방식, 즉 ‘언어’에 대해 배웁니다. 쿠버네티스에서 관리하는 모든 것은 ‘오브젝트’라는 개념으로 추상화됩니다.

6.2.1 선언적 API와 상태 관리는 쿠버네티스를 사용하는 가장 중요한 패러다임입니다. 사용자는 “어떻게” 할지를 명령하는 것이 아니라, “어떤 상태가 되기를 원하는지”를 선언적으로 정의합니다. 예를 들어, “웹 서버 컨테이너 3개를 항상 실행시켜줘” 라고 선언하면, 쿠버네티스의 컨트롤 플레인이 현재 상태를 파악하고 원하는 상태에 도달하도록 필요한 조치(컨테이너 생성, 삭제, 재시작 등)를 알아서 수행합니다. 이 ‘원하는 상태(Desired State)’와 ‘현재 상태(Current State)’를 끊임없이 일치시키려는 메커니즘이 쿠버네티스 상태 관리의 핵심입니다.
6.2.2 오브젝트 명세(Spec)와 상태(Status)는 모든 쿠버네티스 오브젝트가 공통으로 가지는 구조입니다. 사용자는 오브젝트의 ‘명세(Spec)’ 필드에 원하는 상태를 기술합니다. 예를 들어, 어떤 컨테이너 이미지를 사용할지, 몇 개의 복제본을 실행할지 등을 정의하죠. 그러면 쿠버네티스 시스템은 이 명세를 바탕으로 작업을 수행한 후, 그 결과를 오브젝트의 ‘상태(Status)’ 필드에 기록합니다. 우리는 이 Status 필드를 통해 현재 클러스터의 실제 상태를 파악할 수 있습니다. Spec과 Status의 관계를 이해하는 것은 오브젝트를 정의하고 그 결과를 확인하는 데 필수적입니다.
6.2.3 API 그룹과 버전 관리는 쿠버네티스가 제공하는 방대한 종류의 오브젝트들을 체계적으로 관리하고, 시간이 지남에 따라 API가 안정적으로 발전할 수 있도록 하는 메커니즘입니다. 관련된 오브젝트들을 ‘API 그룹’으로 묶고, 각 API의 변경 이력을 ‘버전’으로 관리함으로써, 사용자는 특정 버전의 API를 안정적으로 사용하거나 새로운 기능을 점진적으로 도입할 수 있습니다. 이는 쿠버네티스의 확장성과 안정성을 뒷받침하는 중요한 개념입니다.

마지막으로 6.3 kubectl 기본 사용법 심화에서는 앞에서 배운 아키텍처와 오브젝트 모델 지식을 바탕으로, 쿠버네티스 클러스터와 실제로 상호작용하는 방법을 익힙니다. kubectl은 쿠버네티스 API와 통신하기 위한 가장 기본적인 커맨드라인 도구입니다.

6.3.1 오브젝트 생성, 조회, 수정, 삭제(CRUD)는 kubectl을 이용한 가장 기본적인 작업입니다. YAML이나 JSON 형식으로 정의된 오브젝트 명세 파일을 이용하여 새로운 오브젝트를 생성(Create)하고, 현재 클러스터에 존재하는 오브젝트들의 목록이나 상세 정보를 조회(Read)하며, 기존 오브젝트의 명세를 변경하여 업데이트(Update)하고, 더 이상 필요 없는 오브젝트를 제거(Delete)하는 방법을 배웁니다. 이 CRUD 작업은 쿠버네티스 관리의 기본 중의 기본입니다.
6.3.2 오브젝트 상태 상세 확인에서는 단순히 오브젝트의 존재 유무를 넘어, 해당 오브젝트가 현재 어떤 상태에 있는지, 예를 들어 파드가 정상적으로 실행 중인지, 어떤 이벤트들이 발생했는지 등 구체적인 정보를 확인하는 방법을 다룹니다. kubectl describe 와 같은 명령어를 통해 오브젝트의 Spec과 Status, 그리고 관련 이벤트들을 상세히 살펴보며 문제 해결의 단서를 찾는 방법을 익힙니다.
6.3.3 레이블과 셀렉터 활용은 쿠버네티스에서 여러 오브젝트들을 효율적으로 관리하고 연결하는 핵심 메커니즘입니다. 오브젝트에 임의의 키-값 쌍인 ‘레이블(Label)’을 붙여 식별하고 분류할 수 있으며, ‘셀렉터(Selector)’를 이용해 특정 레이블을 가진 오브젝트들만 선택하여 그룹으로 관리할 수 있습니다. 예를 들어, 특정 서비스가 어떤 파드들에게 트래픽을 전달해야 하는지 정의할 때 이 레이블과 셀렉터가 결정적인 역할을 합니다. 이는 쿠버네티스의 유연성과 강력한 연결성을 가능하게 하는 중요한 기능입니다.
6.3.4 어노테이션 활용은 레이블과 유사하지만, 식별이나 선택 목적이 아닌 부가적인 메타데이터를 오브젝트에 추가하기 위해 사용됩니다. 주로 도구나 라이브러리, 또는 운영자가 참고할 만한 정보(예: 빌드 버전, 담당자 연락처 등)를 기록하는 데 쓰입니다. 레이블과의 차이점을 이해하고 적절한 상황에 어노테이션을 활용하는 방법을 알아봅니다.

이처럼 제 6장을 통해 독자 여러분은 쿠버네티스의 내부 구조와 동작 원리, 핵심 추상화 개념인 오브젝트 모델, 그리고 이를 다루는 기본 도구인 kubectl 사용법까지, 쿠버네티스를 이해하기 위한 가장 근본적인 지식들을 습득하게 될 것입니다. 여기서 다져진 탄탄한 기초는 앞으로 이어질 파드, 서비스, 디플로이먼트 등 구체적인 오브젝트들을 배우고 활용하는 데 있어 무엇과도 바꿀 수 없는 자산이 될 것입니다