Pluto is an open source utility that Fairwinds built to help users find deprecated Kubernetes API versions in their code repositories and Helm releases. As many Kubernetes users know, Kubernetes APIs are periodically reorganized or upgraded, and when this happens, the old API is considered obsolete and eventually removed. Pluto can help users identify these deprecated APIs so that they can update them to the latest version.
Deprecated Kubernetes API versions will eventually be removed from the API, and should be updated to a suitable replacement version. Pluto helps users identify where these versions are in use and recommends a newer version. Pluto is a command line interface (CLI) tool available on GitHub and licensed under the Apache 2.0 license.
You can use Pluto to check a couple of different places where you may have a deprecated API version:
We continue to make improvements to our open source projects — and our Slack Community is available for users to ask questions, get answers, and make suggestions. Recently, we had some questions about Pluto that we thought others might find of interest. Let’s take a look.
One Pluto user asked about the permissions needed on AKS clusters to detect live Helm releases. The question is, what is the minimal permission required to run Pluto in this scenario?
Because Pluto uses Helm releases to detect deprecated apiVersions, the user running Pluto needs access to read secrets from every namespace. If you do not have those permissions, then a good starting point is to use Pluto to check your static manifests and Helm charts within your infrastructure-as-code repository. Also, someone contributed a Github Action that can be used to scan your code with Pluto, which you should check out.
If you are using the in-cluster detection method (the "detect-api-resources" command), then Pluto will require read access to almost all of the various objects in the cluster. This is because it is inspecting all of those objects in order to find the last-applied-configuration annotation.
Another user has a Release channel based on a Google Kubernetes Engine (GKE) cluster that is currently running on Kubernetes 1.22 and they are considering upgrading to 1.23 or a later version. The question is, how can Pluto help in this case? If you run the Pluto CLI command, what would the result be, considering that the target cluster version is different from the version the GKE cluster currently has?
Good question! When you’re using the Pluto CLI, you can set your target version on the command line, like this:
pluto detect-helm --target-versions k8s=v1.23.0
This will change the behavior of exit codes, as well as the behavior of the flags that control how you view deprecated vs. removed apiVersions. The behavior is covered in more detail in the Pluto documentation.
Our Pluto user asked this follow up question: “In this case, does this detect-helm take all the helm chart releases namespace OR only the default one?”
The answer is that by default, Pluto looks for helm releases in all namespaces, however, Pluto accepts the "--namespace" flag, which will restrict it to only one namespace.
The short answer is yes, Pluto can detect Custom Resource Definitions (CRDs). Please note, though, you'll need to specify the target version of the component, for example:
For CertManager, which has its own CRDs, those don't get deprecated in a particular version of Kubernetes. Instead, they get deprecated in a particular version of cert-manager, so you have to specify "I'm targeting cert-manager 1.6.0" and then Pluto can tell you if you have any cert-manager CRDs that won't work with email@example.com.
If you have additional CRDs that you want to add to Pluto, you can specify them by using a custom versions file. Currently, we only have limited support for the cert-manager CRDs, and a few Istio apiVersions that were contributed by a community member. The documentation has more details on the versions file and how to use your own.
We're also working on a more in-depth open source tool for Helm upgrade pre-checks called GoNoGo.
The goal of our Fairwinds Community is to exchange ideas, build and contribute to open source projects, and network with Kubernetes users. Get involved with the community: chat with us on Slack or join the user group.
And if you are interested in contributing to Pluto or any of our other open source projects, we’d appreciate your help making our open source offerings as useful to the community as possible.
If you want to run Pluto in multiple clusters, track results over time, integrate with Slack, Datadog, and Jira, and unlock other functionality to help you run Kubernetes securely, reliably, and cost efficiently at scale, check out Fairwinds Insights.