2장. 클러스터 업데이트 준비
2.1. OpenShift Container Platform 4.19로 업데이트 준비 중 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자가 업데이트를 성공적으로 초기화하기 위해 수행해야 하는 관리 작업과 업데이트를 성공적으로 수행하기 위한 선택적 지침에 대해 자세히 알아보세요.
2.1.1. Kubernetes API 제거 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 4.19는 더 이상 사용되지 않는 Kubernetes API 몇 가지를 제거한 Kubernetes 1.32를 사용합니다.
클러스터 관리자는 클러스터를 OpenShift Container Platform 4.18에서 4.19로 업데이트하기 전에 수동 확인을 제공해야 합니다. 이는 OpenShift Container Platform 4.19로 업그레이드한 후 제거된 API가 클러스터에서 실행되거나 클러스터와 상호 작용하는 워크로드, 도구 또는 기타 구성 요소에서 계속 사용되는 문제를 방지하기 위한 것입니다. 관리자는 제거될 모든 API에 대해 클러스터를 평가하고 영향을 받는 구성 요소를 마이그레이션하여 적절한 새 API 버전을 사용해야 합니다. 이 평가 및 마이그레이션이 완료되면 관리자는 승인을 제공할 수 있습니다.
OpenShift Container Platform 4.18 클러스터를 4.19로 업데이트하려면 먼저 관리자의 승인을 받아야 합니다.
2.1.1.1. 제거된 Kubernetes API 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 4.19는 다음과 같은 더 이상 사용되지 않는 API를 제거한 Kubernetes 1.32를 사용합니다. 적절한 API 버전을 사용하려면 매니페스트와 API 클라이언트를 마이그레이션해야 합니다. 제거된 API 마이그레이션에 대한 자세한 내용은 Kubernetes 설명서 를 참조하십시오.
리소스 | API 제거됨 | 로 마이그레이션 | 주요 변경 사항 |
---|---|---|---|
|
|
| 없음 |
|
|
|
2.1.1.2. 제거된 API에 대한 클러스터 평가 링크 복사링크가 클립보드에 복사되었습니다!
관리자가 제거할 API 위치를 식별하는 데 도움이 되는 여러 가지 방법이 있습니다. 그러나 OpenShift Container Platform은 모든 인스턴스, 특히 유휴 상태인 워크로드 또는 사용되는 외부 툴을 식별할 수 없습니다. 관리자가 제거된 API 인스턴스에 대한 모든 워크로드 및 기타 통합을 적절하게 평가해야 합니다.
2.1.1.2.1. 제거된 API의 사용 식별을 위한 경고 검토 링크 복사링크가 클립보드에 복사되었습니다!
다음 릴리스에서 제거될 API가 사용 중인 경우 두 개의 경고가 발생합니다.
-
APIRemovedInNextReleaseInUse
- OpenShift Container Platform의 다음 릴리스에서 제거될 API의 경우 -
APIRemovedIn다음 EUSReleaseInUse
- OpenShift Container Platform EUS (Extended Update Support) 릴리스에서 제거될 API의 경우
이러한 경고 중 하나가 클러스터에서 실행 중인 경우 경고를 검토하고 새 API 버전을 사용하도록 매니페스트 및 API 클라이언트를 마이그레이션하여 경고를 지우는 조치를 취합니다.
알림에서는 이러한 정보를 제공하지 않으므로, APIRequestCount
API를 사용하면 어떤 API가 사용 중인지, 어떤 워크로드가 제거된 API를 사용하는지에 대한 자세한 정보를 얻을 수 있습니다. 또한 일부 API는 이러한 알림을 발생시키지 않더라도 APIRequestCount
에 의해 캡처될 수 있습니다. 생산 시스템에서 경보 피로를 피하기 위해 경보의 민감도를 낮추도록 조정되었습니다.
2.1.1.2.2. APIRequestCount를 사용하여 제거된 API 사용 확인 링크 복사링크가 클립보드에 복사되었습니다!
APIRequestCount API
를 사용하여 API 요청을 추적하고 제거된 API 중 하나를 사용 중인지 검토할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 명령을 실행하고 출력의
REMOVEDINRELEASE
열을 검사하여 현재 사용 중인 제거된 API를 확인합니다.oc get apirequestcounts
$ oc get apirequestcounts
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요결과에 나타나는 다음 항목은 무시해도 됩니다.
-
system:serviceaccount:kube-system:generic-garbage-collector
및system:serviceaccount:kube-system:namespace-controller
사용자가 결과에 나타날 수 있는 이유는 이러한 서비스가 제거할 리소스를 검색할 때 등록된 모든 API를 호출하기 때문입니다. -
system:kube-controller-manager
및system:cluster-policy-controller
사용자는 다양한 정책을 시행하면서 모든 리소스를 검토하기 때문에 결과에 나타날 수 있습니다.
-o jsonpath
를 사용하여 결과를 필터링할 수도 있습니다.oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'
$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
1.32 flowschemas.v1beta3.flowcontrol.apiserver.k8s.io 1.32 prioritylevelconfigurations.v1beta3.flowcontrol.apiserver.k8s.io
1.32 flowschemas.v1beta3.flowcontrol.apiserver.k8s.io 1.32 prioritylevelconfigurations.v1beta3.flowcontrol.apiserver.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
2.1.1.2.3. APIRequestCount를 사용하여 제거된 API를 사용하는 워크로드 식별 링크 복사링크가 클립보드에 복사되었습니다!
지정된 API 버전에 대해 APIRequestCount
리소스를 검사하여 API를 사용하는 워크로드를 식별할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 명령을 실행하고
username
및userAgent
필드를 검사하여 API를 사용하는 워크로드를 식별할 수 있습니다.oc get apirequestcounts <resource>.<version>.<group> -o yaml
$ oc get apirequestcounts <resource>.<version>.<group> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들면 다음과 같습니다.
oc get apirequestcounts flowschemas.v1beta3.flowcontrol.apiserver.k8s.io -o yaml
$ oc get apirequestcounts flowschemas.v1beta3.flowcontrol.apiserver.k8s.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -o jsonpath를
사용하여APIRequestCount
리소스에서사용자 이름
및userAgent
값을 추출할 수도 있습니다.oc get apirequestcounts flowschemas.v1beta3.flowcontrol.apiserver.k8s.io \ -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \ | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
$ oc get apirequestcounts flowschemas.v1beta3.flowcontrol.apiserver.k8s.io \ -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \ | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
VERBS USERNAME USERAGENT create system:admin oc/4.13.0 (linux/amd64) list get system:serviceaccount:myns:default oc/4.16.0 (linux/amd64) watch system:serviceaccount:myns:webhook webhook/v1.0.0 (linux/amd64)
VERBS USERNAME USERAGENT create system:admin oc/4.13.0 (linux/amd64) list get system:serviceaccount:myns:default oc/4.16.0 (linux/amd64) watch system:serviceaccount:myns:webhook webhook/v1.0.0 (linux/amd64)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.1.3. 제거된 API의 인스턴스 마이그레이션 링크 복사링크가 클립보드에 복사되었습니다!
제거된 Kubernetes API를 마이그레이션하는 방법에 대한 자세한 내용은 Kubernetes 설명서의 더 이상 사용되지 않는 API 마이그레이션 가이드를 참조하세요.
2.1.1.4. 관리자 확인 제공 링크 복사링크가 클립보드에 복사되었습니다!
제거된 API에 대한 클러스터를 평가하고 제거된 API를 마이그레이션한 후에는 클러스터를 OpenShift Container Platform 4.18에서 4.19로 업그레이드할 준비가 되었음을 확인할 수 있습니다.
이 관리자 승인을 제공하기 전에 제거된 API의 모든 사용이 해결되고 필요에 따라 마이그레이션되었는지 확인하는 모든 책임은 관리자에게 있음을 유의하십시오. OpenShift Container Platform은 평가를 지원할 수 있지만 제거된 API, 특히 유휴 워크로드 또는 외부 툴의 모든 사용을 식별할 수 없습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 명령을 실행하여 평가가 완료되었고 클러스터가 OpenShift Container Platform 4.19에서 Kubernetes API 제거에 준비되었음을 확인합니다.
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge
$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.2. 조건부 업데이트의 위험 평가 링크 복사링크가 클립보드에 복사되었습니다!
조건부 업데이트는 클러스터에 적용되는 알려진 위험으로 인해 사용 가능하지만 권장되지 않는 업데이트 대상입니다. 클러스터 버전 운영자(CVO)는 업데이트 권장 사항에 대한 최신 데이터를 얻기 위해 OpenShift 업데이트 서비스(OSUS)를 주기적으로 쿼리하며, 잠재적인 일부 업데이트 대상에는 위험이 있을 수 있습니다.
CVO는 조건부 위험을 평가하고, 위험이 클러스터에 적용되지 않는 경우 대상 버전을 클러스터에 대한 권장 업데이트 경로로 사용할 수 있습니다. 위험이 적용 가능한 것으로 판단되거나 어떤 이유로 CVO가 위험을 평가할 수 없는 경우 업데이트 대상은 클러스터에서 조건부 업데이트로 사용할 수 있습니다.
대상 버전으로 업데이트하는 동안 조건부 업데이트가 발생하면 클러스터를 해당 버전으로 업데이트하는 데 따른 위험을 평가해야 합니다. 일반적으로 해당 대상 버전으로 업데이트할 특정 필요가 없는 경우 Red Hat에서 권장 업데이트 경로를 기다리는 것이 좋습니다.
하지만 해당 버전으로 업데이트해야 하는 강력한 이유가 있는 경우(예: 중요한 CVE를 수정해야 하는 경우)에는 CVE를 수정하는 이점이 업데이트로 인해 클러스터에 문제가 생길 위험보다 더 클 수 있습니다. 다음 작업을 완료하여 Red Hat의 업데이트 위험 평가에 동의하는지 확인할 수 있습니다.
- 프로덕션 환경에서 업데이트를 완료하는 데 문제가 없을 때까지 비프로덕션 환경에서 광범위한 테스트를 완료하세요.
- 조건부 업데이트 설명에 제공된 링크를 따라 버그를 조사하고 클러스터에 문제를 일으킬 가능성이 있는지 확인하세요. 위험을 이해하는 데 도움이 필요하면 Red Hat 지원팀에 문의하세요.
2.1.3. 클러스터 업데이트 전 etcd 백업 링크 복사링크가 클립보드에 복사되었습니다!
etcd 백업은 클러스터와 모든 리소스 객체의 상태를 기록합니다. 현재의 작동하지 않는 상태에서 클러스터를 복구할 수 없는 재해 상황에서 백업을 사용하여 클러스터 상태를 복원할 수 있습니다.
업데이트 컨텍스트에서 업데이트로 인해 이전 클러스터 버전으로 되돌리지 않고는 복구할 수 없는 치명적인 상황이 발생한 경우 클러스터의 etcd 복원을 시도할 수 있습니다. etcd 복원은 실행 중인 클러스터에 파괴적이고 불안정해질 수 있으므로 최후의 수단으로만 사용해야 합니다.
etcd 복원은 심각한 결과를 초래하므로 롤백 솔루션으로 사용할 수 없습니다. 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 업데이트가 완료되지 않으면 Red Hat 지원팀에 문의하세요.
Etcd 복원의 실행 가능성에 영향을 미치는 요소는 여러 가지가 있습니다. 자세한 내용은 "etcd 데이터 백업" 및 "이전 클러스터 상태로 복원"을 참조하세요.
2.1.4. Ingress Operator에 의한 Gateway API 관리 계승 준비 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 4.19부터 Ingress Operator는 모든 Gateway API 사용자 정의 리소스 정의(CRD)의 수명 주기를 관리합니다. 즉, Gateway API에 그룹화된 API 그룹 내에서 CRD를 생성, 업데이트, 삭제하는 작업에 대한 액세스가 거부됩니다.
이 관리가 제공되지 않는 OpenShift Container Platform 4.19 이전 버전에서 업데이트하려면 Ingress Operator에서 요구하는 특정 OpenShift Container Platform 사양을 준수하도록 클러스터에 이미 있는 Gateway API CRD를 교체하거나 제거해야 합니다. OpenShift Container Platform 버전 4.19에는 Gateway API Standard 버전 1.2.1 CRD가 필요합니다.
Gateway API 리소스를 업데이트하거나 삭제하면 가동 중지 및 서비스 또는 데이터 손실이 발생할 수 있습니다. 이 절차의 단계를 수행하기 전에 이것이 클러스터에 어떤 영향을 미칠지 반드시 이해해야 합니다. 필요한 경우 나중에 복원할 수 있도록 YAML 형식으로 Gateway API 객체를 백업하세요.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
선택 사항: 필요한 Gateway API 객체를 백업했습니다.
주의이전 정의에는 있었지만 새 정의에는 없는 CRD 필드에 대한 백업 및 복원이 실패하거나 데이터 손실이 발생할 수 있습니다.
프로세스
다음 명령을 실행하여 제거해야 할 모든 Gateway API CRD를 나열하세요.
oc get crd | grep -F -e gateway.networking.k8s.io -e gateway.networking.x-k8s.io
$ oc get crd | grep -F -e gateway.networking.k8s.io -e gateway.networking.x-k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
gatewayclasses.gateway.networking.k8s.io gateways.gateway.networking.k8s.io grpcroutes.gateway.networking.k8s.io httproutes.gateway.networking.k8s.io referencegrants.gateway.networking.k8s.io
gatewayclasses.gateway.networking.k8s.io gateways.gateway.networking.k8s.io grpcroutes.gateway.networking.k8s.io httproutes.gateway.networking.k8s.io referencegrants.gateway.networking.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 이전 단계의 Gateway API CRD를 삭제합니다.
oc delete crd gatewayclasses.networking.k8s.io && \ oc delete crd gateways.networking.k8s.io && \ oc delete crd grpcroutes.gateway.networking.k8s.io && \ oc delete crd httproutes.gateway.networking.k8s.io && \ oc delete crd referencesgrants.gateway.networking.k8s.io
$ oc delete crd gatewayclasses.networking.k8s.io && \ oc delete crd gateways.networking.k8s.io && \ oc delete crd grpcroutes.gateway.networking.k8s.io && \ oc delete crd httproutes.gateway.networking.k8s.io && \ oc delete crd referencesgrants.gateway.networking.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요CRD를 삭제하면 해당 CRD에 의존하는 모든 사용자 정의 리소스가 제거되고 데이터 손실이 발생할 수 있습니다. Gateway API CRD를 삭제하기 전에 필요한 데이터를 백업하세요. 이전에 Gateway API CRD의 수명 주기를 관리하던 모든 컨트롤러는 제대로 작동하지 않게 됩니다. Ingress Operator와 함께 강제로 사용하여 Gateway API CRD를 관리하려고 하면 클러스터 업데이트가 성공하지 못할 수 있습니다.
다음 명령을 실행하여 지원되는 Gateway API CRD를 가져옵니다.
oc apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
$ oc apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주의CRD를 삭제하지 않고도 이 단계를 수행할 수 있습니다. CRD를 업데이트하면 사용자 지정 리소스에서 사용되는 필드가 제거되므로 데이터가 손실될 수 있습니다. CRD를 두 번째로 업데이트하여 필드를 다시 추가하는 버전을 사용하면 이전에 삭제한 데이터가 다시 나타날 수 있습니다. OpenShift Container Platform 4.19에서 지원되지 않는 특정 Gateway API CRD 버전에 의존하는 모든 타사 컨트롤러는 해당 CRD를 Red Hat에서 지원하는 버전으로 업데이트하면 중단됩니다.
OpenShift Container Platform 구현 및 데드 필드 문제에 대한 자세한 내용은 OpenShift Container Platform을 위한 Gateway API 구현을 참조하세요.
2.1.5. 클러스터 업데이트를 위한 모범 사례 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 업데이트 중에 작업 중단을 최소화하는 강력한 업데이트 환경을 제공합니다. 업데이트 요청 시 클러스터가 업그레이드 가능한 상태가 아니면 업데이트가 시작되지 않습니다.
이 설계는 업데이트를 시작하기 전에 몇 가지 주요 조건을 적용하지만, 클러스터 업데이트의 성공 가능성을 높이기 위해 취할 수 있는 몇 가지 조치가 있습니다.
2.1.5.1. OpenShift 업데이트 서비스에서 권장하는 버전을 선택하세요 링크 복사링크가 클립보드에 복사되었습니다!
OSUS(OpenShift Update Service)는 클러스터의 구독 채널과 같은 클러스터 특성에 따라 업데이트 권장 사항을 제공합니다. 클러스터 버전 운영자는 이러한 권장 사항을 권장 업데이트 또는 조건부 업데이트로 저장합니다. OSUS에서 권장하지 않는 버전으로 업데이트를 시도하는 것은 가능하지만, 권장하는 업데이트 경로를 따르면 사용자는 클러스터에서 알려진 문제나 의도치 않은 결과에 직면하는 것을 방지할 수 있습니다.
성공적인 업데이트를 보장하려면 OSUS에서 권장하는 업데이트 대상만 선택하세요.
2.1.5.2. 클러스터의 모든 중요 경고를 처리합니다. 링크 복사링크가 클립보드에 복사되었습니다!
중요한 경고는 항상 가능한 한 빨리 처리해야 하지만, 특히 클러스터 업데이트를 시작하기 전에 이러한 경고를 처리하고 문제를 해결하는 것이 중요합니다. 업데이트를 시작하기 전에 중요한 경고를 처리하지 못하면 클러스터에 문제가 발생할 수 있습니다.
웹 콘솔의 관리자 화면에서 모니터링
2.1.5.3. 클러스터가 업그레이드 가능 상태인지 확인하세요. 링크 복사링크가 클립보드에 복사되었습니다!
하나 이상의 Operator에서 업그레이드 가능
조건을 1시간 이상 True
로 보고하지 않으면 클러스터에서 ClusterNotUpgradeable
경고 경고가 트리거됩니다. 대부분의 경우 이 경고는 패치 업데이트를 차단하지 않지만, 이 경고가 해결되고 모든 운영자가 업그레이드 가능을
True
로 보고할 때까지 마이너 버전 업데이트를 수행할 수 없습니다.
업그레이드 가능
조건에 대한 자세한 내용은 추가 리소스 섹션의 "클러스터 운영자 조건 유형 이해"를 참조하세요.
2.1.5.3.1. SDN 지원 제거 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift SDN 네트워크 플러그인은 4.15 및 4.16 버전에서 더 이상 사용되지 않습니다. 이 릴리스부터 SDN 네트워크 플러그인은 더 이상 지원되지 않으며 해당 내용은 설명서에서 삭제되었습니다.
OpenShift Container Platform 클러스터가 여전히 OpenShift SDN CNI를 사용하는 경우 OpenShift SDN 네트워크 플러그인에서 마이그레이션을 참조하세요.
OpenShift SDN 네트워크 플러그인을 사용하는 경우 클러스터를 OpenShift Container Platform 4.17로 업데이트할 수 없습니다. OpenShift Container Platform 4.17로 업그레이드하기 전에 OVN-Kubernetes 플러그인으로 마이그레이션해야 합니다.
2.1.5.4. 충분한 예비 노드가 사용 가능한지 확인하세요. 링크 복사링크가 클립보드에 복사되었습니다!
클러스터는 특히 클러스터 업데이트를 시작할 때 여유 노드 용량이 거의 없거나 전혀 없이 실행되어서는 안 됩니다. 실행 중이 아니고 사용할 수 없는 노드는 클러스터 작업 부하를 최소화하면서 업데이트를 수행하는 클러스터의 기능을 제한할 수 있습니다.
클러스터의 maxUnavailable
사양의 구성된 값에 따라 사용할 수 없는 노드가 있는 경우 클러스터가 노드에 머신 구성 변경 사항을 적용하지 못할 수 있습니다. 또한, 컴퓨팅 노드에 여유 용량이 충분하지 않으면 첫 번째 노드가 업데이트를 위해 오프라인으로 전환되는 동안 워크로드를 일시적으로 다른 노드로 전환하지 못할 수 있습니다.
성공적인 노드 업데이트의 가능성을 높이기 위해 각 작업자 풀에 사용 가능한 노드가 충분한지, 그리고 컴퓨팅 노드에 여유 용량이 충분한지 확인하세요.
OpenShift Container Platform의 모든 머신 구성 풀에 대한 maxUnavailable
의 기본 설정은 1
입니다. 이 값은 변경하지 말고 한 번에 하나의 제어 평면 노드만 업데이트하는 것이 좋습니다. 제어 평면 풀의 경우 이 값을 3
으로 변경하지 마세요.
2.1.5.5. 클러스터의 PodDisruptionBudget이 올바르게 구성되었는지 확인하세요. 링크 복사링크가 클립보드에 복사되었습니다!
PodDisruptionBudget
객체를 사용하면 주어진 시간에 사용 가능해야 하는 Pod 복제본의 최소 수 또는 백분율을 정의할 수 있습니다. 이 구성은 클러스터 업데이트와 같은 유지 관리 작업 중에 작업 부하가 중단되지 않도록 보호합니다.
그러나 클러스터 업데이트 중에 노드가 비워지고 업데이트되는 것을 방지하는 방식으로 주어진 토폴로지에 대해 PodDisruptionBudget
을 구성하는 것이 가능합니다.
클러스터 업데이트를 계획할 때 PodDisruptionBudget
개체의 구성에서 다음 요소를 확인하세요.
-
고가용성 워크로드의 경우
PodDisruptionBudget
에 의해 금지되지 않고 일시적으로 오프라인으로 전환할 수 있는 복제본이 있는지 확인하세요. -
가용성이 높지 않은 워크로드의 경우
PodDisruptionBudget
으로 보호되지 않도록 하거나 이러한 워크로드를 결국 소진하기 위한 대체 메커니즘(예: 주기적 재시작 또는 보장된 최종 종료)을 갖추고 있는지 확인하세요.