Two tools for handling obsolete APIs in k8s

When we use Kubernetes to deploy services, we often find ourselves needing to update their APIs or perform a cluster upgrade. As a good practice, before performing any of these actions, we need to know the status of our current and future APIs, to validate if these actions will not affect the normal function of the applications. For this, today we bring you two tools that will facilitate this task: Kube No Trouble (kubent) and Pluto.

APIs.

Before continuing, it’s good to remember that Kubernetes is a system based on APIs, and in each version, these evolve based on new features. They have a versioning system that goes through three stages: Alpha, Beta and Stable. Eventually, within the Kubernetes deprecation policy, they may be checked as "deprecated" or "removed" in a future release of k8s.

Identify outdated APIs

Kubent: It’s a practical and easy tool that will allow us to identify if we are using obsolete versions of the APIs or next to be eliminated. Kubent will connect to our cluster to generate an easy reading report, indicating which are the deprecated APIs and which will be removed in future versions of Kubernetes. You can also specify files outside the cluster to be analyzed.

Installation:

• sh -c "$(curl -sSL 'https://git.io/install-kubent')"
  

Applications:

Analyzing APIs on the active cluster: In this example, we are going to inquire about the status of the APIs in use using as target an upgrade to Kubernetes v1.25.0.

• $ kubent --target-version 1.25.0

We can see that we have two versions of APIs to update, the first ones were removed in version 1.22 and the rest no longer exist in version 1.25.

• Detect APIs over Kubernetes configuration files:

$ kubent --filename nginx-deployment.yaml --cluster=false

In this case, the report shows us that the API used was removed and replaced by the “apps/v1” version since K8s v1.9.

Pluto.

It’s another tool that comes to facilitate the task of identifying APIs, it can perform verification on the helm charts running in our cluster, as well as integrate into our CI/CD as part of the process to validate the obsolescence of your infrastructure as code.

Installation:

• curl -sL "https://github.com/FairwindsOps/pluto/releases/download/v4.0.4/pluto_5.4.0_linux_amd64.tar.gz" | tar -zx --add-file pluto && sudo mv pluto /usr/local/bin/pluto && chmod +x /usr/local/bin/pluto

Applications:

• Analyzing APIs on the active cluster: We are going to analyze the helm packages on the cluster and use as target objective k8s v.1.22.

$ pluto detect-helm -o wide -t k8s=v1.22

In this case, like kubent, two API versions are detected that will be removed in version 1.22.

• Detect outdated APIs on configuration files in a specific directory:

$ pluto detect-files

The report tells us that the API used was removed and replaced by the "apps/v1" version.

• Analyze APIs on a helm chart before implementing it: $ helm template stable/nginx-ingress --version 0.11.1 | pluto detect -o wide -t k8s=v1.25 -

Bonus track

Plugin mapkubeapis:

Mapkubeapis is a helm v3 plugin that allows upgrading of outdated apis versions over Kubernetes cluster.

Installation:

• $ helm plugin install https://github.com/helm/helm-mapkubeapis

Applications:

• Simulate APIs updates.

$ helm mapkubeapis grafana --dry-run --namespace default

• Apply an update to deprecated APIs.

$ helm mapkubeapis grafana --namespace default

If you want to know more about K8s, we suggest going check K8s Cluster Auto-scalers: Autoscaler vs Karpenter

---

If you are interested in learning more about our #TeraTips or our blog's content, we invite you to see all the content entries that we have created for you and your needs.