Skip to main content
このガイドでは、Operatorを使用して ClickHouse および Keeper のクラスターを設定する方法を説明します。

ClickHouseCluster の設定

基本設定

レプリカと分片

  • レプリカ: 各分片あたりの ClickHouse インスタンス数 (高可用性のため)
  • 分片: 水平分割数 (スケーリングのため)
replicas: 3、shards: 2 のクラスターでは、ClickHouse ポッドが合計 6 つ作成されます。

Keeper インテグレーション

すべてのClickHouseクラスターには、協調のためのKeeperアンサンブルが必要です。keeperClusterRef と externalKeeper のいずれか一方のみを 設定してください。両方を設定したクラスター、またはどちらも設定していないクラスターは拒否されます。 このオペレーターが管理するKeeperClusterを keeperClusterRef で指定します。
keeperClusterRef.namespace が設定されている場合、オペレーターは両方のネームスペースを監視する必要があります。WATCH_NAMESPACE が設定されている場合は、その一覧に ClickHouse と Keeper のネームスペースを含めてください。

外部で管理される Keeper

オペレーターの管理対象外の Keeper アンサンブルを使用して ClickHouse を実行するには、externalKeeper を使用します。たとえば、別のオペレーターが所有するアンサンブル、別の Kubernetes クラスターで稼働しているアンサンブル、仮想マシンや ベアメタル上で稼働しているアンサンブル、または複数のシステムで共有されているアンサンブルが該当します。
port のデフォルトは 9181 です。host には DNS 名または IP アドレスを指定します。IPv6 アドレスは角括弧で 囲んでください。TLS で接続するには tls: Enabled を設定し、port にはアンサンブルがセキュア接続を待ち受ける ポート番号を指定します。
ClickHouse は、Keeper の証明書をシステムのトラストストアに加え、設定した caBundle を用いて検証します。 ClickHouse と Keeper 間の TLS 通信を参照してください。 複数の ClickHouse クラスターで 1 つの Keeper アンサンブルを共有する場合は、settings.extraConfig を使用して各クラスターに専用のルート znode を割り当て、 レプリケーションのメタデータ、SQL で定義されたユーザー、名前付きコレクションが 互いに衝突しないようにしてください。znode は ClickHouse の起動前に作成し、以降は変更しないでください:
zookeeper.root を settings.extraReloadableConfig に含めないでください。リロードによって稼働中のクラスターのルートが切り替わり、レプリケートテーブルが読み取り専用になってしまいます。ルート znode にアクセス制御リストが設定されている場合は、 クラスターの keeper-identity に子 znode の作成を許可しておく必要があります。 オペレーターはこれらのサーバーに変更を加えず、ClickHouse をリコンサイルする前にこれらのサーバーの準備完了を待つこともありません。 アンサンブルの可用性の維持は、ユーザー側の責任となります。 認証の仕組みは、オペレーターが管理する Keeper の場合と同じです。オペレーターはクラスターの Secret から keeper-identity キーを読み取り、ClickHouse に渡します。Secret の構成については External Secret を参照してください。

KeeperCluster の設定

終了時のリーダーシップ移譲

Keeper コンテナーにはデフォルトで preStop hook が設定されています。この hook は、停止前にレプリカへ Raft リーダーシップの移譲を要求し、移譲が完了するのを待ってから コンテナーを終了させます。この処理は、オペレーターが開始したロールアウトに限らず、コンテナーが 正常停止するたびに実行されます。descheduler によるエビクション、ノードのドレイン、オートスケーラー の操作のいずれでも同じ hook がトリガーされます。これは、この hook がリコンサイルループのロジックではなく、 キューブレットレベルの preStop ハンドラーだからです。 この仕組みがないと、現在のリーダーを再起動した際、新しい選出が完了するまで ensemble にリーダーが 存在しない状態になります。選出には負荷状況によって数秒かかることがあり、ClickHouse 側では Keeper の接続断やクエリレイテンシの増加として現れます。この hook は、リクエストを送信してすぐにコンテナーを停止させるのではなく、レプリカに リーダーシップの譲渡を要求したうえで (Keeper の 4 文字コマンド ydld を http_control ポート経由で送信) 、レプリカがリーダーでなくなるまでステータスをポーリングします。 fire-and-forget 方式のリクエストでは、書き込み負荷が高い状況で SIGTERM との競合に負ける可能性があります。 待機することで、リーダー不在の期間を一定の範囲内に抑えられます。 この hook は設定不要で、非対応の環境でも問題なく動作します。ここで使用するリーダーシップコマンドにまだ対応していない 26.3 より前の Keeper バージョンでは、リクエストは何も行わず、 コンテナーは hook がない場合と同様に停止します。この hook はシェルスクリプトを実行するため、 イメージに bash が必要です。distroless または scratch の Keeper イメージを使用する場合は、 containerTemplate.lifecycle で hook を上書きまたは削除してください。詳細は API リファレンス を参照してください。

ストレージ構成

dataVolumeClaimSpec (標準的な Kubernetes の PersistentVolumeClaimSpec) を使用して永続ストレージを設定します。オペレーターはこれをレプリカごとの PersistentVolumeClaim に変換し、 データパス /var/lib/clickhouse にマウントします:
オペレーター が既存の PVC を変更できるのは、基盤となる StorageClass がボリューム拡張に対応している場合のみです。
マルチディスク (JBOD) レイアウトでの追加ディスクの接続、永続 ボリュームなしでの実行、容量の拡張、カスタムストレージポリシー、保存時暗号化、および作成後に何を 変更できないかに関するルールについては、専用の ストレージとボリュームのガイドで説明しています。

クラスター ドメイン

spec.clusterDomain は、オペレーター が ClickHouse server の 設定に書き込む完全修飾のポッドホスト名を生成する際に使用する、Kubernetes の DNS 接尾辞を設定します。既定値は cluster.local で、 ClickHouseCluster と KeeperCluster の両方にあります。
ClickHouse レプリカ用に、オペレーターはクライアントトラフィックを処理するヘッドレス Service <cluster-name>-clickhouse-headless を作成します。 また、内部トラフィックおよびオペレーターからの管理リクエスト向けに、Ready でないポッドを公開するレプリカごとの Service <cluster-name>-clickhouse-internal-<shard>-<index> も作成します。 これは、レプリカ自体が Ready になれない場合のレプリカ復旧に使用できます。 Keeper ノードは、ヘッドレス Service を介してポッド名を使用します: <pod>.<headless-service>.<namespace>.svc.<clusterDomain>。
これを上書きするのは、クラスターの キューブレット が cluster.local 以外の --cluster-domain で実行されている場合だけにしてください。値が実際のクラスター ドメインと一致しないと、 ClickHouse は Keeper とレプリカのホスト名を解決できず、協調と Distributed クエリは DNS 名前解決エラーで失敗します。参照先の KeeperCluster と ClickHouseCluster の両方に、同じ値を設定してください。

ポッドの設定

トポロジースプレッドとアフィニティの自動設定

ポッドをアベイラビリティゾーン間に分散します:
Kubernetesクラスターに、分散制約を満たせるだけのノードが異なるゾーンに十分にあることを確認してください。
ノードのオートスケーラー (Karpenter、Cluster Autoscaler) を使用している場合、分散制約だけでは、まだノードが存在しないゾーンをプロビジョニングすることはできません。スケジューラーは認識できるゾーンの範囲で妥協してしまいます。 分散を強制するには、topologyMinDomains にアベイラビリティゾーンの数を設定します:
topologyMinDomains には topologyZoneKey が必要です。要求した数よりも利用可能なゾーンが少ない間、ポッドは Pending のままになるため、クラスターが提供できるゾーン数の範囲内に収めてください。

手動設定

ポッドのアフィニティ/アンチアフィニティ ルールやトポロジースプレッド制約を任意に指定できます。

サポートされているすべてのポッドテンプレートオプションについては、API リファレンスを参照してください。

ポッドの停止予算

オペレーターは、各クラスターに対して PodDisruptionBudget (PDB) を作成します。これにより、自発的な中断 (ノードのドレイン、ローリングアップグレード、オートスケーラーによるエビクション) が発生しても、クォーラムの喪失や可用性の低下につながるほど多くのポッドが停止しないようにできます。 複数の分片を持つ ClickHouse クラスターでは、分片ごとに 1 つの PDB が作成されます。これにより、ある分片での中断が別の分片の許容範囲として扱われることはありません。

デフォルト

オペレーターはクラスターのサイズに応じて安全なデフォルト値を選択するため、新規に apply した時点で、意図しないクォーラムの喪失から保護されます。 replicas: 3 の 3 分片 ClickHouseCluster では、オペレーターは分片ごとに 1 つずつ、合計 3 つの PDB を作成し、それぞれに minAvailable: 1 を設定します。

デフォルト設定の上書き

spec.podDisruptionBudget を使用して、minAvailable または maxUnavailable のいずれか一方のみを上書きできます (必ずどちらか一方のみ) :
または、パーセンテージで指定する maxUnavailable 形式:
minAvailable と maxUnavailable の両方を設定すると、検証 webhook によって拒否されます。どちらか一方を選んでください。Kubernetes 自体も、この 2 つを同時に許可していません。
生成される PDB に unhealthyPodEvictionPolicy フィールドをそのまま渡すこともできます。これは、まだ NotReady 状態のポッドのエビクションを許可する必要がある場合に便利です。

ポリシー

spec.podDisruptionBudget.policy では、オペレーターが PDB をどの程度積極的に管理するかを選択できます。 例 — 開発用クラスターで PDB 管理を完全に無効にする:
例 — 手動で作成した PDB をクラスターと同じ場所に置き、オペレーターがそれを変更しないようにします:

クラスター全体での無効化

PDB の管理は、オペレーターの ENABLE_PDB 環境変数を使用して、クラスター全体で無効にすることもできます。ENABLE_PDB=false の場合、オペレーターは すべての ClickHouseCluster と KeeperCluster について、spec.podDisruptionBudget.policy の設定にかかわらず PDB のリコンサイル手順をスキップし、PodDisruptionBudget リソースを一切監視しません。そのため、オペレーターの ServiceAccount には poddisruptionbudgets.policy/v1 に対する RBAC 権限は不要です。これは、それらの権限を意図的に含めていない制限付きの ServiceAccount でオペレーターを実行する場合に便利です。
これは、独自の中断ポリシー (たとえば Gatekeeper / Kyverno 経由) を備えており、オペレーターを完全に関与させたくない環境を対象としています。

コンテナーの設定

カスタムイメージ

特定のClickHouseイメージを使用します。

コンテナーのリソース

ClickHouse コンテナーの CPU とメモリを設定します。

環境変数

任意の環境変数を追加します:

ボリュームマウント

追加のボリュームマウントを設定します:
同じmountPathに対して複数のボリュームマウントを指定できます。 Operator は、指定されたすべてのマウントを含む projected volume を作成します。

ヘルスプローブ

オペレーターは、すべての ClickHouse および Keeper コンテナーに liveness プローブと readiness プローブを設定します。 デフォルトでは startup プローブは設定されません。 ClickHouse と Keeper では、デフォルトのタイミング設定は共通です。 ClickHouse は、テーブルのロード前に interserver リスナーを開き、ロード完了後にクライアントリスナーを開きます。そのため、テーブルのロードに時間がかかっても liveness プローブは失敗しません。一方、readiness プローブが成功していれば、そのレプリカはクエリを処理できる状態にあります。 どちらのリソースでも、spec.containerTemplate を使用して任意のプローブをオーバーライドできます。たとえば、ClickHouse の liveness プローブは次のようにカスタマイズします。
プローブを設定すると、オペレーターのデフォルト設定は完全に置き換えられます。フィールド単位でマージされるわけではありません。 ハンドラー (httpGet、tcpSocket、exec のいずれか) と、必要なタイミング関連のフィールドをすべて指定してください。省略したフィールドには、上記のオペレーターの値ではなく Kubernetes のデフォルト値 (例:timeoutSeconds: 1、failureThreshold: 3) が適用されます。

startup プローブ

コンテナーの起動に liveness プローブで許容される時間より長くかかる場合は、startupProbe を使用します。デフォルト設定では、liveness プローブで許容されるのは、約 60 秒の初期遅延に加えて、5 秒間隔で 10 回チェックが失敗するまでの時間です。 Kubernetes はstartup プローブが成功するまで liveness プローブと readiness プローブの実行を保留するため、起動に時間がかかっても再起動ループに陥ることはありません。 例えば、大きなスナップショットをリプレイする Keeper レプリカに、接続の受け付けを開始するまで最大 10 分の猶予を与えるには、次のように設定します。
startup プローブが成功すると、以降は通常の liveness プローブと readiness プローブが引き継ぎます。

サポートされているすべての コンテナー テンプレートオプションについては、API リファレンスを参照してください。

TLS/SSL の設定

セキュアなエンドポイントを設定する

セキュアなエンドポイントを有効にするには、TLS 証明書を含む Kubernetes Secret への参照を指定します

SSL 証明書 Secret の形式

Secret には、サーバーのキーペアが含まれている必要があります。
  • tls.crt - PEM エンコードされたサーバー証明書
  • tls.key - PEM エンコードされた秘密鍵
この形式は、cert-manager によって生成された証明書と互換性があります。

TLS を介した ClickHouse-Keeper 通信

keeperClusterRef で参照される KeeperCluster で TLS が有効になっている場合、ClickHouseCluster は Keeper ノードへのセキュアな接続を自動的に使用します。 externalKeeper を使用する場合は、代わりに tls: Enabled を設定し、各ノードの port をアンサンブルのセキュアなクライアントポート (たとえば 9281) に設定します。 ClickHouseCluster は、システムのトラストストアに加えて、設定した caBundle を使用して Keeper ノードの証明書を検証します。 プライベート CA (たとえば、自己署名 CA や内部 CA) を信頼するには、カスタム CA バンドルへの参照を指定します。

External Secret

デフォルトでは、オペレーター はクラスターの内部認証情報 (interserver password、management password、Keeper identity、cluster secret、named-collections key) を含む Secret を作成して管理します。この Secret にはクラスター名が付けられ、クラスターのネームスペース内に作成されます。 これらの認証情報を自分で管理したい場合 (たとえば、HashiCorp Vault、AWS Secrets Manager、または External Secrets Operator から取得する場合) は、spec.externalSecret を使用して、既存の Secret をオペレーター に指定します。
参照先のSecretは、ClickHouseClusterと同じネームスペース内に存在している必要があります。オペレーターが自ら作成していないSecretを削除することはありません。

必須のキー

Secret には、次のキーが含まれている必要があります。 完全な Secret は次のようになります。

ポリシー: Observe と Manage

spec.externalSecret.policy は、必須キーが不足している場合に オペレーター がどのように扱うかを制御します。
policy: Manage を指定していても、Secret はそのネームスペース内にあらかじめ存在している必要があります。オペレーター は Secret 自体を作成せず、既存の Secret に生成したキーを書き込むだけです。参照先の Secret が存在しない場合、ポリシーに関係なく ExternalSecretNotFound reason で リコンサイル処理 は停止されます。
外部システム (Vault、ESO、sealed-secrets、GitOps) を信頼できる情報源として扱い、設定ミスがあれば オペレーター に明確に失敗させたい場合は Observe を選択してください。自己完結的な Bootstrap を行いつつ、Secret オブジェクト自体の管理権は保持しておきたい (たとえばバックアップしたい) 場合は Manage を選択してください.

ステータス条件とトラブルシューティング

オペレーターは ClickHouseCluster.status.conditions に ExternalSecretValid 条件を出力します。リコンサイルが停止しているように見える場合は、この条件を確認してください。
考えられる理由: Secret が無効な間、オペレーター はリコンサイルを再キューするため、不足しているキーを追加すれば、次回のリコンサイルで自動的に反映されます。ポッドを再起動する必要はありません。
必要なキーのセットは、実行中の ClickHouse のバージョンによって異なります。named-collections-key が検証されるのは、オペレーター の version probe が ClickHouse 25.12 以降を検出した場合のみです。古いバージョンでは、このキーが Secret に含まれていなくても問題ありません。disk-encryption-key が必要になるのは、spec.settings.encryption が設定されている場合のみです。

追加ポート

オペレーターは、すべての ClickHouse ポッドとそのパブリックヘッドレス Service で、固定のポート群を公開します。具体的には、8123 HTTP、9000 ネイティブ、9009 interserver、9001/9002 management、9363 Prometheus メトリクス、さらに TLS が有効な場合は TLS 用の 8443/9440 です。interserver および management ポートは、レプリカが Ready になる前にレプリカとオペレーターが通信できるよう、レプリカごとの内部 Service を通じても公開されます。ClickHouse で MySQL、PostgreSQL、gRPC、または任意のカスタムポートなどの追加プロトコルを待ち受けるようにするには、spec.additionalPorts で宣言します。
オペレーター は、それらのポートをポッドの containerPorts とパブリック ヘッドレス Service に追加します。 完全な例は、examples/custom_protocols.yaml にあります。
additionalPorts は、Kubernetes 側でのみポートを開きます。これだけでは、ClickHouse server がそれらのポートで待ち受けるようには設定されません。対応するプロトコルを spec.settings.extraConfig.protocols で有効にする必要もあります。これを行わないと、Service 上ではポートが開いていても、ポッド内では何も応答しません。

エンドツーエンドの例: MySQLワイヤプロトコル

ポート 9004 で ClickHouse を MySQLワイヤプロトコル経由で公開するには:
適用後、クラスター内で確認します:

フィールドの制約

予約済みのポートと名前

validating webhook は、オペレーター 自身がバインドするポートと競合する additionalPorts エントリを拒否します。TLS 関連のポートは、後から spec.settings.tls.enabled を切り替えても、それまで有効だったクラスターが壊れないよう、無条件で予約されています。 次の名前も拒否されます。これらは オペレーター の内部的なプロトコル種別の識別子であり (人が読める別名ではありません) 、以下のとおりです。 拒否されたリクエストでは、次のようなエラーが生成されます。

バージョンプローブとアップグレードチャネル

オペレーターは、クラスターのバージョンに関して 2 つの独立した処理を行います。
  1. バージョン報告 — ClickHouseCluster では、Kubernetes の Job がコンテナーイメージを 1 回実行して実行中の ClickHouse のバージョンを検出します。KeeperCluster では、オペレーターが実行中のレプリカからサーバーが報告するバージョンを読み取ります。検出されたバージョンは .status.version に記録され、他の リコンサイル ステップで使用されます (たとえば、External Secret の named-collections キーは ClickHouse 25.12 以降でのみ必要です) 。
  2. アップグレードチャネル — 公開されている ClickHouse のリリースフィード (https://clickhouse.com/data/version_date.tsv) を定期的に確認します。オペレーターは、新しいバージョンが利用可能かどうかを VersionUpgraded ステータス条件で報告します。クラスターを自動的にアップグレードすることはなく、イメージタグはユーザーが管理します。

リリースチャネルの選択

spec.upgradeChannel は、オペレーターが比較対象とするアップストリームのリリース群を選択します。このフィールドは ClickHouseCluster と KeeperCluster の両方にあります。
許可される値 (CRD によりパターン ^(lts|stable|\d+\.\d+)?$ で検証) : 本番環境では、通常、チャネルを明示的な <major>.<minor> (例: 25.8) に固定することが推奨されます。これにより、クラスターを意図したメジャー release 系列に固定でき、いずれかのレプリカが何らかの理由で別のメジャーへずれてしまった場合に、オペレーターが WrongReleaseChannel 警告を表示できるようになります。これは特に、イメージが人が読めるタグではなくダイジェスト (@sha256:...) で参照されている場合に重要です。デフォルトの空値は、メジャーバージョンのジャンプが問題にならない開発用クラスターであれば問題ありません。

ステータス条件

プローブとアップグレードチェックの結果は、次の 2 つの条件に反映されます。 次のように確認します:

バージョンプローブ Job のオーバーライド

これは ClickHouseCluster にのみ適用されます。KeeperCluster では version-probe Job は実行されなくなりました。バージョンは実行中の Keeper レプリカから直接読み取られるため、spec.versionProbeTemplate は非推奨であり、KeeperCluster では効果がありません。 この probe は通常の Kubernetes Job として実装されています。クラスターで、特定の Tolerations、node selector、security context を必須とする Admission ポリシーが設定されている場合や、完了後の probe Job の保持期間を制限したい場合は、spec.versionProbeTemplate でテンプレートをオーバーライドします:
コンテナー名 version-probe はオペレーターのデフォルトです。containers: 配下の項目は名前でこれに一致するため、オペレーターはユーザー指定のフィールドをデフォルトに対してディープマージします。

オペレーター全体に適用される制御

オペレーターマネージャーの 2 つのフラグで、アップグレードチェックのループ全体を制御します。 エアギャップ環境、または clickhouse.com への egress が許可されていない場合は、--disable-version-update-checks=true を設定してください。

ClickHouse の設定

default ユーザーのパスワード

spec.settings.defaultUserPassword は、組み込みの default ユーザーのパスワードを設定します。値は、CR に直接記述するのではなく、 作成した Secret (推奨) または ConfigMap のキーから指定してください。
secret または configMap のいずれか一方のみを指定し、どちらの場合も name (オブジェクト) と key (パスワードを保持するエントリ) の両方を指定してください。

パスワードの種類

passwordType は、値をどのように解釈するかを ClickHouse に指定します。デフォルトは password (平文) で、代わりに password_sha256_hex や password_double_sha1_hex などのハッシュ形式も使用できます。平文が 保存されないよう、ハッシュ化された種類を使用することを推奨します。完全な一覧は、 ClickHouse のユーザー設定 を参照してください。

Secretを使った完全な例

Secretを作成し、そのキーを参照します。
passwordType: password を使用すると、ポッド内の clickhouse-client が このパスワードで設定されるため、デバッグに便利です。
パスワードをハッシュ化する場合は、平文ではなくハッシュ値を保存します。

ConfigMap を使用する

ConfigMap も同じように機能しますが、その内容は Secret のように保護されません。 機密性のない値、またはすでにハッシュ化されている値にのみ使用してください。たとえば、 password_sha256_hex ダイジェストです。
平文のパスワードを ConfigMap に入れないでください。平文の値 (passwordType: password) には、必ず Secret を使用してください。

設定でのカスタムユーザー

設定ファイルで追加ユーザーを設定します。 ユーザー用のConfigMapとSecretを作成します。
ClickHouseCluster にカスタム設定を追加します:

データベース同期

新しいレプリカのデータベース自動同期を有効にします。
有効にすると、オペレーターは Replicated テーブルとインテグレーション テーブルを新しいレプリカに同期します。 各レプリカ ポッドには clickhouse.com/ReplicaInitialized readiness gate が設定されているため、新しいレプリカは、オペレーターによる初期化が完了した後にのみ パブリック ヘッドレス Service を介して公開されます。初期化時に、default データベースは Replicated engine に変換され、スキーマが同期されます。それまでは、オペレーターと他のレプリカは内部 Service を介してそのレプリカにアクセスします。enableDatabaseSync: false の場合、オペレーターはレプリカを直ちに初期化済みとしてマークするため、readiness はコンテナー probe のみに従います。 オペレーターがデータを含む非 Replicated の default データベースを drop することはありません。このようなレプリカもスキーマの準備後にクライアントトラフィックの処理を開始しますが、そのデータベースを自分で解決するまで、クラスターは reason DefaultDatabaseNotReplicated を伴う SchemaInSync=False を報告します。 scale-down でレプリカが削除される前に、オペレーターはまずそのレプリカへのクライアントトラフィックの振り分けを停止し、公開が停止するまで待機してから、残りのデータを存続するレプリカに複製し、その後で削除します。

サーバーロギング

spec.settings.logger で ClickHouse server のログを設定します。すべてのフィールドは省略可能で、安全なデフォルト値が設定されているため、何も変更していないクラスターでも、コンテナーのコンソールとディスク上のローテーションされるファイルの両方に information レベルでログが出力されます。
オペレーターは、kubectl logs が使えるよう、常にコンソールへのログ出力を有効にしています。logToFile が true の場合は、それに加えてファイルへのログ出力も有効にします。既定値を使用するクラスターでは、次の ロガー ブロックが生成されます。
同じ spec.settings.logger ブロックは KeeperCluster にも適用されます。この場合、オペレーターはファイルを代わりに /var/log/clickhouse-keeper/ 配下へ書き込み、Raft ロガー (raft_logs_level) を同じ level に設定します。
logToFile の設定にかかわららずコンソールへのログ出力は有効なままなので、ファイルロギングを無効にしても kubectl logs は引き続き利用できます。JSON を解析する構造化ログストアにログを送る場合は、jsonLogs: true を設定してください。

システムログテーブル

オペレーターは、システムテーブル query_log、part_log、text_log、metric_log、asynchronous_metric_log を有効にします。これらのテーブルはデータと同じボリュームに保存されるため、spec.settings.systemLogsTTLDays でテーブルの有効期限 (TTL) を設定します。このフィールドを指定せずにクラスターを作成すると、デフォルト値を設定する webhook が 30 を設定します。TTL を明示的に無効にするには、0 を設定します。
デフォルト値が適用されるのは、新しく作成するクラスターのみです。systemLogsTTLDays の導入前に作成されたクラスターでは、このフィールドを設定するまでシステムログテーブルに有効期限 (TTL) は設定されません。
有効期限 (TTL) は、次回のサーバー再起動時に有効になります。テーブルごとの有効期限 (TTL) の上書き、その他のシステムログ設定の調整、@remove 属性を使ったテーブルの無効化は、いずれも extraConfig で行えます。
無効化したテーブルは削除されません。自分でテーブルを削除するまで、既存のデータはディスク上に残ります。
ClickHouse は有効期限 (TTL) が変更されたシステムテーブルを再作成し、古いデータを system.text_log_0 などのリネーム後のテーブルに保持します。過去のデータが不要になったら、これらのテーブルを削除してください。

カスタム設定

埋め込みの追加設定

カスタムの設定ファイルをマウントする代わりに、追加の ClickHouse 設定オプションを直接指定できます。 extraConfig を使用して、カスタムの ClickHouse 設定を追加します。

再読み込み可能な追加設定

extraConfig を変更すると、ClickHouse のポッドが再起動します。オペレーターは、どの設定を再起動せずに適用できるか判断できないためです。ClickHouse が稼働中に再読み込みできる設定 (代表例は named_collections) には、代わりに extraReloadableConfig を使用してください。オペレーターは、ポッドを再起動せずに設定を再読み込みして変更を適用します:
各トップレベルセクションは、extraConfig と extraReloadableConfig のいずれか一方にのみ記述してください。同じセクションを両方に記述すると、オペレーターが警告を出します。
extraReloadableConfig を使用する場合、そこに記述した設定は再読み込みしても問題ないものとみなされます。再起動が必要な設定をここに記述してもエラーにはならず、次回の再起動時に反映されます。

埋め込み追加ユーザー設定

extraUsersConfig を使用すると、追加の ClickHouse ユーザー設定を指定することもできます。これは、ユーザー、プロファイル、クォータ、権限をクラスター仕様内で直接定義する場合に便利です。
extraUsersConfig は k8s の ConfigMap オブジェクトに保存されます。平文のシークレットはそこに保存しないでください。

サポートされているすべての ClickHouse ユーザー設定オプションについては、ドキュメントを参照してください。

設定例

設定例全体は次のとおりです:

定期的な再同期

オペレーターは、Kubernetesのイベントに反応するだけでなく、一定間隔ですべてのクラスターを再度リコンサイルします。これにより、watchでは検知できない状態 (ClickHouseのレプリカのヘルス、Keeperのクォーラムなど) についてもステータス条件を最新に保ち、スタックしたポッドのクリーンアップといった修復処理を再試行します。 この間隔は、オペレーターの環境変数 RESYNC_PERIOD (デフォルトは 30s) で制御します。これは KeeperCluster リソースに適用され、0 を指定すると定期的な再同期が無効になります。ClickHouseCluster リソースは30秒ごとにClickHouseの system.warnings をポーリングしており、その時点でリコンサイルが再度トリガーされるため、現時点では RESYNC_PERIOD は影響しません。
オペレーターは複数のクラスターを同時にリコンサイルします。コントローラーあたりのリコンサイルの最大同時実行数は、MAX_CONCURRENT_RECONCILES (デフォルトは 4) で設定します。

リコンサイルの一時停止

ClickHouseCluster または KeeperCluster に clickhouse.com/pause-reconciliation: "true" アノテーションを設定すると、オペレーターによるリコンサイルを停止できます。オペレーターは一時停止中のリソースについて、理由を ReconciliationPaused として ReconcileSucceeded=False を報告し、それ以外はリソースに手を加えません。オペレーターが手動で加えた変更を元に戻してしまう場合に役立ちます。一時停止中、オペレーターは Ready と Healthy を含むすべての状態条件を、理由を ReconciliationPaused として Unknown と報告します。この間、クラスターの状態は確認しません。再開するにはアノテーションを削除します。保留中の spec の変更は、次回のリコンサイル時に適用されます。