AKS(Azure Kubernetes Service)의 Azure CNI 네트워킹 개요
기본적으로 AKS 클러스터는 kubenet을 사용하며 가상 네트워크 및 서브넷을 만듭니다. Kubenet을 사용하면 노드는 가상 네트워크 서브넷의 IP 주소를 얻습니다. 그런 다음, NAT(Network Address Translation)이 노드에서 구성되며 pod가 노드 IP 뒤에 “숨겨진” IP 주소를 받습니다. 이 방법을 사용하면 네트워크 공간에서 pod가 사용하도록 예약해야 하는 IP 주소의 수가 줄어듭니다.
Azure CNI(컨테이너 네트워킹 인터페이스)를 사용하면 모든 pod가 서브넷에서 IP 주소를 가져오고 직접 액세스할 수 있습니다. AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다. 이러한 IP 주소는 네트워크 공간에서 고유해야 하며 미리 계획되어야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다. 이 방식을 사용할 경우 더 많은 계획이 필요하며, 애플리케이션 요구가 증가하면서 IP 주소가 고갈되거나 더 큰 서브넷에서 클러스터를 구축해야 할 수 있습니다.
참고 항목
이 문서에서는 기존 Azure CNI만 소개합니다. Azure CNI 오버레이의 경우 동적 IP 할당을 위한 Azure CNI VNet 및 Azure CNI VNet - 정적 블록 할당(미리 보기). 대신 해당 설명서를 참조하세요.
필수 조건
AKS 클러스터에 대한 가상 네트워크는 아웃바운드 인터넷 연결을 허용해야 합니다.
AKS 클러스터는 Kubernetes 서비스 주소 범위, Pod 주소 범위 또는 클러스터 가상 네트워크 주소 범위에 대해
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16또는192.0.2.0/24를 사용할 수 없습니다.AKS 클러스터에서 사용되는 클러스터 ID에는 가상 네트워크 내의 서브넷에서 네트워크 기여자 이상의 권한이 있어야 합니다. 기본 제공 네트워크 참가자 역할을 사용하는 대신 사용자 지정 역할을 정의하려는 경우 다음 권한이 필요합니다.
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/readMicrosoft.Authorization/roleAssignments/write
AKS 노드 풀에 할당된 서브넷은 위임된 서브넷일 수 없습니다.
AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. 고유한 서브넷을 제공하고 해당 서브넷과 연결된 NSG를 추가하는 경우 NSG의 보안 규칙이 노드 CIDR 범위 내의 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.
클러스터에 대한 IP 주소 지정 계획
Azure CNI 네트워킹으로 구성한 클러스터에는 추가 계획이 필요합니다. 가상 네트워크 및 해당 서브넷의 크기는 실행하려는 Pod의 수와 클러스터에 대한 노드 수에 부합되어야 합니다.
Pod 및 클러스터 노드의 IP 주소는 가상 네트워크 내의 지정된 서브넷에서 할당됩니다. 각 노드는 기본 IP 주소로 구성됩니다. Azure CNI는 기본적으로 30개의 추가 IP 주소를 미리 구성합니다. 이러한 IP 주소는 노드에서 예약된 Pod에 할당됩니다. 클러스터를 스케일 아웃할 때 각 노드는 서브넷의 IP 주소로 비슷하게 구성됩니다. 노드당 최대 Pod를 확인할 수도 있습니다.
Important
필요한 IP 주소 수에는 업그레이드 및 크기 조정 작업에 대한 고려가 반영되어야 합니다. 고정 노드 수만 지원하는 IP 주소 범위를 설정할 경우 클러스터를 업그레이드하거나 스케일링할 수 없습니다.
AKS 클러스터를 업그레이드할 경우 새 노드가 클러스터에 배포됩니다. 서비스 및 워크로드가 새 노드에서 실행되기 시작하고 기존 노드가 클러스터에서 제거됩니다. 이 업그레이드 배포 프로세스를 위해서는 최소 하나의 추가 IP 주소 블록을 사용할 수 있어야 합니다. 그러면 노드 수가
n + 1입니다.- 이러한 고려 사항은 Windows Server 노드 풀을 사용할 때 특히 중요합니다. AKS의 Windows Server 노드는 Windows 업데이트를 자동으로 적용하지 않습니다. 대신 노드 풀에서 업그레이드를 수행합니다. 이 업그레이드는 최신 Windows Server 2019 기본 노드 이미지 및 보안 패치를 사용하여 새 노드를 배포합니다. Windows Server 노드 풀을 업그레이드하는 방법에 대한 자세한 내용은 AKS에서 노드 풀 업그레이드를 참조하세요.
AKS 클러스터를 확장할 경우 새 노드가 클러스터에 배포됩니다. 서비스 및 워크로드가 새 노드에서 실행되기 시작합니다. IP 주소 범위에서는 클러스터가 지원할 수 있는 노드 및 Pod 수를 조정하려는 방법을 고려해야 합니다. 업그레이드 작업에 대한 추가 노드 하나도 포함되어야 합니다. 그러면 노드 수가
n + number-of-additional-scaled-nodes-you-anticipate + 1입니다.
노드가 최대 Pod 수를 실행하고 Pod를 정기적으로 제거하고 배포하려는 경우 노드당 추가 IP 주소 역시 반영해야 합니다. 서비스를 삭제하고 새 서비스를 배포하고 주소를 획득하기 위해 해당 IP 주소를 해제하는 데 몇 초가 필요할 수 있습니다. 이러한 추가 IP 주소는 이러한 가능성을 고려합니다.
AKS 클러스터에 대한 IP 주소 계획은 노드 및 Pod에 대한 하나 이상의 서브넷에서 가상 네트워크 및 Kubernetes 서비스 주소 범위로 구성됩니다.
| 주소 범위 / Azure 리소스 | 한도 및 크기 조정 |
|---|---|
| 가상 네트워크 | Azure Virtual Network는 /8 이하일 수 있지만 구성된 IP 주소 수는 65,536개로 제한됩니다. 주소 공간을 구성하기 전에 다른 가상 네트워크의 서비스와 통신하는 등 모든 네트워킹 요구 사항을 고려하세요. 예를 들어 너무 많은 주소 공간을 구성하는 경우 네트워크 내에서 다른 주소 공간 겹침과 관련된 문제가 발생할 수 있습니다. |
| 서브넷 | 클러스터에서 프로비전될 수 있는 노드, 포드와 모든 Kubernetes 및 Azure 리소스를 수용할 만큼 커야 합니다. 예를 들어, 내부 Azure Load Balancer를 배포하는 경우, 해당 프런트 엔드 IP는 공용 IP가 아닌 클러스터 서브넷에서 할당됩니다. 서브넷 크기도 업그레이드 작업이나 향후의 크기 조정 요구를 반영해야 합니다. 다음 수식을 사용하여 업그레이드 작업에 추가 노드를 포함하여 최소 서브넷 크기를 계산합니다. 50개 노드 클러스터의 예: 추가로 10개 노드를 확장하기 위한 준비도 포함하는 50개 노드 클러스터의 예: 클러스터를 만들 때 노드당 최대 Pod를 지정하지 않으면 노드당 최대 Pod 수는 30개로 설정됩니다. 필요한 최소 IP 주소 수는 이 값을 기준으로 합니다. 다른 최댓값을 기준으로 최소 IP 주소 요구 사항을 계산하는 경우 클러스터를 배포할 때 이 값을 설정하려면 노드당 최대 Pod 수를 참조하세요. |
| Kubernetes 서비스 주소 범위 | 이 가상 네트워크의 네트워크 요소 또는 이 가상 네트워크에 연결된 모든 네트워크 요소는 이 범위를 사용하지 않아야 합니다. 서비스 주소 CIDR은 /12보다 작아야 합니다. 여러 AKS 클러스터에서 이 범위를 재사용할 수 있습니다. |
| Kubernetes DNS 서비스 IP 주소 | 클러스터 서비스 검색에서 사용되는 Kubernetes 서비스 주소 범위 내의 IP 주소입니다. 주소 범위의 첫 번째 IP 주소를 사용하지 마세요. 서브넷 범위의 첫 번째 주소는 kubernetes.default.svc.cluster.local 주소에 사용됩니다. |
노드당 최대 포드
AKS 클러스터에서 노드당 최대 Pod 수는 250개입니다. 노드당 기본 최대 pod 수는 Kubenet 및 Azure CNI 네트워킹과 클러스터 배포 방법에 따라 다릅니다.
| 배포 방법 | Kubenet 기본 | Azure CNI 기본 | 배포 시 구성 가능 |
|---|---|---|---|
| Azure CLI | 110 | 30 | 예(최대 250) |
| Resource Manager 템플릿 | 110 | 30 | 예(최대 250) |
| 포털 | 110 | 110(노드 풀 탭에서 구성 가능) | 예(최대 250) |
새 클러스터에 대한 노드당 최대 Pod 구성
클러스터 배포 시 또는 새 노드 풀을 추가할 때 노드당 최대 Pod 수를 구성할 수 있습니다. 노드당 최대 Pod 값을 최대 250으로 설정할 수 있습니다.
새 노드 풀을 만들 때 maxPods를 지정하지 않으면 Azure CNI의 기본값 30이 표시됩니다.
노드당 최대 Pod 수에 대한 최솟값은 클러스터 상태에 중요한 시스템 Pod 공간을 보장하기 위해 적용됩니다. 각 노드 풀의 구성에 최소 30개 Pod에 해당하는 공간이 있는 경우에만 노드당 최대 Pod 수에 대해 설정할 수 있는 최솟값은 10입니다. 예를 들어 노드당 최대 Pod 수를 최소 10으로 설정하려면 각 개별 노드 풀에 최소 3개의 노드가 있어야 합니다. 이 요구 사항은 생성된 새 노드 풀에도 적용되므로 10이 노드당 최대 Pod 수로 정의된 경우 추가된 각 후속 노드 풀에는 3개 이상의 노드가 있어야 합니다.
| 네트워킹 | 최소 | 최대 |
|---|---|---|
| Azure CNI | 10 | 250 |
| Kubenet | 10 | 250 |
참고 항목
이전 테이블의 최솟값은 AKS 서비스에 의해 엄격하게 적용됩니다. 표시된 최솟값보다 낮은 maxPods 값을 설정할 수 없습니다. 이렇게 하면 클러스터가 시작되지 않을 수 있습니다.
- Azure CLI: az aks create 명령을 사용하여 클러스터를 배포할 때
--max-pods인수를 지정합니다. 최댓값은 250입니다. - Resource Manager 템플릿: Resource Manager 템플릿을 사용하여 클러스터를 배포할 때 ManagedClusterAgentPoolProfile 개체에
maxPods속성을 지정합니다. 최댓값은 250입니다. - Azure Portal: 클러스터를 만들거나 새 노드 풀을 추가할 때 노드 풀 설정에서
Max pods per node필드를 변경합니다.
기존 클러스터에 대한 노드당 최대 Pod 구성
노드당 maxPods는 새 노드 풀을 만들 때 정의할 수 있습니다. 기존 클러스터에서 maxPods 설정을 늘려야 하는 경우 원하는 새 maxPods 수로 새 노드 풀을 추가합니다. Pod를 새 풀로 마이그레이션한 후에는 이전 풀을 삭제합니다. 클러스터에서 이전 풀을 삭제하려면 시스템 노드 풀 문서에 정의된 대로 노드 풀 모드를 설정해야 합니다.
배포 매개 변수
AKS 클러스터를 만들 때 Azure CNI 네트워킹에서 다음 매개 변수를 구성할 수 있습니다.
가상 네트워크: Kubernetes 클러스터를 배포하려는 가상 네트워크입니다. 클러스터에 대해 새 가상 네트워크를 만들려는 경우 새로 만들기를 선택하고 가상 네트워크 만들기 섹션의 단계를 따릅니다. 기존 가상 네트워크를 선택하려면 Kubernetes 클러스터와 동일한 위치 및 Azure 구독에 있는지 확인합니다. Azure Virtual Network의 제한 및 할당량에 대한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
서브넷: 클러스터를 배포하려는 가상 네트워크 내의 서브넷입니다. 클러스터에 대해 가상 네트워크에 새 서브넷을 만들려는 경우 새로 만들기를 선택하고 서브넷 만들기 섹션의 단계를 따릅니다. 하이브리드 연결의 경우 주소 범위가 환경의 다른 가상 네트워크와 겹쳐서는 안 됩니다.
Azure 네트워크 플러그 인: Azure 네트워크 플러그 인을 사용하는 경우 AKS 클러스터에 속하지 않은 clusterCIDR의 IP를 사용하는 VM은 “externalTrafficPolicy=Local”을 포함한 내부 부하 분산 장치 서비스에 액세스할 수 없습니다.
Kubernetes 서비스 주소 범위: 이 매개 변수는 Kubernetes가 클러스터에서 내부 서비스에 할당하는 가상 IP의 세트입니다. 클러스터를 만든 후에는 이 범위를 업데이트할 수 없습니다. 다음 요구 사항을 충족하는 모든 프라이빗 주소 범위를 사용할 수 있습니다.
- 클러스터의 가상 네트워크 IP 주소 범위에 속하지 않아야 합니다.
- 클러스터 가상 네트워크가 피어링된 다른 가상 네트워크와 겹치지 않아야 합니다.
- 온-프레미스 IP와 겹치지 않아야 합니다.
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16또는192.0.2.0/24범위 내에 있지 않아야 합니다.
기술적으로 클러스터와 동일한 가상 네트워크 내의 서비스 주소 범위를 지정할 수 있지만 이는 권장되지 않습니다. 겹치는 IP 범위를 사용한 경우 예측할 수 없는 동작이 발생할 수 있습니다. 자세한 내용은 이 문서의 FAQ 섹션을 참조하세요. Kubernetes 서비스에 자세한 내용은 Kubernetes 설명서의 서비스를 참조하세요.
Kubernetes DNS 서비스 IP 주소: 클러스터의 DNS 서비스의 IP 주소입니다. 이 주소는 Kubernetes 서비스 주소 범위 내에 있어야 합니다. 주소 범위의 첫 번째 IP 주소를 사용하지 마세요. 서브넷 범위의 첫 번째 주소는 kubernetes.default.svc.cluster.local 주소에 사용됩니다.
자주 묻는 질문
내 클러스터 서브넷에 VM을 배포할 수 있나요?
예. 그러나 동적 IP 할당을 위한 Azure CNI의 경우 VM을 Pod의 서브넷에 배포할 수 없습니다.
Azure CNI 지원 Pod에서 발생하는 트래픽에 대해 외부 시스템에서 확인하는 원본 IP는 무엇인가요?
AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다.
그러나 동적 IP 할당을 위한 Azure CNI의 경우 연결이 동일한 가상 네트워크 또는 가상 네트워크 간 내에 있더라도 Pod IP는 항상 Pod의 트래픽에 대한 원본 주소입니다. 동적 IP 할당을 위한 Azure CNI가 엔드 투 엔드 환경을 제공하는 Microsoft Azure Container Networking 인프라를 구현하기 때문입니다. 따라서 기존 Azure CNI에서
ip-masq-agent여전히 사용되는 사용을 제거합니다.Pod별 네트워크 정책을 구성할 수 있나요?
예, Kubernetes 네트워크 정책은 AKS에서 사용할 수 있습니다. 시작하려면 AKS에서 네트워크 정책을 사용하여 Pod 간 트래픽 보호를 참조하세요.
구성 가능한 노드로 배포할 수 있는 Pod의 최대 수는 얼마나 되나요?
예. Azure CLI 또는 Resource Manager 템플릿을 사용하여 클러스터를 배포할 경우입니다. 노드당 최대 포드를 참조하세요.
기존 클러스터의 노드당 최대 Pod 수는 변경할 수 없습니다.
AKS 클러스터를 만드는 동안 만든 서브넷에 대해 추가 속성을 구성하려면 어떻게 해야 하나요? 예를 들어 서비스 엔드포인트가 있습니다.
AKS 클러스터를 만드는 동안 만든 가상 네트워크와 서브넷에 대한 속성의 전체 목록은 Azure Portal의 표준 가상 네트워크 구성 페이지에서 구성할 수 있습니다.
Kubernetes Service 주소 범위에 대해 내 클러스터 가상 네트워크 내의 다른 서브넷을 사용할 수 있나요?
권장되지 않지만 이 구성은 가능합니다. 서비스 주소 범위는 Kubernetes가 클러스터의 내부 서비스에 할당하는 VIP(가상 IP)의 세트입니다. Azure 네트워킹은 Kubernetes 클러스터의 서비스 IP 범위를 볼 수 없습니다. 클러스터의 서비스 주소 범위에 대한 가시성이 부족하면 문제가 발생할 수 있습니다. 나중에 서비스 주소 범위와 겹치는 클러스터 가상 네트워크에 새 서브넷을 만들 수 있습니다. 이러한 중복이 발생하는 경우 Kubernetes는 예기치 않은 동작이나 오류를 일으키는, 서브넷의 다른 리소스에서 이미 사용 중인 IP를 서비스에 할당할 수 있습니다. 클러스터의 가상 네트워크 외부에서 주소 범위를 사용하는 것을 확인하여 겹치는 위험을 방지할 수 있습니다.
다음 단계
AKS의 네트워킹에 대한 자세한 내용은 다음 문서를 참조하세요.