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

  • 아티클

참고 항목

이 문서에서는 대규모 워크로드에 대한 일반적인 모범 사례에 중점을 둡니다. 중소 규모 워크로드와 관련된 모범 사례는 AKS(Azure Kubernetes Service)의 중소 규모 워크로드에 대한 성능 및 크기 조정 모범 사례를 참조하세요.

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

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

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

  • AKS 및 Kubernetes 컨트롤 플레인 확장성.
  • 백오프, 조사식, 페이지 매김을 포함한 Kubernetes 클라이언트 모범 사례입니다.
  • Azure API 및 플랫폼 제한 한도.
  • 기능 제한 사항.
  • 네트워킹 및 노드 풀 크기 조정 모범 사례.

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

AKS에서 클러스터는 Kubernetes 에이전트를 실행하고 AKS에서 호스트하는 Kubernetes 컨트롤 플레인에 의해 관리되는 노드 세트(물리적 컴퓨터 또는 VM(가상 머신))로 구성됩니다. AKS는 확장성 및 성능을 위해 Kubernetes 컨트롤 플레인 및 해당 구성 요소를 최적화하지만 여전히 업스트림 프로젝트 제한에 의해 바인딩됩니다.

Kubernetes에는 차원을 나타내는 각 리소스 종류가 포함된 다차원 크기 조정 범위가 있습니다. 모든 리소스가 동일한 것은 아닙니다. 예를 들어 조사식은 일반적으로 비밀에 설정되어 kube-apiserver에 대한 목록 호출이 발생하여 조사식이 없는 리소스에 비해 컨트롤 플레인에 비용이 추가되고 부하가 불균형적으로 높아집니다.

컨트롤 플레인은 클러스터의 모든 리소스 크기 조정을 관리하므로 특정 차원 내에서 클러스터의 크기를 더 많이 조정할수록 다른 차원 내에서 더 적게 크기를 조정할 수 있습니다. 예를 들어, AKS 클러스터에서 수십만 개의 Pod를 실행하면 컨트롤 플레인에서 지원할 수 있는 Pod 변동률(초당 Pod 돌연변이 수)에 영향을 줍니다.

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

Important

프로덕션 또는 대규모 워크로드에는 표준 또는 프리미엄 계층을 사용하는 것이 좋습니다. AKS는 Kubernetes 컨트롤 플레인을 자동으로 스케일 업하여 다음과 같은 크기 조정 제한을 지원합니다.

  • AKS 클러스터당 최대 5,000개의 노드
  • AKS 클러스터당 200,000개의 포드(Azure CNI 오버레이 포함)

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

API 우선 순위 및 공정성(APF)을 활용하여 특정 클라이언트를 제한하고 형식을 요청하여 높은 변동 및 로드 중에 컨트롤 플레인을 보호할 수 있습니다.

Kubernetes 클라이언트

Kubernetes 클라이언트는 읽기 또는 변경 작업을 수행하기 위해 kube-api 서버와 통신해야 하는 Kubernetes 클러스터에 배포된 운영자 또는 모니터링 에이전트와 같은 애플리케이션 클라이언트입니다. 이러한 클라이언트의 동작을 최적화하여 kube-api 서버 및 Kubernetes 컨트롤 플레인에 추가하는 부하를 최소화하는 것이 중요합니다.

Kube 감사 로그를 통해 API 서버 트래픽 및 클라이언트 동작을 분석할 수 있습니다. 자세한 내용은 Kubernetes 컨트롤 플레인 문제 해결을 참조하세요.

LIST 요청은 비용이 많이 들 수 있습니다. 수천 개가 넘는 작은 개체나 수백 개가 넘는 큰 개체가 있는 목록을 작업할 때는 다음 지침을 고려해야 합니다.

  • 새 리소스 종류(CRD)를 정의할 때 최종적으로 존재할 것으로 예상되는 개체 수(CR)를 고려합니다.
  • etcd 및 API 서버의 로드는 주로 반환되는 개체 수가 아니라 존재하는 개체 수에 따라 달라집니다. 필드 선택기를 사용하여 목록을 필터링하고 적은 수의 결과만 검색하더라도 이러한 지침은 계속 적용됩니다. 유일한 예외는 metadata.name으로 단일 개체를 검색하는 것입니다.
  • 코드가 메모리에서 업데이트된 개체 목록을 유지해야 하는 경우 가능하면 반복적인 LIST 호출을 피하세요. 대신 대부분의 Kubernetes 라이브러리에서 제공되는 Informer 클래스를 사용하는 것이 좋습니다. Informers는 LIST와 WATCH 기능을 자동으로 결합하여 메모리 내 컬렉션을 효율적으로 유지합니다.
  • Informers가 요구 사항을 충족하지 않는 경우 강력한 일관성이 필요한지 여부를 고려합니다. 쿼리를 실행한 정확한 순간까지의 최신 데이터를 확인해야 합니까? 그렇지 않은 경우 ResourceVersion=0을 설정합니다. 이로 인해 API 서버 캐시가 etcd 대신 요청을 처리합니다.
  • Informers 또는 API 서버 캐시를 사용할 수 없는 경우 큰 목록을 청크로 읽습니다.
  • 필요 이상으로 자주 나열하지 마십시오. Informers를 사용할 수 없는 경우 애플리케이션이 리소스를 나열하는 빈도를 고려하십시오. 큰 목록의 마지막 개체를 읽은 후 동일한 목록을 즉시 다시 쿼리하지 마세요. 대신 잠시 기다려야 합니다.
  • 클라이언트 응용 프로그램의 실행 중인 인스턴스 수를 고려하십시오. 개체를 나열하는 단일 컨트롤러를 갖는 것과 동일한 작업을 수행하는 각 노드에 Pod를 갖는 것 사이에는 큰 차이가 있습니다. 정기적으로 많은 수의 개체를 나열하는 클라이언트 응용 프로그램의 여러 인스턴스를 보유하려는 경우 솔루션이 대규모 클러스터로 확장되지 않습니다.

Azure API 및 플랫폼 제한

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

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

AKS에서 제한 관리

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

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

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

  • AKS 문제 진단 및 해결을 사용하여 오류 분석: AKS 문제 진단 및 해결을 사용하여 오류를 분석하고, 근본 원인을 식별하고 해결 권장 사항을 가져올 수 있습니다.
  • 클러스터를 다른 구독 또는 지역으로 분할: Virtual Machine Scale Sets를 사용하는 클러스터 및 노드 풀이 많은 경우 동일한 구독 내의 다른 구독 또는 지역으로 분할할 수 있습니다. 대부분의 Azure API 제한은 구독 지역 수준에서 공유되므로 클러스터를 다른 구독 또는 지역으로 이동하거나 크기를 조정하여 Azure API 제한에 대한 차단을 해제할 수 있습니다. 이 옵션은 클러스터 활동이 많을 것으로 예상되는 경우 특히 유용합니다. 이러한 제한에 대한 일반적인 지침은 없습니다. 특정 지침을 원하는 경우 지원 티켓을 만들 수 있습니다.

기능 제한 사항

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

참고 항목

컨트롤 플레인의 크기를 조정하는 작업 중에 API 서버 대기 시간이 길어지거나 최대 15분 동안 시간 제한이 발생할 수 있습니다. 지원되는 한도까지 크기 조정하는 데 문제가 계속 발생하면 지원 티켓을 개설합니다.

  • Azure 네트워크 정책 관리자(Azure npm)는 최대 250개의 노드만 지원합니다.
  • 노드 디스크 사용량, 노드 CPU/메모리 사용량, 네트워크 입/출력을 포함한 일부 AKS 노드 메트릭은 컨트롤 플레인이 크기 조정된 후 Azure Monitor 플랫폼 메트릭에서 액세스할 수 없습니다. 컨트롤 플레인이 크기 조정되었는지 확인하려면 configmap 'control-plane-scaling-status'를 찾습니다.
kubectl describe configmap control-plane-scaling-status -n kube-system
  • 노드가 100개가 넘는 클러스터에서는 중지 및 시작 기능을 사용할 수 없습니다. 자세한 내용은 AKS 클러스터 중지 및 시작을 참조하세요.

네트워킹

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

  • NAT 게이트웨이에서 2개 이상의 공용 IP가 있는 클러스터 송신에 관리 NAT를 사용합니다. 자세한 내용은 AKS 클러스터에 대한 관리 NAT 게이트웨이 만들기를 참조하세요.
  • Azure CNI 오버레이를 사용하여 클러스터당 최대 200,000개의 Pod와 5,000개의 노드를 확장할 수 있습니다. 자세한 내용은 AKS에서 Azure CNI 오버레이 네트워킹 구성을 참조하세요.
  • 애플리케이션이 클러스터 간에 직접 Pod-Pod 통신이 필요한 경우 동적 IP 할당과 함께 Azure CNI를 사용하고 Pod당 하나의 라우팅 가능한 IP를 사용하여 클러스터당 최대 50,000개의 애플리케이션 Pod까지 확장합니다. 자세한 내용은 AKS에서 동적 IP 할당을 위한 Azure CNI 네트워킹 구성을 참조하세요.
  • 내부 부하 분산 장치 뒤에서 내부 Kubernetes 서비스를 사용하는 경우 최적의 크기 조정 성능 및 부하 분산 장치 탄력성을 위해 750노드 규모 미만의 내부 부하 분산 장치 또는 서비스를 생성하는 것이 좋습니다.
  • Azure npm은 최대 250개 노드만 지원합니다. 대규모 클러스터에 네트워크 정책을 적용하려면 Azure CNI의 강력한 컨트롤 플레인과 Cilium 데이터 평면을 결합하여 고성능 네트워킹 및 보안을 제공하는 Cilium 기반 Azure CNI를 사용하는 것이 좋습니다.

노드 풀 스케일링

AKS 클러스터를 더 큰 규모 지점으로 확장할 때 다음 노드 풀 크기 조정 모범 사례를 유의하세요.

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

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

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