이제 VMware용 Anthos 클러스터는 VMware용 Google Distributed Cloud(소프트웨어 전용)입니다. 자세한 내용은 제품 개요를 참조하세요.

권장 기능으로 클러스터 마이그레이션 계획

개요

Google Distributed Cloud는 Kubernetes 및 기타 여러 관련 기술을 기반으로 하며, 이러한 기술은 확장성, 성능, 보안, 통합 기능을 개선하기 위해 지속적으로 업데이트되고 개선되고 있습니다. 따라서 Google Distributed Cloud는 지속적으로 조정 및 개선되고 있습니다.

버전 1.30에서 변경사항 및 업데이트는 상당히 개선된 기능을 활용하기 위해 기존 배포를 마이그레이션할 것을 적극 권장합니다. 이 페이지에서는 오래된 기능에서 최신 권장 기능으로 마이그레이션하는 이점에 대해 설명합니다.

각 기능 영역에 대해 선택할 수 있는 옵션은 다음과 같습니다.

기능 영역	추천 옵션	기존 옵션
컨테이너 네트워크 인터페이스(CNI)	Dataplane V2 (`enableDataplaneV2: true`)	Dataplane V1(Calico) (`enableDataplaneV2: false`)
부하 분산기	`ManualLB`(F5 Big IP 에이전트와 호환됨) (`loadBalancer.kind: "ManualLB"`) MetalLB (`loadBalancer.kind: "MetalLB"`)	통합 F5 Big IP¹ (`loadBalancer.kind: "F5BigIP"`) Seesaw (`loadBalancer.kind: "Seesaw"`)
관리자 클러스터 컨트롤 플레인	고가용성(HA) 관리자 클러스터 (`adminMaster.replicas: 3`)	비HA 관리자 클러스터 (`adminMaster.replicas: 1`)
사용자 클러스터 컨트롤 플레인	Controlplane V2 (`enableControlplaneV2: true`)	Kubeception 사용자 클러스터 (`enableControlplaneV2: false`)

^{1 통합 F5 BIG-IP는 클러스터 구성 파일의 loadBalancer.f5BigIP 섹션에 있는 loadBalancer.kind: "F5BigIP" 및 관련 설정을 나타냅니다.}

다음 표에는 관리자 클러스터와 사용자 클러스터에서 이러한 기능에 대한 지원 매트릭스가 나와 있습니다.

클러스터 유형	오래된 기능	새 클러스터에 추가	클러스터 업그레이드 허용	새 기능으로 마이그레이션
버전 1.30
관리자	비HA	아니요	예	예
	Seesaw	아니요	예	예
	통합 F5 Big IP	아니요	예	예
사용자	Kubeception	아니요	예	예
	Seesaw	아니요	예	예
	통합 F5 Big IP	아니요	예	예
	Dataplane V1	아니요	예	예
버전 1.29
관리자	비HA	아니요	예	예(프리뷰)
	Seesaw	아니요	예	예
	통합 F5 Big IP	예	예	예(프리뷰)
사용자	Kubeception	예	예	예(프리뷰)
	Seesaw	예	예	예
	통합 F5 Big IP	예	예	예(프리뷰)
	Dataplane V1	예	예	아니요
버전 1.28
관리자	비HA	아니요	예	아니요
	Seesaw	아니요	예	예
	통합 F5 Big IP	예	예	아니요
사용자	Kubeception	예	예	아니요
	Seesaw	예	예	예
	통합 F5 Big IP	예	예	아니요
	Dataplane V1	예	예	아니요

핵심 사항:

버전 1.30부터는 모든 마이그레이션 솔루션을 사용하여 권장 옵션으로 클러스터를 마이그레이션할 수 있습니다.
새 클러스터를 만들 때 원래 기능이 허용되지 않는 버전은 다음과 같습니다.
- 관리자 클러스터:
  - 비HA 컨트롤 플레인: 1.28 이상
  - Seesaw 부하 분산: 1.28 이상
  - 통합 F5 Big IP: 1.30 이상
- 사용자 클러스터:
  - Kubeception: 1.30 이상
  - Seesaw: 1.30 이상
  - 통합 F5 Big IP: 1.30 이상
  - Dataplane V1: 1.30 이상
기존 기능으로 기존 클러스터를 업그레이드할 수는 있습니다.

사용자 클러스터를 Dataplane V2로 마이그레이션

컨테이너 네트워킹 기능을 제공하는 컨테이너 네트워크 인터페이스(CNI)인 Calico 또는 Dataplane V2를 선택할 수 있습니다. Google의 CNI 구현인 Dataplane V2는 Cilium을 기반으로 하며 Google Kubernetes Engine(GKE)과 Google Distributed Cloud에서 모두 사용됩니다.

Dataplane V2는 최적화된 설계와 효율적인 리소스 사용을 제공하므로 특히 네트워크 트래픽 수요가 많은 대규모 클러스터 또는 환경에서 네트워크 성능과 확장성을 개선할 수 있습니다. 최신 기능, 네트워킹 혁신, 기능을 사용하려면 클러스터를 Dataplane V2로 마이그레이션하는 것이 좋습니다.

버전 1.30부터는 Dataplane V2가 새 클러스터를 만들기 위한 유일한 CNI 옵션입니다.

Calico에서 Dataplane V2로 전환하려면 계획과 조정이 필요하지만 기존 워크로드에 대한 다운타임이 없도록 설계되었습니다. Dataplane V2로 사전에 마이그레이션하면 다음과 같은 이점이 있습니다.

향상된 성능 및 확장성: Dataplane V2의 최적화된 설계와 효율적인 리소스 사용을 제공하므로 특히 네트워크 트래픽 수요가 많은 대규모 클러스터 또는 환경에서 네트워크 성능과 확장성을 개선할 수 있습니다. 이는 BPF 맵을 사용하여 클러스터를 확장할 수 있는 IPTables 대신 EBPF를 사용하기 때문입니다.
간소화된 관리 및 지원: Google Distributed Cloud와 GKE 전반에서 Dataplane V2를 표준화하면 일관된 도구 및 문서 집합을 사용할 수 있으므로 클러스터 관리 및 문제 해결을 간소화할 수 있습니다.
고급 네트워킹 기능: EgressNAT 및 기타 고급 네트워킹 기능은 Dataplane V2에서만 지원됩니다. 향후 네트워킹 요청은 Dataplane V2 레이어에서 구현됩니다.

	마이그레이션 전	이전 후
kube-proxy	필수이며 자동으로 배포됨	필수가 아니며 배포되지 않음
라우팅	kube-proxy + iptables	eBPF

부하 분산기 유형 마이그레이션

권장되는 부하 분산기 유형(loadBalancer.kind)은 "ManualLB" 및 "MetalLB"입니다. F5 BIG-IP 또는 Citrix와 같은 서드 파티 부하 분산기가 있는 경우 "ManualLB"를 사용합니다. MetalLB 부하 분산기를 사용하는 번들 부하 분산 솔루션에는 "MetalLB"를 사용하세요.

버전 1.30부터는 새 클러스터를 만들 수 있는 유일한 옵션입니다. 통합 F5 Big IP 또는 번들 Seesaw 부하 분산기를 사용하는 기존 클러스터의 경우 "F5BigIP" 구성 설정을 "ManualLB"로 마이그레이션하고 번들 Seesaw 부하 분산기를 Seesaw에서 MetalLB로 마이그레이션할 수 있도록 마이그레이션 가이드가 제공됩니다.

F5 BIG-IP 부하 분산기의 구성 설정 마이그레이션

통합 F5 Big IP를 사용하는 클러스터를 ManualLB로 마이그레이션할 계획을 세웁니다. 통합 F5 Big IP는 다음 두 컨트롤러로 구성된 부하 분산기 에이전트와 함께 F5 BIG-IP를 사용합니다.

F5 컨트롤러(pod prefix: load-balancer-f5): LoadBalancer 유형의 Kubernetes 서비스를 F5 Common Controller Core Library(CCCL) ConfigMap 형식으로 조정합니다.
F5 BIG-IP CIS 컨트롤러 v1.14(pod prefix: k8s-bigip-ctlr-deployment): ConfigMap을 F5 부하 분산기 구성으로 변환합니다.

원래 통합 F5 Big IP에는 다음과 같은 제한사항이 있습니다.

제한된 표현력: 통합 F5 Big IP는 Service API의 표현력을 제한하여 F5 BIG-IP의 잠재력을 제한합니다. 이로 인해 특정 요구사항에 맞게 BIG-IP 컨트롤러를 구성하거나 애플리케이션에 중요한 고급 F5 기능을 활용하지 못할 수 있습니다.
기존 구성요소: 현재 구현에는 CCCL ConfigMap API 및 1.x CIS와 같은 이전 기술이 사용됩니다. 이러한 기존 구성요소는 F5 제품의 최신 기능과 호환되지 않을 수 있으며, 이로 인해 성능 개선 및 보안 강화 기회를 놓칠 수 있습니다.

통합 F5 BIG-IP에서 ManualLB로 마이그레이션한 후의 변경사항은 다음과 같습니다.

	마이그레이션 전	이전 후
F5 에이전트 구성요소	F5 컨트롤러 OSS CIS 컨트롤러	F5 컨트롤러(변동 없음) OSS CIS 컨트롤러(변동 없음)
F5 구성요소 버전 업그레이드	F5 구성요소를 업그레이드하려면 클러스터를 업그레이드해야 합니다. 사용 가능한 구성요소 버전은 앞에서 설명한 대로 제한적입니다.	필요에 따라 F5 구성요소 버전을 업그레이드할 수 있습니다.
서비스 생성	F5 에이전트가 처리	F5 에이전트가 처리(변동 없음)

Seesaw에서 MetalLB로 마이그레이션

MetalLB는 Seesaw에 비해 다음과 같은 이점을 제공합니다.

간소화된 관리 및 리소스 감소: Seesaw와 달리 MetalLB는 클러스터 노드에서 직접 실행되므로 부하 분산에 클러스터 리소스를 동적으로 사용할 수 있습니다.
자동 IP 할당: MetalLB 컨트롤러는 서비스의 IP 주소를 관리하므로 각 서비스의 IP 주소를 직접 선택할 필요가 없습니다.
LB 노드 간 부하 분산: 여러 서비스에 대한 MetalLB의 활성 인스턴스가 서로 다른 노드에서 실행될 수 있습니다.
향상된 기능 및 미래 경쟁력 확보: MetalLB의 활성 개발 및 광범위한 Kubernetes 생태계와의 통합은 Seesaw보다 미래 경쟁력이 있는 솔루션입니다. MetalLB를 사용하면 최신 부하 분산 기술을 활용할 수 있습니다.

	마이그레이션 전	이전 후
LB 노드	추가 Seesaw VM(클러스터 외부)	고객이 선택할 수 있는 클러스터 내 LB 노드
클라이언트 IP 보존	`externalTrafficPolicy: Local`을 통해 달성 가능	DataplaneV2 DSR 모드를 통해 달성 가능
서비스 생성	수동으로 지정된 서비스 IP	주소 풀에서 자동 할당된 서비스 IP

사용자 클러스터를 Controlplane V2로, 관리자 클러스터를 HA로 마이그레이션

사용자 클러스터에 권장되는 컨트롤 플레인은 Controlplane V2입니다. Controlplane V2를 사용하면 컨트롤 플레인이 사용자 클러스터 자체의 하나 이상의 노드에서 실행됩니다. kubeception이라고 하는 기존 컨트롤 플레인을 사용하면 사용자 클러스터의 컨트롤 플레인이 관리자 클러스터에서 실행됩니다. 고가용성(HA) 관리자 클러스터를 만들려면 사용자 클러스터에 Controlplane V2가 사용 설정되어 있어야 합니다.

버전 1.30부터 새 사용자 클러스터에는 Controlplane V2가 사용 설정되어야 하며 새 관리자 클러스터는 HA입니다. 기존 컨트롤 플레인을 사용하는 사용자 클러스터의 업그레이드와 비HA 관리자 클러스터의 업그레이드는 계속 지원됩니다.

사용자 클러스터를 Controlplane V2로 마이그레이션

이전에는 사용자 클러스터에서 kubeception을 사용했습니다. 버전 1.13에는 미리보기 기능으로 Controlplane V2가 도입되었으며 버전 1.14에서 정식 버전으로 전환되었습니다. 버전 1.15부터 Controlplane V2는 사용자 클러스터를 만들 때의 기본 옵션이었고 버전 1.30에서는 Controlplane V2가 유일한 옵션입니다.

kubeception과 비교하여 Controlplane V2의 이점은 다음과 같습니다.

아키텍처 일관성: 관리자 클러스터 및 사용자 클러스터는 동일한 아키텍처를 사용합니다.
오류 격리: 관리자 클러스터 오류가 사용자 클러스터에 영향을 주지 않습니다.
운영 분리: 관리자 클러스터 업그레이드는 사용자 클러스터에 대해 다운타임을 일으키지 않습니다.
배포 분리: 관리자 클러스터와 사용자 클러스터를 다른 토폴로지 도메인 또는 여러 위치에 배치할 수 있습니다. 예를 들어 에지 컴퓨팅 배포 모델에서 사용자 클러스터는 관리자 클러스터와 다른 위치에 있을 수 있습니다.

마이그레이션 중에는 기존 사용자 클러스터 워크로드에 다운타임이 발생하지 않습니다. 기본 vSphere 환경에 따라 Controlplane V2로 전환하는 동안 컨트롤 플레인에서 최소한의 다운타임이 발생합니다. 마이그레이션 프로세스는 다음을 수행합니다.

사용자 클러스터에 새 컨트롤 플레인을 만듭니다.
이전 컨트롤 플레인에서 etcd 데이터를 복사합니다.
기존 노드 풀 노드(워커 노드라고도 함)를 새 컨트롤 플레인으로 전환합니다.

	마이그레이션 전	이전 후
컨트롤 플레인 Kubernetes 노드 객체	관리자 클러스터 노드	사용자 클러스터 노드
Kubernetes 컨트롤 플레인 포드	관리자 클러스터 Statefulset/배포(사용자 클러스터 네임스페이스)	사용자 클러스터 정적 포드(kube-system 네임스페이스)
기타 컨트롤 플레인 포드	관리자 클러스터 Statefulset/배포(사용자 클러스터 네임스페이스)	사용자 클러스터 Statefulset/배포(kube-system 네임스페이스)
컨트롤 플레인 VIP	관리자 클러스터 부하 분산기 서비스	keepalived + haproxy(사용자 클러스터 정적 포드)
Etcd 데이터	관리자 클러스터 영구 볼륨	데이터 디스크
컨트롤 플레인 머신 IP 관리	IPAM 또는 DHCP	IPAM
컨트롤 플레인 네트워크	관리자 클러스터 VLAN	사용자 클러스터 VLAN

HA 관리자 클러스터로 마이그레이션

기존에는 관리자 클러스터가 단일 컨트롤 플레인 노드만 실행할 수 있었기 때문에 단일 장애점에 내재된 위험이 발생했습니다. 컨트롤 플레인 노드 1개 외에도 비HA 관리자 클러스터에는 부가기능 노드 2개가 있습니다. HA 관리자 클러스터에는 부가기능 노드가 없는 컨트롤 플레인 노드 3개가 있으므로 새 관리자 클러스터에 필요한 VM 수는 변경되지 않았지만 가용성이 크게 개선되었습니다. 버전 1.16부터는 버전 1.28에서 새 클러스터를 만들기 위한 유일한 옵션이 된 고가용성(HA) 관리자 클러스터를 사용할 수 있습니다.

HA 관리자 클러스터로 마이그레이션하면 다음과 같은 이점이 있습니다.

안정성 및 업타임 향상: HA 구성을 사용하면 단일 장애점이 제거되므로 컨트롤 플레인 노드 중 하나에 문제가 발생하더라도 관리자 클러스터가 계속 작동할 수 있습니다.
업그레이드 및 업데이트 환경 개선: 이제 관리자 클러스터를 업그레이드하고 업데이트하는 데 필요한 모든 단계가 별도의 관리 VM이 아닌 클러스터 내에서 실행됩니다. 이렇게 하면 관리 VM에 대한 초기 세션이 중단되더라도 업그레이드 및 업데이트가 계속됩니다.
클러스터 상태에 대한 신뢰할 수 있는 정보 소스: 비HA 관리자 클러스터는 대역 외 '체크포인트 파일'을 사용하여 관리자 클러스터 상태를 저장합니다. 반면에 HA 관리자 클러스터는 관리자 클러스터 자체 내에 최신 클러스터 상태를 저장하므로, 클러스터 상태에 대한 보다 신뢰할 수 있는 정보 소스를 제공합니다.

비HA 관리자 클러스터를 HA 관리자 클러스터로 마이그레이션할 수 있으며, 이 경우 사용자 워크로드의 다운타임이 발생하지 않습니다. 이 프로세스는 주로 컨트롤 플레인 전환과 연관된 최소한의 다운타임 및 기존 사용자 클러스터에 대한 중단을 일으킵니다. 마이그레이션 프로세스는 다음을 수행합니다.

새 HA 컨트롤 플레인을 만듭니다.
기존 비HA 클러스터에서 etcd 데이터를 복원합니다.
사용자 클러스터를 새 HA 관리자 클러스터로 전환합니다.

	마이그레이션 전	이전 후
컨트롤 플레인 노드 복제본	1	3
부가기능 노드	2	0
데이터 디스크 크기	100GB* 1	25GB* 3
데이터 디스크 경로	관리자 클러스터 구성 파일에서 vCenter.dataDisk로 설정	`/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk` 디렉터리에 자동 생성
컨트롤 플레인 VIP	관리자 클러스터 구성 파일에서 loadBalancer.kind로 설정	keepalived + haproxy
관리자 클러스터 컨트롤 플레인 노드의 IP 주소 할당	network.ipMode.type에 따라 DHCP 또는 정적	고정 IP 주소 3개

부하 분산기 및 컨트롤 플레인 마이그레이션 그룹화

일반적으로 클러스터를 업데이트할 때는 한 번에 하나의 기능 또는 설정만 업데이트하는 것이 좋습니다. 그러나 버전 1.30 이상에서는 부하 분산기와 컨트롤 플레인 모두의 마이그레이션 구성 변경사항을 그룹화한 후 클러스터를 한 번만 업데이트하여 두 가지 변경사항을 모두 적용할 수 있습니다.

이전 CNI를 사용하는 사용자 클러스터가 있는 경우 먼저 DataPlane V2로 마이그레이션해야 합니다. 그런 다음 부하 분산기와 컨트롤 플레인의 마이그레이션을 그룹화할 수 있습니다. 마이그레이션을 그룹화하면 다음과 같은 이점이 있습니다.

더 간단한 프로세스: 컨트롤 플레인과 부하 분산기를 모두 마이그레이션해야 하는 경우 일반적으로 클러스터를 한 번만 업데이트합니다. 먼저 마이그레이션해야 하는 기능을 결정할 필요도 없습니다.
전반적인 다운타임 감소: 특정 마이그레이션에는 컨트롤 플레인 다운타임이 포함되므로 이러한 마이그레이션을 하나의 업데이트 작업으로 그룹화하면 개별 업데이트를 순차적으로 실행하는 것보다 전반적인 다운타임이 줄어듭니다.

이 프로세스는 클러스터 구성에 따라 다릅니다. 전체적으로 각 클러스터의 마이그레이션을 다음 순서로 실행합니다.

권장 CNI인 Dataplane V2를 사용하도록 각 사용자 클러스터를 마이그레이션합니다.
1. 구성을 변경하고 사용자 클러스터를 업데이트하여 Calico에서 Dataplane V2로 사용자 클러스터의 마이그레이션을 트리거합니다.
  
  참고: 관리자 클러스터에는 이 단계가 필요하지 않습니다. 관리자 클러스터를 버전 1.30으로 업그레이드하면 클러스터가 Dataplane V2로 자동으로 마이그레이션됩니다.
각 사용자 클러스터를 마이그레이션하여 권장되는 부하 분산기와 Controlplane V2를 사용합니다.
1. 권장되는 부하 분산기(MetalLB 또는 ManualLB)를 사용하도록 구성을 변경합니다.
2. Controlplane V2를 사용 설정하도록 구성을 변경합니다.
3. 사용자 클러스터를 업데이트하여 부하 분산기와 컨트롤 플레인을 마이그레이션합니다.
권장되는 부하 분산기를 사용하고 컨트롤 플레인의 가용성을 높이기 위해 관리자 클러스터를 마이그레이션합니다.
1. 권장되는 부하 분산기(MetalLB 또는 ManualLB)를 사용하도록 구성을 변경합니다.
2. 구성을 변경하여 관리자 클러스터의 컨트롤 플레인을 비HA에서 HA로 마이그레이션합니다.
3. 관리자 클러스터를 업데이트하여 부하 분산기와 컨트롤 플레인을 마이그레이션합니다.
비HA가 아닌 컨트롤 플레인 VM을 삭제하는 등 선택적 정리 단계를 실행합니다.

관리자 클러스터와 모든 사용자 클러스터가 버전 1.30 이상인 경우 그룹 마이그레이션 프로세스를 사용할 수 있습니다. 자세한 단계는 다음을 참조하세요.