Red Hat Summit개념
쿠버네티스에 관한 기초 지식이 있다면 쿠버네티스가 분산형 애플리케이션 및 서비스를 규모에 맞게 실행하도록 설계된 오픈소스 컨테이너 오케스트레이션 플랫폼임을 알 것입니다. 하지만 그 구성 요소와 구성 요소 간 상호 작용 방식을 이해하지 못할 수도 있습니다.
쿠버네티스의 기본적인 설계 원칙을 간단히 살펴보고 쿠버네티스의 다양한 구성 요소가 어떤 방식으로 함께 작동하는지 알아보겠습니다.
쿠버네티스 컨트롤 플레인 개념과 특징
컨트롤 플레인
쿠버네티스 클러스터의 신경 중추라 할 수 있는 컨트롤 플레인부터 살펴보겠습니다. 여기에는 클러스터를 제어하는 쿠버네티스 구성 요소와 클러스터의 상태 및 구성에 관한 데이터가 함께 있습니다. 이 핵심 쿠버네티스 구성 요소는 컨테이너가 필요한 리소스를 갖고 충분한 횟수로 실행되도록 하는 중요한 작업을 맡습니다.
컨트롤 플레인은 컴퓨팅 노드와 상시 연결되어 있습니다. 클러스터가 일정한 방식으로 실행되도록 구성했다면 컨트롤 플레인은 해당 방식에 따라 실행됩니다.
kube-apiserver
쿠버네티스 클러스터와 상호 작용해야 하나요? API에 요청하세요. 쿠버네티스 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)가 되도록 설계되었습니다.
쿠버네티스 노드 개념과 특징
노드
쿠버네티스 클러스터에는 최소 1개 이상의 컴퓨팅 노드가 필요하지만 일반적으로 여러 개가 있습니다. 포드는 노드에서 실행하도록 예약되고 오케스트레이션됩니다. 클러스터의 용량을 확장해야 한다면 노드를 더 추가하면 됩니다.
포드
포드는 쿠버네티스 오브젝트 모델에서 가장 작고 단순한 유닛으로, 애플리케이션의 단일 인스턴스를 나타냅니다. 각 포드는 컨테이너 실행 방식을 제어하는 옵션과 함께 컨테이너 하나 또는 긴밀히 결합된 일련의 컨테이너로 구성되어 있습니다. 포드를 퍼시스턴트 스토리지에 연결하여 스테이트풀(stateful) 애플리케이션을 실행할 수 있습니다.
컨테이너 런타임 엔진
컨테이너 실행을 위해 각 컴퓨팅 노드에는 컨테이너 런타임 엔진이 있습니다. 그중 한 가지 예가 Docker입니다. 하지만 쿠버네티스는 rkt, CRI-O와 같은 다른 Open Container Initiative 호환 런타임도 지원합니다.
kubelet
각 컴퓨팅 노드에는 컨트롤 플레인과 통신하는 매우 작은 애플리케이션인 kubelet이 있습니다. kublet은 컨테이너가 포드에서 실행되게 합니다. 컨트롤 플레인에서 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행합니다.
kube-proxy
각 컴퓨팅 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-proxy도 있습니다. kube-proxy는 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리합니다.
쿠버네티스 클러스터에 필요한 요소
퍼시스턴트 스토리지
쿠버네티스는 애플리케이션을 실행하는 컨테이너를 관리할 뿐만 아니라 클러스터에 연결된 애플리케이션 데이터도 관리할 수 있습니다. 쿠버네티스를 사용하면 사용자가 기본 스토리지 인프라에 관한 상세 정보를 알지 못해도 스토리지 리소스를 요청할 수 있습니다. 퍼시스턴트 볼륨은 포드가 아닌 클러스터에 따라 다르므로 포드보다 수명이 오래 지속될 수 있습니다.
컨테이너 레지스트리
쿠버네티스가 의존하는 컨테이너 이미지는 컨테이너 레지스트리에 저장됩니다. 이러한 레지스트리를 직접 구성하거나 제 3사가 구성할 수 있습니다.
기본 인프라
쿠버네티스를 원하는 곳에서 실행할 수 있습니다. 즉 베어 메탈 서버, 가상 머신, 퍼블릭 클라우드 제공업체, 프라이빗 클라우드, 하이브리드 클라우드 환경 등에서 실행할 수 있습니다. 쿠버네티스의 주요 이점 중 하나는 다양한 종류의 인프라에서 작동한다는 것입니다.
쿠버네티스 아키텍처의 장점과 기능
쿠버네티스 아키텍처에 대한 이 간략한 개요는 수박 겉핥기일 뿐입니다. 이 구성 요소들이 서로, 그리고 외부 리소스 및 인프라와 어떤 방식으로 통신하는지를 알면 쿠버네티스 클러스터 구성 및 보안 문제를 이해할 수 있습니다.
쿠버네티스는 대규모로 복잡하게 컨테이너화된 애플리케이션을 오케스트레이션할 수 있는 툴을 제공하지만 수많은 의사결정은 사용자의 몫입니다. 즉 운영 체제, 컨테이너 런타임, 지속적인 통합/지속적인 서비스 제공(CI/CD) 툴링, 애플리케이션 서비스, 스토리지 및 대부분의 기타 구성 요소를 사용자가 직접 선택할 수 있습니다. 역할 관리, 액세스 제어, 멀티테넌시, 보안 기본값 설정 작업도 관리해야 합니다. 이외에도 쿠버네티스를 직접 실행하거나 지원되는 버전을 제공할 수 있는 벤더와 협력할 수도 있습니다.
이러한 선택의 자유는 쿠버네티스가 지닌 유연성의 일부입니다. 쿠버네티스는 구현하기 복잡할 수 있지만 이를 사용하면 컨테이너화된 애플리케이션을 자신만의 방식으로 실행하고 조직 내 변화에 민첩하게 대응할 수 있습니다.
쿠버네티스로 클라우드 네이티브 애플리케이션 구축
이 웨비나 시리즈를 통해 애플리케이션을 구축, 실행, 배포 및 현대화하는 데 필요한 엔터프라이즈 쿠버네티스에서 데이터 플랫폼을 구축하는 방법과 관련한 전문가의 관점을 확인해 보세요.
쿠버네티스에 Red Hat OpenShift를 선택해야 하는 이유는 무엇인가요?
Red Hat은 쿠버네티스를 비롯한 오픈소스 컨테이너 기술의 선두주자이자 활발한 구축자로서 컨테이너 인프라 보안, 간소화, 자동 업데이트를 위한 필수 툴을 개발합니다.
Red Hat® OpenShift®는 엔터프라이즈급 쿠버네티스 배포판입니다. Red Hat OpenShift를 통해 팀은 DevOps를 위한 단일 통합 플랫폼을 얻게 됩니다. Red Hat OpenShift는 개발자에게 언어, 프레임워크, 미들웨어 및 데이터베이스를 선택할 수 있도록 하며 CI/CD를 통한 자동화 구축 및 배포로 생산성을 극대화합니다. 컨테이너용으로 설계된 데이터 및 스토리지 서비스 플랫폼인 Red Hat OpenShift Data Foundation도 제공합니다.
