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

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

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

최대 사양

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

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

Azure 로컬 클러스터에서 각 물리적 노드의 하드웨어 구성은 다음과 같습니다.

• 섀시: Dell PowerEdge R650 서버 또는 이와 유사합니다.
• RAM: RDIMM, 3200 MT/s, 이중 순위, 총 256GB.
• CPU: 2개(2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10.4 GT/s, 30M Cache, Turbo, 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 Local에서 AKS 크기 조정을 참조하세요.

사용 가능한 VM 크기

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

Azure 등록에 지원되는 Azure 지역

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

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

Azure 로컬에서 AKS 크기 조정

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

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

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

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

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

• 최종 배포된 시스템의 대상 클러스터 수입니다.
• 모든 대상 클러스터의 제어 평면, 부하 분산 장치 및 작업자 노드를 포함한 노드 수입니다.

또한 대상 클러스터 컨트롤 플레인 노드의 크기를 확인하려면 각 대상 클러스터에 배포하려는 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 로컬 클러스터에서 하나의 실제 노드가 손실되는 것을 완전히 허용할 수 있기를 원합니다.
• 대상 클러스터를 최신 버전으로 업그레이드하도록 지원하려고 합니다.
• 대상 클러스터 컨트롤 플레인 노드 및 부하 분산 장치 노드의 고가용성을 허용하려고 합니다.
• 이러한 경우 전체 Azure 로컬 용량의 일부를 예약하려고 합니다.

제안

• 최적의 성능을 위해 한 실제 노드의 모든 리소스를 다른 7개 노드로 재배포할 수 있도록 클러스터 용량의 15% 이상(100/8=12.5)을 설정해야 합니다. 이 구성을 사용하면 업그레이드 또는 다른 AKS 2일째 작업을 수행할 수 있는 예약이 제공됩니다.

• 최대 하드웨어 크기가 8(8) 노드인 Azure 로컬 클러스터에 대한 200-VM 제한을 초과하여 확장하려면 AKS 호스트 VM의 크기를 늘려 합니다. 크기가 두 배로 증가하면 관리할 수 있는 VM 수가 약 두 배로 증가합니다. 8노드 Azure 로컬 클러스터에서는 지원되는 최대 하드웨어 사양에 설명된 Azure 로컬 권장 리소스 제한에 따라 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 로컬 배치 논리를 사용하여 사용 가능한 Azure 로컬 노드에 대상 클러스터의 각 노드 풀에 대한 작업자 노드를 분산합니다.

확실하지 않은 경우 Azure 지역 사회 포럼에 지원 또는 게시를 위해 로컬 Microsoft 사무실에 문의하세요.

다음 단계

• 스토리지 옵션