Installing and running self-managed ClickHouse on Kubernetes, containers, Linux packages and restricted networks, and sizing and tuning the servers underneath it.
Running ClickHouse and Keeper on Kubernetes with the ClickHouse Operator: installing with Helm, kubectl or OLM, ClickHouseCluster and KeeperCluster resources, storage classes, TLS with cert-manager, and the maturity of a 0.0.x release.
Moving from a quick-start container to a production ClickHouse container: persistent volumes for data and logs, config.d and users.d mounts, ulimits, network ports, and upgrading by image tag.
Installing ClickHouse server and client on Debian, Ubuntu and rpm-based distributions from the official repositories: pinning versions, signing keys, config.d layout, and service management.
Getting ClickHouse into networks with no internet access: mirroring tgz archives or packages, verifying downloads, keeping an internal repository current for monthly releases, and patching without outbound access.
The operating system settings ClickHouse expects: CPU governor, transparent huge pages, memory overcommit, swap, kernel versions, and hypervisor CPU passthrough on OpenStack or libvirt virtual machines.
Storage choices for self-managed ClickHouse servers: SSD versus HDD, RAID-10, RAID-6 and RAID-50 layouts, stripe sizes, ext4 or XFS, NFS caveats, and why replication still matters on top of RAID.
Estimating CPU, memory, disk and replica counts for a self-hosted ClickHouse cluster from concurrency, throughput, data volume and retention, with the vendor's published ratios and example production configurations.
Settings that make small ClickHouse servers stable: mark cache size, query threads, block sizes, parallel parsing, disabling log tables, and why S3 and Kafka integrations need more memory.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.