1. Home
2. Confluent for Kubernetes
3. Confluent Platform の構成

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:

構成のオーバーライド

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

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

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

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

Confluent のカスタムリソースへのアノテーションの適用

Confluent for Kubernetes （CFK）には、Confluent Platform コンポーネントの特定のワークフローまたは状態を変更するために使用できる一連のパブリックアノテーションが用意されています。これらのアノテーションは Confluent Platform のカスタムリソース（CR）に適用できます。

platform.confluent.io/force-reconcile

クラスターのリコンサイルサイクルをトリガーします。リコンサイルサイクルが完了すると、アノテーション値が false にリセットされます。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: すべての CR

platform.confluent.io/block-reconcile

内部リソースまたは CR の指定が変更された場合もリコンサイルをブロックします。これは主に、ユーザーが手動のワークフローを実行できるようにする場合に使用します。これを有効にすると、CFK は CR に別途加えられた変更すべてを破棄します。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: すべての CR

platform.confluent.io/roll-precheck

disable に設定すると、CFK はレプリケーション数が不足しているパーティションの事前チェックを実行しません。

• サポートされる値: disable、enable
• デフォルト値: enable
• 該当する CR のタイプ: Kafka

platform.confluent.io/roll-pause

true に設定すると、現在のポッドのローリングが一時停止されます。

• サポートされる値: disable、enable
• デフォルト値: enable
• 該当する CR のタイプ: Kafka

platform.confluent.io/roll-precheck: "disable" に設定すると、事前チェックが無効になります（jolokia エンドポイントに到達しなくなります）。ほとんどの場合、ローカルテストに必須です。

platform.confluent.io/disable-garbage-collection

CFK が内部的に管理する Kubernetes リソースのガベージコレクションを無効にします。

• サポートされる値: false、true
• デフォルト値: true
• 該当する CR のタイプ: Control Center、Connect、Kafka、REST Proxy、ksqlDB、Schema Registry、ZooKeeper

platform.confluent.io/enable-shrink

Kafka の CR の縮小ワークフローを有効にします。これは、Kafka イメージのバージョンが 7.0 以上の場合のみ有効にする必要があります。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: Kafka

platform.confluent.io/disable-internal-rolebindings-creation

RBAC セキュリティ設定で内部ロールバインディングの作成を無効にするかどうかを定義します。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: Control Center、Connect、REST Proxy、ksqlDB、Schema Registry

platform.confluent.io/soft-deletion-versions

スキーマの CR の論理的な削除ワークフローをトリガーするバージョンのリスト。

• サポートされる値: JSON フォーマットの配列（[1,2,3] など）
• デフォルト値: None
• 該当する CR のタイプ: Schema

platform.confluent.io/delete-versions

スキーマの CR の物理的な削除ワークフローをトリガーするバージョンのリスト。

• サポートされる値: JSON フォーマットの配列（[1,2,3] など）
• デフォルト値: None
• 該当する CR のタイプ: Schema

platform.confluent.io/restart-connector

コネクターの再起動をトリガーします。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: Connector

platform.confluent.io/restart-task

コネクターのタスクの再開をトリガーします。

• サポートされる値: true、false
• デフォルト値: false
• 該当する CR のタイプ: Connector

platform.confluent.io/http-timeout-in-seconds

CR ワークフローの HTTP クライアントのタイムアウトを秒単位で指定します。

• サポートされる値: int32 型の数字
• デフォルト値: None
• 該当する CR のタイプ: Control Center、Connect、Kafka、KafkaTopic、ClusterLink、Schema

platform.confluent.io/confluent-hub-install-extra-args

Connect の CR の追加の引数。Connect が起動して Confluent Hub からプラグインをダウンロードする際に、これらの追加の引数が使用されます。

• サポートされる値: フラグの文字列（--worker-configs /dev/null --component-dir /mnt/plugins など）
• デフォルト値: None
• 該当する CR のタイプ: Connect

アノテーションを追加するには、次のコマンドを実行します。

kubectl annotate <CR-type> <CR name> -n <namespace> <annotation>="<annotation value>"

アノテーションを削除するには、次のコマンドを実行します。

kubectl annotate <CR type> <CR name> -n <namespace> <annotation>-

Confluent ポッドへのアノテーションの適用

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

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

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

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

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

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

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]

• [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

カスタムボリュームのマウント

Kubernetes は Kubernetes ボリューム を介してストレージの抽象化を行います。これらのボリュームは一時的（エフェメラル）である場合があります。この場合、ボリュームの存続期間がポッドの存続期間を越え、ポッドが機能を停止するか永続的になると、ボリュームは破棄されます。

CFK では、さまざまなタイプの複数のボリュームを設定できるよう Confluent Platform ポッドを構成することが可能です。これらを同時にポッドに接続して、ポッド内の任意のパスにマウントできます。

注釈

カスタムボリュームをマウントした場合、ZooKeeper と Kafka のデータに関して複数の PersistentVolume はサポートされません。CFK は、ZooKeeper と Kafka のデータに関して 1 つの PersistentVolume を構成し管理します。

以下では、カスタムボリュームマウントの一般的なユースケースをいくつか紹介します。

• サードパーティシークレットプロバイダー

  機密情報のセキュリティを確保する場合に、Kubernetes シークレットではなく、Hashicorp Vault、AWS Secrets Manager、Azure KeyVault などの Vault 製品を使用することもできます。

  シークレットプロバイダーから認証情報を取得する Confluent コンポーネントポッドのエフェメラル（一時的な）ボリュームマウントを構成することで、サードパーティシークレットプロバイダーを統合できます。

• Kafka のコネクター

  一部の Kafka のコネクターには JAR が必要です。これは Connect プラグインの範囲外ですが、Connect ポッドで使用できる必要があります。コネクターの JAR で永続的なボリュームを作成し、Connect ワーカーポッドにマウントできます。

• 複数のカスタムパーティション

  たとえば、任意の永続的なボリュームに個別にログを書き込むこともできます。

CFK でカスタムボリュームを Confluent コンポーネントポッドにマウントするには、Kafka、ZooKeeper、Control Center、Schema Registry、ksqlDB、Connect、Kafka REST Proxy などのコンポーネントのカスタムリソース（CR）でカスタムボリュームマウントを定義します。同じボリュームが、コンポーネントクラスターの指定されたパスにあるすべてのポッドにマウントされます。

カスタムボリュームを Confluent Platform コンポーネントにマウントするには、次の手順に従います。

1. ドライバの指定に従ってボリュームを構成します。

2. Confluent Platform コンポーネントの CR に以下を追加します。

   spec:
     mountedVolumes:         --- [1]
       volumes:              --- [2]
       volumeMounts:         --- [3]
   

   • [1] mountedVolumes は、このコンポーネント用にリクエストされた volumes と volumeMounts の配列です。

   • [2]（必須）``volumes`` は、ポッド内のどのコンテナーからもアクセスできる、名前付きボリュームの配列です。

     サポート対象のボリュームタイプと、各ボリュームタイプに必要な構成プロパティについては、Kubernetes のボリュームタイプに関する説明 を参照してください。

   • [3]（必須）コンテナー内の volumes のマウントパスを示します。

     ボリュームマウントの構成プロパティについては、Kubernetes ポッドの volumeMounts に関する説明 を参照してください。

3. CR を適用するには、kubectl apply コマンドを使用します。

ボリュームとボリュームマウントがコンポーネントポッドテンプレートに追加される前に、CFK は内部のボリュームマウントに競合がないことを確認するための検証を実行します。以下の場合、リコンサイルが失敗するか、CFK のログにエラーが追加されます。

• カスタムボリュームのマウントパスが、内部のマウントパスと競合している。

  Confluent Platform コンポーネントによって使用されている内部マウントがあります。

  • /mnt/config
  • /mnt/config/init
  • /mnt/config/shared
  • /mnt/data/data0
  • /opt/confluentinc

• カスタムボリュームのマウントパスが、カスタムマウントされたシークレットと競合している。

• カスタムボリュームの名前またはカスタムボリュームのマウントパスの間に競合がある。

以下の例では、Azure のファイルボリュームと HashiCorp Vault を SecretProviderClass および CSI ドライバでマウントしています。

apiVersion: platform.confluent.io/v1beta1
kind: Kafka
spec:
  mountedVolumes:
    volumes:
    - name: azure
      azureFile:
        secretName: azure-secret
        shareName: aksshare
        readOnly: true
    - name: secrets-store-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "vault-database"
    volumeMounts:
    - name: azure
      mountPath: /mnt/azurePath1
    - name: azure
      mountPath: /mnt/azurePath2
    - name: secrets-store-inline
      mountPath: "/mnt/secrets-store"
      readOnly: true