Pluto - how to find deprecated Kubernetes apiVersions

Hi, today I am going to introduce Pluto to you. So, what is it? 🤔

Pluto is a utility to help users find deprecated Kubernetes apiVersions in their code repositories and their helm releases.

Sounds great! You use Kubernetes right? So, you know that Kubernetes has Deprecation Policy. It is a large system, so many features evolve over time and many of them might be removed. Thus, to avoid problems, Kubernetes provides a deprecation policy. So, you know in advance that something is going to be deprecated and you should act!

There are 3 main "API Groups" in Kubernetes:

  • Alpha (v1alpha1)
  • Beta (v1beta1)
  • Stable (v1)

From time to time, some objects (or their versions) in Kubernetes can be removed or deprecated and it would be nice to know about it in advance. And for that job you can use:

Let's see this guy in an action!

You need to install it firstly of course. You can do that by this command:

I used minikube (minikube start --kubernetes-version=v1.16.1) to set up a local Kubernetes cluster, so by default there are only some basic stuff. I am going to install grafana via Helm. This chart is already deprecated, so it is useful, because you find some old stuff there!

The chart has been installed. Let's run pluto. You can use pluto in three ways:

  • File Detection in a Directory
  • Helm Detection (in-cluster)
  • Helm Chart Checking (local files)

I am going to use Helm Detection (in-cluster) because my chart is installed and I want to check it. By default pluto checks v1.16.0 version, but there is a flag --target-versions and I can check whatever version I want. So, let's say that I have Kubernetes cluster in 1.16 version and I want to upgrade my cluster to 1.17.

Before that, I want to check if everything will be all right with my deployments after upgrade. I can type pluto detect-helm -o wide --target-versions k8s=v1.17.0:

What I see here? pluto tells me that in v1.17.0 version, rbac.authorization.k8s.io/v1beta1 will be deprecated for Role and RoleBinding objects. I can still use them (in v1.17.0 version), but it will be removed in v1.22.0 version. So, after the upgrade I should change rbac.authorization.k8s.io/v1beta1 to rbac.authorization.k8s.io/v1 for these objects in my helm chart.

I also checked v1.22.0 version. And, now I know that I should change my Ingress object for grafana too. The current version will be deprecated in v1.19.0, and I should use networking.k8s.io/v1 instead.

Great, I can check what's going on on my cluster, but I also want to know about it in my CI tools. For this, I can use Helm Chart Checking (local files). Here is an example:

I rendered the template of the chronograf chart and piped it into pluto. And this way I know that I cannot use this chart in Kubernetes 1.16. Because extensions/v1beta1 has been removed in v1.16.0, but it is still in my chart.

So, in this way you can loop through your helm charts and check them with pluto to find out about potential problems in advance.

That's it. Have a nice day!

If you do not want to read this post, here is a video:

Comments

Post a Comment

Popular posts from this blog

GitLab - extends keyword

Image
In the previous post I had written about the include keyword. Now, let's dive in the extends  keyword. What can you do with this? Here is the definition from GitLab documentation: extends defines entry names that a job that uses extends inherits from. It’s an alternative to using YAML anchors and is a little more flexible and readable. So, when is it useful? It is useful when you want to be DRY and keep your setup cleanly. Let's assume that you want to build a docker image and give developers possibility to deploy the image on dev , staging and prod environments. We are going to do that without the extends keyword, and after that we will think how we can do it better. Example without the extends  keyword: As you can see, there is a lot of code which repeats itself: stage, image, when  and script . We can remove a lot of code! So, let's do that. We are going to create a hidden job .deploy  (you will not see this job in a pipeline) and the rest of the jobs ...
Read more

Managing Secrets in GitLab / Git

Image
Let's say that you have to log in via ssh into an instance, and you work with GitLab, so you want to keep the private key in GitLab somewhere. Is it secure? Let's see! Custom environment variables You can use custom environment variables. Here you can read more about them (Developers cannot change them, only Maintainers and Owners can). There are two types of variables: Variable (the runner creates an environment variable that uses the key for the name and the value for the value) File (the runner creates an environment variable that uses the key for the name. For the value, the runner writes the variable value to a temporary file and uses this path) It seems that we can use File type for our purpose. We can set up it via API or UI . So, let's do that! Go to project's Settings > CI/CD . There will be Variables section (btw, you can specify variables also per group and even for all projects (in admin panel)). Click Add Variable button and add a variable: Key: ...
Read more

GitLab - trigger keyword

Image
 We are going to talk about the trigger keyword today. With this feature you can define a downstream pipeline trigger. So, you can trigger a pipeline in any project (you must have access to this project of course). There are two types of downstream pipelines: multi-project pipelines child pipelines  Let's omit child pipelines and have a look at multi-project pipelines. It is very easy to use. You just need to provide a path to the project and that's it. Remember that you only can trigger a pipeline, not a job ! You can also provide more information like environment variables. As always, I am going to provide some examples, so you will understand it better. The first example: you want to trigger a pipeline in another project after the deployment of your service/s. How to do that? Here we want to trigger this pipeline (project my/run-tests ). Let's say that we want to run some tests after each deployment: We need to add the job which will trigger this pipeline in my/run-...
Read more