Source

This page is generated from examples/eks-upgrades/in-place-karpenter-check/README.md. Edit the source, not this page.

Assess Your EKS Cluster Upgrade Readiness with APEX EKS

A hands-on exercise that demonstrates the APEX EKS Upgrade Check Workflow in practice. Deploy a cluster at EKS 1.32 with planted issues, then run the readiness assessment to produce a scored report identifying blockers before you upgrade.

The upgrade-check workflow uses the eks-upgrade-check skill to assess cluster readiness across 8 areas: version validation, breaking changes, deprecated APIs, add-on compatibility, node readiness, workload risks, AWS Upgrade Insights, and upgrade planning.

Overview

EKS 1.32 → 1.33 (assessment target)
   │
   ├─ Karpenter v1.0.2 (INCOMPATIBLE — requires >= 1.5 for K8s 1.33)
   ├─ Blocking PDB (singleton-app with minAvailable: 1)
   └─ Deprecated endpoints API (RBAC grants watch on endpoints)
   
   ↓ Run /apex:eks-upgrade-check
   
   📊 Readiness Report: NOT READY (score ≤ 59)
      Hard blocker: Karpenter incompatibility
      HIGH: Blocking PDB on singleton-app
      Deprecated: endpoints API usage

What This Demonstrates

This example exercises the eks-upgrade-check skill — a read-only assessment that produces a scored readiness report. It does NOT perform the upgrade itself. The skill:

1. Discovers your cluster and determines the target version (1.33)
2. Runs checks across 8 assessment areas
3. Calculates a weighted readiness score (0–100)
4. Identifies hard blockers that cap the score at ≤ 59 (NOT READY)
5. Produces a markdown report with prioritized remediation steps
6. Optionally converts to HTML with md_to_html.py

Planted Issues

#	Source	What It Does	Assessment Impact
1	karpenter.tf (Helm v1.0.2)	Deploys Karpenter at v1.0.2 via Terraform	Hard blocker — K8s 1.33 requires Karpenter >= 1.5 per the compatibility matrix. Caps readiness score at ≤ 59.
2	manifests/blocking-pdb.yaml	Single-replica Deployment + PDB with minAvailable: 1	HIGH workload risk — nodes can never be drained because evicting the only pod violates the PDB.
3	manifests/endpoints-watcher.yaml	RBAC granting watch on the endpoints API	Deprecated API — the Endpoints API is deprecated in 1.33 in favor of EndpointSlices (discovery.k8s.io/v1).

Expected Assessment Results

The readiness report should show:

• Overall Score: ≤ 59 (NOT READY)
• Hard Blocker Override: Karpenter 1.0.2 incompatible with K8s 1.33
• Add-on Compatibility: Karpenter marked INCOMPATIBLE
• Workload Risks: Blocking PDB on singleton-app (HIGH severity)
• Deprecated APIs: endpoints API RBAC detected
• Remediation: Upgrade Karpenter to >= 1.5, fix PDB (scale replicas or use maxUnavailable), migrate to EndpointSlices

Prerequisites

• AWS account with EKS permissions
• Terraform >= 1.5.7
• kubectl
• AWS CLI v2
• One of:
  • Claude Code
  • Kiro IDE or Kiro CLI

Setup and Deploy

The deploy script handles: APEX setup for your tool, Terraform deployment of the base cluster, and planting upgrade issues.

Run from this directory (examples/eks-upgrades/in-place-karpenter-check/):

chmod +x ./scripts/deploy.sh
./scripts/deploy.sh

What it does:

1. APEX setup — asks which tool (Claude Code or Kiro), symlinks skills and commands
2. Deployment name — asks for a suffix (default: check), cluster will be ex-karpenter-<suffix>
3. Terraform apply — deploys EKS 1.32 with Karpenter v1.0.2 on Fargate from examples/infrastructure/karpenter/
4. Karpenter resources — applies EC2NodeClass + NodePool, scales inflate to 3 replicas
5. Plant issues — applies blocking PDB and deprecated endpoints RBAC

Run the Upgrade Check

Claude Code

Open Claude Code from the repo root (so Claude doesn't read this README):

cd ../../..
claude

Then use the slash command:

/apex:eks-upgrade-check

Or just ask: "Is my cluster ready to upgrade to 1.33?"

Kiro CLI

cd ../../..
kiro-cli chat

Then ask: "Is my cluster ready to upgrade to 1.33?"

Walkthrough

Claude Code

Step	Screenshot
Skill triggers on upgrade question
Discovers clusters in your region
Shows cluster summary table
Assessment result with score
HTML report view

The assessment correctly identified all 3 planted issues:

1. Karpenter v1.0.2 incompatible — hard blocker, score capped at 59%
2. Blocking PDB on singleton-app — drain-blocking PDB flagged under workload risks
3. Endpoints API deprecation — detected as a behavioral change for 1.33

Full sample output: sample-report.md | sample-report.html

Kiro

Step	Screenshot
Discovers clusters and asks which to assess
Compiles findings summary
Assessment result with score
HTML report view

The assessment correctly identified all 3 planted issues:

1. Karpenter v1.0.2 incompatible — hard blocker, score capped at 47%
2. Drain-blocking PDB on singleton-app — flagged under workload risks
3. Single-replica deployment — singleton-app flagged as availability risk

Full sample output: sample-report.md | sample-report.html

Expected Outcome

By the end of this exercise, you should have:

1. A readiness report — markdown file with scored assessment across 8 areas
2. Hard blocker identified — Karpenter v1.0.2 flagged as incompatible with K8s 1.33
3. Workload risks flagged — blocking PDB detected with remediation guidance
4. Deprecated API found — endpoints RBAC usage identified
5. NOT READY verdict — score capped at ≤ 59 due to the Karpenter hard blocker
6. Prioritized remediation — ordered list of fixes before upgrade can proceed

Cleanup

chmod +x ./scripts/destroy.sh
./scripts/destroy.sh

The destroy script: deletes planted manifests, terminates Karpenter EC2 instances, removes Karpenter K8s resources, and runs terraform destroy.

Further Reading

• APEX EKS Upgrade Check Workflow
• EKS Upgrade Check Skill
  • Version Validation Reference
  • Add-on Compatibility Reference
  • Workload Risks Reference
  • Report Generation Reference
• Karpenter Compatibility Matrix
• EKS Version Release Notes