kubectl "no matches for kind ... in version" / "the server doesn't have a resource type" / "unable to recognize" after a Kubernetes upgrade: removed deprecated API versions (Ingress, CronJob, HPA, PodDisruptionBudget, PodSecurityPolicy)

Cause: Kubernetes removes deprecated beta API versions in specific releases. Manifests, Helm charts and operators that still use the old apiVersion fail on the upgraded cluster with errors like "no matches for kind X in version Y", "unable to recognize", or "the server doesn't have a resource type". The fix is to move to the stable API version, not to downgrade the cluster. Fix (best first): 1. Identify the failing kind and apiVersion from the error, then compare with the Kubernetes deprecated API migration guide. Examples from that guide: batch/v1beta1 CronJob -> batch/v1 (removed in 1.25); policy/v1beta1 PodDisruptionBudget -> policy/v1 (removed in 1.25; note an empty selector in policy/v1 selects all pods in the namespace); autoscaling/v2beta1 HorizontalPodAutoscaler -> autoscaling/v2 (removed in 1.25), and autoscaling/v2beta2 -> autoscaling/v2 (removed in 1.26; targetAverageUtilization becomes target.type Utilization with target.averageUtilization); discovery.k8s.io/v1beta1 EndpointSlice and events.k8s.io/v1beta1 Event -> v1 (removed in 1.25); flowcontrol.apiserver.k8s.io beta versions -> v1 (v1beta2 removed in 1.29, v1beta3 in 1.32). policy/v1beta1 PodSecurityPolicy was removed in 1.25 along with its admission controller; replace it with Pod Security Admission or an admission webhook policy. 2. Update the manifests: change apiVersion and any renamed fields, then re-apply. Re-check the migration guide for the fields that changed per kind. 3. Update Helm charts and operators to versions that use the stable APIs. 4. Find remaining users before upgrading next time: the API server returns Warning headers for deprecated APIs, and the apiserver_requested_deprecated_apis metric (labels group, version, resource, removed_release) shows who still calls them. 5. Check your cluster version with kubectl version and list what it serves with kubectl api-versions and kubectl api-resources. Verify: kubectl apply --dry-run=server -f manifests/ succeeds with no deprecation warnings, and kubectl get the resource works under the new apiVersion. Sources: https://kubernetes.io/docs/reference/using-api/deprecation-guide/ https://kubernetes.io/docs/reference/using-api/deprecation-policy/