EKS의 VPC 네트워크 구성 이해하기
📅 November 04, 2019
•⏱️3 min read
모든 Kubernetes as a Service가 그렇듯 EKS 역시 빠르게 변화하고 있습니다. 오늘의 주제는 EKS의 VPC 네트워크 구성과 CNI 플러그인 입니다.
AWS VPC
아마 AWS를 production 환경에서 사용하고 있다면 VPC 구성은 이미 잘 이해하고 계시리라 생각합니다. VPC 내에 생성한 인스턴스는 eth0이라는 기본 네트워크 인터페이스를 가지게 됩니다. 그리고 네트워크 인터페이스에 하나 이상의 IPv4 또는 IPv6 주소를 할당할 수 있습니다. 또한 각 Subnet에 존재하는 인스턴스는 Route Table을 통해 통신을 할 수 있습니다. 여기까지가 우리가 알고 있는 VPC 내의 Host 간 통신입니다.
그렇다면 EKS는 어떤 점이 다를까요? 쿠버네티스의 Pod은 한 개 이상의 컨테이너를 구성하고 같은 Host와 Network 스택을 공유합니다. 그리고 여러 Host에 사이에 걸쳐 생성된 Pod은 Overlay Network를 통해 서로 통신하게 됩니다. 기존 VPC 환경에서는 Pod 네트워크 통신을 기존 방식처럼 지원하기 어려웠습니다.
하지만 대부분의 사용자들이 VPC 기반의 인프라를 구성하고 있었기 때문에 EKS는 VPC를 지원할 수 있어야 했습니다. 예를 들어 사용자는 Security Group, VPC Flow 로그 등의 기능을 그대로 사용하면서, PrivateLink를 통해 다른 AWS 서비스와 통신할 수 있어야 합니다. 이 문제를 해결하기 위해 AWS는 CNI 라는 네트워크 플러그인을 지원하기 시작했습니다.
EKS CNI
CNI 는 다음과 같은 통신을 지원합니다.
- 단일 Host 내에 존재하는 Pod 간의 통신
- 서로 다른 Host 내에 존재하는 Pod 간의 통신
- Pod 과 다른 AWS 서비스 간의 통신
- Pod 과 온프레미스 데이터 센터 간의 통신
- Pod 과 인터넷 간의 통신
앞서 말했듯 VPC 내의 EC2는 여러 개의 ENI 를 가질 수 있으며, ENI 는 여러 개의 IP 주소를 가질 수 있습니다. 하지만 인스턴스 유형 별 가질 수 있는 ENI 와 주소의 최대 수에는 제한이 있습니다. 만약 EC2 인스턴스가 N개의 ENI와 M개의 주소를 가질 수 있다면 최대 IP는 아래와 같이 계산됩니다.
Max IPs = min((N * M - N), subnet's free IP)
처음 Worker Node가 추가되면 하나의 ENI 가 인스턴스에 할당됩니다. 하지만 실행되는 Pod의 수가 단일 ENI 에서 허용하는 주소를 초과하면 CNI는 노드에 새로운 ENI 를 추가합니다. ENI 에 secondary IP 할당과 Pod에 할당할 노드의 IP 주소 풀 관리는 L-IPAM 데몬을 통해 이루어집니다. L-IPAM 데몬은 모든 노드에 DeamonSet으로 배포되며 gRPC를 통해 CNI 플러그인과 통신합니다.
사용하고 있는 인스턴스 유형이 m5.xlarge라고 가정하고 예시를 들어보겠습니다.
우선 m5.xlarge 유형은 4 ENI 와 ENI 당 15 개의 IP 주소를 가질 수 있습니다.
배포된 Pod의 수가 0에서 14 사이라면 IPAM 데몬은 2개의 Warm Pool을 유지하기 위해 ENI를 하나 더 할당합니다.
이때 사용가능한 IP 수는 2 * (15 - 1) = 28
개가 됩니다.
이런식으로 Warm Pool을 늘려가면서 최대 4 * (15 - 1) = 56
개의 IP를 가질 수 있습니다.
물론 이 부분은 WARM_ENI_TARGET
과 같은 CNI 옵션을 통해 수정할 수 있습니다.
구체적으로 CNI를 통해 Pod1 과 Pod2가 어떻게 통신하는지 다이어그램으로 표현하면 위와 같습니다. 각 Pod의 eth0에는 secondary IP address가 할당되며 Pod Side Route Table를 가지고 있습니다. 노드의 네트워크 인터페이스까지 도달한 패킷은 EC2-VPC fabric에 의해 포워딩 됩니다.
따라서 EKS 노드를 결정할 때 ENI 제한 관련 부분도 중요하게 생각하셔야 합니다. 노드 당 ENI, IP 주소 제한은 해당 공식 문서에서 확인하실 수 있습니다. 물론 CNI를 사용하지 않고 기존의 Calico와 같은 Overlay Network를 사용할 수도 있습니다. 하지만 이를 사용하게 되면 네트워크까지 관리해야하며 새로운 장애 포인트로 이어질 수 있습니다.
Reference
- https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md
- https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727