TKG 서비스 클러스터는 롤링 업데이트 모델을 지원합니다. 클러스터 규격을 변경하여 롤링 업데이트를 시작할 수 있습니다. 일부 시스템 작업은 롤링 업데이트를 시작할 수 있습니다. 환경을 업데이트하기 전에 롤링 업데이트 프로세스를 숙지해야 합니다.
TKG 서비스 3.0 이후 TKGS 클러스터를 위한 롤링 업데이트 모델
TKG 서비스 3.0 버전부터 TKG 컨트롤러는 vCenter Server 및 감독자와 독립적입니다. TKG 서비스 사용의 내용을 참조하십시오. 이러한 구성 요소를 업그레이드해도 TKGS 클러스터의 롤링 업데이트가 시작되지는 않습니다.
TKG 서비스 버전을 업그레이드하면 TKGS 클러스터의 롤링 업데이트가 트리거될 수 있습니다.
TKG 서비스 3.0 이전 TKGS 클러스터를 위한 롤링 업데이트 모델
TKG 컨트롤러는 감독자에서 실행됩니다. 감독자를 업데이트하면 TKG 컨트롤러가 자동으로 업데이트됩니다(업데이트를 사용할 수 있는 경우). 각 TKG 컨트롤러 업데이트에는 지원 서비스(예: CNI, CSI, CPI)에 대한 업데이트와 클러스터에 대한 구성 업데이트가 포함될 수 있습니다. 호환성을 지원하기 위해 시스템은 사전 검사를 수행하고 규정 준수를 적용합니다.
vSphere IaaS control plane는 롤링 업데이트 모델을 사용하여 감독자에서 TKG 클러스터를 업데이트합니다. 롤링 업데이트 모델은 클러스터 업데이트 프로세스 중에 다운타임이 최소화되도록 합니다. 롤링 업데이트에는 Kubernetes 소프트웨어 버전 및 클러스터를 지원하는 인프라 및 서비스(예: 가상 시스템 구성 및 리소스, 서비스 및 네임스페이스, 사용자 지정 리소스) 업그레이드가 포함됩니다. 업데이트가 성공하려면 구성이 몇 가지 호환성 요구 사항을 충족해야 합니다. 그래야 시스템이 재확인 조건을 적용하여 클러스터가 업데이트될 준비가 되었는지 확인하고 클러스터 업그레이드가 실패할 경우 롤백을 지원할 수 있습니다.
클러스터 매니페스트의 특정 측면을 변경하여 TKG 클러스터의 롤링 업데이트를 시작할 수 있습니다. 롤링 클러스터 업데이트는 시스템에 의해 시작될 수도 있습니다. 예를 들어 vSphere 네임스페이스 업데이트가 수행되면 시스템은 업데이트된 구성을 모든 워크로드 클러스터에 즉시 전파합니다. 이러한 업데이트는 클러스터 노드의 롤링 업데이트를 트리거할 수 있습니다. 또한 구성 요소를 변경하여 롤링 업데이트를 시작할 수도 있습니다. 예를 들어, 배포 버전에 해당하는 VirtualMachineImage을 교체하거나 이름을 변경하면, 시스템이 새 이미지에서 실행되는 모든 노드를 가져오려고 하면서 롤링 업데이트가 시작됩니다. 또한, 감독자를 업데이트하면 여기에 배포된 워크로드 클러스터의 롤링 업데이트가 트리거될 가능성이 높습니다. 예를 들어, vmware-system-tkg-controller-manager가 업데이트되면 새 값을 시스템이 매니페스트 생성기에 도입하고 이 값을 배포하기 위해 컨트롤러가 롤링 업데이트를 시작합니다.
클러스터 노드를 교체하는 롤링 업데이트 프로세스는 Kubernetes 배포의 포드에 대한 롤링 업데이트와 비슷합니다. 워크로드 클러스터의 롤링 업데이트를 수행하는 두 가지 개별 컨트롤러가 있습니다. 추가 기능 컨트롤러와 클러스터 컨트롤러입니다. 두 가지 컨트롤러 내에는 롤링 업데이트에 대한 세 가지 주요 단계인 추가 기능 업데이트, 제어부 업데이트 및 작업자 노드 업데이트 단계가 있습니다. 이러한 단계는 순서 대로 진행되며, 이전 단계가 충분히 진행될 때까지 단계를 시작하지 못하게 하는 사전 확인 기능이 있습니다. 이러한 단계가 불필요한 것으로 확인되면 건너뛸 수 있습니다. 예를 들어 업데이트가 작업자 노드에만 영향을 주기 때문에 추가 기능 또는 제어부 업데이트가 필요하지 않을 수 있습니다.
업데이트 프로세스 중에 시스템은 새 클러스터 노드를 추가하고 노드가 대상 Kubernetes 버전으로 온라인 상태가 될 때까지 기다립니다. 그런 다음, 시스템은 이전 노드를 삭제하도록 표시하고 다음 노드로 이동하여 프로세스를 반복합니다. 이전 노드는 모든 포드가 제거될 때까지 삭제되지 않습니다. 예를 들어, 노드가 완전히 드레이닝되는 것을 방지하는 PodDisruptionBudgets를 사용하여 포드를 정의하면 노드가 차단되지만 해당 포드를 제거할 때까지 제거되지 않습니다. 시스템은 모든 제어부 노드를 먼저 업그레이드한 후 작업자 노드를 업그레이드합니다. 업데이트하는 동안 클러스터 상태가 "업데이트 중"으로 변경됩니다. 롤링 업데이트 프로세스가 완료되면 클러스터 상태가 "실행 중"으로 변경됩니다.
복제 컨트롤러가 관리하지 않는 클러스터에서 실행되는 포드는 클러스터 업데이트 동안 작업자 노드 드레이닝의 일부로 Kubernetes 버전 업그레이드 중에 삭제됩니다. 이는 클러스터 업데이트가 vSphere 네임스페이스 또는 감독자 업데이트를 통해 수동으로 또는 자동으로 트리거되는 경우에 적용됩니다. 복제 컨트롤러에서 관리되지 않는 포드에는 배포 또는 ReplicaSet 규격의 일부로 생성되지 않는 포드가 포함됩니다. 자세한 내용은 Kubernetes 설명서에서 포드 수명 주기: 포드 수명을 참조하십시오.
사용자 시작 롤링 업데이트
시스템 시작 롤링 업데이트
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vspheremachinetemplate/vspheremachine(vSphere 8.x용)
- wcpmachinetemplate/wcpmachine(vSphere 7.x용)
vSphere IaaS control plane에서는 감독자에서 실행되는 TKG 컨트롤러가 이러한 개체를 생성하고 시스템 코드와 동기화된 상태로 유지합니다. 즉, 컨트롤러가 최신 코드로 업데이트될 때 위의 개체 중 하나가 변경되면 기존 TKG 클러스터의 롤링 업데이트를 유발합니다. 요컨대, 감독자에 영향을 미치는 시스템 코드 변경으로 인해 TKG 클러스터의 롤링 업데이트가 발생합니다.
| 업그레이드 시나리오 | 설명 |
|---|---|
| vCenter Server 7.x 릴리스에서 vCenter Server 릴리스로 업그레이드 | 모든 Tanzu Kubernetes 클러스터의 롤링 업데이트를 트리거할 수 있습니다. 롤링 업데이트는 vCenter Server 업그레이드 후 감독자를 처음 업그레이드하면 트리거됩니다. 롤링 업데이트는 일반적으로 동일한 vCenter Server에서 감독자를 업그레이드해도 트리거되지 않습니다. 구체적인 세부 내용은 릴리스 정보를 참조하십시오. |
| vCenter Server 릴리스에서 vCenter Server 8.x 릴리스로 업그레이드 | 다음 코드 변경 사항을 전파해야 하기 때문에 모든 TKG 클러스터의 롤링 업데이트가 트리거됩니다.
|
| vCenter Server 8.0 GA 릴리스(8.0.0)에서 vCenter Server 8.0.0b 또는 8.0.0c 릴리스로 업그레이드 | 다음 경우 중 하나라도 해당되는 경우 지정된 TKG 클러스터의 롤링 업데이트가 트리거됩니다.
|
| vSphere 8.0.0b 릴리스에서 vSphere 8.0.0c 릴리스로 업그레이드 | 워크로드 클러스터의 자동 롤아웃 없음 |
| vSphere 8.0.0c 릴리스에서 vSphere 8.0 업데이트 1 릴리스(8.0.1)로 업그레이드 | 워크로드 클러스터의 자동 롤아웃 없음 |
| vSphere 8.x 버전에서 8.0 U2 릴리스(8.0.2)로 업그레이드 | 다음 변경이 필요하므로 모든 TKC에 대한 롤링 업그레이드가 발생합니다.
|
| 8.0 U2(8.0.2) 미만의 모든 vSphere 8.x 버전에서 8.0 U2c 릴리스로 업그레이드 | 다음 변경이 필요하므로 모든 TKC에 대한 롤링 업그레이드가 발생합니다.
|
예를 들어 시스템 정의 OVA 이름을 자동으로 사용하는 구독 컨텐츠 라이브러리를 사용하는 시나리오를 고려해 봅니다. 그런 다음 로컬 컨텐츠 라이브러리로 전환하고 동일한 OVA로 채우지만 다른 이름을 지정합니다. 이렇게 하면 모든 TKG 클러스터의 롤링 업데이트가 트리거됩니다. 교체 콘텐츠 라이브러리의 OVA는 동일하지만 사용자 정의 이름이 다르기 때문입니다.
여러 노드 풀이 있는 클러스터의 롤링 업데이트 고려 사항
- 작업자 노드 풀
-
작업자 노드 풀은 vSphere 7 U3와 함께 릴리스된 TKGS v1alpha2 API를 통해 도입되었습니다. 클러스터 API MachineDeployments는 작업자 노드 풀의 기본 Kubernetes입니다.
ClusterClass는 TKGS의 vSphere 8 릴리스에서 도입되었습니다. v1alpha3와 v1beta1 API는 모두 ClusterClass를 기반으로 합니다. (v1alpha3는 ClusterClass 위에 있는 추상화 계층입니다.)
- 롤링 업데이트 중에 여러 노드 풀이 업데이트되는 방법
-
여러 노드 풀로 프로비저닝된 TKGS 워크로드 클러스터를 업데이트하는 경우 롤링 업데이트 모델은 사용 중인 vSphere 버전에 따라 달라집니다.
vSphere TKGS API 업그레이드 동작 vSphere 7 TKGS v1alpha2 API 동일한 클러스터 내의 여러 노드 풀이 한 번에 업데이트됨(동시에) vSphere 8 TKGS v1alpha3 API 및 v1beta1 API 동일한 클러스터 내의 여러 노드 풀이 논리적 순서에 따라 업데이트됨(순차적)
- 모범 사레 고려 사항
-
동일한 노드 풀이 여러 개 있는 vSphere 8 TKGS 클러스터를 프로비저닝하는 것은 크기 조정 측면에서 아무런 의미가 없습니다. 노드 풀은 서로 다른 크기, VM 클래스, TKr 버전 등에 사용해야 합니다. 동일한 노드 풀을 여러 개 사용하여 편법을 써서 클러스터를 더 빨리 업그레이드하는 것은 작동하지 않으므로 피하십시오.
포드 중단 예산은 업그레이드가 애플리케이션 실행을 방해하지 않도록 하는 적절한 방법입니다. 이 작업을 처리하는 가장 좋은 방법은 워크로드에 PodDisruptionBudgets를 설정하는 것입니다(https://kubernetes.io/docs/tasks/run-application/configure-pdb/ 참조). 클러스터 API는 이러한 항목을 준수하며 임계값을 초과할 경우 시스템을 종료하지 않습니다.
