Deploy ClickHouse on Kubernetes: Production Analytical Database

Deploying an analytical data warehouse requires strict compute limit enforcement, decoupled cluster scaling, and isolated network control planes. This template configures a production-ready standalone ClickHouse server on cloud and on-premises environments using native resource controls and fine-grained authentication profiles.

What's Included

Component	Type	Port	Role
clickhouse-namespace	Namespace	None	Isolates the ClickHouse database resources from the rest of the cluster
clickhouse-data-pvc	PersistentVolumeClaim	None	Allocates 50Gi of hostpath storage for database files and data blocks
clickhouse-config	ConfigMap	None	Configures environment variables for the database name, admin user, and access management
clickhouse-secret	Secret	None	Stores the clickhouse_pass administrative password securely
clickhouse-files	ConfigMap	None	Injects custom config.xml and users.xml configurations into the container
clickhouse	StatefulSet	8123, 9000	Deploys a single-replica server running clickhouse/clickhouse-server:26.5 with custom configuration mounts
clickhouse-service	Service	8123, 9000	Exposes the database pods internally to the cluster network via a static ClusterIP
clickhouse-ingress	Ingress	80	Routes external traffic to the ClickHouse HTTP endpoint via nginx with CORS allowed
clickhouse-hpa	HorizontalPodAutoscaler	None	Triggers horizontal scale behaviors targeting 70 percent CPU and 80 percent memory thresholds
clickhouse-quota	ResourceQuota	None	Imposes hard operational namespace thresholds limiting overall cluster CPU, memory, and pod counts
clickhouse-limits	LimitRange	None	Enforces mandatory minimum and maximum compute boundary defaults on individual data containers
clickhouse-netpol	Network Policy	None	Imposes strict isolation rules restricting database ingress exclusively to tabix pods and nginx ingress controllers

Architecture Overview

External HTTP traffic passes through NGINX Ingress on port 80 to the internal cluster service, where a dedicated network policy isolates port 8123 and port 9000 interaction strictly to authorized controllers and tabix pods. The StatefulSet manages a single data instance mounted to persistent hostpath volume storage with root operational security enforced via a custom file system group id. Multi-layered protection layers apply hard hardware caps across the namespace through strict resource quotas and compute limit ranges

Prerequisites

NGINX Ingress Controller deployed and configured to recognize the nginx ingress class
Distributed hosts file or external DNS entry pointing clickhouse.local to your specific cloud load balancer or local gateway IP
Default storage class setup capable of dynamically provisioning read-write-once persistent storage volumes
KubeKanvas CLI installed and running on your computer (Optional, if you want to use one-click deployment)

How to Deploy

Modify the persistent volume claim storage class to match cloud block devices like aws-ebs-csi or azure-disk-csi when targeting managed public cloud infrastructure.
Adjust the base configuration maps and secrets to establish unique database names and root system passwords.
Review the namespace resource quotas to confirm your target cluster nodes hold sufficient unallocated capacity for the database boundaries.
Deploy the template to your cluster via the Play button in the top right bar. If you prefer to deploy manually, download the YAML and apply it with kubectl.
Wait for all pods to reach Running status. You can monitor progress in the Release Monitor screen.

How to Test

Transmit an HTTP GET request directed at http://clickhouse.local/ping using curl or an external web browser to ensure the application startup and readiness probes evaluate successfully.
Establish a remote TCP link over native database port 9000 using a management utility to confirm internal cluster networking pathways bypass the security policy.
Authenticate against the analytics database catalog using client username credentials to check that custom global system configurations prevent access from unauthorized source networks.

Use Cases

Bounded Resource Multi-Tenancy: Isolation of massive column-oriented analytics engines inside multi-tenant environments using explicit resource quotas and execution safety metrics.
Autoscaled Query Processing Pipelines: Running heavy real-time data analytics pipelines that automatically scale up compute instances when heavy visualization tasks stress cluster resources.

Summary

This template builds a highly standardized, security-hardened ClickHouse installation featuring automatic horizontal pod autoscaling, rigid compute resource boundaries, isolated network access configurations, and cloud-ready data persistence.

Tags:

ClickHouseKubeKanvasKubernetesOLAP

Created by:

Siddiqui

Deploy ClickHouse on Kubernetes: Production Analytical Database template preview

15 uses

What's Included

Component	Type	Port	Role
clickhouse-namespace	Namespace	None	Isolates the ClickHouse database resources from the rest of the cluster
clickhouse-data-pvc	PersistentVolumeClaim	None	Allocates 50Gi of hostpath storage for database files and data blocks
clickhouse-config	ConfigMap	None	Configures environment variables for the database name, admin user, and access management
clickhouse-secret	Secret	None	Stores the clickhouse_pass administrative password securely
clickhouse-files	ConfigMap	None	Injects custom config.xml and users.xml configurations into the container
clickhouse	StatefulSet	8123, 9000	Deploys a single-replica server running clickhouse/clickhouse-server:26.5 with custom configuration mounts
clickhouse-service	Service	8123, 9000	Exposes the database pods internally to the cluster network via a static ClusterIP
clickhouse-ingress	Ingress	80	Routes external traffic to the ClickHouse HTTP endpoint via nginx with CORS allowed
clickhouse-hpa	HorizontalPodAutoscaler	None	Triggers horizontal scale behaviors targeting 70 percent CPU and 80 percent memory thresholds
clickhouse-quota	ResourceQuota	None	Imposes hard operational namespace thresholds limiting overall cluster CPU, memory, and pod counts
clickhouse-limits	LimitRange	None	Enforces mandatory minimum and maximum compute boundary defaults on individual data containers
clickhouse-netpol	Network Policy	None	Imposes strict isolation rules restricting database ingress exclusively to tabix pods and nginx ingress controllers

Architecture Overview

Prerequisites

NGINX Ingress Controller deployed and configured to recognize the nginx ingress class

Distributed hosts file or external DNS entry pointing clickhouse.local to your specific cloud load balancer or local gateway IP

Default storage class setup capable of dynamically provisioning read-write-once persistent storage volumes

KubeKanvas CLI installed and running on your computer (Optional, if you want to use one-click deployment)

How to Deploy

Modify the persistent volume claim storage class to match cloud block devices like aws-ebs-csi or azure-disk-csi when targeting managed public cloud infrastructure.

Adjust the base configuration maps and secrets to establish unique database names and root system passwords.

Review the namespace resource quotas to confirm your target cluster nodes hold sufficient unallocated capacity for the database boundaries.

Deploy the template to your cluster via the Play button in the top right bar. If you prefer to deploy manually, download the YAML and apply it with kubectl.

Wait for all pods to reach Running status. You can monitor progress in the Release Monitor screen.

How to Test

Transmit an HTTP GET request directed at http://clickhouse.local/ping using curl or an external web browser to ensure the application startup and readiness probes evaluate successfully.

Establish a remote TCP link over native database port 9000 using a management utility to confirm internal cluster networking pathways bypass the security policy.

Authenticate against the analytics database catalog using client username credentials to check that custom global system configurations prevent access from unauthorized source networks.

Use Cases

Bounded Resource Multi-Tenancy: Isolation of massive column-oriented analytics engines inside multi-tenant environments using explicit resource quotas and execution safety metrics.

Autoscaled Query Processing Pipelines: Running heavy real-time data analytics pipelines that automatically scale up compute instances when heavy visualization tasks stress cluster resources.