2장. 클러스터 업데이트 준비
2.1. OpenShift Container Platform 4.17으로 업데이트 준비
클러스터 관리자가 업데이트를 성공적으로 초기화하기 위해 수행해야 하는 관리 작업과 성공적인 업데이트를 보장하기 위한 선택적 지침에 대해 자세히 알아보십시오.
2.1.1. RHEL 9.2 마이크로 아키텍처 요구 사항 변경
OpenShift Container Platform은 이제 RHEL 9.2 호스트 운영 체제를 기반으로 합니다. 마이크로 아키텍처 요구 사항이 x86_64-v2, Power9 및 Z14로 향상되었습니다. RHEL 마이크로 아키텍처 요구 사항 설명서를 참조하십시오. 이 KCS 문서에 설명된 절차를 따라 업데이트하여 호환성을 확인할 수 있습니다.
올바른 마이크로 아키텍처 요구 사항이 없으면 업데이트 프로세스가 실패합니다. 각 아키텍처에 적합한 서브스크립션을 구매해야 합니다. 자세한 내용은 Red Hat Enterprise Linux 시작하기 - 추가 아키텍처를참조하십시오.
2.1.2. Kubernetes API 제거
OpenShift Container Platform 4.17에는 Kubernetes API 제거가 없습니다.
2.1.3. 조건부 업데이트의 위험 평가
조건부 업데이트는 클러스터에 적용되는 알려진 위험으로 인해 사용할 수 있지만 권장되지 않는 업데이트 대상입니다. CVO(Cluster Version Operator)는 업데이트 권장 사항에 대한 최신 데이터에 대해 OSUS(OpenShift Update Service)를 주기적으로 쿼리하고 일부 잠재적인 업데이트 대상에는 관련 위험이 있을 수 있습니다.
CVO는 조건부 위험을 평가하고 위험이 클러스터에 적용되지 않으면 대상 버전을 클러스터에 권장되는 업데이트 경로로 사용할 수 있습니다. 위험이 적용 가능한 것으로 확인되거나 어떤 이유로 CVO가 위험을 평가할 수 없는 경우 업데이트 대상을 조건부 업데이트로 클러스터에 사용할 수 있습니다.
대상 버전으로 업데이트하려는 동안 조건부 업데이트가 발생하면 클러스터를 해당 버전으로 업데이트할 위험을 평가해야 합니다. 일반적으로 해당 대상 버전으로 업데이트할 특정 필요가 없는 경우 Red Hat에서 권장 업데이트 경로를 기다리는 것이 좋습니다.
그러나 중요한 CVE를 수정해야 하는 경우와 같이 해당 버전으로 업데이트해야 하는 강력한 이유가 있는 경우 CVE를 수정할 때 클러스터에 문제가 발생할 위험이 발생할 수 있습니다. 다음 작업을 완료하여 업데이트 위험에 대한 Red Hat 평가에 동의했는지 여부를 확인할 수 있습니다.
- 프로덕션 환경에서 업데이트를 쉽게 완료할 수 있도록 비프로덕션 환경에서 광범위한 테스트를 완료합니다.
- 조건부 업데이트 설명에 제공된 링크를 따르고 버그를 조사하고 클러스터에 문제가 발생할 가능성이 있는지 확인합니다. 위험을 이해하는 데 도움이 필요하면 Red Hat 지원에 문의하십시오.
추가 리소스
2.1.4. 클러스터 업데이트 전 etcd 백업
etcd 백업은 클러스터의 상태와 모든 리소스 오브젝트를 기록합니다. 백업을 사용하여 현재 기능 상태의 클러스터를 복구할 수 없는 재해 시나리오에서 클러스터 상태를 복원할 수 있습니다.
업데이트 컨텍스트에서 업데이트로 인해 이전 클러스터 버전으로 되돌리지 않고 수정할 수 없는 치명적인 조건이 포함된 경우 클러스터의 etcd 복원을 시도할 수 있습니다. etcd 복원은 파괴적이고 실행 중인 클러스터로 불안정할 수 있으며 이를 마지막 수단으로만 사용합니다.
결과적으로 etcd 복원은 롤백 솔루션으로 사용되지 않습니다. 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 업데이트가 완료되지 않으면 Red Hat 지원에 문의하십시오.
etcd 복원의 실행 가능성에 영향을 미치는 몇 가지 요소가 있습니다. 자세한 내용은 " etcd 데이터 백업" 및 "이전 클러스터 상태로 복구"를 참조하십시오.
추가 리소스
2.1.5. 클러스터 업데이트 모범 사례
OpenShift Container Platform은 업데이트 중에 워크로드 중단을 최소화하는 강력한 업데이트 환경을 제공합니다. 업데이트 요청 시 클러스터가 업그레이드 가능 상태가 되지 않으면 업데이트가 시작되지 않습니다.
이 설계에서는 업데이트를 시작하기 전에 몇 가지 주요 조건을 적용하지만 클러스터 업데이트가 성공할 가능성을 높이기 위해 수행할 수 있는 여러 작업이 있습니다.
2.1.5.1. OpenShift Update Service에서 권장 버전 선택
OSUS(OpenShift Update Service)는 클러스터의 구독 채널과 같은 클러스터 특성을 기반으로 업데이트 권장 사항을 제공합니다. Cluster Version Operator는 이러한 권장 사항을 권장 또는 조건부 업데이트로 저장합니다. OSUS에서 권장하지 않는 버전을 업데이트할 수는 있지만 권장 업데이트 경로에 따라 사용자가 알려진 문제가 발생하거나 의도하지 않은 결과가 발생하지 않도록 보호합니다.
성공적인 업데이트를 위해 OSUS에서 권장하는 업데이트 대상만 선택합니다.
2.1.5.2. 클러스터의 모든 심각한 경고 해결
중요한 경고는 항상 가능한 한 빨리 처리해야 하지만 클러스터 업데이트를 시작하기 전에 이러한 경고를 해결하고 문제를 해결하는 것이 특히 중요합니다. 업데이트를 시작하기 전에 중요한 경고를 해결하지 못하면 클러스터에 문제가 발생할 수 있습니다.
웹 콘솔의 관리자 화면에서 모니터링
2.1.5.3. 클러스터가 Upgradable 상태인지 확인합니다.
하나 이상의 Operator에서 업그레이드 가능
조건을 1시간 이상 True
로 보고하지 않으면 클러스터에서 ClusterNotUpgradeable
경고 경고가 트리거됩니다. 대부분의 경우 이 경고는 패치 업데이트를 차단하지 않지만 이 경고를 해결하고 모든 Operator에서 Upgradeable
을 True
로 보고할 때까지 마이너 버전 업데이트를 수행할 수 없습니다.
Upgradeable
조건에 대한 자세한 내용은 추가 리소스 섹션의 "클러스터 Operator 상태 유형 이해"를 참조하십시오.
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
사양의 구성된 값에 따라 사용 가능한 노드가 있는 경우 클러스터에서 머신 구성 변경 사항을 노드에 적용하지 못할 수 있습니다. 또한 컴퓨팅 노드에 여유 용량이 충분하지 않으면 첫 번째 노드가 오프라인 상태로 전환되는 동안 워크로드를 일시적으로 다른 노드로 전환하지 못할 수 있습니다.
노드 업데이트 가능성을 늘리려면 각 작업자 풀에 사용 가능한 노드와 컴퓨팅 노드에 충분한 예비 용량이 있는지 확인합니다.
maxUnavailable
의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1
입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3
으로 변경하지 마십시오.
2.1.5.5. 클러스터의 PodDisruptionBudget이 올바르게 구성되었는지 확인합니다.
PodDisruptionBudget
오브젝트를 사용하여 언제든지 사용할 수 있어야 하는 최소 Pod 복제본 수 또는 백분율을 정의할 수 있습니다. 이 구성은 클러스터 업데이트와 같은 유지 관리 작업 중에 워크로드가 중단되지 않도록 보호합니다.
그러나 클러스터 업데이트 중에 노드가 드레이닝 및 업데이트되지 않도록 지정된 토폴로지에 대해 PodDisruptionBudget
을 구성할 수 있습니다.
클러스터 업데이트를 계획할 때 다음 요인에 대해 PodDisruptionBudget
오브젝트의 구성을 확인합니다.
-
고가용성 워크로드의 경우
PodDisruptionBudget
에서 금지하지 않고 일시적으로 오프라인으로 전환할 수 있는 복제본이 있는지 확인합니다. -
고가용성이 아닌 워크로드의 경우
PodDisruptionBudget
에 의해 보호되지 않았는지 확인하거나 정기적인 재시작 또는 보장된 최종 종료와 같이 이러한 워크로드를 드레이닝하기 위한 몇 가지 대체 메커니즘이 있는지 확인하십시오.
추가 리소스