By Stepan Stipl September 1, 2020

Guest post originally published on the DoiT International blog by Stepan Stipl, Senior Cloud Architect at DoiT International

With Kubernetes 1.16 available for a while and starting to slowly roll out across many managed Kubernetes platforms, you might have heard about API deprecations. While fairly simple to deal with, this change might seriously disrupt your services if left unattended.

Fine Wind, Clear Morning by Hokusai

API deprecation — what is that?

As Kubernetes’ feature set evolves, APIs have to evolve too in order to support this change. There are rules in place that aim to guarantee compatibility and stability¹. It does not happen with every release, but eventually, you will have to use the new API version and format as the old one won’t be supported anymore.

Why is this important with the 1.16 release?

A few deprecated APIs have been kept around in the last couple of K8s versions and finally getting completely removed in Kubernetes 1.16 release. Namely following API Groups and versions:

If you try to create a resource using one of these with 1.16, the operation will simply fail.

How to check if I am affected?

You can manually go through all your manifests, but that can be fairly time-consuming. It’s easy to miss some and might be highly unpractical if you have multiple teams deploying to the cluster, or simply don’t have all the current manifests in one place. And this is where Kube-No-Trouble aka kubent comes to help.

What’s the catch?

The information about what API version was used to create a given resource is normally not accessible, as the resource is always converted to and stored in the preferred storage version internally. However. if you’re using kubectl or Helm to deploy your resources, the original manifest is stored inside the cluster as well and we can leverage that².

How to solve your deprecation-induced woes

The simplest way is to install is:

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

This will install the latest version of kubent to /usr/local/bin³.

Configure kubectl’s current context to point to the cluster you want to check and run the kubent tool:

Fig. 1: Sample output of kubent run

Kubent will connect to your cluster, retrieve all resources that might be affected, scan, and print a summary of those that are.

You can also use -f json flag to get output in JSON format which is more suitable in case you want to integrate this in your CI/CD pipeline or process the results further. More details on available configuration options are described in the README of doitintl/kube-no-trouble repo.

What should I do with the resources that are detected?

In some cases, it’s as simple as changing the apiVersion in your manifest, but in others the structure might have changed and will need adjusting. Also, be aware that a lot of defaults changed between versions⁴,so by only changing the apiVersion and applying the same manifest, you would end up with different results. For example, StatefulSet’s updateStrategy.type changed from OnDelete to RollingUpdate, resulting in very different behavior.

The previously used kubectl convert command is now deprecated, and might not convert your resources correctly with respect to the previously mentioned default values.

Possibly the best way is to simply apply the resources (you already have that if you have detected them with kubent) and retrieve the new version from API. This will ensure that the resource will be correctly transformed to the new version. You might have noticed that kubectl is somewhat non-deterministic as to what version it returns. To request a specific API version, use the full form:

kubectl get ingress.v1beta1.extensions -o yaml

Feedback welcome!

Hopefully, this will help you to detect and deal with the use of deprecated APIs in your Kubernetes clusters before these could cause you any trouble.

It is still very early for the kubent tool and I would love to hear any comments, suggestions, and if you find it useful. Safe sailing! ⛵⛵⛵

Additional references:

Work with Stepan at DoiT International! Apply for Engineering openings on our careers site.