이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

이 문서에서는 kubeception을 사용하여 버전 1.29 이상의 사용자 클러스터를 Controlplane V2로 마이그레이션하는 방법을 보여줍니다.

1.29: 미리보기
1.28: 사용할 수 없음
1.16: 사용할 수 없음

사용자 클러스터 컨트롤 플레인 정보

Google Distributed Cloud 1.13 이전 버전에는 사용자 클러스터의 컨트롤 플레인이 관리자 클러스터의 하나 이상의 노드에서 실행되었습니다. 이러한 종류의 컨트롤 플레인을 kubeception이라고 부릅니다. 버전 1.13에서는 새 사용자 클러스터에 Controlplane V2가 도입되었습니다. Controlplane V2가 사용 설정되면 사용자 클러스터의 컨트롤 플레인은 사용자 클러스터 자체에서 실행됩니다.

Controlplane V2의 이점은 다음과 같습니다.

장애 격리. 관리자 클러스터 오류가 사용자 클러스터에 영향을 주지 않습니다.
운영 분리. 관리자 클러스터 업그레이드가 사용자 클러스터에 다운타임을 일으키지 않습니다.
배포 분리. 관리자 클러스터와 사용자 클러스터를 다른 장애 도메인 또는 지리적 사이트에 배치할 수 있습니다. 예를 들어 에지 위치의 사용자 클러스터가 관리자 클러스터와 다른 지리적 사이트에 있을 수 있습니다.

요구사항

사용자 클러스터를 Controlplane V2로 마이그레이션하려면 사용자 클러스터가 다음 요구사항을 충족해야 합니다.

사용자 클러스터는 버전 1.29 이상이어야 합니다. 관리자 클러스터 및 노드 풀은 사용자 클러스터보다 낮은 부 버전 한 개 또는 두 개일 수 있습니다. 필요한 경우 클러스터를 업그레이드합니다.
사용자 클러스터에 Dataplane V2가 사용 설정되어 있어야 합니다. 이 필드는 변경할 수 없으므로 클러스터에서 Dataplane V2를 사용 설정하지 않으면 이를 Controlplane V2로 마이그레이션할 수 없습니다.
사용자 클러스터는 MetalLB 또는 수동 부하 분산기를 사용하도록 구성되어야 합니다. 사용자 클러스터가 SeeSaw 부하 분산기를 사용하는 경우 MetalLB로 마이그레이션할 수 있습니다.
IP 주소 계획 문서를 검토하고 사용자 클러스터의 컨트롤 플레인 노드에 사용할 수 있는 IP 주소가 충분한지 확인합니다. 컨트롤 플레인 노드에는 고정 IP 주소가 필요하며, 새 컨트롤 플레인 가상 IP(VIP)의 경우 추가 IP 주소가 필요합니다.

사용자 클러스터 구성 파일 업데이트

기존 사용자 클러스터 구성 파일을 다음과 같이 변경합니다.

enableControlplaneV2를 true로 설정합니다.
선택적으로 Controlplane V2 사용자 클러스터의 컨트롤 플레인을 고가용성(HA)으로 설정합니다. HA가 아닌 클러스터에서 HA 클러스터로 변경하려면 masterNode.replicas를 1에서 3으로 변경합니다.
사용자 클러스터 컨트롤 플레인 노드의 고정 IP 주소(또는 주소)를 network.controlPlaneIPBlock.ips 섹션에 추가합니다.
network.controlPlaneIPBlock 섹션에서 넷마스크 및 게이트웨이를 입력합니다.
network.hostConfig 섹션이 비어 있으면 입력합니다.
사용자 클러스터가 수동 부하 분산을 사용하는 경우 데이터 영역 트래픽에 대해 컨트롤 플레인 노드 IP가 포함되도록 부하 분산기를 구성합니다.
- (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
- (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)
컨트롤 플레인 VIP의 새 IP 주소로 loadBalancer.vips.controlPlaneVIP 필드를 업데이트합니다. 컨트롤 플레인 노드 IP와 동일한 VLAN에 있어야 합니다.
마이그레이션을 위해 클러스터를 업데이트하는 경우를 제외하고 이전의 모든 필드는 변경할 수 없습니다. 모든 설정을 다시 한번 확인하세요.
gkectl diagnose cluster를 실행하고 명령어로 발견된 문제를 해결합니다.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
다음을 바꿉니다.
- ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
- CLUSTER_NAME: 사용자 클러스터의 이름입니다.

수동 부하 분산기 구성 조정

사용자 클러스터에서 수동 부하 분산을 사용하는 경우 이 섹션의 단계를 수행합니다. 그렇지 않으면 이 섹션을 건너뛰세요.

CPv2 사용자 클러스터에 대한 부하 분산기를 구성하는 것과 마찬가지로 network.controlPlaneIPBlock 섹션에 지정한 3개의 새로운 컨트롤 플레인 노드 IP 주소 각각에 대해 부하 분산기에서 매핑을 구성합니다.

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

클러스터 업데이트

다음 명령어를 실행하여 클러스터를 Controlplane V2로 마이그레이션합니다.

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

다음을 바꿉니다.

ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일의 경로입니다.

이 명령은 다음을 수행합니다.

ControlPlane V2가 사용 설정된 새 클러스터의 컨트롤 플레인을 만듭니다.
kubeception 클러스터의 Kubernetes 컨트롤 플레인을 중지합니다.
kubeception 클러스터의 etcd 스냅샷을 만듭니다.
kubeception 클러스터의 사용자 클러스터 컨트롤 플레인 노드 전원을 끕니다. kubeception 클러스터로 대체되는 장애 복구를 위해 노드는 마이그레이션이 완료될 때까지 삭제되지 않습니다.
앞에서 언급한 etcd 스냅샷을 사용하여 새 컨트롤 플레인에서 클러스터 데이터를 복원합니다.
새 controlPlaneVIP로 액세스할 수 있는 새 컨트롤 플레인에 kubeception 클러스터의 nodepool 노드를 연결합니다.
ControlPlane V2가 사용 설정된 클러스터의 종료 상태를 충족하도록 복원된 사용자 클러스터를 조정합니다.

참고

마이그레이션 중에는 사용자 클러스터 워크로드에 다운타임이 발생하지 않습니다.
마이그레이션 중에는 사용자 클러스터 컨트롤 플레인에서 일부 다운타임이 발생합니다. 구체적으로 컨트롤 플레인은 2단계부터 6단계 완료까지 사용할 수 없습니다. (테스트에 따르면 다운타임이 7분 미만이지만 실제 길이는 인프라에 따라 달라집니다.)
마이그레이션이 끝나면 kubeception 클러스터의 사용자 클러스터 컨트롤 플레인 노드가 삭제됩니다. 관리자 클러스터에서 network.ipMode.type이 "static"으로 설정되었으면 관리자 클러스터 구성 파일에서 이를 삭제하여 사용되지 않은 일부 고정 IP를 재활용하고 gkectl update admin을 실행할 수 있습니다. kubectl get nodes -o wide로 관리자 클러스터 노드 객체를 나열하고 사용 중인 IP를 확인할 수 있습니다.