AWS EKS 업그레이드 시 발생했던 이슈들 공유

안녕하세요? DevOps Engineer 제이디입니다.

이번 포스팅에서는 AWS EKS를 운영하면서 업그레이드시 발생했던 이슈들을 공유해보겠습니다.

 

엔터프라이즈 환경에서 DevOps 변화관리를 진행하면서, 현재 2개의 EKS 클러스터를 운영하고 있습니다.

• GitLab 클러스터 (전사 표준 형상관리 및 CI/CD 도구 제공)
• DevOps 클러스터 (전사 운영시스템 DevOps 변화관리 포탈 서비스 제공)

AWS EKS 업그레이드는 기간에 맞춰서, 약 10개월에 한번 업그레이드를 진행하고있습니다.

EKS 업그레이드 시 어떤 이슈들이 있을까요?

Support 기간 종료일, 파랑색은 안전함, 노랑색은 무서움 ㅋㅋ

 

AWS EKS 업그레이드 시 발생했던 이슈는 크게 두가지가 있었습니다.

• Private Subnet의 IP 부족 이슈
• 클러스터의 Redis Pod가 Node 업그레이드 후 지워지는 현상

---

Private Subnet의 IP 부족 이슈

2022년도 11월에 사내 IDC의 Omnibus 형태의 GitLab를 AWS EKS로 마이그레이션하는 작업을 진행했습니다.

AWS에 리소스를 생성하기 위해 기본적으로 VPC가 필요한데요, IDC와 Site to Site VPN를 연결해서 사용하기 때문에 사내 IDC 팀을 통해서 VPC CIDR를 할당받게 됩니다.

한정적인 VPC CIDR에서 AWS EKS 환경에서 서비스를 운영하면서 Private Subnet의 IP가 점점 부족해지는 현상이 발생했습니다.

Private Subnet에 이용가능한 IP가 0인경우 Control Plane 업그레이드 실행 안됨

 

AWS EKS에서 프로비저닝되는 Pod가 자리가 널널한? Private Subent에 올라가길 매번 기도만 할 수는 없었습니다. (기도 영역)

관련해서 해결 방법을 찾기위해 사내 아키팀 담당자분과 AWS SA 담당자분과 미팅을 진행했습니다. (3가지 방법으로 미팅 진행)

AWS EKS 업그레이드 시 IP 이슈를 해결했던 최종 방법은 'Node Group의 Secondary IP를 활용하자'입니다.

---

aws-node(daemonset)의 MINIMUM_IP_TARGET를 활용한 Secondary IP 변경

AWS EKS에서 사용하는 Node Group의 EC2를 보면 Networking 항목에서 Secondary private IPv4 address를 확인 할 수 있습니다. 노드(EC2)당 약 30개의 IP 목록을 확인 할 수 있는데요, 이 IP들은 무엇일까요?

Secondary IP는 AWS EKS 환경에서 서비스 프로비저닝 시 사용되는 IP 목록입니다, 즉 예비 IP 풀이라고 할 수 있죠.

없는 살림에서 IP를 전달하는 Subnet의 운명 (예시)

 

AWS EKS를 사용하는 여러 이유가 있지만, 서비스가 Scale-out시 Pod가 늘어나면서 결국 IP를 추가적으로 사용해야됩니다.

Node Group의 각 EC2가 미리 여분의 IP(Secondary IP)를 보유하고 있으면서 빠른 대응을 진행하는 것이죠.

다만 문제는 Subnet에 이용 가능한 IP가 적을경우 AWS EKS의 Control Plane 업그레이드가 진행되지 않는다는 점입니다. (최소 4개인가 필요했어요)

각 Node(EC2)에는 kube-system 네임스페이스에 Daemonset으로 구성된 aws-node가 존재하며, aws-node가 각 Node에는 하는 역할 중 하나가 Secondary IP를 조절하는 것이죠.

kubectl set env daemonset aws-node -n kube-system MINIMUM_IP_TARGET=5

 

aws-node의 MINIMUM_IP_TARGET를 조절하면 위 내용 기준 노드(EC2)당 약 30개의 Secondary IP가 5개로 변경됩니다.

25개의 IP는 해당 Private Subnet에 이용 가능한 IP 목록으로 반환되게됩니다. (이제 Control Plane 업그레이드 가능)

---

Worker Node 업그레이드 시 PodEvictionFailure 에러 발생

Controle Plane 정상 업그레이드 완료 후 Worker Node 업그레이드 시 바로 에러가 발생합니다. (역시 한방에 잘되지 않습니다)

PodEvictionFailure 에러는 AWS Document 내용을 찾아보면, Worker Node 업그레이드 시 15분내에 Pod가 다른 Node로 이동하지 않고 force 플래그가 없으면 발생하는 오류입니다.

참고 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/managed-node-update-behavior.html

 

Worker Node를 업그레이드 하면서 Node들의 상태나 Pod들의 상태를 모니터링 해보면 상당히 더딘?(천천히) 움직임을 확인 할 수 있었습니다. 바로 사용 가능한 Secondary IP가 적어서 Subnet에서 이용 가능한 IP를 가져오는데 시간이 소요된다는 점이죠.

실제 EKS 업그레이드는 Control Plane 업그레이드 시 kube-system(daemonset)의 MINIMUM_IP_TARGET를 낮게 조절 후 진행하고 완료되면, 다시 MINIMUM_IP_TARGET의 값을 default로 변경하여 Worker Node를 업그레이드 진행합니다. (IP 이슈 해결)

---

EKS 업그레이드 완료, 정상적이지 않은 Pod

이렇게 AWS EKS의 업그레이드를 Support 기간에 맞춰서 업그레이드 완료하면 다 끝날까요? (역시 한방에 잘되지 않습니다)

Control Plane, Worker Node 등 EKS 업그레이드는 정상적으로 끝났지만 아래 두가지의 문제점이 있었습니다.

• Worker Node 업그레이드 후 Redis Pod가 삭제되는 현상
• Worker Node 업그레이드 후 Grafana 모니터링이 초기화되는 현상

두가지 현상에 관련된 이야기는 다음 포스팅에서 공유드리겠습니다.

감사합니다.