이 문서에서는 버전 1.16~1.29 버전에 대해 Seesaw 부하 분산기에서 MetalLB 부하 분산기로 마이그레이션하는 방법을 보여줍니다. 클러스터의 버전이 1.30 이상인 경우 권장 기능으로 클러스터 마이그레이션 계획의 안내를 따르는 것이 좋습니다.
MetalLB를 사용하면 다른 부하 분산 옵션과 비교했을 때 몇 가지 이점이 있습니다.
1.28 및 1.29: GA
1.16: 미리보기
externalTrafficPolicy를 확인하려면 다음 명령어를 실행합니다.
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"
이 문제와 관련하여 Google 지원팀에 문의하세요.
다운타임 참고사항
마이그레이션 중에 워크로드 다운타임이 발생합니다. SeeSaw 부하 분산기는 HA 관리자 클러스터를 지원하지 않으므로 다음 사항은 고가용성(HA)이 아닌 관리자 클러스터에만 적용됩니다.
관리자 클러스터를 마이그레이션하는 경우:
controlPlaneVIP가 마이그레이션되는 중에 kubeception 사용자 클러스터에서 컨트롤 플레인 다운타임이 발생합니다. 다운타임 시간은 보통 10분 미만이지만 인프라에 따라서 달라집니다.VM에 직접 연결된
controlPlaneVIP로 관리자 마스터 노드를 다시 만들어야 하므로 관리자 클러스터 컨트롤 플레인에 다운타임이 발생합니다. 다운타임 시간은 보통 20분 미만이지만 인프라에 따라서 달라집니다.
사용자 클러스터를 마이그레이션할 때 Seesaw 부하 분산기가 종료된 후 MetalLB 포드가 가동되기 전까지 VIP가 중단됩니다. 이 프로세스에는 일반적으로 1분 정도 걸립니다.
사용자 클러스터 마이그레이션
노드 풀을 선택하고 MetalLB와 함께 사용하도록 사용 설정해야 합니다. MetalLB는 이 노드 풀의 노드에 배포됩니다.
사용자 클러스터 구성 파일에서 노드 풀을 선택하고 enableLoadBalancer를 true로 설정합니다.
nodePools: - name: pool-1 replicas: 3 enableLoadBalancer: true
클러스터를 업데이트합니다.
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
다음을 바꿉니다.
ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일의 경로입니다.
그런 후 파일에서 Seesaw 섹션을 삭제하고 MetalLB 섹션을 추가합니다.
그런 다음 클러스터를 다시 업데이트합니다.
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
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 이름을 찾을 수 있습니다.
예: 사용자 클러스터, 고정 IP 주소
클러스터 노드에 고정 IP 주소를 사용하는 사용자 클러스터가 있다고 가정합니다. 또한 클러스터에 LoadBalancer 유형의 서비스가 2개 있고 이러한 서비스의 외부 주소가 172.16.21.41 및 172.16.21.45라고 가정해 보겠습니다.
다음과 같이 사용자 클러스터 구성 파일을 조정합니다.
network.hostConfig섹션을 유지합니다.loadBalancer.kind을MetalLB로 설정합니다.loadBalancer.seesaw섹션을 삭제합니다.loadBalancer.metalLB섹션을 추가합니다.
예를 들면 다음과 같습니다.
network:
hostConfig:
dnsServers:
- "172.16.255.1"
- "172.16.255.2"
ntpServers:
- "216.239.35.0"
loadBalancer:
vips:
controlPlaneVIP: "172.16.20.30"
ingressVIP: "172.16.20.31"
kind: MetalLB Seesaw
seesaw:
ipBlockFilePath: "user-cluster-1-ipblock.yaml"
vrid: 1
masterIP: ""
cpus: 4
memoryMB: 3072
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.20.31/32"
- "172.16.20.40 - 172.16.21.49"
앞의 예시의 요점은 다음과 같습니다.
클러스터에서 더 이상 Seesaw 부하 분산기를 사용하지 않더라도 클러스터 노드에 고정 IP 주소가 사용되기 때문에
network.hostConfig섹션이 필요합니다.ingressVIP값이 MetalLB 주소 풀에 표시됩니다.LoadBalancer유형의 기존 서비스에 대한 외부 IP 주소(172.16.21.41 및 172.16.21.45)가 MetalLB 주소 풀에 포함되어 있습니다.
예: kubeception 사용자 클러스터, DHCP
클러스터 노드에 DHCP를 사용하는 사용자 클러스터가 있다고 가정해 보겠습니다. 또한 클러스터에 LoadBalancer 유형의 서비스가 2개 있고 이러한 서비스의 외부 주소가 172.16.21.61 및 172.16.21.65라고 가정해 보겠습니다.
다음과 같이 사용자 클러스터 구성 파일을 조정합니다.
network.hostConfig섹션을 삭제합니다.loadBalancer.kind을MetalLB로 설정합니다.loadBalancer.seesaw섹션을 삭제합니다.loadBalancer.metalLB섹션을 추가합니다.
예를 들면 다음과 같습니다.
enableControlplaneV2: false network:hostConfig: dnsServers: - "172.16.255.1" - "172.16.255.2" ntpServers: - "216.239.35.0"loadBalancer: vips: controlPlaneVIP: "172.16.20.50" ingressVIP: "172.16.20.51" kind: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-2-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: addressPools: - name: "address-pool-1" addresses: - "172.16.20.51/32" - "172.16.20.60 - 172.16.21.69"
앞의 예시의 요점은 다음과 같습니다.
클러스터에서 더 이상 Seesaw 부하 분산기를 사용하지 않고 클러스터는 클러스터 노드에 고정 IP 주소를 사용하지 않습니다. 따라서
network.hostConfig섹션은 필요하지 않습니다.ingressVIP값이 MetalLB 주소 풀에 표시됩니다.LoadBalancer유형의 기존 서비스에 대한 외부 IP 주소(172.16.21.61 및 172.16.21.65)가 MetalLB 주소 풀에 포함되어 있습니다.
예: Controlplane V2 사용자 클러스터, DHCP
Controlplane V2가 사용 설정되어 있고 워커 노드에 DHCP를 사용하는 사용자 클러스터가 있다고 가정해 보겠습니다. 또한 클러스터에 LoadBalancer 유형의 서비스가 2개 있고 이러한 서비스의 외부 주소가 172.16.21.81 및 172.16.21.85라고 가정해 보겠습니다.
다음과 같이 사용자 클러스터 구성 파일을 조정합니다.
network.hostconfig섹션을 유지합니다.loadBalancer.kind을MetalLB로 설정합니다.loadBalancer.seesaw섹션을 삭제합니다.loadBalancer.metalLB섹션을 추가합니다.
예를 들면 다음과 같습니다.
enableControlplaneV2: true
network:
hostConfig:
dnsServers:
- "172.16.255.1"
- "172.16.255.2"
ntpServers:
- "216.239.35.0"
loadBalancer:
vips:
controlPlaneVIP: "172.16.20.70"
ingressVIP: "172.16.20.71"
kind: MetalLB Seesaw
seesaw:
ipBlockFilePath: "user-cluster-2-ipblock.yaml"
vrid: 1
masterIP: ""
cpus: 4
memoryMB: 3072
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.20.71/32"
- "172.16.20.80 - 172.16.21.89"
앞의 예시의 요점은 다음과 같습니다.
클러스터에서 워커 노드에 더 이상 고정 IP 주소를 사용하지 않지만 제어 영역 노드에 고정 IP 주소를 사용합니다. 따라서
network.hostConfig섹션이 필요합니다.ingressVIP값이 MetalLB 주소 풀에 표시됩니다.LoadBalancer유형의 기존 서비스에 대한 외부 IP 주소(172.16.21.81 및 172.16.21.85)가 MetalLB 주소 풀에 포함되어 있습니다.
관리자 클러스터 마이그레이션
관리자 클러스터 구성 파일에서 loadBalancer.kind를 MetalLB로 설정하고 loadBalancer.seesaw 섹션을 삭제합니다.
클러스터를 업데이트합니다.
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
다음을 바꿉니다.
ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
ADMIN_CLUSTER_CONFIG: 관리자 클러스터 구성 파일의 경로입니다.
MetalLB 구성요소가 정상적으로 실행되고 있는지 확인합니다.
kubectl --kubeconfig ADMIN_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-gke-admin.yaml 파일의 vmnames 섹션에서 Seesaw VM 이름을 찾을 수 있습니다.
예: 관리자 클러스터, 고정 IP 주소
클러스터 노드에 고정 IP 주소를 사용하는 관리자 클러스터가 있다고 가정합니다.
다음과 같이 관리자 클러스터 구성 파일을 조정합니다.
network.hostConfig섹션을 유지합니다.loadBalancer.kind을MetalLB로 설정합니다.loadBalancer.seesaw섹션을 삭제합니다.
예를 들면 다음과 같습니다.
network:
hostConfig:
dnsServers:
- "172.16.255.1"
- "172.16.255.2"
ntpServers:
- "216.239.35.0"
loadBalancer:
vips:
controlPlaneVIP: "172.16.20.30"
kind: MetalLB Seesaw
seesaw:
ipBlockFilePath: "user-cluster-1-ipblock.yaml"
vrid: 1
masterIP: ""
cpus: 4
memoryMB: 3072
앞의 예시의 요점은 다음과 같습니다.
- 클러스터에서 더 이상 Seesaw 부하 분산기를 사용하지 않더라도 클러스터 노드에 고정 IP 주소가 사용되기 때문에
network.hostConfig섹션이 필요합니다.
예: 관리자 클러스터, DHCP
클러스터 노드에 DHCP를 사용하는 관리자 클러스터가 있다고 가정합니다.
다음과 같이 관리자 클러스터 구성 파일을 조정합니다.
network.hostConfig섹션을 삭제합니다.loadBalancer.kind을MetalLB로 설정합니다.loadBalancer.seesaw섹션을 삭제합니다.
예를 들면 다음과 같습니다.
network:hostConfig: dnsServers: - "172.16.255.1" - "172.16.255.2" ntpServers: - "216.239.35.0"loadBalancer: vips: controlPlaneVIP: "172.16.20.30" kind: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-1-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072
앞의 예시의 요점은 다음과 같습니다.
- 클러스터에서 더 이상 Seesaw 부하 분산기를 사용하지 않고 클러스터는 클러스터 노드에 고정 IP 주소를 사용하지 않습니다. 따라서
network.hostConfig섹션은 필요하지 않습니다.
문제 해결
사용자 클러스터 마이그레이션 중에 gkectl update가 실패하고 사용자 클러스터에서 MetalLB 포드가 실행되고 있지 않으면 사용자 클러스터 Seesaw VM의 전원을 수동으로 켭니다.
이렇게 하면 현재 사용되는 VIP로 트래픽이 다시 설정됩니다. 하지만 load-balancer-seesaw 포드가 실행되고 있지 않으면 Seesaw VM에서 새로 생성된 VIP를 처리하지 않을 수 있습니다. 이 경우 지원 티켓을 만듭니다.
관리자 클러스터 마이그레이션 중에 gkectl update가 실패하고 관리자 클러스터에서 MetalLB 포드가 실행되고 있지 않으면 관리자 클러스터 Seesaw VM의 전원을 수동으로 켭니다. 그러면 사용자 클러스터에 현재 사용된 제어 영역 VIP에 대한 트래픽이 다시 작동할 수 있습니다. 하지만 관리자 클러스터 자체의 제어 영역 VIP가 작동하지 않을 수 있습니다. 이 경우 관리자 클러스터 제어 영역 노드의 IP 주소를 직접 사용하도록 관리자 클러스터의 kubeconfig 파일을 수정합니다.
또한 kube-system 네임스페이스에서 kube-apiserver 서비스 유형을 ClusterIP에서 LoadBalancer로 변경합니다. 필요한 경우 지원 티켓을 만듭니다.