CloudEngineering (AWS)/EKS

EKS Pod 수 제한

Halfmoon 2021. 7. 16. 20:55

개요

"DaemonSet을 배포하다가 FailedScheduling 이벤트가 발생해서 보니까, 몇몇 노드에 Pod 생성 갯수 제한이 낮게 설정되어 있는데 확인 좀 부탁드립니다." 라는 문의가 들어왔다. 확인 해 보자.

Network 확인

우선 EKS에 구성된 Subnet의 이용가능한 IP를 확인했을 때 충분한 여유를 가지고있었다. 그럼 EKS가 IP를 제한하는 부분이 따로 있을까?

 

포드 네트워킹(CNI) - Amazon EKS

CNI 플러그인 버전 1.7.0 이상을 사용하고 있고 사용자 정의 포드 보안 정책을aws-node에 사용되는 Kubernetes 서비스 계정aws-node포드가 배포된 경우 정책에NET_ADMIN에서allowedCapabilities섹션과 함께hostNetwor

docs.aws.amazon.com

위의 문서를 보면 알 수 있는 내용이다. EKS CNI인 L-IPAM 데몬은 네트워크 인터페이스 생성 및 네트워크 인터페이스 연결, 네트워크 인터페이스에 보조 IP 주소 할당, 예약 시 Kubernetes 포드에 할당할 각 노드에서 웜 풀 유지 관리를 책임진다.

노드에는 ENI가 있고 보조 프라이빗 IP가 여러개 붙어있는 것을 확인할 수있는데, Pod가 생성될 때 노드에 붙어있는 ENI에 보조 프라이빗 IP가 하나 할당 된다고 한다.

 

또, EKS Node인 EC2에는 유형별로 사용할 수 있는 최대 ENI와 각 ENI당 붙을 수 있는 보조 IP의 수가 다르다. 정리해 보면 노드 유형에 따라 붙을 수 있는 ENI수와 그에따른 보조 IP의 수는 다르므로 배포할 수 있는 Pod 수 또한 EC2 유형 마다 다른 것이다. 아래는 유형별 배포가능한 pod를 계산하는 식이다. 

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

NodeCapacity 확인

EKS의 노드에는 유형 별 pod의 개수 제한이 있다. 노드의 유형은 무엇이고 pod가 몇개로 제한되어 있는지 확인해 본다. (jsonpath를 이용하여 출력)

$ kubectl get nodes -o jsonpath="{range .items[*]}{.metadata.labels['beta\.kubernetes\.io\/instance-type']}{'\t'}{.status.capacity.pods}{'\n'}{end}"
m5.xlarge       58
m5.xlarge       17
m5.xlarge       17
m5.xlarge       58
m5.xlarge       17

아래의 문서를 보면 유형 별 생성 가능한 pod 수가 명시되어있다. m5.xlarge는 58이 맞다.

그렇다면, 17로 제한된 이유는 무엇일까? 개수로만 봤을 때 t3.medium 유형 정도가 되겠다.

 

awslabs/amazon-eks-ami

Packer configuration for building a custom EKS AMI - awslabs/amazon-eks-ami

github.com

 

이건, aws 버그 아니면 노드가 t3.medium 유형으로 인식 중에 있는 것 같다. 혹시 누군가 t3.medium으로 유형을 변경했던 것은 아닐까? 라는 생각이 들어 cloudtrail을 열심히 뒤져봤다. 역시, 작업자가 t3.medium으로 노드 3대를 유형 변경했던 이력을 발견했다.

물어보니 개발계노드 타입을 낮춰 비용을 아끼려는 생각이였나보다. 하지만, EC2 유형변경으로 진행을하여 이상했던 부분이 있는 지 작업 후에 원복을 한것으로 보인다.

 

알아 둘 것이 있다. EKS NodeGroup은 ScaleOut 및 ScaleIN을 지원하지만 ScaleDown 및 ScaleUP을 지원하지는 않는다. 즉, worker노드의 개수변경은 지원하지만 EC2 유형 변경을 지원하지는 않는다는 말이다.

그렇다면, 유형만 변경하고 싶다면 어떻게 진행해야 할까?

NodeGroup 변경

새로운 NodeGroup을 생성하여 노드를 재 배포 한뒤, Pod를 옮기는 방법이 있겠다.

새로운 유형의 노드 그룹을 생성하고 기존의 노드에 있는 pod들을 drain node 하여, 새로운 node에 이동시킨다.

$ kubectl drain node_name --ignore-daemonsets

모두 이동된 것을 확인 한 후에 기존 node 그룹을 삭제하면 pod가 새로운 유형의 노드에 위치하게 된다.

$ kubectl get pods -o wide

 

 

Amazon EKS에서 작업자 노드 확인, 조정, 삭제 또는 드레이닝

eksctl 또는 AWS Management Console을 사용하여 Amazon Elastic Kubernetes Service(Amazon EKS) 작업자 노드를 시작한 후 작업자 노드를 확인, 조정, 드레이닝 또는 삭제하려고 합니다. 출력은 작업자 노드의 이름, Ku

aws.amazon.com

위의 문서도 참고하면 좋을 것 같다.