What is Kubernetes (K8s)? | AI Glossary

Start here

Kubernetes (K8s) in plain language

Instead of manually starting every replacement container, a team describes the workload. Kubernetes coordinates scheduling and lifecycle management, subject to available capacity and configuration.

A Pod is a deployable unit containing one or more closely related containers. Running Pods is only part of an application: storage, networking, identities, monitoring and application-level correctness still need deliberate design.

How it works

The visual guide

Desired state versus observed state

A simplified reconciliation loop

Declare
Request three replicas of a workload.
Observe
The controller finds fewer than the desired number.
Reconcile
Create replacements; scheduling needs suitable capacity.

The controller observes again. Replacement does not by itself restore lost application data.

Illustrative controller behaviour. The actual outcome depends on resource capacity, health configuration and the workload’s design.

Define the workload
Specify the image, resources, configuration and appropriate health checks.
Provide the platform services
Configure the networking, storage and permissions the workload needs.
Inspect health and changes
Review events, status and user-visible behaviour during rollout or failure. A running process is not always a ready service.

Illustrative example · Fictional data

A fictional API loses one replica

Input: An API Deployment requests three replicas. One Pod terminates unexpectedly.
Process: The controllers attempt to restore the desired replicas. A suitable node must be available and the replacement must pass readiness checks before receiving traffic through the configured Service.
Expected output: The workload returns to the intended available capacity if dependencies and resources permit.
How to check it: Repeat with insufficient capacity or a bad image. The replacement may stay pending or fail; declaring three replicas is not a guarantee that three healthy replicas exist.

Where it helps

Operating multiple containerised workloads with declared configuration.
Coordinating rolling application updates.
Managing replacement and placement across a cluster.

Docker, Kubernetes and managed Kubernetes

Container tooling: Builds and runs application packages.
Kubernetes: Orchestrates workloads across cluster resources.
Managed service: Moves specified cluster operations to a provider; workload configuration and responsibilities remain.

Common pitfalls

Restarting an unhealthy application does not repair its underlying bug.
Replicas sharing one failure boundary may still fail together.
Cluster complexity can outweigh its value for a small application.

Put the idea to work

Try it yourself

For a three-replica API, list what happens if an instance fails, the image is invalid or all nodes lack capacity. Separate controller action from the user-visible result.

Common questions

Does Kubernetes guarantee zero downtime?

No. Availability depends on application design, capacity, health checks, dependencies and rollout settings. Rolling updates, readiness probes and multiple replicas reduce disruption, but database migrations, slow startups or failing dependencies can still cause outages. Test rollouts under realistic load.

Does Kubernetes build container images?

Image builds normally happen in a separate build process. Kubernetes runs workloads using the resulting images. Teams typically build images in a CI pipeline, push them to a container registry and then reference the image tag in Kubernetes deployment manifests.

Should every container application use Kubernetes?

No. Compare its operational cost with simpler hosting options and the actual orchestration needs. A single server, Docker Compose or a managed container service may be enough for a small application. Kubernetes pays off when you run many services that need scaling and self-healing.

Your next step