7.3. 머신 상태 확인

머신 상태 확인을 이해하고 배포합니다.

중요

머신 API가 작동하는 클러스터에서만 고급 머신 관리 및 스케일링 기능을 사용할 수 있습니다. 사용자 프로비저닝 인프라가 있는 클러스터에는 Machine API를 사용하려면 추가 검증 및 구성이 필요합니다.

인프라 플랫폼 유형의 클러스터가 Machine API를 사용할 수 없습니다. 이 제한은 클러스터에 연결된 컴퓨팅 시스템이 기능을 지원하는 플랫폼에 설치된 경우에도 적용됩니다. 이 매개변수는 설치 후 변경할 수 없습니다.

클러스터의 플랫폼 유형을 보려면 다음 명령을 실행합니다.

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'

7.3.1. 머신 상태 점검 정보

참고

컴퓨팅 머신 세트 또는 컨트롤 플레인 머신 세트에서 관리하는 머신에만 머신 상태 점검을 적용할 수 있습니다.

머신 상태를 모니터링하기 위해 컨트롤러 구성을 정의할 리소스를 만듭니다. NotReady 상태를 5 분 동안 유지하거나 노드 문제 탐지기(node-problem-detector)에 영구적인 조건을 표시하는 등 검사할 조건과 모니터링할 머신 세트의 레이블을 설정합니다.

MachineHealthCheck 리소스를 관찰하는 컨트롤러에서 정의된 상태를 확인합니다. 머신이 상태 확인에 실패하면 머신이 자동으로 삭제되고 대체할 머신이 만들어집니다. 머신이 삭제되면 machine deleted 이벤트가 표시됩니다.

머신 삭제로 인한 영향을 제한하기 위해 컨트롤러는 한 번에 하나의 노드 만 드레인하고 삭제합니다. 대상 머신 풀에서 허용된 maxUnhealthy 임계값 보다 많은 비정상적인 머신이 있는 경우 수동 개입이 수행될 수 있도록 복구가 중지됩니다.

참고

워크로드 및 요구 사항을 살펴보고 신중하게 시간 초과를 고려하십시오.

  • 시간 제한이 길어지면 비정상 머신의 워크로드에 대한 다운타임이 길어질 수 있습니다.
  • 시간 초과가 너무 짧으면 수정 루프가 발생할 수 있습니다. 예를 들어 NotReady 상태를 확인하는 시간은 머신이 시작 프로세스를 완료할 수 있을 만큼 충분히 길어야 합니다.

검사를 중지하려면 리소스를 제거합니다.

7.3.1.1. 머신 상태 검사 배포 시 제한 사항

머신 상태 점검을 배포하기 전에 고려해야 할 제한 사항은 다음과 같습니다.

  • 머신 세트가 소유한 머신만 머신 상태 검사를 통해 업데이트를 적용합니다.
  • 머신의 노드가 클러스터에서 제거되면 머신 상태 점검에서 이 머신을 비정상적으로 간주하고 즉시 업데이트를 적용합니다.
  • nodeStartupTimeout 후 시스템의 해당 노드가 클러스터에 참여하지 않으면 업데이트가 적용됩니다.
  • Machine 리소스 단계가 Failed하면 즉시 머신에 업데이트를 적용합니다.

7.3.2. MachineHealthCheck 리소스 샘플

베어 메탈 이외의 모든 클라우드 기반 설치 유형에 대한 MachineHealthCheck 리소스는 다음 YAML 파일과 유사합니다.

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example 1
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> 2
      machine.openshift.io/cluster-api-machine-type: <role> 3
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 4
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s" 5
    status: "False"
  - type:    "Ready"
    timeout: "300s" 6
    status: "Unknown"
  maxUnhealthy: "40%" 7
  nodeStartupTimeout: "10m" 8
1
배포할 머신 상태 점검의 이름을 지정합니다.
2 3
확인할 머신 풀의 레이블을 지정합니다.
4
추적할 머신 세트를 <cluster_name>-<label>-<zone> 형식으로 지정합니다. 예를 들어 prod-node-us-east-1a입니다.
5 6
노드 상태에 대한 시간 제한을 지정합니다. 시간 제한 기간 중 상태가 일치되면 머신이 수정됩니다. 시간 제한이 길어지면 비정상 머신의 워크로드에 대한 다운타임이 길어질 수 있습니다.
7
대상 풀에서 동시에 복구할 수 있는 시스템 수를 지정합니다. 이는 백분율 또는 정수로 설정할 수 있습니다. 비정상 머신의 수가 maxUnhealthy에서의 설정 제한을 초과하면 복구가 수행되지 않습니다.
8
머신 상태가 비정상으로 확인되기 전에 노드가 클러스터에 참여할 때까지 기다려야 하는 시간 초과 기간을 지정합니다.
참고

matchLabels는 예제일 뿐입니다. 특정 요구에 따라 머신 그룹을 매핑해야 합니다.

7.3.2.1. 쇼트 서킷 (Short Circuit) 머신 상태 점검 및 수정

쇼트 서킷(Short-circuiting)은 클러스터가 정상일 때만 머신 상태 점검을 통해 머신을 조정합니다. 쇼트 서킷은 MachineHealthCheck 리소스의 maxUnhealthy 필드를 통해 구성됩니다.

사용자가 시스템을 조정하기 전에 maxUnhealthy 필드 값을 정의하는 경우 MachineHealthCheck는 비정상적으로 결정된 대상 풀 내의 maxUnhealthy 값과 비교합니다. 비정상 머신의 수가 maxUnhealthy 제한을 초과하면 수정을 위한 업데이트가 수행되지 않습니다.

중요

maxUnhealthy가 설정되지 않은 경우 기본값은 100%로 설정되고 클러스터 상태와 관계없이 머신이 수정됩니다.

적절한 maxUnhealthy 값은 배포하는 클러스터의 규모와 MachineHealthCheck에서 다루는 시스템 수에 따라 달라집니다. 예를 들어 maxUnhealthy 값을 사용하여 여러 가용성 영역에서 여러 컴퓨팅 머신 세트를 처리할 수 있으므로 전체 영역을 손실하면 maxUnhealthy 설정이 클러스터 내에서 추가 수정을 방지할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다.

중요

컨트롤 플레인에 대해 MachineHealthCheck 리소스를 구성하는 경우 maxUnhealthy 값을 1 로 설정합니다.

이 구성을 사용하면 여러 컨트롤 플레인 머신이 비정상으로 표시되면 머신 상태 점검이 수행되지 않습니다. 비정상적인 여러 컨트롤 플레인 시스템은 etcd 클러스터의 성능이 저하되었거나 실패한 머신을 교체하는 확장 작업이 진행 중임을 나타낼 수 있습니다.

etcd 클러스터가 성능이 저하되면 수동 개입이 필요할 수 있습니다. 스케일링 작업이 진행 중인 경우 머신 상태 점검을 통해 완료할 수 있어야 합니다.

maxUnhealthy 필드는 정수 또는 백분율로 설정할 수 있습니다. maxUnhealthy 값에 따라 다양한 수정을 적용할 수 있습니다.

7.3.2.1.1. 절대 값을 사용하여 maxUnhealthy 설정

maxUnhealthy2로 설정된 경우

  • 2개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
  • 3개 이상의 노드가 비정상이면 수정을 위한 업데이트가 수행되지 않습니다

이러한 값은 머신 상태 점검에서 확인할 수 있는 머신 수와 관련이 없습니다.

7.3.2.1.2. 백분율을 사용하여 maxUnhealthy 설정

maxUnhealthy40%로 설정되어 있고 25 대의 시스템이 확인되고 있는 경우 다음을 수행하십시오.

  • 10개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
  • 11개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행되지 않습니다.

maxUnhealthy40%로 설정되어 있고 6 대의 시스템이 확인되고 있는 경우 다음을 수행하십시오.

  • 2개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
  • 3개 이상의 노드가 비정상이면 수정을 위한 업데이트가 수행되지 않습니다
참고

maxUnhealthy 머신의 백분율이 정수가 아닌 경우 허용되는 머신 수가 반올림됩니다.

7.3.3. 머신 상태 점검 리소스 생성

클러스터의 머신 세트에 대한 MachineHealthCheck 리소스를 생성할 수 있습니다.

참고

컴퓨팅 머신 세트 또는 컨트롤 플레인 머신 세트에서 관리하는 머신에만 머신 상태 점검을 적용할 수 있습니다.

사전 요구 사항

  • oc 명령행 인터페이스를 설치합니다.

프로세스

  1. 머신 상태 점검 정의가 포함된 healthcheck.yml 파일을 생성합니다.
  2. healthcheck.yml 파일을 클러스터에 적용합니다.

    $ oc apply -f healthcheck.yml

7.3.4. 컴퓨팅 머신 세트 수동 스케일링

컴퓨팅 머신 세트에서 머신 인스턴스를 추가하거나 제거하려면 컴퓨팅 머신 세트를 수동으로 스케일링할 수 있습니다.

이는 완전히 자동화된 설치 프로그램에 의해 프로비저닝된 인프라 설치와 관련이 있습니다. 사용자 지정 사용자 프로비저닝 인프라 설치에는 컴퓨팅 머신 세트가 없습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터 및 oc 명령행을 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

절차

  1. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 머신 세트를 확인합니다.

    $ oc get machinesets -n openshift-machine-api

    컴퓨팅 머신 세트는 < clusterid>-worker-<aws-region-az> 형식으로 나열됩니다.

  2. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 시스템을 확인합니다.

    $ oc get machine -n openshift-machine-api
  3. 다음 명령을 실행하여 삭제할 컴퓨팅 머신에 주석을 설정합니다.

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
  4. 다음 명령 중 하나를 실행하여 컴퓨팅 머신 세트를 확장합니다.

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    또는 다음을 수행합니다.

    $ oc edit machineset <machineset> -n openshift-machine-api
    작은 정보

    다음 YAML을 적용하여 컴퓨팅 머신 세트를 확장할 수 있습니다.

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      name: <machineset>
      namespace: openshift-machine-api
    spec:
      replicas: 2

    컴퓨팅 머신 세트를 확장 또는 축소할 수 있습니다. 새 머신을 사용할 수 있을 때 까지 몇 분 정도 소요됩니다.

    중요

    기본적으로 머신 컨트롤러는 성공할 때까지 머신이 지원하는 노드를 드레이닝하려고 합니다. Pod 중단 예산을 잘못 구성하는 등 일부 상황에서는 드레이닝 작업이 성공하지 못할 수 있습니다. 드레이닝 작업이 실패하면 머신 컨트롤러에서 머신 제거를 진행할 수 없습니다.

    특정 머신에서 machine.openshift.io/exclude-node-draining 에 주석을 달아 노드 드레이닝을 건너뛸 수 있습니다.

검증

  • 다음 명령을 실행하여 의도한 시스템의 삭제를 확인합니다.

    $ oc get machines

7.3.5. 컴퓨팅 머신 세트와 머신 구성 풀의 차이점

MachineSet 개체는 클라우드 또는 머신 공급자와 관련하여 OpenShift Container Platform 노드를 설명합니다.

MachineConfigPool 개체를 사용하면 MachineConfigController 구성 요소가 업그레이드 컨텍스트에서 시스템의 상태를 정의하고 제공할 수 있습니다.

MachineConfigPool 개체를 사용하여 시스템 구성 풀의 OpenShift Container Platform 노드에 대한 업그레이드 방법을 구성할 수 있습니다.

NodeSelector 개체는 MachineSet에 대한 참조로 대체할 수 있습니다.