Confluent Platform の詳細構成オプション¶

このトピックでは、Confluent コンポーネントに関して Confluent for Kubernetes （CFK）に用意されている詳細構成オプションをいくつか取り上げます。

Confluent Cloud を使用した Kafka Connect と ksqlDB の構成¶

Confluent for Kubernetes は、Confluent Cloud Kafka と Schema Registry に接続する Connect、ksqlDB、Confluent Control Center のデプロイと管理をサポートします。

この構成をわかりやすく示したウォークスルーについては、Confluent Cloud への接続に関するチュートリアルを参照してください。

カスタムサービスアカウントの指定¶

Confluent for Kubernetes によってデプロイされる各 Confluent コンポーネントポッドには、Kubernetes サービスアカウントが関連付けられます。Confluent for Kubernetes では、これらのサービスアカウントがさまざまな機能を果たしています。たとえば、Confluent の Docker イメージをプライベートの Docker イメージリポジトリからデプロイするためには、Docker レジストリの認証情報を、Confluent コンポーネントに関連付けられているサービスアカウントと関連付けます。

サービスアカウントを指定しなかった場合は、同じ名前空間内のコンポーネントポッドに default サービスアカウントが割り当てられます。

カスタムサービスアカウントを指定するには、コンポーネントのカスタムリソース（CR）構成で serviceAccountName を設定します。

spec:
  podTemplate:
    serviceAccountName:
Copy

構成のオーバーライド¶

Confluent Platform コンポーネントのデフォルトの構成パラメーターは、コンポーネントのカスタムリソース（CR）で、次のようにしてオーバーライドできます。

spec:
  configOverrides:
    server: []
    jvm: []
    log4j: []
Copy

Confluent Platform コンポーネントで使用される構成パラメーターについては、構成リファレンスを参照してください。

以下に示した Kafka の例では、次のような作用があります。

トピックの自動作成が有効になります（デフォルトでは無効）。
クラスターリンク機能が有効になります（デフォルトでは無効）。
メモリー管理に関連したいくつかの JVM フラグが設定されます。
ログレベルが、デフォルトである INFO から DEBUG に変更されます。

spec:
  configOverrides:
    server:
      - auto.create.topics.enable=true
      - confluent.cluster.link.enable=true
    jvm:
      - "-Xmx6g"
      - "-XX:MetaspaceSize=96m"
      - "-XX:+UseG1GC"
    log4j:
      - log4j.rootLogger=DEBUG, stdout
Copy

変更を適用するには、kubectl apply コマンドを使用します。

マウントされたシークレットの指定¶

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

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

マウントされたシークレットを変更すると、クラスターのローリングが行われます。

マウントされたシークレットを指定して使用するには、コンポーネントの CR に以下を追加します。

spec:
  mountedSecrets:
  - secretRef:                                          --- [1]
    keyItems:                                           --- [2]
    - key:                                              --- [3]
      path:                                             --- [4]

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

[1] 使用するシークレットの名前を設定します。コンポーネントのカスタムリソース（CR）の他の部分で参照されているシークレットを使用する必要があります。
[2]（省略可） keyItems の指定がない場合、シークレットは /mnt/secrets/<secretRef> に格納されます。<secretRef> は [1] で設定された値です。

詳しくは、『Secret のキーの特定のパスへの割り当て』を参照してください。
[3] シークレットキーを設定します。
[4] シークレットキー key （[3]）の格納先を相対パスで設定します。絶対パスは使用しないでください。文字列 .. も使用しないでください。

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

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

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

Kafka CR で次のように configOverrides と mountedSecrets を設定します。

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

次のように Kafka をデプロイします。
```
kubectl apply -f <Kafka CR>
```
Copy

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

Kubernetes のアノテーションにより、構造化されていないキー値マップを定義します。このマップは、メタデータを格納および取得するために外部ツールを使用して設定できます。アノテーションはポッドを使用して保管します。

Confluent Platform コンポーネントにカスタムのアノテーションを定義することができます。このアノテーションは、コンポーネントの Kubernetes ポッドに適用されます。

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

アノテーションを、コンポーネントのカスタムリソース（CR）に以下のように定義します。

spec:
  podTemplate:
    annotations:
      key1: value1
      key2: value2
      ...
Copy

annotations は、文字列キーと文字列値のマップである必要があります。

HashiCorp Vault の Kafka ポッドのアノテーション例を次に示します。

spec:
  podTemplate:
    annotations:
      vault.hashicorp.com/agent-inject: true
      vault.hashicorp.com/agent-inject-status: update
      vault.hashicorp.com/preserve-secret-case: true
      vault.hashicorp.com/agent-inject-secret-jksPassword.txt: secret/jksPassword.txt
Copy

Kubernetes Horizontal Pod Autoscaler 用の構成¶

Kubernetes では、Horizontal Pod Autoscaler（HPA）機能により、ポッドのレプリカの数が自動的にスケーリングされます。

Confluent for Kubernetes （CFK）2.1.0 以降、Confluent Platform ポッドの CPU とメモリーの使用量に基づいて HPA を使用するように Confluent Platform コンポーネントを構成できます。

HPA は ZooKeeper と Confluent Control Center ではサポートされていません。

Confluent Platform コンポーネントで HPA を使用するには、コンポーネントのカスタムリソース（CR）用の HPA リソースを別途作成し、CFK と統合します。

以下の例では、CPU 使用率とメモリー使用量に基づいて Connect 用の HPA リソースを作成します。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: connect-cluster-hpa
spec:
  scaleTargetRef:                             --- [1]
    apiVersion: platform.confluent.io/v1beta1 --- [2]
    kind: Connect                             --- [3]
    name: connect                             --- [4]
  minReplicas: 2                              --- [5]
  maxReplicas: 4                              --- [6]
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50              --- [7]
    - type: Resource
      resource:
        name: memory
        targetAverageValue: 1000Mi            --- [8]
Copy

[1]（必須）Confluent コンポーネント固有の情報をこのセクションに指定します。
[2]（必須） CFK API のバージョン。
[3]（必須）スケーリングするオブジェクトの CR の種類。
[4]（必須）スケーリングするオブジェクトの CR の名前。
[5] スケールダウン時のレプリカの最小数。

Kafka のデフォルトのレプリケーション係数が N の場合、Kafka クラスターの HPA における minReplicas は N 以上でなければなりません。

Schema Registry、Connect、ksqlDB を高可用性（HA）にする必要がある場合は、minReplicas を 2 以上に設定します。
[6] スケールアップ時のレプリカの最大数。
[7] ターゲットの平均 CPU 使用率。ここでは 50% です。
[8] ターゲットの平均メモリー使用量の値。ここでは 1000 MiB です。

Confluent Platform 用に HPA を設定する場合は、以下についてさらに検討してください。

Kafka で oneReplicaPerNode を true に設定している場合（これがデフォルトです）、Kafka ブローカー数の上限は、現在の使用可能な Kubernetes ワーカーノードの数です。
Kafka に対してアフィニティーや Taint または Toleration のルールを設定している場合、使用可能なノードの数がさらに制限されます。
基礎となる Kubernetes クラスターそのものが Kubernetes ワーカーノードの自動スケーリングをサポートしていない場合は、HPA が成功するのに十分な数の Kubernetes ワーカーノードがあることを確認してください。

以下のコマンドを実行して、HPA の現在のステータスを確認できます。

kubectl get hpa
Copy