AKS(Azure Kubernetes Service)의 기본 Load Balancer에서 업그레이드

이 문서에서는 기본 Load Balancer 인스턴스를 AKS(Azure Kubernetes Services)의 표준 Load Balancer로 업그레이드하는 방법을 알아봅니다. 모든 프로덕션 인스턴스에 표준 Load Balancer를 사용하는 것이 좋습니다. 인프라에 많은 주요 차이점을 제공합니다. 기본 Load Balancer에서 AKS 외부의 표준 Load Balancer로 업그레이드하는 방법에 대한 지침은 기본 Load Balancer 업그레이드에 대한 공식 지침을 참조하세요.

중요합니다

2025년 9월 30일부터 AKS(Azure Kubernetes Service)는 더 이상 기본 Load Balancer를 지원하지 않습니다. 잠재적인 서비스 중단을 방지하려면 새 배포에 표준 Load Balancer 를 사용하고 기존 배포를 표준 Load Balancer로 업그레이드하는 것이 좋습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지 GitHub 문제 및 Azure 업데이트 사용 중지 공지 사항을 참조하세요. 공지 사항 및 업데이트에 대한 정보를 유지하려면 AKS 릴리스 정보를 따르세요.

Note

가용성 집합과 기본 Load Balancer를 모두 사용하는 클러스터의 경우 한 번에 두 마이그레이션을 모두 수행하기 위해 실행해야 하는 별도의 az aks update 명령이 있습니다(Virtual Machine 노드 풀에 대한 가용성 집합 및 표준 Load Balancer에 대한 기본 Load Balancer). 이 마이그레이션을 수행하는 단계는 가용성 집합 마이그레이션 지침을 참조하세요.

시작하기 전 주의 사항:

마이그레이션을 시작하기 전에 다음 정보를 검토합니다.

  • 마이그레이션 중에 가동 중지 시간이 발생합니다. 그에 따라 가동 중지 시간을 계획합니다.
  • 마이그레이션이 시작되면 롤백이 허용되지 않습니다.
  • 이 프로세스는 부하 분산 장치와 연결된 인바운드 IP 주소를 동일하게 유지하면서 기본 IP를 표준 IP로 마이그레이션합니다. 새 공용 IP가 만들어져 표준 Load Balancer 아웃바운드 규칙에 연결되어 클러스터 송신 트래픽을 처리합니다.

필수 조건

마이그레이션을 수행하려면 먼저 클러스터가 다음 필수 조건을 충족해야 합니다.

  • 이 스크립트의 최소 Kubernetes 버전은 1.27입니다. AKS 클러스터를 업그레이드해야 하는 경우 AKS 클러스터 업그레이드를 참조하세요.
  • Azure CLI를 설치해야 합니다. 필요한 최소 버전은 2.76.0입니다.
  • 클러스터가 프라이빗 키 자격 증명 모음을 사용하여 키 관리 서비스를 실행하는 경우 마이그레이션을 수행하기 전에 키 관리 서비스를 사용하지 않도록 설정해야 합니다. 자세한 내용은 KMS 끄기를 참조하세요.
  • 마이그레이션을 수행하기 전에 사용하지 ValidatingAdmissionWebhooksMutatingAdmissionWebhooks 않도록 설정해야 합니다.

기본 Load Balancer를 표준 Load Balancer로 업그레이드

  1. az aks update 명령을 사용하고 --load-balancer-sku 플래그를 Standard로 설정하여 기본 Load Balancer를 표준 Load Balancer로 업그레이드합니다.

    az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku=Standard

  2. 명령을 사용하여 마이그레이션에 성공했는지 확인합니다 az aks show .

    az aks show \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP

    출력에서 형식이 load-balancer .로 설정되어 있는지 확인합니다 Standard.

  3. 모든 Pod 및 서비스가 성공적으로 실행되고 있는지 kubectl get pods 및 kubectl get svc 명령을 사용하여 확인합니다.

    kubectl get svc -A
kubectl get pods -A

새 아웃바운드 IP 주소 확인

IP 주소에 대한 리소스 ID를 확인한 다음 IP 주소를 나열하여 아웃바운드 규칙과 연결된 새 IP 주소를 확인할 수 있습니다.

  1. 명령을 사용하여 아웃바운드 IP 주소에 대한 리소스 ID를 az aks show 가져옵니다.

    az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

  2. 명령을 사용하여 각 리소스 ID에 대한 새 IP 주소를 가져옵니다 az network public-ip show .

    az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv

자주 묻는 질문(FAQ)

새 AKS 클러스터를 만들거나 업그레이드할 때 Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'.이 발생하는 이유는 왜인가요?

Microsoft는 특정 AKS 작업에 대해 기본 Load Balancer SKU를 더 이상 사용하지 않으며 일부 지역에서는 생성이 차단되었습니다.

이 문제를 해결하려면 새 클러스터를 만들 때 지정 --load-balancer-sku standard 해야 합니다. 다음은 그 예입니다.

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

기본 로드 밸런서를 현재 위치에서 표준 로드 밸런서로 변경할 수 없는 이유는 무엇인가요?

Load Balancer SKU는 클러스터가 소유한 관리되는 리소스이므로 AKS에서 만든 후에 변경할 수 없습니다.

다음 옵션 중 하나를 사용하여 이 문제를 해결할 수 있습니다.

  • 옵션 1: 명령을 사용하여 az aks update run 기본 Load Balancer를 표준으로 업그레이드합니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 기본 Load Balancer 업그레이드를 참조하세요.
  • 옵션 2: 표준 Load Balancer(청록색 마이그레이션)를 사용하여 새 AKS 클러스터를 만들고 기존 워크로드를 이동합니다.

기본에서 표준 Load Balancer로 업그레이드한 후 공용 IP를 찾을 수 없는 이유는 무엇인가요?

Load Balancer 개체는 마이그레이션 중에 공용 IP 리소스에 대한 참조를 손실했습니다. IP가 기본 SKU Load Balancer에 연결되어 있고 반등하지 않은 경우에 발생할 수 있습니다.

이 문제를 해결하려면:

  1. 새 표준 공용 IP가 올바른 리소스 그룹에 있는지 확인합니다.

  2. 다음 구성을 사용하여 서비스 매니페스트에서 다시 연결합니다.

    annotations:
  service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>

공용 IP 없이 프라이빗 클러스터에서 부하 분산 장치를 마이그레이션할 때 마이그레이션하는 동안 공용 IP가 여전히 생성되는 이유는 무엇인가요?

outboundType가 LoadBalancer인 경우, AKS는 Load Balancer SKU에 관계없이 PIP(공용 IP)를 자동으로 프로비전합니다.

이 문제를 해결하려면:

  1. outboundType을 userDefinedRouting로 변경하여 완전히 프라이빗 클러스터로 만드십시오.
  2. 사용자 지정 아웃바운드 라우팅이 Azure Firewall/NVA를 통해 구성되었는지 확인합니다.

내부 Load Balancer 설정에서 마이그레이션이 실패하는 이유는 무엇인가요?

현재 마이그레이션 도구는 기본에서 표준으로의 현재 위치 내부 가상 네트워크 Load Balancer를 지원하지 않습니다.

이 문제를 해결하려면:

  1. 표준 Load Balancer를 사용하여 동일한 VNet에서 클러스터를 다시 만듭니다.
  2. 워크로드를 배포하고 내부 이름 해석을 검증합니다.

내 노드 풀에서 가용성 집합을 사용하고 있습니다. Load Balancer 마이그레이션 후에도 문제가 계속 발생하나요?

예. 노드 풀에서 가용성 집합을 사용하는 경우 2025년 9월 30일 이후 AKS에서도 사용되지 않습니다.

이 문제를 해결하려면:

  1. 가용성 집합과 기본 Load Balancer를 모두 사용하는 클러스터의 경우 한 번에 두 마이그레이션을 모두 수행하기 위해 실행해야 하는 별도의 az aks update 명령이 있습니다(Virtual Machine 노드 풀에 대한 가용성 집합 및 표준 Load Balancer에 대한 기본 Load Balancer). 이 마이그레이션을 수행하는 단계는 가용성 집합 마이그레이션 지침을 참조하세요.
  2. 업그레이드 후 Azure CLI 또는 REST API를 사용하여 CRUD 작업을 수행하거나 풀을 관리해야 합니다. 제한 사항을 확인합니다.

업그레이드하기 전에 기본 웹후크를 삭제해야 하나요?

아니요. 다른 ValidatingAdmissionWebhooks와 MutatingAdmissionWebhooks가 클러스터에 없는 경우, 마이그레이션하는 동안 컨트롤 플레인의 기본 웹후크를 유지하는 것만으로 충분합니다.

기본 웹후크는 다음과 같습니다.

  • aks-node-mutating-webhook
  • webhook-admission-controller
  • node-validating-webhook

마이그레이션 명령을 실행하는 데 필요한 액세스 권한은 무엇인가요?

마이그레이션 명령을 실행하려면 다음이 필요합니다.

  • 구독 또는 리소스 그룹의 기여자 또는 소유자 역할
  • Azure CLI 버전은 ≥ 2.72.0이어야 합니다.
  • AKS 미리 보기 확장 버전은 0.5.170 이상이어야 합니다.

KMS(키 관리 서비스) 암호화가 비활성화되었는지 어떻게 확인할 수 있나요?

명령을 사용하여 az aks list AKS 클러스터에서 KMS 암호화를 사용할 수 있는지 확인할 수 있습니다.

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

  • 출력이 표시 "KmsEnabled": null되면 KMS 암호화가 해당 클러스터에 대해 활성화되지 않음을 의미하며, 어떤 단계도 건너뛰어 사용하지 않도록 설정할 수 있습니다. 다음은 그 예입니다.

      {

    "KeyId": null,

    "KmsEnabled": null,

    "Name": "myAKSCluster"

  },
...

  • KMS를 사용하도록 설정하고 사용하지 않도록 설정하려면 KMS 암호화 해제를 참조하세요.

다음 단계

AKS 네트워킹에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에 대한 네트워킹 개념을 참조하세요.

  • Last updated on