Kubernetes

Technical definition

Kubernetes is a container orchestration platform that exposes a declarative API describing the desired state of workloads, storage and networking. A control plane continuously compares that declared state against the observed state of the cluster and takes corrective action to reconcile the two. Each machine that runs workloads (a node) runs an agent that starts, stops and reports on containers under instruction from the control plane.

The names and responsibilities of individual control-plane components (for example, an API server, a scheduler, a controller manager and a cluster data store) are established Kubernetes concepts, but their precise current behaviour, defaults and version-specific guarantees should be confirmed against the currently installed Kubernetes version’s official documentation before being treated as settled fact in a specific environment.

Operational relevance

Practitioners use Kubernetes to avoid manually placing, restarting and scaling containers on individual hosts. Instead, they describe the workload they want (for example, “run three copies of this application, restart any that crash, and expose them behind a stable network address”) and Kubernetes works continuously towards that description. Manifests, not manual host changes, become the primary source of truth; drift caused by a manual change made directly on a node is expected to be corrected automatically by the control plane.

Architecture relationship

Kubernetes sits above the container runtime and below the workload itself. It assumes an underlying set of machines joined into a cluster, a container runtime capable of running the specified container images, and a network fabric that lets containers on different nodes reach one another and reach the cluster’s internal services. Kubernetes coordinates these lower layers rather than replacing them. Applications are usually packaged as container images and described as one or more Kubernetes objects, such as a Deployment or a Service, rather than being installed directly on a specific machine.

Example

A minimal illustration of the declarative approach is a Deployment manifest that asks for a fixed number of running copies of an application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
        - name: example-app
          image: example-app:stable
          ports:
            - containerPort: 8080

After applying a manifest of this kind in an isolated or non-production cluster, an operator can check the result with read-only commands rather than assuming the declared state has been reached:

• kubectl get deployment example-app to confirm the desired and available replica counts match.
• kubectl get pods -l app=example-app to confirm each pod reports Running and passes its readiness checks.

Misunderstanding

A common misunderstanding is treating Kubernetes as a platform that guarantees an application is correct, secure or highly available simply because it is “running on Kubernetes”. Kubernetes enforces the desired count and placement of containers; it does not verify that the containerised application itself behaves correctly, that its security configuration is sound, or that its dependencies are themselves resilient. Observed running-pod status is evidence that Kubernetes has reconciled its own object state, not evidence that the application is fit for purpose.

Related terms

• Pod — the smallest deployable unit Kubernetes schedules, typically one or more tightly coupled containers.
• Node — a machine, physical or virtual, that Kubernetes uses to run pods.
• Control plane — the set of components that hold and reconcile the cluster’s declared state.
• Deployment — a Kubernetes object that manages a replicated set of pods and their rollout.
• kubectl — the standard command-line client used to inspect and change cluster state.

Further reading

Before relying on any version-specific behaviour, defaults, or component name described above in a production decision, confirm it against the official documentation for the Kubernetes version actually installed, and verify cluster-specific behaviour directly with read-only commands, such as those in the example above, in a non-production environment first. Where a claim about current Kubernetes internals cannot be confirmed this way, treat it as provisional and escalate to a platform engineer with cluster access before acting on it.