AKS(Azure Kubernetes Service) 대규모 워크로드의 성능 및 크기 조정에 대한 모범 사례

AKS에서 클러스터를 배포하고 유지 관리하는 경우 다음 모범 사례를 사용하여 성능 및 크기 조정을 최적화할 수 있습니다.

크다는 것은 상대적인 용어라는 점을 명심하세요. Kubernetes에는 다차원적인 크기 조정 범위가 있으며 워크로드의 크기 조정 범위는 사용하는 리소스에 따라 다릅니다. 예를 들어 100개의 노드와 수천 개의 Pod 또는 CRD가 있는 클러스터는 대규모로 간주될 수 있습니다. 1,000개의 Pod와 다양한 기타 리소스가 포함된 1,000개의 노드 클러스터는 컨트롤 플레인 관점에서 볼 때 작은 것으로 간주될 수 있습니다. Kubernetes 컨트롤 플레인의 규모에 가장 적합한 신호는 API 서버 HTTP 요청 성공률 및 대기 시간입니다. 이는 컨트롤 플레인의 로드 양에 대한 프록시이기 때문입니다.

이 문서에서는 다음에 대해 알아봅니다.

노드 크기 조정

AKS 클러스터를 더 큰 확장점으로 확장할 때 다음 노드 크기 조정 모범 사례를 염두에 두세요.

• 대규모 AKS 클러스터를 실행하는 경우 가능하면 클러스터 자동 크기 조정기 또는 노드 자동 프로비저닝을 사용하여 컴퓨팅 리소스에 대한 수요에 따라 노드의 동적 크기 조정을 보장합니다.
• 1,000개 이상의 노드를 확장하고 클러스터 자동 크기 조정기를 사용하지 않는 경우 한 번에 500~700개의 노드를 일괄적으로 확장하는 것이 좋습니다. 크기 조정 작업은 Azure API 제한을 방지하기 위해 강화 작업 간에 2분에서 5분 정도 대기해야 합니다. 자세한 내용은 API 관리: 캐싱 및 제한 정책을 참조하세요.
• 시스템 노드 풀의 경우 Standard_D16ds_v5 SKU 또는 임시 OS 디스크가 있는 동등한 코어/메모리 VM SKU를 사용하여 kube-system Pod에 충분한 컴퓨팅 리소스를 제공합니다.
• AKS에는 노드 풀당 노드가 1,000개로 제한되므로 노드를 최대 5,000개까지 확장하려면 사용자 노드 풀을 5개 이상 만드는 것이 좋습니다.

AKS 및 Kubernetes 컨트롤 플레인 확장성

Kubernetes에서 클러스터에서 실행되는 모든 개체는 AKS에서 관리하는 컨트롤 플레인에 의해 관리됩니다. AKS는 확장성 및 성능을 위해 Kubernetes 컨트롤 플레인 및 해당 구성 요소를 최적화하지만 여전히 업스트림 프로젝트 제한에 의해 바인딩됩니다.

Kubernetes는 각 리소스 유형이 하나의 차원을 나타내는 다차원 구조로 이루어져 있으며, 모든 리소스가 비용 측면에서 동일하지는 않습니다. 예를 들어, Secrets는 여러 컨트롤러 및 Pod에 의해 감시되는 경우가 많고, 각 컨트롤러와 Pod는 상태를 동기화하기 위한 초기 LIST 호출을 수행합니다. 비밀은 일반적으로 크고, 자주 업데이트되기 때문에 덜 자주 감시되는 리소스보다 컨트롤 플레인에 더 많은 부하를 줍니다.

지정된 차원 내에서 클러스터의 크기를 조정할수록 다른 차원 내에서 크기를 조정할 수 있는 크기가 줄어듭니다. 예를 들어, AKS 클러스터에서 수십만 개의 Pod를 실행하면 컨트롤 플레인에서 지원할 수 있는 Pod 변동률(초당 Pod 돌연변이 수)에 영향을 줍니다.

AKS는 기본 SKU의 일부로 무료, 표준 및 프리미엄 계층의 세 가지 컨트롤 플레인 계층을 지원합니다. 자세한 내용은 AKS 클러스터 관리에 대한 무료, 표준 및 프리미엄 가격 책정 계층을 참조하세요.

대부분의 경우 크기 조정 제한 임계값을 초과하면 성능이 저하되지만 클러스터가 즉시 장애 조치(failover)되지는 않습니다. Kubernetes 컨트롤 플레인의 로드를 관리하려면 현재 규모의 최대 10~20%를 일괄로 크기 조정하는 것이 좋습니다. 예를 들어 5,000개 노드 클러스터의 경우 500~1,000개 노드 단위로 확장합니다. AKS는 컨트롤 플레인의 크기를 자동으로 조정하지만 즉시 조정되지는 않습니다.

컨트롤 플레인이 확장되었는지 확인하려면 configmap large-cluster-control-plane-scaling-status을 찾습니다.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Kubernetes 확장 한계 및 컨트롤 플레인 고려 사항

Kubernetes 클라이언트는 클러스터에서 실행되고 kube-apiserver와 통신하여 리소스를 읽거나 수정하는 연산자 또는 모니터링 에이전트와 같은 애플리케이션 구성 요소입니다. 이러한 클라이언트가 kube-apiserver 및 Kubernetes 컨트롤 플레인에 배치하는 부하를 줄이기 위해 동작하는 방식을 최적화하는 것이 중요합니다.

지정된 순간에 API 서버에서 적극적으로 처리되는 요청 수는 플래그에 따라 --max-requests-inflight--max-mutating-requests-inflight 결정됩니다. AKS는 이러한 플래그에 대해 400 및 200 요청의 기본값을 사용하므로 지정된 시간에 총 600개의 요청을 디스패치할 수 있습니다. API 서버를 더 큰 크기로 확장할 때 그에 따라 기내 요청도 증가합니다.

두 Kubernetes 개체 형식인 PriorityLevelConfiguration 및 APF(FlowSchema)는 API 서버가 총 요청 용량을 요청 유형 간에 나누는 방법을 결정합니다. AKS는 기본 구성을 사용합니다.

각 PriorityLevelConfiguration에는 허용되는 총 요청의 공유가 할당됩니다. 클러스터의 PriorityLevelConfiguration 개체와 할당된 요청 공유를 보려면 다음 명령을 실행합니다.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema는 API 서버 요청을 PriorityLevelConfiguration에 매핑합니다. 여러 FlowSchema 개체가 요청과 일치하는 경우 API 서버는 일치하는 우선 순위가 가장 낮은 개체를 선택합니다.

다음 명령을 사용하여 FlowSchemas를 PriorityLevelConfigurations에 매핑할 수 있습니다.

kubectl get flowschemas

APF로 인해 요청이 삭제되는지 확인하려면 다음 명령을 실행합니다.

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Kubernetes 클라이언트 모범 사례

최적이 아닌 클라이언트에서 발급된 LIST 호출은 클러스터의 확장성을 제한하는 가장 큰 요인 중 하나입니다. 수천 개가 넘는 작은 개체나 수백 개가 넘는 큰 개체가 있는 목록을 작업할 때는 다음 지침을 고려해야 합니다.

• 새 리소스 종류(CRD)를 정의할 때 최종적으로 존재할 것으로 예상되는 개체 수(CR)를 고려합니다.
• etcd 및 API 서버의 로드는 주로 응답의 크기에 의존합니다. 이 지침은 클라이언트가 큰 개체에 대해 적은 수의 LIST 요청을 발급하는지 아니면 더 작은 개체에 대해 많은 수의 LIST 요청을 발급하는지에 따라 적용됩니다.

정보 제공자 사용

• 코드가 메모리에 업데이트된 개체 목록을 유지해야 하는 경우 클라이언트 이동 라이브러리의 정보 제공자를 사용하면 변경 내용을 폴링하는 대신 이벤트를 기반으로 리소스의 변경 내용을 감시하는 이점이 제공됩니다. 이는 최적화되지 않고 반복되는 LIST를 방지하는 가장 좋은 방법입니다.

API 서버 캐시 사용

• API 서버 캐시에서 결과를 반환하는 데 사용합니다 resourceVersion=0 . 이렇게 하면 객체가 etcd에서 페치되는 것을 방지하여, 그로 인해 etcd의 부하를 줄일 수 있지만 페이징을 지원하지 않습니다.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

효율적인 Kubernetes API 사용

• 가능하면 watch 인수를 사용하는 것이 좋습니다. 인수가 없도록 기본 동작은 개체를 나열하는 것입니다. 아래 예제를 참조하세요.

  /api/v1/namespaces/default/pods?watch=true
  

  이 감시 기능을 사용할 때는 resourceVersion을 이전 목록이나 감시 기능에서 수신한 가장 최근의 알려진 값으로 설정하세요. client-go 에서 자동으로 처리됩니다. 그러나 다른 언어로 Kubernetes 클라이언트를 사용하고 있는지 확인합니다.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• 컨트롤러 또는 연산자가 LIST 호출을 사용해야 하는 경우 특히 큰 클러스터에서 레이블 또는 필드 선택기 없이 클러스터 전체 리소스를 폴링하지 않아야 합니다. 다음 예제에서는 최적화되고 최적화되지 않은 LIST 호출을 보여 줍니다.

  최적화된 목록:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  최적이 아닌 목록:

  /api/v1/pods
  

• 클라이언트가 etcd에서 데이터를 가져와야 하는 경우 페이지 매김을 사용하여 LIST 응답의 크기를 줄입니다. 다음 예제에서는 제한 인수를 사용하여 응답을 100 개체로 제한합니다.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  LIST가 위의 예제에서 모든 Pod 개체를 계속 반환하도록 하려면 제한이 있는 continue 인수를 사용합니다.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  kubectl을 사용하는 경우, --chunk-size 인수를 직접 적용하여 응답을 페이지 단위로 나눌 수 있습니다.

  kubectl get pods -n default --chunk-size=100
  

• 컨트롤러 또는 운영자가 리더 선거에 임대 업데이트를 사용하는 경우, leaseDuration, renewDeadline, retryPeriod을/를 튜닝하여 일시적인 연결 문제에 강하고 워크로드에 최적인지 확인합니다. 클라이언트 이동 리더 선거를 사용하는 Kubernetes 컨트롤러의 경우 다음 수식을 사용합니다.

  lease_duration > renew_deadline > retry_period
  

디먼셋

• 개체를 나열하는 단일 컨트롤러와 동일한 작업을 수행하는 모든 노드에서 실행되는 DaemonSet 간에는 상당한 차이가 있습니다. 클라이언트 애플리케이션의 여러 인스턴스가 정기적으로 많은 수의 개체를 나열하는 경우 솔루션은 큰 클러스터에서 잘 확장되지 않습니다.

• 수천 개의 노드가 있는 클러스터에서 새 DaemonSet을 만들거나, DaemonSet을 업데이트하거나, 노드 수를 늘리면 컨트롤 플레인에 높은 부하가 발생할 수 있습니다. DaemonSet Pod가 Pod 시작 시 비용이 많이 드는 API 서버 요청을 실행하는 경우 많은 수의 동시 요청에서 컨트롤 플레인에서 높은 리소스 사용이 발생할 수 있습니다.

• RollingUpdate 전략을 사용하여 새 DaemonSet Pod를 점진적으로 롤아웃합니다. DaemonSet 템플릿이 업데이트되면 컨트롤러는 이전 Pod를 제어된 방식으로 새 Pod로 바꿉니다. 롤링 업데이트 전략이 명시적으로 구성되지 않은 경우 Kubernetes는 기본적으로 maxUnavailable을 1로, maxSurge를 0으로, minReadySeconds를 0으로 사용하여 RollingUpdate를 만듭니다. 다음 예제를 참조하세요.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• RollingUpdate 전략은 기존 DaemonSet Pod에만 적용됩니다. 새 노드를 추가하거나, 추가 DaemonSet Pod를 만들거나, 완전히 새로운 DaemonSets를 배포하는 영향을 제한하지 않습니다.

• 노드 스케일 아웃 또는 새 DaemonSet 배포 후 시작 중에 DaemonSets가 API 서버에 동시 LIST 요청을 발급하지 않도록 하려면 컨테이너 진입점에서 시작 지터를 구현하고 5xx 또는 429 응답에 대한 적절한 지수 백오프 및 재시도 정책을 구성하여 대규모 LIST 요청의 반복 재시도를 방지합니다.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

etcd 최적화

• 전체 etcd의 크기를 작게 유지하고 etcd를 범용 데이터베이스로 사용하지 마세요. AKS는 기본적으로 8GB의 etcd 스토리지를 제공하지만, etcd 데이터베이스가 클수록 조각 모음 시간이 늘어나서 읽기 및 쓰기 성능 문제가 발생할 수 있습니다. 또한 더 큰 etcd 데이터베이스는 최적이 아닌 클라이언트가 etcd에서 많은 수의 개체를 자주 가져오는 경우 API 서버 및 etcd 안정성 문제의 확률을 높일 수 있습니다. etcd 데이터베이스 크기가 2GB를 초과하는 경우 아래에 나열된 개체 크기 감소 기술을 사용하는 것이 좋습니다.
• Pod 사양 크기를 줄이려면 환경 변수를 Pod 사양에서 ConfigMaps로 이동합니다.
• 큰 비밀 또는 ConfigMaps를 더 작고 관리하기 쉬운 조각으로 분할합니다.
• 가능한 경우 Kubernetes 비밀 대신 Azure Key Vault 저장하여 etcd에 저장된 비밀 수를 줄입니다.
• 사용하지 않는 개체 정리
  • 오래된 작업 및 완료된 Pod를 삭제합니다. 완료된 개체가 자동으로 제거되도록 작업에서 ttlSecondsAfterFinished을 사용합니다.
  • 컨트롤러가 ownerReferences를 설정했는지 확인합니다. 이를 통해 Kubernetes 가비지 수집은 부모 리소스가 삭제될 때 종속 개체를 자동으로 제거할 수 있습니다.
  • 성공한JobsHistoryLimit 및 failedJobsHistoryLimit를 설정하여 CronJob 기록을 제한하여 소수의 완료된 작업 레코드만 유지합니다.
  • 배포 히스토리를 축소합니다. 이전 ReplicaSets도 API 개체로 저장됩니다. 기본값은 10입니다.
• 인수를 사용하여 Helm 수정 기록을 줄입니다 --history-max . 큰 클러스터에서 5 미만을 유지합니다.

AKS 컨트롤 플레인 메트릭 및 로그 모니터링

대규모 AKS 클러스터에서 컨트롤 플레인 메트릭을 모니터링하는 것은 Kubernetes 워크로드의 안정성과 성능을 보장하는 데 매우 중요합니다. 이러한 메트릭은 API 서버, etcd, 컨트롤러 관리자 및 스케줄러와 같은 중요한 구성 요소의 상태 및 동작에 대한 가시성을 제공합니다. 리소스 경합 및 높은 API 호출 볼륨이 일반적인 대규모 환경에서 컨트롤 플레인 메트릭을 모니터링하면 병목 상태를 식별하고, 변칙을 검색하고, 자원 배정 현황을 최적화할 수 있습니다. 운영자는 이러한 메트릭을 분석하여 API 서버 대기 시간, 높은 etcd 개체 또는 과도한 컨트롤 플레인 리소스 사용과 같은 문제를 사전에 해결할 수 있으므로 효율적인 클러스터 작업을 보장하고 가동 중지 시간을 최소화할 수 있습니다.

Azure Monitor는 Azure 관리형 Prometheus 및 진단 설정을 통해 컨트롤 플레인의 상태에 대한 포괄적인 메트릭과 로그를 제공합니다.

• 컨트롤 플레인의 상태를 구성할 경고 목록은 AKS 컨트롤 플레인 모니터링에 대한 모범 사례를 확인하세요.
• 대기 시간이 가장 긴 사용자 에이전트 목록을 얻으려면 컨트롤 플레인 로그/진단 설정을 사용할 수 있습니다.

주요 제어 플레인 플랫폼 지표

AKS는 API 서버 및 etcd 상태를 모니터링하기 위해 Azure Monitor 다음 플랫폼 메트릭을 노출합니다. 이러한 메트릭은 Managed Prometheus를 사용하지 않고 사용할 수 있으며 AKS 클러스터에 대한 Metrics 아래의 Azure 포털에서 직접 볼 수 있습니다.

API 서버 메트릭:

Etcd metrics:

API 서버에서 리소스 압력을 지속적으로 모니터링하고 apiserver_cpu_usage_percentageapiserver_memory_usage_percentage 감지합니다. 지속적으로 50개%초과하는 경우 etcd_database_usage_percentageEtcd Optimizations 섹션을 검토하여 데이터베이스 크기를 줄입니다. 사용 가능한 메트릭의 전체 목록은 AKS 모니터링 데이터 참조를 참조하세요.

기능 제한 사항

AKS 클러스터를 더 큰 규모 지점으로 확장할 때 다음 기능 제한 사항에 유의하세요.

• AKS는 모든 표준 계층/LTS 클러스터에 대해 기본적으로 최대 5,000개의 노드 크기 조정을 지원합니다. AKS는 클러스터 크기 및 API 서버 리소스 사용률을 기반으로 런타임 시 클러스터의 컨트롤 플레인의 크기를 조정합니다. 지원되는 한도까지 확장할 수 없는 경우, 제어 평면 메트릭(프리뷰)을 Azure Monitor 관리 서비스 for Prometheus와 함께 사용하도록 설정하여 제어 평면을 모니터링합니다. 크기 조정 성능 또는 안정성 문제를 해결하려면 다음 리소스를 참조하세요.

  • AKS 규모의 문제 해결 가이드
  • Kubernetes 컨트롤 플레인 문제 해결

  참고

  컨트롤 플레인의 크기를 조정하는 작업 중에 API 서버 대기 시간이 길어지거나 최대 15분 동안 시간 제한이 발생할 수 있습니다. 지원되는 제한으로 확장하는 데 계속 문제가 있는 경우 지원 티켓 엽니다.

• Azure 네트워크 정책 관리자(Azure npm) 최대 250개의 노드만 지원합니다.

• 노드 디스크 사용량, 노드 CPU/메모리 사용량 및 네트워크 인/아웃을 포함한 일부 AKS 노드 메트릭은 컨트롤 플레인을 확장한 후 Azure 모니터 플랫폼 메트릭 액세스할 수 없습니다.

• 노드가 100개가 넘는 클러스터에서는 중지 및 시작 기능을 사용할 수 없습니다. 자세한 내용은 AKS 클러스터 중지 및 시작을 참조하세요.

Azure API 및 플랫폼 스로틀링

클라우드 응용 프로그램의 부하는 활성 사용자 수, 사용자가 수행하는 작업 유형 등의 요인에 따라 시간이 지남에 따라 달라질 수 있습니다. 시스템의 처리 요구 사항이 사용 가능한 리소스의 용량을 초과하면 시스템이 오버로드되어 성능 저하 및 오류가 발생할 수 있습니다.

클라우드 응용 프로그램에서 다양한 로드 크기를 처리하기 위해 응용 프로그램이 지정된 한도까지 리소스를 사용하도록 허용한 다음, 한도에 도달하면 제한할 수 있습니다. Azure에서는 스로틀링이 두 가지 수준에서 발생합니다. ARM(Azure Resource Manager)은 구독 및 테넌트에 대한 요청을 제한합니다. 요청이 구독 및 테넌트의 제한 한도 하에 있는 경우 ARM은 리소스 공급자에게 요청을 라우팅합니다. 그런 다음, 리소스 공급자는 해당 작업에 맞게 조정된 제한 한도를 적용합니다. 자세한 내용은 ARM 제한 요청을 참조하세요.

AKS에서 제한 관리

Azure API 제한은 일반적으로 구독 지역 조합 수준에서 정의됩니다. 예를 들어 지정된 지역의 구독 내의 모든 클라이언트는 지정된 Azure API에 대한 API 제한을 공유합니다(예: VIRTUAL MACHINE SCALE SETS PUT API). 모든 AKS 클러스터에는 클라우드 공급자 또는 클러스터 자동 크기 조정기 같은 여러 AKS 소유 클라이언트 또는 데이터독 또는 자체 호스팅 Prometheus와 같은 고객 소유 클라이언트가 Azure API를 호출합니다. 지정된 지역 내의 구독에서 여러 AKS 클러스터를 실행하는 경우 클러스터 내의 모든 AKS 소유 및 고객 소유 클라이언트는 공통 API 제한 집합을 공유합니다. 따라서 구독 지역에 배포할 수 있는 클러스터 수는 배포된 클라이언트 수, 해당 호출 패턴 및 클러스터의 전체 규모 및 탄력성에 따라 달라집니다.

위의 고려 사항을 염두에 두고 고객은 일반적으로 구독 지역당 20~40개의 중소 규모 클러스터를 배포할 수 있습니다. 다음 모범 사례를 사용하여 구독 규모를 최대화할 수 있습니다.

항상 Kubernetes 클러스터를 최신 버전으로 업그레이드합니다. 최신 버전에는 성능 및 제한 문제를 해결하는 많은 개선 사항이 포함되어 있습니다. 업그레이드된 버전의 Kubernetes를 사용 중이고 실제 부하 또는 구독의 클라이언트 수로 인해 여전히 제한이 표시되는 경우 다음 옵션을 사용해 볼 수 있습니다.

• AKS 진단 및 문제 해결을 사용하여 오류 분석: AKS 진단 및 문제 해결 을 사용하여 오류를 분석하고 근본 원인을 식별하고 해결 권장 사항을 가져올 수 있습니다.
  • 클러스터 자동 크기 조정기 검사 간격 늘리기: 진단 보고서에서 클러스터 오토스케일러 스로틀링이 감지됨이 표시되면, 클러스터 오토스케일러에서 Virtual Machine Scale Sets로의 호출 수를 줄이기 위해 스캔 간격을 늘릴 수 있습니다.
  • 호출을 줄이도록 타사 애플리케이션 다시 구성: 요청 비율 및 제한 세부 정보 보기 진단에서 사용자 에이전트를 기준으로 필터링하고 모니터링 애플리케이션과 같은 타사 애플리케이션이 많은 수의 GET 요청을 만드는 것을 확인하는 경우 이러한 애플리케이션의 설정을 변경하여 GET 호출 빈도를 줄일 수 있습니다. 애플리케이션 클라이언트가 Azure API를 호출할 때 지수 백오프를 사용하는지 확인합니다.
• 클러스터를 다른 구독 또는 지역으로 분할: Virtual Machine Scale Sets 사용하는 클러스터 및 노드 풀이 많은 경우 동일한 구독 내의 다른 구독 또는 지역으로 분할할 수 있습니다. 대부분의 Azure API 제한은 구독 지역 수준에서 공유되므로 클러스터를 다른 구독 또는 지역으로 이동하거나 확장하여 Azure API 제한에서 차단을 해제할 수 있습니다. 이 옵션은 클러스터 활동이 많을 것으로 예상되는 경우 특히 유용합니다. 이러한 제한에 대한 일반적인 지침은 없습니다. 특정 지침을 원하는 경우 지원 티켓을 만들 수 있습니다.

네트워킹

AKS 클러스터를 더 큰 규모 지점으로 확장할 때 다음 네트워킹 모범 사례를 유의하세요.

• NAT 게이트웨이에서 2개 이상의 공용 IP가 있는 클러스터 송신에 관리 NAT를 사용합니다. 자세한 내용은 AKS 클러스터에 대한 관리 NAT 게이트웨이 만들기를 참조하세요.

• Azure 표준 Load Balancer 사용하는 경우 2 아웃바운드 공용 IP 이상을 사용합니다. 또한 대규모 클러스터를 계획할 때 LoadBalancer 서비스 백 엔드 규칙 제한을 고려합니다. Azure 표준 Load Balancer는 프런트 엔드 IP당 최대 10,000개의 백 엔드 IP 구성을 지원합니다. 각 유형: LoadBalancer 서비스는 노출된 포트당 하나의 부하 분산 규칙을 만들고 모든 클러스터 노드를 부하 분산 장치 백 엔드 풀과 연결합니다. 예를 들어 단일 서비스에 대해 5개의 포트를 노출하면 노드 2000개에서 이 제한에 도달합니다.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Azure CNI 오버레이를 사용하여 클러스터당 최대 200,000개의 Pod 및 5,000개의 노드를 확장합니다. 자세한 내용은 AKS Azure CNI 오버레이 네트워킹 구성을 참조하세요.

• 애플리케이션이 클러스터 간에 직접 Pod 간 통신이 필요한 경우 동적 IP 할당으로 Azure CNI를 사용하고 Pod당 하나의 라우팅 가능한 IP를 사용하여 클러스터당 최대 50,000개의 애플리케이션 Pod를 확장합니다. 자세한 내용은 AKS 동적 IP 할당에 대한 Azure CNI 네트워킹 구성을 참조하세요.

• 내부 부하 분산 장치 뒤에서 내부 Kubernetes 서비스를 사용하는 경우 최적의 크기 조정 성능 및 부하 분산 장치 탄력성을 위해 750노드 규모 미만의 내부 부하 분산 장치 또는 서비스를 생성하는 것이 좋습니다.

• Azure NPM(네트워크 정책 관리자)은 최대 250개의 노드만 지원합니다. 더 큰 클러스터에 대한 네트워크 정책을 적용하려면 Cilium 기반의 Azure CNI를 사용하여 고성능 네트워킹 및 보안을 제공하기 위해 Azure CNI의 강력한 제어 평면과 Cilium 데이터 평면을 결합하는 것이 좋습니다.

• 노드 풀에서 LocalDNS 를 사용하도록 설정하여 DNS 확인 대기 시간을 줄이고 중앙 집중식 CoreDNS Pod를 오프로드합니다. DNS 쿼리 볼륨이 높은 대규모 클러스터에서 중앙 집중식 DNS 확인은 병목 상태가 될 수 있습니다. LocalDNS는 각 노드에 DNS 프록시를 systemd 서비스로 배포하여, 로컬에서 쿼리를 해결하고, conntrack 테이블의 압력을 제거하며, 경합 조건을 방지하기 위해 TCP로 연결을 업그레이드합니다 conntrack. 또한 LocalDNS는 업스트림 DNS를 사용할 수 없는 경우 부실 캐시된 응답을 지원하여 일시적인 실패 시 워크로드 복원력을 향상합니다. 자세한 내용은 AKS의 DNS 확인을 참조하세요.

클러스터 업그레이드 고려 사항 및 모범 사례

• 클러스터가 5,000개 노드 한도에 도달하면 클러스터 업그레이드가 차단됩니다. 이 제한은 최대 서지 속성 제한 내에서 롤링 업데이트를 수행할 수 있는 노드 용량이 없기 때문에 업그레이드를 방지합니다. 클러스터가 이 한도에 도달한 경우 클러스터 업그레이드를 시도하기 전에 노드 3,000개 미만으로 클러스터를 축소하는 것이 좋습니다. 이렇게 하면 노드 변동을 위한 추가 용량이 제공되고 컨트롤 플레인의 부하가 최소화됩니다.
• 노드가 500개 이상인 클러스터를 업그레이드하는 경우 노드 풀 용량의 최대 서지 구성 을 10-20% 사용하는 것이 좋습니다. AKS는 최대 급증에 대해 기본값 10%로 업그레이드를 구성합니다. 노드 풀당 최대 일시 급증 설정을 사용자 지정하여 업그레이드 속도와 워크로드 중단 간의 균형을 유지할 수 있습니다. 최대 서지 설정을 늘리면 업그레이드 프로세스가 더 빠르게 완료되지만 업그레이드 프로세스 중에 중단될 수도 있습니다. 자세한 내용은 노드 서지 업그레이드 사용자 지정을 참조하세요.
• 클러스터 업그레이드에 대한 자세한 내용은 AKS 클러스터 업그레이드를 참조하세요.