What is Kubernetes (K8s)?
Author: Domeny.ForSale editorial team Published
In brief: Kubernetes, or K8s for short, is an open platform for running and managing applications in containers. It ensures that the specified number of copies are running, replaces unavailable instances, and makes deploying new versions easier. It is useful for complex systems, but for a simple website or small application, maintaining it can be more complicated than the hosting itself.
From containers to application management
A container is an isolated environment for running an application process. It is created from a container image: a package containing the code, required libraries, and startup settings. This allows the same version of an application to run in different compatible environments without manually installing all its dependencies.
A single container is relatively easy to run. Difficulties arise when you need to manage many applications, distribute them across several servers, update them without lengthy interruptions, and respond to failures. Kubernetes automates some of these tasks — this kind of management is called container orchestration.
K8s is an abbreviation of Kubernetes: there are eight letters between “K” and “s”. It does not refer to a separate product or a different version of the platform.
How Kubernetes works: clusters, nodes, and pods
A cluster is a Kubernetes environment consisting of a management layer and nodes that run applications. A node is a physical or virtual machine. In a small test environment, all the components can run on one computer.
The management layer, known as the control plane, stores configuration and coordinates the cluster’s work. Among other things, it decides where to run an application. Software running on the nodes carries out these instructions and reports the status of running workloads.
Kubernetes works on the principle of desired state. Instead of manually starting each copy of an application, you declare, for example: “three copies of this version should be running”. The system constantly compares this declaration with the actual state and attempts to resolve any differences.
Four concepts are enough to understand the basics:
- Pod — the smallest unit run by Kubernetes. It contains one or more closely cooperating containers that share a network and can use shared volumes, which are storage locations made available to them.
- Deployment — an object that describes, among other things, the application version and the desired number of pods. It makes replacing pods during updates easier.
- Service — provides a stable network address for accessing a group of pods, even though individual pods may be replaced.
- Namespace — a logical space that organises resources within a cluster, for example by team or environment. It does not provide complete security isolation on its own.
Configuration is often written in YAML files, a readable text-based data format. Tools for working with a cluster include the kubectl command-line tool.
What happens during failures and updates
Imagine an online shop whose request-handling component runs in three pods across several nodes. A Deployment specifies the number of copies, while a Service directs traffic to available pods. If one pod stops working, Kubernetes attempts to start a replacement.
This does not mean an immediate or unconditional repair. The cluster must have spare resources, access to the application image, and functioning infrastructure. If the application has a bug that causes it to crash every time it starts, restarting the pod will not remove the cause.
During an update, Kubernetes can gradually replace old pods with new ones. Readiness probes — configured checks of the application’s ability to handle requests — help avoid directing traffic to a copy that is still starting up. However, deployment without downtime requires appropriate configuration and application design — it is not an automatic guarantee provided by the platform.
Scaling works in a similar way. Kubernetes lets you change the number of copies and, once an autoscaling mechanism has been configured, can do so based on metrics such as CPU utilisation. Adding pods will not, however, speed up an overloaded database or another shared bottleneck.
What Kubernetes does not replace
Kubernetes does not build application images or replace the entire process of testing and publishing code. Nor is it synonymous with Docker. Docker tools help with tasks such as building and running containers locally, while Kubernetes manages their operation in a cluster using a suitable container runtime, such as containerd.
The platform does not, on its own, provide comprehensive monitoring, backups, or application security. You need to plan permissions, updates, log collection, and credential protection. Access from the internet also requires appropriate network configuration and usually additional components or provider services.
Data requires particular attention. A pod can disappear and be recreated, so files that need to persist should not remain solely in the container’s writable layer. Kubernetes supports persistent volumes, but using them does not replace a backup or a tested recovery procedure.
When adopting K8s makes sense
Kubernetes is worth considering when you maintain many services, deploy them frequently, need independent scaling, and have a team capable of operating the platform. A common approach to configuration and deployment can then reduce the number of manual operations.
For a blog, a company website, or a single small application, simpler hosting, a virtual server, or a managed application platform often means fewer responsibilities. This is a practical assessment, not a technical limitation: a small application can run in Kubernetes, but the benefits may not outweigh the work involved.
Managed Kubernetes transfers some responsibilities to the provider, but their scope depends on the service. Before choosing one, check the official documentation and pricing for responsibility for updates, control plane availability, and charges for servers, disks, networking, and additional components.
If you are just getting to know K8s, start a local test cluster, for example using kind or minikube. Deploy a simple application with two copies and delete one pod. Watching how the system replaces it helps you understand the basic mechanism without building production infrastructure.
See also: What is 2FA?
Read also
