7.6. Operator 문제 해결


Operator는 OpenShift Container Platform 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. Operator는 소프트웨어 공급 업체의 엔지니어링 팀의 확장 기능으로 OpenShift Container Platform 환경을 모니터링하고 현재 상태를 사용하여 실시간으로 의사 결정을 내립니다. Operator는 업그레이드를 원활하게 처리하고 오류 발생에 자동으로 대응하며 시간을 절약하기 위해 소프트웨어 백업 프로세스를 생략하는 것과 같은 바로가기를 실행하지 않습니다.

OpenShift Container Platform 4.11에는 클러스터가 제대로 작동하는 데 필요한 기본 Operator 세트가 포함되어 있습니다. 이러한 기본 운영자는 CVO (Cluster Version Operator)에 의해 관리됩니다.

클러스터 관리자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 애플리케이션 Operator를 설치할 수 있습니다. 그런 다음 Operator를 하나 이상의 네임 스페이스에 가입시켜 클러스터의 개발자가 사용할 수 있도록합니다. 애플리케이션 Operator는 OLM (Operator Lifecycle Manager)에서 관리합니다.

Operator 문제가 발생하면 Operator 서브스크립션 상태를 확인하십시오. 클러스터 전체에서 Operator Pod 상태를 확인하고 진단을 위해 Operator 로그를 수집합니다.

7.6.1. Operator 서브스크립션 상태 유형

서브스크립션은 다음 상태 유형을 보고할 수 있습니다.

표 7.2. 서브스크립션 상태 유형
상태설명

CatalogSourcesUnhealthy

해결에 사용되는 일부 또는 모든 카탈로그 소스가 정상 상태가 아닙니다.

InstallPlanMissing

서브스크립션 설치 계획이 없습니다.

InstallPlanPending

서브스크립션 설치 계획이 설치 대기 중입니다.

InstallPlanFailed

서브스크립션 설치 계획이 실패했습니다.

ResolutionFailed

서브스크립션의 종속성 확인이 실패했습니다.

참고

기본 OpenShift Container Platform 클러스터 Operator는 CVO(Cluster Version Operator)에서 관리하며 Subscription 오브젝트가 없습니다. 애플리케이션 Operator는 OLM(Operator Lifecycle Manager)에서 관리하며 Subscription 오브젝트가 있습니다.

7.6.2. CLI를 사용하여 Operator 서브스크립션 상태 보기

CLI를 사용하여 Operator 서브스크립션 상태를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. Operator 서브스크립션을 나열합니다.

    $ oc get subs -n <operator_namespace>
  2. oc describe 명령을 사용하여 Subscription 리소스를 검사합니다.

    $ oc describe sub <subscription_name> -n <operator_namespace>
  3. 명령 출력에서 Operator 서브스크립션 조건 유형의 상태에 대한 Conditions 섹션을 확인합니다. 다음 예에서 사용 가능한 모든 카탈로그 소스가 정상이므로 CatalogSourcesUnhealthy 조건 유형의 상태가 false입니다.

    출력 예

    Name:         cluster-logging
    Namespace:    openshift-logging
    Labels:       operators.coreos.com/cluster-logging.openshift-logging=
    Annotations:  <none>
    API Version:  operators.coreos.com/v1alpha1
    Kind:         Subscription
    # ...
    Conditions:
       Last Transition Time:  2019-07-29T13:42:57Z
       Message:               all available catalogsources are healthy
       Reason:                AllCatalogSourcesHealthy
       Status:                False
       Type:                  CatalogSourcesUnhealthy
    # ...

참고

기본 OpenShift Container Platform 클러스터 Operator는 CVO(Cluster Version Operator)에서 관리하며 Subscription 오브젝트가 없습니다. 애플리케이션 Operator는 OLM(Operator Lifecycle Manager)에서 관리하며 Subscription 오브젝트가 있습니다.

7.6.3. CLI를 사용하여 Operator 카탈로그 소스 상태 보기

CLI를 사용하여 Operator 카탈로그 소스의 상태를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 네임스페이스의 카탈로그 소스를 나열합니다. 예를 들어 클러스터 전체 카탈로그 소스에 사용되는 openshift-marketplace 네임스페이스를 확인할 수 있습니다.

    $ oc get catalogsources -n openshift-marketplace

    출력 예

    NAME                  DISPLAY               TYPE   PUBLISHER   AGE
    certified-operators   Certified Operators   grpc   Red Hat     55m
    community-operators   Community Operators   grpc   Red Hat     55m
    example-catalog       Example Catalog       grpc   Example Org 2m25s
    redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
    redhat-operators      Red Hat Operators     grpc   Red Hat     55m

  2. oc describe 명령을 사용하여 카탈로그 소스에 대한 자세한 내용 및 상태를 가져옵니다.

    $ oc describe catalogsource example-catalog -n openshift-marketplace

    출력 예

    Name:         example-catalog
    Namespace:    openshift-marketplace
    Labels:       <none>
    Annotations:  operatorframework.io/managed-by: marketplace-operator
                  target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
    API Version:  operators.coreos.com/v1alpha1
    Kind:         CatalogSource
    # ...
    Status:
      Connection State:
        Address:              example-catalog.openshift-marketplace.svc:50051
        Last Connect:         2021-09-09T17:07:35Z
        Last Observed State:  TRANSIENT_FAILURE
      Registry Service:
        Created At:         2021-09-09T17:05:45Z
        Port:               50051
        Protocol:           grpc
        Service Name:       example-catalog
        Service Namespace:  openshift-marketplace
    # ...

    앞의 예제 출력에서 마지막으로 관찰된 상태는 TRANSIENT_FAILURE입니다. 이 상태는 카탈로그 소스에 대한 연결을 설정하는 데 문제가 있음을 나타냅니다.

  3. 카탈로그 소스가 생성된 네임스페이스의 Pod를 나열합니다.

    $ oc get pods -n openshift-marketplace

    출력 예

    NAME                                    READY   STATUS             RESTARTS   AGE
    certified-operators-cv9nn               1/1     Running            0          36m
    community-operators-6v8lp               1/1     Running            0          36m
    marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
    example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
    redhat-marketplace-57p8c                1/1     Running            0          36m
    redhat-operators-smxx8                  1/1     Running            0          36m

    카탈로그 소스가 네임스페이스에 생성되면 해당 네임스페이스에 카탈로그 소스의 Pod가 생성됩니다. 위 예제 출력에서 example-catalog-bwt8z pod의 상태는 ImagePullBackOff입니다. 이 상태는 카탈로그 소스의 인덱스 이미지를 가져오는 데 문제가 있음을 나타냅니다.

  4. 자세한 정보는 oc describe 명령을 사용하여 Pod를 검사합니다.

    $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

    출력 예

    Name:         example-catalog-bwt8z
    Namespace:    openshift-marketplace
    Priority:     0
    Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
    ...
    Events:
      Type     Reason          Age                From               Message
      ----     ------          ----               ----               -------
      Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
      Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
      Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
      Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
      Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
      Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
      Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

    앞의 예제 출력에서 오류 메시지는 권한 부여 문제로 인해 카탈로그 소스의 인덱스 이미지를 성공적으로 가져오지 못한 것으로 표시됩니다. 예를 들어 인덱스 이미지는 로그인 인증 정보가 필요한 레지스트리에 저장할 수 있습니다.

7.6.4. Operator Pod 상태 쿼리

클러스터 내의 Operator Pod 및 해당 상태를 나열할 수 있습니다. 자세한 Operator Pod 요약을 수집할 수도 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • API 서비스가 작동하고 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 클러스터에서 실행중인 Operator를 나열합니다. 출력에는 Operator 버전, 가용성 및 가동 시간 정보가 포함됩니다.

    $ oc get clusteroperators
  2. Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.

    $ oc get pod -n <operator_namespace>
  3. 자세한 Operator Pod 요약을 출력합니다.

    $ oc describe pod <operator_pod_name> -n <operator_namespace>
  4. Operator 문제가 노드와 관련된 경우 해당 노드에서 Operator 컨테이너 상태를 쿼리합니다.

    1. 노드의 디버그 Pod를 시작합니다.

      $ oc debug node/my-node
    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

      # chroot /host
      참고

      Red Hat Enterprise Linux CoreOS (RHCOS)를 실행하는 OpenShift Container Platform 4.11 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

    3. 상태 및 관련 Pod ID를 포함하여 노드의 컨테이너에 대한 세부 정보를 나열합니다.

      # crictl ps
    4. 노드의 특정 Operator 컨테이너에 대한 정보를 나열합니다. 다음 예는 network-operator 컨테이너에 대한 정보를 나열합니다.

      # crictl ps --name network-operator
    5. 디버그 쉘을 종료합니다.

7.6.5. Operator 로그 수집

Operator 문제가 발생하면 Operator Pod 로그에서 자세한 진단 정보를 수집할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • API 서비스가 작동하고 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 컨트롤 플레인 또는 컨트롤 플레인 시스템의 정규화된 도메인 이름이 있어야 합니다.

절차

  1. Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.

    $ oc get pods -n <operator_namespace>
  2. Operator Pod의 로그를 검토합니다.

    $ oc logs pod/<pod_name> -n <operator_namespace>

    Operator Pod에 컨테이너가 여러 개 있는 경우 위 명령에 의해 각 컨테이너의 이름이 포함된 오류가 생성됩니다. 개별 컨테이너의 로그를 쿼리합니다.

    $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
  3. API가 작동하지 않는 경우 대신 SSH를 사용하여 각 컨트롤 플레인 노드에서 Operator Pod 및 컨테이너 로그를 검토합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

    1. 각 컨트롤 플레인 노드에 Pod를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
    2. Ready 상태가 표시되지 않는 Operator Pod의 경우 Pod 상태를 자세히 검사합니다. <operator_pod_id>를 이전 명령의 출력에 나열된 Operator Pod의 ID로 교체합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
    3. Operator Pod와 관련된 컨테이너를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
    4. Ready 상태가 표시되지 않는 Operator 컨테이너의 경우 컨테이너 상태를 자세히 검사합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
    5. Ready 상태가 표시되지 않는 Operator 컨테이너의 로그를 확인합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
      참고

      Red Hat Enterprise Linux CoreOS (RHCOS)를 실행하는 OpenShift Container Platform 4.11 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. SSH를 통해 진단 데이터를 수집하기 전에 oc adm must gather 및 기타 oc 명령을 실행하여 충분한 데이터를 수집할 수 있는지 확인하십시오. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 ssh core@<node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

7.6.6. Machine Config Operator가 자동으로 재부팅되지 않도록 비활성화

Machine Config Operator(MCO)에서 구성을 변경한 경우 변경 사항을 적용하려면 RHCOS(Red Hat Enterprise Linux CoreOS)를 재부팅해야 합니다. 구성 변경이 자동이든 수동이든 RHCOS 노드는 일시 중지되지 않는 한 자동으로 재부팅됩니다.

참고

다음 수정 사항에서는 노드 재부팅이 트리거되지 않습니다.

  • MCO가 다음 변경 사항을 감지하면 노드를 드레이닝하거나 재부팅하지 않고 업데이트를 적용합니다.

    • 머신 구성의 spec.config.passwd.users.sshAuthorizedKeys 매개변수에서 SSH 키 변경
    • openshift-config 네임 스페이스에서 글로벌 풀 시크릿 또는 풀 시크릿 관련 변경 사항
    • Kubernetes API Server Operator의 /etc/kubernetes/kubelet-ca.crt 인증 기관(CA) 자동 교체
  • MCO가ICSP( ImageContentSourcePolicy ) 오브젝트 추가 또는 편집과 같은 /etc/containers/registries.conf 파일의 변경 사항을 감지하면 해당 노드를 비우고 변경 사항을 적용한 후 노드를 분리합니다. 노드 드레이닝은 다음과 같은 변경에 대해 발생하지 않습니다.

    • 각 미러에 대해 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 레지스트리를 추가합니다.
    • 레지스트리에 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 미러를 추가합니다.
    • unqualified-search-registries 목록에 항목이 추가되었습니다.

원치 않는 중단을 방지하기 위해 Operator에서 머신 구성을 변경한 후 자동 재부팅되지 않도록 머신 구성 풀(MCP)을 수정할 수 있습니다.

참고

MCP를 일시 중지하면 MCO가 연결된 노드에 구성 변경 사항을 적용하지 못합니다. MCP를 일시 중지하면 kube-apiserver-to-kubelet-signer CA 인증서의 자동 순환을 포함하여 자동으로 순환된 인증서가 연결된 노드로 푸시되지 않습니다.

kube-apiserver-to-kubelet-signer CA 인증서가 만료되고 MCO가 인증서를 자동으로 갱신하려고 할 때 MCP가 일시 중지되면 MCO는 새로 순환된 인증서를 해당 노드로 푸시할 수 없습니다. 이로 인해 클러스터의 성능이 저하되고 oc debug, oc logs,oc exec, oc attach 를 포함하여 여러 oc 명령에서 오류가 발생합니다. 인증서가 순환될 때 MCP가 일시 중지되면 OpenShift Container Platform 웹 콘솔의 경고 UI에 알림이 표시됩니다.

MCP 일시 중지는 kube-apiserver-to-kubelet-signer CA 인증서 만료에 대해 신중하게 고려하여 단기간 동안만 수행해야 합니다.

새 CA 인증서는 설치 날짜로부터 292일 후에 생성되며 해당 날짜로부터 365일 후에 제거됩니다. 다음 자동 CA 인증서 교체를 확인하려면 Red Hat OpenShift 4의 Understand CA 인증서 자동 갱신을 참조하십시오.

7.6.6.1. 콘솔을 사용하여 Machine Config Operator가 자동으로 재부팅되지 않도록 비활성화

MCO(Machine Config Operator)에서 원하지 않는 변경을 방지하기 위해 OpenShift Container Platform 웹 콘솔을 사용하여 MCO가 해당 풀의 노드를 변경하지 않도록 MCP(머신 구성 풀)를 수정할 수 있습니다. 이렇게 하면 일반적으로 MCO 업데이트 프로세스의 일부인 재부팅을 방지할 수 있습니다.

참고

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

자동 MCO 업데이트 재부팅을 일시 중지하거나 일시 중지 해제하려면 다음을 수행합니다.

  • 자동 재부팅 프로세스를 일시 중지합니다.

    1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
    2. Click Compute MachineConfigPools.
    3. MachineConfigPools 페이지에서 재부팅을 일시 중지할 노드에 따라 마스터 또는 작업자 를 클릭합니다.
    4. 마스터 또는 작업자 페이지에서 YAML을 클릭합니다.
    5. YAML에서 spec.paused 필드를 true로 업데이트합니다.

      샘플 MachineConfigPool 오브젝트

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      # ...
      spec:
      # ...
        paused: true 1
      # ...

      1
      spec.paused 필드를 true로 업데이트하여 재부팅을 일시 중지합니다.
    6. MCP가 일시 중지되었는지 확인하려면 MachineConfigPools 페이지로 돌아갑니다.

      MachineConfigPools 페이지에서 일시 중지된 열에 수정한 MCP에 대해 True 가 보고됩니다.

      일시 중지된 동안 MCP에 보류 중인 변경 사항이 있는 경우 Updated 열은 False이고 Updating 열은 False입니다. UpdatedTrue이고 UpdatingFalse인 경우 보류 중인 변경 사항이 없습니다.

      중요

      UpdatedUpdating 열이 모두 False인 보류 중인 변경 사항이 있는 경우 최대한 빨리 재부팅할 수 있도록 유지 관리 기간을 예약하는 것이 좋습니다. 자동 재부팅 프로세스를 일시 중지 해제하려면 다음 단계를 사용하여 마지막 재부팅 이후 대기열에 있는 변경 사항을 적용합니다.

  • 자동 재부팅 프로세스의 일시 중지를 해제합니다.

    1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
    2. Click Compute MachineConfigPools.
    3. MachineConfigPools 페이지에서 재부팅을 일시 중지할 노드에 따라 마스터 또는 작업자 를 클릭합니다.
    4. 마스터 또는 작업자 페이지에서 YAML을 클릭합니다.
    5. YAML에서 spec.paused 필드를 false로 업데이트합니다.

      샘플 MachineConfigPool 오브젝트

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      # ...
      spec:
      # ...
        paused: false 1
      # ...

      1
      재부팅을 허용하도록 spec.paused 필드를 false로 업데이트합니다.
      참고

      MCP의 일시 정지를 해제하면 MCO는 모든 일시 중지된 변경 사항이 필요에 따라 RHCOS(Red Hat Enterprise Linux CoreOS) 재부팅을 적용합니다.

    6. MCP가 일시 중지되었는지 확인하려면 MachineConfigPools 페이지로 돌아갑니다.

      MachineConfigPools 페이지에서 일시 중지된 열에 수정한 MCP에 대해 False 를 보고합니다.

      MCP가 보류 중인 변경 사항을 적용하는 경우 Updated 열은 False이고 Updating인 열은 True입니다. 업데이트됨True이고 업데이트 중False인 경우 추가 변경 사항이 적용되지 않습니다.

7.6.6.2. CLI를 사용하여 Machine Config Operator가 자동으로 재부팅되지 않도록 비활성화

MCO(Machine Config Operator)의 변경으로 인한 원치 않는 중단을 방지하려면 OpenShift CLI(oc)를 사용하여 MCP(Machine Config Pool)를 수정하여 MCO가 해당 풀의 노드를 변경하지 못하도록 할 수 있습니다. 이렇게 하면 일반적으로 MCO 업데이트 프로세스의 일부인 재부팅을 방지할 수 있습니다.

참고

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

자동 MCO 업데이트 재부팅을 일시 중지하거나 일시 중지 해제하려면 다음을 수행합니다.

  • 자동 재부팅 프로세스를 일시 중지합니다.

    1. MachineConfigPool 사용자 정의 리소스를 업데이트하여 spec.paused 필드를 true로 설정합니다.

      컨트롤 플레인 (마스터) 노드

      $ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master

      작업자 노드

      $ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker

    2. MCP가 일시 중지되었는지 확인합니다.

      컨트롤 플레인 (마스터) 노드

      $ oc get machineconfigpool/master --template='{{.spec.paused}}'

      작업자 노드

      $ oc get machineconfigpool/worker --template='{{.spec.paused}}'

      출력 예

      true

      spec.paused 필드가 true이고 MCP가 일시 중지되었습니다.

    3. MCP에 보류 중인 변경 사항이 있는지 확인합니다.

      # oc get machineconfigpool

      출력 예

      NAME     CONFIG                                             UPDATED   UPDATING
      master   rendered-master-33cf0a1254318755d7b48002c597bf91   True      False
      worker   rendered-worker-e405a5bdb0db1295acea08bcca33fa60   False     False

      UPDATED 열이 False이고 UPDATINGFalse이면 보류 중인 변경 사항이 있습니다. UPDATEDTrue이고 UPDATINGFalse인 경우 보류 중인 변경 사항이 없습니다. 이전 예에서 작업자 노드에 보류 중인 변경 사항이 있습니다. 컨트롤 플레인 노드에는 보류 중인 변경 사항이 없습니다.

      중요

      UpdatedUpdating 열이 모두 False인 보류 중인 변경 사항이 있는 경우 최대한 빨리 재부팅할 수 있도록 유지 관리 기간을 예약하는 것이 좋습니다. 자동 재부팅 프로세스를 일시 중지 해제하려면 다음 단계를 사용하여 마지막 재부팅 이후 대기열에 있는 변경 사항을 적용합니다.

  • 자동 재부팅 프로세스의 일시 중지를 해제합니다.

    1. MachineConfigPool 사용자 정의 리소스에서 spec.paused 필드를 false로 업데이트합니다.

      컨트롤 플레인 (마스터) 노드

      $ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master

      작업자 노드

      $ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker

      참고

      MCP의 일시 정지를 해제하면 MCO는 일시 중지된 모든 변경 사항을 적용하고 필요에 따라 RHCOS(Red Hat Enterprise Linux CoreOS)를 재부팅합니다.

    2. MCP가 일시 중지되지 않았는지 확인합니다.

      컨트롤 플레인 (마스터) 노드

      $ oc get machineconfigpool/master --template='{{.spec.paused}}'

      작업자 노드

      $ oc get machineconfigpool/worker --template='{{.spec.paused}}'

      출력 예

      false

      spec.paused 필드가 false이고 MCP가 일시 중지되지 않습니다.

    3. MCP에 보류 중인 변경 사항이 있는지 확인합니다.

      $ oc get machineconfigpool

      출력 예

      NAME     CONFIG                                   UPDATED  UPDATING
      master   rendered-master-546383f80705bd5aeaba93   True     False
      worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False    True

      MCP에서 보류 중인 변경 사항을 적용하는 경우 UPDATED 열은 False이고 UPDATING 열은 True입니다. UPDATEDTrue이고 UPDATINGFalse이면 추가 변경 사항이 없습니다. 이전 예에서 MCO는 작업자 노드를 업데이트하고 있습니다.

7.6.7. 실패한 서브스크립션 새로 고침

OLM(Operator Lifecycle Manager)에서는 네트워크상에서 액세스할 수 없는 이미지를 참조하는 Operator를 구독하는 경우 openshift-marketplace 네임스페이스에 다음 오류로 인해 실패하는 작업을 확인할 수 있습니다.

출력 예

ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

출력 예

rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host

결과적으로 서브스크립션이 이러한 장애 상태에 고착되어 Operator를 설치하거나 업그레이드할 수 없습니다.

서브스크립션, CSV(클러스터 서비스 버전) 및 기타 관련 오브젝트를 삭제하여 실패한 서브스크립션을 새로 고칠 수 있습니다. 서브스크립션을 다시 생성하면 OLM에서 올바른 버전의 Operator를 다시 설치합니다.

사전 요구 사항

  • 액세스할 수 없는 번들 이미지를 가져올 수 없는 실패한 서브스크립션이 있습니다.
  • 올바른 번들 이미지에 액세스할 수 있는지 확인했습니다.

프로세스

  1. Operator가 설치된 네임스페이스에서 SubscriptionClusterServiceVersion 오브젝트의 이름을 가져옵니다.

    $ oc get sub,csv -n <namespace>

    출력 예

    NAME                                                       PACKAGE                  SOURCE             CHANNEL
    subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
    
    NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
    clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

  2. 서브스크립션을 삭제합니다.

    $ oc delete subscription <subscription_name> -n <namespace>
  3. 클러스터 서비스 버전을 삭제합니다.

    $ oc delete csv <csv_name> -n <namespace>
  4. openshift-marketplace 네임스페이스에서 실패한 모든 작업 및 관련 구성 맵의 이름을 가져옵니다.

    $ oc get job,configmap -n openshift-marketplace

    출력 예

    NAME                                                                        COMPLETIONS   DURATION   AGE
    job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
    
    NAME                                                                        DATA   AGE
    configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

  5. 작업을 삭제합니다.

    $ oc delete job <job_name> -n openshift-marketplace

    이렇게 하면 액세스할 수 없는 이미지를 가져오려는 Pod가 다시 생성되지 않습니다.

  6. 구성 맵을 삭제합니다.

    $ oc delete configmap <configmap_name> -n openshift-marketplace
  7. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

검증

  • Operator가 제대로 다시 설치되었는지 확인합니다.

    $ oc get sub,csv,installplan -n <namespace>

7.6.8. 실패한 제거 후 Operator 다시 설치

동일한 Operator를 다시 설치하기 전에 Operator를 성공적으로 제거하고 완전히 제거해야 합니다. Operator를 완전히 설치 해제하지 않으면 프로젝트 또는 네임스페이스와 같은 리소스를 "Terminating" 상태로 유지하고 "오류 해결" 메시지가 발생할 수 있습니다. 예를 들어 다음과 같습니다.

프로젝트 리소스 설명의 예

...
    message: 'Failed to delete all resource types, 1 remaining: Internal error occurred:
      error resolving resource'
...

이러한 유형의 문제로 인해 Operator가 다시 설치되지 않을 수 있습니다.

주의

네임스페이스를 강제 삭제하면 "Terminating" 상태 문제가 해결되지 않고 불안정하거나 예측할 수 없는 클러스터 동작이 발생할 수 있으므로 네임스페이스가 삭제되지 않을 수 있는 관련 리소스를 찾는 것이 좋습니다. 자세한 내용은 Red Hat Knowledgebase Solution #4165791 을 참조하십시오.

다음 절차에서는 이전 Operator 설치의 기존 CRD(사용자 정의 리소스 정의)에서 관련 네임스페이스가 삭제되지 않기 때문에 Operator를 다시 설치할 수 없는 경우 문제를 해결하는 방법을 보여줍니다.

프로세스

  1. "Terminating" 상태로 중단된 Operator와 관련된 네임스페이스가 있는지 확인합니다.

    $ oc get namespaces

    출력 예

    operator-ns-1                                       Terminating

  2. 실패한 제거 후에도 여전히 존재하는 Operator와 관련된 CRD가 있는지 확인합니다.

    $ oc get crds
    참고

    CRD는 글로벌 클러스터 정의입니다. CRD와 관련된 실제 CR(사용자 정의 리소스) 인스턴스는 다른 네임스페이스에 있거나 글로벌 클러스터 인스턴스일 수 있습니다.

  3. Operator에서 제공하거나 관리하는 CRD가 있고 제거 후 삭제해야 하는 CRD가 있는 경우 CRD를 삭제합니다.

    $ oc delete crd <crd_name>
  4. 제거 후에도 여전히 존재하는 Operator와 관련된 나머지 CR 인스턴스가 있는지 확인하고 CR을 삭제합니다.

    1. 검색할 CR 유형은 제거 후 결정하기 어려울 수 있으며 Operator에서 관리하는 CRD를 알아야 할 수 있습니다. 예를 들어 EtcdCluster CRD를 제공하는 etcd Operator의 설치 제거 문제를 해결하는 경우 네임스페이스에서 나머지 EtcdCluster CR을 검색할 수 있습니다.

      $ oc get EtcdCluster -n <namespace_name>

      또는 모든 네임스페이스에서 검색할 수 있습니다.

      $ oc get EtcdCluster --all-namespaces
    2. 제거해야 하는 나머지 CR이 있는 경우 인스턴스를 삭제합니다.

      $ oc delete <cr_name> <cr_instance_name> -n <namespace_name>
  5. 네임스페이스 삭제가 성공적으로 해결되었는지 확인합니다.

    $ oc get namespace <namespace_name>
    중요

    네임스페이스 또는 기타 Operator 리소스가 여전히 제거되지 않은 경우 Red Hat 지원팀에 문의하십시오.

  6. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

검증

  • Operator가 제대로 다시 설치되었는지 확인합니다.

    $ oc get sub,csv,installplan -n <namespace>
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.