안녕하세요, 오늘은 AWS VPC CNI에 대해 공부한 내용을 정리해보겠습니다.
실질적으로 AWS EKS 를 사용하는 상황에서는 제일 많이 접하게 되는 VNI인 것 같습니다.
이 글은 Cloud Neta 팀의 KANS (Kubernetes Advanced Network Study)의 마지막 과제로서 작성되었습니다.
AWS VPC CNI 가 뭔가요?
CNI는 이미 앞선 글들에서 봤듯이, Container Network Interface로서 Kubernetes cluster의 네트워크 환경을 구성하는 역할을 합니다.
CNI의 예로 Flannel, Calico, Cilium .. 등(CNI들의 목록)을 들 수 있습니다.
AWS의 Managed Kubernetes인 EKS는 기본적으로는 AWS VPC 내부에 구성합니다.
그리고 Kubernetes cluster의 네트워크 구성을 AWS VPC 기준으로 만듭니다.
이 경우 EKS에 생성되는 pod는 Kubernetes cluster가 구성된 VPC 내부 subnet의 CIDR 대역에 해당하는 IP주소를 할당받는다는 특징이 생깁니다.
이렇게 AWS VPC 네트워크와 EKS 간 인터페이스 역할을 수행하는 AWS의 Network addon이 바로 AWS VPC CNI입니다.
AWS VPC CNI의 특징 : 파드의 IP 네트워크 대역과 노드의 IP 대역이 같다
위에서 설명했듯이, AWS VPC CNI 플러그인은 Kubernetes Pod이 VPC 네트워크에서 동일한 IP 주소를 가지도록 합니다.
AWS VPC CNI는 파드의 IP 네트워크 대역과 노드(워커)의 IP 대역이 같아서 직접 통신이 가능합니다.
AWS VPC CNI의 특징 : AWS 의 다른 기능들과 함께 사용 가능
위의 특징으로 인해 AWS 자체의 네트워크 기능들을 사용할 수 있습니다.
AWS의 VPC Flow logs 를 통해서 flow log들을 수집하고 보는 일도 가능하고, VPC 라우팅 정책, 보안 그룹(Security group) 을 사용 가능합니다.
AWS VPC CNI의 특징 : IP의 할당은 L-IPAM에서
pod는 CIDR 대역에서 IP를 할당받는데, 이는 AWS의 특징을 또 가집니다.
IP 할당은 무한정할 수 있는게 아니라, 각 EC2 인스턴스의 최대 ENI 수에 따라서,
VPC ENI 에 미리 할당된 IP(=Local-IPAM Warm IP Pool)를 파드에서 사용할 수 있습니다.
EKS에는 데몬셋 aws-node가 설치되는 데, 위의 역할을 여기 포함된 L-IPAM(Local IP Address Manager)이 합니다.
이 내용은 뒤에 쓸 동작방식에서 추가로 설명하겠습니다.
AWS VPC CNI를 사용하면 뭐가 좋나요?
네트워크의 최적화
그러면 사용에 따른 어떤 장점이 있는지도 봐야겠죠.
위에서 얘기했듯이 AWS VPC CNI를 사용할 경우, 아래와 같이 노드와 파드의 네트워크 대역이 같습니다.
그러므로 네트워크 통신이 최적화된다는 장점이 있습니다.
아래 Calico의 예에서 보듯이, CNI는 대개 오버레이(VXLAN, IP-IP 등) 통신을 하고,
AWS VPC CNI는 동일 대역으로 직접 통신을 합니다.
그러니 오버레이를 위한 캡슐화 과정이 필요 없어서 캡슐화를 하는 데드는 리소스가 줄어듭니다.
그리고 Latency가 짧아집니다.
AWS VPC 의 네트워크 기능 사용 가능
위에 설명한 특징이 장점이 됩니다.
AWS의 VPC Flow logs 를 통해서 flow log들을 수집하고 보는 일이 가능해지기 때문에
Pod에서 송수신되는 트래픽 흐름을 AWS 기능으로 볼 수 있습니다.
AWS VPC CNI의 구성요소와 동작 방식
AWS VPC CNI의 구성요소
AWS VPC CNI 문서에서 자세한 내용을 확인할 수 있습니다.
Amazon VPC CNI는 두 가지 구성 요소로 이루어져 있습니다
- CNI Binary: Pod 간 통신을 가능하게 하는 네트워크를 설정하며, 노드의 루트 파일 시스템에서 실행됩니다.
새로운 Pod이 노드에 추가되거나 기존 Pod이 제거될 때, kubelet에 의해 호출됩니다. - ipamd: 노드에 위치한 a long-running node-local IP Address Management(IPAM) 데몬입니다.
- 이 데몬은 node에서 ENI를 관리합니다.
- 그리고 사용 가능한 IP 주소의 Warm Pool을 유지합니다.
AWS VPC CNI의 동작방식
AWS EC2 인스턴스가 생성되면 EC2는 subnet과 연결된 ENI를 생성하고 연결합니다.
host network mode를 사용하는 Pod는 ENI에 할당된 기본 IP 주소를 사용하며,
host와 동일한 network namespace를 공유합니다.
AWS VPC CNI plugin은 각 EC2 노드의 ENI를 관리합니다.
기본 ENI에는 Warm Pool이라고 불리는 자동으로 할당되도록 준비된 슬롯(IP주소 또는 prefix)이 있습니다.
예를 들어, pod를 생성하면 Warm Pool들어있는 IP주소를 바로 할당하는 방식입니다.
Warm pool의 경우 EC2의 유형(M5나 C5와 같은) 에 따라 크기가 다릅니다.
그리고 ENI는 EC2의 유형에 따라 지원할 수 있는 슬롯 수가 제한되어 있습니다.
ENI와 슬롯의 최대 수는 EC2의 유형에 따라 다르기 때문에 이를 파악하고 있어야 합니다.
아래와 같이 ENI와 슬롯에 따라 pod에 ip가 할당되는 과정을 도식으로 확인할 수 있습니다.
EC2 유형에 따른 최대 Pod 갯수
위에 설명한 EC2 유형에 따라 IP가 준비될 수 있는 수가 다릅니다.
그러니 pod의 최대 갯수가 다를 것입니다.
그리고 pod에 ip를 배정하는 방식에는 2가지 모드가 있습니다.
- Secondary IPv4 addresses
- IPv4 Prefix Delegation
- Secondary IPv4 addresses
Secondary IPv4 addresses는 인스턴스 유형에 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 선정합니다.
공식은 아래와 같습니다.
Max Pods = ENI * (ENI 당 지원하는 Ipv4 갯수 -1 ) + 2
예를 들어, m5.large는 ENI가 3개가 가능하고, ENI 당 지원하는 IPv4 갯수가 10개 입니다.
그러니 3 * (10 - 1) + 2 = 29 로 최대 29개가 가능합니다.
1을 빼는 이유는 각 ENI의 첫 번째 IP는 pod를 위해 사용할 수 없기 때문입니다.
그리고 2개는 기본으로 포함되는 host network 관련 파드 입니다(AWS CNI, kube-proxy).
- IPv4 Prefix Delegation
2021년 8월에 생긴 IPv4 Prefix Delegation는 IPv4 28bit 서브넷(prefix)를 위임하여 할당 가능 IP 수와 인스턴스 유형에 권장하는 최대 갯수로 선정합니다.
공식은 아래와 같습니다.
Max Pods = ( ENI * ( ENI 당 지원하는 IPv4개수 - 1 ) * 16
단, 제약사항이 있습니다. 30vCPU 미만 인스턴스는 110개로 제한, 이외 모든 인스턴스는 250이 최대값입니다.
아래 도식에서 보는 것처럼, 방식에 따라
t3.medium은 15개, c5.large는 128개의 ip를 배정하고 pod를 생성하는 일이 가능합니다.
실제로 콘솔에서 인스턴스의 정보를 보면 아래와 같은 정보를 볼 수 있습니다.
AWS VPC CNI의 통신
노드 간 Pod 통신
AWS VPC CNI는 특징과 장점이 별도의 오버레이 통신 기술 없이, VPC Native하게 Pod간 직접 통신이 가능하다는 설명을 했었습니다.
이를 비교하기 위해 예전에 그렸던 Calico의 그림을 갖고 왔습니다.
아래를 참고해주시기 바랍니다.
Calico의 경우
AWS VPC CNI의 경우
아래와 같이 별도의 NAT가 일어나지 않습니다.
파드간 통신의 과정은 아래 도식을 참고해주시면 되겠습니다.
Pod에서 외부 통신
Pod에서 외부로 나가는 통신의 흐름은 아래 도식을 참고해주시면 되겠습니다.
iptable 에 SNAT 을 통하여 노드의 eth0 IP로 변경되어서 외부와 통신됩니다.
그리고 VPC CNI 의 External source network address translation (SNAT) 설정에 따라, 외부 통신 시 SNAT 하거나 혹은 SNAT 없이 통신을 할 수도 있습니다.
Kuberetes Service type에 따른 통신 방식
Kubernetes Service type에는 ClusterIP, NodePort, LoadBalancer 타입이 있습니다.
대역이 같기 때문에 AWS VPC CNI에서는 통신 형태가 아래와 같이 됩니다.
- ClusterIP의 경우
- NodePort의 경우
- LoadBalancer의 경우
AWS에서 LoadBalancer는 CLB, NLB, ALB 타입을 지원합니다.
그 중에서 NLB를 생성할 때 타입을 정할 수 있는데 intance type, ip type의 2가지가 있습니다.
기본으로 설정을 하지 않으면 instance type이 되는데 그 경우 아래와 같이 됩니다.
ip type의 경우 아래 도식과 같은 구조이기 때문에 네트워크 성능이 더 좋습니다.
LoadBalancer에서 Pod의 IP를 알고 있기 때문에 iptable을 거치지 않고 바로 직접 통신이 됩니다.
NLB Deep Dive
NLB의 type은 중요하기 때문에 각 type에 대해 추가로 설명하겠습니다.
instance type 입니다.
특별한 설정으로 externalTrafficPolicy가 있습니다.
externalTrafficPolicy: ClusterIP ⇒ 2번 분산 및 SNAT으로 Client IP 확인 불가능 ←LoadBalancer타입 (기본 모드) 동작externalTrafficPolicy: Local ⇒ 1번 분산 및 ClientIP 유지, 워커 노드의 iptables 사용함
ip mode 입니다.
특별한 설정으로 ProxyProtocol v2가 있습니다.
Proxy Protocol v2 비활성화⇒ NLB에서 바로 파드로 인입, 단 ClientIP가 NLB로 SNAT 되어 Client IP 확인 불가능Proxy Protocol v2 활성화⇒ NLB에서 바로 파드로 인입 및 ClientIP 확인 가능(→ 단 PPv2 를 애플리케이션이 인지할 수 있게 설정 필요)
Reference
- https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy
- https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html
- https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html
- https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md
- https://aws.amazon.com/ko/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/
'Kubernetes' 카테고리의 다른 글
| Cilium CNI 공부하기 (3) | 2024.10.25 |
|---|---|
| Istio sidecar mode와 Kubeflow (1) | 2024.10.20 |
| Operator로 배포하는 Gateway API 형태의 Kong API Gateway (4) | 2024.10.09 |
| Iptables와 Kubernetes ClusterIP의 Iptables (2) | 2024.10.08 |
| Kubernetes Kube-proxy의 IPVS 모드 (4) | 2024.10.03 |