Introduction to Kubernetes

Kubernetes Object Management Model

Before jumping into Kubernetes workloads (Pods, Controllers, etc.), it’s important to understand Kubernetes's declarative model. Kubernetes actually also has imperative modes, but we will focus on the declarative model and desired states. If you want to learn more, Sebastien Goasguen, the Kubernetes lead at Bitnami, has a great Medium article on the difference between the imperative vs. declarative modes.

In essence, when we write YAML or JSON files, we describe the desired state of the application: what Docker image should run, what scaling strategy to use, and what ports/services to expose. This information is posted to the kube-api-server, and the master node distributes the work to ensure that the cluster matches the desired state. This configuration is stored in etcd, and the workload is deployed onto the cluster. Finally, Kubernetes will constantly check to see whether the current state of the cluster matches the desired behavior the programmer has defined. So, if a pod dies, Kubernetes will fire up another one to match the desired state.

While this all sounds simple (and that was part of the intent), it's a powerful scheme that makes Kubernetes very useful. You (the programmer) only have to specify the desired state, and Kubernetes will take care of the rest (instead of having you run specific commands to achieve this like in imperative models).