들어가며
AWS에서 EKS 클러스터를 운영하다 보면 어느 순간 반드시 마주하게 되는 작업이 있습니다. 바로 Kubernetes 버전 업그레이드입니다.
보안 패치나 신규 기능을 위해 필요한 과정이지만, 어디서부터 어떻게 시작해야 할지 막막한 경우가 많습니다.
단순히 Control Plane만 업그레이드하면 끝일 것 같지만, 실제로는 Add-on과 Managed Node Group(Data Plane)까지 함께 고려해야 안정적인 업그레이드가 가능합니다. (게다가 업그레이드 방식도 In-Place로 할지, Blue-Green 전략을 쓸지 선택해야 합니다.)
이번 포스팅에서는 AWS EKS 클러스터를 업그레이드할 때 필요한 모든 과정을 AWS Workshop을 통해 실습해 보면서 해당 내용을 정리했습니다.
EKS Version Upgrade
Kubernetes Release Cycle
Kubernetes는 기능 업그레이드, 최신 보안 패치 및 버그 수정등을 통해 지속적으로 업그레이드되고 있습니다.
kubernetes의 버전은 가장 대중적인 Semantic Versioning 규칙을 따르며 일반적으로 x.y.z로 표현되는데 x는 주요 버전, y는 마이너 버전, z는 패치 버전입니다.
새로운 Kubernetes 마이너 버전(y)은 대략 4개월마다 출시되며, 모든 버전은 12개월 동안 표준 지원을 제공하며, 한 번에 최소 3개의 마이너 버전을 지원합니다.
이에 EKS는 Kubernetes 프로젝트 릴리스 주기를 따르지만, 처음 제공된 후 14개월 동안 4개의 마이너 버전에 대한 표준 지원을 제공합니다.
표준 지원(14개월)외에도 12개월을 지원하는 확장 지원(Extended Support)도 제공하며, 확장 지원 기간이 끝나기 전에 클러스터가 업데이트되지 않으면 현재 지원되는 가장 오래된 확장 버전으로 자동 업그레이드됩니다.
| Support type | Duration | Price (per cluster per hour) |
| Standard |
일반적으로 Amazon EKS에서 버전을 사용할 수 있는 날로부터 14개월 후
|
$0.10 |
| Extended |
버전이 Amazon EKS에서 표준 지원이 종료된 날로부터 12개월 후
|
$0.60 |
확장 지원 기간 동안 Kubernetes 버전을 실행하는 클러스터의 가격은 2024년 4월 1일부터 클러스터당 시간당 총 $0.60의 요금이 부과되며, 표준 지원 기간에는 변경되지 않습니다.(클러스터당 시간당 $0.10)
2024년 7월 23일, Amazon EKS는 Kubernetes 버전 정책에 대한 Amazon EKS 제어를 통해 클러스터 관리자는 EKS 클러스터에 대한 표준 지원 동작 종료를 선택할 수 있습니다. 이러한 제어를 통해 어떤 클러스터가 확장 지원을 받아야 하는지와 Kubernetes 버전에 대한 표준 지원 종료 시 자동으로 업그레이드되어야 하는지 결정할 수 있습니다. 이 제어는 클러스터별로 실행되는 환경이나 애플리케이션에 따라 버전 업그레이드를 비즈니스 요구 사항과 균형 있게 조정할 수 있는 유연성을 제공합니다.
Amazon EKS Version Upgrades
EKS Upgrade 순서
Prepare (업그레이드 전 준비)
✅ 업그레이트를 시작하기 전에 릴리즈 노트를 통해 변경된 사항이나 추가된 내용을 미리 검토합니다.
✅ Cluster 를 생성할 때 지정한 subnet에서 최대 5개의 사용가능한 IP주소가 필요합니다.
✅ Cluster의 IAM과 Security Group이 해당 AWS 계정에 있어야 합니다.
EKS Upgrade Insights
Amazon EKS가 Control Plane을 자동으로 업그레이드하기에 이로 인해 영향을 받을 가능성이 있는 리소스나 애플리케이션을 식별하는 것은 수동으로 확인해야 하는 프로세스입니다. (릴리즈 노트를 검토하여 더 이상 사용되지 않거나 제거된 Kubernetes API를 확인한 다음 해당 API를 사용하는 서비스나 애플리케이션을 식별하여 수정하는 작업등)
이때, EKS Upgrade Insights를 활용하여 EKS Cluster를 업그레이드할 때 생길 수 있는 호환성 문제나 변경 사항을 사전에 파악할 수 있습니다.
aws eks list-insights --cluster-name=$CLUSTER_NAME --filter kubernetesVersions=1.29
aws eks list-insights 명령어를 통해 지정한 클러스터에 대해 AWS가 분석한 잠재적인 업그레이드 이슈 목록을 확인하실 수 있습니다.
EKS Upgrade Checklist
EKS 1.32, EKS 1.31, EKS 1.30등 EKS 문서를 참고하여 업그레이드 체크리스트를 만듭니다. 이때, 각 버전의 주요 변경 사항과 고려 사항을 확인해야 합니다.
업그레이드 전략 선택
In-Place Upgrade
기존 EKS 클러스터를 최신 Kubernetes 버전으로 업그레이드하는 방식입니다.
1. EKS Control Plane을 목표하는 Kubernetes 버전으로 업그레이드합니다.
2. 목표하는 Kubernetes 버전과 일치하도록 worker node AMI를 업데이트합니다.
3. 애플리케이션 가동 중지 시간을 최소화하기 위해 worker node를 한 번에 하나씩 또는 소규모로 정리하고 교체합니다.
4. 새 버전과의 호환성을 보장하기 위해 모든 Kubernetes 매니페스트, 애드온 및 구성을 업데이트합니다.
| 장점 | 단점 |
| VPC, 서브넷, 보안 그룹 등 기존 클러스터 리소스와 구성 유지 | 업그레이드 과정에서 가동 중지 시간을 최소화하려면 신중한 계획과 조정이 필요 |
| 동일한 클러스터 API 엔드포인트를 유지하므로 최소한으로 업데이트 | 여러 Kubernetes 버전을 건너뛸 경우 연속적인 업그레이드가 여러 번 필요할 수 있으며, 업그레이드 프로세스가 길어질 수 있음 |
| 클러스터간 상태 저장 애플리케이션과 지속형 데이터를 마이그레이션할 필요성을 최소화 | 업그레이드 중에 문제가 발생하면 롤백이 더 어렵고 시간이 많이 소요됨. (Control Plane이 업그레이드 되면 롤백할 수 없음) |
Blue-Green Upgrade
새 EKS 클러스터(addon, apps)를 만들고 트래픽을 이전 클러스터에서 새 클러스터로 점진적으로 전환하는 업그레이드 방식
1. 원하는 Kubernetes 버전 및 구성으로 새 EKS 클러스터(green)를 만듭니다.
2. 새 클러스터에 애플리케이션, 애드온 및 구성을 배포합니다.
3. DNS 업데이트, 로드 밸런서 구성 또는 서비스 메시와 같은 기술을 사용하여 점진적으로 이전 클러스터(blue)에서 새 클러스터(green)로 트래픽을 전환합니다.
4. 새 클러스터가 트래픽을 처리하고 성능에 문제가 없는지 지속적으로 모니터링합니다.
5. 이후 모든 트래픽이 새 클러스터로 전환되면 이전 클러스터를 해제합니다.
| 장점 | 단점 |
| 단일 업그레이드에서 여러 Kubernetes 버전을 건너뛸 수 있으므로 전체 업그레이드 시간과 노력이 감소 | 두 개의 클러스터를 동시에 유지 관리해야 하므로 업그레이드 프로세스에 추가적인 인프라 리소스와 비용 필요 |
| 문제가 발생할 경우 트래픽을 이전 클러스터로 다시 전환하여 빠르고 쉬운 롤백 메커니즘을 제공 | CI/CD 파이프라인, 모니터링 시스템, 액세스 제어 등의 외부 통합을 업데이트하여 새 클러스터와 연결해야 함. |
| 새 클러스터가 완전히 검증될 때까지 이전 클러스터가 계속 트래픽을 제공하므로 업그레이드 프로세스 동안 가동 중지 시간 최소화 | 클러스터 간 데이터 마이그레이션이나 동기화가 필요한 상태 저장 애플리케이션의 경우 어려울 수 있음. |
K8S Version Skew 를 이용한 Incremental In-place 업그레이드 전략
EKS Control plane과 worker node가 정확히 같은 버전일 필요는 없지만, 일정 범위 안에서만 차이가 허용된다는 규칙으로, 허용되는 최대 버전 skew에 도달할 때까지 workder node 업그레이드를 연기하면서 EKS Controle Plane을 점진적으로 업그레이드하는 전략입니다.
업그레이드 프로세스
1. EKS Control Plane을 다음 마이너 버전으로 업그레이드 합니다.
2. Control Plane이 최대 허용 Skre를 초과하는 버전으로 업그레이드될 때까지 기존 버전에서 workder node를 업그레이드하지 않습니다.
3. Control Plane이 허용되는 최대 Skew를 초과하는 버전에 도달하면 Control Plane을 추가로 업그레이드하기 전에 지원되는 Skew내의 버전으로 Worker node를 업그레이드합니다.
4. Control Plane과 Worker Node 모두 지원하는 Kubernetes 버전에 도달할 때까지 1~3 단계를 반복합니다.
실습 - v1.25 -> v1.26
이제 위에서 살펴본 이론을 바탕으로 직접 실습을 진행해 보겠습니다.
1. kubernetes 릴리즈 노트 검토
2. Control Plane 업그레이드
2-1. (필요시) 백업
3. Add-on 업그레이드
4. Data Plane 업그레이드
5. 완료
Control Plane 업그레이드
eksctl로 업그레이드
eksctl upgrade cluster --name $EKS_CLUSTER_NAME --approve
eksctl을 통해 cluster를 업그레이드하는 방법은 대상 버전을 지정할 수 있지만 --version에 허용되는 값은 클러스터의 현재 버전 이거나 한 버전 더 높은 버전입니다. 즉, 두 개 이상의 Kubernetes 버전 업그레이드는 지원되지 않습니다.
AWS Console에서 업그레이드
AWS Managed Console에서 EKS 메뉴로 접근하신 후 업그레이드를 진행할 Cluster 클릭 후 상단에 버전 업그레이드 버튼을 클릭합니낟.
그럼 위와 같이 대화상자나 나오게 되는데 해당 기능을 통해 업그레이드를 진행할 수 있습니다.
aws cli로 업그레이드
aws eks update-cluster-version --region ${AWS_REGION} --name $EKS_CLUSTER_NAME --kubernetes-version 1.26
aws cli로 cluster 업그레이드를 위와 같이 명령함으로써 업그레이드가 가능합니다.
클러스터에 관리되는 노드 그룹이 연결되어 있는 경우, 클러스터를 새로운 Kubernetes 버전으로 업데이트하려면 모든 노드 그룹의 Kubernetes 버전이 클러스터의 Kubernetes 버전과 일치해야 합니다.
aws eks describe-update --region ${AWS_REGION} --name $EKS_CLUSTER_NAME --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f
describe-update 명령으로 클러스터 업데이트 상태를 모니터링할 수 있습니다. update-cluster-version 명령에서 반환받은 클러스터 이름과 업데이트 ID를 사용하며, Successful 상태가 표시되면 업데이트가 완료된 것입니다.
terraform으로 업그레이드
variable "cluster_version" {
description = "EKS cluster version."
type = string
default = "1.25"
}
variable "mng_cluster_version" {
description = "EKS cluster mng version."
type = string
default = "1.25"
}
...
현재 variable.tf 파일에 위와 같이 cluster_version이 1.25로 명시되어 있습니다.
terraform plan
해당 값을 1.26으로 변경 후 terraform plan 명령어를 실행해 보겠습니다.
...
# module.eks_blueprints_addons.data.aws_eks_addon_version.this["aws-ebs-csi-driver"] will be read during apply
# (depends on a resource or a module with changes pending)
<= data "aws_eks_addon_version" "this" {
+ addon_name = "aws-ebs-csi-driver"
+ id = (known after apply)
+ kubernetes_version = "1.26"
+ most_recent = true
+ version = (known after apply)
}
...
# module.eks_blueprints_addons.aws_eks_addon.this["vpc-cni"] will be updated in-place
~ resource "aws_eks_addon" "this" {
~ addon_version = "v1.19.3-eksbuild.1" -> (known after apply)
id = "eksworkshop-eksctl:vpc-cni"
tags = {
"Blueprint" = "eksworkshop-eksctl"
"GithubRepo" = "github.com/aws-ia/terraform-aws-eks-blueprints"
}
# (11 unchanged attributes hidden)
# (1 unchanged block hidden)
}
..
몇 가지의 add-on이 변경되는 것을 확인하실 수 있습니다.
terraform apply -auto-approve
이제 terraform apply를 통해 plan의 결과를 확인한 상태로 적용해 보겠습니다. 이때, managed node group에 대한 특정 버전이나 AMI가 테라폼 파일에 정의되지 않은 경우, eks cluster control plane과 managed node group. add-on과 같은 관련 리소스를 업데이트하게 됩니다.
위와 같이 업그레이드가 동작중인 것을 바로 확인하실 수 있습니다. (대략 10분 정도 소요)
EKS Controle Plane 업그레이드가 완료되었으니 Add-on 소프트웨어 업그레이드를 진행해 보겠습니다.
Add-on 업그레이드
현재 적용 중인 Add-on 목록 확인
현재 Cluster에 적용되어 있는 Add-on은 VPC CNI, CoreDNS, kube-proxy, EBS CSI Driver 4개입니다.
VPC CNI 호환성 확인
공식문서에서 버전 호환성을 확인하실 수 있습니다.
CoreDNS 호환성 확인
공식 문서에서 버전 호환성을 확인하실 수 있습니다.
kube-proxy 호환성 확인
공식문서에서 버전 호환성을 확인하실 수 있습니다.
eksctl을 통해 확인
eksctl get addon --cluster $CLUSTER_NAME
eksctl을 사용하여 업그레이드 가능한 Add-on의 버전들을 확인하실 수 있습니다.
Terraform으로 버전 확인
Terraform으로 Cluster를 관리하신다면 위와 같이 Add-on의 정보가 있는 tf 파일을 통해 현재 어떤 version이 명시되어 있나 확인하실 수 있습니다.
업그레이드할 Add-on 버전 확인
CoreDNS 버전 확인
aws eks describe-addon-versions --addon-name coredns --kubernetes-version 1.26 --output table \
--query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}"
Amazon EKS는 현재 cluster의 version에 호환되는 Add-on의 버전을 나열하는 API를 제공합니다.
위의 명령을 통해서 현재 Cluster의 버전인 1.26과 호환되는 coredns애드온 버전을 찾을 수 있습니다.
위의 사진과 같이 업데이트 가능한 Add-on 버전을 확인하실 수 있는데, coreDNS는 v1.9.3-eksbuild.22으로 업그레이드를 진행하면 됩니다!
kube-proxy 버전 확인
ws eks describe-addon-versions --addon-name kube-proxy --kubernetes-version 1.26 --output table \
--query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}"
마찬가지로 kube-proxy도 확인해 보겠습니다.
vpc-cni 버전 확인
aws eks describe-addon-versions --addon-name vpc-cni --kubernetes-version 1.26 --output table \
--query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}"
VPC-CNI도 마찬가지로 현재 cluster 버전에 설치가능한 최신 버전을 확인해 보겠습니다.
VPC-CNI를 확인해 본 결과 이미 최신버전이 설치되었기 때문에 넘어가도 되는 것을 확인하실 수 있습니다.
Add-on 버전 업그레이드
module "eks_blueprints_addons" {
...
eks_addons = {
coredns = {
addon_version = "v1.9.3-eksbuild.22"
}
kube-proxy = {
addon_version = "v1.26.15-eksbuild.24"
}
vpc-cni = {
most_recent = true
}
aws-ebs-csi-driver = {
service_account_role_arn = module.ebs_csi_driver_irsa.iam_role_arn
}
}
...
위에서 확인한 최신 버전의 Add-on 버전으로 terraform 코드를 수정합니다.
terraform plan
terraform plan 명령어를 실행하여 어떻게 변경되는지 확인해 보겠습니다.
coreDNS와 kube-proxy가 수정한 버전으로 업그레이드되는 결과를 확인하실 수 있습니다.
terraform apply --auto-approve
plan의 결과가 이상이 없다면 apply를 진행합니다. (대략 1분 정도 이내로 롤링 업데이트로 업데이트가 완료됩니다.)
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c
이제 Cluster에 설치된 add-on의 목록을 확인해 보겠습니다.
업데이트 후 coreDNS와 kube-proxy의 버전이 최신버전으로 업데이트된 것을 확인하실 수 있습니다.
Data Plane 업그레이드 - In-Place 방식
Amazon EKS 관리형 노드 그룹을 사용하면 Kubernetes 애플리케이션을 실행하기 위해 EC2를 별도로 생성할 필요가 없습니다.
In-Place 업그레이드 방식은 기존 Node Group을 유지한 채, Kubernetes 버전의 EKS AMI를 적용하여 노드를 순차적으로 교체하는 방식입니다. 업그레이드를 진행할 노드는 cordon 및 drain을 거쳐 종료되고, 새로운 버전의 노드로 대체되며 롤링 업그레이드 형식으로 진행됩니다. 이 방식은 별도의 Node Group을 만들지 않고도 업그레이드를 수행할 수 있습니다.
eksctl로 업그레이드
# 사용 중인 AMI 유형의 Kubernetes 버전에 대한 최신 AMI 릴리스 버전으로 노드 그룹 업데이트
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=$EKS_CLUSTER_NAME
# 노드 그룹이 클러스터의 Kubernetes 버전에서 이전 Kubernetes 버전인 경우, 노드 그룹을 클러스터의 Kubernetes 버전과 일치하는 최신 AMI 릴리스 버전으로 업데이트
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=$EKS_CLUSTER_NAME --kubernetes-version=<control plane version>
# 최신 버전 대신 특정 AMI 릴리스 버전으로 업그레이드
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=$EKS_CLUSTER_NAME --release-version=<specific AMI Release version>
aws managed console
EKS 메뉴에서 컴퓨팅 > 노드 그룹에 보이는 노드 그룹의 [ 지금 업데이트 ] 버튼을 클릭하면 아래와 같이 수동으로 업그레이드가 가능합니다.
Terraform으로 업그레이드
managed node group을 업그레이드할 때에 AMI ID를 변경하여 업그레이드하거나 지정된 K8s에 대한 기본 AMI 사용하는 방식으로 진행됩니다.
여기서는 사용자 지정 AMI를 사용하여 신규 관리 노드 그룹을 생성하도록 하겠습니다. 이를 위해 업그레이드 시 기존의 pod를 옮겨 운영에 문제없이 배포하기 위해 kubernetes 버전 1.25의 ami_id를 가져오고 variable.tf 파일의 변수 ami_id를 결과 값으로 대체하여 새로운 노드그룹으로 배포해 보겠습니다.
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.25/amazon-linux-2/recommended/image_id \
--region $AWS_REGION --query "Parameter.Value" --output text
위와 같이 ami id가 반환되는 것을 확인하실 수 있습니다.
variable "cluster_version" {
description = "EKS cluster version."
type = string
default = "1.26"
}
variable "mng_cluster_version" {
description = "EKS cluster mng version."
type = string
default = "1.25"
}
variable "ami_id" {
description = "EKS AMI ID for node groups"
type = string
default = "ami-0078a0f78fafda978" # ami_id 추가
}
위에서 EKS 버전을 수정했던 tf 파일에서 ami_id의 값을 변경하도록 하겠습니다.
...
custom = {
instance_types = ["t3.medium"]
min_size = 1
max_size = 2
desired_size = 1
update_config = {
max_unavailable_percentage = 35
}
ami_id = try(var.ami_id)
enable_bootstrap_user_data = true
}
...
사용자 정의 managed node group을 생성하기 위해 eks eks_managed_node_groups 리소스에 위의 코드를 추가합니다.
terraform apply -auto-approve
terraform apply를 진행한 후 약 2분 정도 지나면 새로운 managed node group이 생성됩니다.
노드 그룹과 노드가 생성된 것을 확인하실 수 있습니다.
variable "cluster_version" {
description = "EKS cluster version."
type = string
default = "1.26"
}
variable "mng_cluster_version" {
description = "EKS cluster mng version."
type = string
default = "1.26" # 1.25 -> 1.26
}
variable "ami_id" {
description = "EKS AMI ID for node groups"
type = string
default = "ami-0078a0f78fafda978"
}
이제 기존 노드 그룹의 버전을 업그레이드해보기 위해 위와 같이 version을 수정합니다.
terraform apply --auto-approve
terraform apply를 통해 수정된 내용을 배포하도록 하겠습니다.
위와 같이 업데이트 중이라는 것을 알 수 있고, 해당 작업은 20분 정도 소요됩니다.
1.26으로 업그레이드된 것을 확인하실 수 있습니다.
Data Plane 업그레이드 - Blue-Green 방식
managed node group을 업그레이드하기 위해 Blue / Green 전략을 사용할 수도 있습니다. 위의 실습에서 managed node group이 2개가 있었고, Blue-mng managed node group은 업그레이드하지 않았으니 해당 그룹을 Blue-Green으로 업그레이드해보겠습니다.
Blue-Green 방식은 업그레이드 대상 Node Group(Blue)과 동일한 구성(taint, label 등)을 가진 새로운 버전의 Green Node Group을 생성한 후, 기존 Blue Node Group에서 실행 중인 애플리케이션 및 클러스터 리소스를 점진적으로 Green으로 이동시키는 방식입니다. 모든 리소스가 Green으로 이전되면 Blue Node Group을 삭제합니다.
green node group 생성
blue-mng={
instance_types = ["m5.large", "m6a.large", "m6i.large"]
cluster_version = "1.25"
min_size = 1
max_size = 2
desired_size = 1
update_config = {
max_unavailable_percentage = 35
}
labels = {
type = "OrdersMNG"
}
subnet_ids = [module.vpc.private_subnets[0]]
taints = [
{
key = "dedicated"
value = "OrdersApp"
effect = "NO_SCHEDULE"
}
]
}
# blue node group과 같은 green node group 생성
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"
}
]
}
위의 코드대로 blue managed node group과 같은 green managed node group을 추가합니다.
terraform apply -auto-approve
그 후 terraform apply로 배포합니다.
그 후 AWS Console에 접근해 보면 위와 같이 green-mng라는 managed node group이 생성된 것을 확인하실 수 있습니다.
kubectl get node -l type=OrdersMNG -L topology.kubernetes.io/zone
kubectl get nodes -l type=OrdersMNG -o jsonpath="{range .items[*]}{.metadata.name} {.spec.taints[?(@.effect=='NoSchedule')]}{\"\n\"}{end}"
위와 같이 동일한 레이블과 테인트를 가진 두 개의 노드가 있습니다. blue-mng managed node group은 버전 v1.25.16-eks-ae9a62a에 있고 green-mng managed node group은 버전 v1.26.15-eks-ae9a62a에 있습니다.
blue node group 삭제
# blue-mng={
# instance_types = ["m5.large", "m6a.large", "m6i.large"]
# cluster_version = "1.25"
# min_size = 1
# max_size = 2
# desired_size = 1
# update_config = {
# max_unavailable_percentage = 35
# }
# labels = {
# type = "OrdersMNG"
# }
# subnet_ids = [module.vpc.private_subnets[0]]
# taints = [
# {
# key = "dedicated"
# value = "OrdersApp"
# effect = "NO_SCHEDULE"
# }
# ]
# }
위와 같이 주석을 임시로 넣어 blue-mng 리소스를 삭제하겠습니다.
terraform apply -auto-approve
그 후 terraform apply를 진행합니다.
blue-mng가 삭제되었고, pod들도 다시 배포되고 스케줄링되었는지 확인해 보겠습니다.
kubectl get po -o wide -A
Blue-Green 업그레이드 전략으로 1.26 EKS AMI를 가진 새로운 green-mng managed node group을 생성하고 기존 blue-mng 노드 그룹을 삭제하여 blue node group에 배포되어 있던 pod를 새로운 노드 그룹(green-mng)으로 이동시킵니다.
참고
https://kubernetes.io/ko/releases/
릴리스
쿠버네티스 프로젝트는 가장 최신의 3개 마이너(minor) 릴리스(1.32, 1.31, 1.30)에 대해서 릴리스 브랜치를 관리한다. 쿠버네티스 1.19 및 이후 신규 버전은 약 1년간 패치 지원을 받을 수 있다. 쿠버네
kubernetes.io
https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html
Best Practices for Cluster Upgrades - Amazon EKS
Best Practices for Cluster Upgrades This guide shows cluster administrators how to plan and execute their Amazon EKS upgrade strategy. It also describes how to upgrade self-managed nodes, managed node groups, Karpenter nodes, and Fargate nodes. It does not
docs.aws.amazon.com
https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/blue-green-upgrade/
Blue/Green Upgrade - Amazon EKS Blueprints for Terraform
Blue/Green Migration This directory provides a solution based on EKS Blueprint for Terraform that shows how to leverage blue/green or canary application workload migration between EKS clusters, using Amazon Route 53 weighted routing feature. The workloads
aws-ia.github.io
'스터디 이야기 > 25' AWS EKS' 카테고리의 다른 글
| ArgoCD Image Updater로 이미지 자동으로 감지하여 배포하기 (0) | 2025.03.28 |
|---|---|
| AWS EKS의 AutoMode (0) | 2025.03.21 |
| EKS에서 ConfigMap 없이 API로 접근 관리하기(Cluster Access Management) (2) | 2025.03.14 |
| KWOK를 활용한 Kubernetes AutoScaling 테스트 환경 구축 (1) | 2025.03.08 |
