curl -fsSL https://cli.kiro.dev/install | bash
kiro-cli login   # 배포 킷의 테스트 계정으로 로그인

aws configure  # 배포 킷의 액세스 키 입력 (리전: ap-northeast-2)
aws eks update-kubeconfig --name cost-workshop --region ap-northeast-2 \
  --role-arn <배포 킷의 WorkshopParticipant Role ARN>
kubectl get nodes

kiro-cli
> !kubectl get nodes
> /tools

kiro-cli
> .kiro/skills/cluster-hello 에 스킬을 하나 만들어줘.
  이 클러스터의 노드 수 · 네임스페이스 수 · 총 파드 수를 각각 kubectl로 세서
  "노드 N대, 네임스페이스 M개, 파드 P개" 한 줄로 답하는 스킬이야.
  description은 "클러스터를 한 줄로 요약해달라고 하면 사용"으로 써줘.

# Kiro가 SKILL.md를 만들면 열어서 확인 → 그 다음 발동:
> /cluster-hello              # 또는 그냥 "클러스터 요약해줘"

kiro-cli mcp add --name aws-docs --command uvx --args "awslabs.aws-documentation-mcp-server@latest"
# context7은 본인 무료 키 필요 (아래 함정 카드) — 배포 킷 mcp.json 참고
kiro-cli mcp add --name context7 --command npx \
  --args "-y,@upstash/context7-mcp" --env "CONTEXT7_API_KEY=<본인키>"
kiro-cli
> EKS extended support 요금이 표준 지원과 얼마나 다른지 AWS 문서에서 찾아줘

이 클러스터의 노드 인스턴스 타입과 대수를 확인하고, AWS Pricing API로
서울 리전 온디맨드 단가를 조회해서 월 예상 비용을 계산해줘.
노드 외에 NAT Gateway, EBS 볼륨도 있으면 포함해줘.
주의: 계정 전체 말고 이 클러스터의 VPC와 클러스터 태그가 붙은 리소스만 집계해줘.

노드별 CPU/메모리 사용률을 보여줘. kubectl top nodes 결과와
각 노드의 allocatable 대비 requests 합계를 표로 정리해줘.
kubectl top이 안 되면 Prometheus로 대체해줘 (예: node CPU
100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100).

Prometheus에 물어봐서 (localhost:9090 port-forward 되어 있음)
지난 7일 기준 워크로드별 CPU p95 사용량과 requests를 비교해줘.
갭이 큰 순서로 표를 만들어줘. 쿼리:
quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container!=""}[15m])[7d:5m])
주의 1: rate 창은 15m 이상 (수집 간격보다 넉넉하게 — 5m이면 히스토리가 비어 보임)
주의 2: 7일 창에는 재시작된 옛 파드 시리즈도 포함되니
워크로드(Deployment) 단위로 레플리카별 샘플을 전부 풀링해 p95를 구하고
현재 replicas와 비교해줘.

store-front 네임스페이스에서 최근 재시작이 많은 파드와 그 이유를 찾아줘.
OOMKilled가 있는지 (kube_pod_container_status_last_terminated_reason),
CPU 스로틀링이 심한 파드가 있는지도 확인해줘:
rate(container_cpu_cfs_throttled_periods_total[5m])
  / rate(container_cpu_cfs_periods_total[5m]) > 0.1

kiro-cli
> .kiro/skills/rightsize 에 EKS 워크로드 라이트사이징 스킬을 만들어줘.
  description은 "request 대비 실사용 갭 분석·권장 request·월 절감액 산출을 요청하면 사용".
  스킬이 따라야 할 절차는 이렇게 명시해줘:
  1) Prometheus(localhost:9090)에서 워크로드별 7일 CPU p95 —
     quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container!=""}[15m])[7d:5m])
     rate 창은 반드시 15m (5m은 백필 간격과 같아 빈 결과). 워크로드 단위로 샘플 풀링해 p95.
     메모리는 max_over_time(container_memory_working_set_bytes{container!=""}[7d])
  2) kube_pod_container_resource_requests 와 비교해 갭 계산
  3) 신뢰성 게이트 — 다음은 축소 대상에서 빼고 "늘려야 함"으로 분리:
     · last_terminated_reason=OOMKilled 존재  · CPU 스로틀 비율 > 0.1
  4) 권장 request = CPU p95 ÷ 0.7, 메모리 max × 1.1 (반올림)
  5) 절감액 = Σ(현재−권장) × replicas × 단가 × 730h
     (단가는 Pricing API의 m5.xlarge 서울 온디맨드에서 vCPU/GiB 비율로 유도)
  6) 결과는 워크로드별 표(현재/권장/월 절감액) + 늘려야 할 목록 + kubectl patch 예시

# 생성된 SKILL.md를 열어 6단계와 게이트가 다 들어갔는지 확인

> /rightsize
# 또는: store-front 네임스페이스 라이트사이징 분석해줘

kiro-cli
> .kiro/skills/consolidate 에 EKS 노드 통합 시뮬레이션 스킬을 만들어줘.
  description은 "노드 감축 가능 대수·차단 요소(PDB·do-not-disrupt)·월 절감액을 요청하면 사용".
  절차:
  1) 노드별 allocatable과 파드 requests 합계 수집 (kubectl describe nodes 또는 KSM)
  2) First-Fit 시뮬레이션 — requests 합이 낮은 노드부터, 그 파드들이 다른 노드
     남은 공간(allocatable − requests합)에 전부 들어가는지 검사.
     DaemonSet 제외, kube-system은 이주 불가로 취급
  3) 차단 요소 검사 (있으면 그 노드는 못 비움):
     · PDB maxUnavailable:0 또는 minAvailable=replicas  · do-not-disrupt=true 어노테이션
  4) 결과: "N대 → M대 가능" + 차단 요소 목록·해결안(PDB 완화 YAML)
     + 절감액 = 감축 대수 × 노드 시간 단가 × 730h

# 생성 후 열어서 확인 → 발동:
> /consolidate               # 또는 "노드 몇 대까지 줄일 수 있어?"

kiro-cli
> .kiro/skills/nodesize 에 EKS 노드 다운사이징 시뮬레이션 스킬을 만들어줘.
  description은 "노드 인스턴스 크기를 줄였을 때(예: xlarge→large) 필요 대수·
  스케줄링 제약·월 절감액을 요청하면 사용".
  절차:
  1) 현재 노드의 allocatable(vCPU/메모리)과 전체 파드 requests 합계 수집.
     라이트사이징을 이미 적용했다면 권장 request 기준으로도 한 번 더 계산.
  2) 후보 인스턴스(현재의 1/2 크기)의 allocatable을 Pricing/스펙에서 확인 —
     주의: allocatable ≠ 물리 스펙. kube-reserved·system-reserved·eviction 여유가
     빠지므로 작은 노드일수록 사용 가능 비율이 더 낮다.
  3) 필요 대수 = ceil(요청총합 / 후보 노드 allocatable), 단 아래 제약 검사:
     · 단일 파드의 최대 request > 후보 노드 allocatable 이면 그 노드는 불가 (스케줄 실패)
     · maxPods/ENI 한도 — 작은 노드는 파드 밀도 상한이 낮다
     · DaemonSet 고정비 — 노드가 늘면 DaemonSet 사본도 늘어 오버헤드 비율↑
  4) 절감액 = (현재 대수×현재 단가 − 필요 대수×후보 단가) × 730h.
     단가는 Pricing API에서 조회. Graviton(m6g)이면 m6g.xlarge/m6g.large로 조회.
  5) 결과: "xlarge N대 → large M대" + 스케줄 불가 파드 목록 + 대수감축(3.1)과의 비교 표

# 생성 후 열어서 확인 → 발동:
> /nodesize                   # 또는 "노드를 절반 크기로 줄이면 얼마 아껴?"

이 클러스터 노드(m5.xlarge, 서울)를 기준으로:
1. aws ec2 describe-spot-price-history로 최근 Spot 가격을 조회하고
2. Pricing API로 m6g.large(Graviton) 온디맨드 단가를 조회해서
3. [현재 온디맨드 / Spot 전환 / Graviton 전환 / Spot+Graviton] 4개 시나리오의
   월 비용을 표로 비교해줘. 통합 후 5대 기준으로도 계산해줘.

kiro-cli
> 지금까지 만든 rightsize·consolidate 스킬과 L4 스캔 결과를 종합해서
  Available Savings Report를 report.html 한 파일로 만들어줘. 요구사항:
  · 맨 위에 KPI 4개(베이스라인 월 비용 / 즉시 절감액 / 식별 항목 수 / 축소금지 수)
  · 섹션: 요약·L1 라이트사이징·신뢰성·L2 통합·노드 다운사이징·단가·NET·숨은낭비·적용순서·YAML패치
  · 차트는 인라인 SVG나 CDN 없이 동작하는 방식으로 (베이스라인 도넛, L1 현재vs실사용 막대,
    노드 통합 바, 다운사이징 대수 비교, L3 시나리오 막대)
  · 절감액은 전부 베이스라인 대비 %도 함께
  · L1/L2/노드다운사이징은 서로 겹치니 "적용 순서" 섹션에서 순 절감액을 따로 명시
    (라이트사이징 → 통합 또는 다운사이징 중 택1 → 단가, 순서를 명확히)
  · 함정 2종(OOMKill·스로틀)은 빨간 카드로 "늘려라"로 표시
  그리고 patches/ 폴더에 kubectl patch용 YAML도 같이 만들어줘.

store-front 네임스페이스에서 서로 통신량이 많은 파드 쌍을 찾고,
그 두 파드가 같은 AZ에 있는지 다른 AZ에 있는지 비교해줘.
1. Prometheus로 파드별 네트워크 송수신 rate 확인:
   sum by (pod)(rate(container_network_transmit_bytes_total{namespace="store-front"}[15m]))
2. 트래픽 상위 파드가 어느 노드에 있고, 그 노드의 zone은 뭔지:
   kubectl get pod <파드> -o wide → 노드의 topology.kubernetes.io/zone 라벨
3. X-Ray 서비스맵(aws xray get-service-graph)에 양방향 엣지가 있으면 함께 제시
다른 AZ에 걸친 통신이면 cross-AZ 비용($0.01/GB 양방향)과 해결책을 알려줘.

다음 숨은 낭비를 전부 찾아줘:
1. 네트워크 트래픽이 거의 0인 Deployment (abandoned) — Prometheus rate(container_network_*)
2. 어느 파드에도 연결 안 된 EBS 볼륨 — aws ec2 describe-volumes --filters Name=status,Values=available
3. gp2 타입 볼륨 (gp3 대비 비쌈)
4. Bound 안 된 PV/PVC
5. dev 네임스페이스에서 24/7 도는 워크로드 (off-hours 스케일다운 대상)

이 클러스터의 K8s 버전이 표준 지원인지 Extended Support인지,
표준 지원이 언제 끝나는지 확인하고, Extended로 넘어가면 월 비용이
얼마나 더 드는지 계산해줘.
1. 현재 버전: aws eks describe-cluster --name cost-workshop --query cluster.version
2. 버전별 지원 상태·종료일: aws eks describe-cluster-versions
   (versionStatus = STANDARD_SUPPORT / EXTENDED_SUPPORT / UNSUPPORTED)
3. Extended 요금: 컨트롤플레인 $0.10→$0.60/h (6배) = 클러스터당 월 +$365
   → 표준 지원 종료일까지 남은 개월수와 함께 "언제까지 올려야 하나" 제시