Find Deprecated APIs in Your Kubernetes Apps

Kubernetes’ rapidly evolving ecosystem regularly introduces new features and removes outdated features. Managing applications in this ecosystem can be highly complex, with multiple components and elements to keep track of. Further, upgrading to a newer version is often filled with risks.

Proper management of version upgrades can help prevent compatibility issues, security breaches, and operational inefficiencies caused by deprecated APIs. These issues can sometimes lead to overlooked important details, such as staying current with best practices or identifying deprecated elements in your deployments.

If you've ever encountered problems related to using deprecated APIs, Kubert is the ideal solution.

What is kubent?

Kube No Trouble (Kubent) is a tool that helps you identify your Kubernetes clusters for deprecated APIs. By configuring and running Kubert, you can detect which resources in your cluster are using deprecated APIs based on your deployments. This lets you take proactive steps before upgrading your Kubernetes cluster to a new version.

Why Do Deprecated APIs Matter?

When a new version of the Kubernetes API gets released, the old version is marked as “deprecated” and eventually removed in later versions. If your applications depend on these APIs, they may break or create an error when the Kubernetes cluster is upgraded. If the APIs have unfixed vulnerabilities, this can lead to multiple issues, such as downtime, increased maintenance attempts, or even security risks.

Challenges in Finding Deprecated APIs

Deprecated APIs can be difficult to locate, especially in complex architectures like Kubernetes. Here are a few common challenges to finding the deprecated APIs:

• Continuous Monitoring: Since API deprecation is a continuous process, developers must monitor it and update their codebase often to reflect the most recent changes.
• Identification Complexity: Some deprecated APIs may not be conveniently defined in a single location. As a result, developers may rely on various documentation, release notes, or community forums to find this information.
• Maintenance Activities: Managing deprecated APIs can be time-consuming and resource-intensive, involving extensive code restructuring. 

Let’s dive into how to use kubent with Testkube for automated testing on your Kubernetes clusters!

Setting up kubent with Testkube

Testkube and kubent can be integrated to automate the detection and remediation of deprecated APIs, thus ensuring that your applications are compatible with future Kubernetes versions. 

Testkube is a Kubernetes test execution and orchestration framework that integrates with any CI/CD system and testing tool. It allows teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging Kubernetes' capabilities to eliminate CI/CD bottlenecks and perfect their testing workflow.
‍
Let’s see how it works by putting it in action with Testkube to perform automated tests on your Kubernetes clusters!

Prerequisites

• Get a Testkube account.
• Kubernetes cluster - we’re using a local Minikube cluster.
• Testkube Agent configured on the cluster.

After meeting the prerequisites, you can launch a target Kubernetes cluster with a configured Testkube agent.

Creating a Service Account

We'll create a ServiceAccount for kubent to ensure it has the necessary permissions to list and read all of the resources in your cluster when looking for deprecated APIs. To do so, create a ServiceAccount and a ClusterRoleBinding for it:

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:

kubectl apply -f kubent-sa.yaml

And we're done! We can begin creating and running our kubent tests in Testkube to identify deprecated APIs.

Creating a Test Workflow

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. Once you have the Testkube setup, we can begin creating a Test Workflow for the kubent.

Here, we'll go over the steps for creating and understanding a kubent Test Workflow.

Navigate to the test workflow section and click the “Add New Test Workflow” button. 

A "Create a Test Workflow" dialog appears, providing you with four options to create a test workflow:

• Create from Wizard: This option displays a dialog box that guides you through creating a new test workflow. 
• Start from an Example: This option allows you to use a pre-configured example, such as k6, Playwright, Cypress, Playwright, or Postman.
• Combine Existing Workflows: This option allows you to combine and run various existing test workflows sequentially or simultaneously.
• Import a Workflow from YAML: This option allows you to import a test workflow using a YAML definition.

Create this workflow by choosing the “Create from Wizard” option.

Enter the following information into the designated field of the “Name & Type” tab:

1. Name: This field allows you to specify the test workflow's name. In this field, we will use the name "kubent-testkube."
2. Labels: Use this field to label test workflows for filtering purposes. (Optional)
3. Template: Choose Custom Template from the list of options, which includes Artillery, Cypress, JMeter, k6, and others.
4. Image: This field identifies the Docker image executing the test workflow. Here, we will use the “ghcr.io/doitintl/kube-no-trouble.”
5. Tag: This field specifies the version or specific build of the Docker image to use. Here, we have set the "Tag" field to "latest," signifying that the workflow will use the most recent version of the "ghcr.io/doitintl/kube-no-trouble" Docker image.
6. Shell Command: This command “/app/kubent” executes the tool ”kubent” located in the “/app/” directory within the container.

Click Next.

In the Content tab, click “No content” from the drop-down because we have specified the shell command.

Click Next.

In the Run tab, provide the following information:

1. Execution Working Directory: We have set the directory to "/data," which indicates the execution location for the tests.
2. Artifacts: This field allows you to specify the output files or directories that the test will generate.
3. Environment Variables: You can use environment variables to pass configuration or secrets necessary for test execution.

Click Next. The Summary tab will appear, displaying the spec file created.

The entire workflow specification is provided in YAML format. Click the "Create & Run" button to establish and execute the test workflow.

Executing the Test Workflow

When you click "Create & Run," the test workflow will begin to execute.

To view real-time progress and logs, click on each test procedure step.

You can notice that the test has passed successfully, and no deprecated APIs are found on our cluster. However, If your cluster has any deprecated APIs, Kubent will display the following output:

6:25PM INF >>> Kube No Trouble 'kubent' <<<
6:25PM INF Initializing collectors and retrieving data
6:25PM INF Retrieved 103 resources from collector name=Cluster
6:25PM INF Retrieved 0 resources from collector name="Helm v3"
6:25PM INF Loaded ruleset name=deprecated-1-16.rego
6:25PM INF Loaded ruleset name=deprecated-1-20.rego 
__________________________________________________________________________________________
>>> 1.16 Deprecated APIs <<< 
------------------------------------------------------------------------------------------
KIND         NAMESPACE     NAME                    API_VERSION
Deployment   default       nginx-deployment-old    apps/v1beta1
Deployment   kube-system   event-exporter-v0.2.5   apps/v1beta1
Deployment   kube-system   k8s-snapshots           extensions/v1beta1
Deployment   kube-system   kube-dns                extensions/v1beta1
__________________________________________________________________________________________
>>> 1.20 Deprecated APIs <<< 
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME           API_VERSION
Ingress   default     test-ingress   extensions/v1beta1

Automating kubent Tests with Testkube

Testkube allows us to either schedule or trigger our tests based on various events. To schedule it to run regularly, you can use the scheduling engine for Kubernetes Cron jobs; check out our documentation for a step-by-step guide.

Remove Deprecated APIs from your Kubernetes Cluster with kubent and Testkube

Managing deprecated APIs in Kubernetes is critical to ensuring a stable and future-proof environment. Regular scans and proactive updates will help you avoid deprecated APIs' downtime and security risks. In this blog post, we explored how to set up and run kubent tests within Kubernetes using its executor and Testkube, making it easy to stay on top of deprecated APIs in your environment. 

Why not give it a go yourself? Sign up to Testkube and try one of our examples, or head over to Testkube documentation—if you get stuck or have questions, we’re here to help each out to us on Slack. We’re eager to hear how you use our kubent integration.