Kubernetes AWS EKS 1.30 업데이트 고려사항

Kubernetes 1.30 릴리즈 노트와 EKS 1.30 릴리즈 노트에 명시되지 않은 변화점으로 인해 문제가 발생할 수 있습니다.

특히 EKS Managed Node Group을 사용하고 있다면 1.30으로 업데이트 후, EKS Addon이나 AWS Credentials 획득 실패, IMDS (Instance Meta Data Service) 엑세스 실패등으로 pod들이 정상 동작 하지 않을 수 있습니다.

---

 

다음은 AWS 공식 EKS 1.30 Update 문서입니다.

1.30부터 AMI 기본 이미지가 AL2에서 AL2023으로 변경된다고 하고있으며, AL2와 AL2023 비교 문서의 링크를 제공하고 있습니다. 그러나 이미지 변경으로 인해 정확히 무슨 문제가 발생할 수 있는지는 표시하고 있지 않습니다.

 

Comparing AL2 and AL2023 문서도 살펴봅시다.

길고 장황한 change note이며 딱히 문제점이 있을만한 부분을 강조하고 있지도 않습니다.
그리고 이건 ec2 노드 호스트의 베이스 이미지 변경이므로, k8s의 pod 이미지로 도는 기존 워크로드에 큰 영향이 가지 않아야 하는게 정상이기도 합니다.

---

변경사항의 Security updates를 보면 IMDSv2 라는 항목이 있습니다.

IMDS가 무엇인지 간단히 설명하자면, AWS 인스턴스 메타데이터 서비스의 약자이며 EC2 인스턴스가 자신의 메타데이터에 접근할 수 있도록 제공하는 AWS 서비스입니다. 현재 EC2 환경 내에서 스스로의 이름, 인스턴스 종류, 어느 네트워크 VPC에 떠있는지, 시작 스크립트는 무엇인지 등등을 알 수 있도록 고정된 주소(http://169.254.169.254/latest/meta-data/) 를 통해 이러한 정보를 제공합니다.

즉, 이를 통해 EC2와 연관된 정보들을 획득하는데 사용하며, 특히 AWS EKS에서는 Addon들이 IMDS를 통해 여러 환경 정보를 스스로 파악해 동작하게 됩니다.

EKS Addon 중 많이 사용하게되는 aws load balancer controller 역시 그 중 하나로, VPC 정보를 별도 입력 없이 IMDS를 통해 질의하여 동작하는것이 기본 설치 옵션에서의 동작 방식입니다.

IMDS는 v1과 v2가 있으며 보안 조치 없이 항상 엑세스 가능한것이 v1, 보안 처리가 추가된것이 v2입니다.

v2에서는 특히 토큰 인증을 사용하며, 네트워크 홉 제한을 통해 호출자가 몇 단계 이상의 네트워크 인터페이스를 거치지 못하도록 제한하도록 되어있습니다.

---

이 문서의 Security updates - IMDSv2  항목을 살펴봅시다.

기본적으로 AL2023 이미지부터 IMDSv2-only 로 인스턴스가 실행되며, 컨테이너 워크로드 서포트 허용을 위해 default hop limit이 2로 설정된다고 명시하고 있습니다.

가상 컨테이너 환경 안에서 IMDS를 요청하면 먼저 컨테이너에서 가상 호스트 네트워크를 거쳐 IMDS endpoint로 들어가며, 이 거치는 단계로 인해 hop이 2가 됩니다. 즉, IMDSv2 hop이 1이라면 http 요청에 실패하게 됩니다.

이런 문제가 있기 때문에 AL2023은 기본 hop 설정을 2로 변경해서 EKS와 같이 컨테이너들을 실행하는 EC2들에서 문제가 없도록 제공한다고 씌여있는 겁니다.

그러나, 이 문서에 표시되지 않은 함정이 있는데 바로 Managed Node Group으로 EKS 노드용 EC2가 시작되었을때입니다.

Managed Node Group은 Launch Template 설정에 IMDS 설정이 포함됩니다.

여기서 Metadata 설정을 직접 수정하지 않았다면 AWS Default 설정을 사용하게 됩니다.

그럼 Default 설정이니 문제가 없겠네? 싶을 수 있는데 함정입니다. Managed Node Group에서 Launch Template에 AMI와 Metadata 설정을 하지 않은 경우 EKS 1.30 업데이트되고 뜨는 EC2 노드부터 AMI는 자동으로 AL2023으로 변경되고, Metadata version도 AL2023의 기본값인 IMDSv2 Required로 시작합니다.

여기까진 AL2023의 문서 그대로입니다만, 함정은 hop입니다. hop이 1로 뜹니다. 위에 서술했듯, Container 내에서 IMDS에 접근하려면 호스트 네트워크를 거치므로 무조건 hop 2가 필요합니다. 그래서 AL2023 AMI의 기본값도 hop 2로 변경한 것이죠. 그런데 Managed Node Group으로 생성된 EC2는 AL2023으로 뜨면서 IMDS는 v2로 띄우고 hop은 1로 띄웁니다.

EC2 console 안에서는 이 hop 수를 볼수도 없습니다. 그냥 1.30으로 올린 다음부터 pod안에서 aws credential을 가져오지 못하거나, aws load balancer controller에서 vpcId를 읽지 못하는 오류가 발생하거나 pod가 무한 재시작 되는 상황에서 문제를 추적하다 보면 이 hop에 문제가 있다는 것을 알게 됩니다.

어디에서 이 문제를 추적하고 있는지 찾아보았습니다.

---

우선 AL2023 출시를 공지한 github 이슈에서 이에 대한 설명이 있습니다.

Amazon Linux 2023 (AL2023) is now generally available for MNG, Karpenter, and self managed nodes · Issue #1696 · awslabs/amazon-eks-ami (github.com)

Amazon Linux 2023 (AL2023) is now generally available for MNG, Karpenter, and self managed nodes · Issue #1696 · awslabs/amazo

 

EKS - Managed Node Group 설명서의 항목에서도 다음 문구를 발견할 수 있습니다.

Customizing managed nodes with launch templates - Amazon EKS

 

aws load balancer controller 이슈도 하나 있습니다.

Does not work on Fresh EKS Cluster with Amazon Linux 2023 AMI Type Nodes · Issue #3695 · kubernetes-sigs/aws-load-balancer-controller (github.com)

 

AL2023 출시 블로그에도 문구가 있습니다.

Amazon EKS 최적화 Amazon Linux 2023 AMI 정식 출시 | 컨테이너

 

1.30 release note나 deprecated note 등 주요 업데이트 확인 포인트에는 일언반구도 AL2023과 hop 제한으로 문제가 생긴다는 언급이 없습니다. 어처구니 없게 지들이 만든 EKS Addon에서조차 hop 제한으로 업데이트만 하면 바로 동작하지 않게 만들어 놓았죠.

Managed Node Group에서만 hop 1로 걸고, 다른 EC2 생성에서는 hop 2로 생성이 됩니다. (카펜터등)

즉, 여러 방식으로 EC2를 띄우는 환경이라면 EC2를 누가 띄웠냐에 따라 pod가 동작 했다가 안했다가 한다는 말입니다. 하하 :) 병신들이냐 진짜?

해결법은 간단합니다. 이게 문제라는걸 알기 어려워서 문제인거고, Managed Node Group에서 사용하는 Launch Template에서 hop을 2로 설정하면 됩니다.