What is Kubernetes?

Kubernetes, often abbreviated K8s, is an open source platform for orchestrating containerised applications. It helps teams deploy, schedule, scale and maintain workloads across a cluster of machines. Rather than manually choosing which server should run every application container, operators describe a desired state and Kubernetes works continuously to reconcile actual cluster conditions with that desired state.

Kubernetes is not a container image builder or a replacement for an application. It coordinates container workloads, networking and resources using a control plane and worker nodes. Its value becomes especially clear when applications need multiple instances, controlled updates and recovery from individual container or node failures.

How does Kubernetes work?

A Kubernetes cluster contains a control plane and one or more worker nodes. The control plane maintains cluster state and decides where workloads should run. Worker nodes execute the application containers.

A user submits a workload definition through the Kubernetes API. The scheduler chooses suitable nodes for newly created Pods, and node agents work with a container runtime to run the containers. Controllers continually compare the desired and actual state and make changes where necessary.

What are Pods?

A Pod is the smallest deployable unit in Kubernetes. It contains one or more closely coupled containers that share networking and can share storage. A Pod is not simply another word for a container.

Pods are typically managed through higher level resources such as Deployments rather than created and maintained individually.

What is a Kubernetes Deployment?

A Deployment is a Kubernetes workload resource that manages a set of replicated Pods, usually through a ReplicaSet. It can roll out new versions gradually, track progress and support rollback of application versions.

A Kubernetes Deployment is a specific resource type. The wider term software deployment describes moving software into an environment, which can happen with or without Kubernetes.

How does Kubernetes scale applications?

A Deployment can specify multiple Pod replicas. Kubernetes tries to maintain the requested replica count, placing Pods on nodes with appropriate available resources and scheduling constraints.

Horizontal Pod Autoscaling can adjust replica counts using configured metrics and policies, provided the necessary metrics are available. It does not automatically guarantee additional node capacity or unlimited performance.

What happens when a node fails?

Kubernetes monitors node and Pod conditions. When a node becomes unavailable, controllers can create replacement Pods on healthy nodes, subject to detection delays, scheduling capacity, storage availability and workload constraints.

Recovery is not always instant and does not automatically preserve in memory application state. High availability requires suitable application design, capacity, networking, storage and failure domain planning.

Kubernetes vs Docker

Docker is commonly used to build and run container images and containers. Kubernetes orchestrates container workloads across a cluster. Modern Kubernetes uses container runtimes implementing the Container Runtime Interface, commonly containerd or CRI O, rather than requiring Docker Engine on every worker.

A team can build an image using Docker and then run it under Kubernetes. Kubernetes does not require that Docker was used to create the image.

Kubernetes vs virtual machines

Virtual machines virtualise hardware and run guest operating systems. Kubernetes generally schedules Pods containing containers that share the node's kernel. Kubernetes nodes themselves can be physical servers or virtual machines.

Containers and virtual machines offer different isolation and operational properties. Kubernetes coordinates workloads but is not a security boundary equivalent to a dedicated virtual machine.

Kubernetes networking

Each Pod receives networking within the cluster according to the configured network implementation. Services provide stable access to groups of Pods even when individual Pod addresses change. Ingress controllers or Gateway API implementations can provide application traffic routing from outside the cluster.

Network policies can restrict traffic where the chosen network implementation supports enforcement. DNS, certificates, load balancers and firewalls remain important parts of the wider deployment.

Kubernetes storage and persistent data

Containers and Pods can be replaced, so data stored only in ephemeral writable layers can disappear. PersistentVolumes and PersistentVolumeClaims provide a way to request and attach durable storage through supported storage drivers.

Stateful applications need careful planning for backup, consistency, failover, storage access modes and recovery. A persistent volume is not automatically a backup.

Why does broadband matter for Kubernetes?

Kubernetes can run entirely within a private data centre, but cloud and remote clusters depend on network connectivity. Broadband upload and download speeds can affect how quickly developers push container images, nodes pull images and administrators access services.

Latency and packet loss can also affect remote management and applications spread across locations. Fast headline broadband speed cannot overcome slow storage, a constrained container registry, a weak WiFi connection or insufficient cluster capacity.

Techie Broadband calculation: pulling a 2 GB container image

A decimal 2 GB image is approximately 16 gigabits of data. At a theoretical 100 Mbps download rate, transferring 16,000 megabits takes 160 seconds, or 2 minutes 40 seconds. At 500 Mbps the theoretical minimum is 32 seconds. At 1 Gbps it is 16 seconds, and at 2.5 Gbps it is 6.4 seconds.

Actual pulls can take longer because of protocol overhead, registry limits, congestion, disk performance, compression and extraction. Cached layers can substantially reduce the bytes transferred, so these figures illustrate a full uncached transfer rather than a prediction for every Kubernetes rollout.

Kubernetes security

Control access to the Kubernetes API with strong authentication and role based access control. Restrict workload permissions, protect secrets, keep nodes and container images updated, and apply network segmentation where supported.

Avoid running unnecessary privileged containers. Use workload isolation, resource limits, admission policies, audit logging and appropriate image provenance controls. A working cluster is not automatically a secure cluster.

Common Kubernetes problems

A Pod can remain Pending because no suitable node has enough resources or because a scheduling constraint cannot be met. ImagePullBackOff can indicate image retrieval or authentication problems. CrashLoopBackOff means a container is repeatedly failing and restarting.

Other problems include failing readiness probes, missing configuration, broken DNS, network policy restrictions, unavailable persistent volumes and incompatible application updates.

How to troubleshoot Kubernetes

First inspect Pod status and events using kubectl get pods and kubectl describe pod. Review container logs with kubectl logs, including previous container logs where restarts have occurred. Then check the Deployment rollout, readiness and liveness probes, resource requests, image registry access and node health.

If connectivity is the problem, inspect Service endpoints, DNS, ingress or gateway configuration and network policies. For storage problems, inspect PersistentVolumeClaims and the storage driver. If a production rollout causes unacceptable impact, use the documented recovery or rollback process.

Kubernetes FAQs

Is Kubernetes only for large businesses? No. It can run in small labs as well as large production systems, but its operational complexity may be unnecessary for a simple single server application.

Does Kubernetes automatically make an application highly available? No. It provides mechanisms for replication and recovery, but availability depends on application architecture, resources and cluster design.

Does Kubernetes replace Docker? No. Kubernetes orchestrates workloads while Docker can be used to build and run container images. Kubernetes uses compatible container runtimes.

Can Kubernetes run at home? Yes. Lightweight distributions can run on home lab hardware, provided resources, networking and security are planned appropriately.

Key takeaway

Kubernetes is a container orchestration platform that manages desired application state across a cluster. Its control plane schedules and reconciles workloads, while worker nodes run Pods. Scaling, recovery, networking and updates are powerful capabilities, but reliability and security still depend on thoughtful configuration and application design.

To explore the related technical concepts used in this Kubernetes guide, visit our broadband terminology guide.