ClickHouse on Kubernetes, engineered for reliable operations
In short: ClickHouse on Kubernetes requires more than installing an operator. A DBRE must select the operator and version, design ClickHouse and Keeper topology, match storage and resources to the workload, integrate recovery and observability, and rehearse upgrades and failures before production.
JusDB combines Database Reliability Engineering with hands-on DBA operations for the official ClickHouse Operator or the separately maintained Altinity operator. Recommendations remain specific to the released versions and your Kubernetes platform.
ClickHouse Kubernetes engineering scope
Each decision connects the database, operator, and Kubernetes control planes to a measurable reliability requirement.
Official ClickHouse Operator vs Altinity operator
This is a selection framework, not a universal winner. Capabilities must be confirmed in the exact releases being evaluated.
| Decision area | Official ClickHouse Operator | Altinity operator |
|---|---|---|
| API model | ClickHouseCluster and KeeperCluster custom resources | ClickHouseInstallation-centered custom resources |
| Coordination | ClickHouse Keeper is part of the documented design | Keeper or ZooKeeper support depends on configuration and release |
| Decision test | Fit with current official capabilities and roadmap | Fit with established manifests, features, and community support model |
DBRE delivery method
Assess
Capture workload, failure, security, compliance, platform, and ownership requirements; inventory current ClickHouse and Kubernetes versions.
Design
Select the operator and topology, then document storage, network, scheduling, Keeper, backup, monitoring, and rollback decisions.
Rehearse
Deploy representative data and traffic; test upgrades, disruptions, storage behavior, replica recovery, backup, restore, and observability.
Operate
Release through controlled gates and hand over dashboards, alerts, runbooks, change ownership, capacity reviews, and incident escalation paths.
ClickHouse on Kubernetes FAQ
What does ClickHouse on Kubernetes consulting include?
It includes operator and version selection, ClickHouse and Keeper topology, resource and storage design, scheduling, networking, security, configuration, observability, backup and restore integration, upgrade rehearsal, failure testing, GitOps controls, and day-two DBRE operations. Familiar DBA tasks are mapped to Kubernetes ownership and automation boundaries.
Should I use the official ClickHouse Operator or the Altinity operator?
ClickHouse now publishes an official open-source operator with ClickHouseCluster and KeeperCluster resources. The Altinity-sponsored community operator is a separate, mature project centered on ClickHouseInstallation resources. We compare the exact released versions, required features, migration path, support model, existing manifests, and team experience before choosing; they are not interchangeable APIs.
Does an operator make ClickHouse highly available?
An operator can reconcile Kubernetes resources, but availability also depends on ClickHouse replication, Keeper quorum, failure-domain placement, storage behavior, Services and clients, disruption controls, capacity, and tested recovery procedures. Neither Kubernetes nor an operator creates a universal uptime or data-loss guarantee.
How should persistent storage be designed for ClickHouse on Kubernetes?
We measure ingest, merge, mutation, query-read, latency, capacity, and recovery needs before selecting StorageClasses, volume sizes, reclaim policies, expansion, local or network storage, and any object-storage tier. A PVC protects pod identity, not the database by itself; replication and independently restorable backups remain separate controls.
Can ClickHouse upgrades on Kubernetes avoid interruption?
The official operator and Altinity operator both support lifecycle and upgrade workflows, but safe continuity depends on their exact versions, ClickHouse compatibility, replica health, capacity, client routing, schema operations, and failure behavior. We rehearse the chosen rollout and rollback path rather than promising an interruption-free upgrade before testing.
Are ClickHouse backups included in the Kubernetes operator?
Backup capability should be verified for the exact operator release and selected backup tool; it is not safe to treat every operator as a complete backup system. We design credentials, schedules, retention, object-storage isolation, consistency expectations, restore runbooks, and recurring restore tests as explicit controls.
ClickHouse on Kubernetes operator and platform sources
Review scope: Operator selection, ClickHouse and Keeper custom resources, storage and scheduling, scaling, configuration, upgrades, TLS, monitoring, backups, restores, and failure testing. Guidance is checked against primary documentation; recommendations, delivery timing, availability, migration interruption, and performance outcomes remain specific to the workload, version, topology, infrastructure, and engagement scope.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed: . See the team and roles.
- Official ClickHouse Operator
ClickHouse documentation for the official open-source operator, its custom resources, lifecycle, storage, TLS, scaling, upgrades, and monitoring capabilities.
- ClickHouse Operator repository
Official source repository and release artifacts for the ClickHouse Kubernetes Operator.
- Altinity Kubernetes Operator
Documentation for the separately maintained, Altinity-sponsored community operator and its ClickHouseInstallation model.
Related ClickHouse Services
Explore more ways our ClickHouse experts can help with your database infrastructure.