7장. OpenShift Virtualization 업데이트
OLM(Operator Lifecycle Manager)에서 OpenShift Virtualization에 z-stream 및 마이너 버전 업데이트를 제공하는 방법을 알아봅니다.
Node Maintenance Operator (NMO)는 더 이상 OpenShift Virtualization과 함께 제공되지 않습니다. OpenShift Container Platform 웹 콘솔의 OperatorHub 에서 NMO를 설치하거나 OpenShift CLI(
oc
)를 사용하여 설치할 수 있습니다. 노드 수정, 펜싱 및 유지 관리에 대한 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.OpenShift Virtualization 4.10.2 이상 릴리스에서 OpenShift Virtualization 4.11로 업데이트하기 전에 다음 작업 중 하나를 수행해야 합니다.
- 모든 노드를 유지보수 모드에서 이동합니다.
-
독립 실행형 NMO를 설치하고
nodemaintenances.nodemaintenance.kubevirt.io
CR(사용자 정의 리소스)을nodemaintenances.nodemaintenance.medik8s.io
CR로 교체합니다.
7.1. OpenShift Virtualization 업데이트 정보
- OLM(Operator Lifecycle Manager)은 OpenShift Virtualization Operator의 라이프사이클을 관리합니다. OpenShift Container Platform 설치 중에 배포되는 Marketplace Operator는 클러스터에서 외부 Operator를 사용할 수 있도록 합니다.
- OLM은 OpenShift Virtualization에 z-stream 및 마이너 버전 업데이트를 제공합니다. OpenShift Container Platform을 다음 마이너 버전으로 업데이트할 때 마이너 버전 업데이트가 제공됩니다. OpenShift Container Platform을 먼저 업데이트하지 않고 OpenShift Virtualization을 다음 마이너 버전으로 업데이트할 수 없습니다.
- OpenShift Virtualization 서브스크립션은 stable 이라는 단일 업데이트 채널을 사용합니다. stable 채널을 사용하면 OpenShift Virtualization 및 OpenShift Container Platform 버전이 호환됩니다.
서브스크립션의 승인 전략이 자동으로 설정되어 있으면 stable 채널에서 새 버전의 Operator를 사용할 수 있는 즉시 업데이트 프로세스가 시작됩니다. 자동 승인 전략을 사용하여 지원 가능한 환경을 유지하는 것이 좋습니다. OpenShift Virtualization의 각 부 버전은 해당 OpenShift Container Platform 버전을 실행하는 경우에만 지원됩니다. 예를 들어 OpenShift Container Platform 4.12에서 OpenShift Virtualization 4.12를 실행해야 합니다.
- 수동 승인 전략을 선택할 수 있지만 클러스터의 지원 가능성과 기능에 미칠 위험이 높기 때문에 이 방법은 권장되지 않는 것이 좋습니다. 수동 승인 전략을 사용하면 보류 중인 모든 업데이트를 수동으로 승인해야 합니다. OpenShift Container Platform 및 OpenShift Virtualization 업데이트가 동기화되지 않으면 클러스터가 지원되지 않습니다.
- 업데이트를 완료하는 데 걸리는 시간은 네트워크 연결에 따라 달라집니다. 대부분의 자동 업데이트는 15분 이내에 완료됩니다.
- OpenShift Virtualization을 업데이트하면 네트워크 연결이 중단되지 않습니다.
- 데이터 볼륨 및 관련 영구 볼륨 클레임은 업데이트 중에 보존됩니다.
hostpath 프로비전 프로그램을 사용하는 가상 머신이 실행 중인 경우 실시간으로 마이그레이션할 수 없으며 OpenShift Container Platform 클러스터 업데이트가 차단될 수 있습니다.
해결 방법으로 클러스터를 업데이트하는 동안 전원이 자동으로 꺼지도록 가상 머신을 재구성할 수 있습니다. evictionStrategy: LiveMigrate
필드를 제거하고 runStrategy
필드를 Always
로 설정합니다.
7.1.1. 워크로드 업데이트 정보
OpenShift Virtualization을 업데이트하면 libvirt
,virt-launcher
, qemu
를 포함한 가상 머신 워크로드가 실시간 마이그레이션을 지원하는 경우 자동으로 업데이트됩니다.
각 가상 머신에는 VMI(가상 머신 인스턴스)를 실행하는 virt-launcher
Pod가 있습니다. virt-launcher
Pod는 가상 머신(VM) 프로세스를 관리하는 데 사용되는 libvirt
인스턴스를 실행합니다.
HyperConverged CR
(사용자 정의 리소스)의 spec.workloadUpdateStrategy
스탠자를 편집하여 워크로드가 업데이트되는 방법을 구성할 수 있습니다. LiveMigrate
및 Evict
의 두 가지 사용 가능한 워크로드 업데이트 방법이 있습니다.
Evict
방법이 VMI Pod를 종료하므로 LiveMigrate
업데이트 전략만 기본적으로 활성화됩니다.
LiveMigrate
가 활성화된 유일한 업데이트 전략인 경우:
- 실시간 마이그레이션을 지원하는 VMI가 업데이트 프로세스 중에 마이그레이션됩니다. VM 게스트는 업데이트된 구성 요소가 활성화된 새 Pod로 이동합니다.
실시간 마이그레이션을 지원하지 않는 VMI는 중단되거나 업데이트되지 않습니다.
-
VMI에
LiveMigrate
제거 전략이 있지만 실시간 마이그레이션을 지원하지 않는 경우 업데이트되지 않습니다.
-
VMI에
LiveMigrate
및 Evict
를 모두 사용할 수 있는 경우:
-
실시간 마이그레이션을 지원하는 VMI는
LiveMigrate
업데이트 전략을 사용합니다. -
실시간 마이그레이션을 지원하지 않는 VMI는
Evict
업데이트 전략을 사용합니다. VMI가항상
runStrategy
값이 있는VirtualMachine
오브젝트에 의해 제어되는 경우 업데이트된 구성 요소가 있는 새 Pod에 새 VMI가 생성됩니다.
마이그레이션 시도 및 타임아웃
워크로드를 업데이트할 때 Pod가 다음 기간 동안 Pending
상태인 경우 실시간 마이그레이션이 실패합니다.
- 5분
-
Pod가 보류 중이므로
Unschedul을 사용할 수 있습니다
. - 15분
- 어떤 이유로든 Pod가 보류 중 상태에 있는 경우
VMI가 마이그레이션되지 않으면 virt-controller
에서 다시 마이그레이션하려고 합니다. 이 프로세스는 모든 migratable VMI가 새 virt-launcher
Pod에서 실행될 때까지 이 프로세스를 반복합니다. 그러나 VMI가 부적절하게 구성된 경우 이러한 시도는 무기한 반복할 수 있습니다.
각 시도는 마이그레이션 오브젝트에 해당합니다. 최근 5개의 시도만 버퍼에 저장됩니다. 이렇게 하면 디버깅을 위한 정보를 유지하면서 마이그레이션 오브젝트가 시스템에서 누적되는 것을 방지할 수 있습니다.
7.1.2. EUS-to-EUS 업데이트 정보
4.10 및 4.12를 포함한 OpenShift Container Platform의 모든 짝수 마이너 버전은 EUS (Extended Update Support) 버전입니다. 그러나 Kubernetes 설계에는 직렬 마이너 버전 업데이트가 필요하므로 하나의 EUS 버전에서 다음 버전으로 직접 업데이트할 수 없습니다.
소스 EUS 버전에서 다음 홀수의 마이너 버전으로 업데이트한 후 업데이트 경로에 있는 해당 마이너 버전의 모든 z-stream 릴리스로 OpenShift Virtualization을 순차적으로 업데이트해야 합니다. 해당 최신 z-stream 버전으로 업그레이드한 후 OpenShift Container Platform을 대상 EUS 마이너 버전으로 업데이트할 수 있습니다.
OpenShift Container Platform 업데이트가 성공하면 OpenShift Virtualization에 대한 해당 업데이트를 사용할 수 있습니다. 이제 OpenShift Virtualization을 대상 EUS 버전으로 업데이트할 수 있습니다.
7.1.2.1. 업데이트 준비
EUS-to-EUS 업데이트를 시작하기 전에 다음을 수행해야 합니다.
- EUS-to-EUS 업데이트를 시작하기 전에 작업자 노드의 머신 구성 풀을 일시 중지하여 작업자가 두 번 재부팅되지 않도록 합니다.
- 업데이트 프로세스를 시작하기 전에 자동 워크로드 업데이트를 비활성화합니다. 이는 대상 EUS 버전으로 업데이트할 때까지 OpenShift Virtualization이 VM(가상 머신)을 마이그레이션하거나 제거하지 않도록하기 위한 것입니다.
기본적으로 OpenShift Virtualization은 OpenShift Virtualization Operator를 업데이트할 때 virt-launcher
Pod와 같은 워크로드를 자동으로 업데이트합니다. HyperConverged
사용자 정의 리소스의 spec.workloadUpdateStrategy
스탠자에서 이 동작을 구성할 수 있습니다.
EUS에서 EUS로의 업데이트 수행 준비에 대해 자세히 알아보십시오.