Share via

대규모 AKS 클러스터를 실행하거나 확장할 때 발생하는 일반적인 문제 FAQ

  • 아티클

이 문서에서는 AKS(Microsoft Azure Kubernetes Service)에서 대규모 클러스터를 실행하거나 확장할 때 발생할 수 있는 일반적인 문제에 대한 질문과 대답을 제공합니다. 대규모 클러스터는 500개 이상의 노드 규모로 실행되는 모든 클러스터입니다.

만들거나, 강화하거나, 업그레이드하는 동안 "할당량 초과" 오류가 발생합니다.

이 문제를 resolve 만들거나 확장하거나 업그레이드하려는 구독에서 지원 요청을 만들고 해당 리소스 종류에 대한 할당량을 요청합니다. 자세한 내용은 지역 컴퓨팅 할당량을 참조하세요.

고급 네트워킹을 사용하는 AKS 클러스터를 배포할 때 "insufficientSubnetSize" 오류가 발생합니다.

이 오류는 클러스터에 사용 중인 서브넷이 성공적인 리소스 할당을 위해 CIDR 내에서 더 이상 사용할 수 있는 IP가 없음을 나타냅니다. 이 문제는 업그레이드, 스케일 아웃 또는 노드 풀을 만드는 동안 발생할 수 있습니다. 이 문제는 서브넷의 무료 IP 수가 다음 수식의 결과보다 적기 때문에 발생합니다.

요청된 노드 수 * 노드 풀 --max-pod 값

필수 구성 요소

해결 방법

기존 서브넷의 CIDR 범위를 업데이트할 수 없으므로 이 문제를 resolve 새 서브넷을 만들 수 있는 권한이 있어야 합니다. 다음 단계를 따릅니다.

  1. 운영 목표에 충분한 CIDR 범위가 더 큰 새 서브넷을 다시 빌드합니다.

  2. 겹치지 않는 새 범위가 있는 새 서브넷을 Create.

  3. 새 서브넷에 새 노드 풀을 Create.

  4. 대체될 이전 서브넷에 있는 이전 노드 풀에서 Pod를 드레이닝합니다.

  5. 이전 서브넷 및 이전 노드 풀을 삭제합니다.

SNAT 포트 소모로 인해 산발적인 송신 연결 오류가 발생했습니다.

비교적 큰 규모(500개 이상의 노드)에서 실행되는 클러스터의 경우 확장성을 높이기 위해 AKS NAT(관리형 네트워크 주소 변환) 게이트웨이 를 사용하는 것이 좋습니다. Azure NAT Gateway는 IP 주소당 최대 64,512개의 아웃바운드 UDP 및 TCP 트래픽 흐름과 최대 16개의 IP 주소를 허용합니다.

관리형 NAT를 사용하지 않는 경우 SNAT(원본 네트워크 주소 변환) 고갈 및 연결 시간 제한 문제 해결을 참조하여 SNAT 포트 소모 문제를 이해하고 resolve.

Azure Portal 사용하여 최대 5,000개의 노드를 확장할 수 없습니다.

다음 단계에 따라 Azure CLI를 사용하여 최대 5,000개의 노드까지 확장합니다.

  1. 다음 명령을 실행하여 클러스터의 최소 노드 풀 수를 Create. 최대 노드 풀 노드 제한은 1,000이기 때문입니다.

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. 노드 풀을 한 번에 하나씩 확장합니다. 이상적으로, 1,000의 연속적인 스케일 업 사이 수면 시간의 5 분을 설정합니다. 다음 명령을 실행합니다.

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

업그레이드가 실행 중이지만 속도가 느립니다.

기본 구성에서 AKS는 다음 작업을 수행하여 업그레이드 중에 급증합니다.

  • 하나의 새 노드 만들기.
  • 노드 풀을 원하는 노드 수 이상으로 한 노드로 크기 조정합니다.

최대 서지 설정의 경우 한 노드의 기본값은 AKS가 기존 애플리케이션을 드레이닝하고 이전 버전의 노드를 대체하기 전에 하나의 새 노드를 만든다는 것을 의미합니다. 이 추가 노드를 사용하면 AKS에서 워크로드 중단을 최소화할 수 있습니다.

노드가 많은 클러스터를 업그레이드하는 경우 의 기본값 max-surge을 사용하는 경우 전체 클러스터를 업그레이드하는 데 몇 시간이 걸릴 수 있습니다. 노드 풀당 속성을 사용자 지정 max-surge 하여 업그레이드 속도와 업그레이드 중단 간의 절충을 가능하게 할 수 있습니다. 최대 서지 값을 늘리면 업그레이드 프로세스를 더 빨리 완료할 수 있습니다. 그러나 최대 서지 값이 크면 업그레이드 프로세스 중에 중단이 발생할 수도 있습니다.

다음 명령을 실행하여 기존 노드 풀의 최대 서지를 늘리거나 사용자 지정합니다.

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

업그레이드가 할당량(5,000개 클러스터) 제한에 도달했습니다.

이 문제를 resolve 지역별 vCPU 할당량 증가를 참조하세요.

시간 제한 오류로 인해 750개 이상의 노드에서 내부 서비스 만들기가 느리거나 실패합니다.

SLB(표준 Load Balancer) 백 엔드 풀 업데이트는 알려진 성능 병목 현상입니다. 서비스 및 SLB를 대규모로 더 빠르게 만들 수 있는 새로운 기능을 개발 중입니다. 이 문제에 대한 피드백을 보내려면 IP 기반 백 엔드 풀을 사용하는 부하 분산 장치에 대한 Azure Kubernetes 지원을 참조하세요.

해결 방법

클러스터를 750개 미만의 노드로 축소한 다음 클러스터에 대한 내부 부하 분산 장치를 만드는 것이 좋습니다. 내부 부하 분산 장치를 만들려면 다음 예제 절차에 따라 서비스 유형 및 azure-load-balancer-internal 주석을 만듭니 LoadBalancer 다.

1단계: 내부 부하 분산 장치 Create

내부 부하 분산 장치를 만들려면 다음 예제와 같이 internal-lb.yaml이라는 서비스 매니페스트와 서비스 유형 및 azure-load-balancer-internal 주석을 포함하는 LoadBalancer 서비스 매니페스트를 만듭니다.

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

2단계: 내부 부하 분산 장치 배포

명령을 사용하여 kubectl apply 내부 부하 분산 장치를 배포하고 다음 예제와 같이 YAML 매니페스트의 이름을 지정합니다.

kubectl apply -f internal-lb.yaml

클러스터를 만든 후 내부 부하 분산 장치를 프로비전하고(이 절차에 따라) 내부 부하 분산 서비스를 계속 실행할 수도 있습니다. 이렇게 하면 부하 분산 장치에 대규모로 더 많은 서비스를 추가할 수 있습니다.

대규모로 SLB 서비스 만들기를 실행하는 데 몇 시간이 걸립니다.

SLB 백 엔드 풀 업데이트는 알려진 성능 병목 현상입니다. 만들기, 업데이트 및 삭제 작업을 위해 훨씬 더 빠른 성능으로 부하 분산된 서비스를 대규모로 실행할 수 있는 새로운 기능을 개발 중입니다. 피드백을 보내려면 IP 기반 백 엔드 풀을 사용하는 부하 분산 장치에 대한 Azure Kubernetes 지원을 참조하세요.

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.