블로그 불러오는 중...
문의 보내기
남겨주면 블로그 주인에게 바로 전달돼요.
오늘은 AWS Solutions Architect 김성한 님께서 실습을 진행해 주셨다.
가시다님께서 과거에 온프레미스 Kubernetes 업그레이드 세션을 진행해 주셨고, EKS 는 실제로 써보지 않았기 때문에 어떤식으로 진행되는지 이번 실습을 진행하면서 알아보고자 한다.
빈도 및 규모 쿠버네티스는 4개월 마다 릴리즈 되며 연간 3회 릴리즈가 된다고 한다.
버전 차이 업그레이드에 따라 사용되지 않는 API 등 여러가지 변경사항이 있다.
호환성 컴포넌트 및 어플리케이션에서의 종속성(매니지드 플러그인, 컴포넌트) 등을 생각해야 한다.
정책 업그레이드 될 때마다 변경되는
다운타임 애플리케이션 다운타임 등을 고려해야 한다.
클라우드의 경우 공동 책임 모델이 있다. 공동 책임 모델이라는 것은 AWS 가 책임지는 부분도 있지만, 유저가 보안 등 고객이 관리해야 하는 부분이 있다.
EKS 같은 경우는 컨트롤 플레인은 Amazon 이 관리하지만 워커 노드들은 유저가 관리해야 한다.
이러한 영역에 따라 워커노드는 업그레이드를 진행하면서 관리해야 한다.
쿠버네티스의 경우 14개월은 적극적으로 지원하나 이 시간이 지나가게 되면 보안 취약점 등 이러한 문제들이 있기 때문에 업그레이드를 해야 한다.
기술부채가 누적된다. 사용되지 않는 API 를 사용한다던지, 신규 API 를 사용하지 못한다던지의 단점이 존재한다.
표준 지원 EKS 의 경우 14개월 동안 표준 지원을 받게 된다.
연장 지원 EKS 의 경우에도 최대 26개월까지 지원 한다. 추가로 Extended 지원의 경우 추가 비용이 나가게 된다.

업그레이드 프로세스 다음과 같이 4단계 과정으로 진행되며, 워크샵에서 다음과 같은 순서로 진행 할 예정이다.
서브넷 내의 5개의 여유 IP 가 있는지 확인해야 한다.
릴리즈 노트 검토
사전 요구사항 검토
초기 Security Policy, Group 등 Cluster 서브넷이 유지 되는지 확인.
컨트롤 플레인은 현재버전보다 1버전만 높일 수 있다.

Karpenter 로 업그레이드 시에는 Drift 를 이용해서 업그레이드를 권장한다고 한다.
관리형의 경우 eksctl, console 을 이용해서 하면 된다.
애플리케이션 개발자와 함께 확인. 추가로 Upgrade Insight 를 이용해서 업그레이드 전에 확인 해 보자
AWS Workshop 을 제공해 주셔서 해당 환경에서 진행했다.
https://catalog.workshops.aws/eks-upgrades/en-US 해당 링크의 워크샵을 따라 해 보았다.
컨트롤 플레인 업그레이드의 경우 여러가지 방법이 있는데, 테라폼으로 업그레이드를 진행하였다.
cd ~/environment/terraform
terraform init
terraform plan
terraform apply -auto-approve접근하여 테라폼으로 기본 init 과 실행을 해 준다.
콘솔에서 확인 해 봤을때 쿠버네티스 버전은 1.30이다.
그 이후에 버전 업그레이드를 위해 테라폼 파일을 수정한다.

다음 버전을 수정하고 진행한다.
terraform plan && terraform apply -auto-approve
plan 시 변경되는 사항이 엄청 많다. 해당 부분을 위 명령어를 통해 적용 해 본다.

업그레이드가 된 것을 볼 수 있다. 아래와 같이 업그레이드 인사이트도 볼 수 있다.

세가지 Addon 을 업그레이드 해 본다. CoreDNS ( You can check the compatibility here ) kube-proxy ( You can check the compatibility here ) VPC CNI (You can check the compatibility here )
aws eks describe-addon-versions --addon-name coredns --kubernetes-version 1.31 --output table \ --query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}" 명령어를 통해, 버전에 따라 지원하는 add-on 목록을 뽑아 본다.
aws eks describe-addon-versions --addon-name kube-proxy --kubernetes-version 1.31 --output table \ --query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}"

위와 같이 coredns, kube-proxy 의 버전을 확인하고 아래처럼 테라폼을 변경한다.
먼저 다음과 같이 before 화면을 볼 수 있다.

업그레이드가 끝나면 다음과 같이 변경이 된다.

현재 테라폼은 다음과 같이 세팅이 되어 있다.
eks_managed_node_group_defaults = {
cluster_version = var.mng_cluster_version
}
eks_managed_node_groups = {
initial = {
instance_types = ["m5.large", "m6a.large", "m6i.large"]
min_size = 2
max_size = 10
desired_size = 2
update_config = {
max_unavailable_percentage = 35
}
}
blue-mng={
instance_types = ["m5.large", "m6a.large", "m6i.large"]
cluster_version = "1.30"
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"
}
]
}
}아래 명령어를 통해, 쿠버네티스의 기본 ami 를 조회해서 가져가게 된다.
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.30/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region $AWS_REGION --query "Parameter.Value" --output textami-06441265f3c3cef0a 가 출력되었고, 해당 값을 variables.tf 에 입력해 주었다.
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)
ami_type = "AL2023_x86_64_STANDARD"
enable_bootstrap_user_data = true
}를 base.tf 에 추가한다.
아래 사진을 참고해서 적용한다.

terraform plan && terraform apply -auto-approve 로 실행해서 노드를 추가한다.

다음과 같이 해당 내용이 추가 되어 있는 것을 확인할 수 있다.

위와 같이 버전을 변경해 준다. 아래서 추가 한 ami 의 경우에도 1.31 버전으로 업그레이드 해야하기 때문에
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \ --region $AWS_REGION --query "Parameter.Value" --output text 명령어로 ami 를 다운 받는다.

다 수정 해 주고 다시 적용 한다.
terraform plan && terraform apply -auto-approve다음과 같이 매니지드 노드가 업그레이드 된 것을 볼 수 있다.
