Data last verified 2026-10-31, covers up to Kubernetes 1.37.

Paste a manifest, then choose Check manifest.

  • Removed -
  • Not yet available -
  • Deprecated -
  • Not in dataset -
  • OK -

Results

What this checks

Paste a manifest and choose the version you're upgrading to. Each object's apiVersion and kind are compared with a dataset built from the official Deprecated API Migration Guide and the lifecycle data in the Kubernetes source.

How to read the results

Each problem row shows the best version your target serves, and when it became available. Objects are checked one by one, so one broken document doesn't stop the rest.

Removed vs deprecated

A deprecated API still works, but it's going away. Since 1.19, the API server returns a warning when you use one, and kubectl prints it. A removed API is no longer served, so applying the manifest fails with an error like this:

no matches for kind "Ingress" in version "extensions/v1beta1"

Under the deprecation policy, a beta version must stay served for at least 9 months or 3 minor releases after deprecation, whichever is longer. A GA version can be deprecated, but must not be removed within a major version.

Example: migrating an Ingress

extensions/v1beta1 Ingress was removed in 1.22. Before:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: storefront
spec:
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: web
              servicePort: 80

After:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: storefront
spec:
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: web
                port:
                  number: 80

The apiVersion changes, serviceName becomes service.name, and a numeric servicePort becomes service.port.number. pathType is now required, and ImplementationSpecific matches the old behavior.

Checking a live cluster

This page only sees what you paste. A cluster can also receive requests from controllers and scripts, and reading objects back doesn't help, because the API server converts them between versions. These show what a cluster is really receiving:

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

Limitations

FAQ

Does my manifest leave my browser?

No. The check runs in your browser, and the page's security policy stops scripts from sending data with fetch, XHR, WebSockets, beacons or form posts. The privacy page shows how to confirm it.

Which versions can I check against?

Every minor release from 1.16 through 1.37.

Can a cluster still serve a Removed API?

For one release, on clusters where you run the API server yourself. An admin can set KUBE_APISERVER_SERVE_REMOVED_APIS_FOR_ONE_RELEASE=true, which keeps the API served in the release where its removal takes effect. The source is deleted_kinds.go . Managed services generally don't expose this, so Removed means removed by default.

Does it fix my manifests?

No. The kubectl convert plugin can, though it isn't installed by default and may use non-ideal default values, so review what it produces.