The Cluster API Book
전제조건
MachinehealthCheck를 구성하기 전에 하나 이상의 MachineDeployment 또는 MachineSet가 배포된 작업 관리 클러스터가 있어야 한다.
MachineHealthCheck란 무엇입니까?
MachineHealthCheck는 Cluster API 내의 사용자가 클러스터 내의 시스템이 비정상적으로 간주되어야 하는 조건을 정의할 수 있는 리소스다. 시스템 상태 점검은 관리 클러스터에 정의되고 특정 워크로드 클러스터로 범위가 지정된다.
MachineHealthCheck를 정의할 때 사용자는 시스템 노드에서 검사하기 위해 정의한 각 조건에 대한 시간 초과를 지정한다. 시간 초과 기간 동안 이러한 조건 중 하나라도 충족되면 시스템에 업데이트를 적용한다. 기본적으로 시스템에 업데이트를 적용하는 작업은 실패한 시스템을 대체하기 위해 새 시스템을 생성하도록 트리거해야 하지만 제공자는 보다 정교한 외부 업데이트 적용 솔루션을 연결할 수 있다.
MachineHealthCheck 생성
다음 예를 워커 노드에 대한 MachineHealthCheck를 생성하는 기준으로 사용한다.
apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineHealthCheck
metadata:
name: capi-quickstart-node-unhealthy-5m
spec:
# clusterName is required to associate this MachineHealthCheck with a particular cluster
clusterName: capi-quickstart
# (Optional) maxUnhealthy prevents further remediation if the cluster is already partially unhealthy
maxUnhealthy: 40%
# (Optional) nodeStartupTimeout determines how long a MachineHealthCheck should wait for
# a Node to join the cluster, before considering a Machine unhealthy
nodeStartupTimeout: 10m
# selector is used to determine which Machines should be health checked
selector:
matchLabels:
nodepool: nodepool-0
# Conditions to check on Nodes for matched Machines, if any condition is matched for the duration of its timeout, the Machine is considered unhealthy
unhealthyConditions:
- type: Ready
status: Unknown
timeout: 300s
- type: Ready
status: "False"
timeout: 300sKubeadmControlPlane을 통해 관리되는 콘트롤 플레인 노드에 대해 MachineHealthCheck를 정의하는 기준으로 이 예제를 사용한다.
apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineHealthCheck
metadata:
name: capi-quickstart-kcp-unhealthy-5m
spec:
clusterName: capi-quickstart
maxUnhealthy: 100%
selector:
matchLabels:
cluster.x-k8s.io/control-plane: ""
unhealthyConditions:
- type: Ready
status: Unknown
timeout: 300s
- type: Ready
status: "False"
timeout: 300s교정 단락(Short-Circuiting)
MachineHealthCheck은 클러스터가 정상일 때만 시스템에 업데이트를 적용하기 위해 단락 회로가 구현되어 MachineHealthCheck 규격의 maxUnhealthy 필드를 통해 추가 업데이트를 수행하지 못하도록 한다.
시스템에 업데이트를 적용하기 전에 사용자가 maxUnhealthy(이 시스템 상태 점검에서 선택한 전체 시스템의 절대 수 또는 백분율) 필드에 대한 값을 정의하는 경우 MachineHealthCheck는 maxUnhealthy 값을 불량으로 결정된 시스템 수와 비교합니다. 상태가 좋지 않은 컴퓨터 수가 maxUnhealthy로 설정된 제한을 초과하면 업데이트 적용이 수행되지 않는다.
절대값 사용
maxUnhealthy가 2로 설정된 경우:
- 2개 이하의 노드가 비정상인 경우 업데이트 적용이 수행된다.
- 비정상 노드가 3개 이상이면 업데이트 적용이 수행되지 않는다.
이 값은 MachineHealthCheck에서 검사 중인 Machine 수와 무관하다.
백분율 포함
maxUnhealthy가 40%로 설정되어 있고 25대의 Machine이 확인되는 경우:
- 비정상 노드가 10개 이하일 경우 업데이트 적용이 수행된다.
- 비정상 노드가 11개 이상인 경우 업데이트 적용이 수행되지 않는다.
maxUnhealthy가 40%로 설정되어 있고 6대의 Machine이 확인되고 있는 경우:
- 비정상 노드가 2개 이하인 경우 업데이트 적용이 수행된다.
- 비정상 노드가 3개 이상이면 업데이트 적용이 수행되지 않는다.
백분율이 정수가 아닐 경우 허용된 숫자는 반올림됩니다.
업데이트 적용 건너뛰기
시스템에 대한 업데이트 적용이 바람직하지 않은 시나리오가 있다(예: clusterctl move을 사용한 클러스터 마이그레이션 중). 이러한 경우 MachineHealthCheck는 업데이트를 적용하기 위해 시스템을 건너뛰는 두 가지 메커니즘을 제공합니다.
리소스가 일시 중지될 때 암시적으로 건너뜁니다(cluster.x-k8s.io/paused 주석 사용):
- 클러스터가 일시 중지되면 해당 클러스터에 있는 시스템이 업데이트 적용 대상으로 고려되지 않는다.
- 시스템이 일시 중지되면 해당 시스템만 업데이트 적용 대상으로 간주되지 않는다.
- 클러스터 또는 시스템은 일반적으로 클러스터 API가 마이그레이션을 감지하면 자동으로 일시 중지된다.
cluster.x-k8s.io/skip-remediation 주석을 사용하여 명시적으로 건너뛴다:
- 사용자는 machine에 cluster.x-k8s.io/skip-remediation를 설정하여 업데이트를 적용하기 위한 machine을 건너뛸 수도 있다.
MachineHealthCheck의 한계 및 주의 사항
MachineHealthCheck를 배포하기 전에 다음 제한 사항과 주의 사항을 숙지한다.
- MachineSet 또는 KubedmControlPlane이 소유한 시스템만 MachineHealthCheck를 통해 업데이트를 적용할 수 있다(MachineDeploy는 MachineSet를 사용하므로 여기에는 MachineDeploy의 일부인 시스템이 포함된다).
- KubeadmControlPlane에 의해 관리되는 시스템은 KubeadmControlPlane 제안서에 설명된 삭제 및 재생성 지침에 따라 교정된다.
- 클러스터에서 시스템 노드가 제거되면 MachineHealthCheck에서 이 Machine의 상태가 불량한 것으로 간주하고 즉시 업데이트를 적용한다.
- NodeStartupTimeout 후 시스템에 대해 클러스터에 가입하지 않는 경우, Machine에 업데이트가 적용된다.
- 어떤 이유로든 Machine에 오류가 발생하면(FailureReason이 설정된 경우), Machine에 즉시 업데이트가 적용됩니다.
