ksc0204 님의 블로그

AEWS 4기 7주차(2) - EKS Upgrade(Workshop 실습) 본문

AWS 4기

AEWS 4기 7주차(2) - EKS Upgrade(Workshop 실습)

ksc0204 2026. 5. 1. 10:32
본 글은 공식 문서 및 서종호(가시다)님의 AWS EKS 워크샵 내용을 기반으로 참고하여 학습 목적으로 작성하였습니다.
주관적인 해석이 포함되어 있어 사실과 다르거나 오류가 있을 수 있으니 참고용으로만 읽어주시기 바랍니다.
본 글은 Amazon EKS Upgrades: Strategies and Best Practices에 대한 AWS Workshop 실습을 통해 작성한 내용입니다.

실습 환경 확인

ec2 확인

Cluster 노드

 

LB

 

EKS

EKS version 1.30

EKS - node

 

EKS - Addon

자격 증명 확인
S3 - Terraform state 상태 보관 버킷
ec2-user ~/.bashrc 환경 변수 및 alias 설정 확인

 

# EKS 클러스터 정보 확인
aws eks describe-cluster --name $EKS_CLUSTER_NAME | jq

Endpoint 및 Role 확인
endpointPublicAccess, endpointPrivateAccess : true 확인(하이브리드 네트워킹)

 

노드 정리

노드 유형
(Node Type)		 식별된 노드
(Node Name)		 인스턴스 / 컴퓨팅 타입 프로비저닝 방식 주요 특징 및 식별 근거 (Labels)
AWS Fargate(서버리스) fargate-ip-10-0-44-226 인스턴스 타입 없음(Minimal OS) 서버리스
(파드 단위 할당)		 NodeGroup / NodePool 라벨 없음
CAPACITYTYPE: fargate
EKS Managed Node Group(관리형 노드) ip-10-0-0-14
ip-10-0-30-53
ip-10-0-34-26		 m5.large 온디맨드 NODEGROUP 라벨 존재(blue-mng, initial)
CAPACITYTYPE: ON_DEMAND
Karpenter Node(동적 프로비저닝) ip-10-0-18-252... c5.large 스팟(Spot) NODEPOOL: default
CAPACITY-TYPE: spot
LIFECYCLE: spot
Self-Managed Node(자체 관리형) ip-10-0-3-181
ip-10-0-31-155		 m5.large 온디맨드 NodeGroup / NodePool 라벨 없음 (<none>)
CAPACITYTYPE: self-managed
Self-Managed Node - EKS가 인프라의 수명 주기를 통제하지 않고, 사용자가 직접 EC2 인스턴스를 생성하여 EKS 클러스터에 수동으로 연결(Join)한 워커 노드입니다.

 

argo-cd, efs-csi driver, lb-contorller-karpenter-metrics-server Chart 확인
argoCD 상태 확인
Pod Disruption Budget 확인

Pod Disruption Budget? PDB를 설정하면 관리자가 노드 업그레이드를 위해서 노드를 다운 시키거나 또는 오토스케일러에 의해서 노드가 다운될 경우 Pod 수를 일정 수 유지하는 서비스

Taint 정보 확인

더보기

# fargate 라벨 정보

{

  "name": "fargate-ip-10-0-44-226.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/os": "linux",

    "eks.amazonaws.com/compute-type": "fargate",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2c",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "fargate-ip-10-0-44-226.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "topology.k8s.aws/zone-id": "usw2-az3",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2c"

  }

}

 

# 관리형 노드 그룹

{

  "name": "ip-10-0-0-14.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "m5.large",

    "beta.kubernetes.io/os": "linux",

    "eks.amazonaws.com/capacityType": "ON_DEMAND",

    "eks.amazonaws.com/nodegroup": "blue-mng-2026042908313851250000002b",

    "eks.amazonaws.com/nodegroup-image": "ami-0c42b1f4678fc81d1",

    "eks.amazonaws.com/sourceLaunchTemplateId": "lt-09496ccb2faea0352",

    "eks.amazonaws.com/sourceLaunchTemplateVersion": "1",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2a",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-0-14.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "m5.large",

    "topology.ebs.csi.aws.com/zone": "us-west-2a",

    "topology.k8s.aws/zone-id": "usw2-az2",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2a",

    "type": "OrdersMNG"

  }

}

 

{

  "name": "ip-10-0-30-53.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "m5.large",

    "beta.kubernetes.io/os": "linux",

    "eks.amazonaws.com/capacityType": "ON_DEMAND",

    "eks.amazonaws.com/nodegroup": "initial-20260429083138508000000029",

    "eks.amazonaws.com/nodegroup-image": "ami-0c42b1f4678fc81d1",

    "eks.amazonaws.com/sourceLaunchTemplateId": "lt-084b546bed4093306",

    "eks.amazonaws.com/sourceLaunchTemplateVersion": "1",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2b",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-30-53.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "m5.large",

    "topology.ebs.csi.aws.com/zone": "us-west-2b",

    "topology.k8s.aws/zone-id": "usw2-az1",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2b"

  }

}

 

{

  "name": "ip-10-0-34-26.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "m5.large",

    "beta.kubernetes.io/os": "linux",

    "eks.amazonaws.com/capacityType": "ON_DEMAND",

    "eks.amazonaws.com/nodegroup": "initial-20260429083138508000000029",

    "eks.amazonaws.com/nodegroup-image": "ami-0c42b1f4678fc81d1",

    "eks.amazonaws.com/sourceLaunchTemplateId": "lt-084b546bed4093306",

    "eks.amazonaws.com/sourceLaunchTemplateVersion": "1",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2c",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-34-26.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "m5.large",

    "topology.ebs.csi.aws.com/zone": "us-west-2c",

    "topology.k8s.aws/zone-id": "usw2-az3",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2c"

  }

}

 

# karpenter 라벨 확인

{

  "name": "ip-10-0-18-252.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "c5.large",

    "beta.kubernetes.io/os": "linux",

    "env": "dev",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2b",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "karpenter.k8s.aws/instance-category": "c",

    "karpenter.k8s.aws/instance-cpu": "2",

    "karpenter.k8s.aws/instance-cpu-manufacturer": "intel",

    "karpenter.k8s.aws/instance-ebs-bandwidth": "4750",

    "karpenter.k8s.aws/instance-encryption-in-transit-supported": "false",

    "karpenter.k8s.aws/instance-family": "c5",

    "karpenter.k8s.aws/instance-generation": "5",

    "karpenter.k8s.aws/instance-hypervisor": "nitro",

    "karpenter.k8s.aws/instance-memory": "4096",

    "karpenter.k8s.aws/instance-network-bandwidth": "750",

    "karpenter.k8s.aws/instance-size": "large",

    "karpenter.sh/capacity-type": "spot",

    "karpenter.sh/initialized": "true",

    "karpenter.sh/nodepool": "default",

    "karpenter.sh/registered": "true",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-18-252.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "c5.large",

    "team": "checkout",

    "topology.ebs.csi.aws.com/zone": "us-west-2b",

    "topology.k8s.aws/zone-id": "usw2-az1",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2b"

  }

}

 

# self-managed

{

  "name": "ip-10-0-3-181.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "m5.large",

    "beta.kubernetes.io/os": "linux",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2a",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-3-181.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "m5.large",

    "node.kubernetes.io/lifecycle": "self-managed",

    "team": "carts",

    "topology.ebs.csi.aws.com/zone": "us-west-2a",

    "topology.k8s.aws/zone-id": "usw2-az2",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2a"

  }

}

 

{

  "name": "ip-10-0-31-155.us-west-2.compute.internal",

  "labels": {

    "beta.kubernetes.io/arch": "amd64",

    "beta.kubernetes.io/instance-type": "m5.large",

    "beta.kubernetes.io/os": "linux",

    "failure-domain.beta.kubernetes.io/region": "us-west-2",

    "failure-domain.beta.kubernetes.io/zone": "us-west-2b",

    "k8s.io/cloud-provider-aws": "a94967527effcefb5f5829f529c0a1b9",

    "kubernetes.io/arch": "amd64",

    "kubernetes.io/hostname": "ip-10-0-31-155.us-west-2.compute.internal",

    "kubernetes.io/os": "linux",

    "node.kubernetes.io/instance-type": "m5.large",

    "node.kubernetes.io/lifecycle": "self-managed",

    "team": "carts",

    "topology.ebs.csi.aws.com/zone": "us-west-2b",

    "topology.k8s.aws/zone-id": "usw2-az1",

    "topology.kubernetes.io/region": "us-west-2",

    "topology.kubernetes.io/zone": "us-west-2b"

  }

}

 

각 노드에서 사용되는 IAM 정책 확인
statefulset, StorageClass, efs, pv, pvc 정보 확인
IAM 정책 매핑 확인

 

EKS 업그레이드 - 실습

aws eks list-insights --filter kubernetesVersions=1.31 --cluster-name $CLUSTER_NAME | jq .
EKS 클러스터를 특정 쿠버네티스 버전(v1.30 > v1.31)으로 업그레이드하기 전 사전에 잠재적인 문제나 위험 요소가 없는지 검증을 위한 명령어
더보기

{

  "insights": [

    {

      "id": "fc1f6515-4dd2-432e-9f58-06f250cfe237",

      "name": "EKS add-on version compatibility", # add-on

      "category": "UPGRADE_READINESS",

      "kubernetesVersion": "1.31",

      "lastRefreshTime": "2026-05-01T00:52:50+00:00",

      "lastTransitionTime": "2026-04-29T08:42:46+00:00",

      "description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",

      "insightStatus": {

        "status": "PASSING",

        "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."

      }

    },

    {

      "id": "67935ccf-b719-4185-be9d-a7a2f05c41a9",

      "name": "Kubelet version skew",

      "category": "UPGRADE_READINESS",

      "kubernetesVersion": "1.31",

      "lastRefreshTime": "2026-05-01T00:52:51+00:00",

      "lastTransitionTime": "2026-04-29T08:42:46+00:00",

      "description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",

      "insightStatus": {

        "status": "PASSING",

        "reason": "Node kubelet versions match the cluster control plane version."

      }

    },

    {

      "id": "c40daeb9-d688-492f-913b-6a1d90f7911e",

      "name": "Cluster health issues",

      "category": "UPGRADE_READINESS",

      "kubernetesVersion": "1.31",

      "lastRefreshTime": "2026-05-01T00:52:50+00:00",

      "lastTransitionTime": "2026-04-29T08:42:46+00:00",

      "description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",

      "insightStatus": {

        "status": "PASSING",

        "reason": "No cluster health issues detected."

      }

    },

    {

      "id": "622d966e-45d3-4d0a-b696-2714c30a2582",

      "name": "Amazon Linux 2 compatibility",

      "category": "UPGRADE_READINESS",

      "kubernetesVersion": "1.31",

      "lastRefreshTime": "2026-05-01T00:52:51+00:00",

      "lastTransitionTime": "2026-04-29T08:42:46+00:00",

      "description": "Checks if any nodes in the cluster are running Amazon Linux 2. Support for Amazon Linux 2 on Amazon EKS will end on November 26, 2025. Additionally, Amazon EKS will not release Amazon Linux 2 AMIs for Kubernetes version 1.33 and higher",

      "insightStatus": {

        "status": "PASSING",

        "reason": "No Amazon Linux 2 nodes detected."

      }

    },

    {

      "id": "0fc98173-6cda-43d7-9ad3-6552c70ce100",

      "name": "kube-proxy version skew",

      "category": "UPGRADE_READINESS",

      "kubernetesVersion": "1.31",

      "lastRefreshTime": "2026-05-01T00:52:51+00:00",

      "lastTransitionTime": "2026-04-29T08:42:46+00:00",

      "description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",

      "insightStatus": {

        "status": "PASSING",

        "reason": "kube-proxy versions match the cluster control plane version."

      }

    }

  ]

}

pdb 설정 실습

# eks-gitops-repo 복제
cd ~/environment
git clone codecommit::${REGION}://eks-gitops-repo

tree eks-gitops-repo/apps/orders/

# orders 에 pdb.yaml 파일 작성
cat << EOF > ~/environment/eks-gitops-repo/apps/orders/pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-pdb
  namespace: orders
spec:
  minAvailable: 1
  selector:
    matchLabels: # 아래 항목이 모두 포함된 항목을 확인
      app.kubernetes.io/component: service
      app.kubernetes.io/instance: orders
      app.kubernetes.io/name: orders
EOF

kustomization.yaml에 pdb.yaml 추가

# git 원격 저장소 push
cd ~/environment/eks-gitops-repo/
git add apps/orders/kustomization.yaml
git add apps/orders/pdb.yaml
git commit -m "Add PDB to orders"
git push
# argo cd - orders application 동기화
argocd app sync orders

 

pdb.yaml을 배포한 이후 matchLabels로 등록된 항목들을 확인하여 강제 삭제하여도 해당 노드에 파드가 지워지거나 하지 않는 것을 확인할 수 있습니다.

 

Control Plane 업그레이드(Terraform)

cd ~/environment/terraform
terraform state list

위 코드를 입력 시 terraform 코드가 이미 프로비저닝된 것을 확인할 수 있습니다.

# EKS 1.30 버전 모든 네임스페이스에 컨테이너 이미지 저장
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c > 1.30.txt

terraform variables.tf 파일 수정(1.30 > 1.31)

terraform apply -auto-approve

# 업그레이드 확인
aws eks describe-cluster --name $EKS_CLUSTER_NAME | jq

# 모니터링
while true; do date; aws eks describe-cluster --name eksworkshop-eksctl | egrep 'version|endpoint"|issuer|platformVersion'; echo ; sleep 2; echo; done

변경 확인

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c > 1.31.txt
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c

# 1.30 및 1.31 파드 비교
diff 1.30.txt 1.31.txt # 동일함

# 재생성 파드 확인 ( 없어야 정상 )
kubectl get pod -A

파일 비교 시 다른 내용 없음 확인

 

Add-on 업그레이드

CoreDNS, kube-proxy, VPC CNI에 대한 필수 Add-on과 EBS CSI Driver와 같은 애드온에 대한 업그레이드 진행

 

Amazon EKS는 AWS Managed Addons에 대한 주어진 K8s 버전에 대한 호환되는 애드온 버전을 나열하는 API를 제공

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c

aws eks describe-addon-versions --addon-name coredns --kubernetes-version 1.31 --output table \
    --query "addons[].addonVersions[:10].{Version:addonVersion,DefaultVersion:compatibilities[0].defaultVersion}"
    
    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}"

 

cd ~/environment/terraform/
terraform plan -no-color | tee addon.txt

terraform apply -auto-approve

add-on 업그레이드 전
add-on 업그레이드 후

노드 그룹 업그레이드

워커 노드에 대한 업그레이드 실습 진행

 

MAnaged Node Group 업그레이드

# 사전 작업 1. AMI ID 작성
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 text

AMI ID Terraform variables.tf 파일에 기재

# base.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
    }

오토스케일링 그룹, 노드그룹, 매니지드 노드 그룹 ami 확인
eks-custom 오토스케일링 그룹 생성 및 신규 노드 추가 확인

initial 노드그룹 업그레이드

Managed node group 디폴트 버전 변경 (1.30 > 1.31)

terraform plan -no-color > plan-output.txt

1.30 > 1.31 확인

위 내용에 따라 EKS는 1.31버전으로 업그레이드되지만, custom managed nodegroup은 고정된 AMI가 있기 때문에 해당 그룹에 노드는 업그레이드가 되지 않습니다. 

custom managed nodegroup과 같이 custom AMI로 구성된 관리 노드 그룹이 있을 경우 업그레이드된 Kubernetes 버전에 커스텀 AMI를 제공하여 관리 노드 그룹을 업그레이드

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

EKS 1.31 버전 최적화 AMI 확인
variables.tf - default AMI 변경

terraform apply -auto-approve

배포 전 초기 상태 모니터링
custom, initial 매니지드 노드 그룹 설정 변경 중 확인
전체 노드 중 v1.31 버전으로 업그레이드된 노드 확인

custom 노드 그룹 삭제 및 프로비저닝

# base.tf 파일에서 custom 노드 그룹 관련 내용 지우기
terraform apply -auto-approve

 

Managed Node Group - 블루/그린 업그레이드

[ 사전 작업 ]

- blue-mng 노드그룹 정보 확인

v1.30 OrdersMNG

[ 실습 방법 ]

1. base.tf 파일에 작성된 blue-mng와 유사한 green-mng를 생성(v1.31 버전으로 생성 및 동일 가용 영역에 프로비저닝)

    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 생성 확인
orders pdb min pod 값 확인

이와 같이 blue,green으로 각 노드 그룹으로 노드가 할당된 것을 확인할 수 있습니다.

 

2. green-mng 생성 이후 blue-mng 삭제

# base.tf 파일 내 blue-mng 부분 삭제
    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"
        }
      ]
    }

 

terraform apply -auto-approve 이후 상태 확인

 

Karpenter 노드 그룹 업그레이드

[ 사전 확인 ]

# Karpenter 정보 확인(노드풀, ec2nodeclass)
kubectl describe nodepool
kubectl describe ec2nodeclass

 

Pod 10개 증설

aws ec2 describe-instances --query "Reservations[*].Instances[*].[Tags[?Key=='Name'].Value | [0], ImageId]" --filters "Name=tag:Blueprint,Values=eksworkshop-eksctl" --output table
kubectl get nodes -l team=checkout

kubectl get nodes -l team=checkout -o jsonpath="{range .items[*]}{.metadata.name} {.spec.taints}{\"\n\"}{end}"
kubectl get nodes -l team=checkout -o jsonpath="{range .items[*]}{.metadata.name} {.spec.taints[?(@.effect=='NoSchedule')]}{\"\n\"}{end}"

kubectl get pods -n checkout -o wide

kubectl get nodeclaim
kubectl get nodes -l team=checkout -o jsonpath="{range .items[*]}{.metadata.name} {.spec.taints}{\"\n\"}{end}"
kubectl get pods -n checkout -o wide

 

# ~/environment/eks-gitops-repo/apps/checkout/deployment.yaml 수정
replicas: 1 # 1 > 10 변경
# 모니터링
watch -d "kubectl get nodeclaim; echo ; kubectl get nodes -l team=checkout; echo ; kubectl get nodes -l team=checkout -o jsonpath="{range .items[*]}{.metadata.name} {.spec.taints}{\"\n\"}{end}"; echo ; kubectl get pods -n checkout -o wide"

# 변경이 완료되면 저장소에 변경 사항을 커밋하고 푸시한 후 Argo-cd가 변경 사항을 동기화할 때까지 기다립니다.
cd ~/environment/eks-gitops-repo
git add apps/checkout/deployment.yaml
git commit -m "scale checkout app"
git push --set-upstream origin main

# You can force the sync using ArgoCD console or following command:
argocd app sync checkout

# LIVE(k8s)에 직접 scale 실행
kubectl scale deploy checkout -n checkout --replicas 10

 

현재 ec2nodeclass ami 버전과 v1.31 버전 ami 확인
파드 신규 노드로 프로비저닝 확인

 

Self Node 업그레이드

# self node 및 carts 파드 확인
kubectl get nodes --show-labels | grep self-managed
kubectl get pods -n carts -o wide

1.31 버전에 대한 최적화 AMI 확인

 

base.tf 내용 수정

# 1.31 버전 Amazon-Linux-2023 AMI 확인
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

# 모니터링
while true; do kubectl get nodes -l node.kubernetes.io/lifecycle=self-managed; echo ; aws ec2 describe-instances --query "Reservations[*].Instances[*].[Tags[?Key=='Name'].Value | [0], ImageId]" --filters "Name=tag:Name,Values=default-selfmng" --output table; echo ; date; sleep 1; echo; done

# self-managed 노드 프로비저닝(업그레이드)
cd ~/environment/terraform/
terraform apply -auto-approve

변경 모니터링 확인
변경 중 확인

신규 버전 EC2 1대가 Ready되고 나서 5분 Refresh 시간 이후에 기존 버전 EC2 1대를 종료 실행하면서, 동시에 추가 신규 버전 EC2 1대 생성

kubectl get nodes -l node.kubernetes.io/lifecycle=self-managed
aws ec2 describe-instances --query "Reservations[*].Instances[*].[Tags[?Key=='Name'].Value | [0], ImageId]" --filters "Name=tag:Name,Values=default-selfmng" --output table

 

 

Fargate 업그레이드

  • Fargate를 사용하면 컨테이너를 실행하기 위해 가상 머신 그룹을 직접 프로비저닝, 구성 또는 확장할 필요가 없습니다. 또한 서버 유형을 선택하거나 노드 그룹을 확장할 시기를 결정하거나 클러스터 패킹을 최적화할 필요도 없습니다.
  • Fargate에서 실행되는 기준을 충족하는 Pod를 시작하면 클러스터에서 실행 중인 Fargate 컨트롤러가 Pod를 Fargate로 인식, 업데이트 및 예약합니다.
  • AWS Fargate 노드를 업그레이드하려면 K8s 배포를 다시 시작하여 새로운 포드가 최신 Kubernetes 버전에서 자동으로 예약되도록 할 수 있습니다.

assets 파드 정보 및 노드 정보 확인

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

kubectl wait --for=condition=Ready pods --all -n assets --timeout=180s

# Once the new pods reach ready state, check the version of the new fargate node.
kubectl get pods -n assets -o wide

kubectl get node $(kubectl get pods -n assets -o jsonpath='{.items[0].spec.nodeName}') -o wide

 

전체 워커 노드 업그레이드 확인

'AWS 4기' 카테고리의 다른 글

AEWS 4기 9주차(2) - Inference on Amazon EKS(실습)  (0) 2026.05.22
AEWS 4기 7주차(1) - EKS Upgrade  (0) 2026.05.01
AEWS 4기 6주차(3) - EKS CI/CD(SaaS Tier 전략, ArgoCD Worflow)  (0) 2026.04.23
AEWS 4기 6주차(2) - EKS CI/CD(Flux CD + Helm Chart)  (0) 2026.04.23
AEWS 4기 6주차(1) - EKS CI/CD(flux cd, tofu-controller)  (0) 2026.04.22
'AWS 4기' Related Articles more