EKS 업그레이드 퀴즈

이 퀴즈는 Amazon EKS 클러스터 업그레이드 프로세스, 모범 사례, 문제 해결 및 관련 고려 사항에 대한 이해를 테스트합니다.

퀴즈 개요

• EKS 클러스터 업그레이드 계획

• 컨트롤 플레인 업그레이드

• 노드 그룹 업그레이드

• 애드온 및 구성 요소 업그레이드

• 업그레이드 테스트 및 검증

• 업그레이드 문제 해결

객관식 문제

1. Amazon EKS 클러스터 업그레이드를 계획할 때 가장 중요한 첫 번째 단계는 무엇인가요?

A. 즉시 컨트롤 플레인 업그레이드 수행 B. 모든 워크로드를 한 번에 업그레이드 C. 업그레이드 호환성 검토 및 테스트 계획 수립 D. 모든 노드 그룹 동시 업그레이드

정답 및 설명

정답: C. 업그레이드 호환성 검토 및 테스트 계획 수립

설명: Amazon EKS 클러스터 업그레이드를 계획할 때 가장 중요한 첫 번째 단계는 업그레이드 호환성을 검토하고 테스트 계획을 수립하는 것입니다. 이 단계는 업그레이드 과정에서 발생할 수 있는 문제를 미리 식별하고, 워크로드 중단을 최소화하며, 성공적인 업그레이드를 위한 기반을 마련합니다.

업그레이드 호환성 검토 및 테스트 계획의 주요 구성 요소:

1. 버전 호환성 검토:

   • Kubernetes 버전 간 API 변경 사항 확인

   • 사용 중인 API 버전 및 기능의 지원 여부 검토

   • 더 이상 사용되지 않거나 제거된 API 식별

2. 워크로드 호환성 평가:

   • 애플리케이션 매니페스트의 API 버전 검토

   • 사용 중인 컨트롤러 및 운영자 호환성 확인

   • 커스텀 리소스 정의(CRD) 및 웹훅 호환성 검토

3. 애드온 및 도구 호환성 확인:

   • CNI, CoreDNS, kube-proxy 버전 호환성

   • 인그레스 컨트롤러, 서비스 메시 등의 호환성

   • 모니터링, 로깅, 백업 도구 호환성

4. 테스트 계획 수립:

   • 비프로덕션 환경에서의 업그레이드 테스트

   • 주요 워크로드 기능 테스트 계획

   • 롤백 절차 및 기준 정의

구현 방법:

1. 업그레이드 경로 및 호환성 검토:

   # 현재 EKS 클러스터 버전 확인
   aws eks describe-cluster --name my-cluster --query "cluster.version"
   
   # 사용 가능한 EKS 버전 확인
   aws eks describe-addon-versions --kubernetes-version 1.28
   
   # 더 이상 사용되지 않는 API 확인
   kubectl get --raw /metrics | grep "deprecated_api_requests_total"
   
   # 사용 중인 API 버전 검토
   kubectl get deployment,statefulset,daemonset,cronjob,job -A -o json | jq '.items[].apiVersion' | sort | uniq

2. 워크로드 호환성 검사 도구 사용:

   # pluto를 사용하여 더 이상 사용되지 않는 API 버전 검사
   pluto detect-helm --output wide
   pluto detect-kubectl --output wide
   
   # kube-no-trouble 사용
   kubectl-no-trouble

3. 테스트 클러스터 생성 및 업그레이드 테스트:

   # 테스트 클러스터 생성
   eksctl create cluster \
     --name test-upgrade \
     --version 1.27 \
     --region us-west-2 \
     --nodegroup-name standard-workers \
     --node-type m5.large \
     --nodes 2
   
   # 테스트 클러스터 업그레이드
   eksctl upgrade cluster \
     --name test-upgrade \
     --version 1.28 \
     --approve

4. 업그레이드 계획 문서 작성:

   # EKS 클러스터 업그레이드 계획
   
   ## 현재 상태
   - 클러스터 버전: 1.27
   - 노드 그룹: 3개 (시스템: 1.27, 앱: 1.27, 배치: 1.27)
   - 주요 애드온: AWS VPC CNI 1.12.0, CoreDNS 1.8.7, kube-proxy 1.27.1
   
   ## 대상 상태
   - 클러스터 버전: 1.28
   - 노드 그룹: 3개 (시스템: 1.28, 앱: 1.28, 배치: 1.28)
   - 주요 애드온: AWS VPC CNI 1.13.0, CoreDNS 1.9.3, kube-proxy 1.28.1
   
   ## 호환성 검토 결과
   - 더 이상 사용되지 않는 API: batch/v1beta1 CronJob -> batch/v1 CronJob
   - 애드온 호환성: 모두 호환됨
   - 커스텀 리소스: 업데이트 필요 없음
   
   ## 업그레이드 단계
   1. 비프로덕션 환경 업그레이드 및 테스트
   2. 컨트롤 플레인 업그레이드
   3. 애드온 업그레이드
   4. 노드 그룹 순차적 업그레이드
   5. 검증 및 모니터링
   
   ## 롤백 계획
   - 롤백 기준: 중요 워크로드 장애 발생 시
   - 롤백 절차: 새 노드 그룹 생성 (이전 버전), 워크로드 마이그레이션

업그레이드 호환성 검토 주요 영역:

1. API 변경 사항:

   • Kubernetes 1.22: 많은 베타 API가 제거됨

   • Kubernetes 1.25: PodSecurityPolicy 제거

   • Kubernetes 1.26: HorizontalPodAutoscaler v2beta2 제거

   • Kubernetes 1.27: FlowSchema 및 PriorityLevelConfiguration API 변경

   • Kubernetes 1.28: 일부 베타 API 제거 및 변경

2. 노드 구성 요소 호환성:

   • kubelet 버전은 컨트롤 플레인보다 최대 2개 마이너 버전 이전까지 지원

   • kube-proxy는 컨트롤 플레인과 동일한 버전으로 유지 권장

   • 컨테이너 런타임 호환성 확인

3. 애드온 호환성:

   • CNI 플러그인 버전 호환성

   • CoreDNS 버전 호환성

   • 인그레스 컨트롤러, 서비스 메시 등의 호환성

테스트 계획 수립 모범 사례:

1. 단계적 테스트 접근 방식:

   • 개발 환경 먼저 업그레이드

   • 스테이징 환경에서 전체 테스트 수행

   • 프로덕션 환경 업그레이드 전 최종 검증

2. 주요 워크로드 기능 테스트:

   • 핵심 비즈니스 기능 테스트

   • 성능 및 확장성 테스트

   • 장애 복구 테스트

3. 모니터링 및 알림 강화:

   • 업그레이드 중 추가 모니터링 구성

   • 주요 메트릭 및 로그 모니터링

   • 신속한 대응을 위한 알림 설정

4. 롤백 절차 정의:

   • 명확한 롤백 기준 설정

   • 롤백 절차 문서화 및 테스트

   • 데이터 일관성 보장 방안 마련

실제 구현 예시:

1. 업그레이드 호환성 검토 스크립트:

   #!/bin/bash
   # EKS 클러스터 업그레이드 호환성 검토 스크립트
   
   CLUSTER_NAME="my-cluster"
   TARGET_VERSION="1.28"
   
   echo "=== EKS 클러스터 업그레이드 호환성 검토 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "대상 버전: $TARGET_VERSION"
   echo
   
   # 현재 클러스터 버전 확인
   CURRENT_VERSION=$(aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.version" --output text)
   echo "현재 클러스터 버전: $CURRENT_VERSION"
   
   # 애드온 버전 확인
   echo
   echo "=== 현재 애드온 버전 ==="
   aws eks describe-addon --cluster-name $CLUSTER_NAME --addon-name vpc-cni --query "addon.addonVersion" --output text
   aws eks describe-addon --cluster-name $CLUSTER_NAME --addon-name coredns --query "addon.addonVersion" --output text
   aws eks describe-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy --query "addon.addonVersion" --output text
   
   echo
   echo "=== 대상 버전에서 사용 가능한 애드온 버전 ==="
   aws eks describe-addon-versions --kubernetes-version $TARGET_VERSION --query "addons[?addonName=='vpc-cni'].addonVersions[].addonVersion" --output text
   aws eks describe-addon-versions --kubernetes-version $TARGET_VERSION --query "addons[?addonName=='coredns'].addonVersions[].addonVersion" --output text
   aws eks describe-addon-versions --kubernetes-version $TARGET_VERSION --query "addons[?addonName=='kube-proxy'].addonVersions[].addonVersion" --output text
   
   # 더 이상 사용되지 않는 API 확인
   echo
   echo "=== 더 이상 사용되지 않는 API 사용 현황 ==="
   kubectl get --raw /metrics | grep "deprecated_api_requests_total" || echo "더 이상 사용되지 않는 API 요청이 없습니다."
   
   # 사용 중인 API 버전 검토
   echo
   echo "=== 사용 중인 API 버전 ==="
   kubectl get deployment,statefulset,daemonset,cronjob,job -A -o json | jq '.items[].apiVersion' | sort | uniq
   
   echo
   echo "=== 업그레이드 호환성 검토 완료 ==="

2. 업그레이드 테스트 계획 템플릿:

   # EKS 클러스터 업그레이드 테스트 계획
   
   ## 테스트 환경
   - 클러스터 이름: test-upgrade
   - 현재 버전: 1.27
   - 대상 버전: 1.28
   
   ## 테스트 범위
   
   ### 인프라 테스트
   - [ ] 컨트롤 플레인 업그레이드 성공
   - [ ] 노드 그룹 업그레이드 성공
   - [ ] 애드온 업그레이드 성공
   - [ ] 클러스터 상태 확인
   
   ### 워크로드 테스트
   - [ ] 배포 생성 및 확장
   - [ ] 스테이트풀셋 기능
   - [ ] 인그레스 및 서비스 기능
   - [ ] 크론잡 및 잡 실행
   - [ ] 커스텀 리소스 생성 및 관리
   
   ### 성능 테스트
   - [ ] 노드 리소스 사용량
   - [ ] 파드 시작 시간
   - [ ] API 서버 응답 시간
   - [ ] 네트워크 성능
   
   ### 장애 복구 테스트
   - [ ] 노드 장애 시 파드 재스케줄링
   - [ ] 네트워크 중단 시 동작
   - [ ] 리소스 압박 상황에서의 동작
   
   ## 테스트 결과 및 관찰 사항
   
   ## 결론 및 권장 사항

다른 옵션들의 문제점:

• A. 즉시 컨트롤 플레인 업그레이드 수행: 호환성 검토 및 테스트 없이 바로 업그레이드를 수행하면 예상치 못한 문제가 발생할 수 있으며, 워크로드 중단 위험이 높아집니다.

• B. 모든 워크로드를 한 번에 업그레이드: 이는 위험한 접근 방식으로, 문제 발생 시 전체 시스템에 영향을 미칠 수 있습니다. 단계적 접근이 더 안전합니다.

• D. 모든 노드 그룹 동시 업그레이드: 모든 노드를 동시에 업그레이드하면 전체 워크로드가 중단될 위험이 있으며, 문제 발생 시 롤백이 어려워집니다.

### 2. Amazon EKS 클러스터의 컨트롤 플레인을 업그레이드할 때 가장 올바른 접근 방식은 무엇인가요?

A. 노드 그룹을 먼저 업그레이드한 후 컨트롤 플레인 업그레이드 B. 컨트롤 플레인을 업그레이드한 후 노드 그룹 업그레이드 C. 컨트롤 플레인과 노드 그룹을 동시에 업그레이드 D. 업그레이드 없이 새 클러스터를 생성하고 워크로드 마이그레이션

정답 및 설명

정답: B. 컨트롤 플레인을 업그레이드한 후 노드 그룹 업그레이드

설명: Amazon EKS 클러스터의 컨트롤 플레인을 업그레이드할 때 가장 올바른 접근 방식은 컨트롤 플레인을 먼저 업그레이드한 후 노드 그룹을 업그레이드하는 것입니다. 이 접근 방식은 Kubernetes의 버전 호환성 모델을 따르며, 업그레이드 과정에서 발생할 수 있는 문제를 최소화합니다.

컨트롤 플레인 먼저 업그레이드하는 이유:

1. Kubernetes 버전 호환성 모델:

   • 컨트롤 플레인은 노드보다 최대 2개 마이너 버전까지 앞설 수 있음

   • 노드는 컨트롤 플레인보다 앞설 수 없음

   • 이 모델은 하위 호환성을 보장하기 위함

2. API 서버 호환성:

   • 새 버전의 API 서버는 이전 버전의 kubelet과 통신 가능

   • 반대로 새 버전의 kubelet은 이전 버전의 API 서버와 호환성 문제 발생 가능

3. 점진적 업그레이드 가능:

   • 컨트롤 플레인 업그레이드 후 노드 그룹을 점진적으로 업그레이드 가능

   • 문제 발생 시 영향 범위 제한 및 롤백 용이

구현 방법:

1. 컨트롤 플레인 업그레이드:

   # AWS CLI를 사용한 컨트롤 플레인 업그레이드
   aws eks update-cluster-version \
     --name my-cluster \
     --kubernetes-version 1.28
   
   # 업그레이드 상태 확인
   aws eks describe-update \
     --name my-cluster \
     --update-id <update-id>

   # eksctl을 사용한 컨트롤 플레인 업그레이드
   eksctl upgrade cluster \
     --name my-cluster \
     --version 1.28 \
     --approve

2. 컨트롤 플레인 업그레이드 완료 확인:

   # 클러스터 버전 확인
   aws eks describe-cluster \
     --name my-cluster \
     --query "cluster.version" \
     --output text
   
   # 클러스터 상태 확인
   kubectl get componentstatuses
   kubectl get nodes

3. 노드 그룹 업그레이드 준비:

   # 현재 노드 그룹 확인
   aws eks list-nodegroups \
     --cluster-name my-cluster
   
   # 노드 그룹 버전 확인
   aws eks describe-nodegroup \
     --cluster-name my-cluster \
     --nodegroup-name my-nodegroup \
     --query "nodegroup.version" \
     --output text

컨트롤 플레인 업그레이드 프로세스:

1. 업그레이드 전 준비:

   • 클러스터 상태 확인

   • 백업 수행

   • 중요 워크로드 확인

2. 업그레이드 시작:

   • AWS Management Console, AWS CLI 또는 eksctl 사용

   • 업그레이드 진행 상황 모니터링

3. 업그레이드 중 모니터링:

   • 컨트롤 플레인 엔드포인트 가용성

   • 시스템 워크로드 상태

   • 로그 및 이벤트 모니터링

4. 업그레이드 완료 후 검증:

   • 컨트롤 플레인 구성 요소 상태 확인

   • API 서버 기능 테스트

   • 시스템 워크로드 정상 작동 확인

컨트롤 플레인 업그레이드 시 고려 사항:

1. 업그레이드 시간:

   • 일반적으로 20-30분 소요

   • 클러스터 크기 및 복잡성에 따라 다름

   • 유지 관리 기간 중 수행 권장

2. 업그레이드 중 API 서버 가용성:

   • 업그레이드 중 일시적인 API 서버 중단 가능

   • 기존 워크로드는 계속 실행됨

   • 새로운 배포 및 구성 변경은 지연될 수 있음

3. 업그레이드 실패 시 대응:

   • AWS 지원팀에 문의

   • 클러스터 상태 및 로그 수집

   • 대체 계획 실행

모범 사례:

1. 업그레이드 전 클러스터 상태 확인:

   # 클러스터 상태 확인
   kubectl get nodes
   kubectl get pods --all-namespaces
   kubectl get componentstatuses
   
   # 이벤트 확인
   kubectl get events --all-namespaces --sort-by='.lastTimestamp'
   
   # 리소스 사용량 확인
   kubectl top nodes
   kubectl top pods --all-namespaces

2. 업그레이드 전 etcd 백업:

   # etcd 백업 (자체 관리 클러스터의 경우)
   ETCDCTL_API=3 etcdctl snapshot save snapshot.db
   
   # EKS의 경우 주요 리소스 백업
   kubectl get all --all-namespaces -o yaml > all-resources.yaml

3. 점진적 노드 그룹 업그레이드 계획:

   # 노드 그룹 업그레이드 계획
   # 1. 중요도가 낮은 노드 그룹부터 시작
   # 2. 한 번에 하나의 노드 그룹만 업그레이드
   # 3. 각 노드 그룹 업그레이드 후 검증

4. 업그레이드 후 시스템 구성 요소 확인:

   # 시스템 파드 상태 확인
   kubectl get pods -n kube-system
   
   # CoreDNS 상태 확인
   kubectl get pods -n kube-system -l k8s-app=kube-dns
   
   # CNI 플러그인 상태 확인
   kubectl get pods -n kube-system -l k8s-app=aws-node

실제 구현 예시:

1. 컨트롤 플레인 업그레이드 스크립트:

   #!/bin/bash
   # EKS 컨트롤 플레인 업그레이드 스크립트
   
   CLUSTER_NAME="my-cluster"
   TARGET_VERSION="1.28"
   
   echo "=== EKS 클러스터 컨트롤 플레인 업그레이드 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "대상 버전: $TARGET_VERSION"
   echo
   
   # 현재 클러스터 버전 확인
   CURRENT_VERSION=$(aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.version" --output text)
   echo "현재 클러스터 버전: $CURRENT_VERSION"
   
   # 클러스터 상태 확인
   echo
   echo "=== 클러스터 상태 확인 ==="
   kubectl get nodes
   kubectl get pods --all-namespaces | grep -v "Running\|Completed"
   
   # 사용자 확인
   echo
   read -p "클러스터 업그레이드를 시작하시겠습니까? (y/n): " confirm
   if [[ $confirm != "y" ]]; then
     echo "업그레이드가 취소되었습니다."
     exit 1
   fi
   
   # 업그레이드 시작
   echo
   echo "=== 컨트롤 플레인 업그레이드 시작 ==="
   UPDATE_ID=$(aws eks update-cluster-version \
     --name $CLUSTER_NAME \
     --kubernetes-version $TARGET_VERSION \
     --query "update.id" \
     --output text)
   
   echo "업그레이드 ID: $UPDATE_ID"
   
   # 업그레이드 상태 모니터링
   echo
   echo "=== 업그레이드 상태 모니터링 ==="
   
   STATUS="InProgress"
   while [ "$STATUS" == "InProgress" ]; do
     echo "업그레이드 진행 중... $(date)"
     sleep 60
     STATUS=$(aws eks describe-update \
       --name $CLUSTER_NAME \
       --update-id $UPDATE_ID \
       --query "update.status" \
       --output text)
   done
   
   echo
   echo "업그레이드 상태: $STATUS"
   
   if [ "$STATUS" == "Successful" ]; then
     echo
     echo "=== 컨트롤 플레인 업그레이드 완료 ==="
     echo "새 버전: $(aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.version" --output text)"
     
     echo
     echo "=== 클러스터 상태 확인 ==="
     kubectl get nodes
     kubectl get pods -n kube-system
   else
     echo
     echo "=== 업그레이드 실패 ==="
     aws eks describe-update \
       --name $CLUSTER_NAME \
       --update-id $UPDATE_ID
   fi

2. Terraform을 사용한 EKS 클러스터 버전 관리:

   # EKS 클러스터 정의
   resource "aws_eks_cluster" "main" {
     name     = "my-cluster"
     role_arn = aws_iam_role.eks_cluster.arn
     version  = "1.28"  # 대상 버전 지정
     
     vpc_config {
       subnet_ids         = var.subnet_ids
       security_group_ids = [aws_security_group.eks_cluster.id]
     }
     
     # 버전 업그레이드 시 새 버전이 적용될 때까지 대기
     lifecycle {
       ignore_changes = []
     }
     
     depends_on = [
       aws_iam_role_policy_attachment.eks_cluster_policy
     ]
   }

3. 업그레이드 후 검증 스크립트:

   #!/bin/bash
   # EKS 클러스터 업그레이드 후 검증 스크립트
   
   CLUSTER_NAME="my-cluster"
   
   echo "=== EKS 클러스터 업그레이드 검증 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo
   
   # 클러스터 버전 확인
   CLUSTER_VERSION=$(aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.version" --output text)
   echo "클러스터 버전: $CLUSTER_VERSION"
   
   # 컨트롤 플레인 상태 확인
   echo
   echo "=== 컨트롤 플레인 상태 ==="
   kubectl get componentstatuses
   
   # 시스템 파드 상태 확인
   echo
   echo "=== 시스템 파드 상태 ==="
   kubectl get pods -n kube-system
   
   # 노드 상태 확인
   echo
   echo "=== 노드 상태 ==="
   kubectl get nodes
   
   # API 서버 기능 테스트
   echo
   echo "=== API 서버 기능 테스트 ==="
   kubectl create namespace test-upgrade
   kubectl run nginx --image=nginx -n test-upgrade
   kubectl get pods -n test-upgrade
   kubectl delete namespace test-upgrade
   
   echo
   echo "=== 검증 완료 ==="

다른 옵션들의 문제점:

• A. 노드 그룹을 먼저 업그레이드한 후 컨트롤 플레인 업그레이드: 이는 Kubernetes 버전 호환성 모델에 위배되며, 노드의 kubelet 버전이 API 서버 버전보다 앞서게 되어 호환성 문제가 발생할 수 있습니다.

• C. 컨트롤 플레인과 노드 그룹을 동시에 업그레이드: 동시 업그레이드는 위험하며, 문제 발생 시 전체 클러스터에 영향을 미칠 수 있습니다. 또한 점진적인 검증이 어렵습니다.

• D. 업그레이드 없이 새 클러스터를 생성하고 워크로드 마이그레이션: 이 방법은 가능하지만, 리소스 중복, 복잡한 마이그레이션 절차, 추가 비용 등의 문제가 있어 일반적인 업그레이드에는 권장되지 않습니다.

### 3. Amazon EKS 노드 그룹을 업그레이드하는 가장 안전하고 효과적인 방법은 무엇인가요?

A. 모든 노드를 동시에 종료하고 새 버전으로 교체 B. 관리형 노드 그룹 업그레이드 또는 블루/그린 배포 전략 사용 C. 노드 그룹 업그레이드 없이 컨트롤 플레인만 업그레이드 D. 수동으로 각 노드의 kubelet 버전 업그레이드

정답 및 설명

정답: B. 관리형 노드 그룹 업그레이드 또는 블루/그린 배포 전략 사용

설명: Amazon EKS 노드 그룹을 업그레이드하는 가장 안전하고 효과적인 방법은 관리형 노드 그룹 업그레이드 기능을 사용하거나 블루/그린 배포 전략을 구현하는 것입니다. 이러한 접근 방식은 워크로드 중단을 최소화하면서 노드를 안전하게 업그레이드할 수 있게 해줍니다.

관리형 노드 그룹 업그레이드 및 블루/그린 배포의 주요 이점:

1. 관리형 노드 그룹 업그레이드:

   • AWS에서 관리하는 롤링 업그레이드 프로세스

   • 파드 중단 예산(PDB) 존중

   • 자동 드레이닝 및 코드온

   • 업그레이드 실패 시 자동 롤백

2. 블루/그린 배포 전략:

   • 새 버전의 노드 그룹 생성

   • 워크로드 점진적 마이그레이션

   • 검증 후 이전 노드 그룹 제거

   • 문제 발생 시 빠른 롤백 가능

구현 방법:

1. 관리형 노드 그룹 업그레이드:

   # AWS CLI를 사용한 관리형 노드 그룹 업그레이드
   aws eks update-nodegroup-version \
     --cluster-name my-cluster \
     --nodegroup-name my-nodegroup \
     --kubernetes-version 1.28
   
   # 업그레이드 상태 확인
   aws eks describe-update \
     --name my-cluster \
     --nodegroup-name my-nodegroup \
     --update-id <update-id>

   # eksctl을 사용한 관리형 노드 그룹 업그레이드
   eksctl upgrade nodegroup \
     --cluster my-cluster \
     --name my-nodegroup \
     --kubernetes-version 1.28

2. 블루/그린 배포 전략:

   # 새 노드 그룹 생성
   eksctl create nodegroup \
     --cluster my-cluster \
     --name my-nodegroup-v2 \
     --node-type m5.large \
     --nodes 3 \
     --nodes-min 3 \
     --nodes-max 6 \
     --node-labels "kubernetes.io/role=worker,environment=production,version=v2" \
     --node-ami auto \
     --kubernetes-version 1.28
   
   # 워크로드 마이그레이션 (노드 선호도 사용)
   kubectl apply -f - <<EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     replicas: 3
     template:
       spec:
         affinity:
           nodeAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               preference:
                 matchExpressions:
                 - key: version
                   operator: In
                   values:
                   - v2
   EOF
   
   # 이전 노드 그룹 제거
   eksctl delete nodegroup \
     --cluster my-cluster \
     --name my-nodegroup-v1

노드 그룹 업그레이드 프로세스:

1. 관리형 노드 그룹 업그레이드 프로세스:

   • 최대 사용 불가능 노드 수 설정

   • 새 노드 생성 및 클러스터 조인

   • 기존 노드 드레이닝 및 종료

   • 모든 노드가 업그레이드될 때까지 반복

2. 블루/그린 배포 프로세스:

   • 새 버전의 노드 그룹 생성

   • 새 노드 그룹에 테스트 워크로드 배포

   • 점진적으로 워크로드 마이그레이션

   • 모든 워크로드 마이그레이션 후 이전 노드 그룹 제거

노드 그룹 업그레이드 시 고려 사항:

1. 파드 중단 예산(PDB) 구성:

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: app-pdb
   spec:
     minAvailable: 2  # 또는 maxUnavailable: 1
     selector:
       matchLabels:
         app: my-app

2. 노드 선호도 및 반선호도 설정:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     template:
       spec:
         affinity:
           podAntiAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
             - labelSelector:
                 matchExpressions:
                 - key: app
                   operator: In
                   values:
                   - my-app
               topologyKey: "kubernetes.io/hostname"

3. 테인트 및 톨러레이션 활용:

   # 새 노드 그룹에 테인트 적용
   eksctl create nodegroup \
     --cluster my-cluster \
     --name my-nodegroup-v2 \
     --node-labels "version=v2" \
     --taints "upgrade=v2:NoSchedule" \
     --kubernetes-version 1.28
   
   # 특정 워크로드에 톨러레이션 적용
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     template:
       spec:
         tolerations:
         - key: "upgrade"
           operator: "Equal"
           value: "v2"
           effect: "NoSchedule"

모범 사례:

1. 업그레이드 전 준비:

   # 노드 상태 확인
   kubectl get nodes
   
   # 파드 분포 확인
   kubectl get pods -o wide --all-namespaces
   
   # 리소스 사용량 확인
   kubectl top nodes
   kubectl top pods --all-namespaces

2. 점진적 업그레이드:

   • 한 번에 하나의 노드 그룹만 업그레이드

   • 중요도가 낮은 워크로드부터 시작

   • 각 단계 검증 후 진행

3. 업그레이드 중 모니터링 강화:

   • 노드 상태 모니터링

   • 파드 이벤트 모니터링

   • 애플리케이션 성능 및 가용성 모니터링

4. 롤백 계획 수립:

   • 명확한 롤백 기준 정의

   • 롤백 절차 문서화

   • 빠른 롤백을 위한 준비

실제 구현 예시:

1. 관리형 노드 그룹 업그레이드 스크립트:

   #!/bin/bash
   # EKS 관리형 노드 그룹 업그레이드 스크립트
   
   CLUSTER_NAME="my-cluster"
   NODEGROUP_NAME="my-nodegroup"
   TARGET_VERSION="1.28"
   
   echo "=== EKS 관리형 노드 그룹 업그레이드 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "노드 그룹: $NODEGROUP_NAME"
   echo "대상 버전: $TARGET_VERSION"
   echo
   
   # 현재 노드 그룹 버전 확인
   CURRENT_VERSION=$(aws eks describe-nodegroup \
     --cluster-name $CLUSTER_NAME \
     --nodegroup-name $NODEGROUP_NAME \
     --query "nodegroup.version" \
     --output text)
   echo "현재 노드 그룹 버전: $CURRENT_VERSION"
   
   # 노드 상태 확인
   echo
   echo "=== 노드 상태 확인 ==="
   kubectl get nodes -l eks.amazonaws.com/nodegroup=$NODEGROUP_NAME
   
   # 파드 분포 확인
   echo
   echo "=== 파드 분포 확인 ==="
   NODE_NAMES=$(kubectl get nodes -l eks.amazonaws.com/nodegroup=$NODEGROUP_NAME -o jsonpath='{.items[*].metadata.name}')
   for NODE in $NODE_NAMES; do
     echo "노드: $NODE"
     kubectl get pods --all-namespaces -o wide | grep $NODE | wc -l
   done
   
   # 사용자 확인
   echo
   read -p "노드 그룹 업그레이드를 시작하시겠습니까? (y/n): " confirm
   if [[ $confirm != "y" ]]; then
     echo "업그레이드가 취소되었습니다."
     exit 1
   fi
   
   # 업그레이드 시작
   echo
   echo "=== 노드 그룹 업그레이드 시작 ==="
   UPDATE_ID=$(aws eks update-nodegroup-version \
     --cluster-name $CLUSTER_NAME \
     --nodegroup-name $NODEGROUP_NAME \
     --kubernetes-version $TARGET_VERSION \
     --query "update.id" \
     --output text)
   
   echo "업그레이드 ID: $UPDATE_ID"
   
   # 업그레이드 상태 모니터링
   echo
   echo "=== 업그레이드 상태 모니터링 ==="
   
   STATUS="InProgress"
   while [ "$STATUS" == "InProgress" ]; do
     echo "업그레이드 진행 중... $(date)"
     sleep 60
     STATUS=$(aws eks describe-update \
       --name $CLUSTER_NAME \
       --nodegroup-name $NODEGROUP_NAME \
       --update-id $UPDATE_ID \
       --query "update.status" \
       --output text)
   done
   
   echo
   echo "업그레이드 상태: $STATUS"
   
   if [ "$STATUS" == "Successful" ]; then
     echo
     echo "=== 노드 그룹 업그레이드 완료 ==="
     echo "새 버전: $(aws eks describe-nodegroup \
       --cluster-name $CLUSTER_NAME \
       --nodegroup-name $NODEGROUP_NAME \
       --query "nodegroup.version" \
       --output text)"
     
     echo
     echo "=== 노드 상태 확인 ==="
     kubectl get nodes -l eks.amazonaws.com/nodegroup=$NODEGROUP_NAME
   else
     echo
     echo "=== 업그레이드 실패 ==="
     aws eks describe-update \
       --name $CLUSTER_NAME \
       --nodegroup-name $NODEGROUP_NAME \
       --update-id $UPDATE_ID
   fi

2. 블루/그린 배포 스크립트:

   #!/bin/bash
   # EKS 노드 그룹 블루/그린 업그레이드 스크립트
   
   CLUSTER_NAME="my-cluster"
   OLD_NODEGROUP="my-nodegroup-v1"
   NEW_NODEGROUP="my-nodegroup-v2"
   TARGET_VERSION="1.28"
   NODE_TYPE="m5.large"
   NODE_COUNT=3
   
   echo "=== EKS 노드 그룹 블루/그린 업그레이드 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "이전 노드 그룹: $OLD_NODEGROUP"
   echo "새 노드 그룹: $NEW_NODEGROUP"
   echo "대상 버전: $TARGET_VERSION"
   echo
   
   # 현재 노드 그룹 확인
   echo "=== 현재 노드 그룹 확인 ==="
   aws eks list-nodegroups --cluster-name $CLUSTER_NAME
   
   # 새 노드 그룹 생성
   echo
   echo "=== 새 노드 그룹 생성 ==="
   eksctl create nodegroup \
     --cluster $CLUSTER_NAME \
     --name $NEW_NODEGROUP \
     --node-type $NODE_TYPE \
     --nodes $NODE_COUNT \
     --nodes-min $NODE_COUNT \
     --nodes-max $(($NODE_COUNT * 2)) \
     --node-labels "kubernetes.io/role=worker,environment=production,version=v2" \
     --node-ami auto \
     --kubernetes-version $TARGET_VERSION
   
   # 새 노드 그룹 상태 확인
   echo
   echo "=== 새 노드 그룹 상태 확인 ==="
   kubectl get nodes -l eks.amazonaws.com/nodegroup=$NEW_NODEGROUP
   
   # 워크로드 마이그레이션
   echo
   echo "=== 워크로드 마이그레이션 ==="
   echo "1. 노드 선호도를 사용하여 새 노드 그룹으로 워크로드 마이그레이션"
   echo "2. 다음 명령으로 파드 분포 확인:"
   echo "   kubectl get pods -o wide --all-namespaces | grep <node-name>"
   
   # 사용자 확인
   echo
   read -p "모든 워크로드가 새 노드 그룹으로 마이그레이션되었습니까? (y/n): " confirm
   if [[ $confirm != "y" ]]; then
     echo "이전 노드 그룹 삭제가 취소되었습니다. 수동으로 마이그레이션을 완료하세요."
     exit 1
   fi
   
   # 이전 노드 그룹에 코드온 설정
   echo
   echo "=== 이전 노드 그룹에 코드온 설정 ==="
   kubectl cordon -l eks.amazonaws.com/nodegroup=$OLD_NODEGROUP
   
   # 이전 노드 그룹 드레이닝
   echo
   echo "=== 이전 노드 그룹 드레이닝 ==="
   kubectl drain --ignore-daemonsets --delete-emptydir-data -l eks.amazonaws.com/nodegroup=$OLD_NODEGROUP
   
   # 이전 노드 그룹 삭제
   echo
   echo "=== 이전 노드 그룹 삭제 ==="
   eksctl delete nodegroup \
     --cluster $CLUSTER_NAME \
     --name $OLD_NODEGROUP
   
   echo
   echo "=== 블루/그린 업그레이드 완료 ==="
   echo "현재 노드 그룹:"
   aws eks list-nodegroups --cluster-name $CLUSTER_NAME

3. Terraform을 사용한 블루/그린 배포:

   # 현재 활성 노드 그룹 버전 변수
   variable "active_version" {
     description = "현재 활성 노드 그룹 버전 (blue 또는 green)"
     default     = "blue"
   }
   
   # 블루 노드 그룹
   resource "aws_eks_node_group" "blue" {
     cluster_name    = aws_eks_cluster.main.name
     node_group_name = "blue-nodegroup"
     node_role_arn   = aws_iam_role.node_role.arn
     subnet_ids      = var.private_subnet_ids
     
     scaling_config {
       desired_size = var.active_version == "blue" ? var.desired_nodes : 0
       min_size     = var.active_version == "blue" ? var.min_nodes : 0
       max_size     = var.active_version == "blue" ? var.max_nodes : 0
     }
     
     version = "1.27"  # 현재 버전
     
     labels = {
       "environment" = "production"
       "version"     = "blue"
     }
     
     lifecycle {
       ignore_changes = [scaling_config[0].desired_size]
     }
   }
   
   # 그린 노드 그룹 (새 버전)
   resource "aws_eks_node_group" "green" {
     cluster_name    = aws_eks_cluster.main.name
     node_group_name = "green-nodegroup"
     node_role_arn   = aws_iam_role.node_role.arn
     subnet_ids      = var.private_subnet_ids
     
     scaling_config {
       desired_size = var.active_version == "green" ? var.desired_nodes : 0
       min_size     = var.active_version == "green" ? var.min_nodes : 0
       max_size     = var.active_version == "green" ? var.max_nodes : 0
     }
     
     version = "1.28"  # 새 버전
     
     labels = {
       "environment" = "production"
       "version"     = "green"
     }
     
     lifecycle {
       ignore_changes = [scaling_config[0].desired_size]
     }
   }

다른 옵션들의 문제점:

• A. 모든 노드를 동시에 종료하고 새 버전으로 교체: 이 방법은 모든 워크로드가 동시에 중단되어 서비스 가용성에 심각한 영향을 미칩니다.

• C. 노드 그룹 업그레이드 없이 컨트롤 플레인만 업그레이드: 노드 그룹을 업그레이드하지 않으면 새로운 Kubernetes 기능을 완전히 활용할 수 없으며, 버전 차이가 커질수록 호환성 문제가 발생할 수 있습니다.

• D. 수동으로 각 노드의 kubelet 버전 업그레이드: EKS 관리형 노드에서는 이 방법이 권장되지 않으며, 오류 가능성이 높고 일관성을 유지하기 어렵습니다.

### 4. Amazon EKS 클러스터 업그레이드 중 애드온 관리에 대한 가장 올바른 접근 방식은 무엇인가요?

A. 애드온 업그레이드 무시 B. 컨트롤 플레인 업그레이드 전에 모든 애드온 업그레이드 C. 컨트롤 플레인 업그레이드 후 호환되는 애드온 버전으로 업그레이드 D. 모든 애드온 제거 후 재설치

정답 및 설명

정답: C. 컨트롤 플레인 업그레이드 후 호환되는 애드온 버전으로 업그레이드

설명: Amazon EKS 클러스터 업그레이드 중 애드온 관리에 대한 가장 올바른 접근 방식은 컨트롤 플레인 업그레이드 후 호환되는 애드온 버전으로 업그레이드하는 것입니다. 이 접근 방식은 Kubernetes 버전과 애드온 간의 호환성을 보장하고, 업그레이드 과정에서 발생할 수 있는 문제를 최소화합니다.

컨트롤 플레인 업그레이드 후 애드온 업그레이드의 주요 이점:

1. 버전 호환성 보장:

   • 각 Kubernetes 버전에 맞는 호환 애드온 버전 선택 가능

   • 컨트롤 플레인 API와 애드온 간의 호환성 문제 방지

   • 안정적인 업그레이드 경로 제공

2. 단계적 업그레이드 가능:

   • 컨트롤 플레인 업그레이드 검증 후 애드온 업그레이드

   • 문제 발생 시 원인 격리 용이

   • 각 단계별 검증 가능

3. EKS 관리형 애드온 활용:

   • AWS에서 관리하는 애드온 수명 주기

   • 호환성이 검증된 버전 제공

   • 자동 보안 패치 및 업데이트

구현 방법:

1. EKS 관리형 애드온 업그레이드:

   # 사용 가능한 애드온 버전 확인
   aws eks describe-addon-versions \
     --addon-name vpc-cni \
     --kubernetes-version 1.28
   
   # 애드온 업그레이드
   aws eks update-addon \
     --cluster-name my-cluster \
     --addon-name vpc-cni \
     --addon-version v1.13.0-eksbuild.1 \
     --resolve-conflicts PRESERVE

2. 주요 EKS 애드온 업그레이드:

   # VPC CNI 업그레이드
   aws eks update-addon \
     --cluster-name my-cluster \
     --addon-name vpc-cni \
     --addon-version v1.13.0-eksbuild.1
   
   # CoreDNS 업그레이드
   aws eks update-addon \
     --cluster-name my-cluster \
     --addon-name coredns \
     --addon-version v1.9.3-eksbuild.3
   
   # kube-proxy 업그레이드
   aws eks update-addon \
     --cluster-name my-cluster \
     --addon-name kube-proxy \
     --addon-version v1.28.1-eksbuild.1

3. 자체 관리형 애드온 업그레이드:

   # Helm을 사용한 애드온 업그레이드
   helm repo update
   helm upgrade --install metrics-server metrics-server/metrics-server \
     --namespace kube-system \
     --version 3.8.2 \
     --set apiService.create=true

주요 EKS 애드온 및 호환성:

1. Amazon VPC CNI:

   • 네트워크 인터페이스 관리

   • 파드 IP 할당

   • 버전 호환성 중요

2. CoreDNS:

   • 클러스터 내 DNS 서비스

   • 서비스 디스커버리

   • Kubernetes 버전별 권장 버전 존재

3. kube-proxy:

   • 네트워크 프록시

   • 서비스 IP 라우팅

   • 컨트롤 플레인 버전과 일치 권장

4. 기타 일반 애드온:

   • Cluster Autoscaler

   • Metrics Server

   • AWS Load Balancer Controller

   • External DNS

애드온 업그레이드 시 고려 사항:

1. 충돌 해결 전략:

   • OVERWRITE: 기존 설정 덮어쓰기

   • PRESERVE: 기존 사용자 지정 설정 유지

   • NONE: 충돌 시 업그레이드 실패

2. 업그레이드 순서:

   • 중요도 및 의존성에 따른 순서 결정

   • 일반적으로 CNI → CoreDNS → kube-proxy → 기타 애드온

3. 업그레이드 검증:

   • 각 애드온 업그레이드 후 기능 검증

   • 로그 및 이벤트 모니터링

   • 워크로드 영향 확인

모범 사례:

1. 애드온 버전 호환성 확인:

   # 각 Kubernetes 버전에 대한 호환 애드온 버전 확인
   aws eks describe-addon-versions \
     --kubernetes-version 1.28 \
     --query "addons[].{Name:addonName,LatestVersion:addonVersions[0].addonVersion}"

2. 업그레이드 전 애드온 상태 확인:

   # 현재 애드온 상태 확인
   aws eks describe-addon \
     --cluster-name my-cluster \
     --addon-name vpc-cni
   
   # 애드온 파드 상태 확인
   kubectl get pods -n kube-system -l k8s-app=aws-node

3. 단계적 애드온 업그레이드:

   • 한 번에 하나의 애드온만 업그레이드

   • 각 업그레이드 후 검증

   • 문제 발생 시 롤백 준비

4. 사용자 지정 설정 백업:

   # 애드온 구성 백업
   kubectl get configmap aws-node -n kube-system -o yaml > vpc-cni-configmap-backup.yaml

실제 구현 예시:

1. 애드온 업그레이드 스크립트:

   #!/bin/bash
   # EKS 애드온 업그레이드 스크립트
   
   CLUSTER_NAME="my-cluster"
   KUBERNETES_VERSION="1.28"
   
   echo "=== EKS 애드온 업그레이드 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "Kubernetes 버전: $KUBERNETES_VERSION"
   echo
   
   # 현재 애드온 버전 확인
   echo "=== 현재 애드온 버전 ==="
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name vpc-cni \
     --query "addon.addonVersion" \
     --output text
   
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name coredns \
     --query "addon.addonVersion" \
     --output text
   
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name kube-proxy \
     --query "addon.addonVersion" \
     --output text
   
   # 호환되는 애드온 버전 확인
   echo
   echo "=== 호환되는 애드온 버전 ==="
   VPC_CNI_VERSION=$(aws eks describe-addon-versions \
     --addon-name vpc-cni \
     --kubernetes-version $KUBERNETES_VERSION \
     --query "addons[0].addonVersions[0].addonVersion" \
     --output text)
   
   COREDNS_VERSION=$(aws eks describe-addon-versions \
     --addon-name coredns \
     --kubernetes-version $KUBERNETES_VERSION \
     --query "addons[0].addonVersions[0].addonVersion" \
     --output text)
   
   KUBE_PROXY_VERSION=$(aws eks describe-addon-versions \
     --addon-name kube-proxy \
     --kubernetes-version $KUBERNETES_VERSION \
     --query "addons[0].addonVersions[0].addonVersion" \
     --output text)
   
   echo "VPC CNI: $VPC_CNI_VERSION"
   echo "CoreDNS: $COREDNS_VERSION"
   echo "kube-proxy: $KUBE_PROXY_VERSION"
   
   # 사용자 확인
   echo
   read -p "애드온 업그레이드를 시작하시겠습니까? (y/n): " confirm
   if [[ $confirm != "y" ]]; then
     echo "업그레이드가 취소되었습니다."
     exit 1
   fi
   
   # VPC CNI 업그레이드
   echo
   echo "=== VPC CNI 업그레이드 ==="
   aws eks update-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name vpc-cni \
     --addon-version $VPC_CNI_VERSION \
     --resolve-conflicts PRESERVE
   
   # VPC CNI 상태 확인
   echo
   echo "=== VPC CNI 상태 확인 ==="
   sleep 30
   kubectl get pods -n kube-system -l k8s-app=aws-node
   
   # CoreDNS 업그레이드
   echo
   echo "=== CoreDNS 업그레이드 ==="
   aws eks update-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name coredns \
     --addon-version $COREDNS_VERSION \
     --resolve-conflicts PRESERVE
   
   # CoreDNS 상태 확인
   echo
   echo "=== CoreDNS 상태 확인 ==="
   sleep 30
   kubectl get pods -n kube-system -l k8s-app=kube-dns
   
   # kube-proxy 업그레이드
   echo
   echo "=== kube-proxy 업그레이드 ==="
   aws eks update-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name kube-proxy \
     --addon-version $KUBE_PROXY_VERSION \
     --resolve-conflicts PRESERVE
   
   # kube-proxy 상태 확인
   echo
   echo "=== kube-proxy 상태 확인 ==="
   sleep 30
   kubectl get pods -n kube-system -l k8s-app=kube-proxy
   
   echo
   echo "=== 애드온 업그레이드 완료 ==="
   echo "현재 애드온 버전:"
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name vpc-cni \
     --query "addon.addonVersion" \
     --output text
   
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name coredns \
     --query "addon.addonVersion" \
     --output text
   
   aws eks describe-addon \
     --cluster-name $CLUSTER_NAME \
     --addon-name kube-proxy \
     --query "addon.addonVersion" \
     --output text

2. Terraform을 사용한 애드온 관리:

   # EKS 클러스터 정의
   resource "aws_eks_cluster" "main" {
     name     = "my-cluster"
     role_arn = aws_iam_role.eks_cluster.arn
     version  = "1.28"
     
     vpc_config {
       subnet_ids         = var.subnet_ids
       security_group_ids = [aws_security_group.eks_cluster.id]
     }
   }
   
   # VPC CNI 애드온
   resource "aws_eks_addon" "vpc_cni" {
     cluster_name      = aws_eks_cluster.main.name
     addon_name        = "vpc-cni"
     addon_version     = "v1.13.0-eksbuild.1"  # 1.28 호환 버전
     resolve_conflicts = "PRESERVE"
     
     depends_on = [
       aws_eks_cluster.main
     ]
   }
   
   # CoreDNS 애드온
   resource "aws_eks_addon" "coredns" {
     cluster_name      = aws_eks_cluster.main.name
     addon_name        = "coredns"
     addon_version     = "v1.9.3-eksbuild.3"  # 1.28 호환 버전
     resolve_conflicts = "PRESERVE"
     
     depends_on = [
       aws_eks_cluster.main,
       aws_eks_node_group.main
     ]
   }
   
   # kube-proxy 애드온
   resource "aws_eks_addon" "kube_proxy" {
     cluster_name      = aws_eks_cluster.main.name
     addon_name        = "kube-proxy"
     addon_version     = "v1.28.1-eksbuild.1"  # 1.28 호환 버전
     resolve_conflicts = "PRESERVE"
     
     depends_on = [
       aws_eks_cluster.main
     ]
   }

3. 자체 관리형 애드온 업그레이드 스크립트:

   #!/bin/bash
   # 자체 관리형 애드온 업그레이드 스크립트
   
   CLUSTER_NAME="my-cluster"
   KUBERNETES_VERSION="1.28"
   
   echo "=== 자체 관리형 애드온 업그레이드 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "Kubernetes 버전: $KUBERNETES_VERSION"
   echo
   
   # Helm 리포지토리 업데이트
   echo "=== Helm 리포지토리 업데이트 ==="
   helm repo update
   
   # Metrics Server 업그레이드
   echo
   echo "=== Metrics Server 업그레이드 ==="
   helm upgrade --install metrics-server metrics-server/metrics-server \
     --namespace kube-system \
     --version 3.8.2 \
     --set apiService.create=true
   
   # AWS Load Balancer Controller 업그레이드
   echo
   echo "=== AWS Load Balancer Controller 업그레이드 ==="
   helm upgrade --install aws-load-balancer-controller eks/aws-load-balancer-controller \
     --namespace kube-system \
     --set clusterName=$CLUSTER_NAME \
     --set serviceAccount.create=false \
     --set serviceAccount.name=aws-load-balancer-controller
   
   # Cluster Autoscaler 업그레이드
   echo
   echo "=== Cluster Autoscaler 업그레이드 ==="
   helm upgrade --install cluster-autoscaler autoscaler/cluster-autoscaler \
     --namespace kube-system \
     --set autoDiscovery.clusterName=$CLUSTER_NAME \
     --set awsRegion=$(aws configure get region) \
     --set rbac.create=true \
     --set extraArgs.skip-nodes-with-system-pods=false
   
   echo
   echo "=== 자체 관리형 애드온 업그레이드 완료 ==="
   kubectl get pods -n kube-system | grep -E 'metrics-server|aws-load-balancer-controller|cluster-autoscaler'

다른 옵션들의 문제점:

• A. 애드온 업그레이드 무시: 애드온을 업그레이드하지 않으면 Kubernetes 버전과의 호환성 문제가 발생할 수 있으며, 보안 패치나 버그 수정이 적용되지 않습니다.

• B. 컨트롤 플레인 업그레이드 전에 모든 애드온 업그레이드: 컨트롤 플레인 업그레이드 전에 애드온을 업그레이드하면 새 버전의 애드온이 이전 버전의 컨트롤 플레인과 호환되지 않을 수 있습니다.

• D. 모든 애드온 제거 후 재설치: 이 방법은 불필요하게 복잡하고 위험하며, 애드온 구성 및 설정이 손실될 수 있습니다.

### 5. Amazon EKS 클러스터 업그레이드 중 발생할 수 있는 문제를 해결하기 위한 가장 효과적인 접근 방식은 무엇인가요?

A. 즉시 새 클러스터 생성 B. 문제 발생 시 AWS 지원팀에만 의존 C. 체계적인 문제 해결 접근 방식 및 로그 분석 사용 D. 업그레이드 문제 무시

정답 및 설명

정답: C. 체계적인 문제 해결 접근 방식 및 로그 분석 사용

설명: Amazon EKS 클러스터 업그레이드 중 발생할 수 있는 문제를 해결하기 위한 가장 효과적인 접근 방식은 체계적인 문제 해결 접근 방식 및 로그 분석을 사용하는 것입니다. 이 접근 방식은 문제의 근본 원인을 식별하고, 적절한 해결책을 적용하며, 유사한 문제의 재발을 방지하는 데 도움이 됩니다.

체계적인 문제 해결 접근 방식의 주요 구성 요소:

1. 문제 식별 및 정의:

   • 증상 및 영향 범위 파악

   • 문제 발생 시점 및 조건 확인

   • 정상 동작과의 차이점 식별

2. 정보 수집 및 분석:

   • 로그 및 이벤트 수집

   • 리소스 상태 및 구성 확인

   • 오류 메시지 및 패턴 분석

3. 가설 수립 및 검증:

   • 가능한 원인 식별

   • 가설 테스트 및 검증

   • 근본 원인 확인

4. 해결책 구현 및 검증:

   • 적절한 해결책 적용

   • 해결책 효과 검증

   • 문제 재발 방지 조치

구현 방법:

1. 업그레이드 문제 진단:

   # 클러스터 상태 확인
   aws eks describe-cluster \
     --name my-cluster \
     --query "cluster.status"
   
   # 업그레이드 상태 확인
   aws eks describe-update \
     --name my-cluster \
     --update-id <update-id>
   
   # 컨트롤 플레인 로그 확인
   aws eks update-cluster-config \
     --name my-cluster \
     --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
   
   # CloudWatch Logs에서 로그 확인
   aws logs filter-log-events \
     --log-group-name /aws/eks/my-cluster/cluster \
     --filter-pattern "Error"

2. 노드 그룹 문제 진단:

   # 노드 그룹 상태 확인
   aws eks describe-nodegroup \
     --cluster-name my-cluster \
     --nodegroup-name my-nodegroup
   
   # 노드 상태 확인
   kubectl get nodes
   kubectl describe node <node-name>
   
   # 노드 로그 확인
   kubectl logs -n kube-system <node-agent-pod>

3. 애드온 문제 진단:

   # 애드온 상태 확인
   aws eks describe-addon \
     --cluster-name my-cluster \
     --addon-name vpc-cni
   
   # 애드온 파드 상태 확인
   kubectl get pods -n kube-system -l k8s-app=aws-node
   kubectl describe pod -n kube-system <addon-pod-name>
   kubectl logs -n kube-system <addon-pod-name>

일반적인 업그레이드 문제 및 해결 방법:

1. 컨트롤 플레인 업그레이드 실패:

   • 증상: 업그레이드 상태가 "Failed"로 표시됨

   • 원인: API 서버 구성 문제, 리소스 제약, 네트워크 문제

   • 해결 방법:

     • 업그레이드 오류 메시지 확인

     • AWS 지원팀에 문의

     • 클러스터 상태 및 로그 제공

2. 노드 그룹 업그레이드 실패:

   • 증상: 노드가 Ready 상태가 되지 않음, 파드 스케줄링 실패

   • 원인: 인스턴스 시작 문제, kubelet 구성 오류, CNI 문제

   • 해결 방법:

     • 노드 로그 확인

     • 인스턴스 상태 확인

     • 보안 그룹 및 IAM 권한 확인

3. 애드온 업그레이드 문제:

   • 증상: 애드온 파드가 CrashLoopBackOff 또는 Error 상태

   • 원인: 버전 호환성 문제, 구성 충돌, 리소스 제약

   • 해결 방법:

     • 파드 로그 확인

     • 구성 충돌 해결

     • 호환되는 버전으로 다시 시도

4. 워크로드 호환성 문제:

   • 증상: 애플리케이션 파드 시작 실패, API 오류

   • 원인: 더 이상 사용되지 않는 API 사용, 호환되지 않는 기능

   • 해결 방법:

     • 매니페스트 업데이트

     • 애플리케이션 로그 확인

     • 호환성 문제 해결

모범 사례:

1. 문제 해결을 위한 로그 수집:

   # 클러스터 정보 수집
   kubectl cluster-info dump > cluster-info.txt
   
   # 노드 정보 수집
   kubectl describe nodes > nodes-info.txt
   
   # 시스템 파드 로그 수집
   kubectl logs -n kube-system -l k8s-app=aws-node > vpc-cni-logs.txt
   kubectl logs -n kube-system -l k8s-app=kube-dns > coredns-logs.txt
   kubectl logs -n kube-system -l k8s-app=kube-proxy > kube-proxy-logs.txt
   
   # 이벤트 수집
   kubectl get events --all-namespaces --sort-by='.lastTimestamp' > events.txt

2. 롤백 절차 준비:

   # 노드 그룹 롤백 (새 노드 그룹 생성)
   eksctl create nodegroup \
     --cluster my-cluster \
     --name rollback-nodegroup \
     --node-type m5.large \
     --nodes 3 \
     --nodes-min 3 \
     --nodes-max 6 \
     --node-ami auto \
     --kubernetes-version 1.27  # 이전 버전
   
   # 워크로드 마이그레이션
   kubectl cordon -l eks.amazonaws.com/nodegroup=problematic-nodegroup
   kubectl drain --ignore-daemonsets --delete-emptydir-data -l eks.amazonaws.com/nodegroup=problematic-nodegroup

3. 문제 해결 문서화:

   # 업그레이드 문제 해결 보고서
   
   ## 문제 설명
   - 증상: 노드 그룹 업그레이드 후 CoreDNS 파드가 CrashLoopBackOff 상태
   - 영향: 서비스 디스커버리 실패, 애플리케이션 연결 문제
   - 발생 시점: 2023-07-15 14:30 UTC, 노드 그룹 업그레이드 직후
   
   ## 조사 과정
   1. CoreDNS 파드 상태 확인
   2. CoreDNS 로그 분석
   3. 노드 상태 및 리소스 확인
   4. 네트워크 정책 검토
   
   ## 발견 사항
   - CoreDNS 파드 로그에서 구성 오류 발견
   - 업그레이드 중 CoreDNS ConfigMap이 잘못 수정됨
   
   ## 해결 방법
   1. CoreDNS ConfigMap 복원
   2. CoreDNS 파드 재시작
   3. 서비스 연결 확인
   
   ## 예방 조치
   1. 업그레이드 전 중요 구성 백업
   2. 자동화된 검증 테스트 구현
   3. 단계적 업그레이드 프로세스 개선

4. AWS 지원팀과 효과적으로 협력:

   • 명확한 문제 설명 제공

   • 관련 로그 및 오류 메시지 공유

   • 수행한 문제 해결 단계 설명

실제 구현 예시:

1. 업그레이드 문제 해결 스크립트:

   #!/bin/bash
   # EKS 업그레이드 문제 해결 스크립트
   
   CLUSTER_NAME="my-cluster"
   PROBLEM_TYPE=$1  # control-plane, nodegroup, addon
   
   echo "=== EKS 업그레이드 문제 해결 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "문제 유형: $PROBLEM_TYPE"
   echo
   
   # 진단 정보 디렉토리 생성
   TIMESTAMP=$(date +%Y%m%d-%H%M%S)
   DIAG_DIR="eks-diag-$TIMESTAMP"
   mkdir -p $DIAG_DIR
   
   # 클러스터 정보 수집
   echo "=== 클러스터 정보 수집 ==="
   aws eks describe-cluster --name $CLUSTER_NAME > $DIAG_DIR/cluster-info.json
   kubectl cluster-info dump > $DIAG_DIR/cluster-info-dump.txt
   kubectl get nodes -o wide > $DIAG_DIR/nodes.txt
   kubectl get pods --all-namespaces -o wide > $DIAG_DIR/pods.txt
   kubectl get events --all-namespaces --sort-by='.lastTimestamp' > $DIAG_DIR/events.txt
   
   # 문제 유형별 진단
   case $PROBLEM_TYPE in
     control-plane)
       echo "=== 컨트롤 플레인 문제 진단 ==="
       # 업그레이드 상태 확인
       aws eks list-updates --name $CLUSTER_NAME > $DIAG_DIR/updates.json
       
       # 컨트롤 플레인 로그 확인
       echo "컨트롤 플레인 로그를 확인하려면 CloudWatch Logs 콘솔에서 다음 로그 그룹을 확인하세요:"
       echo "/aws/eks/$CLUSTER_NAME/cluster"
       ;;
       
     nodegroup)
       echo "=== 노드 그룹 문제 진단 ==="
       # 노드 그룹 목록 및 상태
       aws eks list-nodegroups --cluster-name $CLUSTER_NAME > $DIAG_DIR/nodegroups.json
       
       # 각 노드 그룹 상세 정보
       for NG in $(aws eks list-nodegroups --cluster-name $CLUSTER_NAME --query 'nodegroups[*]' --output text); do
         aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name $NG > $DIAG_DIR/nodegroup-$NG.json
       done
       
       # 노드 상태 및 정보
       kubectl describe nodes > $DIAG_DIR/nodes-describe.txt
       
       # 노드 관련 파드 로그
       kubectl logs -n kube-system -l k8s-app=aws-node > $DIAG_DIR/vpc-cni-logs.txt
       ;;
       
     addon)
       echo "=== 애드온 문제 진단 ==="
       # 애드온 목록 및 상태
       aws eks list-addons --cluster-name $CLUSTER_NAME > $DIAG_DIR/addons.json
       
       # 각 애드온 상세 정보
       for ADDON in $(aws eks list-addons --cluster-name $CLUSTER_NAME --query 'addons[*]' --output text); do
         aws eks describe-addon --cluster-name $CLUSTER_NAME --addon-name $ADDON > $DIAG_DIR/addon-$ADDON.json
       done
       
       # 주요 애드온 파드 로그
       kubectl logs -n kube-system -l k8s-app=kube-dns > $DIAG_DIR/coredns-logs.txt
       kubectl logs -n kube-system -l k8s-app=kube-proxy > $DIAG_DIR/kube-proxy-logs.txt
       kubectl logs -n kube-system -l k8s-app=aws-node > $DIAG_DIR/vpc-cni-logs.txt
       ;;
       
     *)
       echo "알 수 없는 문제 유형입니다. control-plane, nodegroup, addon 중 하나를 지정하세요."
       exit 1
       ;;
   esac
   
   echo
   echo "=== 진단 정보 수집 완료 ==="
   echo "진단 정보가 $DIAG_DIR 디렉토리에 저장되었습니다."
   echo "이 정보를 사용하여 문제를 분석하거나 AWS 지원팀에 제공하세요."

2. 업그레이드 롤백 스크립트:

   #!/bin/bash
   # EKS 업그레이드 롤백 스크립트
   
   CLUSTER_NAME="my-cluster"
   PREVIOUS_VERSION="1.27"
   PROBLEMATIC_NODEGROUP="my-nodegroup"
   
   echo "=== EKS 업그레이드 롤백 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo "이전 버전: $PREVIOUS_VERSION"
   echo "문제 노드 그룹: $PROBLEMATIC_NODEGROUP"
   echo
   
   # 롤백 노드 그룹 생성
   echo "=== 롤백 노드 그룹 생성 ==="
   eksctl create nodegroup \
     --cluster $CLUSTER_NAME \
     --name rollback-nodegroup \
     --node-type m5.large \
     --nodes 3 \
     --nodes-min 3 \
     --nodes-max 6 \
     --node-ami auto \
     --kubernetes-version $PREVIOUS_VERSION
   
   # 롤백 노드 그룹 상태 확인
   echo
   echo "=== 롤백 노드 그룹 상태 확인 ==="
   kubectl get nodes -l eks.amazonaws.com/nodegroup=rollback-nodegroup
   
   # 워크로드 마이그레이션
   echo
   echo "=== 워크로드 마이그레이션 ==="
   echo "문제 노드 그룹에 코드온 설정..."
   kubectl cordon -l eks.amazonaws.com/nodegroup=$PROBLEMATIC_NODEGROUP
   
   echo "파드 드레이닝..."
   kubectl drain --ignore-daemonsets --delete-emptydir-data -l eks.amazonaws.com/nodegroup=$PROBLEMATIC_NODEGROUP
   
   # 파드 재배포 확인
   echo
   echo "=== 파드 재배포 확인 ==="
   kubectl get pods --all-namespaces -o wide | grep -v "Running\|Completed"
   
   # 문제 노드 그룹 삭제
   echo
   read -p "문제 노드 그룹을 삭제하시겠습니까? (y/n): " confirm
   if [[ $confirm == "y" ]]; then
     echo "문제 노드 그룹 삭제..."
     eksctl delete nodegroup \
       --cluster $CLUSTER_NAME \
       --name $PROBLEMATIC_NODEGROUP
   else
     echo "문제 노드 그룹 삭제를 건너뜁니다."
   fi
   
   echo
   echo "=== 롤백 완료 ==="
   echo "현재 노드 상태:"
   kubectl get nodes

3. 업그레이드 문제 해결 가이드:

   # EKS 업그레이드 문제 해결 가이드
   
   ## 컨트롤 플레인 업그레이드 문제
   
   ### 증상
   - 업그레이드 상태가 "Failed"로 표시됨
   - API 서버 응답 지연 또는 오류
   - 클러스터 작업 불가
   
   ### 진단 단계
   1. 업그레이드 상태 확인:

   aws eks describe-update --name my-cluster --update-id

   
   2. 컨트롤 플레인 로그 확인:
   - CloudWatch Logs에서 `/aws/eks/my-cluster/cluster` 로그 그룹 검토
   - 오류 메시지 및 패턴 식별
   
   3. 클러스터 상태 확인:

   kubectl get componentstatuses kubectl get nodes kubectl get pods --all-namespaces

   
   ### 해결 방법
   1. AWS 지원팀에 문의
   2. 진단 정보 제공
   3. 지원팀 지침에 따라 조치
   
   ## 노드 그룹 업그레이드 문제
   
   ### 증상
   - 노드가 Ready 상태가 되지 않음
   - 파드 스케줄링 실패
   - 노드 그룹 업그레이드 상태가 "Failed"로 표시됨
   
   ### 진단 단계
   1. 노드 그룹 상태 확인:

   aws eks describe-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

   
   2. 노드 상태 및 이벤트 확인:

   kubectl describe node kubectl get events --field-selector involvedObject.name=

   
   3. 인스턴스 상태 확인:
   - EC2 콘솔에서 인스턴스 상태 확인
   - 인스턴스 시작 문제 식별
   
   ### 해결 방법
   1. 롤백 노드 그룹 생성
   2. 워크로드 마이그레이션
   3. 문제 노드 그룹 삭제
   
   ## 애드온 업그레이드 문제
   
   ### 증상
   - 애드온 파드가 CrashLoopBackOff 또는 Error 상태
   - 네트워크 또는 DNS 문제
   - 애드온 업그레이드 상태가 "Failed"로 표시됨
   
   ### 진단 단계
   1. 애드온 상태 확인:

   aws eks describe-addon --cluster-name my-cluster --addon-name

   
   2. 애드온 파드 상태 및 로그 확인:

   kubectl get pods -n kube-system -l k8s-app= kubectl logs -n kube-system

   
   3. 구성 충돌 확인:
   - 사용자 지정 구성과 기본 구성 비교
   - 충돌 식별
   
   ### 해결 방법
   1. 이전 버전으로 롤백:

   aws eks update-addon --cluster-name my-cluster --addon-name --addon-version --resolve-conflicts OVERWRITE

   
   2. 구성 충돌 해결 후 다시 시도:

   aws eks update-addon --cluster-name my-cluster --addon-name --addon-version --resolve-conflicts PRESERVE

다른 옵션들의 문제점:

• A. 즉시 새 클러스터 생성: 이는 극단적인 접근 방식으로, 시간과 리소스가 많이 소요되며, 근본 원인을 해결하지 않고 회피하는 방법입니다.

• B. 문제 발생 시 AWS 지원팀에만 의존: AWS 지원팀은 중요한 리소스이지만, 기본적인 문제 해결 단계를 먼저 수행하면 해결 시간을 단축할 수 있습니다.

• D. 업그레이드 문제 무시: 업그레이드 문제를 무시하면 클러스터 안정성, 보안 및 성능에 장기적인 영향을 미칠 수 있습니다.

### 6. Amazon EKS 클러스터 업그레이드 후 검증을 위한 가장 포괄적인 접근 방식은 무엇인가요?

A. 노드 수 확인만 수행 B. 클러스터 버전 확인만 수행 C. 시스템 구성 요소, 워크로드 기능 및 성능 메트릭을 포함한 다단계 검증 수행 D. 업그레이드 후 검증 없이 즉시 프로덕션 사용

정답 및 설명

정답: C. 시스템 구성 요소, 워크로드 기능 및 성능 메트릭을 포함한 다단계 검증 수행

설명: Amazon EKS 클러스터 업그레이드 후 검증을 위한 가장 포괄적인 접근 방식은 시스템 구성 요소, 워크로드 기능 및 성능 메트릭을 포함한 다단계 검증을 수행하는 것입니다. 이 접근 방식은 업그레이드가 성공적으로 완료되었고 클러스터가 예상대로 작동하는지 확인하는 데 도움이 됩니다.

다단계 검증의 주요 구성 요소:

1. 시스템 구성 요소 검증:

   • 컨트롤 플레인 구성 요소 상태

   • 노드 상태 및 버전

   • 시스템 파드 및 애드온 상태

2. 워크로드 기능 검증:

   • 애플리케이션 배포 및 확장

   • 서비스 연결 및 라우팅

   • 스토리지 및 볼륨 기능

3. 성능 메트릭 검증:

   • 리소스 사용량 및 효율성

   • 지연 시간 및 처리량

   • 오류율 및 가용성

구현 방법:

1. 시스템 구성 요소 검증:

   # 클러스터 버전 확인
   aws eks describe-cluster \
     --name my-cluster \
     --query "cluster.version" \
     --output text
   
   # 컨트롤 플레인 구성 요소 상태 확인
   kubectl get componentstatuses
   
   # 노드 상태 및 버전 확인
   kubectl get nodes -o wide
   
   # 시스템 파드 상태 확인
   kubectl get pods -n kube-system

2. 워크로드 기능 검증:

   # 테스트 배포 생성
   kubectl create deployment nginx-test --image=nginx
   
   # 배포 확장
   kubectl scale deployment nginx-test --replicas=3
   
   # 서비스 생성 및 연결 테스트
   kubectl expose deployment nginx-test --port=80 --type=ClusterIP
   kubectl run -it --rm --restart=Never busybox --image=busybox -- wget -O- nginx-test
   
   # 볼륨 기능 테스트
   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
   EOF
   
   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
     name: volume-test
   spec:
     containers:
     - name: volume-test
       image: busybox
       command: ["sh", "-c", "echo 'test' > /data/test.txt && sleep 3600"]
       volumeMounts:
       - name: data
         mountPath: /data
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: test-pvc
   EOF

3. 성능 메트릭 검증:

   # 노드 리소스 사용량 확인
   kubectl top nodes
   
   # 파드 리소스 사용량 확인
   kubectl top pods --all-namespaces
   
   # 로드 테스트 수행
   kubectl run -it --rm --restart=Never loadtest --image=busybox -- sh -c "while true; do wget -q -O- http://nginx-test; done"

검증 영역 및 체크리스트:

1. 컨트롤 플레인 검증:

   • API 서버 응답성

   • etcd 상태 및 성능

   • 컨트롤러 관리자 및 스케줄러 기능

2. 데이터 플레인 검증:

   • 노드 상태 및 가용성

   • kubelet 기능

   • 컨테이너 런타임 상태

3. 네트워킹 검증:

   • 파드 간 통신

   • 서비스 디스커버리

   • 인그레스 및 이그레스 트래픽

4. 스토리지 검증:

   • 볼륨 프로비저닝

   • 데이터 지속성

   • 스토리지 클래스 기능

5. 보안 검증:

   • 인증 및 권한 부여

   • 네트워크 정책

   • 암호화 및 보안 컨텍스트

모범 사례:

1. 단계적 검증 접근 방식:

   # 1단계: 시스템 구성 요소 검증
   ./validate-system-components.sh
   
   # 2단계: 기본 워크로드 기능 검증
   ./validate-basic-workloads.sh
   
   # 3단계: 고급 기능 검증
   ./validate-advanced-features.sh
   
   # 4단계: 성능 및 부하 테스트
   ./validate-performance.sh

2. 자동화된 검증 테스트:

   # 검증 작업 정의
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: cluster-validation
   spec:
     template:
       spec:
         containers:
         - name: validation
           image: validation-tools:latest
           command: ["/scripts/validate-cluster.sh"]
         restartPolicy: Never

3. 검증 결과 문서화:

   # 검증 결과 수집
   kubectl get nodes -o wide > validation-results/nodes.txt
   kubectl get pods --all-namespaces > validation-results/pods.txt
   kubectl get events --all-namespaces --sort-by='.lastTimestamp' > validation-results/events.txt
   
   # 성능 메트릭 수집
   kubectl top nodes > validation-results/node-metrics.txt
   kubectl top pods --all-namespaces > validation-results/pod-metrics.txt

4. 점진적인 프로덕션 트래픽 전환:

   • 카나리 배포 사용

   • 트래픽 점진적 증가

   • 지표 모니터링 및 이상 탐지

실제 구현 예시:

1. 포괄적인 검증 스크립트:

   #!/bin/bash
   # EKS 클러스터 업그레이드 후 포괄적인 검증 스크립트
   
   CLUSTER_NAME="my-cluster"
   
   echo "=== EKS 클러스터 업그레이드 검증 ==="
   echo "클러스터: $CLUSTER_NAME"
   echo
   
   # 결과 디렉토리 생성
   TIMESTAMP=$(date +%Y%m%d-%H%M%S)
   RESULTS_DIR="validation-results-$TIMESTAMP"
   mkdir -p $RESULTS_DIR
   
   # 1. 시스템 구성 요소 검증
   echo "=== 1. 시스템 구성 요소 검증 ==="
   
   # 클러스터 버전 확인
   echo "클러스터 버전 확인..."
   CLUSTER_VERSION=$(aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.version" --output text)
   echo "클러스터 버전: $CLUSTER_VERSION"
   echo $CLUSTER_VERSION > $RESULTS_DIR/cluster-version.txt
   
   # 컨트롤 플레인 상태 확인
   echo
   echo "컨트롤 플레인 상태 확인..."
   kubectl get componentstatuses > $RESULTS_DIR/component-status.txt
   cat $RESULTS_DIR/component-status.txt
   
   # 노드 상태 확인
   echo
   echo "노드 상태 확인..."
   kubectl get nodes -o wide > $RESULTS_DIR/nodes.txt
   cat $RESULTS_DIR/nodes.txt
   
   # 시스템 파드 상태 확인
   echo
   echo "시스템 파드 상태 확인..."
   kubectl get pods -n kube-system > $RESULTS_DIR/system-pods.txt
   cat $RESULTS_DIR/system-pods.txt
   
   # 2. 워크로드 기능 검증
   echo
   echo "=== 2. 워크로드 기능 검증 ==="
   
   # 네임스페이스 생성
   echo "테스트 네임스페이스 생성..."
   kubectl create namespace validation-test
   
   # 배포 테스트
   echo
   echo "배포 테스트..."
   kubectl create deployment nginx-test --image=nginx -n validation-test
   sleep 10
   kubectl get deployment -n validation-test > $RESULTS_DIR/deployment-test.txt
   cat $RESULTS_DIR/deployment-test.txt
   
   # 확장 테스트
   echo
   echo "확장 테스트..."
   kubectl scale deployment nginx-test --replicas=3 -n validation-test
   sleep 10
   kubectl get pods -n validation-test > $RESULTS_DIR/scaling-test.txt
   cat $RESULTS_DIR/scaling-test.txt
   
   # 서비스 테스트
   echo
   echo "서비스 테스트..."
   kubectl expose deployment nginx-test --port=80 --type=ClusterIP -n validation-test
   sleep 5
   kubectl run -it --rm --restart=Never busybox --image=busybox -n validation-test -- wget -O- nginx-test > $RESULTS_DIR/service-test.txt 2>&1 || true
   cat $RESULTS_DIR/service-test.txt
   
   # 볼륨 테스트
   echo
   echo "볼륨 테스트..."
   cat <<EOF | kubectl apply -f - -n validation-test
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
   EOF
   
   sleep 5
   kubectl get pvc -n validation-test > $RESULTS_DIR/volume-test.txt
   cat $RESULTS_DIR/volume-test.txt
   
   # 3. 성능 메트릭 검증
   echo
   echo "=== 3. 성능 메트릭 검증 ==="
   
   # 노드 메트릭
   echo "노드 메트릭 수집..."
   kubectl top nodes > $RESULTS_DIR/node-metrics.txt
   cat $RESULTS_DIR/node-metrics.txt
   
   # 파드 메트릭
   echo
   echo "파드 메트릭 수집..."
   kubectl top pods --all-namespaces > $RESULTS_DIR/pod-metrics.txt
   head -n 10 $RESULTS_DIR/pod-metrics.txt
   
   # 이벤트 확인
   echo
   echo "클러스터 이벤트 확인..."
   kubectl get events --all-namespaces --sort-by='.lastTimestamp' > $RESULTS_DIR/events.txt
   tail -n 10 $RESULTS_DIR/events.txt
   
   # 정리
   echo
   echo "테스트 리소스 정리..."
   kubectl delete namespace validation-test
   
   echo
   echo "=== 검증 완료 ==="
   echo "검증 결과가 $RESULTS_DIR 디렉토리에 저장되었습니다."
   echo
   echo "검증 요약:"
   echo "- 클러스터 버전: $CLUSTER_VERSION"
   echo "- 노드 수: $(kubectl get nodes --no-headers | wc -l)"
   echo "- 시스템 파드 수: $(kubectl get pods -n kube-system --no-headers | wc -l)"
   echo "- 오류 상태 파드: $(kubectl get pods --all-namespaces | grep -v "Running\|Completed" | wc -l)"

2. Terraform을 사용한 검증 인프라 구성:

   # 검증 네임스페이스
   resource "kubernetes_namespace" "validation" {
     metadata {
       name = "validation"
     }
   }
   
   # 검증 배포
   resource "kubernetes_deployment" "validation_app" {
     metadata {
       name      = "validation-app"
       namespace = kubernetes_namespace.validation.metadata[0].name
     }
     
     spec {
       replicas = 3
       
       selector {
         match_labels = {
           app = "validation-app"
         }
       }
       
       template {
         metadata {
           labels = {
             app = "validation-app"
           }
         }
         
         spec {
           container {
             name  = "nginx"
             image = "nginx:latest"
             
             resources {
               limits = {
                 cpu    = "200m"
                 memory = "256Mi"
               }
               requests = {
                 cpu    = "100m"
                 memory = "128Mi"
               }
             }
             
             liveness_probe {
               http_get {
                 path = "/"
                 port = 80
               }
               
               initial_delay_seconds = 3
               period_seconds        = 3
             }
           }
         }
       }
     }
   }
   
   # 검증 서비스
   resource "kubernetes_service" "validation_service" {
     metadata {
       name      = "validation-service"
       namespace = kubernetes_namespace.validation.metadata[0].name
     }
     
     spec {
       selector = {
         app = kubernetes_deployment.validation_app.spec[0].template[0].metadata[0].labels.app
       }
       
       port {
         port        = 80
         target_port = 80
       }
       
       type = "ClusterIP"
     }
   }
   
   # 검증 PVC
   resource "kubernetes_persistent_volume_claim" "validation_pvc" {
     metadata {
       name      = "validation-pvc"
       namespace = kubernetes_namespace.validation.metadata[0].name
     }
     
     spec {
       access_modes = ["ReadWriteOnce"]
       
       resources {
         requests = {
           storage = "1Gi"
         }
       }
     }
   }

3. 검증 대시보드 구성:

   # Grafana 대시보드 ConfigMap
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-validation-dashboard
     namespace: monitoring
   data:
     cluster-validation.json: |
       {
         "title": "Cluster Validation Dashboard",
         "panels": [
           {
             "title": "Node Status",
             "type": "stat",
             "datasource": "Prometheus",
             "targets": [
               {
                 "expr": "sum(kube_node_status_condition{condition=\"Ready\", status=\"true\"})",
                 "legendFormat": "Ready Nodes"
               }
             ]
           },
           {
             "title": "Pod Status",
             "type": "gauge",
             "datasource": "Prometheus",
             "targets": [
               {
                 "expr": "sum(kube_pod_status_phase{phase=\"Running\"}) / sum(kube_pod_status_phase) * 100",
                 "legendFormat": "Running Pods (%)"
               }
             ]
           },
           {
             "title": "API Server Requests",
             "type": "timeseries",
             "datasource": "Prometheus",
             "targets": [
               {
                 "expr": "sum(rate(apiserver_request_total[5m])) by (code)",
                 "legendFormat": "{{code}}"
               }
             ]
           },
           {
             "title": "Node Resource Usage",
             "type": "timeseries",
             "datasource": "Prometheus",
             "targets": [
               {
                 "expr": "sum(node_cpu_seconds_total{mode=\"user\"}) by (instance)",
                 "legendFormat": "CPU - {{instance}}"
               },
               {
                 "expr": "sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance) * 100",
                 "legendFormat": "Memory - {{instance}}"
               }
             ]
           }
         ]
       }

다른 옵션들의 문제점:

• A. 노드 수 확인만 수행: 노드 수 확인은 기본적인 검증이지만, 노드 상태, 시스템 구성 요소, 워크로드 기능 등 중요한 측면을 놓칠 수 있습니다.

• B. 클러스터 버전 확인만 수행: 클러스터 버전 확인은 업그레이드가 완료되었는지 확인하는 데 도움이 되지만, 기능적 검증이 부족합니다.

• D. 업그레이드 후 검증 없이 즉시 프로덕션 사용: 검증 없이 프로덕션에 사용하는 것은 위험하며, 잠재적인 문제가 사용자에게 영향을 미칠 수 있습니다.