We’re excited to announce that we’ve expanded Tanzu Application Catalog, Bitnami Premium and Bitnami Application Catalog, enriching the ways you can deploy and manage ClickHouse solutions.
First, we've introduced a new Helm chart for the most popular ClickHouse Operator, enabling more advanced and automated management of ClickHouse installations. Additionally, we’ve added support for ClickHouse Keeper as a built-in alternative to ZooKeeper in the existing ClickHouse Helm chart, offering more flexibility for coordinating your deployments.
ClickHouse Operator
Based on the Altinity Kubernetes Operator for ClickHouse, this new Helm chart allows you to install the operator and its CRDs in your K8s cluster and configure the default configuration and templates to be used by the operator to run ClickHouse and ClickHouse Keeper clusters. Please refer to the Tanzu Application Catalog documentation to find all configuration and installation details this chart offers.
Once it’s installed, you can install, configure, and run ClickHouse clusters using the operator custom resources. For instance, the example below can be used to create a simple ClickHouse cluster with a single ClickHouse replica:
apiVersion: clickhouse.altinity.com/v1
kind: ClickHouseInstallation
metadata:
name: test
spec:
defaults:
templates:
podTemplate: default-clickhouse
dataVolumeClaimTemplate: default-volume-claim
configuration:
users:
default/networks/ip:
- 0.0.0.0/0
- '::/0'
clusters:
- name: cluster
layout:
replicasCount: 1
templates:
podTemplates:
- name: default-clickhouse
spec:
containers:
- name: clickhouse
image: docker.io/bitnami/clickhouse
volumeMounts:
- name: default-volume-claim
mountPath: /bitnami/clickhouse
volumeClaimTemplates:
- name: default-volume-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
The operator also allows you to install, configure, and run ClickHouse Keeper clusters that you can later use to provide coordinating capabilities to your ClickHouse clusters. You can refer to Altinity’s documentation to learn more about how to customize ClickHouse clusters to fit your organization's needs.
Differences between the ClickHouse Helm chart and the ClickHouse Operator Helm chart
The ClickHouse Helm chart deploys a single ClickHouse installation plus some coordinating system (ZooKeeper or ClickHouse Keeper) using a K8s StatefulSet object (together with Services, PVCs, ConfigMaps, etc.). The figure below shows the deployed objects in the cluster after executing installing the chart:

Its lifecycle is managed using Helm and, at the ClickHouse container level, the following operations are automated: persistence management, configuration based on environment variables and users initialization. The StatefulSet does not require any ServiceAccounts with special RBAC privileges so this solution would fit better in more restricted Kubernetes installations.
On the other hand, the ClickHouse Operator Helm chart deploys an Altiny K8s Operator installation using a K8s Deployment. The figure below shows the ClickHouse operator deployment after installing the chart:

The ClickHouse Operator will extend the K8s API with the following objects: ClickHouseInstallation & ClickHouseKeeperInstallation. From that moment, you can deploy objects of these kinds and the previously deployed operator will take care of deploying all the required StatefulSets, ConfigMaps and Services for running ClickHouse or ClickHouse Keeper instances. Its lifecycle is managed using kubectl on the new supported objects. The following figure shows the deployed objects after deploying a ClickHouseInstallation object using kubectl:

This solution allows to easily deploy multiple ClickHouse or ClickHouse Keeper instances compared to the ClickHouse chart. As the operator automatically deploys ClickHouse or ClickHouse Keeper installations, the ClickHouse Operator pods will require a ServiceAccount with privileges to create and destroy multiple K8s objects. This may be problematic for K8s clusters with strict role-based access policies.
New ClickHouse Keeper alternative on ClickHouse chart
In addition to the new ClickHouse Operator chart, we introduced an important improvement in the existing ClickHouse chart. Starting with the 9.0.0 major release, the chart uses ClickHouse Keeper as the default coordinating system, replacing ZooKeeper and solving its well-known drawbacks.
With this new version, you can easily install, configure and scale both ClickHouse replicas and sharding as well as ClickHouse Keeper clusters. Please refer to the Tanzu Application catalog documentation to find all configuration and installation details this chart offers.
In order to upgrade existing ClickHouse chart releases using ZooKeeper, you need to migrate the ZooKeeper data to ClickHouse Keeper data as it is explained in the upstream documentation. That said, it is still possible to continue using your existing ZooKeeper servers to provide coordination capabilities for ClickHouse if you are not interested in migrating your data.
Do not hesitate to contact us for any questions or suggestions at https://.com/bitnami/charts/issues.