Kubernetes & Amazon EKS Training

한국어

English
中文
日本語
Español

한국어

English
中文
日本語
Español

Appearance

Amazon 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. 업그레이드 경로 및 호환성 검토:

    bash
    # 현재 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. 워크로드 호환성 검사 도구 사용:

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

# kube-no-trouble 사용
kubectl-no-trouble

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

    bash
    # 테스트 클러스터 생성
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. 업그레이드 계획 문서 작성:

    markdown
    # 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. 업그레이드 호환성 검토 스크립트:

    bash
    #!/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. 업그레이드 테스트 계획 템플릿:

    markdown
    # 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. 컨트롤 플레인 업그레이드:

    bash
    # 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>
    bash
    # eksctl을 사용한 컨트롤 플레인 업그레이드
eksctl upgrade cluster \
  --name my-cluster \
  --version 1.28 \
  --approve

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

    bash
    # 클러스터 버전 확인
aws eks describe-cluster \
  --name my-cluster \
  --query "cluster.version" \
  --output text

# 클러스터 상태 확인
kubectl get componentstatuses
kubectl get nodes

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

    bash
    # 현재 노드 그룹 확인
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. 업그레이드 전 클러스터 상태 확인:

    bash
    # 클러스터 상태 확인
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 백업:

    bash
    # etcd 백업 (자체 관리 클러스터의 경우)
ETCDCTL_API=3 etcdctl snapshot save snapshot.db

# EKS의 경우 주요 리소스 백업
kubectl get all --all-namespaces -o yaml > all-resources.yaml

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

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

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

    bash
    # 시스템 파드 상태 확인
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. 컨트롤 플레인 업그레이드 스크립트:

    bash
    #!/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 클러스터 버전 관리:

    hcl
    # 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. 업그레이드 후 검증 스크립트:

    bash
    #!/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. 관리형 노드 그룹 업그레이드:

    bash
    # 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>
    bash
    # eksctl을 사용한 관리형 노드 그룹 업그레이드
eksctl upgrade nodegroup \
  --cluster my-cluster \
  --name my-nodegroup \
  --kubernetes-version 1.28

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

    bash
    # 새 노드 그룹 생성
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) 구성:

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

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

    yaml
    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. 테인트 및 톨러레이션 활용:

    yaml
    # 새 노드 그룹에 테인트 적용
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. 업그레이드 전 준비:

    bash
    # 노드 상태 확인
kubectl get nodes

# 파드 분포 확인
kubectl get pods -o wide --all-namespaces

# 리소스 사용량 확인
kubectl top nodes
kubectl top pods --all-namespaces

  2. 점진적 업그레이드:

    • 한 번에 하나의 노드 그룹만 업그레이드
    • 중요도가 낮은 워크로드부터 시작
    • 각 단계 검증 후 진행

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

    • 노드 상태 모니터링
    • 파드 이벤트 모니터링
    • 애플리케이션 성능 및 가용성 모니터링

  4. 롤백 계획 수립:

    • 명확한 롤백 기준 정의
    • 롤백 절차 문서화
    • 빠른 롤백을 위한 준비

실제 구현 예시:

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

    bash
    #!/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. 블루/그린 배포 스크립트:

    bash
    #!/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을 사용한 블루/그린 배포:

    hcl
    # 현재 활성 노드 그룹 버전 변수
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 관리형 애드온 업그레이드:

    bash
    # 사용 가능한 애드온 버전 확인
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 애드온 업그레이드:

    bash
    # 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. 자체 관리형 애드온 업그레이드:

    bash
    # 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. 애드온 버전 호환성 확인:

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

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

    bash
    # 현재 애드온 상태 확인
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. 사용자 지정 설정 백업:

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

실제 구현 예시:

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

    bash
    #!/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을 사용한 애드온 관리:

    hcl
    # 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. 자체 관리형 애드온 업그레이드 스크립트:

    bash
    #!/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. 업그레이드 문제 진단:

    bash
    # 클러스터 상태 확인
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. 노드 그룹 문제 진단:

    bash
    # 노드 그룹 상태 확인
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. 애드온 문제 진단:

    bash
    # 애드온 상태 확인
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. 문제 해결을 위한 로그 수집:

    bash
    # 클러스터 정보 수집
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. 롤백 절차 준비:

    bash
    # 노드 그룹 롤백 (새 노드 그룹 생성)
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. 문제 해결 문서화:

    markdown
    # 업그레이드 문제 해결 보고서

## 문제 설명
- 증상: 노드 그룹 업그레이드 후 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. 업그레이드 문제 해결 스크립트:

    bash
    #!/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. 업그레이드 롤백 스크립트:

    bash
    #!/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. 업그레이드 문제 해결 가이드:

    markdown
    # EKS 업그레이드 문제 해결 가이드

## 컨트롤 플레인 업그레이드 문제

### 증상
- 업그레이드 상태가 "Failed"로 표시됨
- API 서버 응답 지연 또는 오류
- 클러스터 작업 불가

### 진단 단계
1. 업그레이드 상태 확인:
   ```
   aws eks describe-update --name my-cluster --update-id <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 <node-name>
   kubectl get events --field-selector involvedObject.name=<node-name>
   ```

3. 인스턴스 상태 확인:
   - EC2 콘솔에서 인스턴스 상태 확인
   - 인스턴스 시작 문제 식별

### 해결 방법
1. 롤백 노드 그룹 생성
2. 워크로드 마이그레이션
3. 문제 노드 그룹 삭제

## 애드온 업그레이드 문제

### 증상
- 애드온 파드가 CrashLoopBackOff 또는 Error 상태
- 네트워크 또는 DNS 문제
- 애드온 업그레이드 상태가 "Failed"로 표시됨

### 진단 단계
1. 애드온 상태 확인:
   ```
   aws eks describe-addon --cluster-name my-cluster --addon-name <addon-name>
   ```

2. 애드온 파드 상태 및 로그 확인:
   ```
   kubectl get pods -n kube-system -l k8s-app=<addon-label>
   kubectl logs -n kube-system <addon-pod-name>
   ```

3. 구성 충돌 확인:
   - 사용자 지정 구성과 기본 구성 비교
   - 충돌 식별

### 해결 방법
1. 이전 버전으로 롤백:
   ```
   aws eks update-addon --cluster-name my-cluster --addon-name <addon-name> --addon-version <previous-version> --resolve-conflicts OVERWRITE
   ```

2. 구성 충돌 해결 후 다시 시도:
   ```
   aws eks update-addon --cluster-name my-cluster --addon-name <addon-name> --addon-version <target-version> --resolve-conflicts PRESERVE
   ```

다른 옵션들의 문제점:

  • A. 즉시 새 클러스터 생성: 이는 극단적인 접근 방식으로, 시간과 리소스가 많이 소요되며, 근본 원인을 해결하지 않고 회피하는 방법입니다.
  • B. 문제 발생 시 AWS 지원팀에만 의존: AWS 지원팀은 중요한 리소스이지만, 기본적인 문제 해결 단계를 먼저 수행하면 해결 시간을 단축할 수 있습니다.
  • D. 업그레이드 문제 무시: 업그레이드 문제를 무시하면 클러스터 안정성, 보안 및 성능에 장기적인 영향을 미칠 수 있습니다.
### 6. Amazon EKS 클러스터 업그레이드 후 검증을 위한 가장 포괄적인 접근 방식은 무엇인가요?

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

정답 및 설명

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

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

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

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

    • 컨트롤 플레인 구성 요소 상태
    • 노드 상태 및 버전
    • 시스템 파드 및 애드온 상태

  2. 워크로드 기능 검증:

    • 애플리케이션 배포 및 확장
    • 서비스 연결 및 라우팅
    • 스토리지 및 볼륨 기능

  3. 성능 메트릭 검증:

    • 리소스 사용량 및 효율성
    • 지연 시간 및 처리량
    • 오류율 및 가용성

구현 방법:

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

    bash
    # 클러스터 버전 확인
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. 워크로드 기능 검증:

    bash
    # 테스트 배포 생성
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. 성능 메트릭 검증:

    bash
    # 노드 리소스 사용량 확인
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. 단계적 검증 접근 방식:

    bash
    # 1단계: 시스템 구성 요소 검증
./validate-system-components.sh

# 2단계: 기본 워크로드 기능 검증
./validate-basic-workloads.sh

# 3단계: 고급 기능 검증
./validate-advanced-features.sh

# 4단계: 성능 및 부하 테스트
./validate-performance.sh

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

    yaml
    # 검증 작업 정의
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. 검증 결과 문서화:

    bash
    # 검증 결과 수집
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. 포괄적인 검증 스크립트:

    bash
    #!/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을 사용한 검증 인프라 구성:

    hcl
    # 검증 네임스페이스
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. 검증 대시보드 구성:

    yaml
    # 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. 업그레이드 후 검증 없이 즉시 프로덕션 사용: 검증 없이 프로덕션에 사용하는 것은 위험하며, 잠재적인 문제가 사용자에게 영향을 미칠 수 있습니다.