This quick video explains how you configure Kubernetes pods to control Kubernetes itself with raw API calls.
Most users interact with Kubernetes using kubectl. kubectl itself is a sophisticated wrapper for “curl” and communicates with a Kubernetes cluster’s API server. Using the -v flag followed by a number tells kubectl to show the exact call being made to the API server.
Using the -v flag shows information like:
- The method used in the call
- The URL endpoint for the intended resource
- Any headers passed with the request
- Any data being sent in the request in the body
In this video, we’ve illustrated a PATCH request. An example scenario for a script like this would be to have a pod update something about itself or even change the number of replicas like we did with 1 way autoscaling, provided the appropriate RBAC permissions have been assigned to the Pod’s Service Account.
Users can construct scripts using this information that allow containers within each pod to send a request to the cluster API server without installing the kubectl client. Command line tools like wget or curl are widely available to most containers running in Kubernetes pods. These scripts also have access to other information about the pod, like the service account and/or certificates, which are used to authenticate requests.
Once the script is developed, users must mount the script to each container in a pod that wants to use it. This can be done at container build time or more dynamically during Kubernetes deployment. We show that scripts like patchme.sh can be loaded to a cluster as a configMap. The configMap is then mounted to one or more containers in a pod as a volume. This makes the script available to any container with a mounted configMap.
Whether called by an initContainer or a Container Lifecycle hook, containers inside the pod can now execute the script and control Kubernetes!