쿠버네티스 컴포넌트 편집하기

==개요==
{{작성중}}
[[분류: k8s]]
;Kuberentes Components
;쿠버네티스 컴포넌트
https://kubernetes.io/docs/concepts/overview/components/
----
쿠버네티스를 배포하면 클러스터를 얻습니다.

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

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

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

[[파일:components-of-kubernetes.svg|900px]]
<br>쿠버네티스 클러스터의 컴포넌트

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

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

===kube-apiserver===
API 서버는 Kubernetes 컨트롤 플레인의 컴포넌트로, Kubernetes API를 노출합니다. API 서버는 Kubernetes [[k8s 컨트롤 플레인|컨트롤 플레인]]의 프론트 엔드 역할을 합니다.

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

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

Kubernetes 클러스터가 etcd를 백엔드 스토어로 사용하는 경우, 데이터를 [[쿠버네티스를 위한 etcd 클러스터 운영#etcd 클러스터 백업|백업]] 계획을 반드시 마련해야 합니다.

etcd에 대한 자세한 정보는 [https://etcd.io/docs/ 공식 문서]에서 확인할 수 있습니다.

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

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

===kube-controller-manager===
===cloud-controller-manager===

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

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

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

===kube-proxy===
===컨테이너 런타임===

==애드온==
===DNS===
===웹 UI (대시보드)===
===컨테이너 리소스 모니터링===
===클러스터-수준 로깅===
===네트워크 플러그인===
==다음 내용==
@@ 35번째 줄: / 35번째 줄: @@
 ===kube-scheduler===
-노드가 할당되지 않은 새로 생성된 [[k8s 파드|파드]]를 감시하고 실행할 [[k8s 노드|노드]]를 선택하는 컨트롤 플레인 컴포넌트입니다.
+노드가 할당되지 않은 새로 생성된 파드를 감시하고 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트입니다.
 스케줄링 결정에 고려되는 요소에는 개별 및 집합 자원 요구사항, 하드웨어/소프트웨어/정책 제약조건, 어피니티 및 안티-어피니티 사양, 데이터 로컬리티, 워크로드 간 간섭, 데드라인이 포함됩니다.
-===[[kube-controller-manager]]===
+===kube-controller-manager===
-컨트롤 플레인 컴포넌트로, [[k8s 컨트롤러|컨트롤러]] 프로세스를 실행합니다.
+===cloud-controller-manager===
-논리적으로는 각 컨트롤러가 별도의 프로세스이지만, 복잡성을 줄이기 위해 모든 컨트롤러를 단일 바이너리로 컴파일하여 단일 프로세스로 실행합니다.
-다양한 유형의 컨트롤러가 있습니다. 그 예는 다음과 같습니다:
-* Node 컨트롤러: 노드가 다운되었을 때 이를 감지하고 대응하는 역할을 합니다.
-* Job 컨트롤러: 일회성 작업을 나타내는 Job 객체를 감시하고, 해당 작업을 완료하기 위해 Pod를 생성합니다.
-* EndpointSlice 컨트롤러: EndpointSlice 객체를 채워서 서비스와 Pod 간의 연결을 제공합니다.
-* ServiceAccount 컨트롤러: 새로운 네임스페이스에 대한 기본 ServiceAccount를 생성합니다.
-위 목록은 전체 목록이 아닙니다.
-===[[cloud-controller-manager]]===
-클라우드 특정 제어 로직을 포함하는 [[Kubernetes 컨트롤 플레인]] 컴포넌트입니다. cloud-controller-manager를 사용하면 클러스터를 클라우드 제공자의 API에 연결할 수 있으며, 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터와 상호작용하는 컴포넌트와 분리합니다. cloud-controller-manager는 클라우드 제공자에 특정한 컨트롤러만 실행합니다. Kubernetes를 온프레미스에서 실행하거나 개인 PC 내의 학습 환경에서 실행하는 경우 클러스터에는 cloud-controller-manager가 없습니다.
-kube-controller-manager와 마찬가지로 cloud-controller-manager는 여러 논리적으로 독립적인 제어 루프를 단일 바이너리로 결합하여 단일 프로세스로 실행합니다. 성능 향상 또는 장애 허용을 위해 수평으로 확장(여러 복사본 실행)할 수 있습니다.
-다음 컨트롤러는 클라우드 제공자 의존성을 가질 수 있습니다:
-* 노드 컨트롤러: 클라우드 제공자를 확인하여 노드가 응답을 중지한 후 클라우드에서 삭제되었는지 여부를 결정합니다.
-* 라우트 컨트롤러: 기본 클라우드 인프라에서 라우트를 셋업합니다.
-* 서비스 컨트롤러: 클라우드 제공자의 로드 밸런서를 생성, 업데이트, 삭제합니다.
 ==노드 컴포넌트==