An application is running. Then an update arrives, a server fails or several departments need more capacity at once. Kubernetes organizes where containers run and how the agreed operating state is restored. Whether this makes the application more reliable depends on the architecture as a whole.
Consider an internal order portal: employees enter orders, an interface transfers them to the inventory management system and a background process creates documents. Separate containers can handle these tasks. Anyone starting them individually also has to coordinate updates, restarts and placement on machines. This is where orchestration comes in.
The desired state becomes the basis for operations
In Kubernetes, you might specify that two instances of a web application should run a particular software version. The platform continually compares this desired state with the actual state. A Deployment describes how an application is deployed and uses a ReplicaSet controller to manage its Pods. If an instance is missing, the control system attempts to provide a replacement.
This is useful for updates too: a new version can be rolled out gradually. Resources, startup behavior and the chosen update strategy all need to support this. A technically successful rollout does not establish whether an order has been processed correctly. That check remains part of the application and its tests.
Key terms explained through the order portal
- Container image
- The packaged basis for an application, including the files and runtime components it needs. Runnable containers are started from this image.
- Pod
- The smallest deployable unit in Kubernetes. It usually contains one application container; closely related containers can share a Pod and, among other things, its network namespace. Two copies of the web application normally mean two Pods.
- Node
- A machine that runs Pods. A Node can be a virtual machine or a physical server. Kubernetes can therefore complement a virtualization layer rather than necessarily replacing it.
- Cluster and control plane
- The cluster connects the control system with the Nodes that run workloads. The control plane includes the API server, state database, scheduler and controllers. On the Nodes, the kubelet and container runtime handle execution.
- Service
- A stable logical access point for a group of Pods. Their addresses can change when they are replaced. The Service separates access from individual short-lived instances.
What actually happens during a failure
If a Node fails, managed Pods can be deployed again on other suitable Nodes. This requires failure detection, enough spare capacity and access to the necessary data. A second instance on the same physical host does not protect against that host failing. Several servers in the same power or network domain can also share a point of failure.
For our order portal, this means the web interface may be replaced quickly. A document job that has already started must, however, be designed so that repeating it does not create a duplicate invoice or order. Sessions must not be lost in an uncontrolled way when an instance is replaced. These properties depend on the software architecture and connected systems.
Having three servers is therefore not an availability plan on its own. Control, applications, networking, storage and the capacity remaining after a failure must be considered together. The same applies in the cloud or with a managed Kubernetes service: the actual service scope determines which responsibilities belong to the provider and which remain with the business.
Persistent data needs its own plan
Pods are replaceable. Business data must therefore not exist solely in a container’s writable filesystem. Kubernetes can connect persistent storage through Persistent Volumes and the associated requests, called Persistent Volume Claims. A StorageClass describes how suitable storage can be provisioned.
These objects do not automatically make the underlying storage resilient. A local disk remains tied to its infrastructure; an external storage service has its own performance and failure characteristics. A database outside the cluster can also be the right solution. Application support, data consistency, access paths and the agreed recovery process are decisive.
For the portal, we therefore define separately how long it may be unavailable, what data loss would be acceptable and how a restore will be tested. A cluster that reliably propagates an accidental deletion to every instance is no substitute for a backup. Read more about backup and recovery.
When the additional setup is worthwhile
Kubernetes becomes interesting when several applications are updated regularly, repeatable deployment is needed or workloads and available machines need to be allocated deliberately. It also creates tasks for platform updates, access management, networking, storage and monitoring.
For a single stable application, a properly maintained server with Docker Compose or a conventional virtual machine may be a better economic fit. The decision should start with the operating behavior required: which interruptions are acceptable? How often do changes occur? Who can understand the environment and recover it when something goes wrong?
A useful pilot has verifiable goals
- Test a representative business process with realistic data volumes and without production customer data.
- Rehearse an update, including the planned way back. Assess database schema changes separately.
- Test the failure of one instance and one planned infrastructure component under controlled conditions.
- Restore a backup into a separate test environment and open it to verify that the business data is usable.
- Assign named responsibilities for alerts, platform maintenance and the application.
DAXS helps assess the application and choose suitable infrastructure as well as handling implementation and agreed operations. An initial assessment with a concrete use case and clear acceptance criteria is a practical first step.
Sources: Kubernetes: the platform’s role and limits · Cluster components · Pods and their lifecycle · Deployments and updates · Services · Persistent storage · Planning production environments
