[Azure] Azure Kubernetes Service Networking Model

Azure kubernetes service에 대한 네트워크를 정확히 알고 사용하기 위해서는 네트워킹 모델에 대해서 알고 있어야합니다.네트워킹 모델을 정확히 알고자 작성하게 되었습니다.

 

 

1. 네트워킹 모델  

AKS는 세 가지 주요 모델이 있습니다. 

각 모델은 네트워크 구현 방식, IP 주소할당 ,성능, 확장성 등에 차이가 있습니다. 

• kubenet
• Azure CNI Overlay
• Azure CNI NodeSubnet (Flat) 

 

2. 네트워킹 모델 특징 

2.1 kubenet 

kubenet의 기본 특징은 다음과 같습니다. 

• 노드는 Azure Virtual Network(이하 VNet)에서 IP를 할당받고, Pod는 별도의 가상 POD CIDR에서 IP를 할당받습니다. 
• 노드 당 하나의 IP만 VNet에서 사용하므로 IP 효율성이 높습니다. 

kubenet의 작동 방식은 어떻게 될까요 ? 

• 노드풀에 배포되어있는 노드 간 통신을 위해서는 사용자 정의 라우팅(UDR)을 사용해야합니다. 
• Pod 트래픽의 경우 노드 레벨에서 NAT처리되게 됩니다 (SNAT) 
• Linux 브리지 네트워크로 노드 내 Pod 네트워킹을 관리합니다. 

제한 사항에 대해서도 알아보도록 하겠습니다.

• 최대 400개 노드로 확장성이 제한되어 있습니다. (노드간 통신이 UDR 기반으로 되는데 UDR 최대 수가 400임)
• Pod IP는 VNet 외부에서 직접 접근이 불가능합니다. 
• Azure 리소스와의 통합이 제한적일 수 있습니다. 
• 네트워크 정책 지원이 제한적일 수 있습니다. 
• kubenet networking model은 원래 portal에서 기본 모드로 설정 되었으나, CNI Overlay networking model로 인해서 제거 되어 Azure CLI로만 배포가 가능합니다. 
• kubenet networking model은 2028년 3월 31일 이후 더이상 Azure에서 지원하지 않습니다. 

---

2.2  Azure CNI Overlay 

마찬가지로 CNI Overlay의 기본 특징에 대해서 알아보도록 하겠습니다. 

• kubenet과 마찬가지로 노드의경우 Azure VNet에서 IP를 할당받고, Pod는 Overlay Network에서 IP를 할당 받습니다. kubenet과 동일하게 별도의 가상 POD CIDR에서 할당받게 됩니다. 
• 별도의 가상 POD CIDR에서 IP를 할당받기 때문에, IP 주소 효율성이 높으면서도 확장성이 우수합니다. 

작동 방식은 어떻게 될까요 ?

• VXLAN 같은 캡슐화 기술로 Overlay Network를 구현합니다. 
• Pod간 통신은 Overlay Network 내에서 이뤄집니다. 그러므로 Pod간 통신이 가능하게 됩니다. 
• kubenet과 달리 Overlay Network를 통해서 UDR 없이 노드간 통신이 가능합니다. 

CNI Overlay 네트워킹 모델의 장점은 다음과 같습니다. 

• AKS가 배포된 가상네트워크 서브넷의 IP를 사용하지 않고 Overlay Network IP를 사용하기 때문에 IP 효율성이 좋습니다. 
• 마찬가지 이유로 확장성이 뛰어납니다. 
• 네트워크 정책 또한 완벽하게 지원합니다. 

---

2.3 Azure CNI NodeSubnet (Flat) 

마지막으로 CNI NodeSubnet 네트워킹 모델에 대해서 알아보도록 하겠습니다. 

기본적인 특징은 다음과 같습니다. 

• 노드와 Pod 모두 동일한 Azure VNet 서브넷에서 IP를 할당합니다. 
• 각 Pod는 VNet IP를 직접적으로 소비하게 됩니다. 

작동 방식은 어떻게 될까요 ?

• Pod IP는 Azure VNet에서 직접 라우팅이 가능합니다. 
• 노드와 Pod간의 직접적인 네트워크 통합이 가능합니다.
• NAT는 불필요합니다. 아웃바운드 트래픽을 직접 라우팅하기 때문입니다. 

장점과 제한사항에 대해서 알아보도록 하겠습니다. 

장점의 경우,

• Pod IP에 직접 접근이 가능합니다.
• 다른 Azure 서비스와의 원활한 통합이 가능합니다. 

단점은 다음과 같습니다. 

• 높은 IP 주소를 소비하게 됩니다. 
• IP 주소 공간 계획을 신중하게 해야겠지요 
• 대규모 클러스터의 경우 IP 관리가 복잡하게 될 수 있습니다. 

 

앞서, AKS의 네트워킹 모델에 대해서 학습하게 되면 IP 주소 범위 계획에 대해서 신중해지게 됩니다. 

크게 IP 주소 범위 계획을 위해서는 VNet CIDR, Subnet CIDR, Service CIDR, Pod CIDR이 고려됩니다. 

다음, IP 주소 범위 계획에서 알아보도록 하겠습니다.

 

3. IP 주소 범위 계획 

 3.1 VNet CIDR

• Azure 가상 네트워크의 전체 IP 주소 범위 
• 모든 Azure 리소스를 포함할 수 있도록 충분히 큰 범위가 필요하겠지요 
• 예 : 10.0.0.0/16

3.2 Subnet CIDR

• VNet 내에서 AKS 노드가 배포될 서브넷의 IP 주소 범위, 해당 주소범위에 VMSS기반으로 AKS 노드풀이 배포됩니다. 노드풀에 논리적으로 노드가 배포되게 됩니다. 
• VNet CIDR의 하위 집합이 되겠죠. 
• AKS 노드가 배포될 서브넷을 사용자 지정으로 설정하지않는다면, Azure에서 자동으로 생성하게 됩니다. 사용자 지정 네트워크에 배포하기 위해서는 아래 이미지와 같이 설정이 필요합니다. 
• 예: 10.0.0.0/24

• 만약, 앞서 말했듯이 자체 Azure 가상 네트워크 사용을 지정하지 않고 Azure가 자동으로 생성하게 된다면 아래와 같은 정보로 배포되게 됩니다. 
  • 리소스 그룹 : MC_xxxx
  • vnet : aks-vnet-랜덤문자
  • subnet : aks-subnet-랜덤문자

 

3.3 Service CIDR

• kubernetes 서비스에 할당되는 가상 IP 주소 범위 입니다. 
• VNet 및 Pod CIDR과 겹치지 않아야합니다. 
  • 겹치지 않아야 되는 이유는 만약 동일한 IP가 할당되게 된다면, 해당 IP에 접근할때 Azure Vnet의 리소스에 대한 IP인지 AKS Service에 대한 IP인지 불분명해져 충돌이 발생할 수 있습니다. 
  • DNS 서비스 IP의 경우, 전체 서비스 CIDR에 포함되어야 합니다. 
• 예 : 172.0.0.0/16 

 

3.4 Pod CIDR

Pod CIDR의 경우 네트워크 모델에 따라 상이합니다. 

• kubenet : 가상 Pod CIDR 
• Azure CNI Overlay : Overlay Network CIDR 
• Azure CNI NodeSubnet : 별도의 CIDR 없음 (서브넷 사용)

Azure CNI Overlay의 경우 다음 이미지와 같이 pod가 배포됩니다. 

Pod CIDR : 10.244.0.0/16

Subnet CIDR : 10.0.0.0/24 

왜 Pod CIDR에 배포가 전부되지 않고 Subnet CIDR에 배포된 것인가 ? 

• POD CIDR에 배포된 POD는 일반 애플리케이션 워크로드, 시스템 서비스이지만 노드 수준 접근이 필요하지 않는 파드 정도가 될 수 있습니다. 
• Subnet CIDR에 배포되는 Pod의 경우, 노드의 리소스, 커널, 네트워크 스택에 직접 접근이 필요한 노드가 배포됩니다. 예로 kube-proxy, azure-cns, 스토리지와 관련된 csi Pod 들입니다. 

 

결론적으로, Subnet CIDR(노드IP), Service CIDR, Pod CIDR 모든 CIDR은 서로 겹치지 않아야합니다.

 

4. 네트워킹 모델 비교

다음은 앞서 학습했던 내용에 대한 네트워킹 모델에 대한 전체적인 아키텍처 비교입니다. 

 

 

어렵네요..

틀린 부분이 있으면 꼭 말씀해주시면 감사하겠습니다 :)