Bare Metal Kubernetes: Planning a Production Cluster

Bare metal Kubernetes places the cluster directly on physical servers rather than inside a virtual machine layer. That can provide predictable access to CPU, memory, storage, and network capacity, but it also leaves the organization responsible for hardware lifecycle, node failure, and cluster operations.

A production cluster is therefore more than a kubeadm command or a set of dedicated servers. Plan the workload, failure model, networking, storage, security, and recovery process together so the platform is supportable after the first deployment.

Define the production target before choosing hardware

Start with the services the cluster will run. Record availability targets, peak and baseline resource demand, stateful data, maintenance windows, recovery objectives, compliance needs, and the people responsible for day-to-day operations.

• Availability comes first. Decide whether the cluster must continue serving workloads during a node, power, network, or control-plane failure, and design redundancy around that requirement.
• The operating model matters as well. Define who patches the host OS, manages Kubernetes versions, responds to alerts, replaces hardware, and approves changes.

A small development cluster may tolerate a single control-plane node. A customer-facing or business-critical environment normally needs a separate high-availability design, additional capacity for maintenance, and a tested recovery path.

Tip: Write the failure scenarios before selecting server specifications. The cluster should be sized for safe operation while a component is unavailable, not only for normal traffic.

Design control-plane and worker roles

Separate control-plane responsibilities from application capacity unless the workload is explicitly designed for a compact cluster. The control plane runs the API server, scheduler, controller manager, and usually an etcd member; worker nodes run application Pods and node services.

• For high availability, plan multiple control-plane nodes behind a stable API endpoint. A stacked etcd topology is simpler, while external etcd separates more components but requires more hosts and operational effort.
• Keep enough worker capacity to lose a node and still meet application requests, PodDisruptionBudgets, and maintenance requirements. Spread replicas with topology rules instead of relying on chance.

Use a load balancer or virtual IP for the Kubernetes API server, and map racks, power feeds, switches, and sites as failure domains. Physical separation is valuable only when the supporting network and power design are separate too.

Size hardware around allocatable capacity

Calculate capacity from allocatable resources, not the headline specification. Kubelet, the container runtime, system DaemonSets, monitoring, logging, image storage, and Kubernetes reservations consume part of every node.

• A bare metal design can suit predictable or resource-intensive services; Dataplugs’ related guide on scaling SaaS platforms explains why infrastructure choices should follow the application’s resource and operational requirements.
• Reserve headroom for rolling deployments, failover, image pulls, cache growth, and short traffic peaks. Avoid running every node close to CPU, memory, or ephemeral-storage limits. Specify ECC memory, reliable SSD or NVMe storage, redundant power where available, suitable NIC capacity, remote console access, and a documented firmware lifecycle. These are operational dependencies, not optional extras.

Record the performance profile that matters to the service: CPU saturation, memory pressure, disk latency and IOPS, network throughput, packet loss, and tail latency. Benchmark the complete application path, including storage and ingress.

Choose the cluster build and runtime

Use a currently supported Kubernetes minor release and keep the control plane, kubelet, kube-proxy, add-ons, and application integrations within the supported compatibility range. Pin versions in automation and plan upgrades rather than allowing package repositories to decide them.

A kubeadm-based build is a practical foundation for teams that want a supported bootstrap and upgrade path while retaining control over provisioning. Its configuration should be stored and reviewed like application infrastructure.

• Install a Container Runtime Interface-compatible runtime on every node, configure the kubelet and runtime with compatible cgroup settings, and validate kernel, time-synchronization, DNS, and required network settings before joining nodes.
• Provision hosts from a repeatable image or configuration process. Apply baseline packages, access controls, monitoring agents, disk layout, and node labels consistently; then use Kubernetes manifests or GitOps workflows for cluster add-ons and applications. Do not treat manual changes on a single node as the production process. If a replacement server cannot be rebuilt from documented automation, a hardware failure will become a knowledge problem.

Tip: Keep the cluster configuration, node inventory, certificates, secrets-handling process, and recovery commands in controlled documentation with named owners.

Plan networking and traffic paths

Bare metal removes the cloud provider’s default network assumptions. Design the physical network, VLANs or routed segments, pod and service CIDRs, MTU, DNS, API access, ingress, egress, and load-balancing path before deployment. Avoid overlapping ranges with corporate networks and connected services.

• Choose a CNI plugin that meets the requirements for routing, encryption, observability, and NetworkPolicy. Confirm whether it uses an overlay, native routing, BGP, or another model and test failure behaviour on the actual switches and firewalls.
• Define how external traffic reaches Services. MetalLB, an appliance, a reverse proxy, or another load-balancing design may be appropriate, but the address allocation and failover behaviour must be documented.

Test east-west traffic, DNS, ingress, egress controls, node replacement, and API access from the administrator network. A cluster can show Ready nodes while an application remains unreachable because one traffic path was never tested.

Treat storage and backup as separate designs

Containers are replaceable; business data is not. Decide which workloads need persistent volumes, what performance and durability they require, and whether storage is local to a node or provided by a shared or replicated system.

• Use a CSI-backed storage design where dynamic provisioning, snapshots, expansion, or replication is required. Check the driver’s Kubernetes support, upgrade path, failure domains, and backup integration.
• Local NVMe can provide low latency, but a local PersistentVolume remains tied to its node and is not highly available by itself. Use node affinity and an application-level replication or restore strategy when local storage is selected.

Back up etcd regularly and protect application data through the storage system or application-native backup. Test restoration to an isolated environment, record recovery time, and confirm that credentials, manifests, and external dependencies are available during an incident.

Build security and operations into the cluster

Harden the host OS and Kubernetes API together. Restrict administrative access, use role-based access control and least privilege, protect the API endpoint, rotate certificates and credentials, and define how secrets are encrypted at rest and handled outside the cluster.

• Apply Pod Security Standards, NetworkPolicy, image scanning and provenance checks, resource limits, and admission controls appropriate to the workload. Keep privileged containers and host mounts exceptional and documented.
• Centralize metrics, logs, and audit events. Alert on API-server and etcd health, node pressure, failed scheduling, certificate expiry, storage latency, ingress errors, and repeated container restarts.

For stateful enterprise platforms, Dataplugs’ guide on dedicated servers for enterprise ERP systems provides related context on stable resources, integration, identity, and operational planning; the same disciplines apply when those services run in Kubernetes.

Plan upgrades and recovery before go-live

Build a staging cluster or representative test environment and rehearse Kubernetes upgrades, CNI and CSI changes, node replacement, certificate rotation, backup restoration, and application rollback. Validate APIs and admission webhooks before moving between minor releases.

Drain one node at a time where possible, respect PodDisruptionBudgets, verify replacement capacity, and monitor service health during maintenance. For control-plane changes, follow the chosen deployment tool’s documented upgrade order and never skip minor versions without a supported path. Ask ten questions: What services and data will run on the cluster? What failure must it tolerate? How many control-plane and worker nodes are required? Where are the failure domains? Which runtime, CNI, CSI, ingress, and load-balancing components are supported? How much allocatable headroom is reserved? Who patches hosts and Kubernetes? Where are backups stored? How is a full restore tested? Who owns incident response?

If the answers are not documented, the cluster is not ready for production. A dedicated-server platform can offer control and predictable physical resources, but resilience comes from the surrounding design and operating discipline.

Conclusion

Bare Metal Kubernetes can be a strong foundation for workloads that need direct hardware control, predictable performance, or a consistent private infrastructure model. Its benefits are realised only when node roles, physical failure domains, networking, storage, security, and lifecycle operations are designed as one system.

Dataplugs dedicated servers give organizations a physical base for evaluating Kubernetes workloads. Start with service objectives, build repeatable nodes, reserve capacity for failure and maintenance, and test upgrades and recovery before the cluster becomes business-critical.

For more information, visit the Dataplugs website or contact sales@dataplugs.com.