[EKS Study 2주차] EKS Networking - Prefix Delegation

CloudNet@ 팀의 가시다님께서 Leading 하시는 AEWS Study 2주차 도전과제 정리

이번 2주차는 EKS Network 에 관해 공부했습니다.
저번 PKOS 스터디에서 진행했던 Network 와 겹치는 부분이 다소 있어, 이번 주차에는 도전과제 위주로 정리를 해볼까 합니다.

 

기본적인 EKS Network 에 관해서는 아래 글을 참고하시길 바랍니다.

[PKOS Study 2주차] Kubernetes Network ( AWS VPC CNI )

 

이번 글에서는 EKS 에서 파드 생성 갯수 제한을 해결하기 위한 방법 중 하나인

Prefix Delegation (접두사 위임) 에 대해 알아보겠습니다.

 

 

1. Prefix Delegation (접두사 위임) 개념

• 기본적으로 EKS Node 에 생성할 수 있는 Pod 의 개수는 Node에 할당된 ENI 개수와 ENI 에 할당된 IP 주소 수를 기준으로 정해집니다.

자원의 소모가 큰 Pod 인 경우에는 Node 의 자원을 많이 소모할 수 있어 문제가 되지 않지만
자원의 소모가 적은 Pod 일 경우, Node 의 자원 낭비가 발생하게 됩니다.

 

이를 해결하기 위한 방법 중 하나로 Prefix Delegation (접두사 위임) 이라는 방법이 등장하게 됩니다.

 

1.1. Prefix Delegation 조건

 

모든 EKS Node 가 Prefix Delegation 을 사용할 수 있는 것은 아니며, 해당 기능을 사용하기 위한 조건은 다음과 같습니다.

 

a. Amazon VPC CNI 1.9.0 버전 이상

kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

 

 

b. Worker Node 가 AWS Nitro 기반 EC2 인스턴스로 구성

 

c. Worker Node 의 max-pod 값 설정

kubectl get node -o yaml | grep allocatable -A7

 

• 현재 1개 노드당 35개의 Pod만 생성 가능한 상태입니다. (t3.large)

 

1.2. Prefix Delegation 고려사항

 

AWS 에서 제공하는 EKS Best Practice 에서는 다음과 같은 환경일 때 Prefix Delegation 설정을 피해야 한다고 말합니다.

 

a. /28 접두사를 사용하기에 충분하지 않은 Subnet IP 범위를 가지고 있을 때
b. Security Groups for Pods 기능을 사용할 때 - Prefix Delegation 은 해당 노드의 모든 파드가 동일한 보안 그룹을 사용합니다.

 

1.3. Prefix Delegation 관련 기능 용어 정리

 

Prefix Delegation 을 활성화 하는 기능은 AWS VPC CNI 에 존재합니다.
VPC CNI 는 각 노드에 aws-node 라는 DaemonSets 형태의 Pod로 존재합니다.

 

kubectl get pods -n kube-system -o wide

 

 

VPC CNI 에 어떤 기능이 있는 지 잠깐 확인해봅니다.

kubectl describe daemonsets.apps aws-node -n kube-system | grep ADDITIONAL_ENI_TAGS: -B1 -A26

 

• 주목해야할 부분은 다음과 같습니다.

EKS IP 할당 용어

a. WARM_IP_TARGET : Node ENI 전체를 Warm Pool 로 준비하지 않고, 설정한 IP 개수만큼만 확보
b. WARM_PREFIX_TARGET : /28 Prefix를 할당한 ENI를 확보해놓을 개수
c. WARM_ENI_TARGET : EKS Node 에서 신속한 Pod 배포를 위해 미리 부착해놓은 ENI 개수
d. MINIMUM_IP_TARGET : EKS Node 에서 항상 보유할 최소 IP 개수

 

2. Prefix Delegation 활성화

 

아래 명령어로 접두사 위임을 활성화합니다.

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true

 

 

2.1. Pod 배포

 

테스트를 위해 150 개의 Pod 를 배포해보겠습니다.

t3.large 사양을 가진 3개의 Node 에서 진행합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 150
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

 

kubectl get deployments nginx-deployment

 

분명 Prefix 모드를 활성화 했는데, 97개의 Pod 만 배포된 것을 알 수 있습니다.

 

배포되지 않은 Pod 를 살펴봅니다.

kubectl describe pod nginx-deployment-6fb79bc456-zxzqc

 

Pod가 너무 많이 배포되어 실패했다는 것을 알 수 있습니다.

 

여기서 Prefix Delegation 의 3번째 조건을 떠올려 Node 의 max-pods 가 150개의 Pod를 배포하기에 충분한 지 확인합니다.

kubectl get node -o yaml | grep allocatable -A7

 

• 150 개의 Pod 를 띄우기에는 턱없이 부족한 숫자입니다.

 

2.2. Node의 max-pod 변경 (Managed Node Group)

 

현재 동작 중인 Node 의 max-pod 설정을 변경하기 위해서는 해당 Node 에 접속하여 명령어를 입력해야 합니다.
또한, 실행 중인 Node 가 Self-Managed 이냐 Managed 이냐에 따라 수행하는 명령어가 다릅니다.

 

저는 Managed Node Group 을 실행하고 있으므로 다음과 같은 단계를 수행합니다.

 

a. max-pod 설정을 변경하고 싶은 Node 에 ssh 접속

 

kubectl get node ip-192-168-1-78.ap-northeast-2.compute.internal -o yaml | grep allocatable -A7

 

저는 192.168.1.78 노드에서 max-pod 설정을 변경해보겠습니다.

 

ssh ec2-user@192.168.1.78

 

cd /etc/eks

 

AWS Managed Node Group 은 /etc/eks/bootstrap.sh 을 사용해 EKS 설정을 적용합니다.

 

b. bootstrap.sh 설정 변경

sudo /etc/eks/bootstrap.sh myeks --use-max-pods false --kubelet-extra-args '--max-pods=110'

 

해당 명령어를 통해 Node 의 Max-Pod 설정을 변경합니다.

 

하지만 아직 Max-pod 설정이 적용되지 않았습니다.

 

c. kubelet 재시작

해당 설정은 Node 의 kubelet 에 의해 동작합니다.

때문에 kubelet 을 재기동시켜줘야 실제로 바뀐 설정이 적용됩니다.

 

sudo systemctl restart kubelet

 

 

kubectl get node ip-192-168-1-78.ap-northeast-2.compute.internal -o yaml | grep allocatable -A7

 

이후 다시 한 번 Node 의 max-pods 를 확인하면 110으로 늘어난 것을 볼 수 있습니다.

 

마지막으로 배포했던 Deployment 의 상황을 보면 150개의 Pod 가 모두 정상적으로 배포된 것을 알 수 있습니다.

 

---

 

이번 포스팅에서는 AWS VPC CNI 기능 중 하나인 Prefix Delegation 에 대해서 알아보았습니다.

 

저번에 사용할 떄는 Node 를 새로 배포하면서 Max-Pods 를 설정했는데,

이번 포스팅을 하면서 기존에 배포되어 있는 Node 에 Max-Pods 설정을 변경하는 방법에 대해서 알 수 있었습니다.

 

기존 노드 설정 변경 시, Kubelet 이 재시작 되기 때문에 아주 잠깐이지만 서비스 다운이 발생할 수도 있다고 생각합니다.
물론 Pod를 하나만 배포하진 않겠지만, 실제 환경에서는 필요하다면 드레인과 코든을 통해 파드를 다른 노드에 옮기는 것도 고려할 수 있을 것 같습니다.

 

또한 EKS 를 Terraform 으로 배포했다고 한다면, user-data 에 max-pod 설정을 추가하여 사용하는 것을 고려할 수 있을 것입니다.

 

참고 문서

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cni-increase-ip-addresses.html

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

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

https://aws-diary.tistory.com/146

https://aws.github.io/aws-eks-best-practices/networking/prefix-mode/#avoid-prefix-mode-when

https://repost.aws/knowledge-center/eks-configure-cni-plugin-use-ip-address