Skip to content



Kubernetes (or K8s) is an Orchestration system primarily used for running containerized Cloud-native applications in the cloud (AKA other peoples’ computers over the internet).

As the as-of-now de-facto solution for deploying cloud apps, Kubernetes can be thought of as the “operating system of the cloud”. Like a physical server’s operating system provides software abstractions over the hardware resources and manages processes, Kubernetes abstracts cloud resources and manages cloud-native application services.

Kubernetes accomplishes orchestration by providing a cluster of nodes which can run containerized applications. The cluster is managed by the “control plane”, which makes decisions regarding cluster events, pod management, scheduling, and more.


Kubernetes originated from a number of first-party projects at Google which were used to orchestrate Google’s apps (such as the Search platform) at scale. These internal container orchestration solutions (specifically, Borg and then Omega) became increasingly relevant as Google attempted to compete with AWS in the cloud-computing solutions market. Google used its internal solutions to craft the Kubernetes project, a generalized cloud orchestration solution. In 2014, Google open-sourced Kubernates and donated it to the Cloud Native Computing Foundation.

The name “Kubernetes” originates from the Greek word for “helmsman”, and the logo of Kubernetes is, appropriately, an old ship’s helm.



A Kubernetes cluster is a set of nodes.


A Kubernetes node is a server (virtual or physical) which contains a Container engine runtime (such as Docker) as well as a kubelet (monitors status and health of containers) and a kube-proxy (network proxy for managing communication). A node is able to run pods.


A kubelet is a component of a given node which monitors the health of containers running on that node according to the PodSpecs.


A kube-proxy is a component of a given node which supports network communication between pods in the cluster or to cluster pods from outside applications.


Pods are the most granular abstraction in Kubernetes. A pod is a set of one or more containers which share common resources as well as a PodSpec which governs how the containers are initiated, monitored, and managed. Since a pod provides a shared runtime environment and specification for its containers, the “pod” concept is analagous to a Virtual machine.

Normally, pods simply run containers which run applications. However, there are some special types of containers which can also be useful.

Init containers

Init containers run before normal application containers within the pod runtime, enabling setup scripts and configuration tasks prior to initializing the application containers. Init containers are like && scripts: each container must run and complete successfully before the next task on the pod may start.

Ephemeral containers

Ephemeral containers are not run with the purpose of executing an application, but rather with the purpose of inspecting or debugging an existing pod application. Ephemeral containers should not be used directly for building applications. Ephemeral containers may be useful for troubleshooting when conventional strategies, such as shelling into a crashed application container with kubectl exec, aren’t possible.

Control plane

The control plane is responsible for managing the cluster. It’s composed of components which accomplish tasks such as scheduling, cluster event handling, and more.


Also known as the “API server”, kube-apiserver exposes the Kubernetes API to the rest of the control plane. It can scale horizontally as needed to handle requests from the other control plane components.


etcd is a consistent destributed key-value store for the cluster made to store small amounts of data in RAM.


When pods are created, they need to be assigned to a node so that they can run. kube-scheduler handles this assignment while taking resource needs and availability, among other factors, into consideration.


The kube-controller-manager is a single process which actually runs multiple operations in order to monitor the cluster state (via the API server) and perform support tasks as needed. For example, the kube-controller-manager contains a “node controller” which monitors nodes and responds accordingly. It also contains one or more “service account & token controllers” which handle the creation of accounts and API tokens for newly created namespaces.


The cloud-controller-manager handles all communication with the cloud provider, acting as an adapter between the cluster and the cloud provider. Conceptually, this segregates the cloud provider interface from the cluster interface. The cloud-controller-manager, like the kube-controller-manager, runs as a single process which executes multiple controller operations according to the cloud provider interface.

Controllers which may run on the cloud-controller-manager include:

If there is no cloud provider, for example in a private local cluster or learning environment, there is no need for a cloud-controller manager.


Kubernetes provides various useful cluster addons. Examples of addons are cluster DNS (provides a convenient domain name server for cluster services) and cluster-level logging for aggregating all container logs on a given cluster.