Azure CNI(Container Networking Interface) Pod 서브넷

Azure CNI Pod 서브넷은 클러스터 노드의 별도의 서브넷의 Pod에 IP 주소를 할당합니다. 이 기능은 동적 IP 할당 및 정적 블록 할당(미리 보기)의 두 가지 모드에서 사용할 수 있습니다.

필수 조건

참고 항목

CIDR의 정적 블록 할당을 사용하는 경우 Kubernetes Load Balancer 서비스를 사용하여 애플리케이션을 Private Link 서비스로 노출하는 것은 지원되지 않습니다.

• 이 문서에도 동일한 필수 조건이 적용되므로 AKS에서 기본 Azure CNI 네트워킹을 구성하기 위한 필수 조건을 검토합니다.

• AKS에서 기본 Azure CNI 네트워킹을 구성하려면 동일한 매개 변수가 적용되므로 배포 매개 변수를 검토합니다.

• AKS 엔진 및 DIY 클러스터는 지원하지 않습니다.

• Azure CLI 버전 2.37.0 이상 및 aks-preview 확장 버전 2.0.0b2 이상.

• 구독에 대한 구독 수준 기능 플래그인 'Microsoft.ContainerService/AzureVnetScalePreview'를 등록합니다.

• 기존 클러스터가 있는 경우 IP 서브넷 사용량 추가 항목을 모니터링할 수 있도록 컨테이너 인사이트를 사용하도록 설정해야 합니다. 다음 예제와 같이 az aks enable-addons 명령을 사용하여 컨테이너 인사이트를 사용하도록 설정할 수 있습니다.

  az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
  

동적 IP 할당 모드

동적 IP 할당은 AKS 클러스터를 호스팅하는 서브넷과는 별개인 서브넷에서 Pod IP를 할당하여 Pod IP 주소 고갈 문제를 완화하는 데 도움이 됩니다.

동적 IP 할당 모드는 다음과 같은 이점을 제공합니다.

• IP 사용률 향상: IP가 Pod 서브넷에서 클러스터 Pod으로 동적으로 할당됩니다. 이로 인해 모든 노드에 대해 IP의 정적 할당을 수행하는 기존 CNI 솔루션과 비교하여 클러스터의 IP 사용률이 향상됩니다.
• 확장성 및 유연성: 노드 및 Pod 서브넷은 독립적으로 크기를 조정할 수 있습니다. 단일 Pod 서브넷은 클러스터의 여러 노드 풀에서 또는 동일한 VNet에 배포된 여러 AKS 클러스터에서 공유할 수 있습니다. 또한 노드 풀에 대해 별도의 Pod 서브넷을 구성할 수 있습니다.
• 고성능: Pod가 VNet IP를 할당받으므로 VNet의 다른 클러스터 Pod 및 리소스에 직접 연결됩니다. 솔루션은 성능 저하 없이 매우 큰 클러스터를 지원합니다.
• Pod에 대한 별도 VNet 정책: Pod에 별도의 서브넷이 있으므로 노드 정책과 다른 별도의 VNet 정책을 구성할 수 있습니다. 이를 통해 노드가 아닌 Pod에 대해서만 인터넷 연결을 허용하고, Azure NAT Gateway를 사용하여 노드 풀에서 Pod의 원본 IP를 수정하고, NSG(네트워크 보안 그룹)를 사용하여 노드 풀 간의 트래픽을 필터링하는 등의 많은 유용한 시나리오가 가능해 집니다.
• Kubernetes 네트워크 정책: Azure 네트워크 정책 및 Calico는 모두 이 모드로 작동합니다.

IP 주소 지정 계획

동적 IP 할당을 사용하면 노드와 Pod가 독립적으로 확장되므로 주소 공간을 별도로 계획할 수 있습니다. Pod 서브넷은 노드 풀의 세분성으로 구성될 수 있으므로 노드 풀을 추가할 때 언제든지 새 서브넷을 추가할 수 있습니다. 클러스터/노드 풀의 시스템 Pod는 Pod 서브넷에서 IP를 수신하기 때문에 이 동작을 고려해야 합니다.

IP는 16개의 일괄 처리로 노드에 할당됩니다. Pod 서브넷 IP 할당은 클러스터의 노드당 최소 16 IP로 계획해야 합니다. 이는 노드가 시작 시 16개의 IP를 요청하고 할당에 할당되지 않은 <8개의 IP가 있을 때마다 16개의 또 다른 일괄 처리를 요청하기 때문입니다.

Kubernetes 서비스 및 Docker 브리지에 대한 IP 주소 계획은 변경되지 않습니다.

정적 블록 할당 모드(미리 보기)

정적 블록 할당은 개별 IP가 아닌 노드에 CIDR 블록을 할당하여 잠재적인 Pod 서브넷 크기 조정 및 Azure 주소 매핑 제한을 완화하는 데 도움이 됩니다.

정적 블록 할당 모드는 다음과 같은 이점을 제공합니다.

• 향상된 IP 확장성: CIDR 블록은 클러스터 노드에 정적으로 할당되며 기존 CNI를 사용하는 개별 IP의 기존 동적 할당과는 달리 노드의 수명 동안 존재합니다. 이를 통해 CIDR 블록을 기반으로 라우팅할 수 있으며 클러스터당 기존 65,000개의 Pod에서 최대 100만 개의 Pod까지 클러스터 제한을 확장할 수 있습니다. Azure Virtual Network는 클러스터의 규모를 수용할 수 있을 만큼 충분히 커야 합니다.
• 확장성: 노드 및 Pod 서브넷은 독립적으로 크기를 조정할 수 있습니다. 단일 Pod 서브넷은 클러스터의 여러 노드 풀에서 또는 동일한 VNet에 배포된 여러 AKS 클러스터에서 공유할 수 있습니다. 또한 노드 풀에 대해 별도의 Pod 서브넷을 구성할 수 있습니다.
• 고성능: Pod에는 가상 네트워크 IP가 할당되므로 VNet의 다른 클러스터 Pod 및 리소스에 직접 연결됩니다.
• Pod에 대한 별도 VNet 정책: Pod에 별도의 서브넷이 있으므로 노드 정책과 다른 별도의 VNet 정책을 구성할 수 있습니다. 이를 통해 노드가 아닌 Pod에 대해서만 인터넷 연결을 허용하고, Azure NAT Gateway를 사용하여 노드 풀에서 Pod의 원본 IP를 수정하고, NSG를 사용하여 노드 풀 간의 트래픽을 필터링하는 등의 많은 유용한 시나리오가 가능해 집니다.
• Kubernetes 네트워크 정책: Cilium, Azure NPM 및 Calico는 이 솔루션을 사용합니다.

제한 사항

다음은 Azure CNI 정적 블록 할당 사용의 몇 가지 제한 사항입니다.

• 필요한 최소 Kubernetes 버전은 1.28입니다.
• 지원되는 최대 서브넷 크기는 x.x.x.x/12 ~ 100만 IP입니다.
• 서브넷당 단일 작업 모드만 사용할 수 있습니다. 서브넷에서 정적 블록 할당 모드를 사용하는 경우 동일한 서브넷이 있는 다른 클러스터 또는 노드 풀에서 동적 IP 할당 모드를 사용할 수 없으며 그 반대의 경우도 마찬가지입니다.
• 새 클러스터에서만 지원되거나 다른 서브넷이 있는 노드 풀을 기존 클러스터에 추가할 때만 지원됩니다. 기존 클러스터 또는 노드 풀 마이그레이션 또는 업데이트는 지원되지 않습니다.
• 노드 풀의 노드에 할당된 모든 CIDR 블록에서 하나의 IP가 노드의 기본 IP로 선택됩니다. 따라서 --max-pods 값을 선택하는 네트워크 관리자의 경우 아래 계산을 사용하여 요구 사항을 가장 잘 충족하고 서브넷에서 IP를 최적으로 사용하도록 합니다.

max_pods = (N * 16) - 1(N은 양의 정수이고 N> 0)

사용 가능 지역

이 기능은 다음 지역에서 사용할 수 없습니다.

• 미국 남부
• 미국 동부 2
• 미국 서부
• 미국 서부 2

IP 주소 지정 계획

정적 블록 할당을 사용하면 노드와 Pod가 독립적으로 확장되므로 주소 공간을 별도로 계획할 수 있습니다. Pod 서브넷은 노드 풀의 세분성으로 구성될 수 있으므로 노드 풀을 추가할 때 언제든지 새 서브넷을 추가할 수 있습니다. 클러스터/노드 풀의 시스템 Pod는 Pod 서브넷에서 IP를 수신하기 때문에 이 동작을 고려해야 합니다.

노드당 최대 Pod 수를 정의하는 노드 풀에 대한 --max-pods 구성에 따라 /28(16개 IP)의 CIDR 블록이 노드에 할당됩니다. 내부 목적을 위해 해당 노드의 사용 가능한 모든 IP에서 각 노드에 1개의 IP가 예약되어 있습니다.

IP를 계획하는 동안 max_pods_per_node = (16 * N) - 1(N은 0보다 큰 양의 정수) 계산을 사용하여 --max-pods 구성을 정의하는 것이 중요합니다.

IP 낭비가 없는 이상적인 값은 위의 식을 준수하기 위해 최대 Pod 값이 필요합니다.

다음 예제 사례를 참조하세요.

예제 사례	max_pods	노드당 할당된 CIDR 블록	Pod에 사용할 수 있는 총 IP	노드에 대한 IP 낭비
낮은 낭비(허용 가능)	30	2	(16 * 2) - 1 = 32 - 1 = 31	31 - 30 = 1
이상적인 사례	31	2	(16 * 2) - 1 = 32 - 1 = 31	31 - 31 = 0
높은 낭비(권장되지 않음)	32	3	(16 * 3) - 1 = 48 - 1 = 47	47 - 32 = 15

Kubernetes 서비스에 대한 IP 주소 계획은 변경되지 않습니다.

참고 항목

VNet에 클러스터의 규모를 지원하기에 충분히 크고 연속적인 주소 공간이 있는지 확인합니다.