들어가기 앞서
현재 운영 중인 개발, 품질 및 운영 환경의 EKS 클러스터는 모두 Kubernetes 1.29.0 버전을 사용하고 있다. AWS에서 3월 말부터 1.29.0 버전이 만료되면 추가 요금이 발생하므로 1.31.0 버전으로 업그레이드를 진행하였다. 업그레이드는 먼저 DEV 환경의 클러스터를 대상으로 수행했으며, 외부망 및 내부망을 포함하여 총 6개의 EKS 클러스터를 업그레이드하였다. 또한, 금융권 특성상 굉장히 철저히 폐쇄망 환경을 유지하여.. 기본적인 인터넷조차 불가능하고 모든 설치파일 등을 파일 형태로 내부 반입하여 보안 점검을 하고 진행하였다.
업그레이드 조건
- 커스텀 노드 그룹 사용
- 관리형 노드 그룹이 아닌 커스텀 노드 그룹을 사용한다.
- 보안 소프트웨어가 설치된 Golden Image를 사용해야 하기 때문이다.
- Terraform을 활용한 업그레이드
- 모든 업그레이드는 Terraform을 사용하여 진행한다.
- Rolling Update 방식 선택
- 서브넷의 IP가 매우 부족한 상태이다. 추가 IP 할당은 어려운 상황.
- Blue-Green 업그레이드가 불가능하여, Rolling Update 방식으로 업그레이드를 진행하였다.
- Istio 업그레이드 필요
- 현재 사용 중인 Istio는 Kubernetes 1.29까지만 지원하므로, 업그레이드가 필요하다.
- 자체 관리형 애드온 및 AWS 관리형 애드온 업그레이드
업그레이드 순서
- Istio 업그레이드 (1.20.4 → 1.24.3)
- istioOperator 를 사용하여 신규 버전 설치
- 기존 애플리케이션 재배포 (istiod 1.24.3으로 labels 변경)
- sidecar.istio.io/inject: "true" → istio.io/rev = 1-24-3 변경
- Istio 구버전 삭제
https://hyukops.tistory.com/143
[istio] istioOperator 커스텀
1. IstioOperator 개요IstioOperator는 Istio 설치, 업그레이드, 관리를 담당하는 Kubernetes Custom Resource(CR) 와 이를 제어하는 Controller(istio-operator)이다. Istio 프로젝트에서는 단순히 Helm chart 기반 설치에서 발
hyukops.tistory.com
- EKS 업그레이드
- 클러스터 업그레이드 (1.29.0 → 1.30.0, Terraform 사용)
- EKS 노드 그룹의 Launch Template 업데이트 (Terraform 사용)
- EKS 관리형 애드온 및 자체 애드온 업그레이드 (kubectl 및 콘솔 작업)
- kubectl 클라이언트 업그레이드
- 위와 동일한 방식으로 1.31.0 버전까지 업그레이드 진행
첫번째 문제점 발생
현재 개발 계정의 VPC에는 두 개의 서브넷이 있으며, 각 서브넷에 EKS 노드가 배포되어 있다. 그러나 서브넷 내 사용 가능한 IP가 부족한 상태였고, 이를 고려하여 각 노드 그룹의 노드 수를 1개로 조정한 후 Rolling Update 방식으로 업그레이드를 진행하였다. 하지만 실행 중인 파드의 수가 많아 업그레이드 과정에서 새 노드가 정상적으로 배포되지 못했고, 이로 인해 롤링 업데이트가 중단되면서 장애가 발생하였다.
특히, 관리형 노드 그룹이 아닌 커스텀 노드 그룹을 사용하고 있어 AWS에서 제공하는 자동 업그레이드 기능을 활용할 수 없었다. 이를 해결하기 위해 Bastion 서버에서 Node Cordon 및 Node Drain을 강제로 수행하였으나, 노드가 지속적으로 생성되면서 문제가 반복되었다. 또한, 파드를 강제로 삭제하려는 시도도 모두 실패하여 정상적인 업그레이드 진행이 불가능한 상황이 발생하였다.
첫번째 문제점 해결
현재 환경에는 2개의 노드가 존재하고 각 서브넷별로 2개와 13개의 가용 IP가 남아있었고 더이상 ENI가 할당되지 못하는 상태였다. 우선 IP 부족 현상을 해결하기 위해 다음과 같은 방법을 사용하였다.
- aws-node dasemonset의 환경 변수 중 'WARM_ENI_TARGET = 1' 값을 'WARM_IP_TARGET = 3' 으로 변경
kubectl get daemonset aws-node -n kube-system -o yaml > aws-node.yaml
env:
- name: WARM_ENI_TARGET -> "WARM_IP_TARGET" 변경
value: "1" -> "3" 변경
kubectl apply -f aws-node.yaml
kubectl rollout restart daemonset aws-node -n kube-system
VPC CNI는 pod에 빠른 IP 할당을 위해서 미리 노드의 IP를 확보하도록 동작하며, 기본 설정인 'WARM_ENI_TARGET = 1' 설정에 의해서 완전히 비어있는 ENI를 준비하도록 노력한다. 하지만 ENI당 16개의 IP를 사용하는 현재 상태에서 노드는 부족한 서브넷의 IP로 인해서 추가 ENI를 할당할 수 없는 상태였다. WARM_IP_TARGET 설정 시, 완전히 비어있는 ENI를 준비하는 것이 아닌 IP 개수로만 여유 IP를 준비하기 때문에 남은 IP가 16개보다 적은 상황에서도 추가 IP 할당이 가능해진다.
원래 ENI를 하나 비워서 IP를 확보했던 방식(WARM_ENI_TARGET) 대신, IP 개수를 기준으로 여유분을 관리하는 방식(WARM_IP_TARGET)이 작동하기 때문에, 새로운 ENI를 붙일 수 없더라도 남아 있는 IP 자원 내에서 계속 Pod를 생성 가능하다.
이해가 어렵다면..
VPC CNI 에 대해 이해하기 어렵다면, 아래에 필자가 정리했던 포스팅을 확인하도록 하자
https://hyukops.tistory.com/125
[kubernetes] VPC CNI
VPC CNI란?AWS VPC CNI는 Amazon EKS 클러스터 내 Pod가 VPC IP를 사용할 수 있도록 하는 핵심 네트워킹 플러그인이다.구조는 크게 두 가지 컴포넌트로 이루어진다.CNI 바이너리 (/opt/cni/bin/aws-cni): Kubelet이 호
hyukops.tistory.com
또한, ENI/IP 할당 정책에 대해서는 최근에 올린 아래의 포스팅을 확인하도록 하자
https://hyukops.tistory.com/126
[kubernetes] IP/ENI 예비 할당 정책
네트워킹의 세 가지 핵심 요소각 파드는 고유한 IP 주소를 가진다.모든 파드는 NAT 없이 서로 통신할 수 있다.모든 노드는 NAT 없이 서로 통신할 수 있다. (참고: Kubernetes Core Concepts: Pod)EKS의 네트워
hyukops.tistory.com
'Kubernetes & EKS > k8s 운영 특이사항' 카테고리의 다른 글
| [kubernetes] failed to create pod sandbox 에러 발생 (2) | 2025.08.24 |
|---|---|
| [kubernetes] HPA loop 현상 해결 및 Best Practice (3) | 2025.07.30 |
| [kubernetes] 데몬셋 파드 Pending 현상 (PriorityClass) (0) | 2025.06.26 |
| [kubernetes] EKS의 Burstable 인스턴스 타입 변경 문제 (0) | 2025.05.08 |
| [kubernetes] EKS 업그레이드 장애 (2) - net.ipv4.ip_forward (0) | 2025.03.08 |