Confluent Operator および Confluent Platform の構成¶

Confluent Platform と Confluent Operator の構成手順は以下のとおりです。

グローバル構成ファイルを作成します。
グローバルインフラストラクチャ設定を構成します。
オプションで、Confluent Platform のコンポーネントレベルの設定を構成します。

このガイドの例では、以下が想定されています。

$VALUES_FILE は「グローバル構成ファイルの作成」でセットアップする構成ファイルのことです。
Operator ドキュメントで簡潔で明快な例を提示できるよう、すべての構成パラメーターが構成ファイル（ $VALUES_FILE ）に指定されます。ただし、本稼働環境でのデプロイにおいて、Helm を使用して機密データを扱う場合には、--set または --set-file オプションを使用します。以下に例を示します。
```
helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
```
operator は Confluent Platform のデプロイ先となる名前空間です。
コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

構成の概要¶

インストール中、Confluent Operator と Confluent Platform のコンポーネントは、複数の Helm チャート values.yaml ファイル（Operator 用に 1 つと各 Confluent Platform コンポーネント用に 1 つ）とグローバル構成ファイルに格納されているパラメーターに基づいて作成されます。

個々のコンポーネント用 values.yaml ファイルのパラメーターは変更しないでください。コンポーネントについてキャパシティの調整、パラメーターの追加、パラメーターの変更が必要な場合は、グローバル構成ファイルで該当コンポーネントのセクションを変更します。また、helm upgrade コマンドを使用したインストール後に構成パラメーターを調整することもできます。

グローバル構成ファイルは、インストールにおいては values.yaml ファイルの上層に位置付けられます。このファイルには、インストール前に変更できる環境固有の値が格納されます。

Helm バンドルをダウンロードすると、以下のようになります。

各 Confluent Platform コンポーネントの values.yaml ファイルが helm/confluent-operator/charts/<component>/ にあります。
Confluent Operator の values.yaml ファイルが helm/confluent-operator/ にあります。
各プロバイダーの <provider>.yaml ファイルが helm/providers/ にあります。

インストールにおいて、Helm によって値ファイルが以下の順に下層から読み込まれます。

Confluent Platform コンポーネントの values.yaml が読み込まれます。
Operator の values.yaml が読み込まれます。
グローバル構成ファイルが読み込まれます。

グローバル構成ファイルの作成¶

デフォルトの構成ファイルをカスタマイズするには、以下の手順に従います。

Confluent Operator バンドルのダウンロード先ディレクトリにある helm/providers ディレクトリに移動します。
使用プロバイダー環境に対応するプロバイダーファイルのコピーを作成します。たとえば、使用プロバイダーが Google Cloud の場合は、gcp.yaml をコピーして my-values.yaml を作成します。
使用する構成ファイルを指す環境変数を設定します。以下に例を示します。
```
export VALUES_FILE="/path/to/my-values.yaml"
```
以降、このトピックで $VALUES_FILE はこのグローバル構成ファイルのことです。

グローバル設定の構成¶

ここからは、Confluent Operator と Confluent Platform の初期デプロイに必要な構成変更について説明します。設定は、上記で作成した構成ファイル（ $VALUES_FILE ）に指定します。

この構成ファイルは、必要に応じてデプロイ後に手動でアップデートできます。詳細については、「構成のアップデート」を参照してください。

使用するリージョンとゾーン（使用する Kubernetes クラスターが複数のアベイラビリティゾーンにわたる場合は複数のゾーン）を確認または変更します。
ストレージクラスを指定します。
Docker イメージレジストリエンドポイントを確認または変更します。
Confluent Platform に Kubernetes 外からアクセスできるように DNS とロードバランサーを構成します。
ネットワークの暗号化、認証、認可を確認または構成します。
ライセンスキーを確認または構成します。

ライセンスキーの追加¶

Confluent Operator、Kafka、Confluent Control Center は、ライセンスキーがなくても 30 日間試用できます。30 日経過後は、Operator、Kafka、Control Center の使用にライセンスキーが必要です。

RBAC を使用する Confluent Platform を構成するには、Schema Registry のライセンスキーが必要です。

ライセンスキーを構成ファイル（ $VALUES_FILE ）に追加し、helm upgrade コマンドを実行してライセンス認証を行います。以降の例では、構成のアップデートに構成ファイル（ $VALUES_FILE ）の使用が想定されています。

Operator ライセンス¶

以下のセクションを構成ファイル（ $VALUES_FILE ）の Operator ブロックに追加し、ライセンスキーを指定します。

operator:
  licenseKey:

次のコマンドを実行して、ライセンス認証を行います。

helm upgrade --install <operator-release-name> \
  --values $VALUES_FILE \
  --set operator.enabled=true \
  ./confluent-operator

Kafka ライセンス¶

Kafka ライセンスの追加またはアップデートの手順は、次のとおりです。

以下のセクションを構成ファイル（$VALUES_FILE）の Kafka ブロックに追加し、ライセンスキーを指定します。
```
kafka:
  license:
```

次のコマンドでライセンス認証を行います。

helm upgrade --install <kafka-release-name> \
  --values $VALUES_FILE \
  --set kafka.enabled=true \
  ./confluent-operator

Kafka クラスターを再起動します。

Kafka ライセンスの追加またはアップデートを行うには、Kafka ポッドを再起動するか、Kafka クラスターをローリングして、Kafka クラスターを再起動する必要があります。

Confluent Control Center ライセンス¶

以下のセクションを構成ファイル（ $VALUES_FILE ）の Confluent Control Center ブロックに追加し、ライセンスキーを指定します。

controlcenter:
  license:

次のコマンドを実行して、ライセンス認証を行います。

helm upgrade --install <controlcenter-release-name> \
  --values $VALUES_FILE \
  --set controlcenter.enabled=true \
  ./confluent-operator

Schema Registry ライセンス¶

以下のセクションを構成ファイル（$VALUES_FILE）の Schema Registry ブロックに追加し、ライセンスキーを指定します。

schemaregistry:
  license:

次のコマンドを実行して、ライセンス認証を行います。

helm upgrade --install <schema-registry-release-name> \
  --values $VALUES_FILE \
  --set schemaregistry.enabled=true \
  ./confluent-operator

Confluent Platform バージョンの指定¶

Confluent Platform は、Confluent Platform コンポーネントごとに 1 つのイメージが用意された Docker イメージとして出荷されます。Confluent Platform の各リリースにはバージョン番号があり、そのリリースの Docker イメージは、Confluent の Docker Hub に配置され、バージョンがタグとして付けられています。

Confluent Operator では、デプロイする Confluent Platform のバージョンを指定できます。Operator の各リリースは、「サポートされているバージョン」に記載されているように、Confluent Platform の特定のバージョンをサポートしています。

デプロイを構成するときに、構成ファイル（$VALUES_FILE）でコンポーネントごとに、デプロイする Confluent Platform を指定します。

global:
  initContainer:
    image:
      tag:

<component>:
  image:
    tag:

たとえば、Kafka 6.0.1 をデプロイするには、以下のように指定します。

global:
  initContainer:
    image:
      tag: 6.0.1.0

kafka:
  image:
    tag: 6.0.1.0

カスタム Docker レジストリ¶

デフォルトで、Confluent Operator により、Docker Hub でホストされ公開されている Docker イメージが confluentinc リポジトリからデプロイされます。

イメージが Operator によって別のレジストリから、または Docker Hub 上の独自のリポジトリセットからデプロイされるようにするには、このセクションの以下の手順に従います。

Confluent リポジトリから目的のイメージをプルし、ターゲットレジストリ/リポジトリにプッシュします。

Docker イメージ URI のデフォルトリストは以下のとおりで、<tag> を、Operator ダウンロードディレクトリの IMAGES ファイルの対応するタグに置き換えます。

docker.io/confluentinc/cp-server-connect-operator:<tag>
docker.io/confluentinc/cp-enterprise-control-center-operator:<tag>
docker.io/confluentinc/cp-server-operator:<tag>
docker.io/confluentinc/cp-operator-service:<tag>
docker.io/confluentinc/cp-ksqldb-server-operator:<tag>
docker.io/confluentinc/cp-enterprise-replicator-operator:<tag>
docker.io/confluentinc/cp-schema-registry-operator:<tag>
docker.io/confluentinc/cp-zookeeper-operator:<tag>
docker.io/confluentinc/cp-init-container-operator:<tag>

構成ファイル（ $VALUES_FILE ）で、以下の設定を構成します。
```
global:
  provider:
    registry:
      fqdn:                 ----- [1]
      credential:
        required:           ----- [2]
        username:           ----- [3]
        password:           ----- [4]
```
- [1] Docker レジストリの FQDN（完全修飾ドメイン名）です（ docker.io など）。
- [2] Confluent Docker イメージのプッシュ先レジストリ/リポジトリへのアクセスに認証が必要な場合は、ここを true に設定します。それ以外の場合は、false に設定します。
- [3] [2] を true に設定した場合は、使用する Docker レジストリのユーザー名をここに設定します。
- [4] [2] を true に設定した場合は、使用する Docker レジストリのパスワードをここに設定します。
global.provider.registry.credential.required: true のように設定した場合は、追加手順として、以下のセクションの説明に従って Kubernetes シークレットを構成します。

Docker レジストリ認証のための追加手順¶

global.provider.registry.credential.required を true に設定した場合は、Operator のデプロイ時に confluent-docker-registry という名前の Kubernetes シークレットオブジェクトを Operator のデプロイ先と同じ名前空間内に作成するために、ユーザー名とパスワードの値が使用されます。Kubernetes で残りの Confluent Platform コンポーネントのデプロイ時にこのシークレットを使用して必要なイメージをプルできるようにするには、1 つまたは複数の手順が必要となります。このセクションでは、一般的なシナリオをいくつか取り上げます。

シナリオ 1: すべての Confluent Platform コンポーネントを Operator と同じ名前空間にデプロイし、すべての Confluent Platform コンポーネントポッドを同じ名前空間の default サービスアカウントと関連付ける。

このシナリオでは、以下のコマンドを使用して、前述のシークレットを default サービスアカウントに関連付けます。
```
kubectl -n <namespace> patch serviceaccount default -p \
  '{"imagePullSecrets": [{"name": "confluent-docker-registry" }]}'
```
シナリオ 2: すべての Confluent Platform コンポーネントを Operator と同じ名前空間にデプロイし、Operator で管理する Confluent Platform コンポーネントクラスターごとに異なるサービスアカウントを関連付ける。

このシナリオでは、以下のコマンドを使用して、使用予定の追加サービスアカウントそれぞれに confluent-docker-registry シークレットを関連付ける必要があります。
```
kubectl -n <namespace> patch serviceaccount <serviceAccountName> -p \
  '{"imagePullSecrets": [{"name": "confluent-docker-registry" }]}'
```
シナリオ 3: Confluent Platform コンポーネントを Operator の名前空間とは異なる名前空間にデプロイする。

このシナリオでは、以下のコマンドを使用して、異なる名前空間それぞれに confluent-docker-registry シークレットオブジェクトのコピーを作成します。
```
kubectl get secret confluent-docker-registry -n <operatorNamespace> -o yaml | \
  kubectl apply -n <newNamespace> -f -
```
そのうえで、<newNamespace> の confluent-docker-registry シークレットを、Confluent Platform コンポーネントクラスターと関連付ける予定の名前空間に存在するすべてのサービスアカウントに関連付けます。

Confluent Platform コンポーネントのカスタムレジストリ¶

Operator によって、1 つの特定の Confluent Platform コンポーネントイメージが、別のレジストリからデプロイされるようにするには、このセクションの手順に従います。

目的のコンポーネントイメージと init コンテナーイメージ（cp-init-container-operator）を Confluent リポジトリからプルし、ターゲットレジストリにプッシュします。

このコンポーネントイメージと init コンテナーイメージは、同じリポジトリ内にある必要があります。

次のコマンドを使用してコンポーネントイメージをデプロイします。

helm upgrade --install \
  <component-helm-release-name> \
  ./confluent-operator \
  --values $VALUES_FILE \
  --namespace <namespace> \
  --set <component-helm-release-name>.enabled=true \
  --set <component-helm-release-name>.name=connect \
  --set global.provider.registry.fqdn=<custom-registry-endpoint> \
  --set global.provider.registry.credential.required=<true or false> \
  --set global.provider.registry.credential.username=<value if required> \
  --set global.provider.registry.credential.password=<value if required> \
  --set connect.image.repository=<custom-registry>/<custom-repository> \
  --set connect.image.tag=<custom-tag> \
  --set global.initContainer.image.repository=<mypath>/<name> \
  --set global.initContainer.image.tag=<custom-tag>

名前空間によるデプロイ¶

デフォルトで、Confluent Platform は Confluent Operator によってすべての名前空間にデプロイされます。Confluent Platform のデプロイ先名前空間を 1 つに限定して、その名前空間内のオブジェクトのみ調整する場合は、名前空間によるデプロイを有効にします。

名前空間によるデプロイの場合、クラスタースコープの Kubernetes リソースにアクセスしなくても Operator サービスを実行できます。Operator サービスによる管理対象は、デプロイ先名前空間内のリソースのみになります。

名前空間による Confluent Operator のデプロイを有効にするには、構成ファイル（ $VALUES_FILE ）で以下を設定します。

operator:
  namespaced: true

注釈

上述の手順に従っても、Confluent Operator によって必要なクラスターレベルの CustomResourceDefinition（CRD）の自動インストールはトリガーされません。CRD は、Operator と Confluent Platform のデプロイに先立って別途インストールする必要があります。手順については、「名前空間を使用するデプロイに必要なアクセス許可の付与」を参照してください。

Operator と Confluent Platform の名前空間によるデプロイに必要なアクセス許可については、「名前空間を使用するデプロイに必要なアクセス許可の付与」を参照してください。

作成済みのロールとロールバインディングを使用したクラスター全体へのデプロイ¶

Confluent Operator で ClusterRoleBinding を使用するために、以下のオプションが用意されています。

Confluent Operator Helm チャートにより、必要なロールとロールバインディングが Operator のインストール中に作成されます。これがデフォルトの動作です。
Kubernetes 管理者が ClusterRoles と ClusterRoleBinding を作成し、Confluent Platform 管理者が Operator のデプロイ時にそれらを使用します。

Kubernetes 管理者がセットアップした ClusterRoleBinding を使用するには、以下の手順に従います。

Kubernetes クラスターの管理者が ClusterRoleBinding をセットアップします。

ClusterRoleBinding の roleRef が ClusterRole と同じ名前であることを確認します。
Operator 構成ファイル（ $VALUES_FILE ）で、以下を設定します。
```
operator:
  installClusterResources: false
  namespaced: false
```

デフォルトコンポーネント設定の変更¶

グローバル構成ファイル（ $VALUES_FILE ）には、グローバル構成パラメーターが格納されます。values.yaml ファイルには、構成に追加可能なコンポーネント固有の追加パラメーターが含まれます。values.yaml には、各構成パラメーターとその使い方を説明する詳細なコメントも含まれます。以下の表に、各 values.yaml ファイルとその Confluent Operator ホームディレクトリにおける場所をリストします。

コンポーネント	チャート名	values.yaml のパス
Operator	operator	helm/confluent-operator/charts/operator/values.yaml
Kafka	kafka	helm/confluent-operator/charts/kafka/values.yaml
ZooKeeper	zookeeper	helm/confluent-operator/charts/zookeeper/values.yaml
Connect	connect	helm/confluent-operator/charts/connect/values.yaml
Schema Registry	schemaregistry	helm/confluent-operator/charts/schemaregistry/values.yaml
Control Center	controlcenter	helm/confluent-operator/charts/controlcenter/values.yaml
Replicator	replicator	helm/confluent-operator/charts/replicator/values.yaml
ksqlDB	ksql	helm/confluent-operator/charts/ksql/values.yaml

重要

コンポーネントの values.yaml ファイルは変更しないでください。コンポーネント構成パラメーターの使用または変更が必要な場合は、グローバル構成ファイル（ $VALUES_FILE ）で追加または変更を行います。他の values.yaml ファイルは、コンポーネント構成のインストール時やアップグレード時にグローバルプロバイダーファイルによってオーバーライドされます。

コンポーネント構成を変更するには、以下の手順を実行します。

使用する構成パラメーターブロックを values.yaml ファイルで探します。
構成パラメーターをグローバル構成ファイル（ $VALUES_FILE ）の適切な場所にコピーし、必要な変更を行います。

以下の upgrade コマンドを入力します。

helm upgrade --install \
  --values $VALUES_FILE \
  --set <component>.enabled=true \
  <component> \
  ./confluent-operator

たとえば、Kafka 構成パラメーターを変更するには、$VALUES_FILE ファイルへの構成変更の保存後、以下の upgrade コマンドを入力します。

helm upgrade --install \
  --values $VALUES_FILE \
  --set kafka.enabled=true \
  kafka \
  ./confluent-operator

コンテナーのメモリーと CPU の設定¶

必要なポッドリソースは、グローバル構成ファイル（ $VALUES_FILE ）のデフォルトパラメーターに指定されます。Confluent Operator と Confluent Platform のテスト段階では、示されているデフォルト値ほどはリソース要件が大きくない場合が考えられます。それでも、ZooKeeper と Kafka は個別のポッドや個別のノードにインストールされている必要があります。

重要

Confluent Platform デプロイのすべての機能を正常に動作させるには、Kafka ブローカーが少なくとも 3 つ必要です。1 または 2 ブローカー構成はサポートされていないため、開発テストや本稼働環境では使用しないでください。

Confluent Operator では、デプロイするすべての Confluent Platform コンポーネントについてポッドリソースの制限を定義できます。そのための設定は、各コンポーネントにつき、それぞれの values.yaml ファイルで、requests タグと limits タグを使用して定義します。

以下の例に、Kafka のグローバル構成ファイルスニペットに含まれるデフォルトのポッドリソースパラメーターを示します。詳細については、「コンテナのリソース管理」を参照してください。

## Kafka Cluster
##
kafka:
  name: kafka
  replicas: 3
  resources:
    ## It is recommended to set both resource requests and limits.
    ## If not configured, kubernetes will set cpu/memory defaults.
    ## Reference: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
    requests:
      cpu: 200m
      memory: 1Gi
    limits: {}

Kafka および ZooKeeper 構成のオーバーライド¶

Kafka と ZooKeeper のデフォルト構成パラメーターは、構成ファイル（ $VALUES_FILE ）で以下のキーを使用してオーバーライドできます。

zookeeper:
  configOverrides:
    server: []
    jvm: []
    log4j: []
kafka:
  configOverrides:
    server: []

変更できるのは、キー/値ペア形式の構成パラメーターの設定のみです。キーのみの構成パラメーターはオーバーライドできません。Kafka および ZooKeeper で使用される構成パラメーターについては、以下の Confluent ドキュメントを参照してください。

Kafka: 「ブローカーの構成」
ZooKeeper: 「構成オプション」

以下に Kafka の場合の変更例を示します。

auto.create.topics.enable の値が false （デフォルト値）から true へ。
ログレベルが INFO から DEBUG へ。

kafka:
  configOverrides:
    server:
      - auto.create.topics.enable=true
    jvm: []
    log4j:
      - log4j.rootLogger=DEBUG, stdout

upgrade コマンドを実行します。たとえば、Kafka を対象とするこのオーバーライドを追加する場合は、以下のコマンドを入力します。

helm upgrade --install \
  --values $VALUES_FILE \
  --set kafka.enabled=true \
  kafka \
  ./confluent-operator

Kafka inter broker version override¶

Operator により Kafka inter.broker.protocol.version が 2.3 に設定されます。デフォルトバージョンは、対応する Confluent Platform の Kafka ブローカーバージョンと一致するとは限りません。

Kafka の以降のバージョンで、Tiered Storage や Self-Balancing Clusters などの Kafka 機能を使用できるようにするには、Kafka config override を使用して、inter.broker.protocol.version および log.message.format.version プロパティを以降のバージョンに設定し、クラスターをローリングします。

特定のバージョンの Kafka に対して inter-broker version を使用するには、「Confluent Platform のアップグレード」を参照してください。

Operator 構成ファイル（$VALUES_FILES）の以下のスニペットにより、Kafka inter-broker protocol version が 2.4（Tiered Storage を有効にするために必要）に設定されます。

kafka:
  configOverrides:
    server:
      inter.broker.protocol.version=2.4
      log.message.format.version=2.4

スキーマ検証¶

スキーマ検証をセットアップするには、構成ファイル（$VALUES_FILE）で Kafka 構成のオーバーライドを使用します。

このセクションの例では、リリース名として schemaregistry を、また名前空間として operator を使用します。

<domain> 名を取得するには、helm status schemaregistry を実行します。

Schema Registry に HTTP でアクセスするには

内部アクセスの場合:

kafka:
  configOverrides:
    server:
      - confluent.schema.registry.url=http://schemaregistry.operator.svc.cluster.local:9081

外部アクセスの場合:

kafka:
  configOverrides:
    server:
      - confluent.schema.registry.url=http://<domain>:9081

Schema Registry に HTTPS でアクセスするには

Schema Registry への内部アクセスの場合:

kafka:
  configOverrides:
    server:
      - confluent.schema.registry.url=https://schemaregistry.operator.svc.cluster.local:8081

Schema Registry への外部アクセスの場合:

kafka:
  configOverrides:
    server:
      - confluent.schema.registry.url=https://<domain>:8081

Kafka が自己署名証明書を使用してデプロイされている場合は、次のプロパティを渡してオーバーライドします。

mTLS を使用した Schema Registry

kafka:
  configOverrides:
    server:
      confluent.ssl.keystore.location=/tmp/keystore.jks
      confluent.ssl.keystore.password=${file:/mnt/secrets/jksPassword.txt:jksPassword}
      confluent.ssl.key.password=${file:/mnt/secrets/jksPassword.txt:jksPassword}
      confluent.ssl.truststore.location=/tmp/truststore.jks
      confluent.ssl.truststore.password=${file:/mnt/secrets/jksPassword.txt:jksPassword}

TLS のみを使用した Schema Registry

kafka:
  configOverrides:
    server:
      confluent.ssl.truststore.location=/tmp/truststore.jks
      confluent.ssl.truststore.password=${file:/mnt/secrets/jksPassword.txt:jksPassword}

詳細については、Schema Registry ドキュメントの「スキーマ検証」を参照してください。

サービスアカウントの用意¶

Kubernetes で実行される各ポッドには、関連付けられたサービスアカウントがあります。このことは、Confluent Operator によってデプロイされる Confluent Platform コンポーネントポッドにも当てはまります。

サービスアカウントは、Confluent Operator デプロイのコンテキストにおいていくつかの機能を果たします。たとえば、Confluent Platform Docker イメージをプライベートの Docker イメージリポジトリからデプロイするためには、Docker レジストリ認証情報を Confluent Platform コンポーネントに関連付けられているサービスアカウントと関連付けます。

Confluent Platform のデプロイ時にサービスアカウントの指定は不要です。サービスアカウントを指定しなかった場合は、Operator によって、コンポーネントのデプロイ先である Kubernetes 名前空間のデフォルトサービスアカウントが関連付けられます。

カスタムサービスアカウントを指定するには、構成ファイル（ $VALUES_FILE ）のコンポーネントセクションに serviceAccountName を追加します。

<component>:
  serviceAccountName:

マウントされたシークレットの提供¶

Confluent Platform コンポーネントを Helm でインストールする場合、Kubernetes シークレットとして指定した機密の認証情報の構成値は、Helm チャートによってセキュアに格納されます。ただし、Helm チャートでシークレットオブジェクトを作成するのではなく、Confluent Platform の構成で使用する既存の独自シークレットを指定する状況が考えられます。そのうち最も一般的なのがカスタム構成オーバーライドの指定というシナリオで、この場合はオーバーライドが Helm チャートによってパススルー構成扱いされ、データがシークレットオブジェクトに属するかどうかは考慮されません。

独自のシークレットオブジェクトを活用するには、シークレットオブジェクトのリストを指定し、Confluent Platform コンポーネントのコンテナーにインメモリーでマウントします。Confluent Platform のシークレットの外部化機能、およびカスタム構成オーバーライドと組み合わせることで、機密情報を公開することなく、外部ファイルの情報の格納やキーファイルのコンテンツの受け渡しができるよう、独自のシークレットデータを使用して Confluent Platform を構成できます。

注釈

カスタム構成オーバーライドは、現在 ZooKeeper と Kafka についてのみサポートされています。

マウントされたシークレットを指定して使用するには、構成ファイル（ $VALUES_FILE ）のコンポーネント（具体的には Kafka または ZooKeeper）セクションに以下を追加します。

<component>:
  mountedSecrets:
  - secretRef:                                               ----- [1]
    keyItems:                                                ----- [2]
    - key:                                                   ----- [3]
      path:                                                  ----- [4]

  configOverrides:
    server:
      - some.property=${file:/mnt/secrets/<secretRef>:<key>} ----- [5]

[1] secretRef を、使用するシークレットの名前に設定します。
[2]（省略可能） keyItems の指定がない場合、シークレットは /mnt/secrets/<secretRef> に格納されます。<secretRef> は [1] で設定された値です。

Kubernetes でのシークレットの使用については、『Secret のキーの特定のパスへの割り当て』を参照してください。
[3] key をシークレットのキーに設定します。
[4] path をシークレットの key （[3]）の格納先に設定します。

たとえば、secretRef が my-secret-aws に、key が credentials に、path が aws/creds に設定された場合、credentials は /mnt/secrets/my-secret-aws/aws/creds に格納されます。
[5] 外部化されるファイルを ${file:/mnt/secrets/<secretRef>:<key>} フォーマットで設定します。

マウントされたシークレットを使用するワークフローの例を以下に示します。

機密データを含むファイル my_file.txt を用意します。
```
username: user1
password: $ecret_passw0rd
```
上記のファイルの内容をキー my_credentials に格納するシークレットオブジェクト example-secret を作成します。
```
kubectl create secret generic example-secret \
  --from-file=my_credentials=path/to/my_file.txt
```
my_file.txt の内容が Base64 でエンコードされ、example-secret の my_credentials キーに格納されます。

構成ファイル（ $VALUES_FILE ）に configOverrides と mountedSecrets を設定します。

kafka:
  configOverrides:
    server:
      - kafka.some.user=${file:/mnt/secrets/example-secret/my_credentials:username}
      - kafka.some.password=${file:/mnt/secrets/example-secret/my_credentials:password}

  mountedSecrets:
    - secretRef: example-secret

Kafka クラスターをデプロイまたはアップデートします。

helm upgrade --install kafka path/to/chart \
  -values $VALUES_FILE \
  --set kafka.enabled=true

ポッドのアノテーション¶

Confluent Operator でデプロイされた Confluent Platform コンポーネントにカスタムアノテーションを定義できます。定義したアノテーションは Operator によって作成された Kubernetes ポッドに適用されます。

構成ファイル（$VALUES_FILE）の各コンポーネントに podAnnotations を設定します。

podAnnotations は、文字列キーと文字列値とのマップであることが必要です。値に数やブール値などの他の型は使用できません。

一般に、アノテーション値は Kubernetes のアノテーション検証に合格する必要があります。詳細については、アノテーションに関する Kubernetes ドキュメントを参照してください。

以下の例に、いくつかの Confluent Platform コンポーネント向けの podAnnotations を示します。

zookeeper:
  podAnnotations:
    string: "value"
    number: "1"
    boolean: "true"
    list: "[{\"labels\": {\"key\": \"value\"}},{\"key1\": \"value1\"}]"

kafka:
  podAnnotations:
    key1: "value1"
    key2: "value2"

controlcenter:  # ...
  podAnnotations:
    key1: "value3"
    key2: "value4"

アフィニティ¶

Operator では、Confluent Platform クラスター用に Kubernetes のアフィニティ機能がサポートされています。

注釈

従来のアフィニティ実装で使用されてきた disableHostPort、nodeAffinity、rack の設定は現在でも使用できますが非推奨であり、Operator の今後のリリースで削除される予定です。

どの種類のアフィニティについても、種類が同じであれば PREFERRED ルールまたは REQUIRED ルールを複数指定できますが、PREFERRED ルールと REQUIRED ルールをどちらも指定することはできません。ルールのデフォルトの種類は PREFERRED です。

ノードアフィニティ¶

ノードアフィニティを使用すると、Confluent Platform ポッドのスケジュール先として指定できる Kubernetes ノードを指定できます。たとえば、1 つまたは複数のポッドの実行に使用する特別なハードウェアがある場合は、ノードアフィニティを使用して、該当するポッドをその特別なハードウェアノードに固定できます。

ノードアフィニティ機能は、Kubernetes ノードのラベルに基づいています。Kubernetes のビルトインラベルの使用、または独自のノードラベルの追加ができます。

affinity:
  nodeAffinity:
    key:            ----- [1]
    values:
    -               ----- [2]
    rule:           ----- [3]

[1] ノードラベルのキー。
[2] [1] のノードラベルの値。
[3] ルールの種類。PREFERRED または REQUIRED を指定します。デフォルトは PREFERRED です。

以下の例では、クラスターが uscentral1-a ゾーン（ノードラベルのキーは failure-domain.beta.kubernetes.io/zone、値は uscentral1-a ）に含まれるようにしています。

affinity:
  nodeAffinity:
    key: failure-domain.beta.kubernetes.io/zone
    values:
      - uscentral1-a

ポッドアフィニティとポッドアンチアフィニティ¶

ポッドアフィニティを使用すると、Confluent Platform ポッドのスケジュール先として使用できるノードを、ノードで既に実行中のポッドのラベルに基づいて指定できます。

アフィニティルールは、名前空間レベルで適用されます。

構成ファイル（ $VALUES_FILE ）に以下を指定します。

affinity:
  podAntiAffinity:
    rule:           ----- [1]
    terms:
    - key:          ----- [2]
      values:       ----- [3]
      -
      -
      namespaces:
      -             ----- [4]
      topologyKey:
        key:        ----- [5]
      weight:
        weight:     ----- [6]

[1]（省略可能）ルールの種類。PREFERRED または REQUIRED を指定します。デフォルトは PREFERRED です。
[2] Operator によって追加されるポッドラベルのキー。Operator から指定されるポッドラベルを使用します。
[3] [2] のポッドラベルの値。

Operator から指定されるラベルキーと、各ラベルの key で使用できる values の例を以下に示します。
- namespace: operator
- type: zookeeper
[4]（省略可能）このルールが適用される名前空間。
[5]（省略可能）指定がない場合、デフォルトは kubernetes.io/hostname です。詳細については、Kubernetes のアフィニティに関する説明を参照してください。
[6]（省略可能）指定可能な値は 1 ～ 100 です。詳細については、Kubernetes のアフィニティに関する説明を参照してください。

次のスニペットには、このクラスターはラベルが zookeeper であるポッドを既にホストしているノードにはスケジュールされない、というルールが指定されています。

affinity:
  podAntiAffinity:
    terms:
      - key: type
        values:
        - zookeeper

ZooKeeper と Kafka での 1 ノードあたり 1 レプリカ¶

Kuebernetes ノード 1 つにつき、実行される Kafka または ZooKeeper レプリカが 1 つに限定されるように、Operator を構成できます。このルールは名前空間レベルにおいて、同じクラスターから作成されたレプリカにのみ適用されます。

名前空間レベルでは disableHostPort の代わりに oneReplicaPerNode を使用します。oneReplicaPerNode と disableHostPort はどちらもデフォルトで true です。

注釈

5.5.x 以前のバージョンの場合、ZooKeeper および Kafka について disableHostPort のデフォルトは false です。

この機能を有効または無効にするには、構成ファイル（ $VALUES_FILE ）の Kafka および ZooKeeper のセクションで oneReplicaPerNode を使用します。

以下の例を使用すると、複数の ZooKeeper レプリカを 1 つの Kubernetes ノード上で実行できます。

zookeeper:
  oneReplicaPerNode: false

oneReplicaPerNode を true に設定すると、ポッドアンチアフィニティルールがすべて無視されます。ポッドアンチアフィニティルールを使用する場合は、oneReplicaPerNode を false に設定します。