Kubernetes 1.32: Enterprise Upgrade Guide for Regulated Environments

Security Improvements

• Structured Authorization Configuration (GA): Fine-grained, policy-based authorization replaces coarse RBAC for API access. Critical for multi-tenant regulated clusters.
• Pod Security Admission (stable enhancements): Improved enforcement modes and audit logging. Better visibility into what pods violate security baselines.
• Bound Service Account Tokens: Tighter token lifetimes and audience restrictions. Reduces blast radius of token compromise.
• CEL-based Admission Policies: ValidatingAdmissionPolicy is now GA — write admission rules without webhooks. Simpler, more auditable, less operational overhead.

Breaking Changes & Deprecations

• Removed APIs: Check for any workloads using deprecated API versions (FlowSchema v1beta3, PriorityLevelConfiguration v1beta3). These are REMOVED in 1.32, not just deprecated.
• Container runtime: CRI-O and containerd minimum version requirements increased. Verify your node images are current.
• Feature gate removals: Several beta feature gates locked to enabled. If you were relying on disabling a beta feature, it's now always on.
• Kubelet flag deprecations: Several kubelet configuration flags moved to config file only. Node bootstrapping scripts may need updates.

Pre-Upgrade Checklist

1. API deprecation scan: Run kubectl api-resources and compare against removed APIs. Use kubent (kube-no-trouble) to scan manifests for deprecated API usage.
2. Test in staging (identical config): Your staging cluster MUST mirror production: same network policies, same admission controllers, same PSA profiles. If staging diverges, upgrade testing is meaningless.
3. etcd backup: Snapshot etcd before ANY control plane upgrade. Verified restore procedure (not just backup — actually restore it in DR environment).
4. Node drain strategy: For regulated workloads with strict uptime requirements, plan node upgrades during maintenance windows with PDB (PodDisruptionBudget) validation.
5. Rollback plan: Document exact rollback steps. For managed K8s (EKS, AKS, GKE), verify the provider supports version rollback (many don't for control plane — only nodes).
6. Compliance documentation: Update your DORA/NIS2 system inventory with new version. Prepare change record with risk assessment, test results, and approval chain.

Upgrade Execution Order

1. Control plane first: Upgrade API server, controller-manager, scheduler. Verify cluster health (all nodes Ready, all system pods Running).
2. Wait and observe: 24-48 hours minimum in production before touching nodes. Monitor error rates, API latency, admission webhook failures.
3. Worker nodes in batches: Upgrade 10-20% of nodes at a time. Monitor workload health between batches. Never upgrade all nodes simultaneously.
4. Validation: Run conformance tests (Sonobuoy) post-upgrade. Verify all network policies, RBAC rules, and security policies still enforce correctly.
5. Post-upgrade audit: Generate compliance evidence — upgrade timeline, test results, approval records, rollback availability confirmation.

• EKS: Extended support available (14 months standard + 12 months extended). Extended support costs $0.60/cluster/hour — expensive but buys time for regulated upgrade cycles.
• AKS: Long-term support (LTS) channel available for enterprise. Provides 2 years of support per version.
• GKE: Release channels (Regular, Stable) auto-upgrade control planes. For regulated environments, use the Stable channel and disable auto-upgrade for nodes.
• OpenShift: Red Hat's Extended Update Support (EUS) aligns with regulated upgrade cadences. OpenShift 4.16+ maps to K8s 1.29+.