Guest post originally published on Fairwind’s blog by Robert Brennan, Fairwinds
Hello from Pluto, the little planet with big open source value. Once considered a full-size sphere in the cosmos, Pluto was downgraded to a dwarf planet in 2006 when it no longer met the modern criteria. Turns out, Kubernetes APIs are not so different-they also become outdated as older code loses value within the codebase, usually because it has been superseded by newer code.
Pluto, a Fairwinds open source project, is named after the deprecated planet because it helps users easily find worn out Kubernetes API versions in their code repositories and Helm releases.
Wait, what is the deprecation policy for Kubernetes?
As we know, Kubernetes adoption allows users to benefit from container technology at scale. What makes containers so popular is their ability to provide abstraction and isolation of resources. This means that a standalone container image is enough for you to run an application on your system without having to install any additional packages.
Not to be confused with docker, an open source containerization platform launched in 2013, Kubernetes helps to manage such workloads and microservices. As more and more containers are deployed, the requirement for Kubernetes upkeep increases. With each new release, any upgrades to services or operations must be compatible and secure in the production environment. This means the latest version, upon release, must be tested and patched.
As a large open source system with many components and contributors, Kubernetes naturally evolves over time. Because Kubernetes is API-driven, the API evolves gradually to reflect the shifting understanding of the problem space. Sometimes certain features need to be removed as a result, including an API, a flag or even an entire feature. To avoid breaking existing users, Kubernetes follows a depreciation policy for aspects of the system that are slated to be removed.
A given release of Kubernetes can support any number of API groups and versions. Here are three main rules governing the deprecation of API elements:
- API elements may only be removed by incrementing the version of the API group.
- API projects must be able to round-trip between API versions in a given release without data loss-with the exception of whole REST resources that do not exist in some version.
- An API version in a given track may not be deprecated until a new API version that is similarly stable is released.
Tell me more about these API versions…
Unless practitioners explicitly use features only available in a newer version, they must be able to upgrade to a new release of Kubernetes and roll back to a previous release, without anything to the new API versions or suffering breakages. As such, the Kubernetes API versioning scheme is an excellent tool for developers because it allows Kubernetes teams to release new features to alpha and beta API paths and graduate them to stable paths one they’ve been tested and verified. The older versions are then deprecated and eventually deleted.
This process has led to some discussion around Kubernetes upgrades, most notably the 1.16 release, where multiple outdated versions of the deployment resource are removed. Why? Because it can be painful to find all the places where a deprecated API version has been deployed. This is where a visit to Pluto can solve the problem.
What problem does Pluto solve?
As an open source utility established through Fairwinds, Pluto helps users easily identify deprecated Kubernetes API versions in their code repositories and Helm releases. As Kubernetes APIs evolve, they are periodically reorganized or upgraded. When this happens, the old API is considered obsolete and eventually removed. The Kubernetes API server is flexible and will provide the same information about a given resource type, regardless of the API version specified in the request. This feature makes it impossible to differentiate which version was actually deployed to the server, causing problems during upgrade.
Where there are a lot of applications deploying to a Kubernetes cluster, a cluster upgrade can break the deployment process-potentially affecting hundreds of repositories. Pluto was created to provide this information ahead of time, so deployment processes can be addressed before the upgrade takes place.
Pluto can be used to scan a variety of sources for deprecated API versions, including flat manifest files, and even interact directly with a cluster when using Helm to deploy.
Although Helm 2 has been deprecated, here is an example of a cluster that deploys applications using Helm 3:
Pluto indicates the “audit-dashboard-prod-rabbitmq-ha Stateful set” was deployed with a deprecated API via Helm. Locating and fixing a chart repository before deploying now became a whole lot easier. Pluto will be updated to include future releases of Kubernetes and any deprecations to resource APIs. We’re working hard to add features, so please open issues, join the Fairwinds Slack channel and contribute!
If you’re interested in running Pluto in multiple clusters, tracking the results over time, integrating with Slack, Datadog and Jira, or unlocking other functionality, check out Fairwinds Insights, a platform for auditing and enforcing policy in Kubernetes clusters.