쿠버네티스 아키텍처 소개

• 쿠버네티스 아키텍처는 컨트롤 플레인/작업자 노드 모델을 기반으로 합니다.
• 쿠버네티스 클러스터는 안전하고 사용하기 쉬우며 확장 가능해야 합니다.
• 클러스터는 두 부분으로 구성됩니다. 전역적인 의사 결정을 내리는 컨트롤 플레인과 애플리케이션을 실행하는 노드입니다.
• 기본적으로 쿠버네티스에는 서로 다른 노드의 포드 간 통신 방법, 인터넷 트래픽을 내부로 라우팅하는 방법, 로그를 간편하게 확인하는 방법이 포함되어 있지 않습니다.
• 쿠버네티스는 규모가 크고 복잡한 컨테이너화된 애플리케이션을 오케스트레이션하는 데 필요한 툴을 제공하지만, 많은 결정은 사용자가 직접 내려야 합니다.

쿠버네티스 아키텍처란?

쿠버네티스 아키텍처는 컨트롤 플레인/작업자 노드 모델을 기반으로 합니다. 클러스터는 크게 두 계층으로 나뉩니다. 하나는 전역적인 의사 결정을 내리고 클러스터를 관리하는 컨트롤 플레인이고, 다른 하나는 컨테이너 내에서 애플리케이션을 실제로 실행하는 작업자 노드입니다.

쿠버네티스의 기본 개념만 알고 있더라도 쿠버네티스가 분산 애플리케이션과 서비스를 대규모로 실행하도록 설계된 오픈소스 컨테이너 오케스트레이션 플랫폼이라는 점은 알고 있을 것입니다. 하지만 쿠버네티스의 구성 요소와 이러한 요소의 상호작용 방식은 잘 모를 수 있습니다.

먼저 쿠버네티스의 기반이 되는 설계 원칙을 간략히 살펴본 다음, 쿠버네티스의 다양한 구성 요소가 어떻게 함께 작동하는지 알아보겠습니다.

쿠버네티스 클러스터는 쿠버네티스 구현 세부 사항에 설명된 3가지 원칙을 기반으로 설계됩니다.

쿠버네티스 클러스터는 다음과 같은 특성을 갖춰야 합니다.

• 보안성: 최신 보안 모범 사례를 따라야 합니다.
• 사용 편의성: 몇 가지 간단한 커맨드로 작동할 수 있어야 합니다.
• 확장 가능성: 하나의 공급업체만을 선호해서는 안 되고 구성 파일을 통해 사용자 정의할 수 있어야 합니다.

정상적으로 작동하는 쿠버네티스 배포를 클러스터라고 합니다. 쿠버네티스 클러스터는 컨트롤 플레인과 컴퓨팅 머신(또는 노드)의 2개 부분으로 시각화할 수 있습니다. 각 노드는 자체 Linux® 환경이며 물리 또는 가상 머신일 수 있습니다. 각 노드는 컨테이너로 이루어진 포드를 실행합니다.

이 다이어그램은 쿠버네티스 클러스터의 각 구성 요소가 서로 어떻게 연결되어 있는지를 보여줍니다.

쿠버네티스 컨트롤 플레인은 클러스터의 '두뇌'입니다. 애플리케이션 스케줄링과 같은 전역적인 의사 결정을 내리고, 클러스터 이벤트를 감지하고 이에 대응하며, 클러스터의 실제 상태가 사용자가 선언한 원하는 상태와 일치하도록 합니다.

쿠버네티스 컨트롤 플레인에는 클러스터를 제어하는 구성 요소와 클러스터의 상태 및 구성에 관한 데이터가 있습니다. 이러한 핵심 쿠버네티스 구성 요소는 컨테이너가 필요한 리소스를 갖춘 상태로 충분한 수만큼 실행되도록 하는 중요한 작업을 담당합니다. 

컨트롤 플레인은 컴퓨팅 머신과 지속적으로 통신합니다. 사용자가 클러스터의 실행 방식을 구성하면 컨트롤 플레인이 해당 구성대로 실행되도록 합니다.

kube-apiserver

쿠버네티스 API는 쿠버네티스 컨트롤 플레인의 프론트엔드로, 내부 및 외부 요청을 처리합니다. API 서버는 요청이 유효한지 판별하고 유효한 요청을 처리합니다. REST 호출이나 kubectl 커맨드라인 인터페이스 또는 kubeadm과 같은 기타 CLI(command-line interface)를 통해 API에 액세스할 수 있습니다.

kube-scheduler

스케줄러는 CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터의 상태를 고려합니다. 그런 다음 포드를 적절한 컴퓨팅 노드에 예약합니다.

kube-controller-manager

컨트롤러는 실제로 클러스터를 실행하며, 쿠버네티스 controller-manager에는 여러 컨트롤러 기능이 하나로 통합되어 있습니다. 하나의 컨트롤러는 스케줄러를 참고하여 정확한 수의 포드가 실행되게 합니다. 포드에 문제가 생기면 또 다른 컨트롤러가 이를 감지하고 대응합니다. 또 다른 컨트롤러는 서비스를 포드에 연결하여 요청이 올바른 엔드포인트로 전달되게 합니다. 이 밖에도 어카운트와 API 액세스 토큰을 생성하는 컨트롤러가 있습니다.

etcd

클러스터의 상태에 대한 구성 데이터 및 정보는 키-값 저장소 데이터베이스인 etcd에 존재합니다. 내결함성을 갖춘 분산형 etcd는 클러스터에 관한 궁극적 정보 소스(Source Of Truth, SOT)가 되도록 설계되었습니다.

컨트롤 플레인이 두뇌 역할을 한다면 쿠버네티스 작업자 노드는 근육과 같습니다. 애플리케이션을 실제로 실행하는 핵심 작업을 담당합니다.

쿠버네티스 노드는 물리 머신일 수도 있고 가상 머신(VM)일 수도 있습니다. 노드 내부에서는 컨트롤 플레인에서 지시를 받고, 컨테이너를 실행하고, 네트워킹을 관리하고, 상태 정보를 다시 보고하는 작업이 지속적으로 반복됩니다.

쿠버네티스 클러스터에는 최소 1개 이상의 컴퓨팅 노드가 필요하지만, 일반적으로는 여러 개가 있습니다. 포드는 노드에서 실행되도록 스케줄링되고 오케스트레이션됩니다. 클러스터의 용량을 확장해야 한다면 노드를 더 추가하면 됩니다.

포드

포드는 쿠버네티스 오브젝트 모델에서 가장 작고 단순한 단위입니다. 애플리케이션 인스턴스 하나를 나타냅니다. 각 포드는 컨테이너 실행 방식을 제어하는 옵션과 함께 하나의 컨테이너 또는 긴밀히 결합된 일련의 컨테이너들로 구성되어 있습니다. Stateful 애플리케이션을 실행할 수 있도록 포드를 퍼시스턴트 스토리지에 연결할 수 있습니다.

컨테이너 런타임 엔진

컨테이너 실행을 위해 컴퓨팅 노드마다 컨테이너 런타임 엔진이 있습니다. 그중 한 예시가 Docker입니다. 하지만 쿠버네티스는 rkt, CRI-O와 같은 다른 오픈 컨테이너 이니셔티브 호환 런타임도 지원합니다.

Kubelet

각 컴퓨팅 노드에는 컨트롤 플레인과 통신하는 매우 작은 애플리케이션인 kubelet이 있습니다. kubelet의 역할은 컨테이너가 포드에서 실행되게 하는 것입니다. 컨트롤 플레인에서 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행합니다.

kube-proxy

각 컴퓨팅 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-proxy도 있습니다. kube-proxy는 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리합니다.

컨트롤 플레인과 작업자 노드를 갖추면 기술적으로는 쿠버네티스 클러스터가 완성됩니다. 하지만 이 상태로는 기능이 매우 제한적입니다. 기본적으로 쿠버네티스에는 서로 다른 노드의 포드가 통신하는 방법, 인터넷 트래픽을 클러스터 내부로 라우팅하는 방법, 로그를 간편하게 확인하는 방법이 포함되어 있지 않습니다.

클러스터를 프로덕션 환경에서 사용할 수 있는 상태로 만들려면 애드온과 지원 인프라를 설치해야 합니다.

1. 네트워킹: 쿠버네티스에서는 서로 다른 노드의 포드가 원활하게 통신할 수 있도록 가상 네트워크 오버레이가 필요합니다. 이 네트워크 계층을 생성하고 각 포드에 고유한 IP 주소를 할당하려면 Cilium 또는 Calico와 같은 컨테이너 네트워크 인터페이스(CNI) 플러그인을 설치해야 합니다.
2. Ingress 컨트롤러: 내부 트래픽은 자동으로 처리되지만 외부 트래픽을 받아들이려면 게이트웨이가 필요합니다. NGINX 또는 Traefik과 같은 Ingress 컨트롤러는 리버스 프록시 및 로드 밸런서 역할을 하며 외부 인터넷 트래픽을 클러스터 내부의 올바른 서비스로 안전하게 라우팅합니다.
3. 클러스터 DNS: 포드는 재시작할 때마다 IP 주소가 계속 변경되므로 네트워크 경로를 하드코딩할 수 없습니다. 일반적으로 CoreDNS를 사용하는 클러스터 DNS 제공업체는 고정된 도메인 이름을 서비스에 자동으로 매핑하여 애플리케이션이 언제든 서로를 찾을 수 있도록 합니다.
4. 스토리지 프로비저너: 컨테이너는 기본적으로 Stateless 방식이므로 장애가 발생하면 컨테이너에 저장된 데이터가 모두 사라집니다. 컨테이너 스토리지 인터페이스(CSI)는 클러스터를 클라우드 디스크나 NFS와 같은 외부 물리 스토리지에 연결하고 영구 디스크를 자동으로 프로비저닝하여 연결함으로써 재시작 후에도 데이터를 유지할 수 있도록 합니다.
5. 관측성 스택: 애플리케이션이 여러 머신에 분산되어 있으므로 문제를 해결하려면 중앙화된 인사이트가 필요합니다. Prometheus 및 Grafana와 같은 툴은 클러스터 메트릭을 모니터링하고 FluentBit과 같은 로깅 에이전트는 컨테이너 로그를 하나의 검색 가능한 대시보드에 통합합니다.

지금까지 살펴본 쿠버네티스 아키텍처의 개요는 아주 기본적인 내용에 불과합니다. 이러한 구성 요소가 서로 그리고 외부 리소스 및 인프라와 어떻게 통신하는지 생각해 보면 쿠버네티스 클러스터를 구성하고 보호하는 일이 얼마나 어려운지 알 수 있습니다.

쿠버네티스는 규모가 크고 복잡한 컨테이너화된 애플리케이션을 오케스트레이션하는 데 필요한 툴을 제공하지만, 많은 결정은 사용자가 직접 내려야 합니다. 운영 체제, 컨테이너 런타임, 지속적 통합/지속적 제공(CI/CD) 툴, 애플리케이션 서비스, 스토리지 및 기타 대부분의 구성 요소를 직접 선택해야 합니다. 또한 역할, 액세스 제어, 멀티테넌시, 안전한 기본 설정도 관리해야 합니다. 쿠버네티스를 직접 운영할지, 아니면 지원되는 버전을 제공하는 벤더와 협력할지도 선택할 수 있습니다.

이러한 선택의 자유는 쿠버네티스가 지닌 유연성의 일부입니다. 구현 과정이 복잡할 수는 있지만 쿠버네티스를 사용하면 원하는 방식으로 컨테이너화된 애플리케이션을 실행하고 조직의 변화에 민첩하게 대응할 수 있는 강력한 역량을 확보할 수 있습니다.

쿠버네티스로 클라우드 네이티브 애플리케이션 구축

이 웨비나 시리즈에서는 애플리케이션을 구축, 실행, 배포, 현대화하는 데 필요한 엔터프라이즈 쿠버네티스 기반 데이터 플랫폼을 구축하는 데 도움이 되는 전문가의 관점을 살펴볼 수 있습니다. 

온디맨드 웹 시리즈 보기

Red Hat은 쿠버네티스를 비롯한 오픈소스 컨테이너 기술을 선도하며 활발히 구축하는 기업으로서 컨테이너 인프라의 보안, 간소화, 자동 업데이트를 위한 필수 툴을 개발합니다. 

Red Hat® OpenShift®는 엔터프라이즈급 쿠버네티스 배포판입니다. Red Hat OpenShift를 사용하면 팀은 DevOps를 위한 단일 통합 플랫폼을 활용할 수 있습니다. Red Hat OpenShift는 개발자가 원하는 언어, 프레임워크, 미들웨어, 데이터베이스를 선택할 수 있도록 지원하며, CI/CD를 통한 빌드 및 배포 자동화를 제공하여 생산성을 크게 높여줍니다. 또한 컨테이너를 위해 설계된 데이터 및 스토리지 서비스 플랫폼인 Red Hat OpenShift Data Foundation도 제공됩니다.

자세히 알아보기