Azure Arc에서 사용하도록 설정된 AKS에 대한 리소스 제한, VM 크기 및 지역

아티클
12/22/2023

적용 대상: Azure Stack HCI 22H2의 AKS, Windows Server의 AKS

이 문서에서는 Azure Arc에서 사용하도록 설정된 AKS(Azure Kubernetes Service)에 대한 테스트된 구성, 리소스 제한, VM 크기 및 지역에 대한 정보를 제공합니다. 테스트는 Azure Stack HCI에서 AKS의 최신 릴리스를 사용했습니다.

최대 사양

Arc 배포에서 사용하도록 설정된 AKS는 지정된 최대값을 포함하여 다음 구성으로 유효성을 검사했습니다. 이러한 최대값을 초과하는 것은 사용자 고유의 위험에 있으며 예기치 않은 동작 및 실패로 이어질 수 있습니다. 이 문서에서는 일반적인 구성 실수를 방지하는 방법에 대한 몇 가지 지침을 제공하며 더 큰 구성을 만드는 데 도움이 될 수 있습니다. 확실하지 않은 경우 로컬 Microsoft 사무실에 문의하여 도움을 요청하거나 Azure Stack HCI 커뮤니티에서 질문을 제출하세요.

리소스	최대
클러스터당 물리적 서버	8
총 VM 수	200

권장 제한은 다음 표에 따라 기본 VM(가상 머신) 크기로 테스트되었습니다.

시스템 역할	VM 크기
AKS-Host	Standard_A4_v2
대상 클러스터 컨트롤 플레인 노드	기본값
대상 클러스터 HAProxy 부하 분산 장치(선택 사항)	Standard_A4_v2
대상 클러스터 Linux 작업자 노드	Standard_K8S3_v1
대상 클러스터 Windows 작업자 노드	Standard_K8S3_v1

Azure Stack HCI 클러스터에 있는 각 물리적 노드의 하드웨어 구성은 다음과 같습니다.

섀시: Dell PowerEdge R650 서버 또는 이와 유사합니다.
RAM: RDIMM, 3,200MT/s, 이중 순위, 총 256GB.
CPU: 2개(2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10.4 GT/s, 30M 캐시, 터보, HT(150W) DDR4-2666.
디스크: S2D 스토리지 구성을 지원하기 위해 8배 HDD(2TB 이상) 및 2x 1.6TB NVMe
네트워크: 4개(4개) 100Gbit NIC(Mellanox 또는 Intel).

Microsoft 엔지니어링은 위의 구성을 사용하여 Arc에서 사용하도록 설정된 AKS를 테스트했습니다. 단일 노드의 경우. 노드 2개, 노드 4개 및 노드 8개 Windows 장애 조치(failover) 클러스터. 테스트된 구성을 초과해야 하는 경우 Azure Stack HCI에서 AKS 크기 조정을 참조하세요.

중요

AKS 배포를 업그레이드하면 추가 리소스가 일시적으로 소비됩니다. 각 가상 머신은 제어 평면 노드부터 시작하여 롤링 업데이트 흐름에서 업그레이드됩니다. Kubernetes 클러스터의 각 노드에 대해 새 노드 VM이 만들어집니다. 이전 노드 VM은 워크로드가 배포되지 않도록 제한됩니다. 그러면 제한된 VM이 모든 컨테이너에서 드레이닝되어 시스템의 다른 VM에 컨테이너를 배포합니다. 그러면 드레이닝된 VM이 클러스터에서 제거되고, 종료되고, 업데이트된 새 VM으로 대체됩니다. 이 프로세스는 모든 VM이 업데이트될 때까지 반복됩니다.

사용 가능한 VM 크기

컨트롤 플레인 노드, Linux 작업자 노드 및 Windows 작업자 노드에 대한 다음 VM 크기는 Azure Stack HCI의 AKS에 사용할 수 있습니다. Standard_K8S2_v1 및 Standard_K8S_v1 같은 VM 크기는 테스트 및 낮은 리소스 요구 사항 배포에 지원되지만 이러한 크기를 주의 하여 사용하고 메모리 부족 조건으로 인해 예기치 않은 오류가 발생할 수 있으므로 엄격한 테스트를 적용합니다.

VM 크기	CPU	메모리(GB)	GPU 유형	GPU 수
Default	4	4
Standard_A2_v2	2	4
Standard_A4_v2	4	8
Standard_D2s_v3	2	8
Standard_D4s_v3	4	16
Standard_D8s_v3	8	32
Standard_D16s_v3	16	64
Standard_D32s_v3	32	128
Standard_DS2_v2	2	7
Standard_DS3_v2	2	14
Standard_DS4_v2	8	28
Standard_DS5_v2	16	56
Standard_DS13_v2	8	56
Standard_K8S_v1	4	2
Standard_K8S2_v1	2	2
Standard_K8S3_v1	4	6
Standard_NK6	6	12	Tesla T4	1
Standard_NK12	12	24	Tesla T4	2

Azure 등록에 지원되는 Azure 지역

Arc에서 사용하도록 설정된 AKS는 다음 Azure 지역에서 지원됩니다.

오스트레일리아 동부
미국 동부
동남아시아
서유럽

Azure Stack HCI에서 AKS 크기 조정

Azure Stack HCI에서 AKS 배포의 크기를 조정하려면 워크로드 및 대상 클러스터 사용률을 파악하여 미리 계획을 수립해야 합니다. 또한 총 CPU 코어, 총 메모리, 스토리지, IP 주소 등과 같은 기본 인프라의 하드웨어 리소스를 고려합니다.

다음 예제에서는 AKS 기반 워크로드만 기본 인프라에 배포된다고 가정합니다. 독립 실행형 또는 클러스터형 가상 머신 또는 데이터베이스 서버와 같은 AKS가 아닌 워크로드를 배포하면 AKS에서 사용할 수 있는 리소스를 줄일 수 있으므로 고려해야 합니다.

시작하기 전에 최대 규모와 지원해야 하는 대상 클러스터 수를 결정하기 위해 다음 사항을 고려합니다.

대상 클러스터의 Pod에 사용할 수 있는 IP 주소 수입니다.
대상 클러스터의 Kubernetes 서비스에 사용할 수 있는 IP 주소 수입니다.
워크로드를 실행하는 데 필요한 Pod 수입니다.

Azure Kubernetes Service 호스트 VM의 크기를 확인하려면 AKS 호스트 VM의 크기를 결정하는 작업자 노드 및 대상 클러스터의 수를 알고 있어야 합니다. 예를 들면 다음과 같습니다.

최종 배포된 시스템의 대상 클러스터 수입니다.
모든 대상 클러스터의 컨트롤 플레인, 부하 분산 장치 및 작업자 노드를 포함한 노드 수입니다.

참고

단일 AKS 호스트는 동일한 플랫폼에서만 대상 클러스터를 관리할 수 있습니다.

또한 대상 클러스터 컨트롤 플레인 노드의 크기를 확인하려면 각 대상 클러스터에 배포하려는 Pod, 컨테이너 및 작업자 노드의 수를 알고 있어야 합니다.

AKS에서 현재 변경할 수 없는 기본 설정

배포 중 또는 배포 후에는 현재 고객 제어에 사용할 수 없는 기본 구성 및 설정이 있습니다. 이러한 설정은 지정된 대상 클러스터의 크기를 제한할 수 있습니다.

대상 클러스터의 Kubernetes Pod에 대한 IP 주소 수는 서브넷 10.244.0.0/16으로 제한됩니다. 즉, 모든 Kubernetes 네임스페이스에서 작업자 노드당 255개의 IP 주소를 Pod에 사용할 수 있습니다. 클러스터의 각 작업자 노드에 할당된 Pod CIDR을 보려면 PowerShell에서 다음 명령을 사용합니다.

kubectl get nodes -o json | findstr 'hostname podCIDR'

                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

이 예제에서는 각각 254개의 Pod를 호스팅할 수 있는 3개의 CIDR이 있는 3개의 노드를 볼 수 있습니다. Kubernetes 크기 조정 설명서에서는 성능상의 이유로 노드당 110개의 Pod를 초과하지 않는 것이 좋습니다. 대규모 클러스터에 대한 고려 사항을 참조하세요.

기타 고려 사항:

할당한 VIP 풀 외부의 Kubernetes 서비스에 대한 IP 주소 수는 주소 풀에서 10.96.0.0/16 가져옵니다. 시스템은 Kubernetes API 서버에 사용할 수 있는 255개의 주소 중 하나를 사용합니다.
AKS 호스트 VM의 크기는 Set-AksHciConfig를 처음 실행하는 경우에만 설치 시 설정할 수 있습니다. 나중에 변경할 수도 없습니다.
대상 클러스터를 만들 때 대상 클러스터 컨트롤 플레인 및 부하 분산 장치 VM의 크기만 설정할 수 있습니다.

크기 조정 예제

다음 크기 조정 예제는 이러한 일반적인 가정/사용 사례를 기반으로 합니다.

Azure Stack HCI 클러스터에서 하나의 실제 노드 손실을 완전히 허용할 수 있어야 합니다.
대상 클러스터를 최신 버전으로 업그레이드할 수 있도록 지원하려고 합니다.
대상 클러스터 컨트롤 플레인 노드 및 부하 분산 장치 노드의 고가용성을 허용하려고 합니다.
이러한 경우 전체 Azure Stack HCI 용량의 일부를 예약하려고 합니다.

제안

최적의 성능을 위해 한 물리적 노드의 모든 리소스를 다른 7개 노드로 재배포할 수 있도록 클러스터 용량의 15% 이상(100/8=12.5)을 설정해야 합니다. 이 구성을 사용하면 업그레이드 또는 다른 AKS 2일째 작업을 수행할 수 있는 예약이 제공됩니다.
최대 하드웨어 크기 8(8) 노드 Azure Stack HCI 클러스터에 대한 200-VM 제한을 초과하여 확장하려면 AKS 호스트 VM의 크기를 늘입니다. 크기가 두 배로 증가하면 관리할 수 있는 VM 수가 약 두 배로 증가합니다. 8노드 Azure Stack HCI 클러스터에서 지원되는 최대 하드웨어 사양에 설명된 Azure Stack HCI 권장 리소스 제한에 따라 8,192(8x1024) VM을 얻을 수 있습니다. 용량의 약 30%를 예약해야 하므로 모든 노드에서 이론적으로 5,734개의 VM이 제한됩니다.
- Standard_D32s_v3 32개 코어와 128GB의 AKS 호스트에 대해 최대 1,600개의 노드를 지원할 수 있습니다.
참고

이 구성은 광범위하게 테스트되지 않았으므로 신중한 접근 방식과 유효성 검사가 필요합니다.
이와 같은 규모로 환경을 각각 200개의 작업자 노드가 있는 8개 이상의 대상 클러스터로 분할할 수 있습니다.
하나의 대상 클러스터에서 200개의 작업자 노드를 실행하려면 기본 컨트롤 플레인 및 부하 분산 장치 크기를 사용할 수 있습니다. 노드당 Pod 수에 따라 컨트롤 플레인에서 하나 이상의 크기로 이동하여 Standard_D8s_v3 사용할 수 있습니다.
각 대상 클러스터에서 호스트되는 Kubernetes 서비스의 수에 따라 부하 분산 장치 VM의 크기를 늘리고 대상 클러스터를 만들 때 높은 성능으로 서비스에 도달할 수 있고 그에 따라 트래픽이 라우팅되도록 해야 할 수 있습니다.

Arc에서 사용하도록 설정된 AKS의 배포는 Azure Stack HCI 배치 논리를 사용하여 대상 클러스터의 각 노드 풀에 대한 작업자 노드를 사용 가능한 Azure Stack HCI 노드에 분산합니다.

중요

노드 배치는 플랫폼 및 AKS 업그레이드 중에 유지되지 않으며 시간이 지남에 따라 변경됩니다. 실패한 실제 노드는 나머지 클러스터 노드에서 가상 머신의 배포에도 영향을 줍니다.

참고

물리적 클러스터가 이미 50% 가득 찬 경우 4개 이상의 대상 클러스터 만들기를 동시에 실행하지 마세요. 이로 인해 임시 리소스 경합이 발생할 수 있습니다. AKS는 병렬 실행 만들기/크기 조정 프로세스에 대한 리소스 가용성을 확인하지 않으므로 대상 클러스터 노드 풀을 많은 수만큼 확장할 때 사용 가능한 실제 리소스를 고려합니다. 항상 업그레이드 및 장애 조치(failover)를 허용할 만큼 충분한 예약을 보장합니다. 특히 매우 큰 환경에서는 이러한 작업이 병렬로 실행되면 리소스 소모가 빠르게 발생할 수 있습니다.

의심스러운 경우 Azure Stack HCI 커뮤니티 포럼에 지원 또는 게시물을 보려면 로컬 Microsoft 사무실에 문의하세요.

다음 단계

스토리지 옵션