How do I list non-Helm API Deprecations?

[k8s42]

I just discovered Pluto while Googling around how to easily find out which APIs in use in my cluster have been deprecated. We will be upgrading from 1.15.x to 1.16.x soon. The "detect-helm" example is useful and is self-explanatory. However, I am trying to figure out how to scour my entire cluster using Pluto to see which deployments, resources (storage classes, etc.) are using deprecated APIs that I need to update. Can someone please share some examples I can use as a reference?

[sudermanjr]

That's a great question and is probably best answered in our readme in the first section.

Basically, there isn't a 100% reliable way to detect in cluster. That's why we provide file detection.

In the end, the important thing is that you're not actively trying to deploy removed apiVersions. Versions running in the cluster already are not at risk because the api server converts them.

There's also more info in our launch blog article - https://www.fairwinds.com/blog/kubernetes-easily-find-deprecated-api-versions-with-pluto

[k8s42]

Thank you, @sudermanjr. So, that is indeed I am trying to understand. What are the "files" in the following command:

pluto detect-files -d pkg/finder/testdata

[sudermanjr]

Those are any yaml or json manifests that contain Kubernetes object definitions.

[k8s42]

So, as a test, I exported ingress extensions to a YAML file as follows:

kubectl get ingresses.extensions -A --all-namespaces -o yaml>ingressesextensions.yaml

Then I ran the following command against the directory where ingressesextensions.yaml file is stored:

pluto detect-files -d /home/k8s42/

I received the following response:

There were no resources found with known deprecated apiVersions.

However, in the ingressesextensions.yaml file, I do see deprecated APIs listed:

- apiVersion: extensions/v1beta1
  kind: Ingress

[k8s42]

With verbose logging:

./pluto detect-files -d /home/k8s42 --v 5

I0806 19:23:36.065074 94761 root.go:150] no additional versions needed I0806 19:23:36.221239 94761 finder.go:98] error scanning file /home/k8s42/pluto: yaml: control characters are not allowed There were no resources found with known deprecated apiVersions. I0806 19:23:36.221313 94761 root.go:233] retCode: 0

[estahn]

@k8s42 I've just gone through the Kubernetes 1.15 to 1.16 upgrade and had various tools similar to pluto (also wrote my own bash script). I found all have shortcomings.

Re kubectl get ..., it's technically not possible to revert the already applied manifest back to its original. However, you can use workarounds such as reading out kubectl.kubernetes.io/last-applied-configuration.

I used the following tools:

• https://github.com/doitintl/kube-no-trouble (looks at the different annotations and tries to reverse engineer the applied manifest)
• https://github.com/rikatz/kubepug (uses official swagger files to compare what is deprecated, which is a great approach imo – most projects use OPA rego files)
• https://github.com/FairwindsOps/pluto (just started testing it)

What I would like to see though is something like dependabot, that actively create a PR and tells the dev to fix it :)

[sudermanjr]

I0806 19:23:36.221239 94761 finder.go:98] error scanning file /home/k8s42/pluto: yaml: control characters are not allowed

This indicates that your yaml file didn't marshal correctly. Is that a raw yaml file, or is there something else in there? I can't really tell anything without knowing the contents of the file you are testing.

[lucasreed]

So, as a test, I exported ingress extensions to a YAML file as follows:

kubectl get ingresses.extensions -A --all-namespaces -o yaml>ingressesextensions.yaml

Then I ran the following command against the directory where ingressesextensions.yaml file is stored:

pluto detect-files -d /home/k8s42/

I received the following response:

There were no resources found with known deprecated apiVersions.

However, in the ingressesextensions.yaml file, I do see deprecated APIs listed:

- apiVersion: extensions/v1beta1
  kind: Ingress

This is not how we intend the tool to be used so currently it will not parse a list of items from the kubernetes API. It is meant to parse multiple yaml/json files in which you then post to the API (perhaps from a git repository), not from things you gather from the API.

The response you would have received would look like this:

apiVersion: v1
kind: List
items:
- <ingress_definition>
- <ingress_definition>

As discussed above, getting things from the API is not reliable, which is the main reason we don't support parsing this format.