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

권장 기능으로 사용자 클러스터 마이그레이션

개요

이 페이지에서는 버전 1.30 이상의 사용자 클러스터를 다음 권장 기능으로 마이그레이션하는 방법을 보여줍니다.

컨테이너 네트워크 인터페이스(CNI)로 Dataplane V2로 마이그레이션
kubeception을 사용하여 사용자 클러스터를 Controlplane V2로 마이그레이션
부하 분산기 구성을 마이그레이션합니다.
- 통합 F5 BIG-IP 부하 분산기 구성에서 ManualLB로 마이그레이션
  
  또는
- 번들 Seesaw 부하 분산기에서 MetalLB로 마이그레이션

이 페이지는 기본 기술 인프라의 수명 주기를 관리하는 IT 관리자 및 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 태스크 예시는 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

권장사항

먼저 테스트와 같은 중요도가 가장 낮은 환경에서 마이그레이션하는 것이 좋습니다. 마이그레이션이 성공했는지 확인한 후 각 환경에 대해 이 프로세스를 반복하여 프로덕션 환경을 마지막으로 마이그레이션합니다. 이렇게 하면 보다 중요한 환경으로 이동하기 전에 각 마이그레이션의 성공 여부를 검증하고 워크로드가 올바르게 실행되는지 확인할 수 있습니다.

kubeception 클러스터와의 아키텍처 차이를 이해하기 위해서는 Controlplane V2를 사용 설정해서 새 사용자 클러스터를 만드는 것이 좋습니다. 이 새 클러스터는 워크로드에 영향을 미치지 않습니다. 하지만 마이그레이션이 실패하는 최악의 시나리오에는 워크로드를 실행할 수 있는 클러스터가 준비됩니다.

마이그레이션 계획에 관한 자세한 내용은 권장 기능으로 클러스터 마이그레이션 계획을 참조하세요.

요구사항

이 마이그레이션을 위한 요구사항은 다음과 같습니다.

사용자 클러스터 버전이 1.30 이상이어야 합니다.
모든 풀의 버전이 사용자 클러스터와 동일해야 합니다.
클러스터에 Seesaw 부하 분산기를 사용하는 경우 다음 섹션에서 설명하는 것처럼 클라이언트 IP 주소를 보존하기 위해 Seesaw에 의존하지 않도록 합니다.

Seesaw 클라이언트 IP 보존

externalTrafficPolicy를 확인하려면 다음 명령어를 실행합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

이 문제가 발생하면 Google 지원팀에 문의하세요.

소요 시간 예측 및 유지보수 기간 계획

클러스터를 업데이트하면 기본적으로 모든 노드 풀이 한 번에 업데이트됩니다. 하지만 각 노드 풀 내에서는 노드가 순차적으로 업데이트됩니다. 따라서 총 업데이트 시간은 가장 큰 노드 풀에 있는 노드 수에 따라 달라집니다. 각 업데이트의 대략적인 시간을 계산하려면 다음 안내를 따르세요.

Seesaw에서 MetalLB로 마이그레이션할 때는 MetalLB 부하 분산기의 노드 풀을 선택하고 업데이트하는 데 15분 정도 걸립니다. 이 업데이트의 경우 선택한 노드 풀만 업데이트됩니다.
마이그레이션 프로세스 중에 다른 업데이트가 있으면 노드 풀에 있는 노드 수에 15분을 곱합니다.

클러스터 업데이트에 필요한 시간을 추정하려면 클러스터를 업데이트해야 하는 횟수를 세어보세요. 다음 단계는 gkectl update cluster를 실행하여 클러스터를 업데이트해야 하는 시기를 요약해서 보여줍니다.

사용자 클러스터에 상시 사용 설정된 보안 비밀 암호화가 사용되는 경우 이 기능을 사용 중지하고 gkectl update cluster를 실행합니다.
사용자 클러스터에 enableDataplaneV2가 설정되지 않았거나 false로 설정되었으면 구성을 변경한 후 gkectl update cluster를 실행하여 Dataplane V2로 마이그레이션합니다.
부하 분산기 및 컨트롤 플레인 마이그레이션 준비:
1. 관리자 클러스터에 자동 복구가 사용 설정되어 있으면 사용 중지합니다. 그런 후 gkectl update admin을 실행합니다. 이 업데이트는 관리자 클러스터 노드를 다시 만들지 않기 때문에 빠르게 완료됩니다.
2. 사용자 클러스터에 Seesaw가 사용되는 경우 MetalLB 부하 분산기에 사용할 노드 풀을 선택한 후 gkectl update cluster를 실행합니다. 이 업데이트는 선택한 노드 풀에 있는 노드만 업데이트합니다.
부하 분산기를 업데이트하고 Controlplane V2로 마이그레이션하기 위해 모든 필요한 구성을 변경합니다. 그런 후 gkectl update cluster를 실행합니다.
마이그레이션 후 상시 사용 설정된 보안 비밀 암호화를 사용 중지했으면 이 기능을 다시 사용 설정하고 gkectl update cluster를 실행합니다.

총 마이그레이션 시간은 gkectl cluster update를 실행해야 하는 횟수에 따라 달라지며, 이러한 횟수는 구성에 따라 달라집니다. 예를 들어 Dataplane V2, ControlPlane V2, MetalLB로 마이그레이션한다고 가정해 보세요. 또한 가장 큰 노드 풀에 노드가 10개 있고 MetalLB에 사용되는 노드 풀에 노드가 3개 있다고 가정해 보세요. 예상되는 마이그레이션 시간을 계산하려면 다음을 추가합니다.

Dataplane V2로 마이그레이션하는 데에는 150분이 걸립니다(가장 큰 풀에 있는 노드 10개 * 15분 = 150분).
MetalLB에 사용되는 노드 풀은 45분이 걸립니다(노드 풀에 있는 노드 3개 * 15분 = 45분).
Controlplane V2 및 MetalLB 업데이트에는 150분이 걸립니다(가장 큰 풀에 있는 노드 10개 * 15분 = 150분).

총 마이그레이션은 약 345분(5시간 45분)입니다.

필요한 경우 여러 단계에 걸쳐서 마이그레이션을 수행할 수 있습니다. 이전 예시에 대해 한 번의 유지보수 기간 중에 Dataplane V2로 마이그레이션을 수행하고 한 두 번의 유지보수 기간에 걸쳐서 나머지 마이그레이션을 수행할 수 있습니다.

마이그레이션 중 다운타임 계획

마이그레이션을 계획할 때는 다음 유형의 다운타임을 계획하세요.

컨트롤 플레인 다운타임: 마이그레이션 중 Kubernetes API 서버 액세스가 영향을 받습니다. Controlplane V2로 마이그레이션할 경우 loadBalancer.vips.controlPlaneVIP가 마이그레이션될 때 kubeception 사용자에게 컨트롤 플레인 다운타임이 발생합니다. 다운타임은 일반적으로 10분 미만이지만 인프라에 따라 다운타임 기간이 달라집니다.
워크로드 다운타임: 서비스 유형: LoadBalancer에 사용되는 가상 IP(VIP)를 사용할 수 없습니다. 이는 Seesaw에서 MetalLB로 마이그레이션할 때만 발생합니다. MetalLB 마이그레이션 프로세스 중에는 LoadBalancer 유형의 Kubernetes 서비스에 대해 약 2~10분 정도 사용자 클러스터의 모든 VIP에 대한 네트워크 연결이 중단됩니다. 마이그레이션이 완료되면 연결이 다시 작동합니다.

다음 표에서는 마이그레이션 영향을 보여줍니다.

시작	종료	Kubernetes API 액세스	사용자 워크로드
`enableDataplaneV2`가 설정되지 않았거나 `false`로 설정된 Calico를 사용하는 Kubeception 클러스터	Dataplane V2를 사용하는Kubeception 클러스터	영향을 받지 않음	영향을 받지 않음
`enableControlplaneV2`가 설정되지 않았거나 `MetalLB` 또는 `ManualLB`를 사용해서 `false`로 설정된 kubeception 클러스터	동일한 종류의 부하 분산기를 사용하는 Controlplane V2 클러스터	영향을 받음	영향을 받지 않음
`loadBalancer.kind: "F5BigIP"`를 사용하는 Kubeception 클러스터	수동 부하 분산기 구성을 사용하는 Controlplane V2 클러스터	영향을 받음	영향을 받지 않음
`loadBalancer.kind: "Seesaw"`를 사용하는 Kubeception 클러스터	MetalLB를 사용하는 Controlplane V2 클러스터	영향을 받음	영향을 받음

영향을 받음: 마이그레이션 중에 서비스가 눈에 띄게 중단됩니다.
영향을 받지 않음: 서비스 중단이 없거나 거의 알아챌 수 없습니다.

마이그레이션 준비

마이그레이션 성공을 보장하려면 다음 섹션의 단계를 수행합니다.

새 IP 주소 할당

Controlplane V2로 마이그레이션하는 경우 워커 노드(노드 풀에 있는 노드)와 동일한 VLAN에서 새 고정 IP 주소를 할당합니다.

loadBalancer.vips.controlPlaneVIP에 하나의 IP 주소가 필요합니다.
각 컨트롤 플레인 노드에 하나의 IP 주소를 할당합니다. 할당해야 하는 IP 주소 수는 사용자 클러스터가 고가용성(HA) 또는 비HA로 설정되었는지에 따라 달라집니다.
- 비HA: IP 주소 1개
- HA: IP 주소 3개

방화벽 규칙 업데이트

Controlplane V2로 마이그레이션하는 경우 사용자 클러스터에서 다음 규칙을 업데이트합니다. 방화벽 규칙 사용자 클러스터 노드에 설명된 대로 사용자 클러스터에서 컨트롤 플레인 노드에 대해 새로 할당된 IP 주소가 모든 필수 API 및 기타 대상에 연결할 수 있는지 확인합니다.

클러스터 및 노드 풀 버전 확인

모든 노드 풀에 사용자 클러스터와 동일한 버전이 사용되는지 확인합니다. 버전은 1.30 이상이어야 합니다. 그렇지 않으면 마이그레이션을 계속하기 전 사용자 클러스터 구성 파일에서 gkeOnPremVersion으로 노드 풀을 업그레이드합니다. 버전을 확인하려면 다음 명령어를 실행합니다.

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

클러스터 상태 확인

클러스터 상태를 확인하고 gkectl diagnose cluster 명령어로 보고되는 문제를 해결합니다.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name <var>USER_CLUSTER_NAME</var>

다음을 바꿉니다.

ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
USER_CLUSTER_NAME: 사용자 클러스터의 이름입니다.

관리자 클러스터에서 자동 복구 사용 중지

Controlplane V2를 사용하도록 사용자 클러스터를 마이그레이션하는 중이고 관리자 클러스터에서 자동 복구가 사용 설정되어 있으면 자동 복구를 사용 중지합니다. 관리자 클러스터 구성 파일의 autoRepair.enabled 필드를 확인합니다. 이 필드가 설정되지 않았거나 true로 설정되었으면 다음 단계를 수행합니다.

관리자 클러스터 구성 파일에서 autoRepair.enabled를 false로 설정합니다. 예를 들면 다음과 같습니다.
```
autoRepair:
  enabled: true
```

관리자 클러스터를 업데이트합니다.

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

다음을 바꿉니다.

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

마이그레이션이 완료되면 관리자 클러스터에서 자동 복구를 다시 사용 설정합니다.

상시 사용 설정된 보안 비밀 암호화 관련 문제 확인

Controlplane V2를 사용하도록 사용자 클러스터를 마이그레이션하는 중이면 상시 사용 설정된 보안 비밀 암호화 관련 문제를 확인합니다.

상시 사용 설정된 보안 비밀 암호화가 사용자 클러스터에 사용 설정되었으면 마이그레이션을 시작하기 전에 상시 사용 설정된 보안 비밀 암호화 사용 중지 및 보안 비밀 복호화의 단계를 수행해야 합니다. 그렇지 않으면 새 Controlplane V2 클러스터가 보안 비밀을 복호화할 수 없습니다.

마이그레이션을 시작하기 전에 다음 명령어를 실행하여 상시 사용 설정된 보안 비밀 암호화가 이전에 사용 설정되었는지 확인합니다.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

위 명령어의 출력이 비어 있으면 상시 사용 설정된 보안 비밀 암호화가 이전에 사용 설정되지 않았습니다. 마이그레이션을 시작할 수 있습니다.

위 명령어의 출력이 비어 있지 않으면 상시 사용 설정된 보안 비밀 암호화가 이전에 사용 설정된 것입니다. 마이그레이션을 시작하기 전에 다음 섹션의 단계를 수행하여 새 Controlplane V2 클러스터가 보안 비밀을 복호화할 수 있는지 확인합니다.

다음 예시는 비어 있지 않은 출력을 보여줍니다.

{"generatedKeyVersions":{"keyVersions":[1]}}

상시 사용 설정된 보안 비밀 암호화 사용 중지 및 필요한 경우 보안 비밀 복호화

상시 사용 설정된 보안 비밀 암호화를 사용 중지하고 보안 비밀을 복호화하려면 다음 단계를 수행합니다.

사용자 클러스터 구성 파일에서 상시 사용 설정된 보안 비밀 암호화를 사용 중지하기 위해 secretsEncryption 섹션에 disabled: true 필드를 추가합니다.
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
클러스터를 업데이트합니다.
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
다음을 바꿉니다.
- ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
- USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일의 경로입니다.

다음과 같이 특정 DaemonSet에서 순차적 업데이트를 수행합니다.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

사용자 클러스터에서 모든 보안 비밀 매니페스트를 YAML 형식으로 가져옵니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

모든 보안 비밀이 etcd에 일반 텍스트로 저장되므로 사용자 클러스터에서 모든 보안 비밀을 다시 적용합니다.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
이제 Controlplane V2로 마이그레이션을 시작할 수 있습니다. 마이그레이션이 완료되면 클러스터에서 상시 사용 설정된 보안 비밀 암호화를 다시 사용 설정할 수 있습니다.

MetalLB에 사용할 노드 풀 사용 설정

번들 Seesaw 부하 분산기에서 MetalLB로 마이그레이션하는 경우 이 섹션의 단계를 수행합니다. loadBalancer.kind: Seesaw가 사용자 클러스터 구성 파일에 있으면 클러스터가 Seesaw를 사용하는 중입니다. 통합 F5 BIG-IP 구성을 마이그레이션하는 경우 다음 단계인 Dataplane V2로 마이그레이션으로 건너뜁니다.

노드 풀을 선택하고 MetalLB에 사용하도록 사용 설정합니다. 마이그레이션을 수행하면 해당 노드 풀의 노드에 MetalLB를 배포합니다.

사용자 클러스터 구성 파일의 nodePools 섹션에서 노드 풀을 선택하거나 새 노드 풀을 추가하고 enableLoadBalancer를 true로 설정합니다. 예를 들면 다음과 같습니다.
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

클러스터를 업데이트합니다.

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

MetalLB에 대한 자세한 내용은 MetalLB를 사용한 번들 부하 분산을 참조하세요.

Dataplane V2로 마이그레이션

마이그레이션하기 전에 다음 명령어를 실행하여 클러스터에 DataPlane V2가 사용 설정되었는지 확인합니다.

kubectl —kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Dataplane V2가 이미 사용 설정되었으면 다음 섹션인 부하 분산기 마이그레이션 준비로 건너뜁니다.

Dataplane V2로 마이그레이션하려면 다음 단계를 수행합니다. NetworkPolicy 사양을 일시적으로 삭제하는데 문제가 있으면 Google 지원팀에 문의하세요.

클러스터에 NetworkPolicy가 사용되는 경우 다음과 같이 클러스터에서 사양을 일시적으로 삭제합니다.

클러스터에 비시스템 NetworkPolicy가 적용되었는지 확인합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

이전 단계의 출력이 비어 있지 않으면 각 NetworkPolicy 사양을 파일에 저장합니다.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
다음을 바꿉니다.
- NETWORK_POLICY_NAME: 저장하는 NetworkPolicy의 이름입니다.
- NETWORK_POLICY_NAMESPACE: NetworkPolicy의 네임스페이스입니다.

다음 명령어를 사용하여 NetworkPolicy를 삭제합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

다음 단계에 따라 Dataplane V2로 이전합니다.

사용자 클러스터 구성 파일에서 enableDataplaneV2를 true로 설정합니다.

DataPlane V2를 사용 설정하려면 클러스터를 업데이트합니다.

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

이전 단계에서 비시스템 NetworkPolicy 사양을 삭제한 경우 업데이트가 완료된 후 다음 명령어를 사용하여 이를 다시 적용합니다.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

이 단계를 완료하면 Dataplane V2가 사용 설정됩니다. 그런 후 권장되는 부하 분산기 및 Controlplane V2로 클러스터 마이그레이션을 준비합니다.

부하 분산기 마이그레이션 준비

사용자 클러스터에 Seesaw 부하 분산기 또는 통합 F5 BIG-IP가 사용되는 경우 이 섹션의 단계에 따라 필요한 사용자 클러스터 구성 파일을 변경합니다. 그렇지 않으면 다음 단계인 Controlplane V2로 마이그레이션 준비로 건너뜁니다.

F5 BIG-IP

클러스터에 통합 F5 BIG-IP 구성이 사용되는 경우 사용자 클러스터 구성 파일을 다음과 같이 변경하여 ManualLB로 마이그레이션을 준비합니다.

loadBalancer.kind를 "ManualLB"로 변경합니다.
loadBalancer.vips.ingressVIP 필드는 값을 동일하게 유지합니다.
Controlplane V2로 이전하는 경우 loadBalancer.vips.controlPlaneVIP 필드의 값을 할당한 IP 주소로 변경합니다. 또는 값을 동일하게 유지할 수 있습니다.
전체 loadBalancer.f5BigIP 섹션을 삭제합니다.

다음 사용자 클러스터 구성 파일 예시는 이러한 변경사항을 보여줍니다.

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

사용자 클러스터에 Seesaw 부하 분산기가 사용되는 경우 다음 섹션의 단계를 수행하여 MetalLB로 마이그레이션을 준비합니다.

주소 풀 지정

MetalLB 컨트롤러는 서비스의 IP 주소를 관리합니다. 따라서 애플리케이션 개발자가 사용자 클러스터에서 LoadBalancer 유형의 서비스를 만들 때 서비스의 IP 주소를 수동으로 지정할 필요가 없습니다. 대신 MetalLB 컨트롤러에서 사용자가 지정한 주소 풀의 IP 주소가 선택됩니다.

사용자 클러스터에서 활성화될 수 있는 LoadBalancer 서비스의 최대 개수를 고려하세요. 그런 다음 사용자 클러스터 구성 파일의 loadBalancer.metalLB.addressPools 섹션에서 해당 서비스를 수용하도록 IP 주소를 충분하게 지정합니다.

주소 풀을 지정할 때 풀 중 하나에 사용자 클러스터의 인그레스 VIP를 포함합니다. 이는 인그레스 프록시가 LoadBalancer 유형의 서비스에 의해 노출되기 때문입니다.

주소는 CIDR 형식이나 범위 형식이어야 합니다. 개별 주소를 지정하려면 198.51.100.10/32와 같이 /32 CIDR을 사용합니다.

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

다음과 같이 클러스터 구성 파일을 업데이트하여 Seesaw 섹션을 삭제하고 MetalLB 섹션을 추가합니다.

loadBalancer.kind를 "MetalLB"로 설정합니다.
loadBalancer.vips.ingressVIP 필드 값은 동일하게 유지할 수 있습니다.
MetalLB 주소 풀에 인그레스 VIP를 추가합니다.
Controlplane V2로 이전하는 경우 loadBalancer.vips.controlPlaneVIP 필드의 값을 할당한 IP 주소로 변경합니다. 또는 값을 동일하게 유지할 수 있습니다.
loadBalancer.seesaw 섹션을 삭제합니다.
loadBalancer.metalLB 섹션을 추가합니다.

사용자 클러스터 구성 파일 중 다음 부분에 이러한 변경사항과 MetalLB 구성이 표시됩니다.

MetalLB 컨트롤러가 LoadBalancer 유형의 서비스에서 선택하고 할당할 주소 풀입니다. 이 예시에서 인그레스 VIP(198.51.100.10)는 이 풀의 일부이며 범위 형식 표기법에 따라 198.51.100.10/32로 표시됩니다.
사용자 클러스터의 Kubernetes API 서버에 지정된 VIP입니다.
인그레스 프록시에 구성한 인그레스 VIP입니다.
MetalLB를 사용하도록 설정된 노드 풀입니다. 마이그레이션을 수행하면 이 노드 풀의 노드에 MetalLB를 배포합니다.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
  addressPools:
    - name: "address-pool-1"
      enableLoadBalancer: true
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Controlplane V2로 마이그레이션 준비

클러스터에 Controlplane V2가 사용 설정되지 않은 경우:

사용자 클러스터 구성 파일을 업데이트합니다.
클러스터에 수동 부하 분산(loadBalancer.kind: "ManualLB")이 사용되는 경우에는 부하 분산기에서도 구성을 업데이트합니다.

이러한 단계는 다음 섹션에서 설명합니다.

클러스터에 이미 Controlplane V2가 사용 설정되었으면 사용자 클러스터 마이그레이션 섹션으로 건너뜁니다.

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

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

enableControlplaneV2를 true로 설정합니다.
선택적으로 Controlplane V2 사용자 클러스터의 컨트롤 플레인을 고가용성(HA)으로 설정합니다. HA가 아닌 클러스터에서 HA 클러스터로 변경하려면 masterNode.replicas를 1에서 3으로 변경합니다.
사용자 클러스터 컨트롤 플레인 노드의 고정 IP 주소(또는 주소)를 network.controlPlaneIPBlock.ips 섹션에 추가합니다. 컨트롤 플레인 노드의 IP 주소는 워커 노드와 동일한 VLAN에 있어야 합니다.
network.controlPlaneIPBlock 섹션에 netmask 및 gateway를 입력합니다.
network.hostConfig 섹션이 비어 있으면 입력합니다.
loadBalancer.vips.controlPlaneVIP 필드에 컨트롤 플레인 VIP의 새 IP 주소가 있는지 확인합니다. IP 주소는 컨트롤 플레인 노드 IP와 동일한 VLAN에 있어야 합니다.
사용자 클러스터에 수동 부하 분산이 사용되는 경우 loadBalancer.manualLB.controlPlaneNodePort 및 loadBalancer.manualLB.konnectivityServerNodePort를 0으로 설정합니다. Controlplane V2가 사용 설정된 경우에는 필요하지 않지만 값은 0이어야 합니다.
사용자 클러스터에 수동 부하 분산이 사용되는 경우 다음 섹션에 설명된 대로 부하 분산기를 구성합니다.

필요한 경우 부하 분산기의 매핑 조정

사용자 클러스터에 이미 수동 부하 분산이 사용되는 경우 부하 분산기에서 일부 매핑을 구성해야 합니다. 통합 F5 BIG-IP 구성에서 수동 부하 분산으로 마이그레이션하는 경우에는 부하 분산기에서 구성을 변경할 필요가 없고 다음 섹션인 사용자 클러스터 마이그레이션으로 건너뛸 수 있습니다.

network.controlPlaneIPBlock 섹션에 지정한 각 IP 주소에 대해 부하 분산기에서 컨트롤 플레인 노드에 대해 다음 매핑을 구성합니다.

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

이러한 매핑은 컨트롤 플레인 노드와 워커 노드 모두 사용자 클러스터의 모든 노드에 필요합니다. NodePort가 클러스터에 구성되었기 때문에 이 클러스터의 모든 노드가 데이터 플레인 트래픽을 처리할 수 있도록 Kubernetes가 모든 클러스터 노드에서 NodePort를 엽니다.

매핑을 구성한 후 부하 분산기는 표준 HTTP 및 HTTPS 포트에서 사용자 클러스터의 인그레스 VIP에 대해 구성한 IP 주소로 트래픽을 수신 대기합니다. 부하 분산기는 클러스터의 노드로 요청을 라우팅합니다. 요청이 클러스터 노드 중 하나로 라우팅된 후에는 내부 Kubernetes 네트워킹이 요청을 대상 포드로 라우팅합니다.

사용자 클러스터 마이그레이션

먼저 사용자 클러스터 구성 파일에서 모든 변경사항을 검토합니다. 마이그레이션을 위해 클러스터를 업데이트할 때를 제외하면 부하 분산기와 Controlplane V2 설정을 모두 변경할 수 없습니다.

클러스터를 업데이트하려면 다음 명령어를 실행합니다.

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

Controlplane V2 마이그레이션

Controlplane V2 마이그레이션 중에 업데이트는 다음 작업을 수행합니다.

ControlPlane V2가 사용 설정된 새 클러스터의 컨트롤 플레인을 만듭니다.
kubeception 클러스터의 Kubernetes 컨트롤 플레인을 중지합니다.
kubeception 클러스터의 etcd 스냅샷을 만듭니다.
kubeception 클러스터의 사용자 클러스터 컨트롤 플레인 노드 전원을 끕니다. 이러한 노드는 마이그레이션이 완료될 때까지 삭제되지 않으므로 kubeception 클러스터로 돌아가 잠재적인 마이그레이션 실패부터 복구할 수 있습니다.
이전 단계에서 만든 etcd 스냅샷을 사용해서 새 컨트롤 플레인에 클러스터 데이터를 복원합니다.
새 controlPlaneVIP로 액세스할 수 있는 새 컨트롤 플레인에 kubeception 클러스터의 nodepool 노드를 연결합니다.
ControlPlane V2가 사용 설정된 클러스터의 종료 상태를 충족하도록 복원된 사용자 클러스터를 조정합니다.

다음에 유의하세요.

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

마이그레이션 후

업데이트가 완료되면 다음 단계를 수행합니다.

사용자 클러스터 실행 여부 확인:

kubectl get nodes --kubeconfig var>USER_CLUSTER_KUBECONFIG

출력은 다음과 비슷합니다.

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Controlplane V2로 이전한 경우 관리자 클러스터의 방화벽 규칙을 업데이트하여 kubeception 사용자 클러스터의 컨트롤 플레인 노드를 삭제합니다.
상시 사용 설정된 보안 비밀 암호화를 사용 중지했으면 이 기능을 다시 사용 설정합니다.
1. 사용자 클러스터 구성 파일에서 disabled: true 필드를 삭제합니다.
2. 사용자 클러스터를 업데이트합니다.
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
관리자 클러스터에서 자동 복구를 사용 중지했으면 이 기능을 다시 사용 설정합니다.
1. 관리자 클러스터 구성 파일에서 autoRepair.enabled를 true로 설정합니다.
2. 클러스터를 업데이트합니다.
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

부하 분산기 마이그레이션

부하 분산기를 마이그레이션한 경우 부하 분산기 구성요소가 정상적으로 실행되고 있는지 확인합니다.

MetalLB 마이그레이션

MetalLB로 마이그레이션한 경우 MetalLB 구성요소가 정상적으로 실행되는지 확인합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

출력에 MetalLB 컨트롤러 및 스피커에 대한 포드가 표시됩니다. 예를 들면 다음과 같습니다.

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

마이그레이션이 완료된 후 사용자 클러스터의 전원이 꺼진 Seesaw VM을 삭제합니다. 구성 디렉터리에 있는 seesaw-for-[USERCLUSTERNAME].yaml 파일의 vmnames 섹션에서 Seesaw VM 이름을 찾을 수 있습니다.

F5 BIG-IP 마이그레이션

수동 부하 분산으로 마이그레이션한 후에도 클러스터 트래픽은 중단되지 않습니다. 이는 다음 명령어를 실행하여 확인할 수 있는 것처럼 기존 F5 리소스가 아직 있기 때문입니다.

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

출력은 다음과 비슷합니다.


Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z