수정, 펜싱 및 유지 관리

Workload Availability for Red Hat OpenShift 23.3

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

Red Hat Customer Content Services

초록

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

머리말

Red Hat OpenShift 문서의 Workload Availability에 대한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오. 이렇게 하려면 다음을 수행합니다.

  1. JIRA 웹 사이트로 이동합니다.
  2. 요약 필드에 설명 제목을 입력합니다.
  3. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  4. Reporter 필드에 사용자 이름을 입력합니다.
  5. 영향을 받는 버전을 Affects Version/s 필드에 입력합니다.
  6. 대화 상자 하단에서 생성 을 클릭합니다.

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

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

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

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

1.1. Self Node Remediation

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

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

1.2. Fence Agents Remediation

FAR(Fence Agent Remediation) Operator는 Self Node Remediation Operator와 유사하게 비정상 노드를 자동으로 수정하는 Red Hat OpenShift 애드온 Operator입니다. FAR은 관리 인터페이스 또는 기존 API를 사용하여 노드의 전원을 순환하여 비정상 상태에서 노드를 수정하기 위해 FAR를 실행합니다.

FAR은 클러스터 노드의 전원 순환을 위해 기존 API 엔드포인트(예: IPMI)가 있는 환경에 대해 기존 업스트림 펜싱 에이전트 세트를 실행하도록 설계되었습니다.

1.3. 시스템 삭제 수정

MDR(Machine Deletion Remediation) Operator는 Machine API를 사용하여 비정상 노드를 다시 프로비저닝하는 Red Hat OpenShift 애드온 Operator입니다. MDR은 NHC(NodeHealthCheck)와 함께 비정상 노드에 대한 정보를 사용하여 MDR에 대한 사용자 정의 리소스(CR)를 생성합니다.

MDR은 노드의 주석을 연결된 머신 오브젝트로 따르고 소유 컨트롤러가 있는지 확인합니다. MDR은 시스템을 삭제한 다음 소유 컨트롤러에서 교체 시스템을 다시 생성합니다.

1.4. 머신 상태 점검

Machine Health Check는 Red Hat OpenShift 기본 제공 장애 감지, 펜싱 및 수정 시스템을 사용하여 시스템 상태 및 노드 상태를 모니터링합니다. Self Node Remediation과 같은 외부 펜싱 및 수정 시스템을 트리거하도록 시스템 상태 점검을 구성할 수 있습니다.

1.5. 노드 상태 점검

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

1.6. 노드 유지보수

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

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

이러한 유지 관리는 명령줄 툴을 사용하여 수행할 수 있지만 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:
  remediationStrategy: <remediation_strategy> 1
status:
  lastError: <last_error_message> 2
1
노드의 수정 전략을 지정합니다.
2
수정 중에 마지막으로 발생한 오류를 표시합니다. 수정이 성공하거나 오류가 발생하지 않으면 필드가 비어 있습니다.

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

2.1.1. 워치독 장치 정보

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

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

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

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

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

Self Node Remediation Operator는 워치독 장치에 따라 수정 전략을 결정합니다.

하드웨어 워치독 장치가 구성되어 사용 가능한 경우 Operator는 이를 수정에 사용합니다. 하드웨어 워치독 장치가 구성되지 않은 경우 Operator는 수정을 위해 소프트독 장치를 활성화하고 사용합니다.

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

2.2. 컨트롤 플레인 펜싱

이전 릴리스에서는 작업자 노드에서 Self Node Remediation 및 Node Health Check를 활성화할 수 있습니다. 노드 오류가 발생하는 경우 이제 컨트롤 플레인 노드에서 수정 전략을 따를 수 있습니다.

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

  • API 서버 연결

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

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

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

        • 컨트롤 플레인 노드의 상태 진단

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

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 페이지로 이동하여 openshift-operators 프로젝트에서 self-node-remediation-controller-manager Pod 및 self-node-remediation-ds 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를 설치하려면 새 Namespace CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않기 때문에 절차의 3 단계로 건너뜁니다.

사전 요구 사항

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

프로세스

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

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: self-node-remediation
    2. Namespace 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. 서브스크립션 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.7.0      Self Node Remediation Operator   v.0.7.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  6        6        6      6           6          <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
  customDsTolerations: 11
      - effect: NoSchedule
        key: node-role.kubernetes.io.infra
        operator: Equal
        value: "value1"
        tolerationSeconds: 3600
1
비정상 노드에서 실행되는 영향을 받는 워크로드를 복구하기 전에 Operator가 대기하는 기간을 지정합니다. 실패한 노드에서 계속 실행되는 동안 대체 Pod를 시작하면 데이터가 손상되고 run-once 의미 체계가 위반될 수 있습니다. 이러한 문제가 발생하지 않도록 Operator는 ApiServerTimeout,ApiCheckInterval,maxApiErrorThreshold,peerDial Timeout 필드에서 계산된 최소값보다 낮은 값을 무시합니다.
2
노드에서 워치독 장치의 파일 경로를 지정합니다. 워치독 장치에 대한 잘못된 경로를 입력하면 Self Node Remediation Operator에서 softdog 장치 경로를 자동으로 감지합니다.

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

3
비정상 노드의 소프트웨어 재부팅을 활성화하려면 다음을 지정합니다. 기본적으로 값은 SoftwareRebootEnabled 입니다. 소프트웨어 재부팅을 비활성화하려면 매개 변수 값을 false 로 설정합니다.
4
각 API 서버와의 연결을 확인하려면 타임아웃 기간을 지정합니다. 이 기간이 지나면 Operator가 수정을 시작합니다. 시간 초과 기간은 10밀리초보다 크거나 같아야 합니다.
5
각 API 서버와의 연결을 확인할 빈도를 지정합니다. 시간제한 기간은 1초보다 크거나 같아야 합니다.
6
임계값을 지정합니다. 이 임계값에 도달하면 노드가 해당 피어에 연결하기 시작합니다. 임계값은 1초보다 크거나 같아야 합니다.
7
API 서버를 연결할 피어의 시간 제한을 지정합니다. 시간 초과 기간은 10밀리초보다 크거나 같아야 합니다.
8
피어와의 연결을 설정하기 위한 시간 초과 기간을 지정합니다. 시간 초과 기간은 10밀리초보다 크거나 같아야 합니다.
9
피어에서 응답을 가져올 시간 초과 기간을 지정합니다. 시간 초과 기간은 10밀리초보다 크거나 같아야 합니다.
10
IP 주소와 같은 피어 정보를 업데이트할 빈도를 지정합니다. 시간 초과 기간은 10초보다 크거나 같아야 합니다.
다양한 유형의 노드에 대한 수정을 지원하려면 DaemonSet에서 실행 중인 사용자 정의 허용 오차 Self Node Remediation 에이전트를 지정합니다. 다음 필드를 구성할 수 있습니다.
  • effect: effect는 일치시킬 테인트 효과를 나타냅니다. 이 필드가 비어 있으면 모든 테인트 효과가 일치합니다. 지정된 경우 허용되는 값은 NoSchedule,PreferNoScheduleNoExecute 입니다.
  • key: 키는 허용 오차가 적용되는 taint 키입니다. 이 필드가 비어 있으면 모든 taint 키가 일치합니다. 키가 비어 있으면 operator 필드가 Exists 여야 합니다. 이 조합은 모든 값과 모든 키와 일치하는 것을 의미합니다.
  • operator: Operator는 키와 값의 관계를 나타냅니다. 유효한 연산자는 ExistsEqual 입니다. 기본값은 Equal 입니다. exists 는 특정 카테고리의 모든 테인트를 허용할 수 있도록 값의 와일드카드와 동일합니다.
  • value: 허용 오차가 일치하는 테인트 값입니다. 연산자가 Exists 인 경우 값은 비어 있어야 합니다. 그렇지 않으면 일반 문자열일 뿐입니다.
  • tolerationSeconds: 허용 오차(영향이 NoExecute여야 하며, 그렇지 않으면 이 필드가 무시됨) 테인트를 허용하는 기간입니다. 기본적으로 설정되어 있지 않습니다. 즉, 테인트를 영구적으로 허용한다는 의미입니다(즉, 제거하지 마십시오). 0 및 음수 값은 시스템에서 0(즉 즉시 제거됨)으로 처리됩니다.
  • 사용자 정의 허용 오차를 사용하면 Self Node Remediation 에이전트 Pod에 허용 오차를 추가할 수 있습니다. 자세한 내용은 허용 오차를 사용하여 OpenShift Logging Pod 배치 제어를 참조하십시오.
참고

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 템플릿 구성 이해

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

ResourceDeletion
이 수정 전략에서는 노드 오브젝트가 제거되지 않고 노드에서 Pod 및 관련 볼륨 연결을 제거합니다. 이 전략은 워크로드를 더 빠르게 복구합니다. ResourceDeletion 은 기본 수정 전략입니다.
OutOfServiceTaint
이 수정 전략으로 인해 노드 오브젝트가 제거되지 않고 노드에서 Pod 및 관련 볼륨 연결이 제거됩니다. 노드에 OutOfServiceTaint 전략을 배치하여 이를 달성합니다. 이 전략은 워크로드를 더 빠르게 복구합니다. 이 전략은 OpenShift Container Platform 버전 4.13 이후의 기술 프리뷰 및 OpenShift Container Platform 버전 4.15 이후의 일반 가용성에서 지원됩니다.

Self Node Remediation Operator는 ResourceDeletion 수정 전략에서 사용하는 self-node-remediation-resource-deletion-template 에 대한 SelfNodeRemediationTemplate 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.5.3. Self Node Remediation Operator 문제 해결

2.5.3.1. 일반 문제 해결

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

2.5.3.2. 데몬 세트 확인

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

2.5.3.3. 수정 실패

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

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

$ oc get snr -A

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

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

2.5.3.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.5.4. Self Node Remediation Operator에 대한 데이터 수집

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

2.5.5. 추가 리소스

3장. 펜싱 에이전트 수정 사용

Fence Agents Remediation Operator를 사용하여 Self Node Remediation Operator와 유사하게 비정상 노드를 자동으로 수정할 수 있습니다. 이 Operator는 관리 인터페이스 또는 기존 API를 사용하여 노드의 전원을 순환하여 비정상 상태에서 노드를 수정하기 위해 fence-agent를 실행합니다.

3.1. Fence 에이전트 Remediation Operator 정보

FAR( Fence Agent Remediation) Operator는 외부 툴을 사용하여 비정상 노드를 펜싱합니다. 이러한 툴은 각 차단 에이전트를 사용하여 노드를 펜싱하고 노드를 재부팅하는 기존 API(애플리케이션 프로그래밍 인터페이스) 호출을 사용하여 각 차단 에이전트를 사용할 수 있습니다. 이렇게 하면 FAR에서 상태 저장 애플리케이션의 다운타임을 최소화하고 일시적인 오류가 발생할 경우 컴퓨팅 용량을 복원하며 워크로드의 가용성을 높일 수 있습니다.

FAR은 비정상 상태가 될 때 노드를 펜싱할 뿐만 아니라 노드가 비정상 상태가 아닌 상태를 수정 하려고 합니다. 상태 비저장 Pod를 제거하고, 차단 에이전트를 사용하여 노드를 펜싱하기 위해 테인트를 추가하고, 재부팅 후 나머지 워크로드(대부분의 상태 저장 워크로드)를 제거하기 위해 리소스 삭제로 수정을 완료합니다. 테인트를 추가하고 워크로드를 삭제하면 워크로드 예약이 빨라집니다.

Operator는 FenceAgentsRemediation 이라는 신규 또는 삭제된 CR(사용자 정의 리소스)을 감시하여 CR의 이름을 기반으로 노드를 수정하도록 차단 에이전트를 트리거합니다. FAR은 NodeHealthCheck 컨트롤러를 사용하여 클러스터에서 노드의 상태를 감지합니다. 노드가 비정상으로 식별되면 NodeHealthCheck 리소스는 FenceAgentsRemediation Template CR을 기반으로 FenceAgentsRemediation CR을 생성하여 Fence Agents Remediation Operator를 트리거합니다.

FAR은 차단 에이전트를 사용하여 Kubernetes 노드를 펜싱합니다. 일반적으로 펜싱은 응답하지 않는 컴퓨터를 안전한 상태로 사용하고 컴퓨터를 격리하는 프로세스입니다. Fence 에이전트는 관리 인터페이스를 사용하여 펜싱을 수행하는 소프트웨어 코드이며 대부분 전원 기반 펜싱을 수행하여 컴퓨터를 전원 사이클링, 재설정 또는 끌 수 있습니다. 펜스 에이전트의 예는 IPMI(Intelligent Platform Management Interface) 환경에 사용되는 fence_ipmilan 입니다.

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediation
metadata:
  name: node-name 1
  namespace: openshift-operators
spec:
1
node-name은 비정상 클러스터 노드의 이름과 일치해야 합니다.

Operator에는 IPMI 또는 API와 같은 관리 인터페이스를 사용하여 베어 메탈 서버, 가상 머신 및 클라우드 플랫폼에 대한 노드를 프로비저닝/다시 부팅하는 Red Hat High Availability Add-On에서도 사용할 수 있는 차단 에이전트 세트가 포함되어 있습니다.

3.2. 웹 콘솔을 사용하여 Fence Agents Remediation Operator 설치

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

사전 요구 사항

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

프로세스

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

검증

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

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

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

  1. Operator → 설치된 Operator 페이지로 이동하여 상태 열에 오류 또는 실패가 있는지 검사합니다.
  2. 워크로드Pod 페이지로 이동하여 보고된 문제에 대해 fence-agents-remediation-controller-manager Pod의 로그를 확인합니다.

3.3. CLI를 사용하여 Fence Agents Remediation Operator 설치

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

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

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

openshift-operators 네임스페이스에 Operator를 설치하려면 새 Namespace CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않기 때문에 절차의 3 단계로 건너뜁니다.

사전 요구 사항

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

프로세스

  1. Fence Agents Remediation Operator에 대한 Namespace CR(사용자 정의 리소스)을 생성합니다.

    1. 네임스페이스 CR을 정의하고 YAML 파일(예: fence-agents-remediation-namespace.yaml )을 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: fence-agents-remediation-namespace
    2. Namespace CR을 생성하려면 다음 명령을 실행합니다.

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

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

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

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

    1. 서브스크립션 CR을 정의하고 YAML 파일(예: fence-agents-remediation-subscription.yaml )을 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: fence-agents-remediation-subscription
          namespace: fence-agents-remediation-namespace 1
      spec:
          channel: stable
          name: fence-agents-remediation
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: fence-agents-remediation
      1
      Fence Agents Remediation Operator를 설치할 네임스페이스 를 지정합니다(예: 이 절차의 앞부분에 설명된 fence-agents-remediation-namespace ). 일치하는 OperatorGroup CR이 이미 있는 openshift-operators 네임스페이스에 Fence Agent Remediation Operator에 대한 서브스크립션 CR을 설치할 수 있습니다.
    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f fence-agents-remediation-subscription.yaml

검증

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

    $ oc get csv -n fence-agents-remediation-namespace

    출력 예

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    fence-agents-remediation.v.0.2.0      Fence Agents Remediation Operator   v.0.2.0              Succeeded

  2. Fence Agents Remediation Operator가 실행 중인지 확인합니다.

    $ oc get deploy -n fence-agents-remediation-namespace

    출력 예

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    fence-agents-remediation-controller-manager    1/1     1            1           28h

3.4. Fence 에이전트 Remediation Operator 구성

Fence Agents Remediation Operator를 사용하여 Node Health Check Operator(NHC)에서 사용하는 FenceAgentsRemediationTemplate 사용자 정의 리소스(CR)를 생성할 수 있습니다. 이 CR은 노드를 수정하는 데 필요한 모든 매개변수가 있는 클러스터에서 사용할 차단 에이전트를 정의합니다. FenceAgentsRemediationTemplate CR이 여러 개 있을 수 있으며, 각 차단 에이전트에 대해 대부분의 CR이 있을 수 있으며 NHC가 사용 중인 경우 노드의 전원을 순환하는 데 사용할 수정Template으로 FenceAgentsRemediationTemplate을 선택할 수 있습니다.

참고

현재 릴리스에서는 FenceAgentsRemediationTemplate CR이 많이 있을 수 있지만 각 차단 에이전트마다 대부분의 CR이 있을 수 있습니다. 이는 향후 릴리스에서 해결될 알려진 제한 사항입니다.

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

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediationTemplate
metadata:
  name: fence-agents-remediation-template-fence-ipmilan
  namespace: openshift-operators
spec:
  template:
    spec:
      agent: fence_ipmilan 1
        nodeparameters: 2
          --ipport:
            master-0-0: '6230'
            master-0-1: '6231'
            master-0-2: '6232'
            worker-0-0: '6233'
            worker-0-1: '6234'
            worker-0-2: '6235'
        sharedparameters: 3
          '--action': reboot
          '--ip': 192.168.123.1
          '--lanplus': ''
          '--password': password
          '--username': admin
1
실행할 펜스 에이전트의 이름을 표시합니다(예: fence_ipmilan ).
2
차단 에이전트를 실행하기 위한 특정 클러스터 노드 정보를 표시합니다(예: ipport ).
3
차단 에이전트를 실행하기 위한 공통 클러스터 노드 정보를 표시합니다(예: 사용자 이름 ).

3.5. Fence Agents Remediation Operator 문제 해결

3.5.1. 일반 문제 해결

문제
Fence Agents Remediation Operator 관련 문제를 해결하려고 합니다.
해결

Operator 로그를 확인합니다.

$ oc logs <fence-agents-remediation-controller-manager-name> -c manager -n <namespace-name>

3.5.2. 수정 실패

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

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

$ oc get far -A

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

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

3.5.3. Operator 설치 제거 후 Fence Agents Remediation Operator 리소스가 있습니다.

문제
수정 CR 및 수정 템플릿 CR과 같은 Fence Agent Remediation Operator 리소스는 Operator를 설치 제거한 후 존재합니다.
해결

Fence Agent Remediation Operator 리소스를 제거하려면 제거하기 전에 "이 운영자의 모든 피연산자 인스턴스 삭제" 확인란을 선택하여 리소스를 삭제할 수 있습니다. 이 확인란 기능은 버전 4.13 이후 Red Hat OpenShift에서만 사용할 수 있습니다. Red Hat OpenShift의 모든 버전에 대해 각 리소스 유형에 대해 다음 관련 명령을 실행하여 리소스를 삭제할 수 있습니다.

$ oc delete far <fence-agents-remediation> -n <namespace>
$ oc delete fartemplate <fence-agents-remediation-template> -n <namespace>

수정 CR은 동일한 엔티티(예: NHC)에서 생성하고 삭제해야 합니다. 수정 CR이 지금까지 존재하는 경우 FAR Operator와 함께 삭제됩니다.

수정 템플릿 CR fartemplate 은 NHC에서 FAR을 사용하는 경우에만 존재합니다. 웹 콘솔을 사용하여 FAR Operator를 삭제하면 수정 템플릿 CR fartemplate 도 삭제됩니다.

3.6. Fence Agent Remediation Operator에 대한 데이터 수집

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

3.7. 추가 리소스

4장. Machine Deletion Remediation 사용

Machine Deletion Remediation Operator를 사용하여 Machine API를 사용하여 비정상 노드를 다시 프로비저닝할 수 있습니다. Node Health Check Operator와 함께 Machine Deletion Remediation Operator를 사용할 수 있습니다.

4.1. Machine Deletion Remediation Operator 정보

MDR(Machine Deletion Remediation) Operator는 NodeHealthCheck 컨트롤러와 함께 작동하여 Machine API를 사용하여 비정상 노드를 다시 프로비저닝합니다. MDR은 노드에서 관련 머신 오브젝트로 주석을 따르고 소유 컨트롤러(예: MachineSetController)가 있는지 확인한 후 삭제합니다. 머신 CR이 삭제되면 소유 컨트롤러가 교체를 생성합니다.

MDR의 전제 조건은 다음과 같습니다.

  • 클러스터 노드를 프로그래밍 방식으로 제거하고 생성할 수 있는 머신 API 기반 클러스터
  • 머신과 관련된 노드, 및
  • 선언적으로 관리되는 시스템.

그런 다음 NodeHealthCheck CR을 수정하여 MDR을 수정자로 사용할 수 있습니다. 설명서에 MDR 템플릿 오브젝트 및 NodeHealthCheck 구성의 예가 제공됩니다.

MDR 프로세스는 다음과 같이 작동합니다.

  • Node Health Check Operator는 비정상 노드를 감지하고 MDR CR을 생성합니다.
  • MDR Operator는 비정상 노드와 연결된 MDR CR을 감시하고 머신에 소유 컨트롤러가 있는 경우 삭제합니다.
  • 노드가 다시 정상이면 NodeHealthCheck 컨트롤러에서 MDR CR이 삭제됩니다.

4.2. 웹 콘솔을 사용하여 Machine Deletion Remediation Operator 설치

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

사전 요구 사항

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

프로세스

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

검증

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

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

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

  1. Operator → 설치된 Operator 페이지로 이동하여 상태 열에 오류 또는 실패가 있는지 검사합니다.
  2. 워크로드Pod 페이지로 이동하여 보고된 모든 문제에 대해 machine-deletion-remediation-controller Pod의 로그를 확인합니다.

4.3. CLI를 사용하여 Machine Deletion Remediation Operator 설치

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

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

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

openshift-operators 네임스페이스에 Operator를 설치하려면 새 Namespace CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않기 때문에 절차의 3 단계로 건너뜁니다.

사전 요구 사항

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

프로세스

  1. Machine Deletion Remediation Operator에 대한 Namespace CR(사용자 정의 리소스)을 생성합니다.

    1. 네임스페이스 CR을 정의하고 YAML 파일(예: machine-deletion-remediation-namespace.yaml )을 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: machine-deletion-remediation
    2. Namespace CR을 생성하려면 다음 명령을 실행합니다.

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

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

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

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

    1. 서브스크립션 CR을 정의하고 YAML 파일(예: machine-deletion-remediation-subscription.yaml )을 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: machine-deletion-remediation-operator
          namespace: machine-deletion-remediation 1
      spec:
          channel: stable
          name: machine-deletion-remediation-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: machine-deletion-remediation
      1
      Machine Deletion Remediation Operator를 설치할 네임스페이스를 지정합니다. openshift-operators Subscription CR에 Machine Deletion Remediation Operator를 설치할 때 NamespaceOperatorGroup CR이 이미 존재합니다.
    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f machine-deletion-remediation-subscription.yaml

검증

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

    $ oc get csv -n machine-deletion-remediation

    출력 예

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    machine-deletion-remediation.v.0.2.0      Machine Deletion Remediation Operator   v.0.2.0              Succeeded

4.4. Machine Deletion Remediation Operator 구성

Node Health Check Operator와 함께 Machine Deletion Remediation Operator를 사용하여 MachineDeletionRemediationTemplate CR(사용자 정의 리소스)을 생성할 수 있습니다. 이 CR은 노드의 수정 전략을 정의합니다.

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

apiVersion: machine-deletion-remediation.medik8s.io/v1alpha1
kind: MachineDeletionRemediationTemplate
metadata:
  name: machinedeletionremediationtemplate-sample
  namespace: openshift-operators
spec:
  template:
    spec: {}

4.5. Machine Deletion Remediation Operator 문제 해결

4.5.1. 일반 문제 해결

문제
Machine Deletion Remediation Operator의 문제를 해결하려고 합니다.
해결

Operator 로그를 확인합니다.

$ oc logs <machine-deletion-remediation-controller-manager-name> -c manager -n <namespace-name>

4.5.2. 수정 실패

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

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

$ oc get mdr -A

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

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

4.5.3. Operator를 제거한 후에도 Machine Deletion Remediation Operator 리소스가 있습니다.

문제
수정 CR 및 수정 템플릿 CR과 같은 Machine Deletion Remediation Operator 리소스는 Operator를 제거한 후에도 존재합니다.
해결

Machine Deletion Remediation Operator 리소스를 제거하려면 제거하기 전에 이 Operator의 모든 피연산자 인스턴스 삭제 확인란을 선택하여 리소스를 삭제할 수 있습니다. 이 확인란 기능은 버전 4.13 이후 Red Hat OpenShift에서만 사용할 수 있습니다. Red Hat OpenShift의 모든 버전에 대해 각 리소스 유형에 대해 다음 관련 명령을 실행하여 리소스를 삭제할 수 있습니다.

$ oc delete mdr <machine-deletion-remediation> -n <namespace>
$ oc delete mdrt <machine-deletion-remediation-template> -n <namespace>

수정 CR mdr 은 동일한 엔티티(예: NHC)에서 생성하고 삭제해야 합니다. 수정 CR mdr 이 여전히 있으면 MDR Operator와 함께 삭제됩니다.

해결 템플릿 CR mdrt 는 NHC에서 MDR을 사용하는 경우에만 존재합니다. 웹 콘솔을 사용하여 MDR Operator를 삭제하면 수정 템플릿 CR mdrt 도 삭제됩니다.

4.6. Machine Deletion Remediation Operator에 대한 데이터 수집

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

4.7. 추가 리소스

5장. 머신 상태 점검으로 노드 수정

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

5.1. 머신 상태 점검 정보

참고

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

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

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

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

참고

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

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

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

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

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

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

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

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

참고

Self Node Remediation Operator를 머신 상태 점검의 수정 공급자로 사용하려면 머신에 클러스터에 연결된 노드가 있어야 합니다.

사전 요구 사항

  • 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

6장. 노드 상태 점검으로 노드 수정

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

Self Node Remediation Operator에 대한 자세한 내용은 Self Node Remediation 사용 장을 참조하십시오.

참고

ROSA(Red Hat OpenShift Service on AWS) 클러스터에 사전 설치된 머신 상태 점검이 존재하기 때문에 Node Health Check Operator가 이러한 환경에서 작동할 수 없습니다.

6.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은 수정 공급자인 self-node-remediation을 사용하여 다음 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
  escalatingRemediations: 4
    - remediationTemplate:
        apiVersion: self-node-remediation.medik8s.io/v1alpha1
        name: self-node-remediation-resource-deletion-template
        namespace: openshift-operators
        kind: SelfNodeRemediationTemplate
    order: 1
    timeout: 300s
  selector: 5
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 6
    - type: Ready
      status: "False"
      duration: 300s 7
    - type: Ready
      status: Unknown
      duration: 300s 8
1
수정 공급자가 대상 풀의 노드를 동시에 수정하는 데 필요한 정상 노드(% 또는 숫자)를 지정합니다. 정상 노드의 수가 minHealthy 에 의해 설정된 제한과 같거나 초과하는 경우 수정이 수행됩니다. 기본값은 Cryostat입니다.
2
새 수정을 시작하는 것을 방지하고 지속적인 수정을 유지할 수 있습니다. 기본값은 비어 있습니다. 그러나 수정을 일시 중지하는 원인을 식별하는 문자열 배열을 입력할 수 있습니다. 예를 들면 pause-test-cluster 입니다.
참고

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

3
수정 공급자의 수정 템플릿을 지정합니다. 예를 들어 Self Node Remediation Operator에서 다음을 수행합니다. remediationTemplate 은 Escalating Remediations와 함께 사용할 수 없습니다.
4
순서 및 시간 초과 필드가 포함된 RemediationTemplates 목록을 지정합니다. 정상적인 노드를 얻으려면 이 필드를 사용하여 여러 수정을 정렬하고 구성합니다. 이 전략은 성공하지 못할 수 있는 단일 수정에 따라 대신 정상 노드를 얻을 가능성이 높아집니다. order 필드에는 수정 사항이 호출되는 순서가 결정됩니다(더 낮은 순서 = 이전 호출). timeout 필드는 다음 수정이 호출될 시기를 결정합니다. EscalatingRemediationsremediationTemplate 과 함께 사용할 수 없습니다.
5
확인할 레이블 또는 표현식과 일치하는 선택기를 지정합니다. 하나의 CR에서 control-plane 및 worker 노드를 모두 선택하지 마십시오.
6
노드가 비정상으로 간주되는지 여부를 결정하는 조건 목록을 지정합니다.
7 8
노드 상태에 대한 시간 초과 기간을 지정합니다. 시간 초과 기간 동안 조건이 충족되면 노드가 수정됩니다. 시간 초과가 길어지면 비정상 노드의 워크로드에 대한 다운타임이 길어질 수 있습니다.

NodeHealthCheck CR은 metal3을 수정 공급자로 사용하여 다음 YAML 파일과 유사합니다.

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nhc-worker-metal3
spec:
  minHealthy: 30%
  remediationTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3RemediationTemplate
    name: metal3-remediation
    namespace: openshift-machine-api
  selector:
    matchExpressions:
    - key: node-role.kubernetes.io/worker
      operator: Exists
  unhealthyConditions:
  - duration: 300s
    status: 'False'
    type: Ready
  - duration: 300s
    status: 'Unknown'
    type: Ready
참고

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

Metal3RemediationTemplate 은 metal3을 수정 공급자로 사용하여 다음 YAML 파일과 유사합니다.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3RemediationTemplate
metadata:
  name: metal3-remediation
  namespace: openshift-machine-api
spec:
  template:
    spec:
      strategy:
        retryLimit: 1
        timeout: 5m0s
        type: Reboot
참고

NodeHealthCheck CR을 생성하는 것 외에도 Metal3RemediationTemplate 을 생성해야 합니다.

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

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

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

6.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"}

6.2. 컨트롤 플레인 펜싱

이전 릴리스에서는 작업자 노드에서 Self Node Remediation 및 Node Health Check를 활성화할 수 있습니다. 노드 오류가 발생하는 경우 이제 컨트롤 플레인 노드에서 수정 전략을 따를 수 있습니다.

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

수정 전략 고려 사항:

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

6.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 페이지로 이동하여 상태 열에 오류 또는 실패가 있는지 검사합니다.
  2. 워크로드Pod 페이지로 이동하여 openshift-operators 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.

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

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

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

openshift-operators 네임스페이스에 Operator를 설치하려면 새 Namespace 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. Namespace 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. 서브스크립션 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의 최신 버전으로 업그레이드하려면 서브스크립션의 채널 이름을 candidate 에서 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.6.0. Node Health Check Operator  0.6.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

6.5. 노드 상태 점검 생성

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

프로세스

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

    참고

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

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

검증

  • ComputeNodeHealthCheck 페이지로 이동하여 해당 노드 상태 점검 및 해당 상태가 표시되는지 확인합니다. 생성된 노드 상태 점검을 일시 중지, 수정, 삭제할 수 있습니다.

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

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

6.7. 추가 리소스

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

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

7.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 명령과 동일한 결과를 얻을 수 있습니다.

7.2. Node Maintenance Operator 설치

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

참고

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

7.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 페이지로 이동하여 상태 열에 오류 또는 실패가 있는지 검사합니다.
  2. Operator → 설치된 Operator Node Maintenance Operator세부 정보 페이지로 이동하여 Pod 생성 전에 Conditions 섹션에서 오류를 검사합니다.
  3. 워크로드Pod 페이지로 이동하여 설치된 네임스페이스에서 Node Maintenance Operator Pod를 검색하고 로그 탭에서 로그를 확인합니다.

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

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

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

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

openshift-operators 네임스페이스에 Operator를 설치하려면 새 Namespace CR(사용자 정의 리소스) 및 OperatorGroup CR을 생성하는 단계가 필요하지 않기 때문에 절차의 3 단계로 건너뜁니다.

사전 요구 사항

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

프로세스

  1. Node Maintenance Operator의 네임스페이스 CR을 생성합니다.

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: nmo-test
    2. Namespace 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
        installPlanApproval: Automatic
        name: node-maintenance-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        package: node-maintenance-operator
      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.v5.0.0   Node Maintenance Operator   5.0.0               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 사용을 참조하십시오.

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

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

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

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

사전 요구 사항

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

프로세스

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

검증

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

7.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

7.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 수입니다.

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

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

7.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 를 클릭하고 NodeMaintenance 삭제 를 선택합니다.

검증

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

7.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

7.5. 베어 메탈 노드 작업

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

참고

베어 메탈 노드가 있는 클러스터에서도 노드를 유지보수 모드에 배치할 수 있으며, 웹 콘솔 및 CLI를 사용하여 노드를 유지보수 모드에서 다시 시작할 수 있습니다. 웹 콘솔 작업 제어를 사용하여 이러한 방법은 베어 메탈 클러스터에만 적용할 수 있습니다.

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

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

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

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

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

프로세스

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

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

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

검증

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

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

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

프로세스

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

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

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

검증

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

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

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

7.7. 추가 리소스

법적 공지

Copyright © 2024 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.