Kubernetes Architecture === A note about this chapter: This chapter is akin to drinking water from the proverbial firehose. Don't focus on memorizing every detail, at first. Instead, bookmark this chapter in your mind (and your browser) for future reference. The **most important** thing to remember from this chapter is the next paragraph. #### Kubernetes architecture is simple: 1. Kubernetes is made up of Clusters. 2. Each Cluster is composed of only two components: the Master Node and a set of 1 or more Worker Node(s). Worker Nodes are usually a self-sufficient instance of your application. 3. Nodes contain Pods. A Pod is the smallest possible divisibe unit in Kubernetes. A Pod is usually an instance of a microservice that helps compose an instance of your application. 4. Containers live on Pods. Most Pods house 1 container (1 instance of the application). Pods may house more than 1 container; these additional containers are present to support the instance of the application (e.g. sidecar, logging). Kubernetes Architecture Overview -- Here is the architecture of a Kubernetes Cluster provided by the [Official Kubernetes Documentation](https://kubernetes.io/docs/concepts/overview/components/). Come back and refer to it when you're trying to figure out how certain parts of the architecture fit into the big picture. > Note: `Kubernetes Minions` (bottom-right of diagram) and Worker Nodes are the same thing. ![](https://i.imgur.com/2ZSC1eo.png) [The New Stack's blog post](https://thenewstack.io/kubernetes-an-overview/) does a great job breaking down the Kubernetes architecture in detail. The following images were provided by them. > This image shows us where cluster managers and container orchestration engines (read Kubernetes) fits into the overall server architecture for a typical setup: ![](https://i.imgur.com/KOQKXL4.png) > Here is a different interpretation of the overall Kubernetes architecture from [The New Stack](https://thenewstack.io/kubernetes-an-overview/). **In the image below, the UI and CLI are for querying Kubernetes for information about the Pods. These interfaces are not for interfacing with the application, that will come later**: ![](https://i.imgur.com/Fwr02g4.png) Kubernetes is composed of the following: * **UI:** A GUI for interacting with Kubernetes, typically custom-made. Common features include: ability to manually provision application instances, manual scalability, manual secrets management, and many more. * **CLI:** The Command Line Interface for interacting with the Kubernetes API. These, too, can be custom-made, however Kubernetes supplies a robust CLI called `kubectl`. Useful for developer productivity and script compatibility. * **API:** Kubernetes exposes an API for interacting with your cluster(s). As a developer, you will not be manually managing application infrastructure, but instead instructing K8s on how to manage your infrastructure for you. * **Kubernetes Nodes (Master and Workers):** More detail below. Kubernetes Master Node -- > Here we see the architecture of the Kubernetes Master Node: ![](https://i.imgur.com/B21H3Jp.png) The K8s Master Node is composed of the following: * **[API Server](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/):** Also known as the `kube-apiserver`. All external (Ingress and Egress), whether it's communication with the Master Node (e.g. application instance scaling) or with a Pod (instance of your application) is routed through the `kube-apiserver`. All inter-cluster communication (e.g. Pod A sends a message to Pod B) is routed through the Master Node API Server. * **[Scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/):** Also known as the `kube-scheduler`. The `kube-scheduler` is the default scheduler that watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, the scheduler becomes responsible for finding the best Node for that Pod to run on. The scheduler reaches this placement decision based on a set of rules that will be discussed in detail later on. K8s users have the option of utilizing the `kube-scheduler` to create their own Schedulers for the Master Node to use. * **[Kube Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/):** Also known as the `kube-controller-manager`. A daemon responsible for regulating and enforcing the desired state of the cluster. The `kube-controller-manager` utilizes the `apiserver` to monitor and enforce the desired state of the system on a per-Pod basis via `controllers` (e.g. replication controller, endpoints controlller, namespace controller, and serviceaccounts controller). * **[Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/):** Also known as the `cloud-controller-manager`. A daemon responsible for communication with cloud infrastructure providers in regards to authn/z and infrastructure provisioning. Each cloud infrastructure provider is responsible for providing their own `cloud-controller-manager`. The K8s user is responsible for implementing their cloud provider's `cloud-controller-manager`. * **[etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/):** Utilizing redundancy, `etcd` provides a key-value store with consistency and high-availability. K8s utilizes `etcd` to store cluster data. Kubernetes Worker Node -- > Here we see the architecture of a single Kubernetes Worker Node: ![](https://i.imgur.com/XmG6L5J.png) The K8s Worker Node is composed of the following: * **[Image Registry](https://kubernetes.io/docs/concepts/containers/images/):** The Image Registry is not actually part of the K8s Worker Node. In fact, the Image Registry lives outside of Kubernetes altogether. However, each Pod pulls images to buid its containers from the Image Registry. The containers are built via their respective container specs (e.g. [Dockerfile](https://docs.docker.com/engine/reference/builder/)) which are specified on the Pod's `PodSpec`. * **[Pod(s)](https://kubernetes.io/docs/concepts/workloads/pods/pod/):** A Pod is usually a single instance of one of your applications or services. When you scale this up or down you are scaling your application up or down. The Kubernetes documentation does the best job at describing a Pod: > A group of one or more containers (such as Docker containers), with **shared storage/network**, and a specification for how to run the containers (PodSpec). A Pod’s contents are always **co-located and co-scheduled, and run in a shared context**. A Pod models an application-specific “logical host”... in a pre-container world, being executed on the same physical or virtual machine would mean being executed on the same logical host. * **[Container Runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/):** Software used to run a container (e.g. Docker, cri-o, and rkt). * **[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/):** Brain of the Worker Node. The `kubelet` ensures the Node contains the right number of the correct Pods and that those Pods are running according to their `PodSpec`. * **[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/):** Service on each Node that handles Ingress and Egress as defined by the K8s API. * **[Fluentd](https://docs.fluentd.org/v/0.12/articles/kubernetes-fluentd):** From the Fluentd documenation: > Logging agent that take cares of log collection, parsing and distribution. Resources for This Chapter --- [Container Runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) [Docker File Documentation](https://docs.docker.com/engine/reference/builder/) [Fluentd](https://docs.fluentd.org/v/0.12/articles/kubernetes-fluentd) [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) [Kubernetes API Server](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) [Kubernetes Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/) [Kubernetes Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) [Kubernetes etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) [Kubernetes Images](https://kubernetes.io/docs/concepts/containers/images/) [Kubernetes Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/) [Kubernetes Scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/) [Official Kubernetes Documentation: Components](https://kubernetes.io/docs/concepts/overview/components/) [The New Stack: Kubernetes Overview](https://thenewstack.io/kubernetes-an-overview/)