Find Deprecated APIs in Your Kubernetes Apps

Managing applications in a Kubernetes ecosystem is extremely complex - and having too many parts and elements to take care of can sometimes drift you apart from important details such as staying up to date with best practices or checking for deprecated elements. 

If you’ve ever run into issues that can be traced back to using deprecated APIs - I have the perfect solution for you: kubent.

Kube No Trouble (kubent) is a simple tool that helps you check your clusters for deprecated APIs. By configuring and running kubent, you’ll be able to detect these deprecated APIs based on your deployments and be alerted on whether you should upload your workload first before upgrading your Kubernetes cluster. 

Let’s see how it works by putting it in action with Testkube to perform automated tests on your Kubernetes clusters!

New here? Testkube is a test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, empowering teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging all the capabilities of Kubernetes to eliminate CI/CD bottlenecks, perfecting your testing workflow.

‍

## Setting up kubent with Testkube

To get started, you’ll need an instance of Testkube running in your cluster. If you haven’t already, sign up for free to get started today - or read our Installation Guide.

Now that we have Testkube up and running, let’s add kubent as an executor. We’ll do this by adding kubent’s Docker image (available at ghcr.io/doitintl/kube-no-trouble:latest):

```bash

testkube create executor --name kubent-executor --types kubent

--image ghcr.io/doitintl/kube-no-trouble:latest

```

Now, we’ll add a ServiceAccount for kubent, so that the tool is able to list all the resources in your cluster. To do that, you need to create a `ServiceAccount` and a `ClusterRoleBinding` for it:

```yaml

apiVersion: v1

kind: ServiceAccount

metadata:

  name: kubent

  namespace: testkube

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  name: kubent-reader

  namespace: testkube

rules:

- apiGroups: ["*"]

  resources: ["*"]

  verbs: ["get", "list"]

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: kubent-read-everything

  namespace: testkube

subjects:

- kind: ServiceAccount

  name: kubent

  namespace: testkube

roleRef:

  kind: ClusterRole

  name: kubent-reader

  apiGroup: rbac.authorization.k8s.io

```

Let’s apply our configuration:

```bash

kubectl apply -f kubent-sa.yaml

```

Now that we’ve done our initial setup, let’s update our Job template so we reference our new ServiceAccount. Testkube allows you to override the Job template that will be used to run the tests. By doing this, we can add the ServiceAccount to the Job:

```yaml

apiVersion: batch/v1

kind: Job

metadata: 

  name: "{{ .Name }}"

  namespace: "{{ .Namespace }}"

spec:

  template:

    spec:

      restartPolicy: Never

      serviceAccountName: kubent

      containers:

        - name: "{{ .Name }}"

          image: "{{ .Image }}"

```

With our changes, let’s update the executor we created at the beginning of this tutorial:

```bash

testkube update executor --name kubent-executor --job-template job-template.yaml

```

And done! We can start creating and running our kubent tests to find deprecated APIs. 

## Using kubent to detect deprecated APIs

Let’s create our test called `kubent-test`:

```bash

testkube create test --name kubent-test --type kubent

```

Moment of truth! Let’s run our recently created test to check for deprecated API versions:

```bash

testkube run test kubent-test

```

If you look at the logs of the Job, you should see something like this:

```bash

$ testkube watch execution kubent-test-1

‍

Getting logs from test job 64820fce90a243e72062576c

5:28PM INF Target K8s version is 1.27.1

5:28PM INF Retrieved 6 resources from collector name=Cluster

5:28PM INF Retrieved 69 resources from collector name="Helm v3"

5:28PM INF Loaded ruleset name=custom.rego.tmpl

5:28PM INF Loaded ruleset name=deprecated-1-16.rego

5:28PM INF Loaded ruleset name=deprecated-1-22.rego

5:28PM INF Loaded ruleset name=deprecated-1-25.rego

5:28PM INF Loaded ruleset name=deprecated-1-26.rego

5:28PM INF Loaded ruleset name=deprecated-future.rego

‍

.

Use following command to get test execution details:

$ kubectl testkube get execution 64820fce90a243e72062576c

```

So, how can we have this running automatically? Testkube allows us to either schedule or trigger our tests based on various events. To schedule it to run on a regular basis, you can use the scheduling engine for Kubernetes Cron jobs, check out our documentation for a step by step guide.

## Get rid of deprecated APIs in your Kubernetes cluster with kubent and Testkube

In this blog post, we took a look at how to set up and perform kubent tests within Kubernetes using its executor with Testkube - showing you how easy it is to stay on top of deprecated APIs in our environment.

Why not give it a go yourself? Sign up to Testkube and try one of our examples or head over to our documentation - if you get stuck or have questions, we’re here to help! Find an answer to your questions in the Testkube Knowledge Base or reach out to us on Slack. We’re eager to hear how you use our integrations!