Use case · Web & apps
Kubernetes clusters
A Kubernetes cluster comprises a control plane — the API server, scheduler, controllers, and etcd that hold and drive the cluster's state — and worker nodes where containers run. It needs cluster networking, storage for stateful workloads, and, for resilience, a highly-available control plane. Dedicated bare-metal infrastructure in the EU gives a cluster full performance and European sovereignty.
Key points
- A Kubernetes cluster has a control plane and worker nodes where containers run.
- The control plane — API server, scheduler, controllers, and etcd — holds and drives the cluster's state.
- etcd stores all the cluster's state, so it's critical and needs fast storage and backups.
- Cluster networking connects pods and services; storage serves stateful workloads.
- A highly-available control plane and added worker nodes make a cluster resilient and scalable.
What makes up a Kubernetes cluster?
A Kubernetes cluster is made of two kinds of component: a control plane that manages the cluster and decides what runs where, and worker nodes that actually run the containerised workloads. The control plane is the cluster's brain, holding the cluster's state and driving it toward the desired configuration; the worker nodes are where the containers run, carrying out what the control plane schedules. Understanding this division — the control plane managing and the worker nodes running workloads — is the key to understanding how a Kubernetes cluster is structured and what its infrastructure must provide.
Hosting a Kubernetes cluster means providing infrastructure for both the control plane and the worker nodes, along with the networking and storage the cluster needs. The control plane components must run reliably, since the cluster depends on them; the worker nodes need the compute, memory, and storage the workloads require; and the cluster needs networking to connect its parts and workloads, and storage for workloads that keep data. This page focuses on the architecture of a Kubernetes cluster and its components; the broader choices around hosting Kubernetes, such as self-hosted versus managed and why bare metal suits it, are covered on the Kubernetes page.
The control plane
The control plane manages the Kubernetes cluster, and it comprises several components that together hold the cluster's state and drive it toward the desired configuration. The API server is the front end through which the cluster is controlled, receiving instructions and serving the cluster's state; the scheduler decides which worker nodes run which workloads, placing containers according to their needs; and controllers watch the cluster's state and act to bring it to the desired configuration, handling much of Kubernetes's automation. Behind these sits the cluster's state store, etcd, which the next section covers. Together, the control plane components run the cluster.
Because the control plane manages everything, its reliability is important to the cluster, and for resilience it can be made highly available. If the control plane is unavailable, the cluster cannot be managed and changes cannot be made, though running workloads may continue for a time; so keeping the control plane available matters, especially for clusters where changes and recovery must always be possible. Running the control plane components reliably, and for resilience across multiple control plane nodes, keeps the cluster manageable. We provide infrastructure for the control plane, with the reliability and, where needed, the redundancy across multiple nodes that keeping a cluster manageable requires.
etcd: the cluster's state store
At the heart of a Kubernetes cluster's control plane is etcd, a key-value store that holds all the cluster's state — the record of everything in the cluster and its desired configuration — which makes etcd critical and deserving of particular care. Everything Kubernetes knows about the cluster is stored in etcd, so the cluster depends on it entirely: if etcd's data is lost, the cluster's state is lost. This makes etcd's reliability and the durability of its data paramount, more so than almost any other single component of the cluster.
etcd is also sensitive to storage performance, because it writes the cluster's state changes and needs those writes to be fast and reliable. Slow storage under etcd can slow the whole control plane, and etcd's performance depends on low-latency, reliable storage for its writes, so fast storage such as NVMe suits it. Beyond performance, etcd's data should be backed up, so the cluster's state can be recovered if needed, and for resilience etcd is run replicated across multiple nodes. We provide fast, reliable storage for etcd and support running it replicated and backed up, because etcd holds the cluster's entire state, and its performance and the safety of its data are critical to the cluster.
Worker nodes: where workloads run
Worker nodes are the machines in a Kubernetes cluster where the containerised workloads actually run, each running the components that let it host containers under the control plane's direction. On each worker node, an agent takes instructions from the control plane and ensures the assigned containers are running, a container runtime runs the containers, and networking components connect them. The workloads run in pods — the unit Kubernetes schedules, holding one or more containers — placed on the worker nodes by the scheduler. The worker nodes are thus where the actual application work happens, under the control plane's coordination.
The worker nodes must provide the compute, memory, and storage the workloads need, since this is where the workloads consume resources. A cluster's capacity to run workloads comes from its worker nodes, so their number and resources determine how much the cluster can run, and adding worker nodes grows the cluster's capacity. High-core-count servers with ample memory make capable worker nodes, running many pods each. We provide worker-node infrastructure sized for the workloads a cluster runs — servers with the compute, memory, and storage the pods need — so that the cluster has the capacity to run its containerised workloads, with the ability to add nodes as that capacity needs to grow.
Cluster networking and storage
A Kubernetes cluster needs networking that connects its pods and provides stable ways to reach workloads, and storage for workloads that keep data. Kubernetes networking gives pods the ability to communicate across the cluster, and provides services — stable endpoints that route to the pods behind them, balancing load — so that workloads can be reached reliably even as the underlying pods change. This networking is essential to how a cluster's workloads communicate and are accessed, and it runs across the cluster's infrastructure, which must support it.
Storage matters for workloads that keep data, since containers themselves are often ephemeral. Kubernetes provides persistent storage — volumes that outlive individual pods — for stateful workloads such as databases, so their data persists even as pods are rescheduled. This persistent storage must be provided by the infrastructure and made available to the workloads that need it. We provide the networking a cluster needs between its nodes and for its workloads, and storage for stateful workloads that require persistence, so that a Kubernetes cluster hosted with us has both the connectivity its workloads depend on and the durable storage that stateful workloads need, alongside the compute of its nodes.
High availability and scaling the cluster
A Kubernetes cluster can be made highly available and scaled, so that it is resilient to failures and can grow to run more workloads. High availability comes from running the control plane, including etcd, across multiple nodes, so that the failure of a control plane node does not leave the cluster unmanageable — the remaining control plane nodes keep it running. This resilience of the control plane, together with the worker nodes' own redundancy through running workloads across several, makes a cluster able to withstand failures.
Scaling a cluster is done chiefly by adding worker nodes, which increases the capacity to run workloads, and Kubernetes then schedules workloads across the larger set of nodes. As the workloads a cluster runs grow, more worker nodes provide more capacity, and the cluster spreads the workloads across them; the control plane can also be scaled for larger clusters. This lets a cluster grow to run more as demand rises. We provide the infrastructure for a highly-available control plane and for scaling the cluster by adding worker nodes, so that a Kubernetes cluster hosted with us can be made resilient to failures and grown to run the workloads it needs, with the nodes its capacity and resilience require.
Sovereignty, and where VV Internet Hosting fits
A Kubernetes cluster runs an organisation's workloads and holds their data, including in etcd and in persistent storage, so where the cluster runs governs that data, making sovereignty a consideration. VV Internet Hosting is incorporated in the Netherlands, within the EU, so a Kubernetes cluster hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act, keeping the cluster's workloads and data under European law. For workloads handling data subject to European protection, running the cluster in the EU keeps that data sovereign.
We host dedicated bare-metal infrastructure for Kubernetes clusters: reliable infrastructure for the control plane with fast storage for etcd and the option of a highly-available multi-node control plane, worker nodes with the compute, memory, and storage workloads need, cluster networking, and persistent storage for stateful workloads — in EU datacenters under European jurisdiction. This suits organisations self-hosting Kubernetes clusters that want the performance of bare metal, control over their cluster, resilience, and European sovereignty. We are clear about our limits: we provide the dedicated infrastructure the cluster runs on, not a managed Kubernetes service that operates the control plane and cluster for you. We are the dedicated, sovereign infrastructure a self-hosted Kubernetes cluster runs on — and if that fits your workloads, we can host it well.
Questions
Kubernetes clusters, answered plainly
Common questions about hosting for Kubernetes clusters.
What are the main parts of a Kubernetes cluster?
A control plane and worker nodes. The control plane — the API server, scheduler, controllers, and the etcd state store — manages the cluster and decides what runs where. The worker nodes run the containerised workloads in pods, under the control plane's direction. The control plane is the cluster's brain; the worker nodes are where the application work happens.
Why is etcd so important in a Kubernetes cluster?
Because etcd holds all the cluster's state — the record of everything in the cluster and its desired configuration. The cluster depends on it entirely: if etcd's data is lost, the cluster's state is lost. This makes its reliability and data durability paramount. etcd is also sensitive to storage performance, needing fast, reliable storage for its writes, plus backups and replication for resilience.
How do you make a Kubernetes cluster highly available and scalable?
High availability comes from running the control plane, including etcd, across multiple nodes, so one node's failure doesn't leave the cluster unmanageable. Scaling is done chiefly by adding worker nodes, increasing the capacity to run workloads, which Kubernetes then schedules across the larger set of nodes. Together these make a cluster resilient to failures and able to grow.
Planning Kubernetes clusters infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.