이 페이지에서는 VMware용 GKE의 고가용성(HA) 옵션을 설명하고 HA를 위한 특정 VMware용 GKE 구성요소를 설정하는 방법 및 재해에서 복구하는 방법을 설명합니다.
핵심 기능
VMware용 GKE에는 관리자 클러스터와 하나 이상의 사용자 클러스터가 포함됩니다.
관리 클러스터는 사용자 클러스터 만들기, 업데이트, 업그레이드, 삭제를 포함하여 사용자 클러스터의 수명 주기를 관리합니다. 관리 클러스터에서 관리 마스터는 사용자 마스터(관리형 사용자 클러스터의 제어 영역을 실행하는 노드) 및 부가기능 노드(관리 클러스터의 기능을 지원하는 부가기능 구성요소를 실행하는 노드)를 포함하는 관리 워커 노드를 관리합니다.
각 사용자 클러스터의 관리자 클러스터에는 비 HA 노드 1개 또는 제어 영역을 실행하는 HA 노드 3개가 있습니다. 제어 영역에는 Kubernetes API 서버, Kubernetes 스케줄러, Kubernetes 컨트롤러 관리자 및 사용자 클러스터의 몇 가지 주요 컨트롤러가 포함됩니다.
사용자 클러스터의 제어 영역 기능은 워크로드 만들기, 확장 및 축소, 종료와 같은 워크로드 작업에 중요합니다. 즉, 제어 영역이 실행 중인 워크로드와 간섭되지 않지만 제어 영역이 없으면 기존 워크로드에서 Kubernetes API 서버의 관리 기능이 손실됩니다.
컨테이너화된 워크로드 및 서비스는 사용자 클러스터 워커 노드에 배포됩니다. 모든 단일 워커 노드는 애플리케이션이 여러 워커 노드 간에 예약된 중복 포드로 배포되는 한 애플리케이션 가용성에 중요하지 않습니다.
VMware용 GKE는 장애를 가능한 한 기능 영역에 격리하고 비즈니스 연속성에 필수적인 기능을 우선시하도록 설계되었습니다.
VMware용 GKE의 핵심 기능에는 다음 카테고리가 포함됩니다.
애플리케이션 수명 주기
기존 워크로드는 지속적으로 실행될 수 있습니다. 이는 비즈니스 연속성을 보장하는 데 가장 중요한 기능입니다.
워크로드를 생성, 업데이트, 삭제할 수 있습니다. 이는 VMware용 GKE는 트래픽이 증가할 때 워크로드를 확장해야 하기 때문에 두 번째로 중요한 기능입니다.
사용자 클러스터 수명 주기
사용자 클러스터를 추가, 업데이트, 업그레이드, 삭제할 수 있습니다. 이는 사용자 클러스터를 수정할 수 없는 것은 사용자 워크로드에 영향을 미치지 않으므로 덜 중요합니다.
관리자 클러스터 수명 주기
관리자 클러스터를 업데이트하고 업그레이드할 수 있습니다. 이는 관리자 클러스터가 사용자 워크로드를 호스팅하지 않으므로 가장 덜 중요합니다.
오류 모드
다음 유형의 오류가 VMware용 GKE 클러스터의 성능에 영향을 줄 수 있습니다.
ESXi 호스트 오류
Kubernetes 노드를 호스팅하는 가상 머신(VM) 인스턴스를 실행하는 ESXi 호스트가 작동을 중단되거나 네트워크가 파티셔닝될 수 있습니다.
| 기존 워크로드 | 워크로드 생성, 업데이트, 삭제 | 사용자 클러스터 수명 주기 | 관리자 클러스터 수명 주기 |
|---|---|---|---|
| 가능한 중단 + 자동 복구 |
가능한 중단 + 자동 복구 |
중단 + 자동 복구 |
중단 + 자동 복구 |
실패한 호스트에서 호스팅하는 VM에서 실행 중인 포드가 중단되고 다른 정상 VM에 자동으로 다시 예약됩니다. 사용자 애플리케이션에 여유 워크로드 용량이 있고 여러 노드에 분산되어 있는 경우 재시도를 구현하는 클라이언트는 이 중단을 파악할 수 없습니다. |
호스트 오류가 비HA 사용자 클러스터의 제어 영역 VM 또는 HA 사용자 클러스터에서 둘 이상의 제어 영역 VM에 영향을 미치는 경우 중단이 발생합니다. | 호스트 실패가 관리자 클러스터의 제어 영역 VM 또는 작업자 VM에 영향을 미치는 경우 중단이 발생합니다. | 호스트 장애가 관리자 클러스터의 제어 영역 VM에 영향을 미치는 경우 중단이 발생합니다. |
| vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. |
| HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. | HA 사용자 클러스터를 사용하여 중단 가능성을 최소화합니다. |
VM 오류
VM이 예기치 않게 삭제되거나 부팅 디스크가 손상될 수 있습니다. 또한 운영체제 문제로 인해 VM이 합성될 수 있습니다.
| 기존 워크로드 | 워크로드 생성, 업데이트, 삭제 | 사용자 클러스터 수명 주기 | 관리자 클러스터 수명 주기 |
|---|---|---|---|
| 가능한 중단 + 자동 복구 |
가능한 중단 + 자동 복구 |
중단 + 자동/수동 복구 |
중단 + 수동 복구 |
실패한 작업자 VM에서 실행 중인 포드가 중단되고 Kubernetes에 의해 다른 정상 VM에 자동으로 다시 예약됩니다. 사용자 애플리케이션에 여유 워크로드 용량이 있고 여러 노드에 분산되어 있는 경우 재시도를 구현하는 클라이언트는 이 중단을 파악할 수 없습니다. |
비HA 사용자 클러스터의 제어 영역 VM 또는 HA 사용자 클러스터의 두 개 이상의 제어 영역 VM이 실패하는 경우 중단이 발생합니다. | 관리자 클러스터의 제어 영역 VM 또는 작업자 VM이 실패하는 경우 중단이 발생합니다. | 관리자 클러스터의 제어 영역 VM이 실패하는 경우 중단이 발생합니다. |
| 실패한 VM은 사용자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. | 실패한 VM은 관리자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. | 관리자 클러스터에서 실패한 작업자 VM은 관리자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. 관리자 클러스터의 제어 영역 VM을 복구하려면 관리자 클러스터의 제어 영역 VM 복구를 참조하세요. |
관리자 클러스터의 제어 영역 VM을 복구하려면 관리자 클러스터의 제어 영역 VM 복구를 참조하세요. |
| HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. | HA 사용자 클러스터를 사용하여 중단 가능성을 최소화합니다. |
스토리지 오류
VM의 불미스러운 성능 저하로 인해 VMDK 파일의 콘텐츠가 손상되거나 Datastore 장애로 인해 etcd 데이터 및 PersistentVolumes(PV)가 손실될 수 있습니다.
etcd 오류
| 기존 워크로드 | 워크로드 생성, 업데이트, 삭제 | 사용자 클러스터 수명 주기 | 관리자 클러스터 수명 주기 |
|---|---|---|---|
| 중단 없음 | 가능한 중단 + 수동 복구 |
중단 + 수동 복구 |
중단 + 수동 복구 |
| 비HA 사용자 클러스터의 etcd 저장소 또는 HA 사용자 클러스터의 두 개 이상의 etcd 복제본이 실패하는 경우 중단이 발생합니다. | 비HA 사용자 클러스터의 etcd 저장소 또는 HA 사용자 클러스터의 두 개 이상의 etcd 복제본이 실패하는 경우 중단이 발생합니다. 관리자 클러스터의 etcd 복제본이 실패하는 경우 중단이 발생합니다. |
관리자 클러스터의 etcd 복제본이 실패하는 경우 중단이 발생합니다. | |
| VMware용 GKE는 오류를 복구하는 수동 프로세스를 제공합니다. | VMware용 GKE는 실패 복구를 위한 수동 프로세스를 제공합니다. | VMware용 GKE는 실패 복구를 위한 수동 프로세스를 제공합니다. |
사용자 애플리케이션 PV 오류
| 기존 워크로드 | 워크로드 생성, 업데이트, 삭제 | 사용자 클러스터 수명 주기 | 관리자 클러스터 수명 주기 |
|---|---|---|---|
| 가능한 중단 | 중단 없음 | 중단 없음 | 중단 없음 |
실패한 PV를 사용한 워크로드가 영향을 받습니다. HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. |
부하 분산기 오류
부하 분산기 오류는 LoadBalancer 유형의 서비스를 노출하는 사용자 워크로드에 영향을 줄 수 있습니다.
| 기존 워크로드 | 워크로드 생성, 업데이트, 삭제 | 사용자 클러스터 수명 주기 | 관리자 클러스터 수명 주기 |
|---|---|---|---|
| 중단 + 수동 복구 |
|||
|
대기 부하 분산기가 관리 제어 영역 VIP 연결을 복구할 때까지 몇 초간 중단됩니다. Seesaw를 사용하면 서비스가 최대 2초, F5를 사용할 경우 최대 300초 동안 서비스가 중단될 수 있습니다. MetalLB 의 장애 조치 중단 기간은 부하 분산기 노드 수가 증가함에 따라 증가합니다. 노드가 5개 미만이면 중단은 10초 이내입니다. Seesaw HA는 백업 인스턴스를 사용하는 장애 및 장애 조치를 자동으로 감지합니다. VMware용 GKE는 Seesaw의 오류를 복구하는 수동 프로세스를 제공합니다. |
|||
고가용성 사용 설정
vSphere와 VMware용 GKE는 고가용성(HA)에 기여하는 다양한 기능을 제공합니다.
vSphere HA 및 vMotion
VMware용 GKE 클러스터를 호스팅하는 vCenter 클러스터에서 다음 두 기능을 사용 설정하는 것이 좋습니다.
이러한 기능은 ESXi 호스트가 실패할 경우 가용성 및 복구를 향상시킵니다.
vCenter HA는 클러스터로 구성된 여러 ESXi 호스트를 사용하여 서비스 중단을 빠르게 복구하고 가상 머신에서 실행되는 애플리케이션에 대해 비용 효율적인 HA를 제공합니다. 추가 호스트를 사용하여 vCenter 클러스터를 프로비저닝하고 Host Failure Response를 Restart VMs로 설정하여 vSphere HA 호스트 모니터링을 사용 설정하는 것이 좋습니다. 그런 다음 ESXi 호스트 장애 발생 시 다른 사용 가능한 호스트에서 VM이 자동으로 다시 시작될 수 있습니다.
vMotion을 사용하면 한 ESXi 호스트에서 다른 호스트로 VM을 다운타임 없이 실시간 마이그레이션할 수 있습니다. 예정된 호스트 유지보수의 경우 vMotion 라이브 마이그레이션을 사용하여 애플리케이션 다운타임을 완전히 방지하고 비즈니스 연속성을 보장할 수 있습니다.
관리자 클러스터
VMware용 GKE는 고가용성(HA) 관리자 클러스터 만들기를 지원합니다. HA 관리자 클러스터에는 제어 영역 구성요소를 실행하는 3개의 노드가 있습니다. 요구사항 및 제한사항에 관한 자세한 내용은 고가용성 관리자 클러스터를 참조하세요.
관리자 클러스터 제어 영역을 사용할 수 없는 경우에도 기존 사용자 클러스터 기능이나 사용자 클러스터에서 실행되는 워크로드에는 아무런 영향이 없습니다.
관리자 클러스터에는 두 개의 부가기능 노드가 있습니다. 하나가 다운되어도 다른 클러스터는 관리자 클러스터 작업을 수행할 수 있습니다. VMware용 GKE는 중복화를 위해 kube-dns와 같은 중요한 부가기능 서비스를 두 부가기능 노드에 분산합니다.
관리자 클러스터 구성 파일에서 antiAffinityGroups.enabled를 true로 설정하면 VMware용 GKE는 부가기능 노드에 대한 vSphere DRS 안티-어피니티 규칙을 자동으로 생성하고 HA를 위해 두 개의 물리적 호스트에 분산됩니다.
사용자 클러스터
사용자 클러스터 구성 파일에서 masterNode.replicas를 3로 설정하여 사용자 클러스터에 HA를 사용 설정할 수 있습니다. 사용자 클러스터에 Controlplane V2가 사용 설정되었으면(권장) 3개의 제어 영역 노드가 사용자 클러스터에서 실행됩니다.
기존 HA kubeception 사용자 클러스터는 관리자 클러스터에서 3개의 제어 영역 노드를 실행합니다. 각 제어 영역 노드도 etcd 복제본을 실행합니다. 하나의 제어 영역이 실행 중이고 etcd 쿼럼이 있는 한 사용자 클러스터가 계속 작동합니다. etcd 쿼럼은 세 개의 etcd 복제본 중 두 개가 작동해야 합니다.
관리자 클러스터 구성 파일에서 antiAffinityGroups.enabled를 true로 설정하면 VMware용 GKE는 사용자 클러스터 제어 영역을 실행하는 세 노드에 대한 vSphere DRS 안티-어피니티 규칙을 자동으로 생성합니다.
이 경우 VM이 3개의 물리적 호스트에 분산됩니다.
또한 VMware용 GKE는 사용자 클러스터의 작업자 노드에 vSphere DRS 안티-어피니티 규칙을 만들어 3개 이상의 물리적 호스트에 노드를 분산시킵니다. 여러 DRS 안티어피니티 규칙은 노드 수에 따라 사용자 클러스터 노드 풀별로 사용됩니다. 이렇게 하면 호스트 수가 사용자 클러스터 노드 풀의 VM 수보다 적더라도 워커 노드가 실행할 호스트를 찾을 수 있습니다. vCenter 클러스터에 추가 물리적 호스트를 포함하는 것이 좋습니다. 또한 DRS를 완전히 자동화하도록 구성합니다. 이렇게 하면 호스트를 사용할 수 없게 되므로 VM의 안티어피니티 규칙을 위반하지 않고 다른 사용 가능한 호스트에서 VM을 자동으로 다시 시작할 수 있습니다.
VMware용 GKE는 특수 노드 라벨인 onprem.gke.io/failure-domain-name을 유지하고 이 값은 기본 ESXi 호스트 이름으로 설정됩니다. 고가용성을 원하는 사용자 애플리케이션은 이 라벨을 사용하여 podAntiAffinity 규칙을 topologyKey로 설정하여 애플리케이션 포드가 물리적 호스트는 물론 서로 다른 VM에 분산되도록 할 수 있습니다.
또한 다른 Datastore 및 특수 노드 라벨을 사용해서 사용자 클러스터에 대해 여러 노드 풀을 구성할 수 있습니다. 마찬가지로 이 특수 노드 라벨을 사용하여 podAntiAffinity 규칙을 topologyKey로 설정하면 Datastore 실패 시 고가용성을 확보할 수 있습니다.
사용자 워크로드에 대한 HA를 사용하려면 사용자 클러스터가 nodePools.replicas에 원하는 수의 사용자 클러스터 워커 노드가 실행 중인지 확인할 수 있는 충분한 수의 복제본을 가지고 있는지 확인하세요.
관리자 클러스터 및 사용자 클러스터에 별도의 Datastore를 사용하여 오류를 격리할 수 있습니다.
부하 분산기
고가용성에 사용할 수 있는 부하 분산기에는 다음 두 가지 유형이 있습니다.
번들 MetalLB 분산기
번들 MetalLB 부하 분산기의 경우 enableLoadBalancer: true인 노드가 두 개 이상 있으면 HA를 확보할 수 있습니다.
MetalLB는 서비스를 부하 분산기 노드에 배포하지만 단일 서비스의 경우 해당 서비스의 모든 트래픽을 처리하는 리더 노드가 하나뿐입니다.
클러스터 업그레이드 중에 부하 분산기 노드가 업그레이드되면 다운타임이 발생합니다. MetalLB의 장애 조치 중단 기간은 부하 분산기 노드 수가 증가함에 따라 증가합니다. 노드가 5개 미만이면 중단은 10초 이내입니다.
번들 Seesaw 부하 분산기
번들 Seesaw 부하 분산기의 경우 클러스터 구성 파일에서 loadBalancer.seesaw.enableHA를 true로 설정하여 HA를 사용 설정할 수 있습니다.
또한 부하 분산기 포트 그룹에서 MAC 학습, 위조 전송, 무차별 모드의 조합을 사용 설정해야 합니다.
HA를 사용하면 두 개의 부하 분산기가 활성-수동 모드로 설정됩니다. 활성 부하 분산기에 문제가 있는 경우 트래픽은 수동 부하 분산기로 장애 조치됩니다.
부하 분산기 업그레이드 중에는 다운타임이 발생합니다. 부하 분산기에 HA가 사용 설정된 경우 최대 다운타임은 2초입니다.
통합 F5 BIG-IP 부하 분산기
F5 BIG-IP 플랫폼은 애플리케이션의 보안, 가용성, 성능을 개선하는 데 도움이 되는 다양한 서비스를 제공합니다. VMware용 GKE의 경우 BIG-IP는 외부 액세스와 L3/4 부하 분산 서비스를 제공합니다.
자세한 내용은 BIG-IP 고가용성을 참조하세요.
손상된 클러스터 복구
다음 섹션에서는 손상된 클러스터를 복구하는 방법을 설명합니다.
ESXi 호스트 오류 복구
VMware용 GKE는 vSphere HA를 사용하여 ESXi 호스트 장애로부터 복구를 제공합니다. vSphere HA는 ESXi 호스트를 지속적으로 모니터링하고 필요 시 다른 호스트에서 VM을 자동으로 다시 시작할 수 있습니다. 이는 VMware용 GKE 사용자에게 투명합니다.
VM 오류 복구
VM 오류에는 다음이 포함될 수 있습니다.
VM의 예기치 않은 삭제
VM 부팅 디스크 손상(예: 스팸 저널 로그로 인해 부팅 디스크가 읽기 전용이 됨)
성능 디스크 또는 네트워크 설정 문제로 인한 VM 부팅 실패(예: 어떤 이유로 IP 주소를 할당할 수 없으므로 VM을 부팅할 수 없음)
Docker 오버레이 파일 시스템 손상
업그레이드 실패로 인한 관리자 제어 영역 VM 손실
운영체제 문제
이 섹션에서 설명하는 VM 오류에는 VM에 연결된 PV 또는 etcd 데이터 디스크의 데이터 손상 또는 손실이 포함되지 않습니다. 자세한 내용은 스토리지 오류에서 복구를 참조하세요.
VMware용 GKE는 관리자 부가기능 노드, 사용자 제어 영역, 사용자 노드를 위한 자동 복구 메커니즘을 제공합니다. 이 노드 자동 복구 기능은 관리자 클러스터 및 사용자 클러스터별로 사용 설정할 수 있습니다.
관리자 제어 영역 VM은 Kubenete 클러스터에서 관리하지 않으며 가용성은 비즈니스 연속성에 영향을 주지 않는다는 점에서 특별합니다. 관리자 제어 영역 VM 오류를 복구하려면 Google 지원팀에 문의하세요.
스토리지 오류 복구
일부 스토리지 실패는 VMware용 GKE에 영향을 주지 않고 vSphere HA 및 vSAN으로 완화할 수 있습니다. 하지만 vSphere 수준에서 특정 스토리지 오류가 표면화되어 다양한 VMware용 GKE 구성요소에 대한 데이터 손상/손실이 발생할 수 있습니다.
클러스터 및 사용자 워크로드의 스테이트풀(Stateful) 정보는 다음 위치에 저장됩니다.
etcd
각 클러스터(관리자 클러스터 및 사용자 클러스터)에는 클러스터의 상태(Kubernetes 객체)가 저장되는 etcd가 있습니다.
영구 볼륨
시스템 구성요소와 사용자 워크로드 모두에서 사용됩니다.
etcd 데이터 손상 또는 손실 복구
etcd는 Kubernetes에서 사용자 애플리케이션 매니페스트를 포함한 모든 클러스터 상태를 저장하기 위해 사용하는 데이터베이스입니다. 사용자 클러스터의 etcd 데이터베이스가 손상 또는 분실되면 애플리케이션 수명 주기 작업이 작동을 중지합니다. 관리자 클러스터 etcd 데이터베이스가 손상 또는 분실되면 사용자 클러스터 수명 주기 작업이 작동을 중지합니다.
etcd는 데이터 손상 감지를 위한 신뢰할만한 빌트인 메커니즘을 제공하지 않습니다. etcd 데이터의 손상이나 손실이 의심될 경우 etcd 포드의 로그를 살펴봐야 합니다.
보류/오류/비정상 종료 루프 etcd 포드가 항상 etcd 데이터가 손상되거나 손실되었다는 의미는 아닙니다. etcd 포드를 호스팅하는 VM 오류로 인한 문제일 수 있습니다. 데이터 손상 또는 손실 시에만 다음과 같은 etcd 복구를 수행해야 합니다.
etcd 데이터 손상 또는 손실에서 (최근 클러스터 상태로) 복구하려면 클러스터에서 수명 주기 작업(예: 클러스터 생성, 업데이트 또는 업그레이드) 후 etcd를 백업해야 합니다. etcd 데이터를 백업하려면 관리자 클러스터 백업 및 사용자 클러스터 백업을 참조하세요.
etcd 데이터를 복원하면 클러스터가 이전 상태로 전환됩니다. 즉, 애플리케이션이 배포되기 전에 백업을 수행한 다음 해당 백업을 사용하여 클러스터를 복원하는 경우 애플리케이션이 복원된 클러스터에서 실행되지 않습니다. 예를 들어 사용자 클러스터를 만들기 전에 스냅샷이 생성된 관리자 클러스터의 etcd 스냅샷을 사용하면 복원된 관리자 클러스터에서 사용자 클러스터 제어 영역이 삭제됩니다. 따라서 중요한 각 클러스터 작업 후 클러스터를 백업하는 것이 좋습니다.
다음과 같은 시나리오에서 etcd 데이터 손상/분실 장애가 발생할 수 있습니다.
데이터 손상 또는 손실로 인해 3-노드 etcd 클러스터(HA 사용자 클러스터)의 단일 노드가 영구적으로 손상됩니다. 이 경우 단일 노드만 손상되고 etcd 쿼럼은 계속 존재합니다. 이는 etcd 복제본 중 하나의 데이터가 손상되거나 손실되는 HA 클러스터에서 발생할 수 있습니다. 실패한 etcd 복제본을 클린 상태의 새 복제본으로 교체하면 데이터 손실 없이 문제를 해결할 수 있습니다. 자세한 내용은 실패한 etcd 복제본 바꾸기를 참조하세요.
데이터 손실/손상으로 인해 두 개 이상의 3-노드 etcd 클러스터(HA 사용자 클러스터)의 노드가 영구적으로 손상됩니다. 쿼럼은 손실되므로 실패한 etcd 복제본을 새 복제본으로 교체하는 것은 도움이 되지 않습니다. 클러스터 상태를 백업 데이터에서 복원해야 합니다. 자세한 내용은 백업(HA)에서 사용자 클러스터 복원을 참조하세요.
데이터 손실/손상으로 인해 단일 노드 etcd 클러스터(관리자 클러스터 또는 비HA 사용자 클러스터)가 영구적으로 손상됩니다. 쿼럼은 손실되므로 백업에서 새 클러스터를 만들어야 합니다. 자세한 내용은 백업(비HA)에서 사용자 클러스터 복원을 참조하세요.
사용자 애플리케이션 PV 손상 또는 손실 복구
VMware용 GKE 고객은 특정 파트너 스토리지 솔루션을 사용하여 사용자 애플리케이션 PersistentVolumes를 백업 및 복원할 수 있습니다.
VMware용 GKE에 대해 검증된 스토리지 파트너 목록은 Anthos Ready Storage 파트너를 참조하세요.
부하 분산기 오류 복구
번들 Seesaw 부하 분산기의 경우 부하 분산기를 다시 만들어 장애에서 복구할 수 있습니다. 부하 분산기를 다시 만들려면 관리자 클러스터의 부하 분산기 업그레이드에 나와 있는 것과 동일한 버전으로 Seesaw를 업그레이드합니다.
관리자 클러스터 부하 분산기 오류가 발생하면 제어 영역이 제대로 작동하지 않을 수 있습니다. 따라서 제어 영역에 액세스할 수 있는 관리자 제어 영역 VM에서 업그레이드를 실행해야 합니다.
통합 부하 분산기(F5)의 경우 F5 지원에 문의하세요.
번들 MetalLB 부하 분산기의 경우 클러스터 노드를 부하 분산기로 사용합니다. 부하 분산기 문제에서는 자동 노드 복구가 트리거되지 않습니다. 수동 프로세스를 수행하여 노드를 복구할 수 있습니다.
재해 복구에 여러 클러스터 사용
여러 vCenter 또는 GKE Enterprise 플랫폼에 걸쳐 여러 클러스터에 애플리케이션을 배포하면 전역 가용성을 더 높이고 서비스 중단 시 영향 범위를 제한할 수 있습니다.
이 설정에서는 재해 복구를 위해 새 클러스터를 설정하는 대신 보조 데이터 센터의 기존 GKE Enterprise 클러스터를 사용합니다. 요약하면 다음과 같습니다.
보조 데이터 센터에 다른 관리자 클러스터와 사용자 클러스터를 만듭니다. 이 멀티 클러스터 아키텍처에서는 각 데이터 센터에 관리자 클러스터 두 개가 필요하며 각 관리자 클러스터는 사용자 클러스터를 실행합니다.
보조 사용자 클러스터에는 최소한의 워커 노드(3)가 있으며 상시 대기 중(항상 실행 중)입니다.
애플리케이션 배포는 Config Management를 사용하여 2개의 vCenter에 걸쳐 복제될 수 있으며, 선호되는 방식은 기존 애플리케이션 DevOps(CI/CD, Spinnaker) 도구 모음을 사용하는 것입니다.
재해가 발생할 경우 사용자 클러스터의 크기를 노드 수로 조정할 수 있습니다.
또한 클러스터 간 트래픽을 보조 데이터 센터로 라우팅하려면 DNS 전환이 필요합니다.