"Cluster API 개념"의 두 판 사이의 차이

2024년 4월 30일 (화) 16:10 기준 최신판

1 개요[ | ]

Concepts
개념

파일:Management-cluster.svg

2 관리 클러스터[ | ]

워크로드 클러스터의 수명주기를 관리하는 Kubernetes 클러스터. 관리 클러스터는 하나 이상의 제공자가 실행되는 곳이자 머신과 같은 리소스가 저장되는 곳이기도 합니다.

2.1 워크로드 클러스터[ | ]

관리 클러스터에서 수명주기를 관리하는 Kubernetes 클러스터.

3 인프라 제공자[ | ]

클러스터 또는 머신(예: VM, 네트워킹 등)에 필요한 인프라/컴퓨팅 리소스의 프로비저닝을 담당하는 구성요소. 예를 들어, 클라우드 인프라 제공자로는 AWS, Azure, Google가 있고 베어메탈 인프라 제공자로는 VMware, MAAS, metal3.io가 있습니다.

같은 인프라 제공자(예: EC2와 EKS를 모두 제공하는 AWS)로부터 리소스를 얻는 방법이 두 가지 이상인 경우, 각 방법을 베리언트(variant)라고 합니다.

4 부트스트랩 제공자[ | ]

서버를 Kubernetes 노드로 전환하는 작업 및 다음의 작업을 담당하는 구성요소

따로 지정하지 않은 경우, 클러스터 인증서 생성
컨트롤 플레인을 초기화하고, 완료될 때까지 다른 노드 생성을 제어
컨트롤 플레인 및 워커 노드를 클러스터에 조인

5 컨트롤 플레인[ | ]

컨프롤 플레인은 Kubernetes API를 제공하고 제어 루프를 사용하여 원하는 상태를 지속적으로 조정하는 구성요소 집합입니다.

자체 프로비저닝: 단일 클러스터 API 배포로 완전히 관리되는 파드 또는 머신으로 구성된 Kubernetes 컨프롤 플레인입니다. 예를 들어 kubeadm은 컨트롤 플레인 머신에서 kube-apiserver, kube-controller-manager, kube-scheduler와 같은 구성요소를 실행하기 위해 정적 파드를 사용합니다.
파드 기반 배포에는 외부 호스팅 클러스터가 필요합니다. 컨트롤 플레인 구성요소는 표준 Deployment 및 StatefulSet 객체를 사용하여 배포되고 API는 Service를 사용하여 노출됩니다.
외부 또는 관리형 컨프롤 플레인은 GKE, AKS, EKS, IKS와 같은 Cluster API 이외의 일부 시스템에 의해 제공되고 제어됩니다.

기본 제공자는 kubeadm을 사용하여 컨프롤 플레인을 부트스트랩합니다. v1alpha3부터, KubeadmControlPlane 객체를 통해 설정을 노출합니다. 그러면 컨트롤러 capi-kubeadm-control-plane-controller-manager는 KubeadmControlPlane 객체의 요청된 replicas를 기반으로 Machine 및 BootstrapConfig 객체를 생성할 수 있습니다.

6 커스텀 리소스 정의 (CRDs)[ | ]

CustomResourceDefinition은 Kubernetes API를 확장할 수 있는 빌트인 리소스입니다. 각 CustomResourceDefinition은 Kubernetes 설치의 커스터마이제이션을 나타냅니다. Cluster API는 여러 CustomResourceDefinition을 제공하고 이에 의존합니다.

6.1 Machine[ | ]

"머신(Machine)"은 Kubernetes 노드(예: VM)를 호스팅하는 인프라 구성요소에 대한 선언적 사양입니다. 새로운 Machine 객체가 생성되면 제공자별 컨트롤러는 Machine 사양과 일치하는 새 노드로 등록하기 위해 새 호스트를 프로비저닝하고 설치합니다. Machine의 사양이 업데이트되면 컨트롤러는 호스트를 업데이트된 사양과 일치하는 새로운 호스트로 교체합니다. Machine 객체가 삭제되면 해당 하위 인프라와 해당 노드가 컨트롤러에 의해 삭제됩니다.

Kubernetes 버전과 같은 공통 필드는 Machine 사양의 필드로 모델링됩니다. 제공자별 정보는 모두 InfrastructureRef의 일부이며 다른 제공자 간에 이동할 수 없습니다.

6.1.1 Machine 불변성 (제자리 업그레이드 vs. 교체)[ | ]

클러스터 API의 관점에서 볼 때 모든 머신은 변경불가(immutable)입니다. 머신이 생성되면 업데이트되지 않으며(레이블, 주석, 상태 제외) 삭제만 됩니다.

이러한 이유로, MachineDeployments가 선호됩니다. MachineDeployment는 코어 Deployment가 Pod 사양 변경을 처리하는 것과 동일한 방식으로 머신을 교체하여 변경사항을 처리합니다.

6.2 MachineDeployment[ | ]

MachineDeployment는 Machine 및 MachineSet에 대한 선언적 업데이트를 제공합니다.

MachineDeployment는 코어 Kubernetes Deployment와 유사하게 작동합니다. MachineDeployment는 이전 MachineSet과 새로 업데이트된 MachineSet 2개에 대한 변경사항을 롤아웃하여 Machine 사양에 대한 변경사항을 맞춤조정합니다.

6.3 MachineSet[ | ]

MachineSet의 목적은 주어진 시간에 구동되는 안정적인 머신 세트를 유지하는 것입니다.

MachineSet은 코어 Kubernetes ReplicaSet와 유사하게 작동합니다. MachineSet는 직접 사용하기 위한 것이 아니지만 MachineDeployments가 원하는 상태로 맞춤조정하는 데 사용되는 메커니즘입니다.

6.4 MachineHealthCheck[ | ]

MachineHealthCheck는 노드가 비정상(unhealthy)으로 간주되어야 하는 조건을 정의합니다.

노드가 지정된 사용자-설정 시간 동안 이러한 비정상 조건과 일치하면 MachineHealthCheck가 노드 복구를 시작합니다. 노드 복구는 해당 머신을 삭제하여 수행됩니다.

MachineHealthChecks는 MachineSet이 소유한 노드만 복구합니다. 이렇게 하면, MachineSet가 실패한 머신을 교체하기 위해 새 머신을 생성하므로, Kubernetes 클러스터의 용량이 손실되지 않습니다.

6.5 BootstrapData[ | ]

BootstrapData에는 인프라 제공자가 머신을 노드로 부트스트랩하는 데 사용하는 머신 또는 노드 역할별 초기화 데이터(일반적으로 cloud-init)가 포함되어 있습니다.

7 참고[ | ]

https://cluster-api.sigs.k8s.io/user/concepts

@@ 17번째 줄: / 17번째 줄: @@
 ==부트스트랩 제공자==
-A component responsible for turning a server into a Kubernetes node as well as for:
+서버를 Kubernetes 노드로 전환하는 작업 및 다음의 작업을 담당하는 구성요소
-Generating the cluster certificates, if not otherwise specified
+# 따로 지정하지 않은 경우, 클러스터 인증서 생성
-Initializing the control plane, and gating the creation of other nodes until it is complete
+# 컨트롤 플레인을 초기화하고, 완료될 때까지 다른 노드 생성을 제어
-Joining control plane and worker nodes to the cluster
+# 컨트롤 플레인 및 워커 노드를 클러스터에 조인
 ==컨트롤 플레인==
-The control plane is a set of components that serve the Kubernetes API and continuously reconcile desired state using control loops.
+컨프롤 플레인은 Kubernetes API를 제공하고 제어 루프를 사용하여 원하는 상태를 지속적으로 조정하는 구성요소 집합입니다.
-Self-provisioned: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment. e.g kubeadm uses static pods for running components such as kube-apiserver, kube-controller-manager and kube-scheduler on control plane machines.
+* '''자체 프로비저닝''': 단일 클러스터 API 배포로 완전히 관리되는 파드 또는 머신으로 구성된 Kubernetes 컨프롤 플레인입니다. 예를 들어 kubeadm은 컨트롤 플레인 머신에서 kube-apiserver, kube-controller-manager, kube-scheduler와 같은 구성요소를 실행하기 위해 정적 파드를 사용합니다.
+* '''파드 기반''' 배포에는 외부 호스팅 클러스터가 필요합니다. 컨트롤 플레인 구성요소는 표준 Deployment 및 StatefulSet 객체를 사용하여 배포되고 API는 Service를 사용하여 노출됩니다.
+* '''외부''' 또는 '''관리형''' 컨프롤 플레인은 GKE, AKS, EKS, IKS와 같은 Cluster API 이외의 일부 시스템에 의해 제공되고 제어됩니다.
-Pod-based deployments require an external hosting cluster. The control plane components are deployed using standard Deployment and StatefulSet objects and the API is exposed using a Service.
+기본 제공자는 kubeadm을 사용하여 컨프롤 플레인을 부트스트랩합니다. v1alpha3부터, <code>KubeadmControlPlane</code> 객체를 통해 설정을 노출합니다. 그러면 컨트롤러 <code>capi-kubeadm-control-plane-controller-manager</code>는 <code>KubeadmControlPlane</code> 객체의 요청된 replicas를 기반으로 Machine 및 BootstrapConfig 객체를 생성할 수 있습니다.
-External or Managed control planes are offered and controlled by some system other than Cluster API, such as GKE, AKS, EKS, or IKS.
-The default provider uses kubeadm to bootstrap the control plane. As of v1alpha3, it exposes the configuration via the KubeadmControlPlane object. The controller, capi-kubeadm-control-plane-controller-manager, can then create Machine and BootstrapConfig objects based on the requested replicas in the KubeadmControlPlane object.
 ==커스텀 리소스 정의 (CRDs)==
-A CustomResourceDefinition is a built-in resource that lets you extend the Kubernetes API. Each CustomResourceDefinition represents a customization of a Kubernetes installation. The Cluster API provides and relies on several CustomResourceDefinitions:
+CustomResourceDefinition은 Kubernetes API를 확장할 수 있는 빌트인 리소스입니다. 각 CustomResourceDefinition은 Kubernetes 설치의 커스터마이제이션을 나타냅니다. Cluster API는 여러 CustomResourceDefinition을 제공하고 이에 의존합니다.
 ===Machine===
-A “Machine” is the declarative spec for an infrastructure component hosting a Kubernetes Node (for example, a VM). If a new Machine object is created, a provider-specific controller will provision and install a new host to register as a new Node matching the Machine spec. If the Machine’s spec is updated, the controller replaces the host with a new one matching the updated spec. If a Machine object is deleted, its underlying infrastructure and corresponding Node will be deleted by the controller.
+"머신(Machine)"은 Kubernetes 노드(예: VM)를 호스팅하는 인프라 구성요소에 대한 선언적 사양입니다. 새로운 Machine 객체가 생성되면 제공자별 컨트롤러는 Machine 사양과 일치하는 새 노드로 등록하기 위해 새 호스트를 프로비저닝하고 설치합니다. Machine의 사양이 업데이트되면 컨트롤러는 호스트를 업데이트된 사양과 일치하는 새로운 호스트로 교체합니다. Machine 객체가 삭제되면 해당 하위 인프라와 해당 노드가 컨트롤러에 의해 삭제됩니다.
-Common fields such as Kubernetes version are modeled as fields on the Machine’s spec. Any information that is provider-specific is part of the InfrastructureRef and is not portable between different providers.
+Kubernetes 버전과 같은 공통 필드는 Machine 사양의 필드로 모델링됩니다. 제공자별 정보는 모두 InfrastructureRef의 일부이며 다른 제공자 간에 이동할 수 없습니다.
-====Machine Immutability (In-place Upgrade vs. Replace)====
+====Machine 불변성 (제자리 업그레이드 vs. 교체)====
-From the perspective of Cluster API, all Machines are immutable: once they are created, they are never updated (except for labels, annotations and status), only deleted.
+클러스터 API의 관점에서 볼 때 모든 머신은 변경불가(immutable)입니다. 머신이 생성되면 업데이트되지 않으며(레이블, 주석, 상태 제외) 삭제만 됩니다.
-For this reason, MachineDeployments are preferable. MachineDeployments handle changes to machines by replacing them, in the same way core Deployments handle changes to Pod specifications.
+이러한 이유로, MachineDeployments가 선호됩니다. MachineDeployment는 코어 Deployment가 Pod 사양 변경을 처리하는 것과 동일한 방식으로 머신을 교체하여 변경사항을 처리합니다.
 ===MachineDeployment===
-A MachineDeployment provides declarative updates for Machines and MachineSets.
+MachineDeployment는 Machine 및 MachineSet에 대한 선언적 업데이트를 제공합니다.
-A MachineDeployment works similarly to a core Kubernetes Deployment. A MachineDeployment reconciles changes to a Machine spec by rolling out changes to 2 MachineSets, the old and the newly updated.
+MachineDeployment는 코어 Kubernetes Deployment와 유사하게 작동합니다. MachineDeployment는 이전 MachineSet과 새로 업데이트된 MachineSet 2개에 대한 변경사항을 롤아웃하여 Machine 사양에 대한 변경사항을 맞춤조정합니다.
 ===MachineSet===
-A MachineSet’s purpose is to maintain a stable set of Machines running at any given time.
+MachineSet의 목적은 주어진 시간에 구동되는 안정적인 머신 세트를 유지하는 것입니다.
-A MachineSet works similarly to a core Kubernetes ReplicaSet. MachineSets are not meant to be used directly, but are the mechanism MachineDeployments use to reconcile desired state.
+MachineSet은 코어 Kubernetes ReplicaSet와 유사하게 작동합니다. MachineSet는 직접 사용하기 위한 것이 아니지만 MachineDeployments가 원하는 상태로 맞춤조정하는 데 사용되는 메커니즘입니다.
 ===MachineHealthCheck===
-A MachineHealthCheck defines the conditions when a Node should be considered unhealthy.
+MachineHealthCheck는 노드가 비정상(unhealthy)으로 간주되어야 하는 조건을 정의합니다.
-If the Node matches these unhealthy conditions for a given user-configured time, the MachineHealthCheck initiates remediation of the Node. Remediation of Nodes is performed by deleting the corresponding Machine.
+노드가 지정된 사용자-설정 시간 동안 이러한 비정상 조건과 일치하면 MachineHealthCheck가 노드 복구를 시작합니다. 노드 복구는 해당 머신을 삭제하여 수행됩니다.
-MachineHealthChecks will only remediate Nodes if they are owned by a MachineSet. This ensures that the Kubernetes cluster does not lose capacity, since the MachineSet will create a new Machine to replace the failed Machine.
+MachineHealthChecks는 MachineSet이 소유한 노드만 복구합니다. 이렇게 하면, MachineSet가 실패한 머신을 교체하기 위해 새 머신을 생성하므로, Kubernetes 클러스터의 용량이 손실되지 않습니다.
 ===BootstrapData===
-BootstrapData contains the Machine or Node role-specific initialization data (usually cloud-init) used by the Infrastructure Provider to bootstrap a Machine into a Node.
+BootstrapData에는 인프라 제공자가 머신을 노드로 부트스트랩하는 데 사용하는 머신 또는 노드 역할별 초기화 데이터(일반적으로 cloud-init)가 포함되어 있습니다.
 ==참고==