Azure CNI(Container Networking Interface) 오버레이 네트워킹

Azure CNI 오버레이를 사용하면 클러스터 노드가 Azure VNet(Virtual Network) 서브넷에 배포됩니다. Pod에는 노드를 호스트하는 VNet과 논리적으로 다른 프라이빗 CIDR의 IP 주소가 할당됩니다. 클러스터 내의 Pod 및 노드 트래픽은 오버레이 네트워크를 사용합니다. NAT(Network Address Translation)는 노드의 IP 주소를 사용하여 클러스터 외부의 리소스에 연결합니다. 이 솔루션은 상당한 양의 VNet IP 주소를 저장하고 클러스터를 대규모로 크기 조정할 수 있도록 해줍니다. 또한 다양한 AKS 클러스터에서 프라이빗 CIDR을 재사용할 수 있으므로, 이를 통해 AKS(Azure Kubernetes Service)의 컨테이너화된 애플리케이션에 사용할 수 있는 IP 공간을 확장할 수 있습니다.

오버레이 네트워킹 개요

오버레이 네트워킹에서는 Kubernetes 클러스터 노드에만 서브넷의 IP가 할당됩니다. Pod는 클러스터 만들 때 제공된 프라이빗 CIDR로부터 IP를 수신합니다. 각 노드에는 동일한 CIDR에서 얻은 /24 주소 공간이 할당됩니다. 클러스터를 스케일 아웃할 때 만들어진 추가 노드는 동일한 CIDR에서 자동으로 /24 주소 공간을 수신합니다. Azure CNI는 이 /24 공간의 Pod에 IP를 할당합니다.

Pod의 프라이빗 CIDR 공간에 대한 Azure 네트워킹 스택에 별도의 라우팅 도메인이 만들어지며, 이때 Pod 간 직접 통신을 위한 오버레이 네트워크가 만들어집니다. 클러스터 서브넷에서 사용자 지정 경로를 프로비전하거나 캡슐화 방법을 사용하여 Pod 간 트래픽을 터널링할 필요가 없습니다. 이는 VNet의 VM과 동등한 Pod 간 연결 성능을 제공합니다. Pod 내에서 실행되는 워크로드는 네트워크 주소 조작이 발생하고 있다는 사실조차 인식하지 못합니다.

온-프레미스 및 피어링된 VNet과 같은 클러스터 외부 엔드포인트와의 통신은 NAT를 통해 노드 IP를 사용하여 발생합니다. Azure CNI는 트래픽의 원본 IP(Pod의 오버레이 IP)를 VM의 기본 IP 주소로 변환하며, 따라서 Azure 네트워킹 스택이 트래픽을 대상으로 라우팅할 수 있게 됩니다. 클러스터 외부의 엔드포인트는 Pod에 직접 연결할 수 없습니다. VNet에서 연결할 수 있도록 Pod의 애플리케이션을 Kubernetes Load Balancer 서비스로 게시해야 합니다.

표준 SKU Load Balancer 또는 관리 NAT Gateway를 사용하여 오버레이 Pod에 인터넷에 대한 아웃바운드(송신) 연결을 제공할 수 있습니다. 클러스터 서브넷에서 사용자 정의 경로를 사용하여 송신 트래픽을 방화벽으로 전달하는 방식으로 송신 트래픽을 제어할 수도 있습니다.

Nginx 또는 HTTP 애플리케이션 라우팅과 같은 수신 컨트롤러를 사용하여 클러스터에 대한 수신 연결을 구성할 수 있습니다. Azure App Gateway를 사용하여 수신 연결을 구성할 수 없습니다. 자세한 내용은 Azure CNI 오버레이 제한 사항을 참조하세요.

kubenet과 Azure CNI 오버레이의 차이점

다음 표에는 kubenet과 Azure CNI 오버레이의 차이점이 자세히 비교되어 있습니다.

지역	Azure CNI 오버레이	kubenet
클러스터 스케일링	노드 5000개 및 Pod/노드 250개	노드 400개 및 Pod/노드 250개
네트워크 구성	단순 - Pod 네트워킹에 추가 구성이 필요 없음	복합 - Pod 네트워킹을 사용하려면 클러스터 서브넷에 경로 테이블과 UDR 필요
Pod 연결 성능	VNet의 VM과 동등한 성능	추가 홉으로 인해 약간의 대기 시간이 추가됨
Kubernetes 네트워크 정책	Azure 네트워크 정책, Calico, Cilium	Calico
지원되는 OS 플랫폼	Linux 및 Windows Server 2022, 2019	Linux만

IP 주소 계획

클러스터 노드

AKS 클러스터를 설정할 때 VNet 서브넷에 향후 크기 조정을 위해 성장할 수 있는 충분한 공간이 있는지 확인합니다. 각 노드 풀을 전용 서브넷에 할당할 수 있습니다.

처음 3개의 IP 주소는 관리 작업용으로 예약되어 있으므로 /24 서브넷은 최대 251개의 노드를 수용할 수 있습니다.

Pod

오버레이 솔루션은 클러스터를 만드는 동안 지정하는 프라이빗 CIDR의 모든 노드에 있는 Pod에 /24 주소 공간을 할당합니다. 크기가 /24로 고정되어 있으므로 늘리거나 줄일 수 없습니다. 한 노드에서 최대 250개의 Pod를 실행할 수 있습니다.

Pod의 IP 주소 공간을 계획할 때 다음 요소를 고려합니다.

• 향후 클러스터 확장을 지원할 수 있도록 새 노드의 /24 주소 공간을 제공할 수 있을 만큼 프라이빗 CIDR이 충분히 커야 합니다.
• 동일한 Pod CIDR 공간을 동일한 VNet에 있는 여러 독립 AKS 클러스터에서 사용할 수 있습니다.
• Pod CIDR 공간이 클러스터 서브넷 범위와 겹치면 안 됩니다.
• Pod CIDR 공간은 직접 연결된 네트워크(예: VNet 피어링, ExpressRoute 또는 VPN)와 겹쳐서는 안 됩니다. 외부 트래픽에 podCIDR 범위의 원본 IP가 있는 경우 클러스터와 통신하려면 SNAT를 통해 겹치지 않는 IP로 변환해야 합니다.

Kubernetes 서비스 주소 범위

서비스 주소 CIDR의 크기는 만들려는 클러스터 서비스 수에 따라 달라집니다. /12보다 작아야 합니다. 이 범위는 피어링된 VNet 및 온-프레미스 네트워크에 사용되는 Pod CIDR 범위, 클러스터 서브넷 범위 및 IP 범위와 겹쳐서는 안 됩니다.

Kubernetes DNS 서비스 IP 주소

이 IP 주소는 클러스터 서비스 검색에서 사용하는 Kubernetes 서비스 주소 범위 내에 있습니다. 주소 범위의 첫 번째 IP 주소는 kubernetes.default.svc.cluster.local 주소가 사용되므로 주소를 사용하지 마세요.

네트워크 보안 그룹

Azure CNI 오버레이를 사용하는 Pod-Pod 트래픽은 캡슐화되지 않으며 서브넷 네트워크 보안 그룹 규칙이 적용됩니다. 서브넷 NSG에 Pod CIDR 트래픽에 영향을 주는 거부 규칙이 포함된 경우 적절한 클러스터 기능(모든 AKS 송신 요구 사항 외에)을 보장하기 위해 다음 규칙이 있는지 확인합니다.

• 노드 CIDR에서 모든 포트 및 프로토콜의 노드 CIDR로의 트래픽
• 모든 포트 및 프로토콜에서 노드 CIDR에서 Pod CIDR로의 트래픽(서비스 트래픽 라우팅에 필요)
• 모든 포트 및 프로토콜에서 포드 CIDR에서 포드 CIDR로의 트래픽(Pod에서 Pod로, Pod에서 서비스로의 트래픽(DNS 포함)에 필요)

Pod에서 Pod CIDR 블록 외부의 대상으로의 트래픽은 SNAT를 활용하여 원본 IP를 Pod가 실행되는 노드의 IP로 설정합니다.

클러스터의 워크로드 간 트래픽을 제한하려면 네트워크 정책을 사용하는 것이 좋습니다.

노드당 최대 포드

클러스터를 만들 때 또는 새 노드 풀을 추가할 때 노드당 최대 Pod 수를 구성할 수 있습니다. Azure CNI 오버레이의 기본값과 최댓값은 250이며 최솟값은 10입니다. 노드 풀을 만드는 동안 구성된 노드당 최대 Pod 수는 해당 노드 풀의 노드에만 적용됩니다.

사용할 네트워크 모델 선택

Azure CNI는 Pod에 두 가지 IP 주소 지정 옵션 제공: 하나는 Pod에 VNet IP를 할당하는 기존 구성이고, 다른 하나는 오버레이 네트워킹입니다. AKS 클러스터에 사용할 옵션을 선택할 때 중요한 것은 유연성과 고급 구성 요구 사항 간의 균형입니다. 다음 고려 사항은 각 네트워크 모델이 가장 적합한 경우를 대략적으로 알려줍니다.

다음과 같은 경우 오버레이 네트워킹 사용:

• Pod 수를 대량으로 스케일링하고 싶지만 VNet의 IP 주소 공간이 제한되어 있습니다.
• Pod 통신 대부분이 클러스터 내에 있습니다.
• 가상 노드와 같은 고급 AKS 기능이 필요하지 않습니다.

다음과 같은 경우 기존 VNet 옵션 사용:

• 사용 가능한 IP 주소 공간이 있습니다.
• Pod 통신 대부분이 클러스터 외부의 리소스를 대상으로 진행됩니다.
• 클러스터 외부의 리소스는 Pod에 직접 연결해야 합니다.
• 가상 노드와 같은 AKS 고급 기능이 필요합니다.

Azure CNI 오버레이의 제한 사항

Azure CNI 오버레이에는 다음과 같은 제한 사항이 있습니다.

• 수신 컨트롤러(AGIC)로 Application Gateway를 사용할 수 없습니다.
• VMAS(가상 머신 가용성 집합)는 지원되지 않습니다.
• 노드 풀에서는 DCsv2 시리즈 가상 머신을 사용할 수 없습니다. 기밀 컴퓨팅 요구 사항을 충족하려면 대신 DCasv5 또는 DCadsv5 시리즈 기밀 VM을 사용하는 것이 좋습니다.
• 사용자 고유의 서브넷을 사용하여 클러스터를 배포하는 경우 서브넷, VNet을 포함하는 리소스 그룹의 이름은 63자 이하여야 합니다. 이러한 이름은 AKS 작업자 노드에서 레이블로 사용되며 Kubernetes 레이블 구문 규칙이 적용됩니다.