5.3. 머신 상태 확인

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

중요

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

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

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

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

5.3.1. 머신 상태 점검 정보

머신 상태 점검에서는 특정 머신 풀의 비정상적인 머신을 자동으로 복구합니다.

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

참고

마스터 역할이 있는 머신에는 머신 상태 점검을 적용할 수 없습니다.

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

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

참고

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

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

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

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

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

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

5.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는 예제일 뿐입니다. 특정 요구에 따라 머신 그룹을 매핑해야 합니다.

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

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

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

중요

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

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

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

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

maxUnhealthy가 2로 설정된 경우

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

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

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

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

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

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

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

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

5.3.3. MachineHealthCheck 리소스 만들기

클러스터의 모든 MachineSets에 대해 MachineHealthCheck 리소스를 생성할 수 있습니다. 컨트롤 플레인 시스템을 대상으로 하는 MachineHealthCheck 리소스를 생성해서는 안 됩니다.

사전 요구 사항

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

절차

  1. 머신 상태 점검 정의가 포함된 healthcheck.yml 파일을 생성합니다.

  2. healthcheck.yml 파일을 클러스터에 적용합니다. 

    $ oc apply -f healthcheck.yml

5.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/cluster-api-delete-machine="true"

  4. 삭제하려는 노드를 비우고 제외합니다. 

    $ oc adm cordon <node_name>
$ oc adm drain <node_name>

  5. 머신 세트를 스케일링합니다. 

    $ 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

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

검증

  • 원하는 머신 삭제를 확인합니다. 

    $ oc get machines

5.3.5. 머신 세트와 머신 구성 풀 간의 차이점

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

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

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

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