AKS(Azure Kubernetes Service) CNI 네트워킹 개요
Kubernetes는 CNI(Container Networking Interface) 플러그 인을 사용하여 Kubernetes 클러스터에서 네트워킹을 관리합니다. CPI는 Pod에 IP 주소를 할당하고, Pod 간 네트워크 라우팅, Kubernetes Service 라우팅 등을 담당합니다.
AKS는 네트워킹 요구 사항에 따라 클러스터에서 사용할 수 있는 여러 CNI 플러그 인을 제공합니다.
AKS의 네트워킹 모델
AKS 클러스터에 대한 CNI 플러그 인을 선택하는 것은 주로 요구 사항에 가장 적합한 네트워킹 모델에 따라 달라집니다. 각 모델에는 AKS 클러스터를 계획할 때 고려해야 하는 고유한 장점과 단점이 있습니다.
AKS는 두 가지 주요 네트워킹 모델인 오버레이 네트워크 및 플랫 네트워크를 사용합니다.
두 네트워킹 모델 모두 지원되는 여러 CNI 플러그 인 옵션이 있습니다. 모델 간의 주요 차이점은 Pod IP 주소가 할당되는 방식과 트래픽이 클러스터를 나가는 방식에 있습니다.
오버레이 네트워크
오버레이 네트워킹은 Kubernetes에서 사용되는 가장 일반적인 네트워킹 모델입니다. 오버레이 네트워크에서 Pod에는 AKS 노드가 배포된 Azure VNet 서브넷과 논리적으로 분리된 프라이빗 CIDR의 IP 주소가 제공됩니다. 이렇게 하면 플랫 네트워크 모델보다 더 간단하고 종종 더 나은 확장성을 확보할 수 있습니다.
오버레이 네트워크에서 Pod는 서로 직접 통신할 수 있습니다. 클러스터에서 나가는 트래픽은 노드의 IP 주소로 SNAT(Source Network Address Translate)되며, 인바운드 Pod IP 트래픽은 부하 분산 장치와 같은 일부 서비스를 통해 라우팅됩니다. 즉, Pod IP 주소는 노드의 IP 주소 뒤에 "숨겨집니다". 이 방법을 활용하면 클러스터에 필요한 VNet IP 주소 수가 줄어듭니다.
Azure Kubernetes Service는 오버레이 네트워킹을 위한 다음과 같은 CNI 플러그 인을 제공합니다.
- Azure CNI 오버레이: 대부분의 시나리오에 권장되는 CNI 플러그 인입니다.
- kubenet: 레거시 오버레이 모델 CNI입니다.
플랫 네트워크
오버레이 네트워크와 달리 AKS의 플랫 네트워크 모델은 AKS 노드와 동일한 Azure VNet의 서브넷에서 Pod에 IP 주소를 할당합니다. 즉, 클러스터에서 나가는 트래픽이 SNAT되지 않으며 Pod IP 주소는 대상에 직접 노출됩니다. 이는 Pod IP 주소를 외부 서비스에 노출해야 하는 경우와 같은 일부 시나리오에 유용할 수 있습니다.
Azure Kubernetes Service는 오버레이 네트워킹을 위한 두 가지 CNI 플러그 인을 제공합니다. 이 문서에서는 각 플러그 인 옵션에 대해 자세히 설명하지 않습니다. 자세한 내용은 연결된 설명서를 참조하세요.
- Azure CNI Pod 서브넷: 플랫 네트워킹 시나리오에 권장되는 CNI 플러그 인입니다.
- Azure CNI 노드 서브넷: 레거시 플랫 네트워크 모델 CNI는 일반적으로 클러스터에 대한 관리형 VNet이 필요한 경우에만 사용하는 것이 좋습니다.
CNI 선택
CNI를 선택할 때 고려해야 할 몇 가지 요소가 있습니다. 각 네트워킹 모델에는 고유한 장점과 단점이 있으며 클러스터에 가장 적합한 선택은 특정 요구 사항에 따라 달라집니다.
네트워킹 모델 선택
AKS의 두 가지 주요 네트워킹 모델은 오버레이 네트워크와 플랫 네트워크입니다.
오버레이 네트워크:
- Pod에 대해 논리적으로 구분된 CIDR 범위를 사용하여 VNet IP 주소 공간을 절약합니다.
- 최대 클러스터 크기 조정 지원.
- 단순한 IP 주소 관리.
플랫 네트워크:
- Pod는 전체 VNet 연결을 가져오고 연결된 네트워크에서 개인 IP 주소를 통해 직접 연결할 수 있습니다.
- 조각화되지 않은 대규모 VNet IP 주소 공간이 필요합니다.
사용 사례 비교
네트워킹 모델을 선택할 때 각 CNI 플러그 인의 사용 사례와 사용하는 네트워크 모델 유형을 고려합니다.
| CNI 플러그 인 | 네트워킹 모델 | 사용 사례 주요 사항 |
|---|---|---|
| Azure CNI 오버레이 | 오버레이 | - VNET IP 절약에 가장 적합 - API 서버에서 지원하는 최대 노드 수 + 노드당 Pod 250개 - 더 간단한 구성 - 직접 외부 Pod IP 액세스 없음 |
| Azure CNI Pod 서브넷 | 플랫 | - 직접 외부 Pod IP 액세스 - 효율적인 VNet IP 사용 또는 대규모 클러스터 확장 지원을 위한 모드(미리 보기) |
| Kubenet(레거시) | 오버레이 | - IP 절약 우선 순위 지정 - 제한된 크기 조정 - 수동 경로 관리 |
| Azure CNI 노드 서브넷(레거시) | 플랫 | - 직접 외부 Pod IP 액세스 - 더 간단한 구성 - 제한된 크기 조정 - VNet IP의 비효율적인 사용 |
기능 비교
각 CNI 플러그 인의 기능을 비교할 수도 있습니다. 다음 표에서는 각 CNI 플러그 인에서 제공되는 기능을 개략적으로 비교합니다.
| 기능 | Azure CNI 오버레이 | Azure CNI Pod 서브넷 | Azure CNI 노드 서브넷(레거시) | Kubenet |
|---|---|---|---|---|
| 기존 또는 새 VNet에 클러스터 배포 | 지원됨 | 지원됨 | 지원됨 | 지원됨 - 수동 UDR |
| 동일하거나 피어된 VNet에서 VM을 사용하여 Pod-VM 연결 | Pod 시작 | 두 방법 모두 | 두 방법 모두 | Pod 시작 |
| VPN/Express 경로를 통한 온-프레미스 액세스 | Pod 시작 | 두 방법 모두 | 두 방법 모두 | Pod 시작 |
| 서비스 엔드포인트 액세스 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| 부하 분산 장치를 사용하여 서비스 노출 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| App Gateway를 사용하여 서비스 노출 | 현재 지원되지 않음 | 지원됨 | 지원됨 | 지원됨 |
| 수신 컨트롤러를 사용하여 서비스 노출 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| Windows 노드 풀 | 지원됨 | 지원됨 | 지원됨 | 지원되지 않음 |
| 기본 Azure DNS 및 프라이빗 영역 | 지원 여부 | 지원됨 | 지원됨 | 지원됨 |
| 여러 클러스터에서 VNet 서브넷 공유 | 지원됨 | 지원됨 | 지원됨 | 지원되지 않음 |
네트워크 모델 간의 범위 지원
사용하는 CNI에 따라 클러스터 가상 네트워크 리소스를 다음 방법 중 하나로 배포할 수 있습니다.
- Azure 플랫폼은 AKS 클러스터를 만들 때 가상 네트워크 리소스를 자동으로 만들고 구성할 수 있습니다. Azure CNI 오버레이, Azure CNI 노드 서브넷 및 Kubenet에서 수행하는 방법과 비슷합니다.
- AKS 클러스터를 만들 때 가상 네트워크 리소스를 수동으로 만들고 구성하고 해당 리소스에 연결할 수 있습니다.
서비스 엔드포인트나 UDR 같은 기능이 지원되기는 하지만 AKS 지원 정책에서는 사용자가 수행할 수 있는 변경 작업을 정의합니다. 예시:
- AKS 클러스터의 가상 네트워크 리소스를 수동으로 만드는 경우 고유한 UDR이나 서비스 엔드포인트를 구성할 때 지원됩니다.
- Azure 플랫폼에서 AKS 클러스터의 가상 네트워크 리소스가 자동으로 만들어질 경우, 이와 같은 AKS로 관리되는 리소스를 수동으로 변경하여 자체 UDR 또는 서비스 엔드포인트를 구성할 수 없습니다.
필수 조건
AKS에 대한 네트워크 구성을 계획할 때는 유의해야 할 몇 가지 요구 사항과 고려 사항이 있습니다.
- AKS 클러스터에 대한 가상 네트워크는 아웃바운드 인터넷 연결을 허용해야 합니다.
- AKS 클러스터는 Kubernetes 서비스 주소 범위, Pod 주소 범위 또는 클러스터 가상 네트워크 주소 범위에 대해
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16또는192.0.2.0/24를 사용할 수 없습니다. - BYO VNet 시나리오에서 AKS 클러스터에서 사용하는 클러스터 ID에는 가상 네트워크 내의 서브넷에 대한 네트워크 기여자 이상의 권한이 있어야 합니다. 기본 제공 네트워크 참가자 역할을 사용하는 대신 사용자 지정 역할을 정의하려는 경우 다음 권한이 필요합니다.
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(고유한 서브넷 및 CIDR을 정의하는 경우에만 필요)
- AKS 노드 풀에 할당된 서브넷은 위임된 서브넷일 수 없습니다.
- AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. 고유한 서브넷을 제공하고 해당 서브넷과 연결된 NSG를 추가하는 경우 NSG의 보안 규칙이 노드 CIDR 범위 내의 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.
다음 단계
Azure Kubernetes Service