The Kubernetes API versioning scheme is great for developers. It allows the Kubernetes team to easily release new features to alpha and beta API paths and graduate them to stable paths once they’ve been battle-tested. When this happens, the older versions get deprecated and will eventually be deleted. This has led to many conversations around the Kubernetes 1.16 upgrade where multiple deprecated versions of the Deployment resource are removed (among others, read more here). It’s painful to find deprecated versions and you’ll be blocked from upgrading to 1.16 until they’ve all been updated. We decided to write an open source utility, Pluto (named after the deprecated planet), to solve this problem.
The kube-apiserver is flexible and provides the same info about a given resource type regardless of the API version specified in the request. For example, while running Kubernetes 1.15.X you can run the following commands to see Deployments from various API versions:
$ kubectl get deployments.v1beta1.apps rbac-manager -o yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: rbac-manager
...
$ kubectl get deployments.v1beta2.apps rbac-manager -o yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: rbac-manager
...
$ kubectl get deployments.v1.apps rbac-manager -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: rbac-manager
...
$ kubectl get deployments.v1beta1.extensions rbac-manager-o yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: rbac-manager
...
You’ll notice that all of these commands returned the same object, but with the apiVersion set to whatever you asked for in the request. This makes it impossible to tell which version you actually deployed to the server, causing problems when you upgrade. When you have a lot of applications deploying to your Kubernetes cluster (like many of our clients), a cluster upgrade to version 1.16 could break deployment processes, potentially across hundreds of repositories. We wanted a way to provide this info ahead of time so that deployment processes could be addressed before the upgrade happens.
Enter Pluto. You can use Pluto to scan a variety of sources for deprecated API versions, including flat manifest files, stdout from a helm template command, or even interacting directly with your cluster if you used Helm to deploy. For example, here is a scan of a cluster that deploys applications using Helm 3 (Pluto also supports Helm 2):
$ pluto detect-helm --helm-version 3
KIND VERSION DEPRECATED RESOURCE NAME
StatefulSet apps/v1beta1 true audit-dashboard-prod-rabbitmq-ha
Deployment apps/v1 false goldilocks-controller
Deployment apps/v1 false goldilocks-dashboard
Pluto tells you that your audit-dashboard-prod-rabbitmq-ha StatefulSet was deployed with a deprecated API via Helm. This is now easier to locate and fix in your chart repository before deploying on 1.16.
Before upgrading to 1.16, you can validate your Helm charts, YAML manifests, and Helm deployments running in cluster with Pluto and update any deprecated APIs. Once Pluto is passing, you’re ready to migrate to 1.16.
Pluto is now open source and 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 our Slack channel, and contribute!
Looking for a complete Kubernetes governance platform? Fairwinds Insights is available for free. Get started today.
