Example configurations for common deployment scenarios.
Note on Namespaces: All examples assume the default namespace. If using a custom namespace, add
--namespace <your-namespace> --create-namespaceto thehelmcommands below.
Store ClickHouse data in S3 instead of local EBS volumes.
Use case: Lower storage costs, scale storage independently from compute.
Note: The default laminar.yaml already includes ClickHouse S3 configuration. Use this example for additional customization.
helm upgrade -i laminar .. -f ../laminar.yaml -f clickhouse-s3-storage.yamlUse different storage classes for different services based on performance needs.
Use case: High IOPS for PostgreSQL, standard storage for RabbitMQ.
helm upgrade -i laminar .. -f ../laminar.yaml -f mixed-storage-classes.yamlDeploy services to different node groups based on resource requirements.
Use case: Compute-optimized nodes for app servers, storage-optimized for databases.
helm upgrade -i laminar .. -f ../laminar.yaml -f multiple-node-groups.yamlExamples for different secret management backends:
kubernetes-only.yaml- Traditional K8s secretsaws-all-secrets.yaml- All secrets from AWS Secrets Manageraws-partial-secrets.yaml- Sensitive secrets from AWS, rest from K8svault-all-secrets.yaml- All secrets from HashiCorp Vaultmixed-aws-vault.yaml- Mix of AWS, Vault, and K8s secrets
You can combine multiple example files. Files are merged left-to-right, with later files taking precedence:
helm upgrade -i laminar .. \
-f ../laminar.yaml \
-f mixed-storage-classes.yaml \
-f multiple-node-groups.yamlBefore deploying, update placeholder values:
- S3 bucket names and regions
- Node group names
- Storage class names
- IAM role ARNs
kubectl get pods -o wide
kubectl get pvc
kubectl exec laminar-clickhouse-0 -- clickhouse-client --query "SELECT * FROM system.disks"