Programming Kubernetes

Kubernetes Rest API

Kubernetes has a REST API which can be used when creating tooling to work with Kubernetes.

Authentication

The following command will retrieve the token from service account in the “default” namespace:

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

That token can be used in HTTP requests by using it as a bearer token:

$ export TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
$ curl -X GET https://$API_SERVER_HOST:$API_SERVER_PORT/api --header "Authorization: Bearer $TOKEN" --insecure

Listing all pods from the default namespace:

$ curl \
-k \
-X GET \
--header "Authorization: Bearer $TOKEN" \
https://$API_SERVER_HOST/api/v1/namespaces/default/pods

You can list all availables openapi methods by running:

$ curl \
-k \
-X GET \
--header "Authorization: Bearer $TOKEN" \
https://$API_SERVER_HOST/openapi/v2

The PATH format follow the following criteria: /api/v1/namespaces/$NAMESPACE/$GROUP/$VERSION/$KIND (both $GROUP nd $VERSION can be omitted if it is a “core” component such as a pod).

When send POST data for a given resource, such as creating a POD, all you need to do is to transform the YAML resource definiton into json and send it in a POST request.

Kubernetes Controllers

The Operator SDK

URL: https://sdk.operatorframework.io/

The Operator SDK is a tool created and maintained by the CoreOS team.

The SDK faciliates the development of a custom kubernetes controller, including CRD management.

The SDK will create a pre-defined project structure for your operator (controller) and any CRD.

The Status Sub-Resource

You will notice that either your operator code or your CRDs will refer to the CR “status” as a sub-resource.

This means that the user provisioning that particular CR won’t be able to change the CR status, just the spec.

This is done this way so the status can only be changed by the operator (kuberntes will return an permission error if the user tries to change it).

This way the CR spec is where the user should input data while the CR status is where the operator should write its data based on what’s happenning the reconcile loop for that CR.

There are a few recommendations on what properties should be used in the status object from the upstream kubernetes community that is worth reading: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

KubeCTL Plugins

URL: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/

One can also create kubectl CLI plugins, this is useful in case you want to wrap a particular kubernetes integration in kubectl.

A plugin can be written in any languague as long as it can be executed (such as added in your PATH) and uses the following name format: kubectl-$plugin-subcommand.

Kubernetes will run kubectl-$plugin-subcommand when invoked as kubectl $plugin-subcommand, forwarding all arguments that were provided by the user.