쿠버네티스 컴포넌트

1 개요

Kuberentes Components

쿠버네티스 컴포넌트

https://kubernetes.io/docs/concepts/overview/components/

---

쿠버네티스를 배포하면 클러스터를 얻습니다.

쿠버네티스 클러스터는 노드라고 불리는 워커 머신 세트로 구성되며, 이 노드들은 컨테이너화된 애플리케이션을 실행합니다. 모든 클러스터에는 최소한 하나의 워커 노드가 있습니다.

워커 노드들은 애플리케이션 워크로드의 컴포넌트인 파드를 호스팅합니다. 컨트롤 플레인은 클러스터의 워커 노드와 파드를 관리합니다. 프로덕션 환경에서는 컨트롤 플레인이 보통 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 보통 여러 노드를 실행하여 내결함성(fault-tolerance)과 고가용성(high availability)을 제공합니다.

이 문서는 완전하고 작동하는 쿠버네티스 클러스터를 구성하는 데 필요한 다양한 컴포넌트를 설명합니다.

쿠버네티스 클러스터의 컴포넌트

2 컨트롤 플레인 컴포넌트

컨트롤 플레인 컴포넌트는 클러스터에 대한 전반적인 결정을 내리고(예: 스케줄링), 클러스터 이벤트를 감지하고 대응합니다(예: Deployment의 replicas 필드가 충족되지 않을 때 새 파드를 시작).

컨트롤 플레인 컴포넌트는 클러스터의 모든 머신에서 실행될 수 있습니다. 그러나 간단히 하기 위해 설정 스크립트는 일반적으로 모든 컨트롤 플레인 컴포넌트를 같은 머신에서 시작하며, 이 머신에서는 사용자 컨테이너를 실행하지 않습니다. 여러 머신에 걸쳐 실행되는 예시 컨트롤 플레인 설정에 대해서는 kubeadm을 사용하여 고가용성 클러스터 생성하기를 참조하십시오.

2.1 kube-apiserver

API 서버는 Kubernetes 컨트롤 플레인의 컴포넌트로, Kubernetes API를 노출합니다. API 서버는 Kubernetes 컨트롤 플레인의 프론트 엔드 역할을 합니다.

Kubernetes API 서버의 주요 구현체는 kube-apiserver입니다. kube-apiserver는 수평 확장을 염두에 두고 설계되었습니다. 즉, 더 많은 인스턴스를 배포함으로써 확장할 수 있습니다. 여러 인스턴스의 kube-apiserver를 실행하고, 그 인스턴스들 간의 트래픽을 분산시킬 수 있습니다.

2.2 etcd

Kubernetes의 모든 클러스터 데이터를 위한 백엔드 스토어로 사용되는 일관성 있고 고가용성의 키-값 저장소입니다.

Kubernetes 클러스터가 etcd를 백엔드 스토어로 사용하는 경우, 데이터를 백업 계획을 반드시 마련해야 합니다.

etcd에 대한 자세한 정보는 공식 문서에서 확인할 수 있습니다.

2.3 kube-scheduler

노드가 할당되지 않은 새로 생성된 파드를 감시하고 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트입니다.

스케줄링 결정에 고려되는 요소에는 개별 및 집합 자원 요구사항, 하드웨어/소프트웨어/정책 제약조건, 어피니티 및 안티-어피니티 사양, 데이터 로컬리티, 워크로드 간 간섭, 데드라인이 포함됩니다.

2.4 kube-controller-manager

컨트롤 플레인 컴포넌트로, 컨트롤러 프로세스를 실행합니다.

논리적으로는 각 컨트롤러가 별도의 프로세스이지만, 복잡성을 줄이기 위해 모든 컨트롤러를 단일 바이너리로 컴파일하여 단일 프로세스로 실행합니다.

다양한 유형의 컨트롤러가 있습니다. 그 예는 다음과 같습니다:

• Node 컨트롤러: 노드가 다운되었을 때 이를 감지하고 대응하는 역할을 합니다.
• Job 컨트롤러: 일회성 작업을 나타내는 Job 객체를 감시하고, 해당 작업을 완료하기 위해 Pod를 생성합니다.
• EndpointSlice 컨트롤러: EndpointSlice 객체를 채워서 서비스와 Pod 간의 연결을 제공합니다.
• ServiceAccount 컨트롤러: 새로운 네임스페이스에 대한 기본 ServiceAccount를 생성합니다.

위 목록은 전체 목록이 아닙니다.

2.5 cloud-controller-manager

클라우드 특정 제어 로직을 포함하는 Kubernetes 컨트롤 플레인 컴포넌트입니다. cloud-controller-manager를 사용하면 클러스터를 클라우드 제공자의 API에 연결할 수 있으며, 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터와 상호작용하는 컴포넌트와 분리합니다. cloud-controller-manager는 클라우드 제공자에 특정한 컨트롤러만 실행합니다. Kubernetes를 온프레미스에서 실행하거나 개인 PC 내의 학습 환경에서 실행하는 경우 클러스터에는 cloud-controller-manager가 없습니다.

kube-controller-manager와 마찬가지로 cloud-controller-manager는 여러 논리적으로 독립적인 제어 루프를 단일 바이너리로 결합하여 단일 프로세스로 실행합니다. 성능 향상 또는 장애 허용을 위해 수평으로 확장(여러 복사본 실행)할 수 있습니다.

다음 컨트롤러는 클라우드 제공자 의존성을 가질 수 있습니다:

• 노드 컨트롤러: 클라우드 제공자를 확인하여 노드가 응답을 중지한 후 클라우드에서 삭제되었는지 여부를 결정합니다.
• 라우트 컨트롤러: 기본 클라우드 인프라에서 라우트를 셋업합니다.
• 서비스 컨트롤러: 클라우드 제공자의 로드 밸런서를 생성, 업데이트, 삭제합니다.

3 노드 컴포넌트

노드 컴포넌트는 모든 노드에서 실행되어 실행 중인 파드를 유지하고 Kubernetes 런타임 환경을 제공합니다.

3.1 kubelet

클러스터의 각 노드에서 실행되는 에이전트입니다. 이 에이전트는 컨테이너가 파드 내에서 실행되고 있는지 확인합니다.

kubelet은 다양한 메커니즘을 통해 제공되는 PodSpec 세트를 받아 해당 PodSpec에 설명된 컨테이너가 실행되고 건강한 상태인지 보장합니다. kubelet은 Kubernetes가 생성하지 않은 컨테이너는 관리하지 않습니다.

3.2 kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, Kubernetes 서비스 개념의 일부를 구현합니다.

kube-proxy는 노드에서 네트워크 규칙을 유지관리합니다. 이러한 네트워크 규칙은 클러스터 내부 또는 외부의 네트워크 세션에서 Pods로의 네트워크 통신을 허용합니다.

kube-proxy는 운영체제의 패킷 필터링 계층이 있는 경우 이를 사용하며, 그렇지 않으면 kube-proxy 자체가 트래픽을 전달합니다.