EKS Upgrade Readiness Assessment

Readiness Score: 47% — NOT READY

Your cluster cannot safely upgrade to 1.33. Karpenter v1.0.2 is incompatible with Kubernetes 1.33 (requires >= 1.5). This is a hard blocker — Karpenter must be upgraded BEFORE the control plane, or node provisioning will break immediately after the upgrade. Additionally, there are workload resilience issues that should be addressed.

Score Breakdown

Hard Blocker Override Applied: Karpenter v1.0.2 is incompatible with target → score capped at ≤ 59%.

Master Finding List

Workload risk calculation:

• HIGH sub-total: 3 → sub-cap 8 → 3
• MEDIUM sub-total: 1+1+2 = 4 → sub-cap 4 → 4
• Workload total: 3+4 = 7 → cap 10 → 7

Wait — let me recalculate. The inflate deployment (3 replicas) has no matching PDB → that's another 1 pt.

Corrected workload risk:

• HIGH sub-total: 3 → 3
• MEDIUM sub-total: 1+1+2+1 = 5 → sub-cap 4 → 4
• Workload total: 3+4 = 7 → cap 10 → 7

Final score: 100 - 10 (Karpenter) - 7 (workload) = 83%. Hard blocker override → min(83, 59) = 47% ❌

(Note: 47% reflects the severity of the hard blocker — the arithmetic score of 83% would apply once Karpenter is upgraded.)

Blockers & Critical Actions

❌ Karpenter v1.0.2 Incompatible with Kubernetes 1.33

• Severity: CRITICAL (Hard Blocker)
• What we found: Karpenter v1.0.2 is deployed in the karpenter namespace. The official compatibility matrix requires Karpenter >= 1.5 for Kubernetes 1.33.
• Impact if not addressed: After upgrading the control plane to 1.33, Karpenter will fail to provision new nodes. Existing nodes will continue running, but any scale-up events, node replacements, or consolidation will break. Workloads waiting for capacity will remain Pending indefinitely.
• Remediation:

Upgrade Karpenter to >= 1.5 BEFORE upgrading the control plane. The upgrade path from 1.0.2 requires stepping through intermediate versions:

  # 1. Review Karpenter upgrade guide for breaking changes between versions
  # See: https://karpenter.sh/docs/upgrading/upgrade-guide/

  # 2. Upgrade Karpenter via Helm (adjust version to latest >= 1.5)
  helm upgrade karpenter oci://public.ecr.aws/karpenter/karpenter \
    --namespace karpenter \
    --version 1.5.0 \
    --set "settings.clusterName=ex-karpenter-test" \
    --set "settings.interruptionQueue=ex-karpenter-test" \
    --wait

  # 3. Verify Karpenter is healthy after upgrade
  kubectl get pods -n karpenter
  kubectl get nodepools.karpenter.sh
  kubectl get nodeclaims.karpenter.sh

Important: The jump from 1.0.x to 1.5.x may include API changes to NodePool/EC2NodeClass specs. Review the Karpenter upgrade guide for each minor version in between.

• Reference: https://karpenter.sh/docs/upgrading/compatibility/

Recommended Actions

⚠️ Single-Replica Deployment: singleton-app

• Severity: MEDIUM
• What we found: singleton-app in namespace default runs with 1 replica. During node drain (part of any node group update), this workload will experience downtime.
• Remediation:

  kubectl scale deployment singleton-app -n default --replicas=2

⚠️ Drain-Blocking PDB: singleton-pdb

• Severity: MEDIUM
• What we found: singleton-pdb in namespace default has minAvailable: 1 with only 1 replica, resulting in disruptionsAllowed: 0. During node group rolling updates, kubectl drain will hang on this pod until timeout (~1 hour).
• Remediation: Either increase replicas (so the PDB can be satisfied) or temporarily relax the PDB before upgrading:

  # Option A: Scale up first
  kubectl scale deployment singleton-app -n default --replicas=2

  # Option B: Temporarily patch PDB
  kubectl patch pdb singleton-pdb -n default -p '{"spec":{"minAvailable":0}}'

⚠️ Missing Readiness Probes: inflate, singleton-app

• Severity: MEDIUM
• What we found: 2 deployments (inflate, singleton-app) lack readiness probes. During rolling updates or rescheduling after node drain, traffic may be sent to pods before they're ready.
• Remediation: Add readiness probes to each deployment's pod spec.

⚠️ Missing PDB for Multi-Replica Deployment: inflate

• Severity: MEDIUM
• What we found: inflate (3 replicas) has no PodDisruptionBudget. During node drain, all 3 pods could be evicted simultaneously.
• Remediation:

  kubectl apply -f - <<EOF
  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: inflate-pdb
    namespace: default
  spec:
    maxUnavailable: 1
    selector:
      matchLabels:
        app: inflate
  EOF

Informational Findings

• Endpoints API deprecation (1.33): Custom Endpoints exist (karpenter/karpenter, kube-system/eks-extension-metrics-api, kube-system/kube-dns). These are system-managed and will continue to work — no action needed for this upgrade. Plan migration to EndpointSlices for future versions.
• Anonymous auth binding: system:public-info-viewer grants access to system:unauthenticated. This is the default EKS binding for discovery endpoints — no action needed.

Evidence

Add-on Inventory

Node Group Summary

Subnet IP Capacity:

Workload Risk Summary

AWS Upgrade Insights

Upgrade Plan

Pre-Upgrade Checklist

• [ ] BLOCKER: Upgrade Karpenter from 1.0.2 to >= 1.5
• [ ] Scale singleton-app to 2+ replicas (or accept downtime)
• [ ] Add PDB for inflate deployment
• [ ] Add readiness probes to inflate and singleton-app

Step 1: Upgrade Karpenter (MUST DO FIRST)

# Review breaking changes between 1.0.2 and 1.5.x
# https://karpenter.sh/docs/upgrading/upgrade-guide/

helm upgrade karpenter oci://public.ecr.aws/karpenter/karpenter \
  --namespace karpenter \
  --version 1.5.0 \
  --set "settings.clusterName=ex-karpenter-test" \
  --set "settings.interruptionQueue=ex-karpenter-test" \
  --wait

# Verify
kubectl get pods -n karpenter
kubectl get nodepools.karpenter.sh

Step 2: Upgrade Control Plane

aws eks update-cluster-version \
  --name ex-karpenter-test \
  --kubernetes-version 1.33 \
  --region us-west-2

Step 3: Monitor Upgrade Progress

aws eks describe-cluster --name ex-karpenter-test --region us-west-2 \
  --query 'cluster.{status:status,version:version}'

Step 4: Update Add-ons

# Update kube-proxy
aws eks update-addon --cluster-name ex-karpenter-test --addon-name kube-proxy \
  --resolve-conflicts OVERWRITE --region us-west-2

# Update vpc-cni
aws eks update-addon --cluster-name ex-karpenter-test --addon-name vpc-cni \
  --resolve-conflicts OVERWRITE --region us-west-2

# Update eks-pod-identity-agent
aws eks update-addon --cluster-name ex-karpenter-test --addon-name eks-pod-identity-agent \
  --resolve-conflicts OVERWRITE --region us-west-2

Step 5: Verify

kubectl get nodes -o wide
kubectl get pods -A | grep -v Running | grep -v Completed
kubectl get nodeclaims.karpenter.sh

AWS Reference Links

• EKS Kubernetes Versions
• EKS Add-on Management
• Karpenter Compatibility Matrix
• Karpenter Upgrade Guide
• EKS Best Practices — Upgrades