What Is Kubernetes? Architecture, Objects and Uses

What Kubernetes is

Kubernetes, often written k8s, is an open source platform for managing containerized workloads and services. The project describes it as supporting both declarative configuration and automation. You write manifests that say what should exist, you submit them to the cluster, and controllers keep the running system in line with them.

The word cluster means the group of machines plus the software that manages them. From the outside, a cluster looks like one pool of CPU and memory that you deploy into. You do not pick the machine for each container by hand; the scheduler does that.

The problem it solves

One container on one server is simple. Production is different. There are many services, many copies of each, machines that fail, traffic that rises in the morning and falls at night, and releases that must not take the site down. Doing this with scripts and SSH sessions works until a node dies at 3 a.m. or two teams deploy to the same host on the same afternoon.

Kubernetes moves those decisions into a control loop. You state how many copies you want and what each one needs. The cluster places them on nodes with room, watches them, and acts when reality drifts from the plan. The core jobs it takes on are these:

• Scheduling: pick a node with enough free CPU and memory for each container.
• Self-healing: restart containers that crash or fail a liveness probe.
• Rollouts: replace pods gradually, and stop when new pods never become ready.
• Service discovery and load balancing: give a stable name and address to a set of pods that keeps changing.
• Scaling: change the replica count by hand, or let a HorizontalPodAutoscaler do it from metrics.

Where it came from

Kubernetes grew out of Borg, the internal cluster manager Google used for years to run its own production workloads. The Kubernetes project describes Borg as the predecessor and writes about the lessons the new system took from it. Google open sourced Kubernetes in 2014, and in 2015 it was donated to the newly formed Cloud Native Computing Foundation, which hosts the project today. The code is released under the Apache License 2.0, so the software itself costs nothing to use.

Architecture: control plane and nodes

A cluster has two kinds of machine. The control plane makes global decisions and stores the cluster state. Nodes, which are virtual or physical servers, run the containers. In a managed service the cloud provider runs the control plane and you run the nodes.

Control plane components

• kube-apiserver: the front door. kubectl, controllers and kubelets all talk to its REST API, and it is the component that reads and writes cluster state.
• etcd: a consistent, highly available key-value store that holds everything the cluster knows about itself.
• kube-scheduler: chooses the node for each new pod, using resource requests, constraints and affinity rules.
• kube-controller-manager: runs the controllers, loops that compare observed state with desired state and close the gap. Examples include the ReplicaSet and Job controllers.
• cloud-controller-manager: connects the cluster to a cloud provider API for things like load balancers and node lifecycle. It is present only when you run on a cloud.

Node components

• kubelet: the agent on each node. It makes sure the containers described in the pod specs are running and reports their status back.
• kube-proxy: maintains network rules on the node so that Service addresses reach the right pods.
• Container runtime: the software that actually starts containers, through the Container Runtime Interface. containerd and CRI-O are two examples.

Kubernetes removed built-in support for Docker Engine as a runtime in version 1.24. Images built with Docker still run, because they follow the OCI image format and any compliant runtime can start them.

Core objects you will meet first

Everything in Kubernetes is an API object stored in the cluster. Each one has an apiVersion, a kind, metadata and usually a spec. These are the objects that come up in almost every project:

Desired state and reconciliation

Kubernetes is declarative. You write what should exist, not the steps to reach it. You submit a manifest with kubectl apply, the API server stores it as the desired state, and controllers keep comparing that state with what is actually running. When they differ, they act: they create a missing pod, delete an extra one, or roll out a new pod template. This is called reconciliation.

Reconciliation explains two behaviours that surprise newcomers. Delete a pod and a new one appears, because the ReplicaSet still wants the count to be met. Edit a running pod by hand and the change can be reverted, because the next reconcile compares it with the manifest. The practical rule is to change the manifest and apply it, rather than patch live objects that the next apply will overwrite.

A minimal Deployment and Service

The example below runs two copies of a web container and gives them one stable address inside the cluster. The Deployment keeps the replicas alive. The Service finds them by label and load balances between them.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-web
  template:
    metadata:
      labels:
        app: hello-web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hello-web
spec:
  selector:
    app: hello-web
  ports:
    - port: 80
      targetPort: 80

Save the manifest as hello-web.yaml, apply it with kubectl apply -f hello-web.yaml, and check the result with kubectl get deploy,pods,svc. If you want a starting point for your own app, the Kubernetes deployment YAML generator builds a Deployment and Service from a few inputs.

• The default Service type is ClusterIP, which is reachable only from inside the cluster. Traffic from outside needs a LoadBalancer Service, an Ingress or a Gateway.
• Add a readiness probe so the Service sends traffic only to pods that are ready. The difference between the probes is covered in Liveness vs readiness probe.
• When a pod misbehaves, kubectl logs shows what its container printed. See kubectl logs for the flags that matter.

What Kubernetes does not do

Kubernetes is not a platform as a service. The project says so in its own overview: it does not deploy source code and does not build your application. There is no built-in CI pipeline, no source-to-image build, and no image registry. Those are separate tools. A CI system builds the image, a registry stores it, Git holds the code, and Kubernetes runs the result.

• Build: Kubernetes runs container images. It does not create them. Your pipeline needs a build step.
• Ship: a manifest is applied with kubectl or a GitOps tool. The cluster does not decide when to release.
• Observe: there is no default log store or metrics database. You install and pay for the backend that keeps logs and metrics.
• Secure by default: pods can reach each other unless you add NetworkPolicy, and access control depends on RBAC rules you write.
• Run databases for you: a stateful service needs storage, backups and a failover plan. StatefulSets give the building blocks, not the operations.

When you need Kubernetes, and when you do not

Kubernetes pays off when you run many services, need to spread them across several machines, want self-healing and rolling releases, or need the same workload definitions in several environments. It is heavy for one small app on one server, and the operating cost is real. Ask who will run the cluster, how many people must understand it, and whether your workloads will use its controllers.

Scaling is one area where the platform does real work. A HorizontalPodAutoscaler changes the replica count of a Deployment from observed metrics, so you do not need a person watching a dashboard during a traffic spike.

Managed Kubernetes on AWS and elsewhere

Running the control plane yourself means managing etcd backups, certificates and upgrades. Most teams that adopt Kubernetes start with a managed service instead. Amazon Elastic Kubernetes Service (EKS) runs the control plane across multiple AWS Availability Zones. You add worker capacity with managed node groups, self-managed nodes or AWS Fargate for pods. Google Kubernetes Engine and Azure Kubernetes Service are managed offerings on other clouds. The Kubernetes production environment guide covers the setup options for hosted and managed clusters.

SeaGit deploys apps to Amazon EKS in your own AWS account. The cluster, its nodes and the workloads run in your account, and the platform manages the deployment on top of them. SeaGit is AWS only.

Frequently asked questions