1 개요
- Concepts
- 개념
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
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.
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.
6.1.1 Machine Immutability (In-place Upgrade vs. Replace)
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.
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.
6.2 MachineDeployment
A MachineDeployment provides declarative updates for Machines and MachineSets.
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.
6.3 MachineSet
A MachineSet’s purpose is to maintain a stable set of Machines running at any given time.
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.
6.4 MachineHealthCheck
MachineHealthCheck는 노드가 비정상(unhealthy)으로 간주되어야 하는 조건을 정의합니다.
노드가 지정된 사용자-설정 시간 동안 이러한 비정상 조건과 일치하면 MachineHealthCheck가 노드 복구를 시작합니다. 노드 복구는 해당 머신을 삭제하여 수행됩니다.
MachineHealthChecks는 MachineSet이 소유한 노드만 복구합니다. 이렇게 하면, MachineSet가 실패한 머신을 교체하기 위해 새 머신을 생성하므로, Kubernetes 클러스터의 용량이 손실되지 않습니다.
6.5 BootstrapData
BootstrapData에는 인프라 제공자가 Machine을 Node로 부트스트랩하는 데 사용하는 Machine 또는 Node 역할별 초기화 데이터(일반적으로 cloud-init)가 포함되어 있습니다.
7 참고
-
{{comment.page_title}} ―{{comment.name}}