Kubernetes is the most overused tool in blockchain infrastructure, and also one of the most useful, and both facts are true at the same time. It is overused when a single node is placed in a cluster because Kubernetes sounds more serious than Docker Compose. It is useful when a team runs many nodes, needs repeatable deployments across environments, or must survive machine failures without manual intervention. The difference is not the tool. It is the scale and the availability requirement. This post draws that line, then gives a simple pattern for the cases where Kubernetes earns its complexity.
Start with the honest comparison. Docker Compose, covered in the earlier Compose post, defines a node on one host in one file, with a named volume for chain data and a restart policy for recovery. That is enough for a single node, or a small set of nodes on one host, and it is far easier to debug than a cluster. Kubernetes adds a control plane, a scheduler, a network layer, and a storage layer, all of which need operating. For one node, that is pure overhead. For ten nodes across three machines, with rolling upgrades and automatic rescheduling, that overhead buys something real. The question is never "is Kubernetes better?" It is "better at what scale, for what failure?"
When Kubernetes helps, and when it hurts
Kubernetes helps in four situations. First, many nodes: when the node count grows beyond what one host or one Compose file can describe clearly, a declarative deployment per node type scales better than hand-managed hosts. Second, fleet upgrades: when every node must move to a new client version in a controlled order, with verification between steps, a rolling update in Kubernetes is a repeatable procedure, not a series of manual logins. Third, machine failure: when a host dies, the scheduler can recreate the node pod on a healthy host and reattach its volume, where a single-host setup waits for a human. Fourth, shared platform: when nodes share a cluster with indexers, APIs, and monitoring, Kubernetes gives one deployment, networking, and secret model for the whole stack.
Kubernetes hurts in the opposite situations. It hurts for a single node, where the cluster costs more to operate than the node it hosts. It hurts for a beginner team with no Kubernetes experience, where the learning curve delays the node itself and the first incident becomes a cluster incident plus a node incident. It hurts for latency-sensitive validators on underpowered clusters, where the scheduler, network overlay, and storage layer add variables that are hard to separate from chain behaviour. And it hurts when chain data lives on slow or shared storage, because a node that cannot keep up with sync will look like a Kubernetes problem when it is actually a disk problem. If any of those describe you, start with Compose, prove the node, and move to Kubernetes when the node count forces it.
StatefulSets and volumes: the core pattern
The core Kubernetes pattern for a node is a StatefulSet, not a Deployment, and the reason is identity. According to the Kubernetes StatefulSet docs, a StatefulSet maintains a sticky identity for each pod: a stable name, a stable network identity, and stable storage across rescheduling. A Deployment treats pods as interchangeable, which is correct for a stateless API and wrong for a node whose chain data, peer identity, and validator keys belong to that specific node. A StatefulSet gives each pod its own PersistentVolumeClaim through volumeClaimTemplates, so when a pod is recreated, it reattaches to the same volume and resumes from its synced data, rather than starting sync from scratch.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mychain-node
spec:
serviceName: mychain-node
replicas: 1
selector:
matchLabels:
app: mychain-node
template:
spec:
containers:
- name: node
image: client:1.2.3
volumeMounts:
- name: node-data
mountPath: /data
volumeClaimTemplates:
- metadata:
name: node-data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 500Gi
Read that manifest as decisions, not as boilerplate. The image must be pinned to a full version, never a floating tag. The storage size must come from the chain requirements plus a growth buffer, not from a copied example, and the storage class must match fast local or block storage for your provider, because slow storage is the most common reason a Kubernetes node falls behind. The access mode ReadWriteOnce means one node at a time, which is correct for chain data that cannot be safely shared between two writers. A headless Service, named in serviceName, gives each pod a stable DNS name, which matters for peer discovery and for validator identity. Every field here is a choice that affects sync, recovery, or cost, and copying it without checking those choices is how a cluster looks correct and runs badly.
Monitoring and upgrades in Kubernetes
Monitoring in Kubernetes should cover the node and the cluster separately, because a node alert and a cluster alert have different owners and different fixes. Node metrics are the same as on any host: block height versus chain tip, peer count, disk usage and growth, sync status, and client logs. Cluster metrics are additional: pod restarts, volume attachment failures, node pressure, and scheduler events. When a node falls behind, check node metrics first, then cluster events, in that order. Jumping to cluster debugging when the disk is full wastes the incident, and the earlier monitoring post covers the node metrics that matter most.
Upgrades in Kubernetes should be rolling, tested, and reversible, and the StatefulSet makes that procedure explicit. Test the new client image on a staging StatefulSet with the same manifest, snapshot or back up the volume first, then update the image in the manifest and let the StatefulSet recreate pods in order, verifying sync after each pod. Keep the previous image available, and keep the volume, because rollback is a manifest change back to the previous image, not a data rebuild. Never delete a StatefulSet and its volumes together on a production node unless you intend to resync, because Kubernetes does not delete StatefulSet volumes automatically on scale-down or deletion, which protects data, but a manual volume deletion removes that protection in one command.
Two warnings belong in every Kubernetes node plan. First, never run two validator pods with the same signing keys at the same time, including during a rolling upgrade that briefly overlaps old and new pods. Duplicate signing is a slashing risk, and Kubernetes rolling updates can create exactly that overlap if the update strategy is not set to stop the old pod before starting the new one for validator workloads. Second, never treat Kubernetes as a substitute for backups. Volumes persist across pod recreation, but they do not survive a storage failure, a mistaken deletion, or a corrupted database on their own. Snapshots, tested restores, and off-cluster key backups remain mandatory, exactly as on a single host.
The rule to take away is short. One node, or a few nodes on one host: use Compose, and spend the saved effort on monitoring and backups. Many nodes, fleet upgrades, or machine-failure tolerance: use StatefulSets, pinned images, fast volumes, and a tested rolling upgrade procedure, and operate the cluster as a product in its own right. If you are deciding between those two, or if your current cluster is harder to operate than the nodes inside it, blockchain node setup and DevOps node operations cover deployment design, volume and upgrade planning, and monitoring, starting with a free infra audit. Bring your node count, your current manifest, and your upgrade history: those three items show immediately whether Kubernetes is helping or hurting.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-01 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.