7.6. Operator 문제 해결
Operator는 OpenShift Container Platform 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. Operator는 소프트웨어 공급 업체의 엔지니어링 팀의 확장 기능으로 OpenShift Container Platform 환경을 모니터링하고 현재 상태를 사용하여 실시간으로 의사 결정을 내립니다. Operator는 업그레이드를 원활하게 처리하고 오류 발생에 자동으로 대응하며 시간을 절약하기 위해 소프트웨어 백업 프로세스를 생략하는 것과 같은 바로가기를 실행하지 않습니다.
OpenShift Container Platform 4.9에는 클러스터가 제대로 작동하는 데 필요한 기본 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 서브스크립션 상태 유형
서브스크립션은 다음 상태 유형을 보고할 수 있습니다.
상태 | 설명 |
---|---|
| 해결에 사용되는 일부 또는 모든 카탈로그 소스가 정상 상태가 아닙니다. |
| 서브스크립션 설치 계획이 없습니다. |
| 서브스크립션 설치 계획이 설치 대기 중입니다. |
| 서브스크립션 설치 계획이 실패했습니다. |
기본 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
)가 설치되어 있습니다.
절차
Operator 서브스크립션을 나열합니다.
$ oc get subs -n <operator_namespace>
oc describe
명령을 사용하여Subscription
리소스를 검사합니다.$ oc describe sub <subscription_name> -n <operator_namespace>
명령 출력에서 Operator 서브스크립션 조건 유형의 상태에 대한
Conditions
섹션을 확인합니다. 다음 예에서 사용 가능한 모든 카탈로그 소스가 정상이므로CatalogSourcesUnhealthy
조건 유형의 상태가false
입니다.출력 예
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
)가 설치되어 있습니다.
절차
네임스페이스의 카탈로그 소스를 나열합니다. 예를 들어 클러스터 전체 카탈로그 소스에 사용되는
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
oc describe
명령을 사용하여 카탈로그 소스에 대한 자세한 내용 및 상태를 가져옵니다.$ oc describe catalogsource example-catalog -n openshift-marketplace
출력 예
Name: example-catalog Namespace: openshift-marketplace ... 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
입니다. 이 상태는 카탈로그 소스에 대한 연결을 설정하는 데 문제가 있음을 나타냅니다.카탈로그 소스가 생성된 네임스페이스의 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
입니다. 이 상태는 카탈로그 소스의 인덱스 이미지를 가져오는 데 문제가 있음을 나타냅니다.자세한 정보는
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
)가 설치되어 있습니다.
절차
클러스터에서 실행중인 Operator를 나열합니다. 출력에는 Operator 버전, 가용성 및 가동 시간 정보가 포함됩니다.
$ oc get clusteroperators
Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.
$ oc get pod -n <operator_namespace>
자세한 Operator Pod 요약을 출력합니다.
$ oc describe pod <operator_pod_name> -n <operator_namespace>
Operator 문제가 노드와 관련된 경우 해당 노드에서 Operator 컨테이너 상태를 쿼리합니다.
노드의 디버그 Pod를 시작합니다.
$ oc debug node/my-node
디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host
로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.# chroot /host
참고RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.9 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않으며 노드는 accessed 테인트로 표시됩니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우
oc
작업이 영향을 받습니다. 이러한 상황에서 대신ssh core @ <node>.<cluster_name>.<base_domain>
을 사용하여 노드에 액세스할 수 있습니다.상태 및 관련 Pod ID를 포함하여 노드의 컨테이너에 대한 세부 정보를 나열합니다.
# crictl ps
노드의 특정 Operator 컨테이너에 대한 정보를 나열합니다. 다음 예는
network-operator
컨테이너에 대한 정보를 나열합니다.# crictl ps --name network-operator
- 디버그 쉘을 종료합니다.
7.6.5. Operator 로그 수집
Operator 문제가 발생하면 Operator Pod 로그에서 자세한 진단 정보를 수집할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - API 서비스가 작동하고 있어야 합니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - 컨트롤 플레인 또는 컨트롤 플레인 시스템의 정규화된 도메인 이름이 있어야 합니다.
절차
Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.
$ oc get pods -n <operator_namespace>
Operator Pod의 로그를 검토합니다.
$ oc logs pod/<pod_name> -n <operator_namespace>
Operator Pod에 컨테이너가 여러 개 있는 경우 위 명령에 의해 각 컨테이너의 이름이 포함된 오류가 생성됩니다. 개별 컨테이너의 로그를 쿼리합니다.
$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
API가 작동하지 않는 경우 대신 SSH를 사용하여 각 컨트롤 플레인 노드에서 Operator Pod 및 컨테이너 로그를 검토합니다.
<master-node>.<cluster_name>.<base_domain>
을 적절한 값으로 바꿉니다.각 컨트롤 플레인 노드에 Pod를 나열합니다.
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
Ready
상태가 표시되지 않는 Operator Pod의 경우 Pod 상태를 자세히 검사합니다.<operator_pod_id>
를 이전 명령의 출력에 나열된 Operator Pod의 ID로 교체합니다.$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
Operator Pod와 관련된 컨테이너를 나열합니다.
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
Ready
상태가 표시되지 않는 Operator 컨테이너의 경우 컨테이너 상태를 자세히 검사합니다.<container_id>
를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
Ready
상태가 표시되지 않는 Operator 컨테이너의 로그를 확인합니다.<container_id>
를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
참고RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.9 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않으며 노드는 accessed 테인트로 표시됩니다. 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가
ImageDigestMirrorSet
또는ImageTagMirrorSet
오브젝트 추가 또는 편집과 같은/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의 노드에 적용되지 않습니다. 이로 인해 oc debug
, oc logs
, oc exec
, oc attach
를 포함하여 여러 oc
명령이 실패합니다. 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 업데이트 재부팅을 일시 중지하거나 일시 중지 해제하려면 다음을 수행합니다.
자동 재부팅 프로세스를 일시 중지합니다.
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다. -
Compute
MachineConfigPools를 클릭합니다. - MachineConfigPools 페이지에서 재부팅을 일시 중지할 노드에 따라 마스터 또는 작업자 를 클릭합니다.
- 마스터 또는 작업자 페이지에서 YAML을 클릭합니다.
YAML에서
spec.paused
필드를true
로 업데이트합니다.샘플 MachineConfigPool 오브젝트
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool ... spec: ... paused: true 1
- 1
spec.paused
필드를true
로 업데이트하여 재부팅을 일시 중지합니다.
MCP가 일시 중지되었는지 확인하려면 MachineConfigPools 페이지로 돌아갑니다.
MachineConfigPools 페이지에서 Paused 열은 수정한 MCP에 대한 True 를 보고합니다.
일시 중지된 동안 MCP에 보류 중인 변경 사항이 있는 경우 Updated 열은 False이고 Updating 열은 False입니다. Updated이 True이고 Updating이 False인 경우 보류 중인 변경 사항이 없습니다.
중요Updated 및 Updating 열이 모두 False인 보류 중인 변경 사항이 있는 경우 최대한 빨리 재부팅할 수 있도록 유지 관리 기간을 예약하는 것이 좋습니다. 자동 재부팅 프로세스를 일시 중지 해제하려면 다음 단계를 사용하여 마지막 재부팅 이후 대기열에 있는 변경 사항을 적용합니다.
-
자동 재부팅 프로세스의 일시 중지를 해제합니다.
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다. -
Compute
MachineConfigPools를 클릭합니다. - MachineConfigPools 페이지에서 재부팅을 일시 중지할 노드에 따라 마스터 또는 작업자 를 클릭합니다.
- 마스터 또는 작업자 페이지에서 YAML을 클릭합니다.
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) 재부팅을 적용합니다.
MCP가 일시 중지되었는지 확인하려면 MachineConfigPools 페이지로 돌아갑니다.
MachineConfigPools 페이지에서 Paused 열은 수정한 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 업데이트 재부팅을 일시 중지하거나 일시 중지 해제하려면 다음을 수행합니다.
자동 재부팅 프로세스를 일시 중지합니다.
MachineConfigPool
사용자 정의 리소스를 업데이트하여spec.paused
필드를true
로 설정합니다.컨트롤 플레인 (마스터) 노드
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
작업자 노드
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
MCP가 일시 중지되었는지 확인합니다.
컨트롤 플레인 (마스터) 노드
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
작업자 노드
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
출력 예
true
spec.paused
필드가true
이고 MCP가 일시 중지되었습니다.MCP에 보류 중인 변경 사항이 있는지 확인합니다.
# oc get machineconfigpool
출력 예
NAME CONFIG UPDATED UPDATING master rendered-master-33cf0a1254318755d7b48002c597bf91 True False worker rendered-worker-e405a5bdb0db1295acea08bcca33fa60 False False
UPDATED 열이 False이고 UPDATING이 False이면 보류 중인 변경 사항이 있습니다. UPDATED가 True이고 UPDATING이 False인 경우 보류 중인 변경 사항이 없습니다. 이전 예에서 작업자 노드에 보류 중인 변경 사항이 있습니다. 컨트롤 플레인 노드에는 보류 중인 변경 사항이 없습니다.
중요Updated 및 Updating 열이 모두 False인 보류 중인 변경 사항이 있는 경우 최대한 빨리 재부팅할 수 있도록 유지 관리 기간을 예약하는 것이 좋습니다. 자동 재부팅 프로세스를 일시 중지 해제하려면 다음 단계를 사용하여 마지막 재부팅 이후 대기열에 있는 변경 사항을 적용합니다.
자동 재부팅 프로세스의 일시 중지를 해제합니다.
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)를 재부팅합니다.
MCP가 일시 중지되지 않았는지 확인합니다.
컨트롤 플레인 (마스터) 노드
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
작업자 노드
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
출력 예
false
spec.paused
필드가false
이고 MCP가 일시 중지되지 않습니다.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입니다. UPDATED가 True이고 UPDATING이 False이면 추가 변경 사항이 없습니다. 이전 예에서 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를 다시 설치합니다.
사전 요구 사항
- 액세스할 수 없는 번들 이미지를 가져올 수 없는 실패한 서브스크립션이 있습니다.
- 올바른 번들 이미지에 액세스할 수 있는지 확인했습니다.
프로세스
Operator가 설치된 네임스페이스에서
Subscription
및ClusterServiceVersion
오브젝트의 이름을 가져옵니다.$ 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
서브스크립션을 삭제합니다.
$ oc delete subscription <subscription_name> -n <namespace>
클러스터 서비스 버전을 삭제합니다.
$ oc delete csv <csv_name> -n <namespace>
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
작업을 삭제합니다.
$ oc delete job <job_name> -n openshift-marketplace
이렇게 하면 액세스할 수 없는 이미지를 가져오려는 Pod가 다시 생성되지 않습니다.
구성 맵을 삭제합니다.
$ oc delete configmap <configmap_name> -n openshift-marketplace
- 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.
검증
Operator가 제대로 다시 설치되었는지 확인합니다.
$ oc get sub,csv,installplan -n <namespace>