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

(새 문서: ==개요== ;Concepts ;개념 파일:management-cluster.svg ==참고== * https://cluster-api.sigs.k8s.io/user/concepts 분류: cluster-api)
 
 
(같은 사용자의 중간 판 12개는 보이지 않습니다)
4번째 줄: 4번째 줄:


[[파일:management-cluster.svg]]
[[파일:management-cluster.svg]]
==관리 클러스터==
워크로드 클러스터의 수명주기를 관리하는 Kubernetes 클러스터. 관리 클러스터는 하나 이상의 제공자가 실행되는 곳이자 머신과 같은 리소스가 저장되는 곳이기도 합니다.
===워크로드 클러스터===
관리 클러스터에서 수명주기를 관리하는 Kubernetes 클러스터.
==인프라 제공자==
클러스터 또는 머신(예: VM, 네트워킹 등)에 필요한 인프라/컴퓨팅 리소스의 프로비저닝을 담당하는 구성요소. 예를 들어, 클라우드 인프라 제공자로는 AWS, Azure, Google가 있고 베어메탈 인프라 제공자로는 VMware, MAAS, metal3.io가 있습니다.
같은 인프라 제공자(예: EC2와 EKS를 모두 제공하는 AWS)로부터 리소스를 얻는 방법이 두 가지 이상인 경우, 각 방법을 베리언트(variant)라고 합니다.
==부트스트랩 제공자==
서버를 Kubernetes 노드로 전환하는 작업 및 다음의 작업을 담당하는 구성요소
# 따로 지정하지 않은 경우, 클러스터 인증서 생성
# 컨트롤 플레인을 초기화하고, 완료될 때까지 다른 노드 생성을 제어
# 컨트롤 플레인 및 워커 노드를 클러스터에 조인
==컨트롤 플레인==
컨프롤 플레인은 Kubernetes API를 제공하고 제어 루프를 사용하여 원하는 상태를 지속적으로 조정하는 구성요소 집합입니다.
* '''자체 프로비저닝''': 단일 클러스터 API 배포로 완전히 관리되는 파드 또는 머신으로 구성된 Kubernetes 컨프롤 플레인입니다. 예를 들어 kubeadm은 컨트롤 플레인 머신에서 kube-apiserver, kube-controller-manager, kube-scheduler와 같은 구성요소를 실행하기 위해 정적 파드를 사용합니다.
* '''파드 기반''' 배포에는 외부 호스팅 클러스터가 필요합니다. 컨트롤 플레인 구성요소는 표준 Deployment 및 StatefulSet 객체를 사용하여 배포되고 API는 Service를 사용하여 노출됩니다.
* '''외부''' 또는 '''관리형''' 컨프롤 플레인은 GKE, AKS, EKS, IKS와 같은 Cluster API 이외의 일부 시스템에 의해 제공되고 제어됩니다.
기본 제공자는 kubeadm을 사용하여 컨프롤 플레인을 부트스트랩합니다. v1alpha3부터, <code>KubeadmControlPlane</code> 객체를 통해 설정을 노출합니다. 그러면 컨트롤러 <code>capi-kubeadm-control-plane-controller-manager</code>는 <code>KubeadmControlPlane</code> 객체의 요청된 replicas를 기반으로 Machine 및 BootstrapConfig 객체를 생성할 수 있습니다.
==커스텀 리소스 정의 (CRDs)==
CustomResourceDefinition은 Kubernetes API를 확장할 수 있는 빌트인 리소스입니다. 각 CustomResourceDefinition은 Kubernetes 설치의 커스터마이제이션을 나타냅니다. Cluster API는 여러 CustomResourceDefinition을 제공하고 이에 의존합니다.
===Machine===
"머신(Machine)"은 Kubernetes 노드(예: VM)를 호스팅하는 인프라 구성요소에 대한 선언적 사양입니다. 새로운 Machine 객체가 생성되면 제공자별 컨트롤러는 Machine 사양과 일치하는 새 노드로 등록하기 위해 새 호스트를 프로비저닝하고 설치합니다. Machine의 사양이 업데이트되면 컨트롤러는 호스트를 업데이트된 사양과 일치하는 새로운 호스트로 교체합니다. Machine 객체가 삭제되면 해당 하위 인프라와 해당 노드가 컨트롤러에 의해 삭제됩니다.
Kubernetes 버전과 같은 공통 필드는 Machine 사양의 필드로 모델링됩니다. 제공자별 정보는 모두 InfrastructureRef의 일부이며 다른 제공자 간에 이동할 수 없습니다.
====Machine 불변성 (제자리 업그레이드 vs. 교체)====
클러스터 API의 관점에서 볼 때 모든 머신은 변경불가(immutable)입니다. 머신이 생성되면 업데이트되지 않으며(레이블, 주석, 상태 제외) 삭제만 됩니다.
이러한 이유로, MachineDeployments가 선호됩니다. MachineDeployment는 코어 Deployment가 Pod 사양 변경을 처리하는 것과 동일한 방식으로 머신을 교체하여 변경사항을 처리합니다.
===MachineDeployment===
MachineDeployment는 Machine 및 MachineSet에 대한 선언적 업데이트를 제공합니다.
MachineDeployment는 코어 Kubernetes Deployment와 유사하게 작동합니다. MachineDeployment는 이전 MachineSet과 새로 업데이트된 MachineSet 2개에 대한 변경사항을 롤아웃하여 Machine 사양에 대한 변경사항을 맞춤조정합니다.
===MachineSet===
MachineSet의 목적은 주어진 시간에 구동되는 안정적인 머신 세트를 유지하는 것입니다.
MachineSet은 코어 Kubernetes ReplicaSet와 유사하게 작동합니다. MachineSet는 직접 사용하기 위한 것이 아니지만 MachineDeployments가 원하는 상태로 맞춤조정하는 데 사용되는 메커니즘입니다.
===MachineHealthCheck===
MachineHealthCheck는 노드가 비정상(unhealthy)으로 간주되어야 하는 조건을 정의합니다.
노드가 지정된 사용자-설정 시간 동안 이러한 비정상 조건과 일치하면 MachineHealthCheck가 노드 복구를 시작합니다. 노드 복구는 해당 머신을 삭제하여 수행됩니다.
MachineHealthChecks는 MachineSet이 소유한 노드만 복구합니다. 이렇게 하면, MachineSet가 실패한 머신을 교체하기 위해 새 머신을 생성하므로, Kubernetes 클러스터의 용량이 손실되지 않습니다.
===BootstrapData===
BootstrapData에는 인프라 제공자가 머신을 노드로 부트스트랩하는 데 사용하는 머신 또는 노드 역할별 초기화 데이터(일반적으로 cloud-init)가 포함되어 있습니다.


==참고==
==참고==

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 노드로 전환하는 작업 및 다음의 작업을 담당하는 구성요소

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

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-managerKubeadmControlPlane 객체의 요청된 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 참고[ | ]

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}