Building stuff with the Kubernetes API

Kubernetes is a formidable platform on (and with) which you can create all sorts of tools. Fortunately, there are many options when it comes to programming against the Kubernetes APIs. These options, however, can be overwhelming which can leave potential developers with no clear directions.

In this series, will highlight the extensibility of Kubernetes as a platform. We will walkthrough the different options that are available when building solutions using the Kubernetes platform, from simple tools to extending Kubernetes with custom API types.

When building tools around Kubernnetes platform, it is important to understand the geography of its API landscape. Before we write any code, let us look at ways to explore and work with API objects directly without any programming languages (that will come in later posts). go through kuberetes online training and learn from expertes in an effective manner

An API-first architecture

A Kubernetes cluster is comprised of several loosely-coupled components. Central to the cluster is the API server which manages access to stored (versioned) objects that represent the state of the cluster.

API architecture

Control of the Kubernetes cluster can be achieved declaratively by creating or mutating existing objects (stored in etcd) that represent different aspects of Kubernetes. Cluster components and tools can observe these changes, in a reconciliation loop, and mutate the cluster itself until it reaches the desired state.

Accessing API objects with kubectl get

One of the easiest ways to see the guts of the Kubernetes API objects is to use the kubectl get command with the raw flag. This lets you to explore your cluster’s API landscape without the need of additional tools. For instance, you can issue the following command to get a list of all API paths on the cluster:

$ kubectl 
 get --raw /
 "paths": [    
 "/apis",    ...    

Using kubectl, you can explore all accessible objects for inspections. For instance, the following returns a NodeList resource which is a collection of all nodes represented in the cluster. The output of the command is piped to the Python json package for readability as shown (abbreviated). kubernetes certification training will help you to learn more.

Accessing the API server directly

With the proper setup, it is possible to access the API server directly over HTTP so you can use tool such as cURL, a web browser, or your favorite REST tool.

Using command kubectl proxy

If you need direct HTTP access to the API server, the recommended way is to use command kubectl proxy. The command sets up a proxy allowing authorized and authenticated access to the running API server. For instance, the following snippet starts the proxy to forward all requests to localhost port 8080 to the API server:

$ kubectl proxy --port=8080 &$ Starting to serve on

Once the proxy is running, it is possible to access the API server via HTTP using your favorite tool.

Direct server access

If using kubectl proxy is not an option, you can access the API server directly without proxied traffic. This implies, however, that you must provide the server with proper authorization credentials. To do this, we first scrape the the API server address and the default service account authorization token from Kubernetes using kubectl