Ajeet Raina I am a Docker Captain, ARM Innovator & Docker Bangalore Community Leader. I am a maintainer of Collabnix blogging site. I work for Docker as a full-time employee. I run Collabnix Community Slack with over 6500+ audience . We have built a popular projects like Docker Labs, KubeLabs, KubeTools and DockerTools. You can follow me on Twitter(@ajeetsraina) & GitHub(@ajeetraina)

A Quick Look at the Kubernetes API Concepts

2 min read

The core of Kubernetes’ control plane is the API server and the HTTP API that it exposes. The Kubernetes API is the front end of the Kubernetes control plane and is how users interact with their Kubernetes cluster. Users, the different parts of your cluster, and external components all communicate with one another through the API server. The Kubernetes API lets you query and manipulate the state of API objects in Kubernetes (for example: Pods, Namespaces, ConfigMaps, and Events). The API directly using REST calls. Both human users and Kubernetes service accounts can be authorized for API access.

In the latest Kubernetes v1.23, there are three significant changes from api-machineryCLI, and autoscaling SIGs that were introduced. It introduces a brand new feature in alpha: events. Highly useful for users who wants to filter different types of events when observing their clusters.

kubectl events

With this newer Kubernetes release, Horizontal Pod Autoscaler (HPA) graduated to General Availability. HPA is the central component of Kubernetes that automatically scales the number of pods based on metrics. HPA can scale up or down many resources, such as replica sets, deployments, or stateful sets with well-known metrics like CPU utilization. It has been part of the Kubernetes API since 2015, and it’s finally graduating to general availability (GA).

The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP. It supports retrieving, creating, updating, and deleting primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET). When accessing the Kubernetes API for the first time, use the Kubernetes command-line tool, kubectl. To access a cluster, you need to know the location of the cluster and have credentials to access it.

Checking the location & credentials

[node1 kubelabs]$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.0.18:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate

Directly accessing the REST API

The kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an HTTP client like curl or wget, or a browser, there are multiple ways you can locate and authenticate against the API server:

  • Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
  • Provide the location and credentials directly to the HTTP client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you’ll need to import a root cert into your browser. Using the Go or Python client libraries provides accessing kubectl in proxy mode.

Using kubectl proxy

The following command runs kubectl in a mode where it acts as a reverse proxy. It handles locating the API server and authenticating.

kubectl proxy --port=8080 &

Then you can explore the API with curlwget, or a browser, like so:

curl http://localhost:8080/api/

The output is similar to this:

[node1 kubelabs]$ curl http://localhost:8080/api/
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.0.18:6443"
    }
  ]

Without kubectl proxy

  # Check all possible clusters, as you .KUBECONFIG may have multiple contexts:
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'

# Select name of cluster you want to interact with from above output:
export CLUSTER_NAME="some_server_name"

# Point to the API server referring the cluster name
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")

# Gets the token value
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)

# Explore the API with TOKEN
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Further Reference:

Have Queries? Join https://launchpass.com/collabnix

Ajeet Raina I am a Docker Captain, ARM Innovator & Docker Bangalore Community Leader. I am a maintainer of Collabnix blogging site. I work for Docker as a full-time employee. I run Collabnix Community Slack with over 6500+ audience . We have built a popular projects like Docker Labs, KubeLabs, KubeTools and DockerTools. You can follow me on Twitter(@ajeetsraina) & GitHub(@ajeetraina)