How to Detect Deprecated Kubernetes APIs with Plural

Kubernetes has developed the Kubernetes API to evolve and expand consistently to accommodate new use cases and evolving needs.

Running outdated Kubernetes versions puts your application at risk of experiencing downtime, like a site-wide outage experienced by Reddit in 2023. While that was a worst-case scenario, you can’t afford anything but your business application that makes your company money can’t afford to be down for even one minute.

In this post, we’ll highlight how you would detect APIs in your cluster without Plural and explore how Plural automates this process for you in a single pane of glass.

What is the Kubernetes API?

The Kubernetes API serves as an interface to interact with a Kubernetes cluster. It allows users to query and manipulate Kubernetes objects like pods, namespaces, and deployments. These APIs can be accessed through tools such as kubectl, via the REST API directly, or using client libraries.

Even if upgrading doesn’t result in a full-out outage, tiny differences in Kubernetes APIs can frustrate developers hunting down the underlying problem. While figuring out Kubernetes API versions for one cluster isn’t bad, it increases in complexity and time required when identifying specific API versions for a large fleet of clusters spread out across multiple teams utilizing various cloud, on-prem, and edge environments.

Detecting deprecated APIs in your cluster without Plural

Although Kubernetes provides official documentation to examine deprecated or removed APIs, identifying resources in your cluster utilizing those APIs can be quite challenging.

Kubernetes abides by a stringent API versioning protocol, resulting in multiple deprecations of v1beta1 and v2beta1 APIs across several releases. Their policy states Beta API versions are mandated to receive support for a minimum of 9 months or 3 releases (whichever is longer) after deprecation, after which may be subject to removal.

In cases where APIs have been deprecated and are still actively employed by workloads, tools, or other components interfacing with clusters, disruptions may occur. Hence, users and administrators must conduct a thorough assessment of their cluster to identify any APIs in use slated for removal, and subsequently migrate affected components to leverage the appropriate new API version.

An example is the APIVersion extensions/v1beta1 of the Ingress Resource, which was removed in Kubernetes version v1.22. Attempting to use such a removed API version in your configuration would result in an error message:

 Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Ingress" in version "extensions/v1beta1"

You can also review all supported API groups along with their versions through official documentation or by using kubectl command-line tool's api-versions command:‌

kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1

However, simply listing your Kubernetes resources using kubectl commands may yield inaccurate API version information, as explained in this issue.

app/v1 show as extensions/v1beta1 when `kubectl get xxx -oyaml` · Issue #58131 · kubernetes/kubernetes

Is this a BUG REPORT or FEATURE REQUEST?: Uncomment only one, leave it on its own line: /kind bug /kind feature What happened: kubectl version [root@ib17b07 ~]# kubectl version Client Version: vers…

GitHubkubernetes

Still, identifying deprecated versions of Kubernetes APIs is a laborious and error-prone task, requiring manual inspection of all manifests. This process becomes even more cumbersome – or even impossible – when multiple teams deploy to a cluster without a centralized manifest repository.

Identifying deprecated Kubernetes API versions with Plural

Plural offers a comprehensive analysis of source code deployed to your Kubernetes clusters by scanning existing Git repositories. Our platform automatically surfaces deprecated resources detected on clusters and links the location in Github for review. To access these features you’ll need to sign in to your plural account and navigate to the Plural console.

Deprecations will surface at the cluster level in the "Status" column of the Clusters table. If the cluster was deployed via Plural, a button to upgrade the cluster will appear. If you deployed the cluster yourself Plural will surface a notification to upgrade the cluster externally to the latest version.

To see deprecations relevant to a specific service, navigate to the Service details page. You'll see a notification to review any changes that need to be made:

So you can triage a ticket to the appropriate service owner to get it fixed before you hit that next upgrade.

On top of this, Plural will immediately identify non-compatible Kubernetes add-ons that make Kubernetes upgrades challenging. Our platform will surface the compatible Kubernetes versions based on their documentation.

You can also see the full version history for those add-ons as well. One of the main benefits of this approach is it removes a lot of the risks from upgrading and this helps engineers who are not as familiar with the Kubernetes ecosystem be able to own a Kubernetes upgrade instead of a very seasoned senior engineer.

Plural for Kubernetes Fleet Management

Currently, the barrier to entry for working with Kubernetes is high and slows down fast-moving teams' adoption of Kubernetes at scale. Plural allows any engineer to easily manage their Kubernetes ecosystem anywhere - securely and at scale -  in a single pane of glass regardless of expertise.

Plural is a self-hosted Kubernetes fleet management platform that provides a single pane of glass, removing the complexity of managing Kubernetes clusters at scale. With Plural, engineering teams can gain visibility, automation, governance, and security capabilities in an easily adaptable platform to manage the lifecycle of Kubernetes clusters across public clouds such as AWS, Azure, and GCP as well as on-prem and remote/edge locations.

With Plural, engineering teams can do the following:

• Gain multi-cluster visibility into your entire cluster fleet across various environments. With Plural, your engineers get self-service access to Kubernetes clusters and automated cluster lifecycle management using proven templates with guardrails included.
• Manage Kubernetes clusters and add-on upgrades in a single, intuitive interface and confidently know that upgrading a Kubernetes version won’t break anything downstream. Plural will help you with upgrading the control plane, Kubernetes add-ons, and your services. With Plural, you’ll be made aware if you have a compatible version of your add-ons for the version of Kubernetes you are upgrading.
• Share the responsibility of managing Kubernetes tasks with a broader subset of your engineers, including those without prior Kubernetes experience. Top-tier Kubernetes talent is costly and hard to attain. Managing infrastructure shouldn’t be challenging and pricey, and your most skilled engineers should focus on building out awesome product features to drive business value. With Plural, your team can create standard workflows to automate time-tedious and challenging tasks of configuring, and provisioning clusters across fleets in one patch rather than following the manual, error-prone process today that makes managing Kubernetes clusters challenging.

To learn more about Plural’s self-hosted fleet Kubernetes fleet management platform sign up for a custom product demo to learn more.