AEWS 9주차 - EKS Upgrade

본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다.  모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 

금주의 포스팅은 AWS EKS Workshop을 바탕으로 실습을 진행 및 정리하였습니다.

 

---

EKS Upgrade

 

 

EKS 버전은 왜 업그레이드 시켜야할까요?

 

아마 보안, EOS 등 여러가지 생각이 나실텐데 아래 6가지로 정리할 수 있을 것 같습니다.

 

1️⃣ 보안 패치 적용

• Kubernetes의 이전 버전은 **보안 취약점(CVE)**에 노출될 가능성이 높습니다.
• AWS는 EKS에서 특정 버전까지만 보안 패치를 제공하며, 지원이 종료된 버전에서는 심각한 보안 문제가 발생할 수 있습니다.
• 최신 버전으로 유지하면 공격 표면을 최소화하고, 안전한 환경을 유지할 수 있습니다.

2️⃣ EKS 지원 종료 정책

• AWS는 EKS 버전에 대해 약 14개월간만 지원하며, 이후에는 보안 패치 및 기술 지원이 중단됩니다.
• 지원이 종료된 버전에서는 새로운 기능을 사용할 수 없고, AWS의 EKS Managed Add-on도 최신 버전을 요구할 수 있습니다.

3️⃣ 새로운 기능과 성능 최적화

• Kubernetes는 지속적으로 네트워크, 스토리지, 스케줄링 최적화 등의 성능 개선을 포함한 새로운 기능을 제공합니다.
• 최신 버전을 유지하면 더 나은 리소스 활용, 빠른 스케줄링, 최적화된 워크로드 배포가 가능합니다.

4️⃣ 버전 불일치 문제 방지 (Version Skew Policy)

• EKS의 Control Plane과 Worker Node의 버전 차이가 2개 이상이면, 클러스터가 예상대로 동작하지 않을 수 있습니다.
• Kubernetes 공식 Version Skew Policy를 준수하지 않으면 kubectl CLI, 애드온(CoreDNS, VPC CNI, kube-proxy 등)과의 호환성 문제 발생 가능성이 높습니다.

5️⃣ 규정 및 컴플라이언스 준수

• 많은 기업 및 기관은 **보안 정책 및 컴플라이언스(GDPR, ISO 27001 등)**을 준수해야 합니다.
• Kubernetes의 최신 보안 패치를 적용하지 않으면 규정 준수가 어려울 수 있으며, 보안 감사를 통과하지 못할 수 있습니다.

6️⃣ 비용 및 운영 효율성

• 구버전의 Kubernetes를 유지하면 버그 수정, 패치, 비효율적인 리소스 관리로 인해 운영 비용이 증가할 수 있습니다.
• 최신 버전에서는 더 효율적인 리소스 관리 및 오토스케일링 기능이 추가되어 비용 절감 효과를 얻을 수 있습니다.

 

 

 

 

 

25년 4월 기준 1.32까지 나왔으며,최근 3개 버전 release branches(패치)합니다.

 

그리고 Version Skew Policy이 존재합니다.

 

Version Skew Policy란?

Version Skew Policy는 Kubernetes의 다양한 컴포넌트(컨트롤 플레인, 노드, 클라이언트 도구 등) 간의 버전 불일치 허용 범위를 정의하는 정책입니다. 이를 통해 클러스터 업그레이드 시 안정적인 운영과 호환성 유지를 보장합니다.

 

 

 

 

주요 원칙

 

1. Control Plane과 Node 간 버전 차이
   • EKS에서 Kubernetes Control Plane(마스터 노드) 버전은 항상 워커 노드보다 최신이어야 함
   • 최대 2개 이하의 마이너 버전 차이만 허용됨
   • 예를 들어, Control Plane이 v1.28이라면 노드는 v1.27 또는 v1.28이 가능하지만, v1.26 이하 버전은 지원되지 않음
2. kubectl(Client)과 Server 간 버전 차이
   • kubectl은 Kubernetes API 서버와 최대 1개 마이너 버전 차이까지만 보장됨
   • 예를 들어, API 서버가 v1.28이면 kubectl v1.27 또는 v1.28 사용 가능
   • 더 낮은 버전(v1.26 이하)의 kubectl은 예상치 못한 오류가 발생할 수 있음
3. Add-on 및 Controller 버전 관리
   • Kubernetes의 네이티브 애드온(CoreDNS, kube-proxy, VPC CNI 등)도 업그레이드 시 함께 확인해야 함
   • Add-on은 Control Plane과 최대 1개 마이너 버전 차이만 허용됨
   • Ingress Controller, CNI 플러그인 등도 Kubernetes 버전에 맞춰 업그레이드해야 함

 

 

이제 workshop의 실습으로 진행합니다. 

( 해당 workshop은 IaC도구인 Terraform으로 구성되어있습니다.)

 

[출처] 가시다님 스터디

 

 

위 workshop으로 이와 같은 프로세스를 이해할 수 있습니다.

 

 

구성 환경 확인

 

Cluster, Node, addon 확인

 

 

 

노드는 2개의 Managed Node, 2개의 Self-managed Node, 1개의 Fargate 그리고 karpenter을 이용한 Node들도 보입니다.

매우 다양한 타입의 노드들을 이용한 EKS Cluster을 가정합니다.

 

 

 

버전을 보시면 1.25로써 25년 4월 1일에는 이미 많이 노후된 버전입니다.

위에 도움말을 보면 알 수 있다시피 특정 extended support 기간이 지나면 클러스터는 자동으로 업그레이드합니다.

* 뿐만 아니라 extended support 비용은 꽤나 비싸기 때문에 꼭 유의하셔야합니다.

 

Support type Duration Price (per cluster per hour)

Standard	14 months starting from the date a version is generally available on Amazon EKS	$0.10
Extended	12 months starting from the date a version reaches the end of standard support in Amazon EKS	$0.60

 

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar

Understand the Kubernetes version lifecycle on EKS - Amazon EKS

 

 

 

이외에도 EKS 콘솔에서 업그레이드 인사이트를 통해 deprecate되는 것들을 미리 확인하고 대비할 수 있습니다.

 

 

 

crd 확인

 

 

helm 및 application 확인

 

pod, pdb확인

 

pdb : PDB(Pod Disruption Budget)는 Kubernetes에서 어떤 Pod들이 강제 종료되거나 재시작될 때 최소한의 가용성을 보장하는 정책입니다.

 

 

sts, pv, pvc 확인

 

 

그밖에도 nodepool, 권한, label등 많은 정보들을 확인할 수 있습니다.

 

 

 

이제 위에서 얘기했던 플로우를 다시 보면서 업그레이드를 준비합니다.

 

[출처] 가시다님 스터디

 

• 업그레이드 워크플로
  • Amazon EKS 및 Kubernetes 버전에 대한 주요 업데이트 식별 Identify
  • 사용 중단 정책 이해 및 적절한 매니페스트 리팩토링 Understand , Refactor
  • 올바른 업그레이드 전략을 사용하여 EKS 제어 평면 및 데이터 평면 업데이트 Update
  • 마지막으로 다운스트림 애드온 종속성 업그레이드

 

우선 upgrade insight를 통해 가시적으로 deprecate되는 것들이 존재하는지 가시적인 확인을합니다.

이후 설치 되어이는 addon들을 확인 (Self-managed addon)을 특히 유의하여 확인합니다.

 

무엇보다 AWS 공식문서를 통해 자세히 확인하는 것이 제일 정확합니다.

 

---

Control Plane Upgrade

 

 

Amazon EKS에서 클러스터를 실행하는 가장 큰 이점 중 하나는 클러스터 제어 평면의 업그레이드가 단일 완전 자동화된 작업이라는 것입니다. 업그레이드하는 동안 현재 제어 평면 구성 요소는 파란색/녹색 방식으로 업그레이드됩니다. 문제가 발생하면 업그레이드가 롤백되고 애플리케이션은 계속 작동하고 사용 가능합니다.

* 조건 : 클러스터를 생성할 때 지정한 서브넷에서 최대 5개의 사용 가능한 IP 주소가 필요합니다.

 

1.25 -> 1.26

 

 

variables.tf에 정의된 cluster의 버전을 1.26으로 수정하고 terraform apply를 통해 적용시킵니다.

 

 

Cluster의 상태가 변경되며, 약 10분후 업그레이드가 완료되면 상태가 활성으로 돌아갑니다.

 

 

 

IRSA를 이용하는 4개의 APP도 동작에 문제 없습니다.

 

 

또한 재생성된 파드가 없습니다.

 

 

 

하지만 hpa쪽에서 인사이트에 오류가 있음이 확인가능합니다.

 

 

이후 실습에서 고쳐질 것입니다.

 

---

Addon Upgrade

 

get addon 명령어를 통해 update available한 addon을 확인할 수 있습니다.

 

terraform을 사용하여 CoreDNS , kube-proxy 및 VPC CNI 의 업그레이드를 진행합니다.

 

 

 

coredns와 kube-proxy는 특정 버전을 지정해주며, vpc cni는 most recent가 true로 활성화 되어있네요

이대로 terraform apply를 진행합니다.

 

 

똑같이 상태가 변경되며, 약 1분후 업그레이드가 완료됩니다.

(롤링업데이트로 진행됩니다.)

 

---

Data Plane Upgrade(Inplace)

 

Data Plane은 두 노드 그룹을 하나는 in-place, 하나는 blue/green으로 업그레이를 진행합니다.

 

먼저 in-place 업그레이드를 통해 (RollingUpdate)를 진행하겠습니다.

 

 managed nodegroup의 version을 변경하고 terraform apply을 진행합니다.

* 저는 custom image를 활용한 실습은 건너띄었습니다.

 

 

eksctl 명령어 혹은 콘솔에서 손쉽게 inplace 업그레이드가 가능하지만

Terraform으로 관리하는 인프라라면 해당 AMI을 찾아서 var.tf을 수정 후 해당 버전을 지정하여 하나씩 올리는 방법도 좋은 것 같습니다.

 

 

 

 

이렇게 버전을 1단계씩 올리는 inplace 업그레이드를 경험했습니다.

inplace 업그레이드의 단점은 한번 올리면 롤백이 안된다는 점이 있습니다. 이번에는 블루/그린을 통해 

비용은 더 발생하지만 유연한 업그레이드를 진행해보겠습니다.

 

Data Plane Upgrade(Blue/Green)

 

우선 blue-mng 코드 밑에 green-mng를 추가하여서 green node를 생성합니다.

    green-mng={
      instance_types = ["m5.large", "m6a.large", "m6i.large"]
      subnet_ids = [module.vpc.private_subnets[0]]
      min_size     = 1
      max_size     = 2
      desired_size = 1
      update_config = {
        max_unavailable_percentage = 35
      }
      labels = {
        type = "OrdersMNG"
      }
      taints = [
        {
          key    = "dedicated"
          value  = "OrdersApp"
          effect = "NO_SCHEDULE"
        }
      ]
    }

  }

 

 

이렇게 green-mng를 1.26버전으로 만들고 문제가 없다고 판단되면 blue-mng을 삭제하여서 해당 노드에 있던

리소스들을 drain하여 성공적으로 1.26으로 마이그레이션을 진행합니다.

 

저희는 terraform으로 sync을 맞추기 때문에 해당 코드를 삭제하고 terraform apply를 진행합니다.

 

기존의 blue-mng는 notready 상태로 전환되는 로그도 확인이 가능합니다.

 

 

 

 

Data Plane Upgrade(Karpenter)

Karpenter 업그레이드 방식에는 원하는 버전으로 업그레이드를 유도하는 Drift와 TTL의 expire 시간을 이용한 업그레이드가 존재합니다. Drift는 그중에서도

1. Drift with specified AMI values 지정된 AMI 값을 사용한 드리프트

2. Drift with Amazon EKS optimized AMIs Amazon EKS 최적화 AMI를 사용한 드리프트

가 존재합니다.

 

하기에도 tf파일의 이미지를 1.26으로 바꾸고 code를 push하면 argocd가 이를 감지할 것입니다.

 

그리고 nodepool을 수정해줍니다.

kubectl get nodepool default -o yaml 
...
spec:
  disruption:
    budgets:
    - nodes: "1"
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  limits:
  ...

 

code를 push하고 argocp app을 sync해줍니다.

cd ~/environment/eks-gitops-repo
git add apps/karpenter/default-ec2nc.yaml apps/karpenter/default-np.yaml
git commit -m "disruption changes"
git push --set-upstream origin main
argocd app sync karpenter

 

Nodeclass의 ami 이미지를 drift하여 새로운 이미지(1.26)의 ami로 노드를 생성합니다.

 

 

Data Plane Upgrade(Self Managed Node)

 

기본 정보 확인

 

원래 Self-Node는 Launch Template을 수정하여서 업그레이드를 진행합니다.

 

본 워크샵은 Terraform으로 해당 인프라들이 배포되어있어서 tf파일의 ami를 수정하여 업데이트 및 업그레이드가 가능합니다.

 

 

terraform apply를 진행합니다.

 

 

새로운 버전의 node를 올리고 예전 버전의 노드를 하나씩 지우는 방식으로 올라옵니다.

 

 

 

Data Plane Upgrade(Fargate)

 

기본 정보 확인

 

Fargate는 data plane도 AWS에서 관리해줍니다. 그러면 ami 버전을 어떻게 지정할 수 있을까요?

 

이번 실습에서는 rollout restart deployment로 재배포만 하면 알아서 control plane과 호환되는 최신 버전의 노드가 올라오는 것으로 확인이 되어지네요

# 디플로이먼트 재시작 Restart
kubectl rollout restart deployment assets -n assets

 

 

AWS에서 관리해주는 영역이 많아질수록 업그레이드는 더욱 쉬워지는 것 같습니다.

 

 

이렇게 EKS 업그레이드에 대한 전반적인 내용들을 확인해보았습니다.