Kubernetes is a container orchestrator that aims to decouple the underlying compute resources from logical application deployments. It's open source software, written in Go (Private). It was originally developed by Google, and it's governed by the Cloud Native Computing Foundation.

It's built on the lessons learned from the Borg and p.r.comp.google.omega (Private) platforms Google uses to maintain its production workloads, but isn't a direct descendent.

The name Kubernetes, often abbreviated to K8s, comes from the Greek word for "Helmsman", κυβερνήτης (kyvernítis), though its name was originally Seven of Nine in reference to a rescued Borg drone. The seven spokes in the logo are a reference to the former name.


  • Enhanced developer experience:
    • Accelerate developer on-boarding through common infrastructure.
    • More accurate, and easier, emulation of production.
  • More reliable operations:
    • Codified deployments are easy to move between environments.
    • Managed deployment model with automated rollout and versioning.
    • Deployments can be made self-healing.
    • Easier scaling, as the underlying compute is decoupled from the logical view of a deployment.


flowchart LR Client[kubectl] CloudPlatform["Cloud platform (AWS, Azure, GCP, etc.)"] subgraph ControlPlaneNodes[Control plane nodes] ApiServer[kube-apiserver] ControllerManager[kube-controller-manager] Scheduler[kube-scheduler] ControlPlaneNodeKubelet[kubelet] ControlPlaneNodeProxy[kube-proxy] Etcd[etcd] CloudControllerManager[cloud-controller-manager] ApiServer <--> ControllerManager ApiServer <--> Scheduler ApiServer <--> ControlPlaneNodeKubelet ApiServer <--> Etcd ApiServer <--> CloudControllerManager ControlPlaneNodeKubelet --> ControlPlaneNodeProxy end subgraph WorkerNodes[Worker nodes] WorkerNodeKubelet[kubelet] ContainerEngine["Container engine (CRI-O, containerd, Docker)"] WorkerNodeProxy["kube-proxy"] Iptables["iptables/eBPF"] WorkerNodeKubelet <--> ApiServer WorkerNodeKubelet <--> ContainerEngine WorkerNodeProxy <--> ApiServer WorkerNodeProxy --> Iptables end CloudControllerManager <--> CloudPlatform Client -- "REST API call" --> ApiServer

Kubernetes clusters are made up of a series of nodes which are maintained by the control plane. Clusters are made up of two types of nodes, each specialised for a role:

  • Master nodes, head nodes, or control plane nodes run the control plane and are responsible for managing the state of the cluster.
    • The API Server exposes a REST API for interacting with the cluster control plane, both for kubelets and external clients. This is the sole component which directly communicates with etcd.
    • The Controller Manager performs control loops, communicating with the API Server, determining changes that need to be made to make the cluster's actual state reach the goal state.
    • The Scheduler is forwarded the Pod spec and uses it to bind Pods to Nodes.
  • Worker nodes, often referred to as workers or just nodes and previously known as minions, execute containers.
    • The kubelet is the agent responsible for reporting node state and requesting work from the control plane.
    • Container runtimes execute the containers.

All Nodes, regardless of role, are responsible for their own networking.

  • kube-proxy configures the node's host firewall (a backend) to enable traffic to be routed to services in line with Services' endpoints.

Release cycle

  • New major release every four months.
  • New minor releases approximately every ten days.


Configuration is stored in etcd.


See controllers.


Kubernetes stores its view of the desired state as a series of related objects. Objects can reference other objects via selectors targeting their labels. The creation of an object can trigger Controllers which will create additional objects, forming a common use case for CRDs.

Objects are identified through several means:

  • A unique name assigned at creation time.
  • A unique server-generated object ID.
  • A parent namespace is used to create security, naming/organisational and resource allocation boundaries. Not all objects are namespaced!
  • Labels contain data used to locate objectsL e.g. for administration of the cluster, matching pods to controllers and matching pods to appropriate nodes when scheduling.
  • Annotations are used by people and tooling to make decisions about objects. It's commonly used to embed information from external sources (e.g. source code management or build tools containing versioning information) to make the cluster self-contained and avoid integrations. Unlike labels, it's not possible to search for objects by annotations.

Objects can be defined either statefully using manifests or imperatively via the CLI.

Some common objects are defined in:


See namespaces.


See networking.

Cluster setup

Different deployment tools are used to deploy Kubernetes to different environments:

  • `kubeadm` is best suited to deploying on bare metal, and is general enough to be usable in most settings.
  • kops currently only supports AWS.
  • AKS Engine can be used to deploy to Azure.
  • Minikube configures a single-node deployment for use in development environments.
  • Docker Desktop embeds a single-node Kubernetes cluster for use in development environments.
  • kind sets up a Kubernetes cluster using Docker containers to host Nodes, and is geared towards testing Kubernetes itself.


`kubectl` is the administrative client for Kubernetes.

  1. API Server
  2. Annotations
  3. Authentication
  4. Cluster API
  5. Configuration
  6. Container Runtime Interface
  7. Control plane
  8. Controllers
  9. Dashboard
  10. Federation
  11. Ingress
  12. Kubeconfig
  13. Labels
  14. Manifests
  15. Namespaces
  16. Networking
  17. Resources
  18. Scheduler
  19. Secrets Store CSI Driver
  20. Selectors
  21. Utilities
  22. kube-proxy
  23. kube-vip
  24. kubelet