Kubernetes for Business: When Containers Are Really Needed

Kubernetes is often described as the standard for modern cloud-native infrastructure, which can create the impression that it is needed for almost every project that uses containers. In reality, orchestration solves a specific class of tasks: managing large numbers of containerised workloads, automatic recovery, scaling, standardising deployment and handling frequent changes. If the system is relatively small, Kubernetes may add more operational complexity than value.

Therefore, the decision to implement it should begin not with choosing a distribution or cloud provider, but with assessing the system itself: how many services need to be supported, how often they are updated, how much the load changes, what availability requirements exist and whether the team has sufficient expertise to operate a cluster.

What is Kubernetes

Kubernetes is an open platform for orchestrating containerised workloads. It helps automate application deployment, maintain the required number of application replicas, place workloads on available nodes, recover managed workload’s after certain failures and scale them according to defined rules.

The Kubernetes project was created at Google based on the company’s many years of experience with its internal Borg and Omega orchestration systems. Kubernetes became open source in 2014, and in 2015 Google donated it to the Cloud Native Computing Foundation. Today, Kubernetes is developed as an open project by a large international community and is not tied to the infrastructure of a single provider.

Kubernetes and Docker are not interchangeable technologies. Docker is widely used to build images and run containers locally, whereas Kubernetes is responsible for orchestrating workload’s in a cluster. Modern Kubernetes runs containers through a runtime compatible with the Container Runtime Interface, such as containerd or CRI-O. Therefore, using Docker to build images does not mean that Docker Engine must necessarily be running on Kubernetes nodes.

It is also important to understand the limits of Kubernetes. It does not replace CI/CD, does not fix architectural problems in an application and does not guarantee uninterrupted operation by itself. Kubernetes supports rolling updates and self-healing mechanisms, but zero-downtime updates are possible only when the application, probes, number of replicas, traffic balancing and other components are configured accordingly.

Kubernetes also does not automatically make infrastructure cheaper. The orchestrator can help distribute resources between workload’s more efficiently, but it also introduces costs associated with the control plane, network model, storage, observability, backup, upgrades and engineering work. The economic effect should be assessed through the total cost of operation rather than solely through the number of servers.

Why businesses need container orchestration

The need for orchestration usually emerges as a system grows. A few containers on a single server can be managed using Docker Compose or another simpler tool. When the number of services increases, they run across several nodes, are updated regularly and have different resource requirements, manual administration gradually becomes a separate source of risk.

For example, after an update, configuration may differ between nodes, an individual process may fail to recover after an outage, and new application versions may have to be distributed between servers manually. Kubernetes moves a significant part of these operations into a declarative model: the team describes the desired state of the system, while controllers attempt to keep the actual state aligned with that description.

Kubernetes can maintain the required number of pod’s, recreate them after certain failures and distribute them between available nodes. A Service object provides a stable access point to a group of pod’s and can distribute traffic between them within the cluster. Depending on the architecture, LoadBalancer, Ingress or Gateway are additionally used to expose applications externally.

Containers and virtual machines solve different tasks. A virtual machine has its own guest operating system, whereas Linux containers usually use the host operating system kernel and isolate processes at another level. Because there is no need to boot a separate guest OS, containers often start faster and allow computing resources to be used more densely, although the actual startup time also depends on image size, image download, application initialisation and storage.

This does not mean that containers eliminate virtualisation. Kubernetes often runs on top of virtual machines, which form the infrastructure layer and provide an additional isolation boundary. More information about different models for providing computing resources can be found in the material about cloud technologies.

How a cluster is structured

A Kubernetes cluster consists of a control plane and worker nodes. The control plane manages the state of the system and makes decisions, while worker nodes directly run pod’s containing application workload’s. For a production environment, the architecture of these components is determined by availability and scaling requirements and by acceptable failure scenarios.

There is no universal minimum number of servers that automatically makes a cluster production-ready. In highly available configurations, control plane components are duplicated, while worker nodes are provisioned with sufficient resources and spare capacity. The specific topology depends on which failures the system must be able to withstand.

Control plane

The control plane maintains the global state of the cluster. The API server is the main point of interaction with the Kubernetes API, the scheduler determines which node can host a new pod, the controller manager performs reconciliation loops, and etcd stores data about the state of the cluster.

The desired-state model is fundamental to Kubernetes. For example, if a Deployment defines three application replicas, the controllers compare this description with the actual state and attempt to maintain the required number of pod’s. This model underpins a significant part of automatic recovery and scaling.

If the control plane is temporarily unavailable, workload’s already running on healthy nodes will not necessarily stop immediately, and kubelet can perform some local operations with containers. However, the cluster loses its normal ability to schedule new pod’s, make Deployment changes, respond to certain failures and maintain the desired state across the cluster. Therefore, control planes for critical production environments are designed with redundancy.

Etcd requires particular attention. It stores the Kubernetes state, so a self-managed cluster requires a well-designed backup procedure and tested recovery.

Worker nodes

A worker node is a physical or virtual server on which pod’s run. The node runs kubelet and a container runtime, while network components provide the required interaction between workload’s in accordance with the cluster configuration.

The smallest deployment unit in Kubernetes is a pod. It can contain one or more containers that run together on the same node and share a network namespace. In practice, a model with one main container per pod is common, although additional containers can be used for sidecar functions.

Pod’s should be regarded as temporary entities. During updates, scaling or recovery, Kubernetes can create new pod’s with different IP addresses. Therefore, stable access to a group of replicas is usually implemented through a Service rather than through direct access to a specific pod.

If a worker node becomes unavailable, Kubernetes can create replacements for the pod’s of a managed workload on other suitable nodes. However, this works only if the cluster still has the required resources, storage is available according to its model, and the application is designed to tolerate such a scenario. Therefore, spare capacity is part of availability planning.

Signs that Kubernetes is needed

A single project characteristic is rarely sufficient reason to use Kubernetes. A strong case appears when several requirements accumulate at the same time for which manual operation or simpler tools become too difficult.

• A large number of independent services – dozens of components have separate lifecycles, versions and resource requirements.
• Frequent deployments – the team regularly releases new versions and needs standardised rolling updates, rollbacks and automation of deployment processes.
• Variable load – the number of replicas needs to increase or decrease according to metrics. At the same time, scaling worker nodes is a separate layer and depends on the infrastructure and additional mechanisms.
• A need for automatic workload recovery – the system must respond to pod or node failures without manually starting every service.
• A unified deployment model is required – teams want to use the same Kubernetes API and deployment approaches across different environments, while recognising that multi-cluster and hybrid cloud require separate architecture.

These factors should be assessed together with the future development of the system. If a company is already moving towards dozens of independent services, active CI/CD and more complex infrastructure, early Kubernetes planning may be justified. However, creating a cluster simply because Kubernetes is widely used in the market makes no economic sense.

When Kubernetes is not needed

Kubernetes is itself a complex distributed system that needs to be configured, updated, monitored and secured. Therefore, for a small application, the cost of the platform itself may be higher than the operational problem it is intended to solve.

A monolithic architecture does not in itself prevent the use of Kubernetes. A monolith can be containerised and run in a cluster. However, if it is a single application with a few replicas and predictable load, a significant proportion of the orchestrator’s capabilities may remain unused. In such a situation, simpler infrastructure will often be easier to operate.

The second factor is team expertise. Self-managed Kubernetes requires an understanding of networking, container runtimes, storage, IAM, certificates, observability, backup and upgrades. If responsibility for all of this is assigned to one person who is also maintaining other systems, Kubernetes may increase operational risk.

Stable load also reduces the value of some Kubernetes capabilities, but it does not automatically rule it out. The orchestrator may still be useful for standardised deployments or self-healing even without frequent scaling. The entire set of requirements should be assessed rather than a single characteristic.

The main principle is simple: the complexity of the platform should match the complexity of the task. If the requirements can be reliably met with fewer components, Kubernetes should not become an end in itself.

How much does deployment cost

A licence for Kubernetes itself is not the main cost item because the project is open source. Costs are formed around the infrastructure, supporting components and operation.

1. Computing infrastructure – control plane, worker nodes, spare resources and load balancing.
2. Storage and networking – persistent volumes, CSI, ingress, load balancing, DNS and required network components.
3. Observability and security – monitoring, centralised logs, auditing, image scanning and access control.
4. Backup and recovery – copies of etcd, persistent data and tested recovery procedures according to application architecture.
5. Operation – Kubernetes and dependency upgrades, compatibility checks, incident response and engineering work.

For a self-managed production cluster with high availability requirements, control plane components are usually duplicated, while the number of worker nodes is determined with failure scenarios in mind. There is no single universal minimum for all production systems.

Components such as a monitoring stack, log aggregation, image registry, ingress controller or code delivery systems should also not automatically be regarded as part of “free Kubernetes”. The specific set depends on the architecture, but all these systems consume resources and require support.

Therefore, Kubernetes should not be compared only with the cost of the current servers. A correct assessment considers TCO: engineering time, release-process complexity, the consequences of incidents, redundancy requirements, scaling speed and the cost of supporting the platform throughout its entire lifecycle.

Where to deploy a cluster

Kubernetes can run in a public cloud, private virtual infrastructure or on bare metal. Managed Kubernetes is another option, where a provider assumes responsibility for a defined part of platform management. It is important not to confuse these models: an ordinary cloud with virtual machines does not itself mean that managed Kubernetes is available.

Before choosing a platform, requirements for CPU, RAM, storage, networking, availability, data geography and the operating model must be defined. The basic differences between infrastructure models are covered in the material what is a private cloud.

Managed provider service

In managed Kubernetes, the provider takes responsibility for at least a certain part of the control plane lifecycle. The precise area of responsibility differs between providers: version upgrades, control plane SLA, backup, worker nodes, CNI, CSI, ingress, monitoring and security should be checked separately.

This model can significantly reduce the amount of work associated with the platform itself, but it does not remove the team’s responsibility for applications, resource requests and limits, readiness and liveness probes, images, secrets, workload configuration and application-level security.

Managed Kubernetes should not be equated with an ordinary public cloud. For example, Atman Cloud, available through Hostpark, is Atman’s public cloud infrastructure based on OpenStack. The virtual resources of such a cloud can serve as an infrastructure foundation for Kubernetes, but simply using Atman Cloud does not mean that a Kubernetes cluster is automatically deployed and supported as a managed service.

If Kubernetes is planned to run on public cloud infrastructure, it is necessary to determine separately who is responsible for creating the control plane, upgrades, backup, network integration and ongoing operation.

Own cluster in a private cloud

Self-managed Kubernetes can be deployed on private virtual infrastructure. This approach gives the team greater control over topology, versions, networking, storage and policies, but at the same time transfers responsibility for the platform lifecycle to the team.

Hostpark provides a VMware private cloud. On the current commercial page, VMware Cloud Director, NSX-T and Tanzu are listed among the platform components. VMware Tanzu technologies can be used to build Kubernetes environments, but the specific cluster architecture, component set and boundaries of responsibility for its support must be defined for each particular project. More information about the technological approach can be found in the material about deploying Kubernetes on VMware Tanzu.

For scenarios where direct access to physical resources is important, Kubernetes can be deployed on Atman dedicated servers in Poland. The bare-metal model removes the hypervisor layer and provides full access to server resources, but node redundancy, storage and recovery processes need to be designed separately.

Hybrid cloud should also not automatically be implemented as a single cluster stretched across remote sites. Kubernetes is sensitive to network availability and latency between system components. In many scenarios, it is more reliable to use separate clusters in different environments and manage them through common CI/CD, policy and observability processes.

Cluster security

Kubernetes security does not appear automatically after installing the platform. A production environment requires separate solutions for access control, network segmentation, secret protection, image security, component upgrades and external perimeter protection.

One of the most important components is the Kubernetes API. Access to it should be restricted, strong authentication should be used, and permissions should be separated through RBAC according to the principle of least privilege. Administrative access should not be exposed to the entire internet without a valid need.

The network model inside the cluster also requires configuration. If NetworkPolicy is not applied, pod’s do not have ingress and egress restrictions by default at the Kubernetes NetworkPolicy level. Therefore, for a production environment, it is advisable to define which services genuinely need to communicate with one another and apply policies through a network component that supports their enforcement.

Particular care is required when working with Kubernetes Secrets. The object name does not mean that information is automatically encrypted in etcd. Values in the data field are Base64 encoded, but this does not provide confidentiality. For a production environment, encryption at rest should be configured, RBAC access should be restricted and, where necessary, an external secrets management system should be integrated.

Container images should be obtained from controlled registries, their versions or digests should be pinned, base images should be updated regularly and dependencies should be checked for known vulnerabilities. Scanning should complement rather than replace patching and image lifecycle management.

Kubernetes perimeter protection is a separate layer from NetworkPolicy inside the cluster. For controlling network traffic at the infrastructure level, Hostpark provides the managed Atman Firewall service based on Fortinet FortiGate. It should be regarded as network protection for the infrastructure rather than as a replacement for Kubernetes RBAC, NetworkPolicy or application security.

Kubernetes upgrades also need to be planned. The project has a regular release cycle, and older versions eventually reach end of support. Therefore, the upgrade process, test environment and compatibility checks for CNI, CSI, ingress controller and other components should be part of the operating procedures from the outset.

Common mistakes at the start

Most unsuccessful Kubernetes implementations are related not to the orchestrator itself, but to incorrectly defining the task or underestimating the operational side.

• Implementation without sufficient need – a complex platform is created for several simple workload’s that could have been supported much more easily.
• Lack of observability – without metrics, logs and alerts, the team does not understand why pod’s are restarting, where resource shortages occur and how the state of the system is changing.
• Moving stateful systems without preparation – a database in a container does not automatically become fault-tolerant; replication, persistent storage, backup and recovery need to be designed separately.
• Lack of requests and limits – one workload may consume a disproportionate amount of CPU or memory and affect other pod’s on the same node.
• Treating the cluster as a one-off project – Kubernetes requires continuous upgrades, compatibility checks, security hardening and regular testing of recovery procedures.

Observability, backup, security and the upgrade process should be designed at the same time as the cluster architecture itself. Adding them after the first production incident is significantly more difficult than planning for them during the design stage.

Conclusion

Kubernetes is a powerful tool for managing containerised workload’s, but its value appears only when the complexity of applications and processes genuinely requires orchestration. A large number of independent services, frequent deployment’s, the need for self-healing, variable load and standardised environment management can all be strong arguments in its favour.

For a small application with predictable load, a simpler architecture will often be cheaper, easier to understand and more reliable to operate. Therefore, the starting point should be business and technical requirements rather than the technology itself.

If Kubernetes is required, the next step is choosing the infrastructure model. Through Hostpark, different infrastructure foundations are available for such architectures: Atman Cloud public cloud on OpenStack, VMware private cloud with Tanzu and Cloud Director components, and dedicated servers. At the same time, the composition of the Kubernetes solution itself, the control plane management model, backup, networking, storage, upgrades and SLA must be defined separately for each specific project.