Kubernetes architecture: In a Nutshell
Kubernetes architecture is purely API-driven. The cornerstone of Kubernetes is the reconciliation loop, which has at its core the controller pattern that helps in achieving and maintaining the desired state.
The Kubernetes API makes a distinction between the specification of the desired state of an object (a nested object field called spec) and the current status of the object (a nested object field called status).
Almost every Kubernetes object includes two nested object fields that govern the object’s configuration: the object spec and the object status.
The status describes the current state of the object, supplied and updated by the Kubernetes system and its components, you can check the status field of a Pod object, by running:
# check status for pods in all namespaces
kubectl get po -ojsonpath='{.items[*].status}' -A | jq .If you inspect the status structure you can observe the phase field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. If you want a quick holistic view concerning the pod phases in the cluster, a nifty trick is to leverage the field-selector flag:
# get all failed/pending/completed pods in all namespaces
kubectl get po --field-selector=status.phase!=Running -AA Kubernetes object is a “record of intent” — once you create the object, the Kubernetes system will constantly work to ensure that the object exists and has the desired state.
For instance, a deployment object that has as a spec the desired replicas set to 3. Therefore even if someone deletes one of the pods, Kubernetes will spin up another one, because it wants to converge to the desired state for the specified workload (nginx in this case).
The main takeaway to remember is that the desired state means how the application should function once running, and the true challenge lies in “drift” detection. For another view concerning Kubernetes architecture check…Probing Kubernetes architecture.
