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 Circuit)은 클러스터가 정상일 경우에만 머신 상태 점검을 통해 머신을 조정합니다. 쇼트 서킷은 MachineHealthCheck
리소스의 maxUnhealthy
필드를 통해 구성됩니다.
사용자가 시스템을 조정하기 전에 maxUnhealthy
필드 값을 정의하는 경우 MachineHealthCheck
는 비정상적으로 결정된 대상 풀 내의 maxUnhealthy
값과 비교합니다. 비정상 머신의 수가 maxUnhealthy
제한을 초과하면 수정을 위한 업데이트가 수행되지 않습니다.
maxUnhealthy
가 설정되지 않은 경우 기본값은 100%
로 설정되고 클러스터 상태와 관계없이 머신이 수정됩니다.
적절한 maxUnhealthy
값은 배포하는 클러스터의 규모와 MachineHealthCheck에서
다루는 시스템 수에 따라 달라집니다. 예를 들어 maxUnhealthy
값을 사용하여 여러 가용 영역에서 여러 머신 세트를 처리할 수 있으므로 전체 영역을 손실하면 maxUnhealthy
설정이 클러스터 내에서 추가 수정을 방지 할 수 있습니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다.
maxUnhealthy
필드는 정수 또는 백분율로 설정할 수 있습니다. maxUnhealthy
값에 따라 다양한 수정을 적용할 수 있습니다.
7.3.2.1.1. 절대 값을 사용하여 maxUnhealthy 설정
maxUnhealthy
가 2
로 설정된 경우
- 2개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
- 3개 이상의 노드가 비정상이면 수정을 위한 업데이트가 수행되지 않습니다
이러한 값은 머신 상태 점검에서 확인할 수 있는 머신 수와 관련이 없습니다.
7.3.2.1.2. 백분율을 사용하여 maxUnhealthy 설정
maxUnhealthy
가 40%
로 설정되어 있고 25 대의 시스템이 확인되고 있는 경우 다음을 수행하십시오.
- 10개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
- 11개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행되지 않습니다.
maxUnhealthy
가 40%
로 설정되어 있고 6 대의 시스템이 확인되고 있는 경우 다음을 수행하십시오.
- 2개 이상의 노드가 비정상인 경우 수정을 위한 업데이트가 수행됩니다.
- 3개 이상의 노드가 비정상이면 수정을 위한 업데이트가 수행되지 않습니다
maxUnhealthy
머신의 백분율이 정수가 아닌 경우 허용되는 머신 수가 반올림됩니다.
7.3.3. MachineHealthCheck 리소스 만들기
클러스터의 모든 MachineSets
에 대해 MachineHealthCheck
리소스를 생성할 수 있습니다. 컨트롤 플레인 시스템을 대상으로 하는 MachineHealthCheck
리소스를 생성해서는 안 됩니다.
사전 요구 사항
-
oc
명령행 인터페이스를 설치합니다.
절차
-
머신 상태 점검 정의가 포함된
healthcheck.yml
파일을 생성합니다. healthcheck.yml
파일을 클러스터에 적용합니다.$ oc apply -f healthcheck.yml
7.3.4. 머신 세트 수동 스케일링
머신 세트에서 머신 인스턴스를 추가하거나 제거하려면 머신 세트를 수동으로 스케일링할 수 있습니다.
이는 완전히 자동화된 설치 프로그램에 의해 프로비저닝된 인프라 설치와 관련이 있습니다. 사용자 지정된 사용자 프로비저닝 인프라 설치에는 머신 세트가 없습니다.
사전 요구 사항
-
OpenShift Container Platform 클러스터 및
oc
명령행을 설치합니다. -
cluster-admin
권한이 있는 사용자로oc
에 로그인합니다.
절차
클러스터에 있는 머신 세트를 확인합니다.
$ oc get machinesets -n openshift-machine-api
머신 세트는
<clusterid>-worker-<aws-region-az>
형식으로 나열됩니다.클러스터에 있는 머신을 확인합니다.
$ oc get machine -n openshift-machine-api
삭제할 머신에서 주석을 설정합니다.
$ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"
다음 명령 중 하나를 실행하여 머신 세트를 확장합니다.
$ 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
에 대한 참조로 대체할 수 있습니다.