수정, 펜싱 및 유지 관리

Workload Availability for Red Hat OpenShift 23.1

워크로드 가용성 수정, 펜싱 및 유지 관리

Red Hat Customer Content Services

초록

워크로드 가용성 Operator 및 해당 사용에 대한 정보

머리말

1장. 노드 수정, 펜싱 및 유지보수 정보

하드웨어는 결함이 있고 소프트웨어에 버그가 포함되어 있습니다. 커널이 중단되거나 NIC(네트워크 인터페이스 컨트롤러)와 같은 노드 수준 오류가 발생하면 클러스터에 필요한 작업이 감소하지 않으며 영향을 받는 노드에서 워크로드를 다시 시작해야 합니다. 그러나 RWO(ReadWriteOnce) 볼륨 및 StatefulSets와 같은 일부 워크로드에는 거의 하나의 의미가 필요할 수 있습니다.

이러한 워크로드에 영향을 미치는 실패로 인해 데이터 손실, 손상 또는 둘 다 위험이 있습니다. 또한 워크로드를 복구하고 이상적으로 노드를 복구하기 전에 노드가 펜싱 이라는 안전한 상태에 도달하는 것이 중요합니다.

노드 및 워크로드의 실제 상태를 확인하기 위해 관리자의 개입에 의존하는 것이 항상 실용적이지 않습니다. 이러한 개입을 용이하게 하기 위해 Red Hat OpenShift는 장애 감지, 펜싱 및 수정을 자동화하는 데 필요한 여러 구성 요소를 제공합니다.

1.1. Self Node Remediation

Self Node Remediation Operator는 비정상 노드를 재부팅하고 Pod 및 VolumeAttachments와 같은 리소스를 삭제하는 펜싱 및 수정의 외부 시스템을 구현하는 Red Hat OpenShift 애드온 Operator입니다. 재부팅을 통해 워크로드가 펜싱되고 리소스 삭제가 영향을 받는 워크로드의 일정 조정이 가속화됩니다. 다른 외부 시스템과 달리 셀프 노드 수정에는 IPMI(Intelligent Platform Management Interface) 또는 노드 프로비저닝용 API와 같은 관리 인터페이스가 필요하지 않습니다.

Self Node Remediation은 Machine Health Check 또는 Node Health Check와 같은 장애 탐지 시스템에서 사용할 수 있습니다.

1.2. 머신 상태 점검

머신 상태 점검은 시스템의 상태 및 노드 상태를 모니터링하는 Red Hat OpenShift의 장애 감지, 펜싱 및 수정 시스템을 활용합니다. Self Node Remediation과 같은 외부 펜싱 및 해결 시스템을 트리거하도록 시스템 상태 점검을 구성할 수 있습니다.

1.3. 노드 상태 점검

Node Health Check Operator는 노드 상태를 모니터링하는 장애 감지 시스템을 구현하는 Red Hat OpenShift 애드온 Operator입니다. 펜싱 또는 수정 시스템이 내장되어 있지 않으므로 이러한 기능을 제공하는 외부 시스템을 사용하여 구성해야 합니다. 기본적으로 Self Node Remediation 시스템을 사용하도록 구성되어 있습니다.

1.4. 노드 유지보수

관리자는 드라이브, RAM 또는 NIC를 교체하여 클러스터를 중단해야 하는 상황에 직면합니다.

이러한 유지 관리 전에 영향을 받는 노드를 차단하고 드레인해야 합니다. 노드가 차단되면 해당 노드에서 새 워크로드를 예약할 수 없습니다. 노드가 드레인(drain)되면 다운타임을 방지하거나 최소화하기 위해 영향을 받는 노드의 워크로드가 다른 노드로 전송됩니다.

이러한 유지 관리는 명령줄 툴을 사용하여 수행할 수 있지만 Node Maintenance Operator는 사용자 정의 리소스를 사용하여 이를 수행할 수 있는 선언적 접근 방식을 제공합니다. 노드에 이러한 리소스가 있는 경우 Operator는 노드를 차단하고 리소스가 삭제될 때까지 노드를 드레이닝합니다.

2장. Self Node Remediation 사용

Self Node Remediation Operator를 사용하여 비정상 노드를 자동으로 재부팅할 수 있습니다. 이 수정 전략에서는 상태 저장 애플리케이션과 RWO(ReadWriteOnce) 볼륨의 다운타임을 최소화하고 일시적인 오류가 발생하는 경우 컴퓨팅 용량을 복원합니다.

2.1. Self Node Remediation Operator 정보

Self Node Remediation Operator는 클러스터 노드에서 실행되며 비정상으로 식별되는 노드를 재부팅합니다. Operator는 MachineHealthCheck 또는 NodeHealthCheck 컨트롤러를 사용하여 클러스터의 노드 상태를 탐지합니다. 노드가 비정상으로 확인되면 MachineHealthCheck 또는 NodeHealthCheck 리소스에서 SelfNodeRemediation CR(사용자 정의 리소스)을 생성하여 Self Node Remediation Operator를 트리거합니다.

SelfNodeRemediation CR은 다음 YAML 파일과 유사합니다.

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
status:
  lastError: <last_error_message> 1
1
수정 중에 발생한 마지막 오류를 표시합니다. 수정에 성공하거나 오류가 없는 경우 필드가 비어 있습니다.

Self Node Remediation Operator는 상태 저장 애플리케이션의 다운타임을 최소화하고 일시적인 오류가 발생하는 경우 컴퓨팅 용량을 복원합니다. IPMI 또는 API와 같은 관리 인터페이스에 관계없이 이 Operator를 사용하여 설치 관리자 프로비저닝 인프라 또는 사용자 프로비저닝 인프라와 같은 클러스터 설치 유형에 관계없이 노드를 프로비저닝할 수 있습니다.

2.1.1. 워치독 장치 정보

워치독 장치는 다음 중 하나일 수 있습니다.

  • 독립적으로 구동되는 하드웨어 장치
  • 제어하는 호스트와 전원을 공유하는 하드웨어 장치
  • 소프트웨어 또는 softdog에서 구현된 가상 장치

하드웨어 워치독 및 softdog 장치에는 각각 전자적 또는 소프트웨어 타이머가 있습니다. 이러한 워치독 장치는 오류 조건이 감지될 때 머신이 안전 상태가 되도록 하는 데 사용됩니다. 클러스터는 정상 상태임을 증명하기 위해 워치독 타이머를 반복적으로 재설정해야 합니다. 교착 상태, CPU 부족 및 네트워크 또는 디스크 액세스 손실과 같은 오류 상태로 인해 이 타이머가 만료될 수 있습니다. 타이머가 만료되면 워치독 장치는 결함이 발생했음을 가정하고 장치는 강제 노드 재설정을 트리거합니다.

하드웨어 워치독 장치는 softdog 장치보다 안정적입니다.

2.1.1.1. 워치독 장치를 사용한 Self Node Remediation Operator 동작 이해

Self Node Remediation Operator는 존재하는 워치독 장치를 기반으로 수정 전략을 결정합니다.

하드웨어 워치독 장치가 구성되어 있고 사용 가능한 경우 Operator에서 이를 해결하기 위해 사용합니다. 하드웨어 워치독 장치가 구성되지 않은 경우 Operator는 해결을 위해 softdog 장치를 활성화하고 사용합니다.

시스템 또는 구성에서 워치독 장치를 모두 지원하는 경우 Operator는 소프트웨어 재부팅을 사용하여 노드를 수정합니다.

추가 리소스

워치독 구성

2.2. 컨트롤 플레인 펜싱

이전 릴리스에서는 작업자 노드에서 Self Node Remediation 및 Node Health Check를 활성화할 수 있습니다. 노드 장애가 발생하면 컨트롤 플레인 노드에서 수정 전략을 실행할 수도 있습니다.

Self Node Remediation은 두 가지 주요 시나리오에서 수행됩니다.

  • API Server 연결

    • 이 시나리오에서는 수정할 컨트롤 플레인 노드가 격리되지 않습니다. API 서버에 직접 연결하거나 API 서버에 직접 연결된 작업자 노드 또는 컨트롤 플레인 노드를 통해 API 서버에 간접적으로 연결할 수 있습니다.
    • API Server Connectivity가 있는 경우 Node Health Check Operator에서 노드에 대한 SelfNodeRemediation CR(사용자 정의 리소스)을 생성한 경우에만 컨트롤 플레인 노드가 수정됩니다.
  • API Server 연결 없음

    • 이 시나리오에서는 수정할 컨트롤 플레인 노드가 API 서버와 분리됩니다. 노드는 API 서버에 직접 또는 간접적으로 연결할 수 없습니다.
    • API Server Connectivity가 없는 경우 다음 단계에 설명된 대로 컨트롤 플레인 노드가 수정됩니다.

      • 대부분의 피어 작업자 노드가 있는 컨트롤 플레인 노드의 상태를 확인합니다. 대부분의 피어 작업자 노드에 연결할 수 없는 경우 노드를 추가로 분석합니다.

        • 컨트롤 플레인 노드의 자체 진단

          • 자체 진단이 통과되면 아무 작업도 수행하지 않습니다.
          • 자체 진단에 실패한 경우 노드가 펜싱되고 수정됩니다.
          • 현재 지원되는 자체 진단은 kubelet 서비스 상태를 확인하고 구성을 선택하여 끝점 가용성을 확인하는 것입니다.
      • 노드가 대부분의 작업자 피어와 통신할 수 없는 경우 다른 컨트롤 플레인 노드와 컨트롤 플레인 노드의 연결을 확인합니다. 노드가 다른 컨트롤 플레인 피어와 통신할 수 있는 경우 작업을 수행하지 않습니다. 그렇지 않으면 노드가 펜싱되고 수정됩니다.

2.3. 웹 콘솔을 사용하여 Self Node Remediation Operator 설치

Red Hat OpenShift 웹 콘솔을 사용하여 Self Node Remediation Operator를 설치할 수 있습니다.

참고

Node Health Check Operator는 Self Node Remediation Operator도 기본 수정 공급자로 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Red Hat OpenShift 웹 콘솔에서 OperatorOperatorHub 로 이동합니다.
  2. 사용 가능한 Operator 목록에서 Self Node Remediation Operator를 검색한 다음 설치를 클릭합니다.
  3. 기본 설치 모드네임스페이스 를 계속 선택하여 Operator가 openshift-operators 네임스페이스에 설치되었는지 확인합니다.
  4. 설치를 클릭합니다.

검증

설치에 성공했는지 확인하려면 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. Operator가 openshift-operators 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
  2. 워크로드Pod 페이지로 이동하여 문제를 보고하는 self-node-remediation-controller-manager 프로젝트에서 Pod의 로그를 확인합니다.

2.4. CLI를 사용하여 Self Node Remediation Operator 설치

OpenShift CLI(oc)를 사용하여 Self Node Remediation Operator를 설치할 수 있습니다.

자체 네임스페이스 또는 openshift-operators 네임스페이스에 Self Node Remediation Operator를 설치할 수 있습니다.

자체 네임스페이스에 Operator를 설치하려면 절차의 단계를 따르십시오.

openshift-operators 네임스페이스에 Operator를 설치하려면 새 네임스페이스 CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않으므로 절차의 3단계로 건너 뛰십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Self Node Remediation Operator의 Namespace CR(사용자 정의 리소스)을 생성합니다.

    1. Namespace CR을 정의하고 YAML 파일을 저장합니다(예: self-node-remediation-namespace.yaml ).

      apiVersion: v1
      kind: Namespace
      metadata:
        name: self-node-remediation
    2. 네임스페이스 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f self-node-remediation-namespace.yaml
  2. OperatorGroup CR을 생성합니다.

    1. OperatorGroup CR을 정의하고 YAML 파일을 저장합니다(예: self-node-remediation-operator-group.yaml ).

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: self-node-remediation-operator
        namespace: self-node-remediation
    2. OperatorGroup CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f self-node-remediation-operator-group.yaml
  3. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: self-node-remediation-subscription.yaml ).

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: self-node-remediation-operator
          namespace: self-node-remediation 1
      spec:
          channel: stable
          installPlanApproval: Manual 2
          name: self-node-remediation-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: self-node-remediation
      1
      Self Node Remediation Operator를 설치할 네임스페이스 를 지정합니다. openshift-operators 네임스페이스에 Self Node Remediation Operator를 설치하려면 Subscription CR에 openshift-operators 를 지정합니다.
      2
      지정된 버전이 카탈로그의 이후 버전으로 대체되는 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.
    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f self-node-remediation-subscription.yaml

검증

  1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

    $ oc get csv -n self-node-remediation

    출력 예

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    self-node-remediation.v.0.4.0      Self Node Remediation Operator   v.0.4.0              Succeeded

  2. Self Node Remediation Operator가 실행 중인지 확인합니다.

    $ oc get deploy -n self-node-remediation

    출력 예

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    self-node-remediation-controller-manager    1/1     1            1           28h

  3. Self Node Remediation Operator가 SelfNodeRemediationConfig CR을 생성했는지 확인합니다.

    $ oc get selfnoderemediationconfig -n self-node-remediation

    출력 예

    NAME                           AGE
    self-node-remediation-config   28h

  4. 각 작업자 노드에서 각 자체 노드 수정 Pod가 예약되어 실행 중인지 확인합니다.

    $ oc get daemonset -n self-node-remediation

    출력 예

    NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
    self-node-remediation-ds  3        3        3      3           3          <none>         28h

    참고

    이 명령은 컨트롤 플레인 노드에 지원되지 않습니다.

2.5. Self Node Remediation Operator 구성

Self Node Remediation Operator는 SelfNodeRemediationConfig CR 및 SelfNodeRemediationTemplate CRD(Custom Resource Definition)를 생성합니다.

2.5.1. Self Node Remediation Operator 구성 이해

Self Node Remediation Operator는 self-node-remediation-config 라는 이름으로 SelfNodeRemediationConfig CR을 생성합니다. CR은 Self Node Remediation Operator의 네임스페이스에 생성됩니다.

SelfNodeRemediationConfig CR 변경으로 Self Node Remediation 데몬 세트가 다시 생성됩니다.

SelfNodeRemediationConfig CR은 다음 YAML 파일과 유사합니다.

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180 1
  watchdogFilePath: /dev/watchdog 2
  isSoftwareRebootEnabled: true 3
  apiServerTimeout: 15s 4
  apiCheckInterval: 5s 5
  maxApiErrorThreshold: 3 6
  peerApiServerTimeout: 5s 7
  peerDialTimeout: 5s 8
  peerRequestTimeout: 5s 9
  peerUpdateInterval: 15m 10
1
남은 피어의 시간 초과 기간을 지정합니다. 그러면 Operator에서 비정상 노드가 재부팅되었다고 가정할 수 있습니다. Operator는 이 값에 대한 하한값을 자동으로 계산합니다. 그러나 다른 노드에 다른 워치독 타임아웃이 있는 경우 이 값을 더 높은 값으로 변경해야 합니다.
2
노드에서 워치독 장치의 파일 경로를 지정합니다. 워치독 장치에 잘못된 경로를 입력하면 Self Node Remediation Operator에서 softdog 장치 경로를 자동으로 탐지합니다.

워치독 장치를 사용할 수 없는 경우 SelfNodeRemediationConfig CR은 소프트웨어 재부팅을 사용합니다.

3
비정상 노드의 소프트웨어 재부팅을 활성화하려면 지정합니다. 기본적으로 isSoftwareRebootEnabled 값은 true 로 설정됩니다. 소프트웨어 재부팅을 비활성화하려면 매개 변수 값을 false 로 설정합니다.
4
각 API 서버와의 연결을 확인할 시간 초과 기간을 지정합니다. 이 기간이 지나면 Operator가 수정을 시작합니다. 시간 초과 시간은 10밀리초 이상이어야 합니다.
5
각 API 서버와의 연결을 확인할 빈도를 지정합니다. 시간 초과 시간은 1초보다 크거나 같아야 합니다.
6
임계값을 지정합니다. 이 임계값에 도달하면 노드는 해당 피어에 연결하기 시작합니다. 임계값은 1초보다 크거나 같아야 합니다.
7
API 서버를 연결할 피어의 시간 초과 기간을 지정합니다. 시간 초과 시간은 10밀리초 이상이어야 합니다.
8
피어와 연결을 설정하기 위한 시간 초과 기간을 지정합니다. 시간 초과 시간은 10밀리초 이상이어야 합니다.
9
피어에서 응답을 가져올 시간 초과 기간을 지정합니다. 시간 초과 시간은 10밀리초 이상이어야 합니다.
10
피어 정보를 업데이트할 빈도(예: IP 주소)를 지정합니다. 시간 초과 시간은 10초보다 크거나 같아야 합니다.
참고

Self Node Remediation Operator에서 생성한 self-node-remediation-config CR을 편집할 수 있습니다. 그러나 Self Node Remediation Operator에 대한 새 CR을 생성하려고 하면 로그에 다음 메시지가 표시됩니다.

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

2.5.2. Self Node Remediation Template 구성 이해

Self Node Remediation Operator는 SelfNodeRemediationTemplate CRD(Custom Resource Definition)도 생성합니다. 이 CRD는 노드의 수정 전략을 정의합니다. 다음과 같은 수정 전략을 사용할 수 있습니다.

ResourceDeletion
이 수정 전략에서는 노드 오브젝트가 아닌 노드에서 Pod 및 관련 볼륨 연결을 제거합니다. 이 전략은 워크로드를 더 빨리 복구하는 데 도움이 됩니다. ResourceDeletion 은 기본 수정 전략입니다.
NodeDeletion
이 수정 전략은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 현재 릴리스에서는 NodeDeletion 전략이 선택된 경우에도 ResourceDeletion 전략이 사용됩니다.

Self Node Remediation Operator는 ResourceDeletion 수정 전략이 사용하는 self-node-remediation-resource-deletion-template 에 대한 self NodeRemediationTemplate CR을 생성합니다.

SelfNodeRemediationTemplate CR은 다음 YAML 파일과 유사합니다.

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template 1
  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>  2
1
수정 전략에 따라 수정 템플릿 유형을 지정합니다. & lt;remediation_object >를 리소스 또는 노드로 교체합니다. 예를 들어 self-node-remediation-resource-deletion-template.
2
수정 전략을 지정합니다. 수정 전략은 ResourceDeletion 입니다.

2.6. Self Node Remediation Operator 문제 해결

2.6.1. 일반 문제 해결

문제
Self Node Remediation Operator 관련 문제를 해결하려고 합니다.
해결
Operator 로그를 확인합니다.

2.6.2. 데몬 세트 확인

문제
Self Node Remediation Operator가 설치되어 있지만 데몬 세트를 사용할 수 없습니다.
해결
Operator 로그에 오류 또는 경고가 있는지 확인합니다.

2.6.3. 실패한 수정

문제
비정상적인 노드가 해결되지 않았습니다.
해결

다음 명령을 실행하여 SelfNodeRemediation CR이 생성되었는지 확인합니다.

$ oc get snr -A

노드가 비정상으로 설정될 때 MachineHealthCheck 컨트롤러에서 SelfNodeRemediation CR을 생성하지 않은 경우 MachineHealthCheck 컨트롤러의 로그를 확인합니다. 또한 MachineHealthCheck CR에 수정 템플릿을 사용하는 데 필요한 사양이 포함되어 있는지 확인합니다.

SelfNodeRemediation CR이 생성된 경우 이름이 비정상 노드 또는 머신 오브젝트와 일치하는지 확인합니다.

2.6.4. Operator를 제거한 후에도 데몬 세트 및 기타 Self Node Remediation Operator 리소스가 있습니다.

문제
데몬 세트, 구성 CR 및 해결 템플릿 CR과 같은 Self Node Remediation Operator 리소스는 Operator를 제거한 후에도 존재합니다.
해결

Self Node Remediation Operator 리소스를 제거하려면 각 리소스 유형에 대해 다음 명령을 실행하여 리소스를 삭제합니다.

$ oc delete ds <self-node-remediation-ds> -n <namespace>
$ oc delete snrc <self-node-remediation-config> -n <namespace>
$ oc delete snrt <self-node-remediation-template> -n <namespace>

2.7. Self Node Remediation Operator에 대한 데이터 수집

Self Node Remediation Operator에 대한 디버깅 정보를 수집하려면 must-gather 툴을 사용합니다. Self Node Remediation Operator의 must-gather 이미지에 대한 자세한 내용은 특정 기능에 대한 데이터 수집 을 참조하십시오.

2.8. 추가 리소스

3장. 머신 상태 점검을 사용하여 노드 수정

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

3.1. 머신 상태 점검 정보

참고

컨트롤 플레인 머신 세트를 사용하는 클러스터의 컨트롤 플레인 머신에 머신 상태 점검을 적용할 수 있습니다.

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

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

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

참고

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

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

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

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

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

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

3.2. Self Node Remediation Operator를 사용하도록 머신 상태 점검 구성

다음 절차에 따라 Self Node Remediation Operator를 수정 공급자로 사용하도록 작업자 또는 control-plane 머신 상태 점검을 구성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. SelfNodeRemediationTemplate CR을 생성합니다.

    1. SelfNodeRemediationTemplate CR을 정의합니다.

      apiVersion: self-node-remediation.medik8s.io/v1alpha1
      kind: SelfNodeRemediationTemplate
      metadata:
        namespace: openshift-machine-api
        name: selfnoderemediationtemplate-sample
      spec:
        template:
          spec:
            remediationStrategy: ResourceDeletion 1
      1
      수정 전략을 지정합니다. 기본 전략은 ResourceDeletion 입니다.
    2. SelfNodeRemediationTemplate CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f <snrt-name>.yaml
  2. SelfNodeRemediationTemplate CR을 가리키도록 MachineHealthCheck CR을 생성하거나 업데이트합니다.

    1. MachineHealthCheck CR을 정의하거나 업데이트합니다.

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineHealthCheck
      metadata:
        name: machine-health-check
        namespace: openshift-machine-api
      spec:
        selector:
          matchLabels: 1
            machine.openshift.io/cluster-api-machine-role: "worker"
            machine.openshift.io/cluster-api-machine-type: "worker"
        unhealthyConditions:
        - type:    "Ready"
          timeout: "300s"
          status: "False"
        - type:    "Ready"
          timeout: "300s"
          status: "Unknown"
        maxUnhealthy: "40%"
        nodeStartupTimeout: "10m"
        remediationTemplate: 2
          kind: SelfNodeRemediationTemplate
          apiVersion: self-node-remediation.medik8s.io/v1alpha1
          name: selfnoderemediationtemplate-sample
      1
      머신 상태 점검에서 작업자 또는 컨트롤 플레인 노드를 위한지 여부를 선택합니다. 레이블은 사용자 정의일 수도 있습니다.
      2
      수정 템플릿에 대한 세부 정보를 지정합니다.
    2. MachineHealthCheck CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f <mhc-name>.yaml
    3. MachineHealthCheck CR을 업데이트하려면 다음 명령을 실행합니다.

      $ oc apply -f <mhc-name>.yaml

4장. 노드 상태 점검을 사용하여 노드 수정

Node Health Check Operator를 사용하여 비정상적인 노드를 식별할 수 있습니다. Operator는 Self Node Remediation Operator를 사용하여 비정상 노드를 수정합니다.

4.1. Node Health Check Operator 정보

Node Health Check Operator는 클러스터의 노드 상태를 감지합니다. NodeHealthCheck 컨트롤러는 노드 상태를 확인하기 위해 기준 및 임계값 세트를 정의하는 NodeHealthCheck CR(사용자 정의 리소스)을 생성합니다.

Node Health Check Operator는 Self Node Remediation Operator도 기본 수정 공급자로 설치합니다.

Node Health Check Operator에서 비정상 노드를 감지하면 수정 공급자를 트리거하는 수정 CR을 생성합니다. 예를 들어 컨트롤러는 SelfNodeRemediation CR을 생성하여 Self Node Remediation Operator를 트리거하여 비정상 노드를 수정합니다.

NodeHealthCheck CR은 다음 YAML 파일과 유사합니다.

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51% 1
  pauseRequests: 2
    - <pause-test-cluster>
  remediationTemplate: 3
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: openshift-operators
    kind: SelfNodeRemediationTemplate
  selector: 4
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 5
    - type: Ready
      status: "False"
      duration: 300s 6
    - type: Ready
      status: Unknown
      duration: 300s 7
1
수정 공급자가 대상 풀의 노드를 동시에 수정하는 데 필요한 정상 노드의 양(% 또는 수)을 지정합니다. 정상 노드 수가 minHealthy 로 설정된 제한과 같거나 초과하는 경우 수정이 수행됩니다. 기본값은 10.0.0.1입니다.
2
지속적인 수정을 계속 수행하는 동안 새 수정이 시작되지 않도록 합니다. 기본값은 비어 있습니다. 그러나 수정을 일시 중지하는 원인을 식별하는 문자열 배열을 입력할 수 있습니다. 예를 들면 pause-test-cluster 가 있습니다.
참고

업그레이드 프로세스 중에 클러스터의 노드를 일시적으로 사용할 수 없게 되고 비정상으로 식별될 수 있습니다. 작업자 노드의 경우 Operator에서 클러스터 업그레이드 여부를 감지하면 이러한 노드가 재부팅되지 않도록 새 비정상적인 노드 수정을 중지합니다.

3
수정 공급자의 수정 템플릿을 지정합니다. 예를 들어 Self Node Remediation Operator에서 다음을 수행합니다.
4
확인할 레이블 또는 표현식과 일치하는 선택기 를 지정합니다. 기본값은 비어 있으며 모든 노드를 선택합니다.
5
노드가 비정상으로 간주되는지 여부를 결정하는 조건 목록을 지정합니다.
6 7
노드 조건의 시간 초과 기간을 지정합니다. 시간 제한 기간 중 상태가 일치되면 노드가 수정됩니다. 시간 제한이 길어지면 비정상 노드의 워크로드에 대한 다운타임이 길어질 수 있습니다.

4.1.1. Node Health Check Operator 워크플로 이해

노드가 비정상으로 확인되면 Node Health Check Operator는 비정상인 다른 노드 수를 확인합니다. 정상 노드의 수가 NodeHealthCheck CR의 minHealthy 필드에 지정된 양을 초과하면 컨트롤러는 수정 공급자가 외부 수정 템플릿에 제공하는 세부 정보에서 수정 CR을 생성합니다. 수정 후 kubelet은 노드의 상태를 업데이트합니다.

노드가 정상 상태가 되면 컨트롤러에서 외부 수정 템플릿을 삭제합니다.

4.1.2. 노드 상태 점검에서 머신 상태 점검과 충돌을 방지하는 방법 정보

노드 상태 점검 및 머신 상태 점검이 모두 배포되면 노드 상태 점검에서 머신 상태 점검과 충돌하지 않도록 합니다.

참고

Red Hat OpenShift는 machine-api-termination-handler 를 기본 MachineHealthCheck 리소스로 배포합니다.

다음 목록에는 노드 상태 점검 및 머신 상태 점검이 배포될 때 시스템 동작이 요약되어 있습니다.

  • 기본 머신 상태 점검만 있는 경우 노드 상태 점검은 비정상 노드를 계속 식별합니다. 그러나 노드 상태 점검은 Terminating 상태의 비정상적인 노드를 무시합니다. 기본 머신 상태 점검은 Terminating 상태로 비정상 노드를 처리합니다.

    로그 메시지 예

    INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}

  • 기본 머신 상태 점검이 수정되거나(예: unhealthyConditionsReady임) 또는 추가 머신 상태 점검이 생성되는 경우 노드 상태 점검이 비활성화됩니다.

    로그 메시지 예

    INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

  • 다시 기본 머신 상태 점검만 있으면 노드 상태 점검이 다시 활성화됩니다.

    로그 메시지 예

    INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

4.2. 컨트롤 플레인 펜싱

이전 릴리스에서는 작업자 노드에서 Self Node Remediation 및 Node Health Check를 활성화할 수 있습니다. 노드 장애가 발생하면 컨트롤 플레인 노드에서 수정 전략을 실행할 수도 있습니다.

작업자 노드 및 컨트롤 플레인 노드에 동일한 NodeHealthCheck CR을 사용하지 마십시오. 작업자 노드와 컨트롤 플레인 노드를 함께 그룹화하면 정상 상태의 최소 노드 수가 잘못 평가되고 예기치 않거나 누락된 수정이 발생할 수 있습니다. 이는 Node Health Check Operator가 컨트롤 플레인 노드를 처리하는 방식 때문입니다. 컨트롤 플레인 노드를 자체 그룹 및 해당 그룹의 작업자 노드를 그룹화해야 합니다. 필요한 경우 작업자 노드 그룹을 여러 개 생성할 수도 있습니다.

수정 전략에 대한 고려 사항:

  • 예기치 않은 동작이 발생할 수 있으므로 동일한 노드가 겹치는 여러 구성이 포함된 노드 상태 점검 구성을 방지하십시오. 이 제안은 작업자 및 컨트롤 플레인 노드 모두에 적용됩니다.
  • Node Health Check Operator는 한 번에 최대 하나의 컨트롤 플레인 노드를 수정하는 하드 코딩된 제한을 구현합니다. 동시에 여러 컨트롤 플레인 노드를 수정할 수 없습니다.

4.3. 웹 콘솔을 사용하여 Node Health Check Operator 설치

Red Hat OpenShift 웹 콘솔을 사용하여 Node Health Check Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Red Hat OpenShift 웹 콘솔에서 OperatorOperatorHub 로 이동합니다.
  2. Node Health Check Operator를 검색한 다음 설치를 클릭합니다.
  3. 기본 설치 모드네임스페이스 를 계속 선택하여 Operator가 openshift-operators 네임스페이스에 설치되도록 합니다.
  4. Console 플러그인이 Enable 으로 설정되어 있는지 확인합니다.
  5. 설치를 클릭합니다.

검증

설치에 성공했는지 확인하려면 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. Operator가 openshift-operators 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
  2. 워크로드Pod 페이지로 이동하여 openshift-operators 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.

4.4. CLI를 사용하여 Node Health Check Operator 설치

OpenShift CLI(oc)를 사용하여 Node Health Check Operator를 설치할 수 있습니다.

자체 네임스페이스에 Operator를 설치하려면 절차의 단계를 따르십시오.

openshift-operators 네임스페이스에 Operator를 설치하려면 새 네임스페이스 CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않으므로 절차의 3단계로 건너 뛰십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Node Health Check Operator의 Namespace CR(사용자 정의 리소스)을 생성합니다.

    1. Namespace CR을 정의하고 YAML 파일을 저장합니다(예: node-health-check-namespace.yaml ).

      apiVersion: v1
      kind: Namespace
      metadata:
        name: node-health-check
    2. 네임스페이스 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-health-check-namespace.yaml
  2. OperatorGroup CR을 생성합니다.

    1. OperatorGroup CR을 정의하고 YAML 파일을 저장합니다(예: node-health-check-operator-group.yaml ).

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-health-check-operator
        namespace: node-health-check
    2. OperatorGroup CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-health-check-operator-group.yaml
  3. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: node-health-check-subscription.yaml ).

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: node-health-check-operator
          namespace: node-health-check 1
      spec:
          channel: stable 2
          installPlanApproval: Manual 3
          name: node-healthcheck-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: node-healthcheck-operator
      1
      Node Health Check Operator를 설치할 네임스페이스 를 지정합니다. openshift-operators 네임스페이스에 Node Health Check Operator를 설치하려면 Subscription CR에 openshift-operators 를 지정합니다.
      2
      서브스크립션 채널 이름을 지정합니다. Node Health Check Operator의 최신 버전으로 업그레이드하려면 서브스크립션의 채널 이름을 후보 에서 stable 로 수동으로 변경해야 합니다.
      3
      지정된 버전이 카탈로그의 이후 버전으로 대체되는 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.
    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-health-check-subscription.yaml

검증

  1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

    $ oc get csv -n openshift-operators

    출력 예

    NAME                              DISPLAY                     VERSION  REPLACES PHASE
    node-healthcheck-operator.v0.2.0. Node Health Check Operator  0.2.0             Succeeded

  2. Node Health Check Operator가 실행 중인지 확인합니다.

    $ oc get deploy -n openshift-operators

    출력 예

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-health-check-operator-controller-manager  1/1     1            1           10d

4.5. 노드 상태 점검 생성

웹 콘솔을 사용하여 노드 상태 점검을 생성하여 비정상 노드를 식별하고 수정 유형 및 전략을 지정할 수 있습니다.

절차

  1. Red Hat OpenShift 웹 콘솔의 관리자 화면에서 컴퓨팅NodeHealthChecksCreateNodeHealthCheck 를 클릭합니다.
  2. 양식 보기 또는 YAML 보기 를 사용하여 노드 상태 점검을 구성할지 여부를 지정합니다.
  3. 노드 상태 점검의 이름을 입력합니다. 이름은 소문자, 영숫자, '-' 또는 '.'로 구성되어야 하며 영숫자 문자로 시작하고 끝나야 합니다.
  4. Remediator 유형 및 셀프 노드 수정을 지정하거나 기타를 지정합니다. Self Node Remediation Operator는 Node Health Check Operator와 함께 설치된 Self Node Remediation Operator의 일부입니다. 기타를 선택하려면 API 버전,Kind,Name, Namespace 를 입력해야 합니다. 그러면 Remediator의 수정 템플릿 리소스를 가리킵니다.
  5. 수정하려는 노드 의 레이블을 지정하여 노드를 선택합니다. 선택 항목이 확인하려는 레이블과 일치합니다. 두 개 이상의 레이블이 지정된 경우 노드에 각 라벨이 포함되어야 합니다. 기본값은 비어 있으며 작업자 및 컨트롤 플레인 노드를 모두 선택합니다.

    참고

    Self Node Remediation Operator를 사용하여 노드 상태 점검을 생성할 때 node-role.kubernetes.io/worker 또는 node-role.kubernetes.io/control-plane 을 값으로 선택해야 합니다.

  6. NodeHealthCheck 가 대상 풀의 노드를 수정하는 데 필요한 백분율 또는 숫자를 사용하여 최소 정상 노드 수를 지정합니다. 정상 상태의 노드 수가 Min healthy 로 설정된 제한과 같거나 초과하는 경우 수정이 수행됩니다. 기본값은 10.0.0.1입니다.
  7. 노드가 충족되어 노드가 비정상으로 간주되는지 여부를 결정하는 경우 수정이 필요한 Unhealthy 조건 목록을 지정합니다. Type,Status, Duration 을 지정할 수 있습니다. 사용자 정의 유형을 생성할 수도 있습니다.
  8. 생성을 클릭하여 노드 상태 점검을 생성합니다.

검증

  • 컴퓨팅NodeHealthCheck 페이지로 이동하여 해당 노드 상태 점검이 나열되고 해당 상태가 표시되는지 확인합니다. 노드 상태 점검을 생성하고 나면 노드 상태 점검을 일시 정지, 수정 및 삭제할 수 있습니다.

4.6. Node Health Check Operator에 대한 데이터 수집

Node Health Check Operator에 대한 디버깅 정보를 수집하려면 must-gather 툴을 사용합니다. Node Health Check Operator의 must-gather 이미지에 대한 자세한 내용은 특정 기능에 대한 데이터 수집 을 참조하십시오.

4.7. 추가 리소스

5장. Node Maintenance Operator를 사용하여 노드를 유지보수 모드로 배치

Node Maintenance Operator를 사용하여 oc adm 유틸리티 또는 NodeMaintenance CR(사용자 정의 리소스)을 사용하여 노드를 유지보수 모드에 배치할 수 있습니다.

5.1. Node Maintenance Operator 정보

Node Maintenance Operator는 신규 또는 삭제된 NodeMaintenance CR을 감시합니다. 새 NodeMaintenance CR이 감지되면 새 워크로드가 예약되지 않고 나머지 클러스터에서 노드가 차단됩니다. 제거할 수 있는 모든 Pod는 노드에서 제거됩니다. NodeMaintenance CR이 삭제되면 CR에서 참조되는 노드를 새 워크로드에 사용할 수 있습니다.

참고

노드 유지관리 작업에 NodeMaintenance CR을 사용하면 표준 Red Hat OpenShift CR 처리를 사용하여 oc adm cordonoc adm drain 명령과 동일한 결과를 얻을 수 있습니다.

5.2. Node Maintenance Operator 설치

웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 Node Maintenance Operator를 설치할 수 있습니다.

참고

OpenShift Virtualization 버전 4.10 이상이 클러스터에 설치된 경우 Node Maintenance Operator 버전의 오래된 버전이 포함되어 있습니다.

5.2.1. 웹 콘솔을 사용하여 Node Maintenance Operator 설치

Red Hat OpenShift 웹 콘솔을 사용하여 Node Maintenance Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Red Hat OpenShift 웹 콘솔에서 OperatorOperatorHub 로 이동합니다.
  2. Node Maintenance Operator를 검색한 다음 설치를 클릭합니다.
  3. 기본 설치 모드네임스페이스 를 계속 선택하여 Operator가 openshift-operators 네임스페이스에 설치되도록 합니다.
  4. 설치를 클릭합니다.

검증

설치에 성공했는지 확인하려면 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. Operator가 openshift-operators 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
  2. Operator → 설치된 Operator Node Maintenance Operator세부 정보 페이지로 이동하여 Pod 생성 전에 오류가 있는지 확인합니다.
  3. 워크로드Pod 페이지로 이동하여 설치된 네임스페이스에서 Node Maintenance Operator Pod를 검색하고 Logs 탭에서 로그를 확인합니다.

5.2.2. CLI를 사용하여 Node Maintenance Operator 설치

OpenShift CLI(oc)를 사용하여 Node Maintenance Operator를 설치할 수 있습니다.

Node Maintenance Operator를 자체 네임스페이스 또는 openshift-operators 네임스페이스에 설치할 수 있습니다.

자체 네임스페이스에 Operator를 설치하려면 절차의 단계를 따르십시오.

openshift-operators 네임스페이스에 Operator를 설치하려면 새 네임스페이스 CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않으므로 절차의 3단계로 건너 뛰십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. Node Maintenance Operator의 Namespace CR을 생성합니다.

    1. Namespace CR을 정의하고 YAML 파일을 저장합니다(예: node-maintenance-namespace.yaml ).

      apiVersion: v1
      kind: Namespace
      metadata:
        name: nmo-test
    2. 네임스페이스 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-maintenance-namespace.yaml
  2. OperatorGroup CR을 생성합니다.

    1. OperatorGroup CR을 정의하고 YAML 파일을 저장합니다(예: node-maintenance-operator-group.yaml ).

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test
    2. OperatorGroup CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-maintenance-operator-group.yaml
  3. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: node-maintenance-subscription.yaml ).

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test 1
      spec:
        channel: stable
        InstallPlaneApproval: Automatic
        name: node-maintenance-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        StartingCSV: node-maintenance-operator.v4.12.0
      1
      Node Maintenance Operator를 설치할 네임스페이스 를 지정합니다.
      중요

      openshift-operators 네임스페이스에 Node Maintenance Operator를 설치하려면 Subscription CR에 openshift-operators 를 지정합니다.

    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f node-maintenance-subscription.yaml

검증

  1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

    $ oc get csv -n openshift-operators

    출력 예

    NAME                               DISPLAY                     VERSION   REPLACES  PHASE
    node-maintenance-operator.v4.12    Node Maintenance Operator   4.12                Succeeded

  2. Node Maintenance Operator가 실행 중인지 확인합니다.

    $ oc get deploy -n openshift-operators

    출력 예

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-maintenance-operator-controller-manager   1/1     1            1           10d

Node Maintenance Operator는 제한된 네트워크 환경에서 지원됩니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

5.3. 노드를 유지보수 모드로 설정

NodeMaintenance CR을 사용하여 웹 콘솔 또는 CLI에서 노드를 유지보수 모드에 배치할 수 있습니다.

5.3.1. 웹 콘솔을 사용하여 노드를 유지보수 모드로 설정

노드를 유지보수 모드로 설정하려면 웹 콘솔을 사용하여 NodeMaintenance CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • OperatorHub 에서 Node Maintenance Operator를 설치합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 Node Maintenance Operator를 선택합니다.
  3. Node Maintenance 탭에서 NodeMaintenance 생성을 클릭합니다.
  4. NodeMaintenance 생성 페이지에서 양식 보기 또는 YAML 보기 를 선택하여 NodeMaintenance CR을 구성합니다.
  5. 구성한 NodeMaintenance CR을 적용하려면 생성을 클릭합니다.

검증

Node Maintenance 탭에서 Status 열을 검사하고 해당 상태가 Succeeded 인지 확인합니다.

5.3.2. CLI를 사용하여 노드를 유지보수 모드로 설정

NodeMaintenance CR(사용자 정의 리소스)을 사용하여 노드를 유지관리 모드에 배치할 수 있습니다. NodeMaintenance CR을 적용하면 허용되는 모든 Pod가 제거되고 노드가 예약되지 않습니다. 제거된 Pod는 클러스터의 다른 노드로 이동하기 위해 대기열에 있습니다.

사전 요구 사항

  • Red Hat OpenShift CLI oc 를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

절차

  1. 다음 NodeMaintenance CR을 생성하고 파일을 nodemaintenance-cr.yaml 로 저장합니다.

    apiVersion: nodemaintenance.medik8s.io/v1beta1
    kind: NodeMaintenance
    metadata:
      name: nodemaintenance-cr  1
    spec:
      nodeName: node-1.example.com 2
      reason: "NIC replacement" 3
    1
    노드 유지보수 CR의 이름입니다.
    2
    유지보수 모드에 배치할 노드의 이름입니다.
    3
    유지 관리 이유에 대한 일반 텍스트 설명입니다.
  2. 다음 명령을 실행하여 노드 유지보수 CR을 적용합니다.

    $ oc apply -f nodemaintenance-cr.yaml

검증

  1. 다음 명령을 실행하여 유지 관리 작업의 진행 상황을 확인합니다.

    $ oc describe node <node-name>

    여기서 <node-name >은 노드의 이름입니다(예: node-1.example.com).

  2. 예제 출력을 확인합니다.

    Events:
      Type     Reason                     Age                   From     Message
      ----     ------                     ----                  ----     -------
      Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

5.3.3. 현재 NodeMaintenance CR 작업의 상태 확인

현재 NodeMaintenance CR 작업의 상태를 확인할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift CLI oc 를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  • 다음 명령을 실행하여 현재 노드 유지관리 작업의 상태를 확인합니다(예: NodeMaintenance CR 또는 nm 오브젝트).

    $ oc get nm -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: nodemaintenance.medik8s.io/v1beta1
      kind: NodeMaintenance
      metadata:
    ...
      spec:
        nodeName: node-1.example.com
        reason: Node maintenance
      status:
        drainProgress: 100   1
        evictionPods: 3   2
        lastError: "Last failure message" 3
        lastUpdate: "2022-06-23T11:43:18Z" 4
        phase: Succeeded
        totalpods: 5 5
    ...

    1
    노드 드레이닝의 백분율입니다.
    2
    제거 예약된 Pod 수입니다.
    3
    최신 제거 오류(있는 경우)입니다.
    4
    상태가 마지막으로 업데이트된 시간입니다.
    5
    노드가 유지보수 모드에 진입하기 전의 총 Pod 수입니다.

5.4. 유지관리 모드에서 노드 재시작

NodeMaintenance CR을 사용하여 웹 콘솔 또는 CLI에서 유지보수 모드에서 노드를 재시작할 수 있습니다. 노드를 재시작하면 노드가 유지관리 모드에서 해제되어 노드를 다시 스케줄링할 수 있습니다.

5.4.1. 웹 콘솔을 사용하여 유지보수 모드에서 노드 재시작

유지보수 모드에서 노드를 재시작하려면 웹 콘솔을 사용하여 NodeMaintenance CR(사용자 정의 리소스)을 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • OperatorHub 에서 Node Maintenance Operator를 설치합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 Node Maintenance Operator를 선택합니다.
  3. Node Maintenance 탭에서 삭제할 NodeMaintenance CR을 선택합니다.
  4. 노드 끝에 있는 옵션 메뉴 kebab 를 클릭하고 노드 유지 관리 삭제를 선택합니다.

검증

  1. Red Hat OpenShift 콘솔에서 컴퓨팅 → 노드를 클릭합니다.
  2. NodeMaintenance CR을 삭제한 노드의 Status 열을 검사하고 해당 상태가 Ready 인지 확인합니다.

5.4.2. CLI를 사용하여 유지보수 모드에서 노드 재시작

NodeMaintenance CR을 삭제하여 NodeMaintenance CR로 시작된 유지보수 모드에서 노드를 재시작할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift CLI oc 를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

절차

  • 노드 유지관리 작업이 완료되면 활성 NodeMaintenance CR을 삭제합니다.

    $ oc delete -f nodemaintenance-cr.yaml

    출력 예

    nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted

검증

  1. 다음 명령을 실행하여 유지 관리 작업의 진행 상황을 확인합니다.

    $ oc describe node <node-name>

    여기서 <node-name >은 노드의 이름입니다(예: node-1.example.com).

  2. 예제 출력을 확인합니다.

    Events:
      Type     Reason                  Age                   From     Message
      ----     ------                  ----                  ----     -------
      Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

5.5. 베어 메탈 노드 작업

베어 메탈 노드가 있는 클러스터의 경우 웹 콘솔 작업 제어를 사용하여 노드를 유지보수 모드로 배치하고 유지보수 모드에서 노드를 다시 시작할 수 있습니다.

참고

베어 메탈 노드가 있는 클러스터에서도 노드를 유지보수 모드에 배치할 수 있으며 설명된 대로 웹 콘솔 및 CLI를 사용하여 유지보수 모드에서 노드를 재시작할 수 있습니다. 웹 콘솔 Actions 컨트롤을 사용하여 이러한 방법은 베어 메탈 클러스터에만 적용할 수 있습니다.

5.5.1. 베어 메탈 노드 유지관리

베어메탈 인프라에 Red Hat OpenShift를 배포하는 경우 클라우드 인프라에 배포하는 것과 비교하여 추가 고려 사항을 고려해야 합니다. 클러스터 노드가 임시로 간주되는 클라우드 환경에서와 달리 베어 메탈 노드를 재프로비저닝하려면 유지 관리 작업에 더 많은 시간과 노력이 필요합니다.

커널 오류 또는 NIC 카드 하드웨어 오류로 인해 베어 메탈 노드가 실패하면 문제가 발생한 노드를 복구하거나 교체하는 동안 장애가 발생한 노드의 워크로드를 클러스터의 다른 노드에서 다시 시작해야 합니다. 클러스터 관리자는 노드 유지보수 모드를 통해 노드를 정상적으로 끄고, 워크로드를 클러스터의 다른 부분으로 이동하고, 워크로드가 중단되지 않도록 할 수 있습니다. 유지보수 관리 중에 자세한 진행 상황 및 노드 상태 세부 정보가 제공됩니다.

5.5.2. 베어 메탈 노드를 유지보수 모드로 설정

컴퓨팅 → 노드 목록의 각 노드에 있는 옵션 메뉴 kebab 를 사용하거나 노드 세부 정보 화면의 작업 컨트롤을 사용하여 베어 메탈 노드를 유지보수 모드로 설정합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드를 클릭합니다.
  2. 이 화면에서 노드를 유지보수 모드로 설정하면 여러 노드에 대한 작업을 더 쉽게 수행할 수 있습니다. 노드 세부 정보 화면에서 노드를 유지보수 모드로 설정하면 선택한 노드에 대한 포괄적인 세부 정보를 볼 수 있습니다.

    • 노드 끝에 있는 옵션 메뉴 kebab 를 클릭하고 유지보수 시작을 선택합니다.
    • 노드 이름을 클릭하여 노드 세부 정보 화면을 열고 작업유지보수 시작을 클릭합니다.
  3. 확인 창에서 유지보수 시작을 클릭합니다.

노드를 더 이상 예약할 수 없습니다. LiveMigration 제거 전략이 있는 가상 머신이 있는 경우 이를 실시간 마이그레이션합니다. 노드의 기타 모든 Pod 및 가상 머신이 삭제되고 다른 노드에서 다시 생성됩니다.

검증

  • 컴퓨팅노드 페이지로 이동하여 해당 노드의 상태가 유지 관리 중인지 확인합니다.

5.5.3. 유지보수 모드에서 베어 메탈 노드 재시작

컴퓨팅 → 노드 목록의 각 노드에 있는 옵션 메뉴 kebab 를 사용하거나 노드 세부 정보 화면의 작업 컨트롤을 사용하여 유지보수 모드에서 베어 메탈 노드를 재시작합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드를 클릭합니다.
  2. 이 화면에서 노드를 재시작하면 여러 노드에 대한 작업을 더 쉽게 수행할 수 있습니다. 노드 세부 정보 화면에서 노드를 재시작하면 선택한 노드에 대한 포괄적인 세부 정보를 볼 수 있습니다.

    • 노드 끝에 있는 옵션 메뉴 kebab 를 클릭하고 유지보수 중지를 선택합니다.
    • 노드 이름을 클릭하여 노드 세부 정보 화면을 열고 작업유지보수 중지를 클릭합니다.
  3. 확인 창에서 유지보수 중지를 클릭합니다.

노드를 예약할 수 있게 됩니다. 유지보수 전에 노드에서 실행 중인 가상 머신 인스턴스가 있는 경우 이 노드로 자동으로 마이그레이션되지 않습니다.

검증

  • 컴퓨팅노드 페이지로 이동하여 해당 노드의 상태가 Ready 인지 확인합니다.

5.6. Node Maintenance Operator에 대한 데이터 수집

Node Maintenance Operator에 대한 디버깅 정보를 수집하려면 must-gather 툴을 사용하십시오. Node Maintenance Operator의 must-gather 이미지에 대한 자세한 내용은 특정 기능에 대한 데이터 수집 을 참조하십시오.

5.7. 추가 리소스

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.