What is Kubernetes?

Turning Kubernetes into a dependable application platform? WZ-IT designs, builds and operates Kubernetes on Proxmox, bare metal and European cloud infrastructure, including networking, GitOps, monitoring and backup. Explore our Kubernetes services

Kubernetes is an open-source platform for orchestrating containerized applications. It distributes workloads across a cluster, maintains their desired state and provides a shared API model for deployment, networking, configuration and operations. Instead of managing every server separately, a team declares: this application should run in three instances, be reachable through this service and be replaced automatically when an instance fails.

The key point is not that Kubernetes can start containers. Docker can do that too. Kubernetes creates a consistent control and automation layer across multiple systems, applications and teams. That extra layer is valuable when operational complexity justifies it. For a single application on one server, it can be unnecessary overhead.

Contents

• The problem Kubernetes solves
• How a Kubernetes cluster is structured
• The most important Kubernetes objects
• The control loop: desired and actual state
• What Kubernetes does not solve automatically
• Kubernetes, Docker and container runtimes
• Where Kubernetes can run
• When Kubernetes makes sense
• What production-ready operations involve

The problem Kubernetes solves

A containerized application rarely consists of just one process. Production environments combine web applications, APIs, background jobs, databases, caches, ingress, certificates, configuration, secrets and monitoring. Once several applications are distributed across multiple servers, recurring questions emerge:

• Which workload should run on which system?
• What happens when a process or an entire node fails?
• How are new versions rolled out without avoidable downtime?
• How do services find one another when Pods are replaced and their IP addresses change?
• How are resources, permissions and configurations standardized?
• How does the platform remain reproducible across development, staging and production?

Kubernetes answers these questions through a declarative API and continuously running controllers. It provides scheduling, service discovery, rolling updates, horizontal scaling, self-healing and configuration distribution. The result is a common platform on which applications can be delivered according to consistent rules.

Kubernetes is neither a hosting provider nor a complete enterprise platform. It is the orchestration core around which networking, storage, identity, delivery, observability and operational processes must be designed deliberately.

How a Kubernetes cluster is structured

A cluster consists of a control plane and one or more worker nodes. The official Kubernetes components overview separates their responsibilities clearly.

Control plane

• kube-apiserver exposes the Kubernetes API. Tools, users and controllers communicate through this central interface.
• etcd stores the cluster's consistent state. Losing it without a usable backup can render the cluster unrecoverable.
• kube-scheduler decides which worker should run a new Pod, taking resources, constraints and placement rules into account.
• kube-controller-manager runs multiple control loops that reconcile desired and actual state.

In a highly available production setup, these components must not be concentrated into a single point of failure. The Kubernetes production environment documentation recommends a replicated control plane and a secured, load-balanced API endpoint.

Worker nodes

• kubelet ensures that the Pods assigned to a node are running.
• A container runtime such as containerd starts and manages the containers.
• A networking component implements service and forwarding behavior. The actual Pod network is normally provided by a CNI plugin such as Cilium or Calico.

This separation lets applications be described independently of an individual server. It does not remove physical reality: if every virtual node resides on the same hypervisor, power feed or storage system, that layer remains a shared failure domain.

The most important Kubernetes objects

Kubernetes represents platform state through API objects. The most relevant building blocks are:

Objects can be declared as YAML and applied through kubectl, Helm, Kustomize or a GitOps system. For production platforms, these definitions should be versioned, reviewed and delivered reproducibly rather than changed manually in the cluster.

The control loop: desired and actual state

The central operating principle is reconciliation. A Deployment may declare that three replicas of version X should be running. Controllers continuously observe actual state. If a Pod fails or a node disappears, Kubernetes attempts to create the missing instance elsewhere.

This is the frequently cited self-healing behavior, but its scope matters:

• Kubernetes can replace a failed container or Pod.
• It can reschedule a workload after a node failure if other nodes and the required data remain available.
• It cannot automatically repair a logically corrupted database.
• Without suitable health checks, it cannot reliably know whether an application works correctly at the business level.
• It does not replace disaster recovery if the cluster, storage layer or entire site is lost.

What Kubernetes does not solve automatically

Kubernetes supplies mechanisms, not a complete operating organization. The following duties remain:

• Backups and restore tests: etcd, persistent data and application backups require distinct procedures and tested recovery plans.
• Monitoring and logging: metrics, logs, traces and business-level health checks must be collected, retained and connected to alerts.
• Security: RBAC, admission policies, NetworkPolicies, image verification, secrets and patching must be configured and maintained.
• Storage: a PersistentVolume is not itself a backup or high-availability strategy.
• Application architecture: Kubernetes does not make a faulty or non-scalable application cloud native.
• Capacity planning: cluster autoscaling can help, but it still needs available infrastructure, defined resource requests and cost controls.

This is why we treat Kubernetes as part of an operating model rather than an isolated installation project.

Kubernetes, Docker and container runtimes

Kubernetes is not a replacement for containers. It consumes OCI container images and executes them through a runtime. Docker can remain the developer tool used to build and run images locally; Kubernetes itself commonly uses containerd or CRI-O through the Container Runtime Interface.

The difference is the abstraction layer:

• Docker Compose describes and starts a set of related containers, normally on one Docker system.
• Coolify adds a self-hosted user and deployment layer for Docker-based applications.
• Kubernetes provides a distributed orchestration API for clusters, platform teams and more demanding operational requirements.

Our comparison Kubernetes vs Docker Compose vs Coolify explores this decision in detail.

Where Kubernetes can run

Kubernetes is portable across infrastructure models:

1. Private virtualization: for example Kubernetes on Proxmox with virtual control-plane and worker nodes.
2. Bare metal: direct installation on physical servers, useful for high performance or specialized networking and GPU requirements.
3. European cloud and bare-metal providers: for example Hetzner or OVHcloud, operated independently with controllable data residency.
4. Managed Kubernetes: Amazon EKS, Azure AKS or Google GKE manage parts of the control plane, while workloads, permissions, networking and data remain customer responsibilities.
5. Lightweight edge deployments: distributions such as K3s reduce resource consumption and installation complexity for smaller or distributed environments.

The application platform remains similar, but responsibility, cost model, integrations and sovereignty differ substantially.

When Kubernetes makes sense

Kubernetes becomes relevant when several of these conditions apply:

• many containerized services or multiple application teams,
• standardized deployments across several environments,
• frequent changes and automated rollouts,
• horizontal scaling or dynamic workloads,
• clear resilience requirements and maintenance without extended interruptions,
• hybrid, sovereign or multi-cluster infrastructure,
• a shared platform with policies, self-service and GitOps.

It is often excessive when a small number of stable applications runs on one server, deployments are infrequent and nobody can own the additional platform over time. Do we need Kubernetes? provides a structured decision framework.

What production-ready operations involve

An installed cluster is only the beginning. Production requires at least:

• a documented target architecture and failure objectives,
• a highly available control plane or a consciously accepted single point of failure,
• separated network zones and controlled API access,
• ingress or Gateway, DNS and certificate automation,
• dependable persistent storage,
• Git-based delivery and reproducible configuration,
• monitoring, logging, alerting and capacity limits,
• backup, restore testing and disaster recovery,
• upgrade and security processes for cluster and workloads.

Kubernetes publishes roughly three minor releases each year and supports a minor version for about one year according to its official release and support overview. Cluster upgrades must therefore be a recurring operational process, not an occasional major project.

Internal APIs, dashboards and services do not all need public endpoints. A private NetBird access layer can expose cluster access and internal services based on identity and policy.

Conclusion

Kubernetes standardizes the operation of containerized applications across multiple systems. Its strengths are the declarative API, continuous control loops and extensive ecosystem. The platform fits when requirements for delivery, scaling, resilience and shared operating standards justify the additional cluster operations. For smaller systems, Docker Compose, Coolify or virtual machines may meet the same requirements with fewer platform components.

WZ-IT therefore starts by assessing the application, team, infrastructure and operating objectives. If Kubernetes fits, we build the entire chain: from Proxmox, bare metal or cloud through networking and GitOps to monitoring, backup and long-term operations.

Sources

• Kubernetes documentation: Concepts
• Kubernetes documentation: Cluster components
• Kubernetes documentation: Production environments
• Kubernetes documentation: Workloads
• Kubernetes releases and support periods