How Kubernetes Works | Kubernetes Tutorial
Kubernetes runs on a cluster. A cluster is simply a collection of physical or virtual machines that run your applications.
When you deploy Kubernetes you get this cluster.
Worker nodes
Some of these machines act as "worker nodes". Worker nodes are the machines actually running your applications. Specifically, worker nodes host pods. These pods are collections of one or more containers. Pods share the same storage, ip address, and run on the same physical worker node.
Each worker node in the cluster run an agent called the kubelet. This process ensures containers are running properly in each pod.
This kubelet coordinates with the container runtime interface (CRI) for that worker node. If you've used Docker then you've worked with a CRI.
Another kube-proxy process also runs on each worker node in the cluster. This process manages network connections both internally and externally.
Control plane
Other machines in the cluster host the control plane. The control plane is responsible for managing the worker nodes.
The control plane is a collection of components that manage the cluster. While these components can be hosted by different machines in the cluster they are typically deployed on the same node for convenience.
Among these components is the kube-api-server. This component presents a front-end interface for managing objects in the cluster.
The kube-api-server
When you use the Kubernetes CLI kubectl or a client library for connecting to Kubernetes you are interfacing with the kube-api-server
The kube-api-server is designed to scale horizontally. This means you can run multiple instances of the kube-api-server and load balance traffic to scale your cluster.
Kubernetes Objects
Using the kube-api-server allows you to create, modify, and delete Kubernetes objects. These objects include deployments, services, replicatSets, volumes, etc. and are used to describe the desired state of your system.
For example, you can define a Kubernetes deployment object with a replica set of 3. When you create this object, Kubernetes deploys 3 replicas of your containerized application. If one of these replicas goes down, Kubernetes will spin up another replica if possible.
The data backing all of these objects is stored in a high availability key/value store etcd. While fundamental to Kubernetes internal storage, etcd is not native to Kubernetes and is more generally used as a means of storing information on a distributed system.
When new pods are created, the kube-scheduler evaluates resource requirements and other specifications to determine what worker node runs the pod.
Similarly, the kube-controller-manager includes a node controller for managing when worker nodes go down.M.
Likewise, the replication controller manages replication, an endpoint controller joins services and pods, and a service account controller manages secrets and tokens for the cluster.
A cloud controller is also responsible for interfacing with cloud providers. Vendors like Amazon (AWS) and Google (GCP) use the cloud controller to integrate with your own cluster. Note that the cloud controller is only necessary when using a third party vendor with your Kubernetes instance.
Conclusion
Kubernetes runs on a cluster of machines. Some of these machines act as worker nodes and others implement the control pane.
Remember that worker nodes actually host and run collections of containers called pods. Control plane components work together to manage the overall health and performance of the cluster.
Kubernetes exposes a client facing api server for interacting with the cluster. Using either the kubectl or other Kubernetes client libraries, you can create, modify, and delete Kubernetes objects.
These objects specify the desired state and status of the cluster. Kubernetes uses these objects to continuously achieve the desired state of your system.
