[AWS]EKS 네트워크 이해하기(CNI Plugin)

안녕하세요 오늘은 EKS 네트워크에 대해 이야기 해보고자합니다.
EKS 네트워크는 EKS사용에 있어서 가장 중요한 포인트중 하나 입니다.

EKS 네트워크

쿠버네티스의 Pod는 한 개 이상의 컨테이너를 구성하고 같은 Host와 Network 스택을 공유합니다. 그리고 여러 Host에 사이에 걸쳐 생성된 Pod은Overlay Network를 통해 서로 통신하게 됩니다.

이 말은 즉슨 EKS에 생성되는 Pod들이 AWS VPC의 네트워크를 잡아 먹는다는 이야기 입니다. 이것이 왜 중요 하냐면 아래에서 설명드릴테지만 Node instance는 공식에 의해 자동으로 Max IP를 할당하는데, 내가 노드 인스턴스 1개를 생성했어도 네트워크 인터페이스가 1개가 아닌 여러개가 될 수 있다는 이야기 입니다.

EKS네트워크 설계의 중요성

따라서 생각지도 못한 상황에서 네트워크의 IP가 부족하게 될 수도 있다는 이야기 입니다. 제가 접한 대~기업 고객분들을 보면 기존에 레거시 환경에서 사용하던 네트워크와 AWS VPC와 하이브리드로 구성하는경우가 대다수 였습니다. 그럴 수 밖에 없는게 AWS 클라우드로 마이그레이션이 힘든 서버들도 있고, 굳이 AWS로 마이그레이션 하지 않아도되는 서버들도 있기 때문 입니다.

이 때 문제가 발생하는데요

네트워크 구성이 아주 타이트하게 되어있어서 IP대역을 신규 발급 받기가 매우 어렵습니다. 따라서 기존 인프라 네트워크 관련 부서는 아주 방어적일 수 밖에 없으며 절차도 복잡합니다. 때문에 Elastic 한것이 장점인 AWS와 Kubernetes를 쓰기 전에 여기서부터 막히게 됩니다.
초기에 node instance 가 얼마나 필요할지 pod가 얼마나 scale out 될지를 파악하는건 쉽지 않기때문에 시작부터 애를 먹게 됩니다.

어찌됐든.. EKS에 필요한 네트워크 설계를 잘..!!해야합니다. ( 방법이 있나요 ㅠㅠ)

(한가지 팁을 말씀드리면 VPC설계는 기존 방식처럼 CIDR을 계산해서 쪼개지말고, secondary VPC를 붙힐 수 있는 형태로 설계해야 향 후 운영할때 좋습니다. 대역이 부족해서 추가하게될경우 용이하기 때문이죠)

EKS CNI

기존 VPC 환경에서는 Pod 네트워크 통신을 기존 방식처럼 지원하기 어려웠다고 합니다.

하지만 대부분의 사용자들이 VPC 기반의 인프라를 구성하고 있었기 때문에 EKS는 VPC를 지원할 수 있어야 했습니다. 예를 들어 사용자는 Security Group, VPC Flow 로그 등의 기능을 그대로 사용하면서, PrivateLink를 통해 다른 AWS 서비스와 통신할 수 있어야 합니다.

이 문제를 해결하기 위해 AWS는 CNI 라는 네트워크 플러그인을 지원하기 시작했습니다.

CNI 는 다음과 같은 통신을 지원합니다.

• 단일 Host 내에 존재하는 Pod 간의 통신
• 서로 다른 Host 내에 존재하는 Pod 간의 통신
• Pod 과 다른 AWS 서비스 간의 통신
• Pod 과 온프레미스 데이터 센터 간의 통신
• Pod 과 인터넷 간의 통신

Node instance MAX IP 계산하기

앞서 말했듯 VPC 내의 EC2는 여러 개의 ENI 를 가질 수 있으며, ENI 는 여러 개의 IP 주소를 가질 수 있습니다. 하지만 인스턴스 유형 별 가질 수 있는 ENI 와 주소의 최대 수에는 제한이 있습니다. 만약 EC2 인스턴스가 N개의 ENI와 M개의 주소를 가질 수 있다면 최대 IP는 아래와 같이 계산됩니다.

Instance별 Max Pod 개수 확인 https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt

(Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2

처음 Worker Node가 추가되면 하나의 ENI 가 인스턴스에 할당됩니다. 하지만 실행되는 Pod의 수가 단일 ENI 에서 허용하는 주소를 초과하면 CNI는 노드에 새로운 ENI 를 추가합니다. ENI 에 secondary IP 할당과 Pod에 할당할 노드의 IP 주소 풀 관리는L-IPAM데몬을 통해 이루어집니다. L-IPAM 데몬은 모든 노드에 DeamonSet으로 배포되며 gRPC를 통해 CNI 플러그인과 통신합니다.

Node instnace MAX IP 계산 예시

사용하고 있는 인스턴스 유형이 m5.xlarge라고 가정하고 예시를 들어보겠습니다.

우선 m5.xlarge 유형은 4 ENI 와 ENI 당 15 개의 IP 주소를 가질 수 있습니다. 배포된 Pod의 수가 0에서 14 사이라면 IPAM 데몬은 2개의 Warm Pool을 유지하기 위해 ENI를 하나 더 할당합니다.

이때 사용가능한 IP 수는(2 * (15 - 1)) + 2 = 30개가 됩니다.

이런식으로 Warm Pool을 늘려가면서 최대(4 * (15 - 1)) + 2 = 58개의 IP를 가질 수 있습니다.
이 부분은WARM_ENI_TARGET과 같은 CNI 옵션을 통해 수정할 수 있습니다.

일반적으로 CIN 플러그인, kube-proxy가 기본적으로 모든 노드 인스턴스 위에 동작하기 때문에 m5.xlarge 가 실제로 사용가능한 pod개수는 56개 입니다.

• 참고 경로 : Instance Type 별 최대 Pod수 확인
  https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt
• 참고 경로 : Instance 별 최대 ENI 개수를 확인
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI

Node instance Secondary IP제한 하기

위에서 계산된 공식에의해서 자동으로 할당되고 늘어나는 Node instance 의 secondary IP 개수를 임의적으로 제한할 수도 있습니다.
Node instance가 갖는 IP개수가 많아지면 그만큼 네트워크대역을 차지한다는 하게 되기 때문에 실제로 실무에서는 이를 제한해야하는 상황이 발생하기도 합니다.

아래와 같이 aws-node 데몬셋 설정을하여 IP개수에 대한 제어가 가능합니다.
aws-node데몬셋이 L-IPAM데몬을 실행하여 ENI에 secondary IP할당과 Pod IP할당을 하기 때문입니다.

kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=1
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=30

파라미터 설명

• WARM_IP_TARGET : 특정 IP개수만 Warm Pool을 설정하겠다라는 설정함. 1로 설정되면 pod가 생성될때마다 secondary IP가 1개씩 추가로 할당됨

* Pod의 생성이 빈번할때 인스턴스에 IP를 할당하고 해제하는 API call횟수가 늘어나게 되서 Throttling이 발생할 수 있으므로 MINIMUM_IP_TARGET 설정을 같이 설정합니다.

• MINIMUM_IP_TARGET : Node instance에 일반적으로 유지되는 pod수를 설정함. 해당 수만큼 미리 ENI에 secondary IP가 할당됨

오늘은 여기까지 EKS의 네트워크 이해와 Node instance 의 IP를 제어하는 방법을 알아보았습니다.

모든 시스템 설계의 기본은 네트워크 설계입니다. 처음 EKS사용에 앞서 네트워크 설계때문에 애를 먹은 기억이 아직 또렷합니다.

네트워크 IP가 부족해서 VPC를 새로 생성해야 했는데 그말은 그위에 올라가있는 모든 서비스들을 새로 만들어야한다는 것이죠. 말만 들어도 끔찍한데, 이 글을 보시는 분들은 그런일이 발생하지 않았으면 좋겠습니다.

EKS와 Kubernetes를 사용하면서 공유할 수 있는 내용들을 지속적으로 블로깅할 예정입니다.

오늘도 감사합니다.