AWS EKS의 IP 주소 관리: 쿠버네티스 클러스터의 네트워킹 고려사항

 

EKS(Elastic Kubernetes Service)는 AWS에서 제공하는 관리형 쿠버네티스 서비스입니다.

 

EKS는 다양한 방면에서 리소스를 관리해주기 때문에 쿠버네티스 클러스터를 편리하게 운영할 수 있는데요.

 

그 중 AWS VPC CNI는 overlay network를 간편하게 구성해주는 장점을 제공합니다.

 

본 포스팅에서는 AWS VPC CNI의 특징과 AWS VPC CNI Plugin을 설치한 EKS 클러스터의 운영 시 IP Address management 고려 사항에 대해서 기술하겠습니다.

 

 

1. AWS VPC CNI란?

 

AWS VPC CNI는 AWS의 ENI(Elastic Network Interface)를 활용한 Pod networking plugin입니다.

 

EKS 클러스터는 해당 CNI를 통해 AWS VPC의 이점을 이용하면서 EC2 Node들 간의 통신을 구성할 수 있습니다.

 

AWS VPC CNI는 다양한 기능을 제공하지만, 가장 중요한 것은 L-IPAMD(Local IP Address Manager Daemon)을 이용한 IP Address 관리 기능입니다.

 

L-IPAMD(이하 IPAMD)는 AWS ENI의 Secondary IP 기능을 이용해 EKS Pod가 사용할 IP Address Pool을 관리하는 역할을 합니다.

 

IPAMD가 관리하는 IP Address Pool을 Warm Pool이라고 하며, IPAMD는 Pod 생성 등의 Kubelet 요청에 따라 Warm Pool 내의 IP 개수를 자동으로 추가하거나 삭제합니다.

 

L-IPAMD가 kubelet의 요청에 따라 Warm pool을 관리하는 프로세스

 

하지만 IPAMD를 통한 IP Address 관리는 아래와 같은 제한 사항이 존재합니다.

 

• EC2 인스턴스의 타입에 따라 부착할 수 있는 ENI 개수가 정해져 있다는 점
• 하나의 ENI가 가질 수 있는 Secondary IP 개수가 정해져 있다는 점
• IPAMD가 ENI의 추가, 삭제를 통해 Warm Pool 내의 IP Address 개수를 조절한다는 점

 

위와 같은 제한 사항 때문에 AWS VPC CNI를 설치한 EKS Cluster는 IP Address 파편화(Fragmantation) 현상이 존재합니다.

 

이로 인해 EKS 클러스터는 할당한 IP Address 범위에 비해 실제 사용할 수 있는 IP Address 개수가 적어진다는 단점이 존재 합니다. 

 

AWS VPC CNI에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

 

 

2.AWS VPC CNI의 L-IPAM 동작

 

 

위에서 언급했듯이, AWS VPC CNI Plugin을 설치한 EKS Cluster는 L-IPAMD를 통해 Pod가 사용할 IP Address를 관리합니다.

 

IPAM이 IP Address를 관리하는 프로세스는 아래와 같습니다.

 



AWS VPC CNI의 L-IPAMD가 IP Address를 관리하는 프로세스

 

하나의 EKS Cluster가 사용 가능한 IP Address의 개수는 EC2 인스턴스의 개수와 타입에 영향을 받는데요.

단일 EC2 인스턴스에 할당할 수 있는 IP Address 개수는 아래와 같은 요인에 따라 결정됩니다.

 

• EC2 인스턴스가 가질 수 있는 최대 ENI 개수
• EC2 인스턴스의 ENI가 가질 수 있는 최대 Private IP Address 개수

 

인스턴스 타입 별 IP Address 개수의 리스트는 이 파일에서 볼 수 있습니다.

 

예를 들어 a1.large 타입의 EC2 인스턴스는 공식 문서에 따르면 아래와 같은 값을 가지게 됩니다.

 

• EC2 인스턴스가 가질 수 있는 최대 ENI 개수 = 3
• EC2 인스턴스의 ENI가 가질 수 있는 최대 Private IP Address 개수 = 10

 

그리고 아래와 같은 산식에 따라 해당 인스턴스는 이론 상 29개의 IP Address를 사용할 수 있습니다.

 

(ENI 개수 × (ENI 당 IP Address 개수 - 1)) + 2

 

하지만 실제 클러스터에서 사용할 수 있는 IP Address 개수는 위 산식으로 계산한 개수보다 적어지는데요. 이는 위에서 언급한 IP Address 파편화 현상이 발생하기 때문입니다.

 

IP 파편화 현상의 예시

 

 

위 일러스트에서 볼 수 있듯이, IPAM은 하나의 IP Address라도 사용 중일 시 ENI를 해제하지 않기 때문에 적은 수의 IP Address로도 다수의 ENI가 사용될 수 있습니다.

 

때문에 최악의 경우 3개의 Pod를 스케쥴링하기 위해 29개의 IP Address가 노드에 할당됩니다.

 

만약 다른 Node에 스케쥴링되어야할 Pod가 존재한다면, 위에서 사용되지 않은 26개 IP Address는 그대로 낭비되는 결과가 나타나게 됩니다.

 

이는 작은 규모의 Cluster라면 문제될 여지가 적으나, Cluster 규모가 커질 수록 낭비되는 IP Address 개수가 많아져 결국 Subnet에 할당한 IP Address 로는 필요한 Pod IP Address를 충족시키지 못하는 현상이 발생하게 됩니다.

 

 

3. IP 파편화 현상을 완화하기 위한 대책

 

IP 파편화로 인한 IP Address 부족 문제를 완화하기 위해 사용할 수 있는 몇 가지 대책이 존재합니다. 

이는 아래와 같습니다.

 

1. 계획된 EKS Cluster 구성
2. 새 Subnet으로의 Migration
3. Custom CNI 사용
4. AWS VPC CNI 환경 변수 조절

 

3-1. 계획된 EKS Cluster 구성

EKS Cluster를 구성 시 적절한 Subnet, EC2 인스턴스 타입을 계획하는 것으로 IP 파편화로 인한 문제를 완화할 수 있습니다.

EKS Cluster가 몇 개의 Pod를 필요로 하는지 사전에 파악하고, 이를 통해 적절한 Subnet IP Address CIDR와 EC2 인스턴스 타입을 선택하면 IP Address의 낭비를 방지할 수 있습니다.

max-pods-calculator.sh 스크립트의 도움을 받아 인스턴스 타입에 따른 EKS Cluster의 권장 최대 Pod 개수를 계산할 수 있습니다.

 

Pros : 계획된 구성을 통해 IP Address를 효율적으로 사용 가능

Cons : EKS Cluster에 필요한 Pod 개수를 계산하는 것이 항상 정확하지 않음

 

3-2. 새 Subnet으로의 Migration

EKS Cluster 운영 중에 계획된 것보다 더 많은 Pod를 필요로 하게 될 경우, 더 넓은 CIDR 범위를 가진 Subnet을 사용해야 합니다.

단 AWS는 기존 Subnet의 CIDR 범위를 확장하는 기능을 지원하지 않기 때문에 기존 Subnet에 존재하는 Pod들을 새 Subnet으로 Migration하는 작업이 필요하다는 것입니다.

이 작업을 수행할시 기존에 사용하던 Node를 Draining해야 하기 때문에 주의해야 합니다.

 

Pros : 기존에 사용하던 EKS Cluster를 그대로 사용 가능

Cons : Node를 Draining하는 작업이 필요하기 때문에 Downtime이 발생

 

3-3. Custom CNI 사용

IP 파편화로 인한 IP Address의 부족 문제는 근본적으로 AWS VPC CNI를 사용하기 때문에 발생하는 문제입니다.

그래서 Cilium, Calico 등 AWS VPC CNI가 아닌 Custom CNI를 사용하는 것으로 이 문제를 완화할 수 있습니다.

단 Custom CNI를 사용할 시 AWS VPC의 이점을 활용할 수 없다는 점에 유의해야 합니다.

 

Pros : IP 파편화 문제를 완화 가능

Cons : AWS VPC에서 제공되는 기능들을 사용할 수 없음

 

3-4. AWS VPC CNI 환경 변수 조절

AWS VPC CNI는 Warm Pool 관리에 필요한 변수를 조절할 수 있는 환경 변수를 제공하고 있습니다.

이는 아래와 같습니다.

 

• WARM_ENI_TARGET : Warm 상태로 유지되는 ENI의 개수를 결정합니다. ENI의 상태가 Warm이라는 것은 어떤 Pod가 사용하고 있지 않더라도 Node에 Secondary ENI로써 부착된 상태라는 것을 의미합니다. 
  
  
• WARM_IP_TARGET : Warm 상태로 유지되는 IP Address의 개수를 결정합니다. IP Addres의 상태가 Warm이라는 것은 IP Address가 어떤 Pod도 사용 중이지 않은 것을 말합니다. 즉 ENI를 추가하지 않고도 Pod에 할당할 수 있는 예비 IP Address의 개수를 결정합니다.
  
  
• MINIMUM_IP_TARGET : 각 Node가 가져야 할 최소 IP Address의 개수를 결정합니다. 현재 IP Address 할당이 필요한 Pod 개수와 상관없이 지정된 IP Address를 확보합니다.

 

위 3개 환경 변수를 적절히 조절하는 것으로 IP 파편화로 인한 IP Address 부족 문제를 완화할 수 있습니다.

 

환경 변수 값 선택에 도움을 받기 위해 Subnet Calculator Excel Document를 활용할 수 있습니다.

 

이 문서에 따르면 MINIMUM_IP_TARGET 값은 각 Node에 필요할 것으로 예상되는 Pod 수보다 약간 많게,

WARM_IP_TARGET 값은 작은 규모의 Cluster에서 설정하는 것을,

WARM_ENI_TARGET  값은 1로 설정하는 것을 권장하고 있습니다.

 

Pros : 기존 EKS Cluster를 유지할 수 있으며, 큰 작업이 필요하지 않음

Cons : 적절한 값을 지정하기 위해 정교한 계산이 필요함

 

 

4. 결론

 

지금까지 AWS VPC CNI의 동작과 이에 따른 IP 파편화 현상, 그리고 문제 완화 대책을 알아봤습니다.

개인적으로는 아래와 같은 프로세스로 EKS Cluster의 IP Address를 관리하는 것이 Best-Practice라고 생각합니다.

 

• 초기 EKS Cluster 구성시 Pod 개수를 가능한 범위 내에서 예측
• 예측한 Pod 개수를 바탕으로 Subnet의 IP CIDR, EC2 인스턴스 타입을 결정
• IP Address 및 CNI 동작을 지속적으로 Monitoring해 IP Address 고갈에 대비
• AWS VPC CNI 환경변수를 지속적으로 조절해 IPAM Optimizing
• 필요시 Downtime을 최소화하기 위한 Subnet Migration 고려

 

위 사항들을 구현하기 위해서는 우선 EKS Cluster를 계획적으로 구성해야 하며, IP Address 관련 Metric을 Monitoring할 수 있는 환경이 구성되어야 하고, AWS VPC CNI 환경 변수 값에 따른 동작을 적절히 이해해야 할 것입니다.

 

 

Reference : 

Amazon VPC CNI - EKS Best Practices Guides 

Experiences for IP Addresses Shortage on EKS Clusters 

Elastic network interfaces - Amazon Elastic Compute Cloud 

https://github.com/awslabs/amazon-eks-ami/blob/master/files/max-pods-calculator.sh 

https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt 

https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md