KubeKanvas Logo
  • Features
  • Pricing
  • Templates
    • How KubeKanvas works
    • Docs
    • Downloads
    • Blog
    • E-Book
    • Tutorials
  • FAQs
  • Contact
  • Features
  • Pricing
  • Templates
    • How KubeKanvas works
    • Docs
    • Downloads
    • Blog
    • E-Book
    • Tutorials
  • FAQs
  • Contact
Back to Templates

Deploy ClickHouse on Kubernetes: Production Analytical Database

Tags:
ClickHouseKubeKanvasKubernetesOLAP
Created by:
Siddiqui
Deploy ClickHouse on Kubernetes: Production Analytical Database template preview
0 uses
KubeKanvas Logo
Visual Kubernetes cluster design tool that helps you create, manage, and deploy your applications with ease.
Product
  • Features
  • Pricing
  • Templates
Resources
  • Blog
  • Tutorials
Company
  • About Us
  • Contact
  • Terms of Service
  • Privacy Policy
  • Impressum
XGitHubLinkedIn
© 2026 KubeKanvas. All rights reserved.

Introduction

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

ComponentTypePortRole
clickhouse-namespaceNamespaceNoneIsolates the ClickHouse database resources from the rest of the cluster
clickhouse-data-pvcPersistentVolumeClaimNoneAllocates 50Gi of hostpath storage for database files and data blocks
clickhouse-configConfigMapNoneConfigures environment variables for the database name, admin user, and access management
clickhouse-secretSecretNoneStores the clickhouse_pass administrative password securely
clickhouse-filesConfigMapNoneInjects custom config.xml and users.xml configurations into the container
clickhouseStatefulSet8123, 9000Deploys a single-replica server running clickhouse/clickhouse-server:26.5 with custom configuration mounts
clickhouse-serviceService8123, 9000Exposes the database pods internally to the cluster network via a static ClusterIP
clickhouse-ingressIngress80Routes external traffic to the ClickHouse HTTP endpoint via nginx with CORS allowed
clickhouse-hpaHorizontalPodAutoscalerNoneTriggers horizontal scale behaviors targeting 70 percent CPU and 80 percent memory thresholds
clickhouse-quotaResourceQuotaNoneImposes hard operational namespace thresholds limiting overall cluster CPU, memory, and pod counts
clickhouse-limitsLimitRangeNoneEnforces mandatory minimum and maximum compute boundary defaults on individual data containers
clickhouse-netpolNetwork PolicyNoneImposes 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

  1. 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.
  2. Adjust the base configuration maps and secrets to establish unique database names and root system passwords.
  3. Review the namespace resource quotas to confirm your target cluster nodes hold sufficient unallocated capacity for the database boundaries.
  4. 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.
  5. Wait for all pods to reach Running status. You can monitor progress in the Release Monitor screen.

How to Test

  1. 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.
  2. Establish a remote TCP link over native database port 9000 using a management utility to confirm internal cluster networking pathways bypass the security policy.
  3. 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.