전제조건

MachinehealthCheck를 구성하기 전에 하나 이상의 MachineDeployment 또는 MachineSet가 배포된 작업 관리 클러스터가 있어야 한다.

중요

현재 MachineHealthChecks는 MachineSet에서 소유하는 컴퓨터만 지원한다. MachineHealthCheck 제한에 대한 자세한 내용은 이 페이지 하단의 Machine HealthCheck의 제한사항 및 주의사항을 검토한다.

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: 300s

KubeadmControlPlane을 통해 관리되는 콘트롤 플레인 노드에 대해 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

중요

동일한 클러스터에 대해 둘 이상의 MachineHealthCheck를 정의하는 경우 동일한 시스템 집합에 업데이트를 적용하려고 할 때 충돌이나 예기치 않은 동작을 방지하기 위해 선택기가 겹치지 않는지 확인한다.

교정 단락(Short-Circuiting)

MachineHealthCheck은 클러스터가 정상일 때만 시스템에 업데이트를 적용하기 위해 단락 회로가 구현되어 MachineHealthCheck 규격의 maxUnhealthy 필드를 통해 추가 업데이트를 수행하지 못하도록 한다.

시스템에 업데이트를 적용하기 전에 사용자가 maxUnhealthy(이 시스템 상태 점검에서 선택한 전체 시스템의 절대 수 또는 백분율) 필드에 대한 값을 정의하는 경우 MachineHealthCheck는 maxUnhealthy 값을 불량으로 결정된 시스템 수와 비교합니다. 상태가 좋지 않은 컴퓨터 수가 maxUnhealthy로 설정된 제한을 초과하면 업데이트 적용이 수행되지 않는다.

중요

maxUnhealthy에 대한 기본값은 100%다. 즉, 단락 메커니즘은 기본적으로 비활성화되어 있으며 클러스터 상태에 관계없이 Machine에 업데이트가 적용된다.

절대값 사용

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에 즉시 업데이트가 적용됩니다.
답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like

1.6 Machine Template 변경

인프라 Machine Template 변경 Cluster API의 여러 구성 요소는 KubeadmControlPlane, Machine Deployment 및 MachineSet을 비롯한 인프라 시스템 템플릿을…

1.7.2 ClusterResourceSet

실험 기능: ClusterResourceSet (알파) ClusterResourceSet 기능은 사용자가 정의한 리소스 세트(예: CNI/CSI)를 새로 생성된 클러스터와 일치시키는 데 자동으로 적용할…

Cluster API Book : 개념

개념 관리 클러스터(Management cluster) 워크로드 클러스터의 라이프사이클을 관리하는 쿠버네티스 클러스터다. 관리 클러스터는 하나 이상의 인프라 공급자가 실행되고, 머신과…

Cluster API Book : 소개

Cluster API 프로젝트 Cluster API는 여러 Kubernetes 클러스터의 프로비저닝, 업그레이드 및 운영을 단순화하는 선언적 API 및 툴링을 제공하는…