---
url: 'https://altinity.com/blog/new-in-the-altinity-kubernetes-operator-for-clickhouse-keeper-fips-and-openshift'
title: 'New in the Altinity Kubernetes Operator for ClickHouse®: Keeper, FIPS and OpenShift'
author:
  name: Alexander Zaitsev
  url: 'https://altinity.com/author/alzaltinity/'
date: '2026-06-15T13:03:29-07:00'
modified: '2026-06-16T02:07:12-07:00'
type: post
summary: 'The Altinity Kubernetes Operator for ClickHouse now supports FIPS deployments, has better integration for ClickHouse Keeper, and is in the OpenShift community operators repository.'
categories:
  - Blog
tags:
  - Altinity
  - Altinity Kubernetes Operator
  - ClickHouse
  - FIPS
  - keeper
  - openshift
image: 'https://altinity.com/wp-content/uploads/2026/06/new-operator-features-2026-fips-openshift.png'
published: true
---

# New in the Altinity Kubernetes Operator for ClickHouse®: Keeper, FIPS and OpenShift

The Altinity Kubernetes Operator for ClickHouse, aka [Altinity/clickhouse-operator on GitHub](https://github.com/Altinity/clickhouse-operator), has reached 2500 stars! It is one of the most popular Kubernetes operators for databases, surpassed only by those for PostgreSQL. Started in 2019, with first production use in 2020, it now powers thousands of production ClickHouse clusters around the world. It is also the heart of Altinity.Cloud and other managed services for ClickHouse. 

The operator is licensed under Apache 2.0 and its wide adoption is a direct result of open source collaboration. We listen to users and adopt accordingly. The operator has a very rich feature set and enormous customization capabilities driven by a wide variety of use cases and operational environments. More than 100 contributors have offered new fixes and improvements. 

So much for marketing! Here are some cool new features in Operator version 0.27.x:

## Deeper Keeper Integration

ClickHouse Keeper support was originally added to the operator by an external contributor at the end of 2023. That was a good start, but it took us a while to integrate it properly. It worked to our satisfaction [a year later](https://altinity.com/blog/whats-new-in-the-altinity-kubernetes-operator-for-clickhouse), and since then we have been working on improvements.

In the [0.27.0 release](https://github.com/Altinity/clickhouse-operator/releases/tag/release-0.27.0) we’ve taken a final step. Now a ClickHouse Keeper (a CHK) can be directly referenced from a ClickHouse installation (a CHI). This is how. Consider we have a CHK named `my-keeper`:

```
apiVersion: "clickhouse-keeper.altinity.com/v1"kind: "ClickHouseKeeperInstallation"metadata:  name: my-keeperspec:  configuration:    clusters:      - name: keeper        layout:          replicasCount: 3
```

Previously, users had to reference it from the CHI using services. Now it is as simple as adding the keeper name. That’s it:

```
spec:  configuration:    zookeeper:      keeper:        name: my-keeper
```

The reference resolves to individual Keeper services. If the number of Keeper replicas changes, the configuration in the CHI is automatically adjusted. 

There were also a lot of behind-the-scenes changes to improve Keeper reliability and performance in Kubernetes. With the 0.27.0 release, the operator now has GA-level Keeper support.

## Monitoring Customization

The operator is bundled with a metrics-exporter sidecar that scrapes ClickHouse metrics and makes them available for Prometheus. While the ClickHouse server can expose metrics by itself, having centralized control is often an advantage, since it does not depend on behavior changes between ClickHouse versions. It also allows us to expose metrics missing in standard ClickHouse, like table-level statistics.

The default metrics-exporter implementation is sufficient for most cases. But sometimes users want to add additional metrics. Those could be metrics from ClickHouse system tables or even from application tables. Now it is possible to do so by defining additional tables or views that would be picked up by metrics-exporter.  

```
  metrics:       tablesRegexp: "^(metrics|custom_metrics)$"
```

This is a regular expression that allows adding extra tables for scraping. By default the `system.custom_metrics` table or view is configured, but it can be changed of course. The structure of the table should match the `system.metrics` table. For example, let’s define the metric to measure latest user activity on the cluster:

```
CREATE OR REPLACE VIEW system.custom_metrics ( metric String, value Int64, description String)SELECT 'LastInsert' as metric,        toUnixTimestamp(max(event_time))::Int64 as value,        '' as description  FROM system.part_log  WHERE database != 'system' AND event_type = 'NewPart'UNION ALLSELECT 'LastQuery' as metric,        toUnixTimestamp(max(event_time))::Int64 as value,        '' as description  FROM system.query_log WHERE databases != ['system']
```

When queried, it produces an output like this:

```
   ┌─metric─────┬──────value─┬─description─┐1. │ LastInsert │ 1780905526 │             │2. │ LastQuery  │ 1780905528 │             │   └────────────┴────────────┴─────────────┘
```

It then appears in Prometheus as `chi_clickhouse_metric_LastInsert` and `chi_clickhouse_metric_LastQuery` correspondingly. Perhaps in a future version we will add such metrics as a standard.

So, we added an option to extend default metrics. But there are opposite cases as well when default metrics generate too much data. Now users may configure the operator to exclude certain metrics from monitoring. 

```
  metrics:    excludeRegexp:      - "^metric\\.(OS.*CPU[0-9]+|CPUFrequencyMHz_[0-9]+)$"
```

By default all OS/CPU host level metrics are excluded starting from version 0.27.0. We have found them rarely useful but saturating the network.

Of course, default behavior can be changed, too. All options are listed in operator configuration and can be customized using the [ClickHouseOperatorConfiguration](https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/70-chop-config.yaml) resource.

## Pre/Post Hooks

Another interesting new feature is pre/post hooks. There could be multiple use cases for them, but one of the most important is graceful shutdown.

The operator already uses best efforts to make restarts and shutdowns of ClickHouse nodes as smooth as possible. It waits for queries to finish and so on. But in some cases even more advanced behavior is needed. For example, when scaling down Antalya Swarm clusters, we may want to exclude swarm nodes from [dynamic cluster autodiscovery](https://docs.altinity.com/altinityantalya/antalya-reference/#configuring-swarm-cluster-autodiscovery) before shutting them down. It can be done via the following hook:

```
 reconcile:    host:      hooks:        pre:          - sql:              queries:                - "SYSTEM STOP SWARM MODE"            events:              - HostShutdown
```

Stopping swarm mode prevents the node from receiving new tasks for distributed queries. The node finishes processing already assigned tasks before it can safely shut down without errors.

## FIPS mode

FIPS-140-3 is an important requirement for software that runs in regulated environments and requires a high level of network and data protection. Following [Altinity.Stable FIPS ClickHouse builds](https://docs.altinity.com/altinitystablebuilds/fips-compatible-altinity-builds/) we have added [FIPS controls](https://github.com/Altinity/clickhouse-operator/blob/0.27.1/docs/security_hardening_fips.md) to the operator itself. Starting from the [0.27.1](https://github.com/Altinity/clickhouse-operator/releases/tag/release-0.27.1) release, it is built with FIPS-approved cryptographic modules and satisfies FIPS-140-3 security requirements to the operator itself and managed ClickHouse and Keeper clusters. There is a special ACVP mode (Automatic Cryptographic Validation Protocol) that confirms all cryptographic modules are correct. We have also provided a [FIPS deployment example](https://github.com/Altinity/clickhouse-operator/blob/0.27.1/docs/fips_setup.md) that demonstrates how to configure all components properly for a regulated environment. 

## OpenShift Availability

Over many years users were asking us how to run ClickHouse on OpenShift Container Platform. (This is what RedHat calls Kubernetes these days.) Finally we have an answer: the Altinity Operator is now available in [the repository of community operators for OpenShift](https://operatorhub.io/operator/clickhouse)! So if you were unsure how to run ClickHouse on OpenShift, be of good cheer! It is now fully supported.

## Final Words

As ClickHouse gets more and more popular the variety of use cases increases. Altinity Kubernetes Operator for ClickHouse® keeps extending its capabilities and adapts to new user requirements and operational environments. We do our best to keep up with user requests, and welcome the contributions. Thanks to AI, it is now easier to submit contributions, and we see the growth or pull requests co-authored with the help of AI. It always requires a careful review and sometimes requires a complete rewrite, but it allows us to release improvements even faster than before. Stay tuned for [new releases](https://github.com/Altinity/clickhouse-operator/releases).