Static pods are like regular pods, except they are managed by the kubelet service on a node and not the API server. The kubelet creates a mirror pod on the API server, which is a read-only copy that allows the pod to be seen on the API server but not controlled. The kubelet service is responsible for managing the state of the pod and controlling restarts, for example. The kubelet process watches the location specified with the configuration parameter --manifest-url or --pod-manifest-path.

A DaemonSet is an object which ensures that there is a copy of a pod running on each node. This type of object is commonly used to deploy pods which provide a management service, such as log collection daemons or monitoring daemons to provide data to a solution such as Prometheus. The scheduler places a copy of the pod specified in a DaemonSet on all eligible nodes within the cluster.

Labels are a key/value formatted peice of metadata attached to an object within Kubernetes. Labels provide additional information about the object with relevance to the consumer or object. For example, a label can specify hardware characteristics of a node or if a workload is for testing of production. Labels implicitly group like objects together while providing a lookup mechanism for users, controllers and external systems. For this example, I have a deployment for a web service which runs on internal infrastructure and one which runs on DMZ infrastructure.

I’ve recently started learning Kubernetes, working through the CKA curriculum and performing various administrative tasks. During my study so far, I have found that there are a lot of manual steps involved when looking at an end to end process. Often the process required to achieve an outcome requires the same data to be entered in multiple places, for example, labels and selectors. A process which I have found to be overly manual and prone to misconfiguration is user management.