As a DevOps Engineer, you’re likely well-versed in using Kubernetes. But did you know that Kubernetes actually has its own API? In this blog post, we’ll show you how to use the Kubernetes API and some of the benefits it can offer your workflow.
The Kubernetes API is a RESTful interface for querying the Kubernetes state. It provides an HTTP endpoint that enables you to query and manipulate data in your Kubernetes cluster. The API server exposes a set of resources that you can use to get information about your cluster or perform actions within it.
The Kubernetes API is the engine that drives a cluster.
The API is used for all actions within your Kubernetes cluster. The kubectl tool as a whole is just a wrapper around this API. When you execute kubectl apply, you are requesting that the control plane build your resources. This request is routed to the API, which then routes it to the appropriate internal services.
Kubernetes API benefits
Some of the benefits of using the Kubernetes API include:
- You can use the Kubernetes API to automate common tasks, such as rolling out updates or creating and deleting resources.
- You can use the Kubernetes API to get information about your cluster that is not available through the kubectl command-line interface. For example, you can use the API to get a list of all Pods in your cluster.
- You can use the Kubernetes API to debug problems with your cluster. For example, if you are having trouble accessing a resource, you can use the API to get more information about what is happening behind the scenes.
Using the Kubernetes API
There are numerous ways to connect with the Kubernetes API depending on your use case. Whether you’re creating an application that interacts directly with your cluster or simply want to explore the API’s capabilities, there’s an easy way to get started. Because you’re working with a REST API, having access and knowing the possibilities is more important than learning a new framework.
kubectl
The kubectl command is the simplest method to get started with the Kubernetes API:
kubectl proxy --port=8080Then you should be able to open your browser as long as the command is successful. Use:
curl http://localhost:8080To receive a list of various resources., use:
kubectl get --raw /To receive a response informing you of the paths that can be queried.
There are two significant differences between this approach and the standard kubectl get pods approach:
- Instead of a properly formatted result, the output is a JSON response.
- The API is not namespace-compliant. When you use the “raw” command to get pods, it returns all of the pods in your cluster.
Client Library
While it is possible to use the API directly, it can be more convenient to use a client library. Client libraries provide a higher-level abstraction over the raw API, making it easier to write programs that interact with Kubernetes. There are many different client libraries available for Kubernetes, each with its own strengths and weaknesses. When choosing a client library, it is important to consider the language that you will be using, the level of abstraction that you need, and the support that is available.
Kubernetes Operators
The language in which you write determines how you interact with the Kubernetes API. As discussed in the last section, you’ll most likely wish to use a client library. A client library can be used by any program to integrate with the API, but employing it in an operator is special.
Operators are often used to automate operations or to connect third-party technologies more deeply into your cluster.
An operator can be used to launch apps on demand. Kubernetes includes several options for how to deploy an application, but occasionally you have a unique use case.
Consider having a web UI where developers may spin up their own pods to ensure that the modifications they make work before merging them into the repository. In this situation, you might have an operator respond to an event and then launch the application in a pod.
Securing API Access
Now that you understand how to connect with the Kubernetes API, make sure you do so safely. The first step is to ensure that the API is not publicly accessible. You may believe that creating the necessary users and assigning the appropriate permissions is sufficient. That’s a wonderful first step towards securing your cluster, but IP-based security should come first.
There are numerous bots that are continually hunting for open Kubernetes APIs. As a result, your initial action should be to add the IP addresses you know your organization utilizes to an allow list. After that, you can begin establishing users and delegating permissions using Role-Based Access Control (RBAC). RBAC allows you to grant very granular rights, preventing your users from making modifications that are not strictly essential.
Then there are situations where you do not want to secure user access, but rather your program. It is possible to utilize the default service account, but you can also create your own. You should create a service account for each program and give it only the permissions it need. This is accomplished via Roles and RoleBinding, either by using the basic Roles provided in any Kubernetes cluster or by developing your own.
Conclusion
The Kubernetes API is a powerful tool that every DevOps Engineer should know how to use. By learning how to use the Kubernetes API, you can automate common tasks, get information about your cluster, and debug problems with your cluster.
