운영 체크리스트

4부 (EKS 실전)의 마지막 챕터입니다. 21장 EKS 클러스터 셋업 ~ 25장 모니터링 · 알람 까지를 거쳐 myshop-api는 처음 만든 빈 클러스터 위에 배포 · DB · CI/CD · 옵저버빌리티까지 한 흐름이 모두 자동화된 상태입니다. 이 시점에서 클러스터는 잘 굴러가는 상태이지만, 한 해 단위로 안전하게 운영하는 일은 다른 결의 작업입니다. K8s는 1년에 마이너 버전이 3 개씩 나오고, AWS는 분기마다 새 인스턴스 타입을 내고, RDS는 정기적으로 maintenance window가 잡힙니다. 이번 챕터는 그 정기 운영 사이클을 정리합니다 — EKS 업그레이드, 백업 · 복구, 비용, 보안의 네 차원입니다.

이번 챕터의 끝에서는 4부 회고와 본 책 1~4부 (1~26장)의 회고를 한 묶음으로 담습니다. 그 뒤로는 5부 (운영 · 디버깅 · 비용)와 6부 (캡스톤)의 본격 운영 결로 넘어갑니다.

EKS 업그레이드 — 1년에 한 번은 마이너 버전 #

K8s 자체의 버전 정책은 명확합니다.

• 마이너 버전 (1.30 → 1.31 → 1.32) — 약 4개월 주기로 릴리스됩니다.
• 각 마이너 버전의 지원 기간 — 출시 후 약 14개월입니다.
• EKS의 지원 기간 — 표준 지원 14개월 + 확장 지원 추가 12개월 (유료)입니다.

운영 클러스터가 표준 지원 안에 있도록 유지하려면 1년에 최소 한 번의 마이너 업그레이드가 필요합니다. 분기별 업데이트 캘린더로 관리하는 것이 표준입니다.

업그레이드의 표준 흐름 #

1. 릴리스 노트 검토 — 새 버전의 deprecation, removed API
2. dev 클러스터에서 먼저 업그레이드
3. 1 ~ 2 주 dev 에서 굴려 보기
4. 매니페스트의 deprecated API 정리
5. 업그레이드 점검 도구 실행 (pluto, kubent)
6. prod 컨트롤 플레인 업그레이드
7. prod 노드 그룹 업그레이드 (rolling)
8. 애드온 업그레이드 (vpc-cni, coredns, kube-proxy, ebs-csi)

각 단계에서 시간이 가장 많이 드는 곳은 4단계 — deprecated API 정리입니다. K8s가 마이너 버전마다 일부 API를 제거하므로, 매니페스트에 옛 API가 들어 있으면 새 클러스터에서 거부됩니다.

점검 도구 — pluto와 kubent #

pluto detect-files -d charts/ --target-versions k8s=v1.31

kubent --target-version 1.31

두 도구가 합쳐져 “내 매니페스트와 내 클러스터 둘 다에서” deprecated API를 찾아 줍니다. 20장 GitOps의 git 단일 소스 모델 덕분에 pluto가 매니페스트 repo 한 곳만 스캔하면 모든 환경의 deprecated API가 한 번에 잡힙니다.

컨트롤 플레인 업그레이드 — Terraform 한 줄 #

module "eks" {
  # ...
  cluster_version = "1.31"   # 1.30 -> 1.31
}

terraform apply가 EKS 컨트롤 플레인의 마이너 업그레이드를 트리거합니다. EKS는 컨트롤 플레인을 무중단으로 업그레이드합니다 — 사용자 워크로드는 영향받지 않고, kubectl도 계속 작동합니다. 약 30분~1시간 정도 걸립니다. 21장의 Terraform 매니페스트에서 cluster_version 한 줄을 올리는 것이 운영의 시작점입니다.

노드 그룹 업그레이드 — Rolling vs Blue-green #

노드 그룹의 업그레이드는 두 패턴이 있습니다.

EKS Managed Node Group의 기본은 in-place rolling입니다. EKS가 자동으로 Pod를 cordon → drain → 새 노드 띄우기 → Pod를 새 노드로 → 옛 노드 삭제의 사이클을 돕니다. 22장 앱 배포 골격에서 만든 PodDisruptionBudget이 이 시점에서 결정적입니다 — PDB가 없으면 같은 워크로드의 Pod가 동시에 다 내려갈 수 있고, 사용자에게 다운타임으로 보입니다. 22장에서 적은 한 매니페스트 한 줄이 1년 뒤 업그레이드에서 다운타임을 막는 안전선으로 기능하는 모양입니다.

# 컨트롤 플레인이 1.31 로 올라간 뒤
aws eks update-nodegroup-version \
  --cluster-name myshop-prod \
  --nodegroup-name general \
  --region ap-northeast-2

대규모 클러스터에서 업그레이드의 영향이 우려되면 blue-green 패턴이 안전합니다 — 새 노드 그룹을 만들고 13장 오토스케일링의 Karpenter disruption 제어로 워크로드를 점진 이전한 뒤 옛 그룹을 비우는 흐름입니다.

애드온 업그레이드 #

컨트롤 플레인과 노드가 새 버전이 된 뒤 애드온도 함께 올립니다.

cluster_addons = {
  vpc-cni = {
    most_recent = true   # 또는 명시적 버전
  }
  coredns = {
    most_recent = true
  }
  # ...
}

most_recent = true로 두면 Terraform이 K8s 버전과 호환되는 최신 애드온 버전으로 자동 업그레이드합니다. 명시적 버전 핀이 필요한 경우 addon_version 필드를 씁니다. 15장 CNI 깊이의 VPC CNI와 16장 RBAC / ServiceAccount 깊이의 IRSA OIDC provider가 모두 이 사이클로 함께 갱신됩니다.

백업과 복구 — RDS의 PITR이 1차 방어선 #

myshop의 데이터는 거의 전부 RDS에 있습니다. K8s 클러스터 자체는 매니페스트가 git에 있으므로 무너져도 다시 구성할 수 있지만, RDS 데이터는 한 번 잃으면 복구가 어렵습니다. 20장 GitOps의 git 단일 소스 모델 덕분에 클러스터의 stateless 부분은 본질적으로 재현 가능한 상태이고, 운영의 진짜 위험은 stateful 시스템에 집중됩니다.

자동 스냅샷 + PITR #

23장 DB 연동의 Terraform에서 backup_retention_period = 30을 적은 한 줄이 다음을 만들어 냈습니다.

• 매일 자동 스냅샷 — backup_window (03:00~04:00 UTC) 시간에 자동 백업이 돕니다.
• PITR (Point-in-Time Recovery) — 지난 30일 안의 임의 시각으로 1초 단위 복구가 가능합니다.

PITR은 RDS의 가장 강력한 백업 기능입니다. 사용자가 실수로 DELETE FROM orders;를 prod에 돌렸을 때, 그 직전 시각으로 5분 만에 새 RDS 인스턴스를 복구해 데이터를 비교할 수 있습니다.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier myshop-prod \
  --target-db-instance-identifier myshop-prod-recovery \
  --restore-time 2026-05-21T08:30:00Z \
  --db-subnet-group-name myshop-prod \
  --vpc-security-group-ids sg-xxxxx

이 명령이 30분 전 시점의 데이터를 가진 새 인스턴스를 만듭니다. 그 인스턴스에서 손상되지 않은 데이터를 SELECT로 가져와 prod에 복원하는 흐름이 표준 사고 대응입니다. 30장 업그레이드 전략 §“백업과 RPO / RTO"에서 업그레이드 직전 백업 점검의 결과 함께 짚습니다.

복구 훈련 — 분기별 점검 #

자동 백업이 굴러가는 것을 보고 안심하는 것과 실제로 복구가 가능한 것은 다릅니다. 분기에 한 번씩 복구를 시뮬레이션해 보는 게 표준입니다.

1. PITR 로 새 인스턴스 복구 (위 명령)
2. 새 인스턴스의 데이터를 표본 확인 (row count, 최근 트랜잭션)
3. dev 환경의 myshop-api 를 새 인스턴스로 가리키도록 설정 변경
4. 기능 시험 (가상 주문 생성, 조회)
5. 새 인스턴스 삭제 + 결과 문서화

이 훈련에서 한 번이라도 실패가 나오면 운영 우선순위 1번으로 잡아야 하는 신호입니다. “백업이 있다"가 아니라 “복구가 검증되었다"가 운영의 표준입니다.

클러스터 복구 — Velero #

K8s 클러스터 자체의 복구는 GitOps repo가 1차 방어선이지만, etcd 자체에 있는 동적 상태 (사용자가 만든 PVC, ConfigMap의 자동 갱신 등)까지 보존하려면 Velero가 표준 도구입니다.

velero install \
  --provider aws \
  --bucket myshop-velero-backups \
  --region ap-northeast-2 \
  --plugins velero/velero-plugin-for-aws:v1.10.0 \
  --backup-location-config region=ap-northeast-2

# 매일 자동 백업
velero schedule create daily --schedule="0 2 * * *" --ttl 720h

Velero가 etcd에서 K8s 객체 + EBS 볼륨 스냅샷을 S3로 정기 백업합니다. 클러스터를 통째로 잃었을 때 새 클러스터에서 velero restore로 복구할 수 있습니다. 9장 PV / PVC / StorageClass의 PV 모델이 본격적인 백업 대상이 되는 모양입니다.

비용 — 가장 빠르게 새는 영역 #

K8s 클러스터의 비용은 의도하지 않으면 빠르게 부풀어 오릅니다. 운영 클러스터의 비용 점검 표준 항목들을 짚어 둡니다. 본격적인 비용 최적화는 28장 비용 최적화에서 다루지만, 운영 체크리스트 차원에서 다섯 가지 출처를 미리 정리합니다.

1. Karpenter + Spot의 결합 #

21장 EKS 셋업에서 짧게 언급한 Karpenter가 비용 측면에서 가장 큰 절감을 만듭니다.

spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: NotIn
          values: ["m5.metal"]   # 너무 큰 인스턴스 제외
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Karpenter가 워크로드의 자원 요구에 정확히 맞는 인스턴스를 Spot 가격으로 띄웁니다. ON_DEMAND 대비 약 50~70% 절감이 일반적이고, consolidation으로 사용량이 낮은 노드를 자동 통합합니다. 13장 오토스케일링에서 짚었던 Karpenter의 본격 운영이 비용 결로 이어지는 단계입니다.

2. RDS 인스턴스 right-sizing #

RDS 비용은 인스턴스 클래스 + 스토리지 + IOPS의 합입니다. 인스턴스 클래스가 가장 큰 비중을 차지하므로 분기별 right-sizing 검토가 표준입니다.

- CPU 사용률 평균이 30% 미만 -> 한 단계 작은 클래스 검토
- max_connections 사용률 50% 미만 -> 풀 크기 / 인스턴스 모두 검토
- 스토리지 IOPS 의 max 가 baseline 의 50% 미만 -> gp3 로 다운사이징 검토

매니지드 서비스라 인스턴스 클래스 변경이 한 번의 reboot로 끝납니다. 분기 단위 right-sizing이 가장 큰 비용 절감 항목 중 하나입니다. 23장의 PgBouncer 도입이 본 절의 두 번째 시그널 (max_connections 사용률)을 자연스럽게 낮춰 주는 결입니다.

3. NAT Gateway 데이터 전송 #

21장에서 짧게 짚었던 NAT Gateway 비용은 시간당 + GB 당 데이터 전송 요금입니다. private 서브넷의 워크로드가 외부와 통신할 때마다 비용이 쌓이고, 의외로 큰 비중을 차지하는 경우가 많습니다.

- VPC Endpoint 도입 — S3 / ECR / DynamoDB 같은 AWS 서비스는 VPC Endpoint 로 NAT 우회
- 같은 region 의 RDS 는 VPC 내부 라우팅이라 NAT 우회 (VPC peering / Transit Gateway)
- 외부 API 를 자주 부른다면 캐싱 레이어 도입

월 $100~$500 NAT 비용이 VPC Endpoint 도입으로 그 절반 이하로 떨어지는 일이 흔합니다.

4. EBS 스냅샷과 unused 자원 #

- 옛 EBS 스냅샷 (RDS 자동 스냅샷 외에 수동으로 만든 것)
- 옛 AMI
- 분리된 EBS 볼륨 (옛 노드 그룹의 잔재)
- 사용되지 않는 ALB / NLB (옛 Ingress 의 잔재)
- ECR 의 옛 이미지 (lifecycle policy 로 자동 삭제 권장)

ECR lifecycle policy는 Terraform 한 장으로 정리됩니다.

resource "aws_ecr_lifecycle_policy" "myshop_api" {
  repository = aws_ecr_repository.myshop_api.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "Keep last 30 production tags"
        selection = {
          tagStatus     = "tagged"
          tagPrefixList = ["v"]
          countType     = "imageCountMoreThan"
          countNumber   = 30
        }
        action = { type = "expire" }
      },
      {
        rulePriority = 2
        description  = "Expire untagged after 7 days"
        selection = {
          tagStatus   = "untagged"
          countType   = "sinceImagePushed"
          countUnit   = "days"
          countNumber = 7
        }
        action = { type = "expire" }
      }
    ]
  })
}

24장 CI / CD의 이미지 태그 immutable 결정과 이 lifecycle policy가 함께 굴러갑니다 — immutable이라 같은 태그를 덮어쓸 수 없으니 옛 태그를 lifecycle로 정리하는 게 유일한 청소 길입니다.

5. 비용 가시화 — Kubecost / OpenCost #

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  -n opencost --create-namespace

OpenCost가 Prometheus 메트릭과 클라우드 비용 API를 결합해 네임스페이스 · 워크로드 단위 비용을 보여 줍니다. “myshop 네임스페이스가 한 달에 얼마를 쓰는가, 어느 워크로드가 대부분인가"가 한눈에 보입니다. 7장 Namespace와 라벨의 라벨 표준 (team / env / cost-center)이 본 절에서 본격적인 비용 책임 분배의 키로 활용됩니다. 비용 책임이 팀 단위로 떨어지는 환경에서는 거의 표준이고, 28장에서 더 자세히 짚습니다.

보안 — 정기 점검의 표준 항목 #

운영 클러스터의 보안은 한 번의 셋업이 아니라 정기 점검의 누적입니다. 표준 항목 셋을 짚어 둡니다. 비밀 운영의 본격적인 결은 29장 시크릿 운영에서 다루지만, 운영 캘린더 차원에서 네 가지 (CIS Benchmark · 이미지 스캔 · RBAC audit · admission 정책)를 먼저 정리합니다.

1. CIS Benchmark — kube-bench #

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
kubectl logs -l job-name=kube-bench

kube-bench가 CIS Kubernetes Benchmark의 항목을 자동 점검합니다. EKS는 컨트롤 플레인이 매니지드라 점검 항목이 노드 + 워크로드 매니페스트에 한정됩니다. 분기별로 실행하고 FAIL 항목을 정리하는 것이 표준입니다.

2. 컨테이너 이미지 스캔 — Trivy #

- name: Trivy 이미지 스캔
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/myshop-api:${{ steps.meta.outputs.tag }}
    format: sarif
    severity: CRITICAL,HIGH
    exit-code: 1   # CRITICAL 발견 시 빌드 실패
    output: trivy-results.sarif

- name: SARIF 를 GitHub Security 탭에 업로드
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: trivy-results.sarif

Trivy가 베이스 이미지의 OS 패키지 + 애플리케이션 의존성의 알려진 취약점 (CVE)을 스캔합니다. CRITICAL이 발견되면 빌드 실패로 막아 새 이미지가 ECR에 들어가지 못하게 합니다. 24장 CI / CD 파이프라인의 GitHub Actions 워크플로에 한 단계로 들어가, 보안 점검이 배포 파이프라인의 자연스러운 일부가 됩니다. ECR Enhanced Scanning (유료)도 같은 영역을 채우는 매니지드 옵션입니다.

3. RBAC 권한 audit #

# 모든 ClusterRoleBinding 보기
kubectl get clusterrolebindings -o wide

# 특정 권한이 부여된 주체 찾기
kubectl auth can-i --list --as=system:serviceaccount:myshop:myshop-api

# 외부 도구 — krane (Salesforce) 또는 rbac-tool

분기별로 RBAC를 audit 해서 “사용되지 않는 권한”, “과도한 권한”, “옛 ServiceAccount의 잔재"를 정리하는 흐름이 표준입니다. 16장 RBAC / ServiceAccount 깊이에서 다룬 kubectl auth can-i가 일상 점검의 도구이고, 14장 RBAC / NetworkPolicy / ResourceQuota의 표준 ClusterRole (view / edit / admin)이 audit의 기준선이 됩니다.

4. 정책 엔진 — Kyverno로 admission 강제 #

17장 Admission Controller와 18장 CRD와 Operator에서 다룬 Kyverno를 도입하면 다음 같은 정책이 admission 단계에서 강제됩니다.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-from-ecr
spec:
  validationFailureAction: Enforce
  rules:
    - name: ecr-only
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "Images must come from our ECR registry."
        pattern:
          spec:
            containers:
              - image: "123456789012.dkr.ecr.*"

이런 정책 5~10개가 운영 클러스터의 표준 가드레일입니다. 다른 사람이 외부 이미지나 limits 없는 컨테이너를 실수로 배포해도 admission 단계에서 거부됩니다. 24장의 ArgoCD 자동 sync가 도입된 환경에서는 이 admission 가드레일이 사고 방지의 마지막 보호선이 됩니다.

정기 운영 캘린더 #

위 항목을 캘린더로 정리하면 다음과 같습니다.

이 캘린더가 한 페이지에 정리되어 있고 담당자가 정해져 있는 것이 운영 팀의 목표입니다. 한 번 셋업한 뒤 “잘 굴러가니까 잊고 산다"가 가장 위험한 패턴입니다.

4부 회고 — EKS 실전 6장이 손에 남긴 것 #

4부의 6장을 한번 짚어 둡니다.

• 21장 EKS 클러스터 셋업 — Terraform으로 VPC · EKS · 노드 그룹 · IRSA · 표준 애드온까지를 한 코드베이스로 정리했습니다. eksctl 비교와 Karpenter 예고도 함께였습니다.
• 22장 앱 배포 골격 — Deployment + Service + Ingress + ConfigMap + Secret + ServiceAccount + HPA + PDB + Namespace의 표준 9 묶음을 적었습니다. AWS Load Balancer Controller로 ALB 자동 프로비저닝, Helm 차트로 dev / prod 환경별 values 분기까지 따라갔습니다.
• 23장 DB 연동 — RDS Terraform, Secrets Manager, External Secrets Operator로 비밀 동기화, PgBouncer 커넥션 풀, Helm hook 기반 마이그레이션 Job, RDS IAM 인증의 더 진보된 결까지 묶었습니다.
• 24장 CI / CD 파이프라인 — GitHub Actions OIDC로 정적 키 없이 ECR push, 매니페스트 repo 자동 commit, ArgoCD App of Apps, Argo Rollouts 카나리까지의 GitOps 파이프라인을 한 사이클로 정리했습니다.
• 25장 모니터링 · 알람 — kube-prometheus-stack의 한 번 설치, ServiceMonitor + PrometheusRule, 4 golden signals, Alertmanager severity 분기, Loki + CloudWatch의 두 축까지를 운영 결로 풀었습니다.
• 본 챕터 (26장 운영 체크리스트) — EKS 업그레이드, PITR 백업 · 복구, Karpenter Spot 비용 절감, kube-bench / Trivy / Kyverno 보안의 정기 사이클을 묶었습니다.

4부 첫 챕터에서 잡았던 가상 시나리오 (myshop-api)가 6장을 거치며 실제 운영 클러스터의 한 사이클로 완성됐습니다. 추상이 아닌 구체로 EKS를 도입 · 운영하는 시야가 손에 들어오는 단계입니다.

1~4부 회고 — 26장이 손에 남긴 것 #

본 책의 1~4부, 즉 1장부터 26장까지의 큰 그림을 한 번 정리합니다.

[1부 기초 (1 ~ 7장)]      매니페스트 한 장의 모델 — kubectl apply 한 번의 흐름
[2부 워크로드와 운영      그 매니페스트가 운영 클러스터에서 굴러가는 깊이
   (8 ~ 14장)]            — StatefulSet, PV, Ingress, 헬스, 자원, RBAC
[3부 깊이 (15 ~ 20장)]    그 위에 얹히는 정책 · 확장 · 관측 · 동기화의 결
                          — CNI, IRSA, Admission, CRD, 옵저버빌리티, GitOps
[4부 EKS 실전 (21 ~ 26장)] EKS 위 진짜 서비스 한 사이클 — myshop-api

각 부가 다음 부의 입력이 되는 구조이고, 26장 다 따라온 시점이라면 다음이 손에 들어와 있습니다.

• 매니페스트 한 장의 의도를 한 줄로 읽을 수 있는 시야
• 새 클러스터의 셋업 · 확장 · 운영의 결정이 머릿속에 들어와 있는 상태
• 사고 발생 시 어디부터 봐야 할지 즉시 짚을 수 있는 감
• 비용 · 보안 · 업그레이드의 정기 사이클이 머릿속에 캘린더로 잡힌 모양

다음 챕터 — 5부의 본격 운영 #

이 시점에서 myshop-api는 코드부터 배포 · 운영 · 관측 · 정기 사이클까지 모두 자동화된 상태입니다. 그러나 운영의 사고 대응 결은 자동화로 풀 수 없는 영역입니다. 어떤 사고가 어떤 모양으로 들어오는지, 그때 어디부터 봐야 하는지, 어느 도구가 어떤 신호를 보여 주는지의 깊이는 별도의 결로 다뤄야 합니다.

5부 (운영 · 디버깅 · 비용)의 4장이 그 결을 채웁니다.

• 27장 kubectl 디버깅 패턴 — Pod / Service / Ingress / Node의 사고 유형별 진단 경로. CrashLoopBackOff, ImagePullBackOff, OOMKilled, OutOfSync 같은 단골 사고의 책임 추적법.
• 28장 비용 최적화 — 본 챕터의 5 가지 비용 출처를 본격적으로 짚는 결. Spot · Karpenter · right-sizing · Savings Plans의 결정 트리.
• 29장 시크릿 운영 — K8s Secret의 base64 한계, sealed-secrets · external-secrets · SOPS의 비교, IRSA + RDS IAM auth의 “비밀번호 0” 운영, 저장 · 회전 · 주입 · 감사의 네 축.
• 30장 업그레이드 전략 — K8s 마이너 릴리스 사이클, 컨트롤 플레인 → 데이터 플레인 → 애드온의 순서, deprecated API 검출 (pluto / kubent / apiserver 메트릭), drain의 안전장치 (PDB · terminationGracePeriodSeconds · preStop), 업그레이드 전 1주 / 당일 / 후 1주 체크리스트.

그 뒤로는 6부 캡스톤 31장 풀스택 앱 EKS 배포에서 본 책의 모든 결을 한 프로젝트로 묶고, 부록 A docker-compose에서 K8s로에서 Docker / docker-compose 사용자를 위한 마이그레이션 가이드로 마무리합니다.

연습문제 #

1. 본인의 운영 시나리오 (또는 학습용 myshop-api 클러스터)에 맞춰 §“정기 운영 캘린더"의 6 행을 다시 채워 봅니다. 각 항목에 담당자 (또는 본인 역할) · 사용할 도구 · 마지막 실행 일자 · 다음 예정 일자를 함께 적습니다. 채운 캘린더가 한 페이지에 들어가는지 확인하고, 안 들어가면 무엇을 빼야 할지 판단합니다.
2. dev 클러스터의 EKS 버전을 한 단계 마이너 업그레이드해 봅니다. §“업그레이드의 표준 흐름"의 8단계 중 어느 단계가 가장 많은 시간을 잡아먹는지 측정하고, deprecated API 정리에 pluto와 kubent가 각각 어떤 항목을 잡아 줬는지 한 표로 비교합니다. 22장의 PDB가 노드 rolling 중에 실제로 어떤 보호를 했는지 kubectl get events로 추적합니다.
3. RDS PITR 복구 훈련을 §“복구 훈련"의 5단계로 한 번 따라 합니다. 4단계의 기능 시험에서 myshop-api의 어느 시나리오가 가장 검증 가치가 높은지 본인 도메인에 맞춰 정리하고, 훈련 결과를 25장의 Runbook git repo에 한 페이지로 문서화합니다. 다음 분기 훈련의 개선점도 함께 적어 둡니다.

한 줄 요약: 운영 클러스터의 정기 사이클은 EKS 마이너 업그레이드 (분기) + RDS PITR · Velero 백업과 분기 복구 훈련 + Karpenter Spot · OpenCost 비용 가시화 + kube-bench · Trivy · Kyverno 보안 점검의 네 축이 매일 · 매주 · 매월 · 분기 · 반기 · 연 캘린더로 묶여 굴러간다. “백업이 있다"가 아니라 “복구가 검증되었다"가 운영의 표준이고, 한 번 셋업한 뒤 “잘 굴러가니까 잊고 산다"가 가장 위험한 패턴이다. 4부의 6장이 가상 시나리오 myshop-api를 추상에서 구체로 옮겼고, 1~4부의 26장이 매니페스트 한 장의 의도부터 분기 운영 캘린더까지 한 사람의 머릿속에 자연스럽게 묶이는 시야를 만들었다.