EKS add-on(vpc-cni) 업그레이드 이슈

본 글은 EKS add-on 업그레이드 중 발생한 이슈 내용을 기록하기 위한 글이다.

 

아래는 AWS에서 제공하는 EKS 버전 공식 지원 종료 날짜이다.

Kubernetes 버전	업스트림 릴리스	Amazon EKS 릴리스	Amazon EKS 지원 종료
1.26	2022년 12월 9일	2023년 4월 11일	2024년 6월
1.25	2022년 8월 23일	2023년 2월 22일	2024년 5월
1.24	2022년 5월 3일	2022년 11월 15일	2024년 1월
1.23	2021년 12월 7일	2022년 8월 11일	2023년 10월
1.22	2021년 8월 4일	2022년 4월 4일	2023년 6월 4일
1.21	2021년 4월 8일	2021년 7월 19일	2023년 2월 15일
1.20	2020년 12월 8일	2021년 5월 18일	2022년 11월 1일

링크:https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html

Amazon EKS Kubernetes 버전 - Amazon EKS

 

ami 버전 : https://github.com/awslabs/amazon-eks-ami/blob/master/CHANGELOG.md

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

 

addon 버전 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-networking-add-ons.html

Amazon EKS 네트워킹 추가 기능 - Amazon EKS

 

 

EKS를 업그레이드할 때 다음과 같은 절차가 이루어진다.

1. EKS Cluster 업그레이드
2. 업그레이드 호환 버전으로 add-on, 시작 템플릿 ami 업데이트
3. EKS Worker node 개수 2배로 확장
4. 기존 Worker node drain을 사용하여 Pod를 신규 노드로 이동
   1. PDB 설정으로 인해 drain이 안 되는 증상이 발생할 수 있으니 PDB 설정 체크가 필요할 수 있다
5. Worker node를 원래 개수로 축소
   1. 추가된 노드에는 scale-in protection 옵션이 적용되어 기존 노드만 삭제된다
   2. Auto Scaling 그룹에 lifecycle hooks에 종료에 대한 heartbeat timeout 이 설정되어 있으면 해당 시간이 지나고 종료된다.

목차

1. 상황
2. 원인
3. 해결

 

1. 상황

---

EKS의 버전 1.22를 1.23으로 업그레이드하고 이에 맞게 add-on을 업데이트하는 과정에서 발생한 이슈이다. 

( v1.11.0-eksbuild.1 -> v1.12.6-eksbuild.1 )

 

환경에 대한 구성을 간략하게 표현하면 아래와 같다.

Application LoadBalancer의 Forward to target group으로 EKS의 Pod들이 연결되어 있고, 해당 Pod들은 Pod 전용 security group(SecurityGroupPolicy)를 사용하여 통신하고 있다.

 

1.22 버전은 6월 4일까지 지원 종료이므로 6월 전까지 업데이트를 해야 했다.

 

EKS 버전에 맞게 add-on도 함께 업그레이드를 진행하였다. 업그레이드 중 add-on 업데이트 과정에서 5분가량 애플리케이션의 통신이 안 되는 문제가 발생하였다.

 

문제는 Target group에서 등록되어 있는 대상에 대한 상태가 unhealthy로 되었다가 healthy 상태로 원복 된 상황을 확인하게 되었다.

 

아래는 문제 발생한 시간에 AWS Target group의 monitoring 지표이다.

 

 

2. 원인

---

현재 테라폼으로 EKS를 관리하는데, aws_eks_addon 리소스 블록에서 vpc-cni를 업데이트하는 부분에서 문제가 있었다.

add-on 테라폼 코드는 다음과 같다.

## add on ##
resource "aws_eks_addon" "addon" {
  cluster_name = aws_eks_cluster.eks.name
  addon_name   = "vpc-cni"
  addon_version = "v1.11.0-eksbuild.1"
  resolve_conflicts    = "OVERWRITE"
}

참고) 현재 aws provider 버전은 3.76.1을 사용하고 있다

addon_version을 현재 권장 버전인  v.1.12.6-eksbuild.1으로 변경하고 배포하면 해당 버전으로 EKS에 배포되어 있는 aws-node 데몬셋의 image 업데이트가 이루어진다. 이때 충돌이 발생하여 이를 해결하기 위해 resolve_conflicts 옵션 값인 "OVERWRITE" 에 의해 업데이트되는 버전의 기본 스키마 값으로 OVERWRITE 되어 업데이트가 된다.

 

즉, pod 전용 security group을 사용하기 위해 설정한 값이 default 값으로 덮어 씌워져 문제가 발생한다는 의미이다.

 

resolve_conflicts 옵션에 대한 설명은 다음과 같다.

• PRESERVE : 애드온의 기존 구성 값을 보존한다. 애드온 설정에 사용자 정의 값을 설정한 경우 이 옵션을 사용하지 않으면 Amazon EKS가 기본값으로 값을 덮어쓰게 된다. 이 옵션을 사용하는 경우, 프로덕션 클러스터에서 애드온을 업데이트하기 전에 테스트 클러스터에서 필드 및 값 변경을 테스트하는 것을 권장한다.
• OVERWRITE : 모든 설정이 Amazon EKS의 기본값으로 변경된다. 설정에 사용자 정의 값을 설정한 경우 이 값들은 Amazon EKS의 기본값으로 덮어 쓰일 수 있다. 
• none : Amazon EKS는 모든 설정의 값을 변경하지 않지만 업데이트가 실패할 수 있다. 업데이트가 실패하면 충돌을 해결하는 데 도움이 되는 오류 메시지를 받게 된다.

 vpc-cni가 배포되면 pod 전용 security group을 사용하기 위해 테라폼에서 aws-node 데몬셋의 "ENABLE_POD_ENI"," DISABLE_TCP_EARLY_DEMUX" 두 값을 true로 변경하는 트리거 코드가 동작하게 구성되어 있다.

 

만약 resolve_conflicts=OVERWRITE 값에 의해  pod 전용 security group 사용을 위해 설정한 aws-node 데몬셋의 값이 원복 되었다면 이후 트리거 코드에 의해 다시 설정하는 것이다.

 

aws-node의 값에 대한 변화 과정을 요약하자면 아래와 같다.

1. 업데이트 전 : ENABLE_POD_ENI=true, DISABLE_TCP_EARLY_DEMUX=true (정상)

2. 업데이트 후 : ENABLE_POD_ENI=false, DISABLE_TCP_EARLY_DEMUX=false (실패)

3. 트리거 동작 : ENABLE_POD_ENI=true, DISABLE_TCP_EARLY_DEMUX=true (정상)

 

업데이트 후 false상태에서 잠깐 통신이 안되었다가 트리거 동작에 의해 다시 true로 변경되어 동작이 되는 것이다.

 

"ENABLE_POD_ENI=true" 값은 노드가 교체될 때 적용 되므로, 실제로 false 값에 의해 pod security group 통신에 영향을 주는 값은 "DISABLE_TCP_EARLY_DEMUX=false" 이다.

 

 

3. 해결

---

위 문제가 발생하지 않으려면 resolve_conflicts=OVERWRITE 값을 PRESERVE 값으로 변경하면 기존 설정값을 유지하기 때문에 업데이트 간 pod 전용 security group 사용 관련하여 문제가 발생하지 않는다.

## add on ##
resource "aws_eks_addon" "addon" {
  cluster_name = aws_eks_cluster.eks.name
  addon_name   = "vpc-cni"
  addon_version = "v1.12.6-eksbuild.1"  ## 업데이트 버전으로 변경
  resolve_conflicts    = "PRESERVE"    ## 변경
}

하지만 해당 옵션은 새 버전의 VPC CNI가 기존과 호환되지 않을 수 있고, 이번과 같은 예기치 않은 네트워크 중단이 발생할 수 있기 때문에 충분히 테스트 환경에서 적용해 보고 동작에 이상이 없는지 검증 후 프로덕션 환경에 적용해야 한다.

 

 

분석

---

그동안 지속적으로 버전 업데이트를 해왔는데 왜 이제 문제가 발생했나?라는 의문이 들 수 있다.

 

아래 명령을 통해 vpc-cni의 버전별 configuration 스키마 값을 확인할 수 있다.

$ aws eks describe-addon-configuration --addon-name {{addon-name}} --addon-version {{addon-version}}
예) aws eks describe-addon-configuration --addon-name vpc-cni --addon-version v1.11.0-eksbuild.1

위 그림을 보면 v1.12.1에 DISABLE_TCP_EARLY_DEMUX 스키마 값이 있는 걸 확인할 수 있다.

 

즉, 이전 사용하던 버전에서는 DISABLE_TCP_EARLY_DEMUX 스키마 값이 존재하지 않아 기존 설정되어 있던 "DISABLE_TCP_EARLY_DEMUX=true" 값이 유지되었지만 v1.12.1-eksbuild.1부터 "DISABLE_TCP_EARLY_DEMUX"

스키마가 추가되어 있어 해당 기본값인 "DISABLE_TCP_EARLY_DEMUX=false"가 overwrite 된 것이었다.

 

실제로 resolve_conflicts=OVERWRITE 값으로 업데이트를 해보면 1.12.1-eksbuild.1부터 DISABLE_TCP_EARLY_DEMUX 값이 false로 overwrite 되어 변경되는 걸 확인할 수 있다.

 

참고로 v1.12.1-eksbuild.1 이전 버전 중에서도 DISABLE_TCP_EARLY_DEMUX  스키마 값이 존재하는 버전도 있다.