OpenShift での AMQ Streams の設定


Red Hat AMQ Streams 2.4

OpenShift Container Platform での AMQ Streams 2.4 のデプロイメントの設定および管理

概要

AMQ Streams でデプロイされた Operator および Kafka コンポーネントを設定し、大規模なメッセージングネットワークを構築します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

第1章 設定の概要

AMQ Streams は、OpenShift クラスターで Apache Kafka を実行するプロセスを簡素化します。

このガイドでは、AMQ Streams デプロイメントを設定および管理する方法について説明します。

1.1. カスタムリソースの設定

カスタムリソースを使用して、AMQ Streams デプロイメントを設定します。

カスタムリソースを使用して、次のコンポーネントのインスタンスを設定および作成できます。

  • Kafka クラスター
  • Kafka Connect クラスター
  • Kafka MirrorMaker
  • Kafka Bridge
  • Cruise Control

カスタムリソース設定を使用してインスタンスを管理したり、デプロイメントを変更して追加機能を導入したりすることもできます。これには、以下をサポートする設定が含まれる場合があります。

  • Kafka ブローカーへのクライアントアクセスの保護
  • クラスター外からの Kafka ブローカーへのアクセス
  • トピックの作成
  • ユーザー (クライアント) の作成
  • フィーチャーゲートの制御
  • ロギングの頻度変更
  • リソース制限とリクエストの割り当て
  • AMQ Streams Drain Cleaner、Cruise Control、分散トレースなどの機能紹介

カスタムリソース API リファレンス では、設定で使用できるプロパティーを説明しています。

1.2. ConfigMap を使用した設定の追加

ConfigMap リソースを使用して、特定の設定を AMQ Streams デプロイメントに追加します。ConfigMap はキーと値のペアを使用して機密ではないデータを保存します。ConfigMap に追加された設定データは 1 か所に保持され、コンポーネント間で再利用できます。

ConfigMap は、以下に関連する設定データのみを保存できます。

  • ログ設定
  • メトリクスの設定
  • Kafka Connect コネクターの外部設定

設定の他の領域に ConfigMap を使用することはできません。

コンポーネントを設定する場合、configMapKeyRef プロパティーを使用して ConfigMap への参照を追加できます。

たとえば、configMapKeyRef を使用してロギングの設定を提供する ConfigMap を参照できます。ConfigMap を使用して Log4j 設定ファイルを渡すことができます。参照を logging 設定に追加します。

ロギングの ConfigMap の例

spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: my-config-map
        key: my-config-map-key

メトリクス設定に ConfigMap を使用するには、同じ方法でコンポーネントの metricsConfig 設定への参照を追加します。

ExternalConfiguration プロパティーは、Pod にマウントされた ConfigMap (またはシークレット) からのデータを環境変数またはボリュームとして使用できるようにします。Kafka Connect によって使用されるコネクターの外部設定データを使用できます。データは外部データソースに関連する可能性があり、コネクターがそのデータソースと通信するために必要な値を指定します。

たとえば、configMapKeyRef プロパティーを使用して、ConfigMap から設定データを環境変数として渡すことができます。

環境変数の値を提供する ConfigMap の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          configMapKeyRef:
            name: my-config-map
            key: my-key

外部で管理される ConfigMap を使用している場合は、設定プロバイダーを使用して ConfigMap にデータを読み込みます。設定プロバイダーの使用の詳細は、3章外部ソースからの設定値の読み込み を参照してください。

1.2.1. カスタム ConfigMap の命名

AMQ Streams は、OpenShift にデプロイされると、独自の ConfigMap およびその他のリソースを作成 します。ConfigMap には、コンポーネントの実行に必要なデータが含まれます。AMQ Streams によって作成された ConfigMap は編集しないでください。

作成するカスタム ConfigMap にはこれらのデフォルト ConfigMap と同じ名前がないことを確認します。名前が同じ場合は上書きされます。たとえば、ConfigMap が Kafka クラスターの ConfigMap と同じ名前である場合、Kafka クラスターの更新がある場合に上書きされます。

1.3. 本書の表記慣例

ユーザー置換値

ユーザーが置き換える値は、置き換え可能 な値とも呼ばれ、山かっこ (<>) を付けて 斜体 で表示されます。アンダースコア ( _ ) は、複数単語の値に使用されます。値がコードまたはコマンドを参照する場合は monospace も使用されます。

たとえば、以下のコードでは <my_namespace> を namespace の名前に置き換えます。

sed -i 's/namespace: .*/namespace: <my_namespace>/' install/cluster-operator/*RoleBinding*.yaml

1.4. 関連情報

第2章 OpenShift デプロイメントでの AMQ Streams の設定

カスタムリソースを使用して AMQ Streams の展開を設定します。AMQ Streams は、デプロイメント用の独自の Kafka コンポーネント設定を構築する際の開始点として役立つ 設定ファイルの例 を提供します。

注記

カスタムリソースに適用されるラベルは、クラスターを設定する OpenShift リソースにも適用されます。そのため、必要に応じてリソースに簡単にラベルを付けることができます。

AMQ Streams デプロイメントのモニタリング

Prometheus および Grafana を使用して、AMQ Streams デプロイメントを監視できます。詳細は、Kafka に追加されたメトリクスの紹介 を参照してください。

2.1. 標準の Kafka 設定プロパティーの使用

標準の Kafka 設定プロパティーを使用して Kafka コンポーネントを設定します。

プロパティーは、以下の Kafka コンポーネントの設定を制御および調整するオプションを提供します。

  • ブローカー
  • Topics
  • クライアント (プロデューサーとコンシューマー)
  • 管理クライアント
  • Kafka Connect
  • Kafka Streams

ブローカーおよびクライアントパラメーターには、承認、認証、および暗号化を設定するオプションが含まれます。

注記

AMQ Streams on OpenShift では、一部の設定プロパティーは AMQ Streams によって完全に管理されており、変更できません。

Kafka 設定プロパティーの詳細と、プロパティーを使用してデプロイメントを調整する方法は、以下のガイドを参照してください。

2.2. Kafka クラスターの設定

Kafka リソースを使用して Kafka デプロイメントを設定します。Kafka クラスターは ZooKeeper クラスターと共にデプロイされるため、Kafka リソース内の ZooKeeper の設定オプションも使用できます。Entity Operator は Topic Operator と User Operator で設定されます。Kafka リソースの entityOperator プロパティーを設定して、Topic Operator と User Operator をデプロイメントに含めることもできます。

Kafka スキーマ参照」 Kafka リソースの完全なスキーマについて説明します。

Apache Kafka の詳細については、Apache Kafka のドキュメント を参照してください。

リスナーの設定

クライアントを Kafka ブローカーに接続するためのリスナーを設定します。リスナーの設定の詳細については、Generic KafkaListener スキーマ参照」 を参照してください。

TLS 証明書の管理

Kafka をデプロイする場合、Cluster Operator は自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。必要な場合は、更新期間の開始前にクラスターおよびクライアント CA 証明書を手動で更新できます。クラスターおよびクライアント CA 証明書によって使用される鍵を置き換えることもできます。詳細は、CA 証明書の手動更新 および 秘密鍵の置換 を参照してください。

2.2.1. Kafka の設定

Kafka リソースのプロパティーを使用して、Kafka デプロイメントを設定します。

Kafka の設定に加え、ZooKeeper および AMQ Streams Operator の設定を追加することもできます。ロギングやヘルスチェックなどの一般的な設定プロパティーは、コンポーネントごとに独立して設定されます。

この手順では、可能な設定オプションの一部のみを取り上げますが、特に重要なオプションは次のとおりです。

  • リソース要求 (CPU/メモリー)
  • 最大および最小メモリー割り当ての JVM オプション
  • リスナー (およびクライアントの認証)
  • 認証
  • ストレージ
  • ラックアウェアネス
  • メトリクス
  • Cruise Control によるクラスターのリバランス

Kafka バージョン

Kafka configinter.broker.protocol.version プロパティーは、指定された Kafka バージョン (spec.kafka.version) によってサポートされるバージョンである必要があります。このプロパティーは、Kafka クラスターで使用される Kafka プロトコルのバージョンを表します。

Kafka 3.0.0 以降、inter.broker.protocol.version3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。

Kafka バージョンのアップグレード時には、inter.broker.protocol.version のアップグレードが必要です。詳細は、Upgrading Kafka を参照してください。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

以下をデプロイする手順については、 OpenShift での AMQ Streams のデプロイおよびアップグレード を参照してください。

手順

  1. Kafka リソースの spec プロパティーを編集します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        replicas: 3 1
        version: 3.4.0 2
        logging: 3
          type: inline
          loggers:
            kafka.root.logger.level: "INFO"
        resources: 4
          requests:
            memory: 64Gi
            cpu: "8"
          limits:
            memory: 64Gi
            cpu: "12"
        readinessProbe: 5
          initialDelaySeconds: 15
          timeoutSeconds: 5
        livenessProbe:
          initialDelaySeconds: 15
          timeoutSeconds: 5
        jvmOptions: 6
          -Xms: 8192m
          -Xmx: 8192m
        image: my-org/my-image:latest 7
        listeners: 8
          - name: plain 9
            port: 9092 10
            type: internal 11
            tls: false 12
            configuration:
              useServiceDnsDomain: true 13
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication: 14
              type: tls
          - name: external 15
            port: 9094
            type: route
            tls: true
            configuration:
              brokerCertChainAndKey: 16
                secretName: my-secret
                certificate: my-certificate.crt
                key: my-key.key
        authorization: 17
          type: simple
        config: 18
          auto.create.topics.enable: "false"
          offsets.topic.replication.factor: 3
          transaction.state.log.replication.factor: 3
          transaction.state.log.min.isr: 2
          default.replication.factor: 3
          min.insync.replicas: 2
          inter.broker.protocol.version: "3.4"
          ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 19
          ssl.enabled.protocols: TLSv1.2
          ssl.protocol: TLSv1.2
        storage: 20
          type: persistent-claim 21
          size: 10000Gi 22
        rack: 23
          topologyKey: topology.kubernetes.io/zone
        metricsConfig: 24
          type: jmxPrometheusExporter
          valueFrom:
            configMapKeyRef: 25
              name: my-config-map
              key: my-key
        # ...
      zookeeper: 26
        replicas: 3 27
        logging: 28
          type: inline
          loggers:
            zookeeper.root.logger: "INFO"
        resources:
          requests:
            memory: 8Gi
            cpu: "2"
          limits:
            memory: 8Gi
            cpu: "2"
        jvmOptions:
          -Xms: 4096m
          -Xmx: 4096m
        storage:
          type: persistent-claim
          size: 1000Gi
        metricsConfig:
          # ...
      entityOperator: 29
        tlsSidecar: 30
          resources:
            requests:
              cpu: 200m
              memory: 64Mi
            limits:
              cpu: 500m
              memory: 128Mi
        topicOperator:
          watchedNamespace: my-topic-namespace
          reconciliationIntervalSeconds: 60
          logging: 31
            type: inline
            loggers:
              rootLogger.level: "INFO"
          resources:
            requests:
              memory: 512Mi
              cpu: "1"
            limits:
              memory: 512Mi
              cpu: "1"
        userOperator:
          watchedNamespace: my-topic-namespace
          reconciliationIntervalSeconds: 60
          logging: 32
            type: inline
            loggers:
              rootLogger.level: INFO
          resources:
            requests:
              memory: 512Mi
              cpu: "1"
            limits:
              memory: 512Mi
              cpu: "1"
      kafkaExporter: 33
        # ...
      cruiseControl: 34
        # ...
    1
    2
    Kafka バージョン。アップグレード手順 に従うと、サポート対象のバージョンに変更できます。
    3
    ConfigMap を介して直接 (inline) または間接 (external) に追加された Kafka ロガーとログレベル。カスタム ConfigMap は、log4j.properties キー下に配置する必要があります。Kafka kafka.root.logger.level ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
    4
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    5
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    6
    Kafka を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    7
    高度な任意設定: 特別な場合のみ推奨される コンテナーイメージの設定
    8
    リスナーは、ブートストラップアドレスでクライアントが Kafka クラスターに接続する方法を設定します。リスナーは、OpenShift クラスター内部または外部からの接続の 内部 または 外部 リスナーとして設定 されます。
    9
    リスナーを識別するための名前。Kafka クラスター内で一意である必要があります。
    10
    Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。
    11
    リスナーのタイプは、internal または cluster-ip (ブローカーごとの ClusterIP サービスを使用して Kafka を公開するため) として指定されるか、外部リスナーの場合は、route (OpenShift のみ)、loadbalancernodeport または ingress (Kubernetes のみ) として指定されます。
    12
    各リスナーの TLS 暗号化を有効にします。デフォルトは false です。route リスナーに TLS 暗号化は必要ありません。
    13
    クラスターサービス接尾辞 (通常は cluster.local) を含む完全修飾 DNS 名が割り当てられているかどうかを定義します。
    14
    15
    16
    外部 CA (認証局) によって管理される Kafka リスナー証明書 のオプションの設定。brokerCertChainAndKey は、サーバー証明書および秘密鍵が含まれる Secret を指定します。TLS による暗号化が有効な任意のリスナーで Kafka リスナー証明書を設定できます。
    17
    承認は Kafka ブローカーで簡易、OAUTH2.0、または OPA 承認を有効化 します。簡易承認では、AclAuthorizer Kafka プラグインが使用されます。
    18
    19
    20
    Storageephemeralpersistent-claimjbod のいずれかに設定されています。
    21
    22
    永続ストレージには、動的ボリュームプロビジョニングのためのストレージ idclass など、追加の設定オプション があります。
    23
    異なるラック、データセンター、または可用性ゾーンにレプリカを分散させるための Rack awareness 設定。topologyKey は、ラック ID を含むノードラベルと一致する必要があります。この設定で使用される例では、標準の topology.kubernetes.io/zone ラベルを使用するゾーンを指定します。
    24
    Prometheus メトリクス は有効になっています。この例では、メトリクスは Prometheus JMX Exporter (デフォルトのメトリクスエクスポーター) に対して設定されます。
    25
    Prometheus JMX Exporter 経由でメトリクスを Grafana ダッシュボードにエクスポートする Prometheus ルール。Prometheus JMX Exporter の設定が含まれる ConfigMap を参照することで有効になります。metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap の参照を使用して、追加設定なしでメトリクスを有効にできます。
    26
    Kafka 設定と似たプロパティーが含まれる、ZooKeeper 固有の設定。
    27
    ZooKeeper ノードの数。通常、ZooKeeper クラスターまたはアンサンブルは、一般的に 3、5、7 個の奇数個のノードで実行されます。効果的なクォーラムを維持するには、過半数のノードが利用可能である必要があります。ZooKeeper クラスターでクォーラムを失うと、クライアントへの応答が停止し、Kafka ブローカーが機能しなくなります。AMQ Streams では、ZooKeeper クラスターの安定性および高可用性が重要になります。
    28
    29
    30
    Entity Operator の TLS サイドカー設定。Entity Operator は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。
    31
    指定された Topic Operator ロガーおよびログレベル。この例では、inline ロギングを使用します。
    32
    33
    Kafka Exporter の設定。Kafka Exporter は、Kafka ブローカーからメトリックデータ、特にコンシューマーラグデータを抽出するためのオプションのコンポーネントです。Kafka Exporter が適切に機能できるようにするには、コンシューマーグループを使用する必要があります。
    34
    Kafka クラスターの再バランスに使用される Cruise Control のオプションの設定。
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

2.2.2. Entity Operator の設定

Entity Operator は、実行中の Kafka クラスターで Kafka 関連のエンティティーを管理します。

Entity Operator は以下で設定されます。

  • Kafka トピックを管理する Topic Operator
  • Kafka ユーザーを管理する User Operator

Cluster Operator は Kafka リソース設定を介して、Kafka クラスターのデプロイ時に、上記の Operator の 1 つまたは両方を含む Entity Operator をデプロイできます。

これらの operator は、Kafka クラスターのトピックおよびユーザーを管理するために自動的に設定されます。Topic Operator と User Operator は、1 つの名前空間のみを監視できます。

注記

デプロイされると、デプロイメント設定に応じて、Entity Operator pod に operator が含まれます。

2.2.2.1. Entity Operator の設定プロパティー

Kafka.specentityOperator プロパティーを使用して Entity Operator を設定します。

entityOperator プロパティーでは複数のサブプロパティーがサポートされます。

  • tlsSidecar
  • topicOperator
  • userOperator
  • template

tlsSidecar プロパティーには、ZooKeeper との通信に使用される TLS サイドカーコンテナーの設定が含まれます。

template プロパティーには、ラベル、アノテーション、アフィニティー、および容認 (Toleration) などの Entity Operator Pod の設定が含まれます。テンプレートの設定に関する詳細は、「OpenShift リソースのカスタマイズ」 を参照してください。

topicOperator プロパティーには、Topic Operator の設定が含まれます。このオプションがないと、Entity Operator は Topic Operator なしでデプロイされます。

userOperator プロパティーには、User Operator の設定が含まれます。このオプションがないと、Entity Operator は User Operator なしでデプロイされます。

Entity Operator の設定に使用されるプロパティーに関する詳細は EntityUserOperatorSpec schema reference を参照してください。

両方の Operator を有効にする基本設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}

topicOperator および userOperator に空のオブジェクト ({}) が使用された場合、すべてのプロパティーでデフォルト値が使用されます。

topicOperator および userOperator プロパティーの両方がない場合、Entity Operator はデプロイされません。

2.2.2.2. Topic Operator 設定プロパティー

Topic Operator デプロイメントは、topicOperator オブジェクト内で追加オプションを使用すると設定できます。以下のプロパティーがサポートされます。

watchedNamespace
Topic Operator が KafkaTopic リソースを監視する OpenShift 名前空間。デフォルトは、Kafka クラスターがデプロイされた namespace です。
reconciliationIntervalSeconds
定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは 120 です。
zookeeperSessionTimeoutSeconds
ZooKeeper セッションのタイムアウト (秒単位)。デフォルトは 18 です。
topicMetadataMaxAttempts
Kafka からトピックメタデータの取得を試行する回数。各試行の間隔は、指数バックオフとして定義されます。パーティションまたはレプリカの数によって、トピックの作成に時間がかかる可能性がある場合は、この値を大きくすることを検討してください。デフォルトは 6 です。
image
image プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、image を参照してください。
resources
resources プロパティーを使用すると、Topic Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、resources を参照してください。
logging
logging プロパティーは、Topic Operator のロギングを設定します。詳細は logging を参照してください。

Topic Operator の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
    # ...

2.2.2.3. User Operator 設定プロパティー

User Operator デプロイメントは、userOperator オブジェクト内で追加オプションを使用すると設定できます。以下のプロパティーがサポートされます。

watchedNamespace
User Operator が KafkaUser リソースを監視する OpenShift 名前空間。デフォルトは、Kafka クラスターがデプロイされた namespace です。
reconciliationIntervalSeconds
定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは 120 です。
image
image プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、image を参照してください。
resources
resources プロパティーを使用すると、User Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、resources を参照してください。
logging
logging プロパティーは、User Operator のロギングを設定します。詳細は logging を参照してください。
secretPrefix
secretPrefix プロパティーは、KafkaUser リソースから作成されたすべての Secret の名前に接頭辞を追加します。たとえば、secretPrefix: kafka- は、すべてのシークレット名の前に kafka- を付けます。そのため、my-user という名前の KafkaUser は、kafka-my-user という名前の Secret を作成します。

User Operator の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-user-namespace
      reconciliationIntervalSeconds: 60
    # ...

2.2.3. Kafka および ZooKeeper ストレージの設定

Kafka および ZooKeeper はステートフルなアプリケーションであるため、データをディスクに格納します。AMQ Streams では、3 つのタイプのストレージがサポートされます。

  • 一時データストレージ (開発用のみで推奨されます)
  • 永続データストレージ
  • JBOD (ZooKeeper ではなく Kafka のみ)

Kafka リソースを設定する場合、Kafka ブローカーおよび対応する ZooKeeper ノードで使用されるストレージのタイプを指定できます。以下のリソースの storage プロパティーを使用して、ストレージタイプを設定します。

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper

ストレージタイプは type フィールドで設定されます。

ストレージ設定プロパティーの詳細は、スキーマリファレンスを参照してください。

警告

Kafka クラスターをデプロイした後に、ストレージタイプを変更することはできません。

2.2.3.1. データストレージに関する留意事項

AMQ Streams がうまく機能するには、効率的なデータストレージインフラストラクチャーが不可欠です。ブロックストレージを使用することを強くお勧めします。AMQ Streams は、ブロックストレージでの使用についてのみテストされています。NFS などのファイルストレージはテストされておらず、動作するという保証はありません。

ブロックストレージには、以下のいずれかのオプションを選択します。

  • Amazon Elastic Block Store (EBS) などのクラウドベースのブロックストレージソリューション。
  • ローカル永続ボリューム を使用した永続ストレージ
  • ファイバーチャネルiSCSI などのプロトコルがアクセスする SAN (ストレージエリアネットワーク) ボリューム
注記

AMQ Streams には OpenShift の raw ブロックボリュームは必要ありません。

2.2.3.1.1. ファイルシステム

Kafka は、メッセージの保存にファイルシステムを使用します。AMQ Streams は、Kafka で一般的に使用される XFS および ext4 ファイルシステムと互換性があります。ファイルシステムを選択して設定するときは、デプロイメントの基盤となるアーキテクチャーと要件を考慮してください。

詳細については、Kafka ドキュメントの Filesystem Selection を参照してください。

2.2.3.1.2. ディスク使用率

Apache Kafka と ZooKeeper には別々のディスクを使用します。

ソリッドステートドライブ (SSD) は必須ではありませんが、複数のトピックに対してデータが非同期的に送受信される大規模なクラスターで Kafka のパフォーマンスを向上させることができます。SSD は、高速で低レイテンシーのデータアクセスが必要な ZooKeeper で特に有効です。

注記

Kafka と ZooKeeper の両方にデータレプリケーションが組み込まれているため、複製されたストレージのプロビジョニングは必要ありません。

2.2.3.2. 一時ストレージ

一時データストレージは一時的なものです。ノード上のすべての Pod は、ローカルの一時ストレージスペースを共有します。データは、それを使用する Pod が実行されている限り保持されます。Pod が削除されると、データは失われます。ただし、Pod は高可用性環境でデータを回復できます。

その一時的な性質のため、一時ストレージは開発とテストにのみ推奨されます。

一時ストレージは emptyDir ボリュームを使用してデータを保存します。Pod がノードに割り当てられると、emptyDir ボリュームが作成されます。sizeLimit プロパティーを使用して、emptyDir のストレージの合計量を設定できます。

重要

一時ストレージは、単一ノードの ZooKeeper クラスターやレプリケーション係数が 1 の Kafka トピックでの使用には適していません。

一時ストレージを使用するには、Kafka または ZooKeeper リソースのストレージタイプ設定を ephemeral に設定します。

一時ストレージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    storage:
      type: ephemeral
    # ...
  zookeeper:
    # ...
    storage:
      type: ephemeral
    # ...

2.2.3.2.1. Kafka ログディレクトリーのマウントパス

一時ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data/kafka-logIDX

IDX は、Kafka ブローカー Pod インデックスです。たとえば、/var/lib/kafka/data/kafka-log0 のようになります。

2.2.3.3. 永続ストレージ

永続的なデータストレージは、システムが中断した場合でもデータを保持します。永続的なデータストレージを使用する Pod の場合、データは Pod の障害や再起動後も保持されます。

動的プロビジョニングフレームワークにより、永続的なストレージを使用してクラスターを作成できます。Pod 設定では、永続ボリューム要求 (PVC) を使用して、永続ボリューム (PV) でストレージ要求を行います。PV は、ストレージボリュームを表すストレージリソースです。PV は、それを使用する Pod から独立しています。PVC は、Pod の作成時に必要なストレージの量を要求します。PV の基盤となるストレージインフラストラクチャーを理解する必要はありません。PV がストレージ基準に一致する場合、PVC は PV にバインドされます。

永続的な性質のため、本番環境には永続ストレージをお勧めします。

PVC は、StorageClass を指定することにより、さまざまなタイプの永続ストレージを要求できます。ストレージクラスはストレージプロファイルを定義し、PV を動的にプロビジョニングします。ストレージクラスが指定されていない場合、デフォルトのストレージクラスが使用されます。永続ストレージオプションには、SAN ストレージタイプまたは ローカル永続ボリューム が含まれる場合があります。

永続ストレージを使用するには、Kafka または ZooKeeper リソースのストレージタイプ設定を persistent-claim に設定します。

本番環境では、次の設定が推奨されます。

  • Kafka の場合、type: jbod を 1 つ以上の type: persistent-claim ボリュームで設定します
  • ZooKeeper の場合は、type: persistent-claim を設定します。

永続ストレージには、次の設定オプションもあります。

id (任意)
ストレージ ID 番号。このオプションは、JBOD ストレージ宣言で定義されるストレージボリュームには必須です。デフォルトは 0 です。
size (必須)
永続ボリューム要求のサイズ (例: 1000Gi)。
class (任意)
動的ボリュームプロビジョニングに使用する OpenShift の ストレージクラス。ストレージ class の設定には、ボリュームのプロファイルを詳細に記述するパラメーターが含まれます。
selector (任意)
特定の PV を指定する設定。選択したボリュームのラベルを表す key:value ペアを提供します。
deleteClaim (任意)
クラスターのアンインストール時に PVC を削除するかどうかを指定するブール値。デフォルトは false です。
警告

既存の AMQ Streams クラスターで永続ボリュームのサイズを増やすことは、永続ボリュームのサイズ変更をサポートする OpenShift バージョンでのみサポートされます。サイズを変更する永続ボリュームには、ボリューム拡張をサポートするストレージクラスを使用する必要があります。ボリューム拡張をサポートしないその他のバージョンの OpenShift およびストレージクラスでは、クラスターをデプロイする前に必要なストレージサイズを決定する必要があります。既存の永続ボリュームのサイズを縮小することはできません。

Kafka と ZooKeeper の永続ストレージ設定の例

# ...
spec:
  kafka:
    # ...
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 2
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    # ...
  zookeeper:
    storage:
      type: persistent-claim
      size: 1000Gi
# ...

ストレージクラスを指定しない場合、デフォルトが使用されます。次の例では、ストレージクラスを指定します。

特定のストレージクラスを使用した永続ストレージ設定の例

# ...
storage:
  type: persistent-claim
  size: 1Gi
  class: my-storage-class
# ...

selector を使用して、SSD などの特定の機能を提供するラベル付き永続ボリュームを指定します。

セレクターを使用した永続ストレージ設定の例

# ...
storage:
  type: persistent-claim
  size: 1Gi
  selector:
    hdd-type: ssd
  deleteClaim: true
# ...

2.2.3.3.1. ストレージクラスのオーバーライド

デフォルトのストレージクラスを使用する代わりに、1 つ以上の Kafka ブローカー または ZooKeeper ノードに異なるストレージクラスを指定できます。これは、ストレージクラスが、異なるアベイラビリティーゾーンやデータセンターに制限されている場合などに便利です。この場合、overrides フィールドを使用できます。

以下の例では、デフォルトのストレージクラスの名前は my-storage-class になります。

ストレージクラスのオーバーライドを使用した AMQ Streams クラスターの例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  labels:
    app: my-cluster
  name: my-cluster
  namespace: myproject
spec:
  # ...
  kafka:
    replicas: 3
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
        class: my-storage-class
        overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
      # ...
  # ...
  zookeeper:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...

overrides プロパティーが設定され、ボリュームによって以下のストレージクラスが使用されます。

  • ZooKeeper ノード 0 の永続ボリュームでは my-storage-class-zone-1a が使用されます。
  • ZooKeeper ノード 1 の永続ボリュームでは my-storage-class-zone-1b が使用されます。
  • ZooKeeepr ノード 2 の永続ボリュームでは my-storage-class-zone-1c が使用されます。
  • Kafka ブローカー 0 の永続ボリュームでは my-storage-class-zone-1a が使用されます。
  • Kafka ブローカー 1 の永続ボリュームでは my-storage-class-zone-1b が使用されます。
  • Kafka ブローカー 2 の永続ボリュームでは my-storage-class-zone-1c が使用されます。

現在、overrides プロパティーは、ストレージクラスの設定をオーバーライドするためのみに使用されます。他のストレージ設定プロパティーのオーバーライドは現在サポートされていません。他のストレージ設定プロパティーは現在サポートされていません。

2.2.3.3.2. 永続ストレージ用の PVC リソース

永続ストレージを使用すると、次の名前で PVC が作成されます。

data-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを格納するために使用されるボリュームの PVC。
data-cluster-name-zookeeper-idx
ZooKeeper ノード Pod idx のデータを格納するために使用されるボリュームの PVC。
2.2.3.3.3. Kafka ログディレクトリーのマウントパス

永続ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data/kafka-logIDX

IDX は、Kafka ブローカー Pod インデックスです。たとえば、/var/lib/kafka/data/kafka-log0 のようになります。

2.2.3.4. 永続ボリュームのサイズ変更

既存の AMQ Streams クラスターによって使用される永続ボリュームのサイズを増やすことで、ストレージ容量を増やすことができます。永続ボリュームのサイズ変更は、JBOD ストレージ設定で 1 つまたは複数の永続ボリュームが使用されるクラスターでサポートされます。

注記

永続ボリュームのサイズを拡張することはできますが、縮小することはできません。永続ボリュームのサイズ縮小は、現在 OpenShift ではサポートされていません。

前提条件

  • ボリュームのサイズ変更をサポートする OpenShift クラスター。
  • Cluster Operator が稼働中です。
  • ボリューム拡張をサポートするストレージクラスを使用して作成された永続ボリュームを使用する Kafka クラスター。

手順

  1. クラスターの Kafka リソースを編集します。

    size プロパティーを変更して、Kafka クラスター、ZooKeeper クラスター、またはその両方に割り当てられた永続ボリュームのサイズを増やします。

    • Kafka クラスターの場合は、spec.kafka.storage の下にある size プロパティーを更新します。
    • ZooKeeper クラスターの場合は、spec.zookeeper.storage の下にある size プロパティーを更新します。

    ボリュームサイズを 2000Giに増やす Kafka 設定

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: persistent-claim
          size: 2000Gi
          class: my-storage-class
        # ...
      zookeeper:
        # ...

  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

    OpenShift では、Cluster Operator からの要求に応じて、選択された永続ボリュームの容量が増やされます。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。

  3. クラスター上の関連する Pod のストレージ容量が増加したことを確認します。

    oc get pv

    ストレージが増加した Kafka ブローカー Pod

    NAME               CAPACITY   CLAIM
    pvc-0ca459ce-...   2000Gi     my-project/data-my-cluster-kafka-2
    pvc-6e1810be-...   2000Gi     my-project/data-my-cluster-kafka-0
    pvc-82dc78c9-...   2000Gi     my-project/data-my-cluster-kafka-1

    出力には、ブローカー Pod に関連付けられた各 PVC の名前が表示されます。

関連情報

2.2.3.5. JBOD ストレージ

AMQ Streams で、複数のディスクやボリュームのデータストレージ設定である JBOD を使用するように設定できます。JBOD は、Kafka ブローカーのデータストレージを増やす方法の 1 つです。また、パフォーマンスを向上することもできます。

注記

JBOD ストレージは Kafka でのみ サポートされ、ZooKeeper ではサポートされません。

JBOD 設定は 1 つ以上のボリュームによって記述され、各ボリュームは 一時 または 永続 ボリュームのいずれかになります。JBOD ボリューム宣言のルールおよび制約は、一時および永続ストレージのルールおよび制約と同じです。たとえば、プロビジョニング後に永続ストレージのボリュームのサイズを縮小することはできません。また、タイプが ephemeral の場合は、sizeLimit の値を変更することはできません。

JBOD ストレージを使用するには、Kafka リソースのストレージタイプ設定を jbod に設定します。volumes プロパティーを使用すると、JBOD ストレージアレイまたは設定を設定するディスクを記述できます。

JBOD ストレージ設定の例

# ...
storage:
  type: jbod
  volumes:
  - id: 0
    type: persistent-claim
    size: 100Gi
    deleteClaim: false
  - id: 1
    type: persistent-claim
    size: 100Gi
    deleteClaim: false
# ...

JBOD ボリュームが作成されると、ID を変更することはできません。JBOD 設定からボリュームを追加または削除できます。

2.2.3.5.1. JBOD ストレージの PVC リソース

永続ストレージを使用して JBOD ボリュームを宣言すると、次の名前の PVC が作成されます。

data-id-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを格納するために使用されるボリュームの PVC。id は、Kafka ブローカー Pod のデータを格納するために使用されるボリュームの ID になります。
2.2.3.5.2. Kafka ログディレクトリーのマウントパス

JBOD ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data-id/kafka-logidx

id は、Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの ID に置き換えます。たとえば、/var/lib/kafka/data-0/kafka-log0 のようになります。

2.2.3.6. JBOD ストレージへのボリュームの追加

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターにボリュームを追加する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。

注記

以前使用され、削除された id の下に新規ボリュームを追加する場合、以前使用された PersistentVolumeClaims が必ず削除されているよう確認する必要があります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator
  • JBOD ストレージのある Kafka クラスター。

手順

  1. Kafka リソースの spec.kafka.storage.volumes プロパティーを編集します。新しいボリュームを volumes アレイに追加します。たとえば、id が 2 の新しいボリュームを追加します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 1
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 2
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>
  3. 新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てます。

    ヒント

    Cruise Control は、パーティションを再割り当てするための効果的なツールです。ブローカー内のディスク分散を実行するには、KafkaRebalance.specrebalanceDisktrue に設定します。

2.2.3.7. JBOD ストレージからのボリュームの削除

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターからボリュームを削除する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。JBOD ストレージには、常に 1 つのボリュームが含まれている必要があります。

重要

データの損失を避けるには、ボリュームを削除する前にすべてのパーティションを移動する必要があります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator
  • 複数のボリュームがある JBOD ストレージのある Kafka クラスター

手順

  1. 削除するディスクからすべてのパーティションを再度割り当てます。削除するディスクに割り当てられたままになっているパーティションのデータは削除される可能性があります。

    ヒント

    kafka-reassign-partitions.sh ツールを使用してパーティションを再割り当てできます。

  2. Kafka リソースの spec.kafka.storage.volumes プロパティーを編集します。volumes アレイから 1 つまたは複数のボリュームを削除します。たとえば、ID が 12 のボリュームを削除します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
  3. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

2.2.4. ターミナルからの ZooKeeper への接続

ほとんどの Kafka CLI ツールは Kafka に直接接続できます。したがって、通常の状況では ZooKeeper に接続する必要はありません。ZooKeeper サービスは暗号化および認証でセキュア化され、AMQ Streams の一部でない外部アプリケーションでの使用は想定されていません。

ただし、ZooKeeper への接続を必要とする Kafka CLI ツールを使用する場合は、ZooKeeper コンテナー内でターミナルを使用し、ZooKeeper アドレスとして localhost:12181 に接続できます。

前提条件

  • 利用可能な OpenShift クラスター
  • 稼働中の Kafka クラスター
  • Cluster Operator が稼働中です。

手順

  1. OpenShift コンソールを使用してターミナルを開くか、CLI から exec コマンドを実行します。

    以下に例を示します。

    oc exec -ti my-cluster-zookeeper-0 -- bin/kafka-topics.sh --list --zookeeper localhost:12181

    必ず localhost:12181 を使用してください。

    ZooKeeper に対して Kafka コマンドを実行できるようになりました。

2.2.5. Kafka ノードの手動による削除

この手順では、OpenShift アノテーションを使用して既存の Kafka ノードを削除する方法を説明します。Kafka ノードの削除するには、Kafka ブローカーが稼働している Pod と、関連する PersistentVolumeClaim の両方を削除します (クラスターが永続ストレージでデプロイされた場合)。削除後、Pod と関連する PersistentVolumeClaim が自動的に再作成されます。

警告

PersistentVolumeClaim を削除すると、データが永久に失われる可能性があります。以下の手順は、ストレージで問題が発生した場合にのみ実行してください。

前提条件

以下を実行する方法については、OpenShift での AMQ Streams のデプロイおよびアップグレード を参照すること。

手順

  1. 削除する Pod の名前を見つけます。

    Kafka ブローカー Pod の名前は <cluster-name>-kafka-<index> です。ここで、<index> はゼロで始まり、レプリカの合計数から 1 を引いた数で終了します。例: my-cluster-kafka-0

  2. OpenShift で Pod リソースにアノテーションを付けます。

    oc annotate を使用します。

    oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true
  3. 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。

2.2.6. ZooKeeper ノードの手動による削除

この手順では、OpenShift アノテーションを使用して既存の ZooKeeper ノードを削除する方法を説明します。ZooKeeper ノードを削除するには、ZooKeeper が稼働している Pod と、関連する PersistentVolumeClaim の両方を削除します (クラスターが永続ストレージでデプロイされた場合)。削除後、Pod と関連する PersistentVolumeClaim が自動的に再作成されます。

警告

PersistentVolumeClaim を削除すると、データが永久に失われる可能性があります。以下の手順は、ストレージで問題が発生した場合にのみ実行してください。

前提条件

以下を実行する方法については、OpenShift での AMQ Streams のデプロイおよびアップグレード を参照すること。

手順

  1. 削除する Pod の名前を見つけます。

    ZooKeeper Pod の名前は <cluster-name>-zookeeper-<index> です。ここで、<index> はゼロで始まり、レプリカの合計数から 1 を引いた数で終了します。例: my-cluster-zookeeper-0

  2. OpenShift で Pod リソースにアノテーションを付けます。

    oc annotate を使用します。

    oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true
  3. 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。

2.2.7. Kafka クラスターリソースのリスト

以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。

共有リソース

cluster-name-cluster-ca
クラスター通信の暗号化に使用されるクラスター CA プライベートキーのあるシークレット。
cluster-name-cluster-ca-cert
クラスター CA 公開鍵のあるシークレット。このキーは、Kafka ブローカーのアイデンティティーの検証に使用できます。
cluster-name-clients-ca
ユーザー証明書に署名するために使用されるクライアント CA 秘密鍵のあるシークレット。
cluster-name-clients-ca-cert
クライアント CA 公開鍵のあるシークレット。このキーは、Kafka ユーザーのアイデンティティーの検証に使用できます。
cluster-name-cluster-operator-certs
Kafka および ZooKeeper と通信するための Cluster Operator キーのあるシークレット。

ZooKeeper ノード

cluster-name-zookeeper

以下の ZooKeeper リソースに指定された名前。

  • ZooKeeper ノード Pod を管理するための StrimziPodSet または StatefulSet (UseStrimziPodSets フィーチャーゲートが無効な場合)。
  • ZooKeeper ノードで使用されるサービスアカウント。
  • ZooKeeper ノードに設定された PodDisruptionBudget。
cluster-name-zookeeper-idx
ZooKeeper StatefulSet または StrimziPodSet によって作成された Pod。
cluster-name-zookeeper-nodes
DNS が ZooKeeper Pod の IP アドレスを直接解決するのに必要なヘッドレスサービス。
cluster-name-zookeeper-client
Kafka ブローカーがクライアントとして ZooKeeper ノードに接続するために使用するサービス。
cluster-name-zookeeper-config
ZooKeeper 補助設定が含まれ、ZooKeeper ノード Pod によってボリュームとしてマウントされる ConfigMap。
cluster-name-zookeeper-nodes
ZooKeeper ノードキーがあるシークレット。
cluster-name-network-policy-zookeeper
ZooKeeper サービスへのアクセスを管理するネットワークポリシー。
data-cluster-name-zookeeper-idx
ZooKeeper ノード Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。

Kafka ブローカー

cluster-name-kafka

以下の Kafka リソースに指定された名前。

  • Kafka ブローカー Pod を管理するための StrimziPodSet または StatefulSet (UseStrimziPodSets フィーチャーゲートが無効な場合)。
  • Kafka Pod によって使用されるサービスアカウント。
  • Kafka ブローカーに設定された PodDisruptionBudget。
cluster-name-kafka-idx

以下の Kafka リソースに指定された名前。

  • Kafka StatefulSet または StrimziPodSet によって作成された Pod。
  • Kafka ブローカー設定を含む ConfigMap (UseStrimziPodSets フィーチャーゲートが有効な場合)。
cluster-name-kafka-brokers
DNS が Kafka ブローカー Pod の IP アドレスを直接解決するのに必要なサービス。
cluster-name-kafka-bootstrap
サービスは、OpenShift クラスター内から接続する Kafka クライアントのブートストラップサーバーとして使用できます。
cluster-name-kafka-external-bootstrap
OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いサービス名が使用されます。
cluster-name-kafka-pod-id
トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いサービス名が使用されます。
cluster-name-kafka-external-bootstrap
OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いルート名が使用されます。
cluster-name-kafka-pod-id
OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いルート名が使用されます。
cluster-name-kafka-listener-name-bootstrap
OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-listener-name-pod-id
トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-listener-name-bootstrap
OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-listener-name-pod-id
OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-config
Kafka の補助設定を含む ConfigMap。UseStrimziPodSets フィーチャーゲートが無効な場合、ブローカー Pod によってボリュームとしてマウントされます。
cluster-name-kafka-brokers
Kafka ブローカーキーのあるシークレット。
cluster-name-network-policy-kafka
Kafka サービスへのアクセスを管理するネットワークポリシー。
strimzi-namespace-name-cluster-name-kafka-init
Kafka ブローカーによって使用されるクラスターロールバインディング。
cluster-name-jmx
Kafka ブローカーポートのセキュア化に使用される JMX ユーザー名およびパスワードのあるシークレット。このリソースは、Kafka で JMX が有効になっている場合にのみ作成されます。
data-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。
data-id-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを保存するために使用されるボリューム id の永続ボリューム要求です。このリソースは、永続ボリュームをプロビジョニングしてデータを保存するときに、JBOD ボリュームに永続ストレージが選択された場合のみ作成されます。

Entitiy Operator

これらのリソースは、Cluster Operator を使用して Entity Operator がデプロイされる場合にのみ作成されます。

cluster-name-entity-operator

以下の Entity Operator リソースに指定された名前:

  • Topic および User Operator とのデプロイメント。
  • Entity Operator によって使用されるサービスアカウント。
cluster-name-entity-operator-random-string
Entity Operator デプロイメントによって作成された Pod。
cluster-name-entity-topic-operator-config
Topic Operator の補助設定のある ConfigMap。
cluster-name-entity-user-operator-config
User Operator の補助設定のある ConfigMap。
cluster-name-entity-topic-operator-certs
Kafka および ZooKeeper と通信するための Topic Operator キーのあるシークレット。
cluster-name-entity-user-operator-certs
Kafka および ZooKeeper と通信するための User Operator キーのあるシークレット。
strimzi-cluster-name-entity-topic-operator
Entity Topic Operator によって使用されるロールバインディング。
strimzi-cluster-name-entity-user-operator
Entity User Operator によって使用されるロールバインディング。

Kafka Exporter

これらのリソースは、Cluster Operator を使用して Kafka Exporter がデプロイされる場合にのみ作成されます。

cluster-name-kafka-exporter

以下の Kafka Exporter リソースに指定された名前。

  • Kafka Exporter でのデプロイメント。
  • コンシューマーラグメトリクスの収集に使用されるサービス。
  • Kafka Exporter によって使用されるサービスアカウント。
cluster-name-kafka-exporter-random-string
Kafka Exporter デプロイメントによって作成された Pod。

Cruise Control

これらのリソースは、Cluster Operator を使用して Cruise Control がデプロイされた場合のみ作成されます。

cluster-name-cruise-control

以下の Cruise Control リソースに指定された名前。

  • Cruise Control でのデプロイメント。
  • Cruise Control との通信に使用されるサービス。
  • Cruise Control によって使用されるサービスアカウント。
cluster-name-cruise-control-random-string
Cruise Control デプロイメントによって作成された Pod。
cluster-name-cruise-control-config
Cruise Control の補助設定が含まれ、Cruise Control Pod によってボリュームとしてマウントされる ConfigMap。
cluster-name-cruise-control-certs
Kafka および ZooKeeper と通信するための Cruise Control キーのあるシークレット。
cluster-name-network-policy-cruise-control
Cruise Control サービスへのアクセスを管理するネットワークポリシー。

2.3. Kafka Connect クラスターの設定

KafkaConnect リソースを使用して Kafka Connect デプロイメントを設定します。Kafka Connect は、コネクタープラグインを使用して Kafka ブローカーと他のシステムの間でデータをストリーミングする統合ツールです。Kafka Connect は、Kafka と、データベースなどの外部データソースまたはターゲットを統合するためのフレームワークを提供し、コネクターを使用してデータをインポートまたはエクスポートします。コネクターは、必要な接続設定を提供するプラグインです。

KafkaConnect スキーマ参照」 KafkaConnect リソースの完全なスキーマについて説明します。

コネクタープラグインのデプロイの詳細については、コネクタープラグインによる Kafka Connect の拡張 を参照してください。

2.3.1. Kafka Connect の設定

Kafka Connect を使用して、Kafka クラスターへの外部データ接続を設定します。KafkaConnect リソースのプロパティーを使用して、Kafka Connect デプロイメントを設定します。

KafkaConnector の設定

KafkaConnect リソースを使用すると、Kafka Connect のコネクターインスタンスを OpenShift ネイティブに作成および管理できます。

Kafka Connect 設定では、strimzi.io/use-connector-resources アノテーションを追加して、Kafka Connect クラスターの KafkaConnectors を有効にします。また、build 設定を追加して、データ接続に必要なコネクタープラグインを備えたコンテテナーイメージを AMQ Streams が自動的にビルドするようにすることもできます。Kafka Connect コネクターの外部設定は、externalConfiguration プロパティーで指定します。

コネクターを管理するには、KafkaConnector カスタムリソースまたは Kafka Connect REST API を使用できます。KafkaConnector リソースは、リンク先の Kafka Connect クラスターと同じ namespace にデプロイする必要があります。これらの方法を使用してコネクターを作成、再設定、または削除する方法の詳細については、コネクターの追加 を参照してください。

コネクター設定は、HTTP リクエストの一部として Kafka Connect に渡され、Kafka 自体に保存されます。ConfigMap およびシークレットは、設定やデータの保存に使用される標準的な OpenShift リソースです。ConfigMap およびシークレットを使用してコネクターの特定の要素を設定できます。その後、HTTP REST コマンドで設定値を参照できます。これにより、必要な場合は設定が分離され、よりセキュアになります。この方法は、ユーザー名、パスワード、証明書などの機密性の高いデータに適用されます。

大量のメッセージ処理

設定を調整して、大量のメッセージを処理できます。詳細については、大量のメッセージの処理 を参照してください。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

以下を実行する方法については、OpenShift での AMQ Streams のデプロイおよびアップグレード を参照すること。

手順

  1. KafkaConnect リソースの spec プロパティーを編集します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect 1
    metadata:
      name: my-connect-cluster
      annotations:
        strimzi.io/use-connector-resources: "true" 2
    spec:
      replicas: 3 3
      authentication: 4
        type: tls
        certificateAndKey:
          certificate: source.crt
          key: source.key
          secretName: my-user-source
      bootstrapServers: my-cluster-kafka-bootstrap:9092 5
      tls: 6
        trustedCertificates:
          - secretName: my-cluster-cluster-cert
            certificate: ca.crt
          - secretName: my-cluster-cluster-cert
            certificate: ca2.crt
      config: 7
        group.id: my-connect-cluster
        offset.storage.topic: my-connect-cluster-offsets
        config.storage.topic: my-connect-cluster-configs
        status.storage.topic: my-connect-cluster-status
        key.converter: org.apache.kafka.connect.json.JsonConverter
        value.converter: org.apache.kafka.connect.json.JsonConverter
        key.converter.schemas.enable: true
        value.converter.schemas.enable: true
        config.storage.replication.factor: 3
        offset.storage.replication.factor: 3
        status.storage.replication.factor: 3
      build: 8
        output: 9
          type: docker
          image: my-registry.io/my-org/my-connect-cluster:latest
          pushSecret: my-registry-credentials
        plugins: 10
          - name: debezium-postgres-connector
            artifacts:
              - type: tgz
                url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/2.1.3.Final/debezium-connector-postgres-2.1.3.Final-plugin.tar.gz
                sha512sum: c4ddc97846de561755dc0b021a62aba656098829c70eb3ade3b817ce06d852ca12ae50c0281cc791a5a131cb7fc21fb15f4b8ee76c6cae5dd07f9c11cb7c6e79
          - name: camel-telegram
            artifacts:
              - type: tgz
                url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.11.5/camel-telegram-kafka-connector-0.11.5-package.tar.gz
                sha512sum: d6d9f45e0d1dbfcc9f6d1c7ca2046168c764389c78bc4b867dab32d24f710bb74ccf2a007d7d7a8af2dfca09d9a52ccbc2831fc715c195a3634cca055185bd91
      externalConfiguration: 11
        env:
          - name: AWS_ACCESS_KEY_ID
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsAccessKey
          - name: AWS_SECRET_ACCESS_KEY
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsSecretAccessKey
      resources: 12
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 13
        type: inline
        loggers:
          log4j.rootLogger: "INFO"
      readinessProbe: 14
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      metricsConfig: 15
        type: jmxPrometheusExporter
        valueFrom:
          configMapKeyRef:
            name: my-config-map
            key: my-key
      jvmOptions: 16
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 17
      rack:
        topologyKey: topology.kubernetes.io/zone 18
      template: 19
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 20
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
    1
    KafkaConnect を使用します。
    2
    Kafka Connect クラスターの KafkaConnectors を有効にします。
    3
    タスクを実行するワーカーの レプリカノード数
    4
    mTLSトークンベースの OAuth、SASL ベース SCRAM-SHA-256/SCRAM-SHA-512、または PLAIN として指定された Kafka Connect クラスターの認証。デフォルトでは、Kafka Connect はプレーンテキスト接続を使用して Kafka ブローカーに接続します。
    5
    Kafka Connect クラスターに接続するための ブートストラップサーバー
    6
    クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
    7
    ワーカーの Kafka Connect 設定 (コネクターではない)。標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
    8
    コネクタープラグインで自動的にコンテナーイメージをビルドするための ビルド設定プロパティー
    9
    (必須) 新しいイメージがプッシュされるコンテナーレジストリーの設定。
    10
    (必須) 新しいコンテナーイメージに追加するコネクタープラグインとそれらのアーティファクトの一覧。各プラグインは、1 つ以上の artifact で設定する必要があります。
    11
    ここで示す環境変数や、ボリュームを使用した Kafka コネクターの外部設定設定プロバイダープラグイン を使用して、外部ソースから設定値を読み込む こともできます。
    12
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    13
    指定された Kafka loggers and log levels が ConfigMap を介して直接的に (inline) または間接的に (external) に追加されます。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。Kafka Connect log4j.rootLogger ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
    14
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    15
    Prometheus メトリクス。この例では、Prometheus JMX エクスポーターの設定が含まれる ConfigMap を参照して有効になります。metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap の参照を使用して、追加設定なしでメトリクスを有効にできます。
    16
    Kafka Connect を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    17
    高度な任意設定: 特別な場合のみ推奨される コンテナーイメージの設定
    18
    特別なオプション: 展開のための Rack awareness 設定。これは、リージョン間ではなく、同じロケーション内でのデプロイメントを目的とした特殊なオプションです。このオプションは、コネクターがリーダーレプリカではなく、最も近いレプリカから消費する場合に使用できます。場合によっては、最も近いレプリカから消費することで、ネットワークの使用率を改善したり、コストを削減したりできます。topologyKey は、ラック ID を含むノードラベルと一致する必要があります。この設定で使用される例では、標準の topology.kubernetes.io/zone ラベルを使用するゾーンを指定します。最も近いレプリカから消費するには、Kafka ブローカー設定で RackAwareReplicaSelector を有効にします。
    19
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    20
    分散トレース用に環境変数が設定されます。
  2. リソースを作成または更新します。

    oc apply -f KAFKA-CONNECT-CONFIG-FILE
  3. Kafka Connect の承認が有効である場合、Kafka Connect ユーザーを設定し、Kafka Connect のコンシューマーグループおよびトピックへのアクセスを有効化 します。

2.3.2. 複数のインスタンス用の Kafka Connect の設定

Kafka Connect のインスタンスを複数実行している場合は、以下の config プロパティーのデフォルト設定を変更する必要があります。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: connect-cluster 1
    offset.storage.topic: connect-cluster-offsets 2
    config.storage.topic: connect-cluster-configs 3
    status.storage.topic: connect-cluster-status  4
    # ...
# ...
1
Kafka 内の Kafka Connect クラスター ID。
2
コネクターオフセットを保存する Kafka トピック。
3
コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4
コネクターおよびタスクステータスの更新を保存する Kafka トピック。
注記

group.id が同じすべての Kafka Connect インスタンスで、これら 3 つのトピックの値を揃える必要があります。

デフォルト設定を変更しない限り、同じ Kafka クラスターに接続する Kafka Connect インスタンスはそれぞれ同じ値でデプロイされます。事実上、すべてのインスタンスが結合されてクラスターで実行されて同じトピックを使用するようになります。

複数の Kafka Connect クラスターが同じトピックの使用を試みると、Kafka Connect は想定どおりに動作せず、エラーが生成されます。

複数の Kafka Connect インスタンスを実行する場合は、インスタンスごとにこれらのプロパティーの値を変更してください。

2.3.3. Kafka Connect のユーザー承認の設定

この手順では、Kafka Connect のユーザーアクセスを承認する方法を説明します。

Kafka でいずれかのタイプの承認が使用される場合、Kafka Connect ユーザーは Kafka Connect のコンシューマーグループおよび内部トピックへの読み書きアクセス権限が必要になります。

コンシューマーグループおよび内部トピックのプロパティーは AMQ Streams によって自動設定されますが、KafkaConnect リソースの spec で明示的に指定することもできます。

KafkaConnect リソースの設定プロパティーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster 1
    offset.storage.topic: my-connect-cluster-offsets 2
    config.storage.topic: my-connect-cluster-configs 3
    status.storage.topic: my-connect-cluster-status 4
    # ...
  # ...

1
Kafka 内の Kafka Connect クラスター ID。
2
コネクターオフセットを保存する Kafka トピック。
3
コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4
コネクターおよびタスクステータスの更新を保存する Kafka トピック。

この手順では、simple 承認の使用時にアクセス権限が付与される方法を説明します。

簡易承認では、Kafka AclAuthorizer プラグインによって処理される ACL ルールを使用し、適切なレベルのアクセス権限が提供されます。KafkaUser リソースに簡易認証を使用するように設定する方法については、AclRule スキーマリファレンスを参照してください。

注記

複数のインスタンスを実行 している場合、コンシューマーグループとトピックのデフォルト値は異なります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

手順

  1. KafkaUser リソースの authorization プロパティーを編集し、アクセス権限をユーザーに付与します。

    以下の例では、literal の名前の値を使用して Kafka Connect トピックおよびコンシューマーグループにアクセス権限が設定されます。

    プロパティー名前

    offset.storage.topic

    connect-cluster-offsets

    status.storage.topic

    connect-cluster-status

    config.storage.topic

    connect-cluster-configs

    group

    connect-cluster

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      # ...
      authorization:
        type: simple
        acls:
          # access to offset.storage.topic
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operations:
              - Create
              - Describe
              - Read
              - Write
            host: "*"
          # access to status.storage.topic
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operations:
              - Create
              - Describe
              - Read
              - Write
            host: "*"
          # access to config.storage.topic
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operations:
              - Create
              - Describe
              - Read
              - Write
            host: "*"
          # consumer group
          - resource:
              type: group
              name: connect-cluster
              patternType: literal
            operations:
              - Read
            host: "*"
  2. リソースを作成または更新します。

    oc apply -f KAFKA-USER-CONFIG-FILE

2.3.4. Kafka Connect クラスターリソースの一覧

以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。

connect-cluster-name-connect

次の Kafka Connect リソースに付けられた名前:

  • Kafka Connect ワーカーノード Pod を作成するデプロイメント (StableConnectIdentities フィーチャーゲートが無効な場合)。
  • Kafka Connect ワーカーノード Pod を作成する StrimziPodSet (StableConnectIdentities フィーチャーゲートが有効な場合)。
  • 安定した DNS 名を Connect Pod に提供するヘッドレスサービス (StableConnectIdentities フィーチャーゲートが有効な場合)。
  • Kafka Connect ワーカーノードに設定された Pod の Disruption Budget。
connect-cluster-name-connect-idx
Kafka Connect StrimziPodSet によって作成された Pod (StableConnectIdentities フィーチャーゲートが有効な場合)。
connect-cluster-name-connect-api
Kafka Connect クラスターを管理するために REST インターフェイスを公開するサービス。
connect-cluster-name-config
Kafka Connect 補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。

2.3.5. 変更データキャプチャーのための Debezium の Red Hat ビルドとの統合

Debezium の Red Hat ビルドは、分散型の変更データキャプチャープラットフォームです。データベースの行レベルの変更をキャプチャーして、変更イベントレコードを作成し、Kafka トピックにレコードをストリーミングします。Debezium は Apache Kafka に構築されます。AMQ Streams で Red Hat build of Debezium をデプロイおよび統合できます。AMQ Streams のデプロイ後に、Kafka Connect で Debezium をコネクター設定としてデプロイします。Debezium は変更イベントレコードを AMQ Streams on OpenShift に渡します。アプリケーションは 変更イベントストリーム を読み取りでき、変更イベントが発生した順にアクセスできます。

Debezium には、以下を含む複数の用途があります。

  • データレプリケーション
  • キャッシュの更新およびインデックスの検索
  • モノリシックアプリケーションの簡素化
  • データ統合
  • ストリーミングクエリーの有効化

データベースの変更をキャプチャーするには、Debezium データベースコネクターで Kafka Connect をデプロイします。KafkaConnector リソースを設定し、コネクターインスタンスを定義します。

AMQ Streams で Debezium の Red Hat ビルドをデプロイする方法の詳細は、製品ドキュメント を参照してください。ドキュメントには、Debezium スタートガイド が含まれています。このガイドでは、データベース更新の変更イベントレコードの表示に必要なサービスおよびコネクターの設定方法を説明しています。

2.4. Kafka MirrorMaker 2 クラスター設定

KafkaMirrorMaker2 リソースを使用して、Kafka MirrorMaker 2 デプロイメントを設定します。MirrorMaker 2 は、データセンター内またはデータセンター間で 2 つ以上の Kafka クラスター間でデータを複製します。

KafkaMirrorMaker2 スキーマ参照」 KafkaMirrorMaker2 リソースの完全なスキーマについて説明します。

MirrorMaker 2 のリソース設定は、MirrorMaker の以前のバージョンとは異なります。MirrorMaker 2 の使用を選択した場合は、現在レガシーサポートがないため、リソースを手動で新しい形式に変換する必要があります。

2.4.1. MirrorMaker 2 データレプリケーション

クラスター全体のデータレプリケーションでは、以下を必要とする状況がサポートされます。

  • システム障害時のデータの復旧
  • 分析用のデータの集計
  • 特定のクラスターへのデータアクセスの制限
  • レイテンシーを改善するための特定場所でのデータのプロビジョニング
2.4.1.1. MirrorMaker 2 の設定

MirrorMaker 2 は、ソース Kafka クラスターからのメッセージを消費し、ターゲット Kafka クラスターに書き込みます。

MirrorMaker 2 は以下を使用します。

  • ソースクラスターからデータを消費するソースクラスターの設定
  • データをターゲットクラスターに出力するターゲットクラスターの設定

MirrorMaker 2 は、クラスター間のデータ転送を管理する コネクター である Kafka Connect フレームワークに基づいています。

MirrorMaker 2 を設定して、ソースクラスターとターゲットクラスターの接続の詳細を含む Kafka Connect デプロイメントを定義し、一連の MirrorMaker 2 コネクターを実行して接続を確立します。

MirrorMaker 2 は次のコネクターで設定されます。

MirrorSourceConnector
ソースコネクターは、トピックをソースクラスターからターゲットクラスターにレプリケーションします。また、ACL をレプリケーションし、MirrorCheckpointConnector を実行する必要があります。
MirrorCheckpointConnector
チェックポイントコネクターは定期的にオフセットを追跡します。有効にすると、ソースクラスターとターゲットクラスター間のコンシューマーグループオフセットも同期されます。
MirrorHeartbeatConnector
ハートビートコネクターは、ソースクラスターとターゲットクラスター間の接続を定期的にチェックします。
注記

User Operator を使用して ACL を管理する場合、コネクターを介した ACL レプリケーションはできません。

ソースクラスターからターゲットクラスターへのデータの ミラーリング プロセスは非同期です。各 MirrorMaker 2 インスタンスは、1 つのソースクラスターから 1 つのターゲットクラスターにデータをミラーリングします。複数の MirrorMaker 2 インスタンスを使用して、任意の数のクラスター間でデータをミラーリングできます。

図2.1 2 つのクラスターにおけるレプリケーション

MirrorMaker 2 レプリケーション

デフォルトでは、ソースクラスターの新規トピックのチェックは 10 分ごとに行われます。頻度は、refresh.topics.interval.seconds をソースコネクター設定に追加することで変更できます。

2.4.1.1.1. クラスター設定

MirrorMaker 2 は、アクティブ/パッシブ または アクティブ/アクティブ クラスター設定で使用できます。

アクティブ/アクティブのクラスター設定
アクティブ/アクティブ設定には、双方向でデータをレプリケーションするアクティブなクラスターが 2 つあります。アプリケーションはいずれかのクラスターを使用できます。各クラスターは同じデータを提供できます。これにより、地理的に異なる場所で同じデータを利用できるようにします。コンシューマーグループは両方のクラスターでアクティブであるため、レプリケーションされたトピックのコンシューマーオフセットはソースクラスターに同期されません。
アクティブ/パッシブクラスター設定
アクティブ/パッシブ設定には、パッシブクラスターにデータをレプリケーションするアクティブクラスターがあります。パッシブクラスターはスタンバイのままになります。システムに障害が発生した場合に、データ復旧にパッシブクラスターを使用できます。

プロデューサーとコンシューマーがアクティブなクラスターのみに接続することを前提とします。MirrorMaker 2 クラスターはターゲットごとに必要です。

2.4.1.1.2. 双方向レプリケーション (active/active)

MirrorMaker 2 アーキテクチャーは、アクティブ/アクティブ クラスター設定での双方向レプリケーションをサポートします。

各クラスターは、source および remote トピックの概念を使用して、別のクラスターのデータをレプリケーションします。同じトピックが各クラスターに保存されるため、リモートトピックの名前は MirrorMaker 2 によってソースクラスターを表すように自動的に変更されます。元のクラスターの名前の先頭には、トピックの名前が追加されます。

図2.2 トピック名の変更

MirrorMaker 2 双方向アーキテクチャー

ソースクラスターにフラグを付けると、トピックはそのクラスターにレプリケーションされません。

remote トピックを介したレプリケーションの概念は、データの集約が必要なアーキテクチャーの設定に役立ちます。コンシューマーは、同じクラスター内でソースおよびリモートトピックにサブスクライブできます。これに個別の集約クラスターは必要ありません。

2.4.1.1.3. 一方向レプリケーション (active/passive)

MirrorMaker 2 アーキテクチャーは、アクティブ/パッシブ クラスター設定での一方向レプリケーションをサポートします。

active/passive のクラスター設定を使用してバックアップを作成したり、データを別のクラスターに移行したりできます。この場合、リモートトピックの名前の自動変更はお勧めしません。

IdentityReplicationPolicy をソースコネクター設定に追加することで、名前の自動変更をオーバーライドできます。この設定が適用されると、トピックには元の名前が保持されます。

2.4.1.2. トピック設定の同期

MirrorMaker 2 は、ソースクラスターとターゲットクラスター間のトピック設定の同期をサポートします。MirrorMaker 2 設定でソーストピックを指定します。MirrorMaker 2 はソーストピックを監視します。MirrorMaker 2 は、ソーストピックへの変更を検出し、リモートトピックに伝達します。変更には、欠けているトピックおよびパーティションの自動作成が含まれる場合があります。

注記

ほとんどの場合、ローカルトピックに書き込み、リモートトピックから読み取ります。リモートトピックでは書き込み操作ができないわけではありませんが、使用しないようにしてください。

2.4.1.3. オフセットの追跡

MirrorMaker 2 は、内部トピックを使用してコンシューマーグループのオフセットを追跡します。

offset-syncs トピック
offset-syncs トピックは、レプリケーションされたトピックパーティションのソースおよびターゲットオフセットをレコードメタデータからマッピングします。
checkpoints トピック
checkpoints トピックは、各コンシューマーグループでレプリケーションされたトピックパーティションのソースおよびターゲットクラスターで、最後にコミットされたオフセットをマッピングします。

これらは MirrorMaker 2 によって内部的に使用されるため、これらのトピックと直接対話することはありません。

MirrorCheckpointConnector は、オフセット追跡用の チェックポイント を発行します。checkpoints トピックのオフセットは、設定によって事前に決定された間隔で追跡されます。両方のトピックは、フェイルオーバー時に正しいオフセットの位置からレプリケーションの完全復元を可能にします。

offset-syncs トピックの場所は、デフォルトで source クラスターです。offset-syncs.topic.location コネクター設定を使用して、これを target クラスターに変更することができます。トピックが含まれるクラスターへの読み取り/書き込みアクセスが必要です。ターゲットクラスターを offset-syncs トピックの場所として使用すると、ソースクラスターへの読み取りアクセス権しかない場合でも、MirrorMaker 2 を使用できるようになります。

2.4.1.4. コンシューマーグループオフセットの同期

__consumer_offsets トピックには、各コンシューマーグループのコミットされたオフセットに関する情報が保存されます。オフセットの同期は、ソースクラスターのコンシューマーグループのコンシューマーオフセットをターゲットクラスターのコンシューマーオフセットに定期的に転送します。

オフセットの同期は、特に active/passive 設定で便利です。アクティブなクラスターがダウンした場合、コンシューマーアプリケーションをパッシブ (スタンバイ) クラスターに切り替え、最後に転送されたオフセットの位置からピックアップできます。

トピックオフセットの同期を使用するには、sync.group.offsets.enabled を checkpoint コネクター設定に追加し、プロパティーを true に設定して、同期を有効にします。同期はデフォルトで無効になっています。

ソースコネクターで IdentityReplicationPolicy を使用する場合は、チェックポイントコネクター設定でも設定する必要があります。これにより、ミラーリングされたコンシューマーオフセットが正しいトピックに適用されます。

コンシューマーオフセットは、ターゲットクラスターでアクティブではないコンシューマーグループに対してのみ同期されます。コンシューマーグループがターゲットクラスターにある場合、Synchronization を実行できず、UNKNOWN_MEMBER_ID エラーが返されます。

同期を有効にすると、ソースクラスターからオフセットの同期が定期的に行われます。この頻度は、sync.group.offsets.interval.seconds および emit.checkpoints.interval.seconds をチェックポイントコネクター設定に追加することで変更できます。これらのプロパティーは、コンシューマーグループのオフセットが同期される頻度 (秒単位) と、オフセットを追跡するためにチェックポイントが生成される頻度を指定します。両方のプロパティーのデフォルトは 60 秒です。refresh.groups.interval.seconds プロパティーを使用して、新規コンシューマーグループのチェック頻度を変更することもできます。デフォルトでは 10 分ごとに実行されます。

同期は時間ベースであるため、コンシューマーによってパッシブクラスターへ切り替えられると、一部のメッセージが重複する可能性があります。

注記

Java で作成されたアプリケーションがある場合は、RemoteClusterUtils.java ユーティリティーを使用して、アプリケーションを通じてオフセットを同期できます。ユーティリティーは、checkpoints トピックからコンシューマーグループのリモートオフセットを取得します。

2.4.1.5. 接続性チェック

MirrorHeartbeatConnectorheartbeat を発行して、クラスター間の接続を確認します。

内部 heartbeat トピックは、ソースクラスターからレプリケーションされます。ターゲットクラスターは、heartbeat トピックを使用して次のことを確認します。

  • クラスター間の接続を管理するコネクターが稼働しているかどうか
  • ソースクラスターが利用可能かどうか

2.4.2. コネクター設定

Kafka クラスター間のデータの同期を調整する内部コネクターには、Mirrormaker 2 コネクター設定を使用します。

以下の表は、コネクタープロパティーと、これらを使用するために設定するコネクターについて説明しています。

表2.1 MirrorMaker 2 コネクター設定プロパティー
プロパティーsourceConnectorcheckpointConnectorheartbeatConnector
admin.timeout.ms
新規トピックの検出などの管理タスクのタイムアウト。デフォルトは 60000 (1 分) です。

replication.policy.class
リモートトピックの命名規則を定義するポリシー。デフォルトは org.apache.kafka.connect.mirror.DefaultReplicationPolicy です。

replication.policy.separator
ターゲットクラスターのトピックの命名に使用されるセパレーター。デフォルトは . (ドット) です。

consumer.poll.timeout.ms
ソースクラスターをポーリングする際のタイムアウト。デフォルトは 1000 (1 秒) です。

 
offset-syncs.topic.location
offset-syncs トピックの場所。これは、source (デフォルト) または target クラスターになります。

 
topic.filter.class
レプリケーションするトピックを選択するためのトピックフィルター。デフォルトは org.apache.kafka.connect.mirror.DefaultTopicFilter です。

 
config.property.filter.class
レプリケーションするトピック設定プロパティーを選択するトピックフィルター。デフォルトは org.apache.kafka.connect.mirror.DefaultConfigPropertyFilter です。

  
config.properties.exclude
レプリケーションすべきでないトピック設定プロパティー。コンマ区切りのプロパティー名と正規表現をサポートします。

  
offset.lag.max
リモートパーティションが同期されるまでの最大許容 (同期外) オフセットラグ。デフォルトは 100 です。

  
offset-syncs.topic.replication.factor
内部 offset-syncs トピックのレプリケーション係数。デフォルトは 3 です。

  
refresh.topics.enabled
新しいトピックおよびパーティションの確認を有効にします。デフォルトは true です。

  
refresh.topics.interval.seconds
トピック更新の頻度。デフォルトは 600 (10 分) です。

  
replication.factor
新しいトピックのレプリケーション係数。デフォルトは 2 です。

  
sync.topic.acls.enabled
ソースクラスターからの ACL の同期を有効にします。デフォルトは true です。User Operator との互換性がありません。

  
sync.topic.acls.interval.seconds
ACL 同期の頻度。デフォルトは 600 (10 分) です。

  
sync.topic.configs.enabled
ソースクラスターからのトピック設定の同期を有効にします。デフォルトは true です。

  
sync.topic.configs.interval.seconds
トピック設定の同期頻度。デフォルトは 600 (10 分) です。

  
checkpoints.topic.replication.factor
内部 checkpoints トピックのレプリケーション係数。デフォルトは 3 です。
 

 
emit.checkpoints.enabled
コンシューマーオフセットをターゲットクラスターに同期できるようにします。デフォルトは true です。
 

 
emit.checkpoints.interval.seconds
コンシューマーオフセット同期の頻度。デフォルトは 60 (1 分) です。
 

 
group.filter.class
レプリケーションするコンシューマーグループを選択するためのグループフィルター。デフォルトは org.apache.kafka.connect.mirror.DefaultGroupFilter です。
 

 
refresh.groups.enabled
新規コンシューマーグループの確認を有効にします。デフォルトは true です。
 

 
refresh.groups.interval.seconds
コンシューマーグループ更新の頻度。デフォルトは 600 (10 分) です。
 

 
sync.group.offsets.enabled
ターゲットクラスターの __consumer_offsets トピックへのコンシューマーグループオフセットの同期を有効にします。デフォルトは false です。
 

 
sync.group.offsets.interval.seconds
コンシューマーグループオフセット同期の頻度。デフォルトは 60 (1 分) です。
 

 
emit.heartbeats.enabled
ターゲットクラスターでの接続性チェックを有効にします。デフォルトは true です。
  

emit.heartbeats.interval.seconds
接続性チェックの頻度。デフォルトは 1 (1 秒) です。
  

heartbeats.topic.replication.factor
内部 heartbeats トピックのレプリケーション係数。デフォルトは 3 です。
  

2.4.3. コネクタープロデューサーおよびコンシューマーの設定

MirrorMaker 2 コネクターは、内部プロデューサーとコンシューマーを使用します。必要に応じて、これらのプロデューサーおよびコンシューマーを設定して、デフォルト設定を上書きできます。

たとえば、トピックをターゲットの Kafka クラスターに送信するソースプロデューサーの batch.size を増やして、大量のデータをより適切に対応できます。

重要

プロデューサおよびコンシューマーの設定オプションは MirrorMaker 2 の実装に依存しており、変更される可能性があります。

次の表では、各コネクターのプロデューサーとコンシューマー、および設定を追加できる場所について説明します。

表2.2 ソースコネクターのプロデューサーとコンシューマー
説明Configuration

producer

トピックメッセージをターゲット Kafka クラスターに送信します。大量のデータを処理する場合は、このプロデューサーの設定を調整することを検討してください。

mirrors.sourceConnector.config: producer.override.*

producer

レプリケートされたトピックパーティションのソースオフセットとターゲットオフセットをマップする、offset-syncs トピックに書き込みます。

mirrors.sourceConnector.config: producer.*

Consumer

ソース Kafka クラスターからトピックメッセージを取得します。

mirrors.sourceConnector.config: consumer.*

表2.3 チェックポイントコネクターのプロデューサーとコンシューマー
説明Configuration

producer

コンシューマーオフセットチェックポイントを発行します。

mirrors.checkpointConnector.config: producer.override.*

Consumer

offset-syncs トピックを読み込みます。

mirrors.checkpointConnector.config: consumer.*

注記

offset-syncs.topic.locationtarget に設定して、ターゲット Kafka クラスターを offset-syncs トピックの場所として使用できます。

表2.4 ハートビートコネクタープロデューサー
説明Configuration

producer

ハートビートを生成します。

mirrors.heartbeatConnector.config: producer.override.*

次の例は、プロデューサーとコンシューマーを設定する方法を示しています。

コネクターのプロデューサーとコンシューマーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.4.0
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 5
      config:
        producer.override.batch.size: 327680
        producer.override.linger.ms: 100
        producer.request.timeout.ms: 30000
        consumer.fetch.max.bytes: 52428800
        # ...
    checkpointConnector:
      config:
        producer.override.request.timeout.ms: 30000
        consumer.max.poll.interval.ms: 300000
        # ...
    heartbeatConnector:
      config:
        producer.override.request.timeout.ms: 30000
        # ...

2.4.4. タスクの最大数を指定

コネクターは、Kafka にデータを出し入れするタスクを作成します。各コネクターは、タスクを実行するワーカー Pod のグループ全体に分散される 1 つ以上のタスクで設定されます。タスクの数を増やすと、多数のパーティションをレプリケーションするとき、または多数のコンシューマーグループのオフセットを同期するときのパフォーマンスの問題に役立ちます。

タスクは並行して実行されます。ワーカーには 1 つ以上のタスクが割り当てられます。1 つのタスクが 1 つのワーカー Pod によって処理されるため、タスクよりも多くのワーカー Pod は必要ありません。ワーカーよりも多くのタスクがある場合、ワーカーは複数のタスクを処理します。

tasksMax プロパティーを使用して、MirrorMaker 設定でコネクタータスクの最大数を指定できます。タスクの最大数を指定しない場合、デフォルト設定のタスク数は 1 つです。

ハートビートコネクターは常に単一のタスクを使用します。

ソースおよびチェックポイントコネクターに対して開始されるタスクの数は、可能なタスクの最大数と tasksMax の値の間の低い値です。ソースコネクターの場合、可能なタスクの最大数は、ソースクラスターからレプリケーションされるパーティションごとに 1 つです。チェックポイントコネクターの場合、可能なタスクの最大数は、ソースクラスターからレプリケーションされるコンシューマーグループごとに 1 つです。タスクの最大数を設定するときは、プロセスをサポートするパーティションの数とハードウェアリソースを考慮してください。

インフラストラクチャーが処理のオーバーヘッドをサポートしている場合、タスクの数を増やすと、スループットと待機時間が向上する可能性があります。たとえば、タスクを追加すると、多数のパーティションまたはコンシューマーグループがある場合に、ソースクラスターのポーリングにかかる時間が短縮されます。

チェックポイントコネクターのタスク数を増やすと、多数のパーティションがある場合に役立ちます。

ソースコネクターのタスク数を増やす

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 10
  # ...

多数のコンシューマーグループがある場合は、チェックポイントコネクターのタスク数を増やすと便利です。

チェックポイントコネクターのタスク数の増加

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    checkpointConnector:
      tasksMax: 10
  # ...

デフォルトでは、MirrorMaker 2 は 10 分ごとに新しいコンシューマーグループをチェックします。refresh.groups.interval.seconds 設定を調整して、頻度を変更できます。低く調整するときは注意してください。より頻繁なチェックは、パフォーマンスに悪影響を及ぼす可能性があります。

2.4.4.1. コネクタータスクの動作の確認

Prometheus と Grafana を使用してデプロイメントを監視している場合は、MirrorMaker 2 のパフォーマンスをチェックできます。AMQ Streams で提供される MirrorMaker 2 Grafana ダッシュボードの例には、タスクとレイテンシーに関連する次のメトリックが表示されます。

  • タスクの数
  • レプリケーションのレイテンシー
  • オフセット同期のレイテンシー

2.4.5. ACL ルールの同期

User Operator を使用して いない 場合は、ACL でリモートトピックにアクセスできます。

User Operator なしで AclAuthorizer が使用されている場合、ブローカーへのアクセスを管理する ACL ルールはリモートトピックにも適用されます。ソーストピックを読み取りできるユーザーは、そのリモートトピックを読み取りできます。

注記

OAuth 2.0 での承認は、このようなリモートトピックへのアクセスをサポートしません。

2.4.6. Kafka MirrorMaker 2 の設定

KafkaMirrorMaker2 リソースのプロパティーを使用して、Kafka MirrorMaker 2 デプロイメントを設定します。MirrorMaker 2 を使用して、Kafka クラスター間でデータを同期します。

設定では以下を指定する必要があります。

  • 各 Kafka クラスター
  • 認証を含む各クラスターの接続情報
  • レプリケーションのフローおよび方向

    • クラスターからクラスターへ
    • トピックからトピックへ
注記

従来のバージョンの MirrorMaker は継続してサポートされます。以前のバージョン用に設定されたリソースを使用したい場合は、MirrorMaker 2 でサポートされる形式に更新する必要があります。

MirrorMaker 2 は、レプリケーション係数などのプロパティーのデフォルト設定値を提供します。デフォルトに変更がない最小設定の例は以下のようになります。

MirrorMaker 2 の最小設定

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.4.0
  connectCluster: "my-cluster-target"
  clusters:
  - alias: "my-cluster-source"
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092
  - alias: "my-cluster-target"
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector: {}

mTLS または SASL 認証を使用して、ソースおよびターゲットクラスターのアクセス制御を設定できます。この手順では、ソースおよびターゲットクラスターに対して mTLS による暗号化および認証を使用する設定を説明します。

KafkaMirrorMaker2 リソースのソースクラスターからレプリケートするトピックとコンシューマーグループを指定できます。これを行うには、topicsPattern および groupsPattern プロパティーを使用します。名前の一覧を指定したり、正規表現を使用したりできます。既定では、topicsPattern および groupsPattern プロパティーを設定しない場合、すべてのトピックとコンシューマーグループがレプリケートされます。.* を正規表現として使用して、すべてのトピックとコンシューマーグループを複製することもできます。ただし、クラスターに不要な負荷が余分にかかるのを避けるため、必要なトピックとコンシューマーグループのみを指定するようにしてください。

大量のメッセージ処理

設定を調整して、大量のメッセージを処理できます。詳細については、大量のメッセージの処理 を参照してください。

前提条件

  • AMQ Streams が実行されている
  • ソースおよびターゲットの Kafka クラスターが使用できる

手順

  1. KafkaMirrorMaker2 リソースの spec プロパティーを編集します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker2
    spec:
      version: 3.4.0 1
      replicas: 3 2
      connectCluster: "my-cluster-target" 3
      clusters: 4
      - alias: "my-cluster-source" 5
        authentication: 6
          certificateAndKey:
            certificate: source.crt
            key: source.key
            secretName: my-user-source
          type: tls
        bootstrapServers: my-cluster-source-kafka-bootstrap:9092 7
        tls: 8
          trustedCertificates:
          - certificate: ca.crt
            secretName: my-cluster-source-cluster-ca-cert
      - alias: "my-cluster-target" 9
        authentication: 10
          certificateAndKey:
            certificate: target.crt
            key: target.key
            secretName: my-user-target
          type: tls
        bootstrapServers: my-cluster-target-kafka-bootstrap:9092 11
        config: 12
          config.storage.replication.factor: 1
          offset.storage.replication.factor: 1
          status.storage.replication.factor: 1
          ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 13
          ssl.enabled.protocols: TLSv1.2
          ssl.protocol: TLSv1.2
          ssl.endpoint.identification.algorithm: HTTPS 14
        tls: 15
          trustedCertificates:
          - certificate: ca.crt
            secretName: my-cluster-target-cluster-ca-cert
      mirrors: 16
      - sourceCluster: "my-cluster-source" 17
        targetCluster: "my-cluster-target" 18
        sourceConnector: 19
          tasksMax: 10 20
          autoRestart: 21
            enabled: true
          config:
            replication.factor: 1 22
            offset-syncs.topic.replication.factor: 1 23
            sync.topic.acls.enabled: "false" 24
            refresh.topics.interval.seconds: 60 25
            replication.policy.separator: "." 26
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy" 27
        heartbeatConnector: 28
          autoRestart:
            enabled: true
          config:
            heartbeats.topic.replication.factor: 1 29
        checkpointConnector: 30
          autoRestart:
            enabled: true
          config:
            checkpoints.topic.replication.factor: 1 31
            refresh.groups.interval.seconds: 600 32
            sync.group.offsets.enabled: true 33
            sync.group.offsets.interval.seconds: 60 34
            emit.checkpoints.interval.seconds: 60 35
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy"
        topicsPattern: "topic1|topic2|topic3" 36
        groupsPattern: "group1|group2|group3" 37
      resources: 38
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 39
        type: inline
        loggers:
          connect.root.logger.level: "INFO"
      readinessProbe: 40
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      jvmOptions: 41
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 42
      rack:
        topologyKey: topology.kubernetes.io/zone 43
      template: 44
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 45
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing:
        type: jaeger 46
      externalConfiguration: 47
        env:
          - name: AWS_ACCESS_KEY_ID
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsAccessKey
          - name: AWS_SECRET_ACCESS_KEY
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsSecretAccessKey
    1
    常に同じになる Kafka Connect と Mirror Maker 2.0 の バージョン
    2
    タスクを実行するワーカーの レプリカノード数
    3
    Kafka Connect の Kafka クラスターエイリアスターゲット Kafka クラスターを指定する必要があります。Kafka クラスターは、その内部トピックのために Kafka Connect によって使用されます。
    4
    同期される Kafka クラスターの 指定
    5
    ソースの Kafka クラスターの クラスターエイリアス
    6
    ソースクラスターの認証。mTLSトークンベースの OAuth、SASL ベース SCRAM-SHA-256/SCRAM-SHA-512、または PLAIN として指定します。
    7
    ソース Kafka クラスターに接続するための ブートストラップサーバー
    8
    ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
    9
    ターゲット Kafka クラスターの クラスターエイリアス
    10
    ターゲット Kafka クラスターの認証は、ソース Kafka クラスターと同様に設定されます。
    11
    ターゲット Kafka クラスターに接続するための ブートストラップサーバー
    12
    Kafka Connect の設定。標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
    13
    TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー
    14
    HTTPS に設定することで、ホスト名の検証が有効 になります。空の文字列を指定すると検証が無効になります。
    15
    ターゲット Kafka クラスターの TLS による暗号化は、ソース Kafka クラスターと同様に設定されます。
    16
    17
    MirrorMaker 2 コネクターによって使用されるソースクラスターの クラスターエイリアス
    18
    MirrorMaker 2 コネクターによって使用されるターゲットクラスターの クラスターエイリアス
    19
    リモートトピックを作成する MirrorSourceConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    20
    コネクターによる作成が可能なタスクの最大数。タスクは、データのレプリケーションを処理し、並行して実行されます。インフラストラクチャーが処理のオーバーヘッドをサポートする場合、この値を大きくするとスループットが向上されます。Kafka Connect は、クラスターのメンバー間でタスクを分散します。ワーカーよりも多くのタスクがある場合は、ワーカーには複数のタスクが割り当てられます。シンクコネクターでは、消費される各トピックパーティションに 1 つタスクがあるようになることを目指します。ソースコネクターでは、並行して実行できるタスクの数は外部システムによって異なる場合もあります。並列処理を実現できない場合、コネクターは最大数より少ないタスクを作成します。
    21
    失敗したコネクターとタスクの自動再起動を有効にします。再起動は最大 7 回試行され、その後は手動で再起動する必要があります。
    22
    ターゲットクラスターで作成されるミラーリングされたトピックのレプリケーション係数。
    23
    ソースおよびターゲットクラスターのオフセットをマップする MirrorSourceConnector offset-syncs 内部トピックのレプリケーション係数。
    24
    ACL ルールの同期 が有効になっていると、同期されたトピックに ACL が適用されます。デフォルトは true です。この機能は User Operator と互換性がありません。User Operator を使用している場合は、このプロパティーを false に設定します。
    25
    新規トピックのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
    26
    リモートトピック名の変更に使用する区切り文字を定義します。
    27
    リモートトピック名の自動変更をオーバーライドするポリシーを追加します。その名前の前にソースクラスターの名前を追加する代わりに、トピックが元の名前を保持します。このオプションの設定は、active/passive バックアップおよびデータ移行に役立ちます。トピックオフセットの同期を設定するには、このプロパティーも checkpointConnector.config に設定する必要があります。
    28
    接続チェックを実行する MirrorHeartbeatConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    29
    ターゲットクラスターで作成されたハートビートトピックのレプリケーション係数。
    30
    オフセットを追跡する MirrorCheckpointConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    31
    ターゲットクラスターで作成されたチェックポイントトピックのレプリケーション係数。
    32
    新規コンシューマーグループのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
    33
    コンシューマーグループのオフセットを同期する任意設定。これは、active/passive 設定でのリカバリーに便利です。同期はデフォルトでは有効になっていません。
    34
    コンシューマーグループオフセットの同期が有効な場合は、同期の頻度を調整できます。
    35
    オフセット追跡のチェック頻度を調整します。オフセット同期の頻度を変更する場合は、これらのチェックの頻度も調整することをお勧めします。
    36
    コンマ区切りリストまたは正規表現パターンとして定義された ソースクラスターからのトピックレプリケーション。ソースコネクターは指定のトピックをレプリケーションします。チェックポイントコネクターは、指定されたトピックのオフセットを追跡します。ここでは、3 つのトピックを名前でリクエストします。
    37
    コンマ区切りリストまたは正規表現パターンとして定義され たソースクラスターからのコンシューマーグループのレプリケーション。チェックポイントコネクターは、指定されたコンシューマーグループをレプリケーションします。ここで、3 つのコンシューマーグループを名前で要求します。
    38
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    39
    指定された Kafka loggers and log levels が ConfigMap を介して直接的に (inline) または間接的に (external) に追加されます。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。Kafka Connect log4j.rootLogger ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
    40
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    41
    Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    42
    高度な任意設定: 特別な場合のみ推奨される コンテナーイメージの設定
    43
    特別なオプション: 展開のための Rack awareness 設定。これは、リージョン間ではなく、同じロケーション内でのデプロイメントを目的とした特殊なオプションです。このオプションは、コネクターがリーダーレプリカではなく、最も近いレプリカから消費する場合に使用できます。場合によっては、最も近いレプリカから消費することで、ネットワークの使用率を改善したり、コストを削減したりできます。topologyKey は、ラック ID を含むノードラベルと一致する必要があります。この設定で使用される例では、標準の topology.kubernetes.io/zone ラベルを使用するゾーンを指定します。最も近いレプリカから消費するには、Kafka ブローカー設定で RackAwareReplicaSelector を有効にします。
    44
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    45
    分散トレース用に環境変数が設定されます。
    46
    Jaeger では分散トレースが有効になっています。
    47
    環境変数として Kafka MirrorMaker にマウントされた OpenShift Secret の 外部設定設定プロバイダープラグイン を使用して、外部ソースから設定値を読み込む こともできます。
  2. リソースを作成または更新します。

    oc apply -f MIRRORMAKER-CONFIGURATION-FILE

2.4.7. Kafka MirrorMaker 2 デプロイメントの保護

この手順では、MirrorMaker 2 デプロイメントを保護するために必要な設定の概要を説明します。

ソース Kafka クラスターとターゲット Kafka クラスターには別々の設定が必要です。また、MirrorMaker がソースおよびターゲットの Kafka クラスターに接続するために必要な認証情報を提供するために、個別のユーザー設定が必要です。

Kafka クラスターの場合、OpenShift クラスター内のセキュア接続用の内部リスナーと、OpenShift クラスター外の接続用の外部リスナーを指定します。

認証および許可メカニズムを設定できます。ソースおよびターゲットの Kafka クラスターに実装されたセキュリティーオプションは、MirrorMaker 2 に実装されたセキュリティーオプションと互換性がある必要があります。

クラスターとユーザー認証情報を作成したら、セキュアな接続のために MirrorMaker 設定でそれらを指定します。

注記

この手順では、Cluster Operator によって生成された証明書が使用されますが、独自の証明書をインストール して証明書を置き換えることもできます。外部 CA (認証局) によって管理される Kafka リスナー証明書を使用 するようにリスナーを設定することもできます。

作業を開始する前の注意事項

この手順を開始する前に、AMQ Streams が提供する 設定ファイルの例 を確認してください。これらには、mTLS または SCRAM-SHA-512 認証を使用して MirrorMaker 2 のデプロイメントを保護するための例が含まれています。例では、OpenShift クラスター内で接続するための内部リスナーを指定しています。

この例では、ソースおよびターゲットの Kafka クラスターでの操作を許可するために MirrorMaker 2 で必要なすべての ACL を含む、完全な承認の設定を提供します。

前提条件

  • AMQ Streams が実行されている
  • ソースクラスターとターゲットクラスターの namespace が分離されている

この手順では、ソースとターゲットの Kafka クラスターが別々の namespace にインストールされていることを前提としています。Topic Operator を使用する場合は、これを行う必要があります。Topoic Operator は、指定された namespace 内の単一クラスターのみをモニタリングします。

クラスターを namespace に分割することにより、クラスターシークレットをコピーして、namespace の外部からアクセスできるようにする必要があります。MirrorMaker 設定でシークレットを参照する必要があります。

手順

  1. 2 つの Kafka リソースを設定します。1 つはソース Kafka クラスターを保護するためのもので、もう 1 つはターゲット Kafka クラスターを保護するためのものです。

    認証用のリスナー設定を追加し、認可を有効にすることができます。

    この例の場合、内部リスナーは mTLS 暗号化と認証を使用して Kafka クラスター用に設定されています。Kafka の simple 認証が有効になっています。

    TLS 暗号化と mTLS 認証を使用したソース Kafka クラスター設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-source-cluster
    spec:
      kafka:
        version: 3.4.0
        replicas: 1
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
        authorization:
          type: simple
        config:
          offsets.topic.replication.factor: 1
          transaction.state.log.replication.factor: 1
          transaction.state.log.min.isr: 1
          default.replication.factor: 1
          min.insync.replicas: 1
          inter.broker.protocol.version: "3.4"
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
      zookeeper:
        replicas: 1
        storage:
          type: persistent-claim
          size: 100Gi
          deleteClaim: false
      entityOperator:
        topicOperator: {}
        userOperator: {}

    TLS 暗号化と mTLS 認証を使用したターゲット Kafka クラスター設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-target-cluster
    spec:
      kafka:
        version: 3.4.0
        replicas: 1
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
        authorization:
          type: simple
        config:
          offsets.topic.replication.factor: 1
          transaction.state.log.replication.factor: 1
          transaction.state.log.min.isr: 1
          default.replication.factor: 1
          min.insync.replicas: 1
          inter.broker.protocol.version: "3.4"
        storage:
          type: jbod
          volumes:
            - id: 0
              type: persistent-claim
              size: 100Gi
              deleteClaim: false
      zookeeper:
        replicas: 1
        storage:
          type: persistent-claim
          size: 100Gi
          deleteClaim: false
      entityOperator:
        topicOperator: {}
        userOperator: {}

  2. 別の namespace で Kafka リソースを作成または更新します。

    oc apply -f <kafka_configuration_file> -n <namespace>

    Cluster Operator はリスナーを作成し、クラスターおよびクライアント認証局 (CA) 証明書を設定して Kafka クラスター内で認証を有効にします。

    証明書は、シークレット <cluster_name>-cluster-ca-cert に作成されます。

  3. 2 つの KafkaUser リソースを設定します。1 つはソース Kafka クラスターのユーザー用で、もう 1 つはターゲット Kafka クラスターのユーザー用です。

    1. 対応するソースおよびターゲットの Kafka クラスターと同じ認証および認可タイプを設定します。たとえば、ソース Kafka クラスターの Kafka 設定で tls 認証と simple 認可タイプを使用した場合は、KafkaUser 設定でも同じものを使用します。
    2. MirrorMaker 2 に必要な ACL を設定して、ソースおよびターゲットの Kafka クラスターでの操作を許可します。

      ACL は、内部 MirrorMaker コネクター、および基盤となる Kafka Connect フレームワークによって使用されます。

    mTLS 認証のソースユーザー設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-source-user
      labels:
        strimzi.io/cluster: my-source-cluster
    spec:
      authentication:
        type: tls
      authorization:
        type: simple
        acls:
          # MirrorSourceConnector
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operations:
              - Create
              - DescribeConfigs
              - Read
              - Write
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operations:
              - DescribeConfigs
              - Read
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operations:
              - Describe
          - resource: # Needed for every group for which offsets are synced
              type: group
              name: "*"
            operations:
              - Describe
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operations:
              - Read

    mTLS 認証のターゲットユーザー設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-target-user
      labels:
        strimzi.io/cluster: my-target-cluster
    spec:
      authentication:
        type: tls
      authorization:
        type: simple
        acls:
          # Underlying Kafka Connect internal topics to store configuration, offsets, or status
          - resource:
              type: group
              name: mirrormaker2-cluster
            operations:
              - Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operations:
              - Create
              - Describe
              - DescribeConfigs
              - Read
              - Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operations:
              - Create
              - Describe
              - DescribeConfigs
              - Read
              - Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operations:
              - Create
              - Describe
              - DescribeConfigs
              - Read
              - Write
          # MirrorSourceConnector
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operations:
              - Create
              - Alter
              - AlterConfigs
              - Write
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operations:
              - Describe
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operations:
              - Create
              - Describe
              - Read
              - Write
          - resource: # Needed for every group for which the offset is synced
              type: group
              name: "*"
            operations:
              - Read
              - Describe
          # MirrorHeartbeatConnector
          - resource:
              type: topic
              name: heartbeats
            operations:
              - Create
              - Describe
              - Write

    注記

    typetls-external に設定することにより、User Operator の外部で発行された証明書を使用できます。詳細は、KafkaUserSpec スキーマ参照」 を参照してください。

  4. ソースおよびターゲットの Kafka クラスター用に作成した各 namespace で、KafkaUser リソースを作成または更新します。

    oc apply -f <kafka_user_configuration_file> -n <namespace>

    User Operator はクライアント (MirrorMaker) に対応するユーザーを作成すると共に、選択した認証タイプに基づいて、クライアント認証に使用されるセキュリティークレデンシャルを作成します。

    User Operator は、KafkaUser リソースと同じ名前の新しいシークレットを作成します。シークレットには、mTLS 認証用の秘密鍵と公開鍵が含まれています。公開鍵は、クライアント CA によって署名されたユーザー証明書に含まれます。

  5. ソースおよびターゲットの Kafka クラスターに接続するための認証の詳細を使用して KafkaMirrorMaker2 リソースを設定します。

    TLS 暗号化と mTLS 認証を使用した MirrorMaker 2 設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker-2
    spec:
      version: 3.4.0
      replicas: 1
      connectCluster: "my-target-cluster"
      clusters:
        - alias: "my-source-cluster"
          bootstrapServers: my-source-cluster-kafka-bootstrap:9093
          tls: 1
            trustedCertificates:
              - secretName: my-source-cluster-cluster-ca-cert
                certificate: ca.crt
          authentication: 2
            type: tls
            certificateAndKey:
              secretName: my-source-user
              certificate: user.crt
              key: user.key
        - alias: "my-target-cluster"
          bootstrapServers: my-target-cluster-kafka-bootstrap:9093
          tls: 3
            trustedCertificates:
              - secretName: my-target-cluster-cluster-ca-cert
                certificate: ca.crt
          authentication: 4
            type: tls
            certificateAndKey:
              secretName: my-target-user
              certificate: user.crt
              key: user.key
          config:
            # -1 means it will use the default replication factor configured in the broker
            config.storage.replication.factor: -1
            offset.storage.replication.factor: -1
            status.storage.replication.factor: -1
      mirrors:
        - sourceCluster: "my-source-cluster"
          targetCluster: "my-target-cluster"
          sourceConnector:
            config:
              replication.factor: 1
              offset-syncs.topic.replication.factor: 1
              sync.topic.acls.enabled: "false"
          heartbeatConnector:
            config:
              heartbeats.topic.replication.factor: 1
          checkpointConnector:
            config:
              checkpoints.topic.replication.factor: 1
              sync.group.offsets.enabled: "true"
          topicsPattern: "topic1|topic2|topic3"
          groupsPattern: "group1|group2|group3"

    1
    ソース Kafka クラスターの TLS 証明書。それらが別の namespace にある場合は、Kafka クラスターの namespace からクラスターシークレットをコピーします。
    2
    TLS mechanism を使用してソース Kafka クラスターにアクセスするためのユーザー認証。
    3
    ターゲット Kafka クラスターの TLS 証明書。
    4
    ターゲット Kafka クラスターにアクセスするためのユーザー認証。
  6. ターゲット Kafka クラスターと同じ namespace で KafkaMirrorMaker2 リソースを作成または更新します。

    oc apply -f <mirrormaker2_configuration_file> -n <namespace_of_target_cluster>

関連情報

  • type-KafkaMirrorMaker2ClusterSpec-reference[]

2.4.8. Kafka MirrorMaker 2 コネクターの再起動の実行

この手順では、OpenShift アノテーションを使用して Kafka MirrorMaker 2 コネクターの再起動を手動でトリガーする方法について説明します。

前提条件

  • Cluster Operator が稼働中である。

手順

  1. 再起動する Kafka MirrorMaker 2 コネクターを制御する KafkaMirrorMaker2 カスタムリソースの名前を見つけます。

    oc get KafkaMirrorMaker2
  2. KafkaMirrorMaker2 カスタムリソースから再起動する Kafka MirrorMaker 2 コネクターの名前を見つけます。

    oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
  3. コネクターを再起動するには、OpenShift で KafkaMirrorMaker2 リソースにアノテーションを付けます。この例では、oc annotatemy-source->my-target.MirrorSourceConnector という名前のコネクターを再起動します。

    oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector=my-source->my-target.MirrorSourceConnector"
  4. 次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。

    アノテーションが調整プロセスによって検出されているかぎり、Kafka MirrorMaker 2 コネクターは再起動されます。再起動要求が許可されると、アノテーションは KafkaMirrorMaker2 カスタムリソースから削除されます。

2.4.9. Kafka MirrorMaker 2 コネクタータスクの再起動の実行

この手順では、OpenShift アノテーションを使用して Kafka MirrorMaker 2 コネクタータスクの再起動を手動でトリガーする方法について説明します。

前提条件

  • Cluster Operator が稼働中である。

手順

  1. 再起動する Kafka MirrorMaker 2 コネクターを制御する KafkaMirrorMaker2 カスタムリソースの名前を見つけます。

    oc get KafkaMirrorMaker2
  2. KafkaMirrorMaker2 カスタムリソースから、Kafka MirrorMaker 2 コネクターの名前と再起動するタスクの ID を見つけます。タスク ID は 0 から始まる負の値ではない整数です。

    oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
  3. コネクタータスクを再起動するには、OpenShift で KafkaMirrorMaker2 リソースにアノテーションを付けます。この例では、oc annotatemy-source->my-target.MirrorSourceConnector という名前のコネクターのタスク 0 を再起動します。

    oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector-task=my-source->my-target.MirrorSourceConnector:0"
  4. 次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。

    アノテーションが調整プロセスによって検出されているかぎり、Kafka MirrorMaker 2 コネクタータスクが再起動されます。再起動タスクの要求が受け入れられると、KafkaMirrorMaker2 のカスタムリソースからアノテーションが削除されます。

2.5. Kafka MirrorMaker クラスターの設定

KafkaMirrorMaker リソースを使用して Kafka MirrorMaker デプロイメントを設定します。KafkaMirrorMaker は、Kafka クラスター間でデータを複製します。

KafkaMirrorMaker スキーマ参照」 KafkaMirrorMaker リソースの完全なスキーマについて説明します。

AMQ Streams は MirrorMaker または MirrorMaker 2 で使用できます。MirrorMaker 2 は最新バージョンで、Kafka クラスター間でデータをミラーリングするためのより効率的な方法を提供します。

重要

Kafka MirrorMaker 1 (ドキュメントでは単に MirrorMaker と呼ばれる) は Apache Kafka 3.0.0 で非推奨となり、Apache Kafka 4.0.0 で削除されます。そのため、Kafka MirrorMaker 1 のデプロイに使用される KafkaMirrorMaker カスタムリソースも、AMQ Streams で非推奨となりました。Apache Kafka 4.0.0 を導入すると、KafkaMirrorMaker リソースは AMQ Streams から削除されます。代わりに、IdentityReplicationPolicyKafkaMirrorMaker2 カスタムリソースを使用します。

2.5.1. Kafka MirrorMaker の設定

KafkaMirrorMaker リソースのプロパティーを使用して、Kafka MirrorMaker デプロイメントを設定します。

TLS または SASL 認証を使用して、プロデューサーおよびコンシューマーのアクセス制御を設定できます。この手順では、コンシューマーおよびプロデューサー側で mTLS による暗号化および認証を使用する設定を説明します。

前提条件

  • 以下を実行する方法については、OpenShift での AMQ Streams のデプロイおよびアップグレード を参照すること。

  • ソースおよびターゲットの Kafka クラスターが使用できる必要があります。

手順

  1. KafkaMirrorMaker リソースの spec プロパティーを編集します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker
    metadata:
      name: my-mirror-maker
    spec:
      replicas: 3 1
      consumer:
        bootstrapServers: my-source-cluster-kafka-bootstrap:9092 2
        groupId: "my-group" 3
        numStreams: 2 4
        offsetCommitInterval: 120000 5
        tls: 6
          trustedCertificates:
          - secretName: my-source-cluster-ca-cert
            certificate: ca.crt
        authentication: 7
          type: tls
          certificateAndKey:
            secretName: my-source-secret
            certificate: public.crt
            key: private.key
        config: 8
          max.poll.records: 100
          receive.buffer.bytes: 32768
          ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 9
          ssl.enabled.protocols: TLSv1.2
          ssl.protocol: TLSv1.2
          ssl.endpoint.identification.algorithm: HTTPS 10
      producer:
        bootstrapServers: my-target-cluster-kafka-bootstrap:9092
        abortOnSendFailure: false 11
        tls:
          trustedCertificates:
          - secretName: my-target-cluster-ca-cert
            certificate: ca.crt
        authentication:
          type: tls
          certificateAndKey:
            secretName: my-target-secret
            certificate: public.crt
            key: private.key
        config:
          compression.type: gzip
          batch.size: 8192
          ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 12
          ssl.enabled.protocols: TLSv1.2
          ssl.protocol: TLSv1.2
          ssl.endpoint.identification.algorithm: HTTPS 13
      include: "my-topic|other-topic" 14
      resources: 15
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 16
        type: inline
        loggers:
          mirrormaker.root.logger: "INFO"
      readinessProbe: 17
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      metricsConfig: 18
       type: jmxPrometheusExporter
       valueFrom:
         configMapKeyRef:
           name: my-config-map
           key: my-key
      jvmOptions: 19
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 20
      template: 21
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 22
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing: 23
        type: jaeger
    1
    2
    コンシューマーおよびプロデューサーの ブートストラップサーバー
    3
    4
    5
    6
    コンシューマーまたはプロデューサーの TLS 証明書が X.509 形式で保存される、キー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
    7
    mTLSトークンベースの OAuth、SASL ベース SCRAM-SHA-256/SCRAM-SHA-512、または PLAIN として指定されたコンシューマーまたはプロデューサーの認証。
    8
    コンシューマー および プロデューサー の Kafka 設定オプション。
    9
    TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー
    10
    HTTPS に設定することで、ホスト名の検証が有効 になります。空の文字列を指定すると検証が無効になります。
    11
    abortOnSendFailure プロパティーtrue に設定されている場合、メッセージの送信に失敗した後、Kafka MirrorMaker は終了し、コンテナーは再起動します。
    12
    TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー
    13
    HTTPS に設定することで、ホスト名の検証が有効 になります。空の文字列を指定すると検証が無効になります。
    14
    ソースからターゲット Kafka クラスターにミラーリングされた 含まれるトピック
    15
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    16
    指定された ロガーおよびログレベル が ConfigMap を介して直接的に (inline) または間接的に (external) に追加されます。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。MirrorMaker には mirrormaker.root.logger と呼ばれる単一のロガーがあります。ログレベルは INFO、ERROR、WARN、TRACE、DEBUG、FATAL、または OFF に設定できます。
    17
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    18
    Prometheus メトリクス。この例では、Prometheus JMX エクスポーターの設定が含まれる ConfigMap を参照して有効になります。metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap の参照を使用して、追加設定なしでメトリクスを有効にできます。
    19
    Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    20
    高度な任意設定: 特別な場合のみ推奨される コンテナーイメージの設定
    21
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    22
    分散トレース用に環境変数が設定されます。
    23
    Jaeger では分散トレースが有効になっています。
    警告

    abortOnSendFailure プロパティーが false に設定されると、プロデューサーはトピックの次のメッセージを送信しようとします。失敗したメッセージは再送されないため、元のメッセージが失われる可能性があります。

  2. リソースを作成または更新します。

    oc apply -f <your-file>

2.5.2. Kafka MirrorMaker クラスターリソースの一覧

以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。

<mirror-maker-name>-mirror-maker
Kafka MirrorMaker Pod の作成を担当するデプロイメント。
<mirror-maker-name>-config
Kafka MirrorMaker の補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
<mirror-maker-name>-mirror-maker
Kafka MirrorMaker ワーカーノードに設定された Pod の Disruption Budget。

2.6. Kafka Bridge クラスターの設定

KafkaBridge リソースを使用して Kafka Bridge デプロイメントを設定します。Kafka Bridge には、HTTP ベースのクライアントと Kafka クラスターを統合する API が含まれています。

KafkaBridge スキーマ参照」 KafkaBridge リソースの完全なスキーマについて説明します。

2.6.1. Kafka Bridge の設定

Kafka Bridge を使用した Kafka クラスターへの HTTP ベースのリクエスト

KafkaBridge リソースのプロパティーを使用して、Kafka Bridge デプロイメントを設定します。

クライアントのコンシューマーリクエストが異なる Kafka Bridge インスタンスによって処理された場合に発生する問題を防ぐには、アドレスベースのルーティングを利用して、要求が適切な Kafka Bridge インスタンスにルーティングされるようにする必要があります。また、独立した各 Kafka Bridge インスタンスにレプリカが必要です。Kafka Bridge インスタンスには、別のインスタンスと共有されない独自の状態があります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

以下を実行する方法については、OpenShift での AMQ Streams のデプロイおよびアップグレード を参照すること。

手順

  1. KafkaBridge リソースの spec プロパティーを編集します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaBridge
    metadata:
      name: my-bridge
    spec:
      replicas: 3 1
      bootstrapServers: <cluster_name>-cluster-kafka-bootstrap:9092 2
      tls: 3
        trustedCertificates:
          - secretName: my-cluster-cluster-cert
            certificate: ca.crt
          - secretName: my-cluster-cluster-cert
            certificate: ca2.crt
      authentication: 4
        type: tls
        certificateAndKey:
          secretName: my-secret
          certificate: public.crt
          key: private.key
      http: 5
        port: 8080
        cors: 6
          allowedOrigins: "https://strimzi.io"
          allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
      consumer: 7
        config:
          auto.offset.reset: earliest
      producer: 8
        config:
          delivery.timeout.ms: 300000
      resources: 9
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 10
        type: inline
        loggers:
          logger.bridge.level: "INFO"
          # enabling DEBUG just for send operation
          logger.send.name: "http.openapi.operation.send"
          logger.send.level: "DEBUG"
      jvmOptions: 11
        "-Xmx": "1g"
        "-Xms": "1g"
      readinessProbe: 12
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      image: my-org/my-image:latest 13
      template: 14
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        bridgeContainer: 15
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
    1
    2
    ターゲット Kafka クラスターに接続するための ブートストラップサーバー。Kafka クラスターの名前は <cluster_name> を使用します。
    3
    ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
    4
    mTLSトークンベースの OAuth、SASL ベース SCRAM-SHA-256/SCRAM-SHA-512、または PLAIN として指定された Kafka Bridge クラスターの認証。デフォルトでは、Kafka Bridge は認証なしで Kafka ブローカーに接続します。
    5
    Kafka ブローカーへの HTTP アクセス
    6
    選択されたリソースおよびアクセスメソッドを指定する CORS アクセス。要求に別の HTTP ヘッダーを追加して、Kafka クラスターへのアクセスが許可されるオリジンが記述されます。
    7
    コンシューマー設定 オプション。
    8
    プロデューサー設定 オプション。
    9
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    10
    指定された Kafka Bridge loggers and log levels が ConfigMap を介して直接的に (inline) または間接的に (external) に追加されます。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。Kafka Bridge ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
    11
    Kafka Bridge を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    12
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    13
    オプション: コンテナーイメージの設定。これは、特別な状況でのみ推奨されます。
    14
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    15
    分散トレース用に環境変数が設定されます。
  2. リソースを作成または更新します。

    oc apply -f KAFKA-BRIDGE-CONFIG-FILE

2.6.2. Kafka Bridge クラスターリソースのリスト

以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。

bridge-cluster-name-bridge
Kafka Bridge ワーカーノード Pod の作成を担当するデプロイメント。
bridge-cluster-name-bridge-service
Kafka Bridge クラスターの REST インターフェイスを公開するサービス。
bridge-cluster-name-bridge-config
Kafka Bridge の補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
bridge-cluster-name-bridge
Kafka Bridge ワーカーノードに設定された Pod の Disruption Budget。

2.7. OpenShift リソースのカスタマイズ

AMQ Streams デプロイメントでは、DeploymentsStatefulSetsPodsServices などの OpenShift リソースを作成します。これらのリソースは AMQ Streams Operator が管理します。特定の OpenShift リソースの管理を担当する operator のみがそのリソースを変更できます。operator によって管理される OpenShift リソースを手動で変更しようとすると、operator はその変更を元に戻します。

operator が管理する OpenShift リソースの変更は、以下のような特定のタスクを実行する場合に役立ちます。

  • Pod が Istio またはその他のサービスによって処理される方法を制御するカスタムラベルまたはアノテーションの追加
  • Loadbalancer-type サービスがクラスターによって作成される方法の管理

このような変更は、AMQ Streams カスタムリソースの template プロパティーを使用して追加します。template プロパティーは以下のリソースでサポートされます。API リファレンスは、カスタマイズ可能フィールドに関する詳細を提供します。

Kafka.spec.kafka
KafkaClusterTemplate スキーマ参照」 を参照
Kafka.spec.zookeeper
ZookeeperClusterTemplate スキーマ参照」 を参照
Kafka.spec.entityOperator
EntityOperatorTemplate スキーマ参照」 を参照
Kafka.spec.kafkaExporter
KafkaExporterTemplate スキーマ参照」 を参照
Kafka.spec.cruiseControl
CruiseControlTemplate スキーマ参照」 を参照
KafkaConnect.spec
KafkaConnectTemplate スキーマ参照」 を参照
KafkaMirrorMaker.spec
KafkaMirrorMakerTemplate スキーマ参照」 を参照
KafkaMirrorMaker2.spec
KafkaConnectTemplate スキーマ参照」 を参照
KafkaBridge.spec
KafkaBridgeTemplate スキーマ参照」 を参照
KafkaUser.spec
KafkaUserTemplate スキーマ参照」 を参照

以下の例では、template プロパティーを使用して Kafka ブローカーの Pod のラベルを変更します。

テンプレートのカスタマイズ例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  labels:
    app: my-cluster
spec:
  kafka:
    # ...
    template:
      pod:
        metadata:
          labels:
            mylabel: myvalue
    # ...

2.7.1. イメージプルポリシーのカスタマイズ

AMQ Streams では、Cluster Operator によってデプロイされたすべての Pod のコンテナーのイメージプルポリシーをカスタマイズできます。イメージプルポリシーは、Cluster Operator デプロイメントの環境変数 STRIMZI_IMAGE_PULL_POLICY を使用して設定されます。STRIMZI_IMAGE_PULL_POLICY 環境変数に設定できる値は 3 つあります。

Always
Pod が起動または再起動されるたびにコンテナーイメージがレジストリーからプルされます。
IfNotPresent
以前プルされたことのないコンテナーイメージのみがレジストリーからプルされます。
Never
コンテナーイメージはレジストリーからプルされることはありません。

現在、イメージプルポリシーは、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターに対して一度にのみカスタマイズできます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリング更新が実行されます。

2.7.2. 終了時の猶予期間の適用

終了時の猶予期間を適用し、Kafka クラスターが正常にシャットダウンされるように十分な時間を確保します。

terminationGracePeriodSeconds プロパティーを使用して時間を指定します。プロパティーを Kafka カスタムリソースの template.pod 設定に追加します。

追加する時間は Kafka クラスターのサイズによって異なります。終了猶予期間の OpenShift のデフォルト値は 30 秒です。クラスターが正常にシャットダウンしていないことが判明した場合には、終了までの猶予期間を増やすことができます。

終了時の猶予期間は、Pod が再起動されるたびに適用されます。この期間は、OpenShift が Pod で実行されているプロセスに term (中断) シグナルを送信すると開始します。この期間は、終了する Pod のプロセスを、停止する前に別の Pod に転送するのに必要な時間を反映する必要があります。期間の終了後、kill シグナルにより、Pod で実行中のプロセスはすべて停止します。

以下の例では、終了猶予期間 120 秒を Kafka カスタムリソースに追加します。他の Kafka コンポーネントのカスタムリソースで設定を指定することもできます。

終了猶予期間の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    template:
      pod:
        terminationGracePeriodSeconds: 120
        # ...
    # ...

2.8. Pod スケジューリングの設定

2 つのアプリケーションが同じ OpenShift ノードにスケジュールされた場合、両方のアプリケーションがディスク I/O のように同じリソースを使用し、パフォーマンスに影響する可能性があります。これにより、パフォーマンスが低下する可能性があります。ノードを他の重要なワークロードと共有しないように Kafka Pod をスケジュールする場合、適切なノードを使用したり、Kafka 専用のノードのセットを使用すると、このような問題を適切に回避できます。

2.8.1. アフィニティー、容認 (Toleration)、およびトポロジー分散制約の指定

アフィニティー、容認 (Toleration)、およびトポロジー分散制約を使用して、kafka リソースの Pod をノードにスケジュールします。アフィニティー、容認 (Toleration)、およびトポロジー分散制約は、以下のリソースの affinitytolerations、および topologySpreadConstraint プロパティーを使用して設定されます。

  • Kafka.spec.kafka.template.pod
  • Kafka.spec.zookeeper.template.pod
  • Kafka.spec.entityOperator.template.pod
  • KafkaConnect.spec.template.pod
  • KafkaBridge.spec.template.pod
  • KafkaMirrorMaker.spec.template.pod
  • KafkaMirrorMaker2.spec.template.pod

affinitytolerations、および topologySpreadConstraint プロパティーの形式は、OpenShift の仕様に準拠します。アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

  • Pod のアフィニティーおよび非アフィニティー
  • ノードのアフィニティー
2.8.1.1. Pod の非アフィニティーを使用して重要なアプリケーションがノードを共有しないようにする

Pod の非アフィニティーを使用して、重要なアプリケーションが同じディスクにスケジュールされないようにします。Kafka クラスターの実行時に、Pod の非アフィニティーを使用して、Kafka ブローカーがデータベースなどの他のワークロードとノードを共有しないようにすることが推奨されます。

2.8.1.2. ノードのアフィニティーを使用したワークロードの特定ノードへのスケジュール

OpenShift クラスターは、通常多くの異なるタイプのワーカーノードで設定されます。ワークロードが非常に大きい環境の CPU に対して最適化されたものもあれば、メモリー、ストレージ (高速のローカル SSD)、または ネットワークに対して最適化されたものもあります。異なるノードを使用すると、コストとパフォーマンスの両面で最適化しやすくなります。最適なパフォーマンスを実現するには、AMQ Streams コンポーネントのスケジューリングで適切なノードを使用できるようにすることが重要です。

OpenShift はノードのアフィニティーを使用してワークロードを特定のノードにスケジュールします。ノードのアフィニティーにより、Pod がスケジュールされるノードにスケジューリングの制約を作成できます。制約はラベルセレクターとして指定されます。beta.kubernetes.io/instance-type などの組み込みノードラベルまたはカスタムラベルのいずれかを使用してラベルを指定すると、適切なノードを選択できます。

2.8.1.3. 専用ノードへのノードのアフィニティーと容認 (Toleration) の使用

テイントを使用して専用ノードを作成し、ノードのアフィニティーおよび容認 (Toleration) を設定して専用ノードに Kafka Pod をスケジュールします。

クラスター管理者は、選択した OpenShift ノードをテイントとしてマーク付けできます。テイントのあるノードは、通常のスケジューリングから除外され、通常の Pod はそれらのノードでの実行はスケジュールされません。ノードに設定されたテイントを許容できるサービスのみをスケジュールできます。このようなノードで実行されるその他のサービスは、ログコレクターやソフトウェア定義のネットワークなどのシステムサービスのみです。

専用のノードで Kafka とそのコンポーネントを実行する利点は多くあります。障害の原因になったり、Kafka に必要なリソースを消費するその他のアプリケーションが同じノードで実行されません。これにより、パフォーマンスと安定性が向上します。

2.8.2. それぞれの Kafka ブローカーを別のワーカーノードでスケジュールするための Pod の非アフィニティーの設定

多くの Kafka ブローカーまたは ZooKeeper ノードは、同じ OpenShift ワーカーノードで実行できます。ワーカーノードが失敗すると、それらはすべて同時に利用できなくなります。信頼性を向上させるために、podAntiAffinity 設定を使用して、各 Kafka ブローカーまたは ZooKeeper ノードを異なる OpenShift ワーカーノードにスケジュールすることができます。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

手順

  1. クラスターデプロイメントを指定するリソースの affinity プロパティーを編集します。ワーカーノードが Kafka ブローカーまたは ZooKeeper ノードで共有されないようにするには、strimzi.io/name ラベルを使用します。topologyKeykubernetes.io/hostname に設定して、選択した Pod が同じホスト名のノードでスケジュールされないように指定します。これにより、同じワーカーノードを単一の Kafka ブローカーと単一の ZooKeeper ノードで共有できます。以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/name
                          operator: In
                          values:
                            - CLUSTER-NAME-kafka
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/name
                          operator: In
                          values:
                            - CLUSTER-NAME-zookeeper
                    topologyKey: "kubernetes.io/hostname"
        # ...

    CLUSTER-NAME は、Kafka カスタムリソースの名前です。

  2. Kafka ブローカーと ZooKeeper ノードが同じワーカーノードを共有しないようにする場合は、strimzi.io/cluster ラベルを使用します。以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/cluster
                          operator: In
                          values:
                            - CLUSTER-NAME
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/cluster
                          operator: In
                          values:
                            - CLUSTER-NAME
                    topologyKey: "kubernetes.io/hostname"
        # ...

    CLUSTER-NAME は、Kafka カスタムリソースの名前です。

  3. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

2.8.3. Kafka コンポーネントでの Pod の非アフィニティーの設定

Pod の非アフィニティー設定は、Kafka ブローカーの安定性とパフォーマンスに役立ちます。podAntiAffinity を使用すると、OpenShift は他のワークロードと同じノードで Kafka ブローカーをスケジュールしません。通常、Kafka が他のネットワークと同じワーカーノードで実行されないようにし、データベース、ストレージ、その他のメッセージングプラットフォームなどのストレージを大量に消費するアプリケーションで実行されないようにします。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

手順

  1. クラスターデプロイメントを指定するリソースの affinity プロパティーを編集します。ラベルを使用して、同じノードでスケジュールすべきでない Pod を指定します。topologyKeykubernetes.io/hostname に設定し、選択した Pod が同じホスト名のノードでスケジュールされてはならないことを指定する必要があります。以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: application
                          operator: In
                          values:
                            - postgresql
                            - mongodb
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
  2. リソースを作成または更新します。

    oc apply を使用して、これを行うことができます。

    oc apply -f <kafka_configuration_file>

2.8.4. Kafka コンポーネントでのノードのアフィニティーの設定

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

手順

  1. AMQ Streams コンポーネントをスケジュールする必要のあるノードにラベルを付けます。

    oc label を使用してこれを行うことができます。

    oc label node NAME-OF-NODE node-type=fast-network

    または、既存のラベルによっては再利用が可能です。

  2. クラスターデプロイメントを指定するリソースの affinity プロパティーを編集します。以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                    - matchExpressions:
                      - key: node-type
                        operator: In
                        values:
                        - fast-network
        # ...
      zookeeper:
        # ...
  3. リソースを作成または更新します。

    oc apply を使用して、これを行うことができます。

    oc apply -f <kafka_configuration_file>

2.8.5. 専用ノードの設定と Pod のスケジューリング

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator

手順

  1. 専用ノードとして使用するノードを選択します。
  2. これらのノードにスケジュールされているワークロードがないことを確認します。
  3. 選択したノードにテイントを設定します。

    oc adm taint を使用してこれを行うことができます。

    oc adm taint node NAME-OF-NODE dedicated=Kafka:NoSchedule
  4. さらに、選択したノードにラベルも追加します。

    oc label を使用してこれを行うことができます。

    oc label node NAME-OF-NODE dedicated=Kafka
  5. クラスターデプロイメントを指定するリソースの affinity および tolerations プロパティーを編集します。

    以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            tolerations:
              - key: "dedicated"
                operator: "Equal"
                value: "Kafka"
                effect: "NoSchedule"
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                  - matchExpressions:
                    - key: dedicated
                      operator: In
                      values:
                      - Kafka
        # ...
      zookeeper:
        # ...
  6. リソースを作成または更新します。

    oc apply を使用して、これを行うことができます。

    oc apply -f <kafka_configuration_file>

2.9. ロギングの設定

Kafka コンポーネントおよび AMQ Streams Operator のカスタムリソースでロギングレベルを設定します。ログレベルは、カスタムリソースの spec.logging プロパティーに直接指定できます。あるいは、configMapKeyRef プロパティーを使用してカスタムリソースで参照される ConfigMap でロギングプロパティーを定義することもできます。

ConfigMap を使用する利点は、ロギングプロパティーが 1 カ所で維持され、複数のリソースにアクセスできることです。複数のリソースに ConfigMap を再利用することもできます。ConfigMap を使用して AMQ Streams Operator のロガーを指定する場合は、ロギング仕様を追加してフィルターを追加することもできます。

ロギング仕様でロギング type を指定します。

  • ロギングレベルを直接指定する場合は inline
  • ConfigMap を参照する場合は external

inline ロギングの設定例

spec:
  # ...
  logging:
    type: inline
    loggers:
      kafka.root.logger.level: "INFO"

external 設定の例

spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: my-config-map
        key: my-config-map-key

ConfigMap の namekey の値は必須です。namekey が設定されていない場合は、デフォルトのロギングが使用されます。

2.9.1. Kafka コンポーネントおよび Operator のロギングオプション

特定の Kafka コンポーネントまたは Operator のログ設定の詳細は、次のセクションを参照してください。

2.9.2. ロギングの ConfigMap の作成

ConfigMap を使用してロギングプロパティーを定義するには、ConfigMap を作成してから、リソースの spec にあるロギング定義の一部としてそれを参照します。

ConfigMap には適切なロギング設定が含まれる必要があります。

  • Kafka コンポーネント、ZooKeeper、および Kafka Bridge の log4j.properties
  • Topic Operator および User Operator の log4j2.properties

設定はこれらのプロパティーの配下に配置する必要があります。

この手順では、ConfigMap は Kafka リソースのルートロガーを定義します。

手順

  1. ConfigMap を作成します。

    ConfigMap を YAML ファイルとして作成するか、プロパティーファイルから Config Map を作成します。

    Kafka のルートロガー定義が含まれる ConfigMap の例:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: logging-configmap
    data:
      log4j.properties:
        kafka.root.logger.level="INFO"

    プロパティーファイルを使用している場合は、コマンドラインでファイルを指定します。

    oc create configmap logging-configmap --from-file=log4j.properties

    プロパティーファイルではロギング設定が定義されます。

    # Define the logger
    kafka.root.logger.level="INFO"
    # ...
  2. リソースの specexternal ロギングを定義し、logging.valueFrom.configMapKeyRef.name に ConfigMap の名前を、logging.valueFrom.configMapKeyRef.key にこの ConfigMap のキーを設定します。

    spec:
      # ...
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: logging-configmap
            key: log4j.properties
  3. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

2.9.3. ロギングフィルターの Operator への追加

ConfigMap を使用して AMQ Streams Operator のロギングレベル (log4j2) ロギングレベルを設定する場合、ロギングフィルターを定義して、ログに返される内容も制限できます。

ロギングフィルターは、ロギングメッセージが多数ある場合に役に立ちます。ロガーのログレベルを DEBUG(rootLogger.level="DEBUG") に設定すると仮定します。ロギングフィルターは、このレベルでロガーに対して返されるログ数を減らし、特定のリソースに集中できるようにします。フィルターが設定されると、フィルターに一致するログメッセージのみがログに記録されます。

フィルターはマーカーを使用して、ログに含まれる内容を指定します。マーカーの種類、namespace、および名前を指定します。たとえば、Kafka クラスターで障害が発生した場合、種類を Kafka に指定してログを分離し、障害が発生しているクラスターの namespace および名前を使用します。

以下の例は、my-kafka-cluster という名前の Kafka クラスターのマーカーフィルターを示しています。

基本的なロギングフィルターの設定

rootLogger.level="INFO"
appender.console.filter.filter1.type=MarkerFilter 1
appender.console.filter.filter1.onMatch=ACCEPT 2
appender.console.filter.filter1.onMismatch=DENY 3
appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster) 4

1
MarkerFilter 型は、フィルターを行うために指定されたマーカーを比較します。
2
onMatch プロパティーは、マーカーが一致するとログを受け入れます。
3
onMismatch プロパティーは、マーカーが一致しない場合にログを拒否します。
4
フィルター処理に使用されるマーカーの形式は KIND(NAMESPACE/NAME-OF-RESOURCE) です。

フィルターは 1 つまたは複数作成できます。ここでは、ログは 2 つの Kafka クラスターに対してフィルターされます。

複数のロギングフィルターの設定

appender.console.filter.filter1.type=MarkerFilter
appender.console.filter.filter1.onMatch=ACCEPT
appender.console.filter.filter1.onMismatch=DENY
appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster-1)
appender.console.filter.filter2.type=MarkerFilter
appender.console.filter.filter2.onMatch=ACCEPT
appender.console.filter.filter2.onMismatch=DENY
appender.console.filter.filter2.marker=Kafka(my-namespace/my-kafka-cluster-2)

フィルターの Cluster Operator への追加

フィルターを Cluster Operator に追加するには、そのロギング ConfigMap YAML ファイルを更新します (install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml)。

手順

  1. 050-ConfigMap-strimzi-cluster-operator.yaml ファイルを更新して、フィルタープロパティーを ConfigMap に追加します。

    この例では、フィルタープロパティーは my-kafka-cluster Kafka クラスターのログのみを返します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: strimzi-cluster-operator
    data:
      log4j2.properties:
        #...
        appender.console.filter.filter1.type=MarkerFilter
        appender.console.filter.filter1.onMatch=ACCEPT
        appender.console.filter.filter1.onMismatch=DENY
        appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster)

    または、ConfigMap を直接編集することもできます。

    oc edit configmap strimzi-cluster-operator
  2. ConfigMap を直接編集せずに YAML ファイルを更新する場合は、ConfigMap をデプロイして変更を適用します。

    oc create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml

Topic Operator または User Operator へのフィルターの追加

フィルターを Topic Operator または User Operator に追加するには、ロギング ConfigMap を作成または編集します。

この手順では、ロギング ConfigMap は、Topic Operator のフィルターで作成されます。User Operator に同じアプローチが使用されます。

手順

  1. ConfigMap を作成します。

    ConfigMap を YAML ファイルとして作成するか、プロパティーファイルから Config Map を作成します。

    この例では、フィルタープロパティーは my-topic トピックに対してのみログを返します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: logging-configmap
    data:
      log4j2.properties:
        rootLogger.level="INFO"
        appender.console.filter.filter1.type=MarkerFilter
        appender.console.filter.filter1.onMatch=ACCEPT
        appender.console.filter.filter1.onMismatch=DENY
        appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)

    プロパティーファイルを使用している場合は、コマンドラインでファイルを指定します。

    oc create configmap logging-configmap --from-file=log4j2.properties

    プロパティーファイルではロギング設定が定義されます。

    # Define the logger
    rootLogger.level="INFO"
    # Set the filters
    appender.console.filter.filter1.type=MarkerFilter
    appender.console.filter.filter1.onMatch=ACCEPT
    appender.console.filter.filter1.onMismatch=DENY
    appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)
    # ...
  2. リソースの specexternal ロギングを定義し、logging.valueFrom.configMapKeyRef.name に ConfigMap の名前を、logging.valueFrom.configMapKeyRef.key にこの ConfigMap のキーを設定します。

    Topic Operator については、Kafka リソースの topicOperator 設定でロギングを指定します。

    spec:
      # ...
      entityOperator:
        topicOperator:
          logging:
            type: external
            valueFrom:
              configMapKeyRef:
                name: logging-configmap
                key: log4j2.properties
  3. Cluster Operator をデプロイして変更を適用します。
create -f install/cluster-operator -n my-cluster-operator-namespace

第3章 外部ソースからの設定値の読み込み

設定プロバイダープラグインを使用して、外部ソースから設定データを読み込みます。プロバイダーは AMQ Streams とは独立して動作します。これを使用して、プロデューサーやコンシューマーを含む、すべての Kafka コンポーネントの設定データを読み込むことができます。たとえば、これを使用して、KafkaConnect コネクター設定のクレデンシャルを提供します。

OpenShift 設定プロバイダー

OpenShift Configuration Provider プラグインは、OpenShift シークレットまたは ConfigMap から設定データを読み込みます。

Kafka namespace 外で管理される Secret オブジェクト、または Kafka クラスター外にあるシークレットがあるとします。OpenShift 設定プロバイダーを使用すると、ファイルを抽出せずに設定のシークレットの値を参照できます。使用するシークレットをプロバイダーに伝え、アクセス権限を提供する必要があります。プロバイダーは、新しい Secret または ConfigMap を使用している場合でも、Kafka コンポーネントを再起動することなくデータをロードします。この機能により、Kafka Connect インスタンスが複数のコネクターをホストする場合に中断の発生を防ぎます。

環境変数設定プロバイダー

環境変数の設定プロバイダープラグインを使用して、環境変数から設定データを読み込みます。

環境変数の値は、シークレットまたは ConfigMap からマッピングできます。環境変数設定プロバイダーを使用して、たとえば、OpenShift シークレットからマップされた環境変数から証明書または JAAS 設定を読み込むことができます。

注記

OpenShift Configuration Provider はマウントされたファイルを使用できません。たとえば、トラストストアまたはキーストアの場所を必要とする値をロードできません。代わりに、ConfigMap またはシークレットを環境変数またはボリュームとして Kafka Connect Pod にマウントできます。環境変数設定プロバイダーを使用して、環境変数の値を読み込むことができます。KafkaConnect.specexternalConfiguration プロパティー を使用して設定を追加します。このアプローチでアクセス権限を設定する必要はありません。ただし、コネクターに新しい Secret または ConfigMap を使用する場合は、Kafka Connect の再起動が必要になります。これにより、すべての Kafka Connect インスタンスのコネクターが中断されます。

3.1. ConfigMap からの設定値の読み込み

この手順では、OpenShift 設定プロバイダープラグインを使用する方法を説明します。

この手順では、外部 ConfigMap はコネクターの設定プロパティーを提供します。

前提条件

  • 利用可能な OpenShift クラスター
  • 稼働中の Kafka クラスター
  • Cluster Operator が稼働中です。

手順

  1. 設定プロパティーが含まれる ConfigMap またはシークレットを作成します。

    この例では、my-connector-configuration という名前の ConfigMap にはコネクタープロパティーが含まれます。

    コネクタープロパティーのある ConfigMap の例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-connector-configuration
    data:
      option1: value1
      option2: value2

  2. Kafka Connect 設定で OpenShift Configuration Provider を指定します。

    ここで示される仕様は、シークレットおよび ConfigMap からの値の読み込みをサポートできます。

    OpenShift 設定プロバイダーを有効にする Kafka Connect の設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      name: my-connect
      annotations:
        strimzi.io/use-connector-resources: "true"
    spec:
      # ...
      config:
        # ...
        config.providers: secrets,configmaps 1
        config.providers.secrets.class: io.strimzi.kafka.KubernetesSecretConfigProvider 2
        config.providers.configmaps.class: io.strimzi.kafka.KubernetesConfigMapConfigProvider 3
      # ...

    1
    設定プロバイダーのエイリアスは、他の設定パラメーターを定義するために使用されます。プロバイダーパラメーターは config.providers からのエイリアスを使用し、config.providers.${alias}.class の形式を取ります。
    2
    KubernetesSecretConfigProvider は Secret から値を指定します。
    3
    KubernetesConfigMapConfigProvider は設定マップから値を指定します。
  3. リソースを作成または更新してプロバイダーを有効にします。

    oc apply -f <kafka_connect_configuration_file>
  4. 外部の設定マップの値へのアクセスを許可するロールを作成します。

    設定マップから値にアクセスするロールの例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: connector-configuration-role
    rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      resourceNames: ["my-connector-configuration"]
      verbs: ["get"]
    # ...

    このルールは、my-connector-configuration 設定マップにアクセスするためのロールパーミッションを付与します。

  5. ロールバインディングを作成し、設定マップが含まれる namespace へのアクセスを許可します。

    設定マップが含まれる namespace にアクセスするためのロールバインディングの例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: connector-configuration-role-binding
    subjects:
    - kind: ServiceAccount
      name: my-connect-connect
      namespace: my-project
    roleRef:
      kind: Role
      name: connector-configuration-role
      apiGroup: rbac.authorization.k8s.io
    # ...

    ロールバインディングは、ロールに my-project 名前空間へのアクセス許可を与えます。

    サービスアカウントは、Kafka Connect デプロイメントによって使用されるものと同じである必要があります。サービスアカウント名の形式は <cluster_name>-connect で、<cluster_name>KafkaConnect のカスタムリソースの名前です。

  6. コネクター設定で設定マップを参照します。

    設定マップを参照するコネクター設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnector
    metadata:
      name: my-connector
      labels:
        strimzi.io/cluster: my-connect
    spec:
      # ...
      config:
        option: ${configmaps:my-project/my-connector-configuration:option1}
        # ...
    # ...

    設定マップのプロパティー値のプレースホルダーは、コネクター設定で参照されます。プレースホルダー構造は、configmaps:<path_and_file_name>:<property> です。KubernetesConfigMapConfigProvider は、外部の ConfigMap から option1 プロパティーの値を読み込んで抽出します。

3.2. 環境変数から設定値の読み込み

この手順では、環境変数設定プロバイダープラグインを使用する方法を説明します。

この手順では、環境変数はコネクターの設定プロパティーを提供します。データベースのパスワードは環境変数として指定します。

前提条件

  • 利用可能な OpenShift クラスター
  • 稼働中の Kafka クラスター
  • Cluster Operator が稼働中です。

手順

  1. Kafka Connect 設定で環境変数設定プロバイダーを指定します。

    externalConfiguration プロパティー を使用して環境変数を定義します。

    環境変数設定プロバイダーを有効にする Kafka Connect 設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      name: my-connect
      annotations:
        strimzi.io/use-connector-resources: "true"
    spec:
      # ...
      config:
        # ...
        config.providers: env 1
        config.providers.env.class: io.strimzi.kafka.EnvVarConfigProvider 2
      # ...
      externalConfiguration:
        env:
          - name: DB_PASSWORD 3
            valueFrom:
              secretKeyRef:
                name: db-creds 4
                key: dbPassword 5
      # ...

    1
    設定プロバイダーのエイリアスは、他の設定パラメーターを定義するために使用されます。プロバイダーパラメーターは config.providers からのエイリアスを使用し、config.providers.${alias}.class の形式を取ります。
    2
    EnvVarConfigProvider は、環境変数から値を指定します。
    3
    DB_PASSWORD 環境変数は、シークレットからパスワードの値を取ります。
    4
    事前に定義されたパスワードが含まれるシークレットの名前。
    5
    シークレット内に格納されているパスワードのキー。
  2. リソースを作成または更新してプロバイダーを有効にします。

    oc apply -f <kafka_connect_configuration_file>
  3. コネクター設定の環境変数を参照してください。

    環境変数を参照するコネクター設定の例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnector
    metadata:
      name: my-connector
      labels:
        strimzi.io/cluster: my-connect
    spec:
      # ...
      config:
        option: ${env:DB_PASSWORD}
        # ...
    # ...

第4章 AMQ Streams Pod およびコンテナーへのセキュリティーコンテキストの適用

セキュリティーコンテキストは、Pod とコンテナーの制約を定義します。セキュリティーコンテキストを指定すると、Pod およびコンテナーに必要なパーミッションのみが設定されます。たとえば、パーミッションはランタイム操作やリソースへのアクセスを制御できます。

4.1. OpenShift プラットフォームによるセキュリティーコンテキストの処理

セキュリティーコンテキストの処理は、使用している OpenShift プラットフォームのツールによって異なります。

たとえば、OpenShift はビルトイン SCC (Security Context Constraints)を使用してパーミッションを制御します。SCC は、Pod がアクセスできるセキュリティー機能を制御する設定およびストラテジーです。

デフォルトでは、OpenShift はセキュリティーコンテキスト設定を自動的に注入します。ほとんどの場合、Cluster Operator によって作成される Pod およびコンテナーのセキュリティーコンテキストを設定する必要はありません。ただし、引き続き独自の SCC を作成して管理することはできます。

詳細は、Openshift ドキュメント を参照してください。

第5章 Apicurio Registry の Red Hat ビルドを使用したスキーマの検証

AMQ Streams で Apicurio Registry の Red Hat ビルドを使用できます。

Apicurio Registry は、API およびイベント駆動型アーキテクチャー全体で標準的なイベントスキーマおよび API 設計を共有するためのデータストアです。Apicurio Registry を使用して、クライアントアプリケーションからデータの構造を切り離し、REST インターフェイスを使用して実行時にデータ型と API の記述を共有および管理できます。

Apicurio Registry では、メッセージをシリアライズおよびデシリアライズするために使用されるスキーマが保存されます。その後、クライアントアプリケーションからスキーマを参照して、送受信されるメッセージとこれらのスキーマの互換性を維持するようにします。Apicurio Registry によって、Kafka プロデューサーおよびコンシューマーアプリケーションの Kafka クライアントシリアライザーおよびデシリアライザーが提供されます。Kafka プロデューサーアプリケーションは、シリアライザーを使用して、特定のイベントスキーマに準拠するメッセージをエンコードします。Kafka コンシューマーアプリケーションはデシリアライザーを使用して、特定のスキーマ ID に基づいてメッセージが適切なスキーマを使用してシリアライズされたことを検証します。

アプリケーションがレジストリーからスキーマを使用できるようにすることができます。これにより、スキーマが一貫して使用されるようにし、実行時にデータエラーが発生しないようにします。

関連情報

第6章 カスタムリソース API のリファレンス

6.1. 共通の設定プロパティー

共通設定プロパティーは複数のリソースに適用されます。

6.1.1. replicas

replicas プロパティーを使用してレプリカを設定します。

レプリケーションのタイプはリソースによって異なります。

  • KafkaTopic はレプリケーション係数を使用して、Kafka クラスター内で各パーティションのレプリカ数を設定します。
  • Kafka コンポーネントはレプリカを使用してデプロイメントの Pod 数を設定し、可用性とスケーラビリティーを向上します。
注記

OpenShift で Kafka コンポーネントを実行している場合、高可用性のために複数のレプリカを実行する必要がない場合があります。コンポーネントがデプロイされたノードがクラッシュすると、OpenShift によって自動的に Kafka コンポーネント Pod が別のノードに再スケジュールされます。ただし、複数のレプリカで Kafka コンポーネントを実行すると、他のノードが稼働しているため、フェイルオーバー時間が短縮されます。

6.1.2. bootstrapServers

bootstrapServers プロパティーを使用してブートストラップサーバーのリストを設定します。

ブートストラップサーバーリストは、同じ OpenShift クラスターにデプロイされていない Kafka クラスターを参照できます。AMQ Streams によってデプロイされた Kafka クラスターを参照することもできます。

同じ OpenShift クラスターである場合、各リストに CLUSTER-NAME-kafka-bootstrap という名前の Kafka クラスターブートストラップサービスとポート番号が含まれる必要があります。AMQ Streams によって異なる OpenShift クラスターにデプロイされた場合、リストの内容はクラスターを公開するために使用された方法によって異なります (route、ingress、nodeport、または loadbalancer)。

AMQ Streams によって管理されない Kafka クラスターで Kafka を使用する場合は、指定のクラスターの設定に応じてブートストラップサーバーのリストを指定できます。

6.1.3. ssl

SSL 設定と暗号スイートの仕様を組み込んで、クライアントアプリケーションと Kafka クラスター間の TLS ベースの通信をさらに保護できます。標準の TLS 設定に加えて、サポートされている TLS バージョンを指定し、Kafka ブローカーの設定で暗号スイートを有効にすることができます。クライアントが使用する TLS バージョンと暗号スイートを制限する場合は、クライアントに設定を追加することもできます。クライアントの設定では、ブローカーで有効になっているプロトコルと暗号スイートのみを使用する必要があります。

暗号スイートは、セキュアな接続とデータ転送のための一連のセキュリティーメカニズムです。たとえば、暗号スイート TLS_AES_256_GCM_SHA384 は、TLS プロトコルと組み合わせて使用される次のメカニズムで設定されています。

  • AES (Advanced Encryption Standard) 暗号化 (256 ビットキー)
  • GCM (Galois/Counter Mode) 認証暗号化
  • SHA384 (Secure Hash Algorithm) データ整合性保護

この組み合わせは、TLS_AES_256_GCM_SHA384 暗号スイート仕様にカプセル化されています。

ssl.enabled.protocols プロパティーは、クラスターとそのクライアントの間のセキュアな通信に使用できる TLS バージョンを指定します。ssl.protocol プロパティーは、すべての接続のデフォルトの TLS バージョンを設定します。有効なプロトコルから選択する必要があります。ssl.endpoint.identification.algorithm プロパティーを使用して、ホスト名検証を有効または無効にします。

SSL の設定例

# ...
config:
  ssl.cipher.suites: TLS_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 1
  ssl.enabled.protocols: TLSv1.3, TLSv1.2 2
  ssl.protocol: TLSv1.3 3
  ssl.endpoint.identification.algorithm: HTTPS 4
# ...

1
有効な暗号スイート仕様。
2
サポート対象の TLS バージョン。
3
デフォルトの TLS バージョンは TLSv1.3 です。クライアントが TLSv1.2 のみをサポートしている場合でも、サポートされているバージョンを使用してブローカーに接続して通信できます。また、クライアント上に設定があり、ブローカーが TLSv1.2 のみをサポートしている場合はその逆です。
4
ホスト名の検証は、HTTPS に設定して有効化されます。空の文字列を指定すると検証が無効になります。

6.1.4. trustedCertificates

tls を設定して TLS 暗号化を設定する場合は、trustedCertificates プロパティーを使用して、証明書が X.509 形式で保存されるキー名にシークレットの一覧を提供します。

Kafka クラスターの Cluster Operator によって作成されるシークレットを使用するか、独自の TLS 証明書ファイルを作成してから、ファイルから Secret を作成できます。

oc create secret generic MY-SECRET \
--from-file=MY-TLS-CERTIFICATE-FILE.crt

TLS による暗号化の設定例

tls:
  trustedCertificates:
    - secretName: my-cluster-cluster-cert
      certificate: ca.crt
    - secretName: my-cluster-cluster-cert
      certificate: ca2.crt

複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。

TLS 暗号化を有効にし、Java に同梱されるデフォルトの公開認証局のセットを使用する場合は、trustedCertificates を空の配列として指定できます。

デフォルトの Java 証明書で TLS を有効にする例

tls:
  trustedCertificates: []

mTLS 認証の設定に関する詳細は、KafkaClientAuthenticationTls schema reference を参照してください。

6.1.5. resources

AMQ Streams コンテナーのリソースを制御するために、リソース 要求 および 制限 を設定します。メモリーおよび cpu リソースの要求および制限を指定できます。要求には、Kafka の安定したパフォーマンスを確保できる十分な値が必要です。

実稼働環境でリソースを設定する方法は、さまざまな要因によって異なります。たとえば、アプリケーションは OpenShift クラスターでリソースを共有する可能性があります。

Kafka では、デプロイメントの以下の要素が、必要なリソースに影響を与える可能性があります。

  • メッセージのスループットとサイズ
  • メッセージを処理するネットワークスレッドの数
  • プロデューサーおよびコンシューマーの数
  • トピックおよびパーティションの数

リソース要求に指定の値は予約され、常にコンテナーで利用可能になります。リソース制限によって、指定のコンテナーが消費可能な最大リソースが指定されます。要求数から制限数の間は予約されず、常に利用できるとは限りません。コンテナーは、リソースが利用できる場合のみ、制限以下のリソースを使用できます。リソースの制限は一時的で、再割り当てが可能です。

リソース要求および制限

Boundaries of a resource requests and limits

要求なしに制限を設定する場合や、その逆の場合、OpenShift は両方に同じ値を使用します。OpenShift は制限を超えない限りコンテナーを強制終了しないので、リソースに対して、要求と制限を同じ数に設定すると、QoS (Quality of Service) が保証されます。

サポート対象のリソース 1 つまたは複数に対して、リソース要求および制限を設定できます。

リソース設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
  entityOperator:
    #...
    topicOperator:
      #...
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"

Topic Operator および User Operator のリソース要求および制限は Kafka リソースに設定されます。

リソース要求が OpenShift クラスターで利用可能な空きリソースを超える場合、Pod はスケジュールされません。

注記

AMQ Streams では、OpenShift 構文を使用して メモリー および cpu リソースを指定します。OpenShift におけるコンピュートリソースの管理に関する詳細は、Managing Compute Resources for Containers を参照してください。

メモリーリソース

メモリーリソースを設定する場合は、コンポーネントの合計要件を考慮してください。

Kafka は JVM 内で実行され、オペレーティングシステムページキャッシュを使用してディスクに書き込む前にメッセージデータを保存します。Kafka のメモリー要求は、JVM ヒープおよびページキャッシュに適合する必要があります。 jvmOptions プロパティーを設定 すると、最小および最大ヒープサイズを制御できます。

他のコンポーネントはページキャッシュに依存しません。メモリーリソースは、ヒープサイズを制御する jvmOptions を指定せずに、設定できます。

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。仕様では、以下の接尾辞を使用します。

  • M (メガバイト)
  • G (ギガバイト)
  • Mi (メビバイト)
  • Gi (ギビバイト)

異なるメモリー単位を使用するリソースの例

# ...
resources:
  requests:
    memory: 512Mi
  limits:
    memory: 2Gi
# ...

メモリーの指定およびサポートされるその他の単位に関する詳細は、Meaning of memory を参照してください。

CPU リソース

常に信頼できるパフォーマンスを発揮させるには、CPU 要求を十分に指定する必要があります。CPU の要求および制限は、コア または ミリ cpu/ミリコア として指定します。

CPU コアは、整数 (5 CPU コア) または小数 (2.5 CPU コア) で指定します。1000 ミリコア1 CPU コアと同じです。

CPU の単位の例

# ...
resources:
  requests:
    cpu: 500m
  limits:
    cpu: 2.5
# ...

1 つの CPU コアのコンピューティング能力は、OpenShift がデプロイされたプラットフォームによって異なることがあります。

CPU 仕様の詳細は、Meaning of CPUを参照してください。

6.1.6. image

image プロパティーを使用して、コンポーネントによって使用されるコンテナーイメージを設定します。

コンテナーイメージのオーバーライドは、別のコンテナーレジストリーやカスタマイズされたイメージを使用する必要がある特別な状況でのみ推奨されます。

たとえば、ネットワークで AMQ Streams によって使用されるコンテナーリポジトリーへのアクセスが許可されない場合、AMQ Streams イメージのコピーまたはソースからのビルドを行うことができます。しかし、設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。

コンテナーイメージのコピーはカスタマイズでき、デバッグに使用されることもあります。

以下のリソースの image プロパティーを使用すると、コンポーネントに使用するコンテナーイメージを指定できます。

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper
  • Kafka.spec.entityOperator.topicOperator
  • Kafka.spec.entityOperator.userOperator
  • Kafka.spec.entityOperator.tlsSidecar
  • KafkaConnect.spec
  • KafkaMirrorMaker.spec
  • KafkaMirrorMaker2.spec
  • KafkaBridge.spec

Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定

Kafka、Kafka Connect、および Kafka MirrorMaker では、複数の Kafka バージョンがサポートされます。各コンポーネントには独自のイメージが必要です。異なる Kafka バージョンのデフォルトイメージは、以下の環境変数で設定されます。

  • STRIMZI_KAFKA_IMAGES
  • STRIMZI_KAFKA_CONNECT_IMAGES
  • STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

これらの環境変数には、Kafka バージョンと対応するイメージ間のマッピングが含まれます。マッピングは、image および version プロパティーとともに使用されます。

  • imageversion のどちらもカスタムリソースに指定されていない場合、version は Cluster Operator のデフォルトの Kafka バージョンに設定され、環境変数のこのバージョンに対応するイメージが指定されます。
  • image が指定されていても version が指定されていない場合、指定されたイメージが使用され、Cluster Operator のデフォルトの Kafka バージョンが version であると想定されます。
  • version が指定されていても image が指定されていない場合、環境変数の指定されたバージョンに対応するイメージが使用されます。
  • versionimage の両方を指定すると、指定されたイメージが使用されます。このイメージには、指定のバージョンの Kafka イメージが含まれると想定されます。

異なるコンポーネントの image および version は、以下のプロパティーで設定できます。

  • Kafka の場合は spec.kafka.image および spec.kafka.version
  • spec.image および spec.version の Kafka Connect および Kafka MirrorMaker の場合。
警告

version のみを提供し、image プロパティーを未指定のままにしておくことが推奨されます。これにより、カスタムリソースの設定時に間違いが発生する可能性が低減されます。異なるバージョンの Kafka に使用されるイメージを変更する必要がある場合は、Cluster Operator の環境変数を設定することが推奨されます。

他のリソースでの image プロパティーの設定

他のカスタムリソースの image プロパティーでは、デプロイメント中に指定の値が使用されます。image プロパティーがない場合、Cluster Operator 設定に指定された image が使用されます。image 名が Cluster Operator 設定に定義されていない場合、デフォルト値が使用されます。

  • Topic Operator の場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/strimzi-rhel8-operator:2.4.0 container image.
  • User Operator の場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/strimzi-rhel8-operator:2.4.0 container image.
  • Entity Operator TLS サイドカーの場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/kafka-34-rhel8:2.4.0 container image.
  • Kafka Exporter の場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/kafka-34-rhel8:2.4.0 container image.
  • Kafka Bridge の場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/bridge-rhel8:2.4.0 container image.
  • Kafka ブローカーイニシャライザーの場合:

    1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
    2. registry.redhat.io/amq-streams/strimzi-rhel8-operator:2.4.0 container image.

コンテナーイメージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    image: my-org/my-image:latest
    # ...
  zookeeper:
    # ...

6.1.7. livenessProbe および readinessProbe healthcheck

livenessProbe および readinessProbe プロパティーを使用して、AMQ Streams でサポートされる healthcheck プローブを設定します。

Healthcheck は、アプリケーションの健全性を検証する定期的なテストです。ヘルスチェックプローブが失敗すると、OpenShift によってアプリケーションが正常でないと見なされ、その修正が試行されます。

プローブの詳細は、Configure Liveness and Readiness Probes を参照してください。

livenessProbe および readinessProbe の両方で以下のオプションがサポートされます。

  • initialDelaySeconds
  • timeoutSeconds
  • periodSeconds
  • successThreshold
  • failureThreshold

Liveness および Readiness プローブの設定例

# ...
readinessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
livenessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
# ...

livenessProbe および readinessProbe のオプションに関する詳細は、Probe スキーマ参照 を参照してください。

6.1.8. metricsConfig

metricsConfig プロパティーを使用して、Prometheus メトリクスを有効化および設定します。

metricsConfig プロパティーには、Prometheus JMX Exporter の追加設定が含まれる ConfigMap への参照が含まれます。AMQ Streams では、Apache Kafka および ZooKeeper によってサポートされる JMX メトリクスを Prometheus メトリクスに変換するために、Prometheus JMX エクスポーターを使用した Prometheus メトリクスがサポートされます。

追加設定なしで Prometheus メトリクスのエクスポートを有効にするには、metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap を参照します。空のファイルを参照する場合、名前が変更されていない限り、すべてのメトリクスが公開されます。

Kafka のメトリクス設定が含まれる ConfigMap の例

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-configmap
data:
  my-key: |
    lowercaseOutputName: true
    rules:
    # Special cases and very specific rules
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
       clientId: "$3"
       topic: "$4"
       partition: "$5"
    # further configuration

Kafka のメトリクス設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    # ...
  zookeeper:
    # ...

有効になったメトリクスは、9404 番ポートで公開されます。

metricsConfig (または非推奨の metrics) プロパティーがリソースに定義されていない場合、Prometheus メトリクスは無効になります。

Prometheus および Grafana の設定およびデプロイに関する詳細は、OpenShift での AMQ Streams のデプロイおよびアップグレードKafka へのメトリクスの導入を参照してください。

6.1.9. jvmOptions

以下の AMQ Streams コンポーネントは、Java 仮想マシン (JVM) 内で実行されます。

  • Apache Kafka
  • Apache ZooKeeper
  • Apache Kafka Connect
  • Apache Kafka MirrorMaker
  • AMQ Streams Kafka Bridge

異なるプラットフォームやアーキテクチャーでパフォーマンスを最適化するには、以下のリソースに jvmOptions プロパティーを設定します。

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper
  • Kafka.spec.entityOperator.userOperator
  • Kafka.spec.entityOperator.topicOperator
  • Kafka.spec.cruiseControl
  • KafkaConnect.spec
  • KafkaMirrorMaker.spec
  • KafkaMirrorMaker2.spec
  • KafkaBridge.spec

設定では、以下のオプションを指定できます。

-Xms
JVM の起動時に最初に割り当てられる最小ヒープサイズ。
-Xmx
最大ヒープサイズ
-XX
JVM の高度なランタイムオプション
javaSystemProperties
追加のシステムプロパティー
gcLoggingEnabled
ガベッジコレクターのロギングを有効にします
注記

-Xmx-Xms などの JVM 設定で使用できる単位は、対応するイメージの JDK java バイナリーで使用できる単位と同じです。そのため、1g または 1G は 1,073,741,824 バイトを意味し、Gi は接尾辞として有効な単位ではありません。これは、1G が 1,000,000,000 バイトを意味し、1Gi が 1,073,741,824 バイトを意味する OpenShift 規則に従う、メモリー要求および制限 に使用される単位とは異なります。

-Xms および -Xmx オプション

コンテナーのメモリー要求および制限値を設定するだけでなく、-Xms および -Xmx JVM オプションを使用して、JVM に特定のヒープサイズを設定できます。-Xms オプションを使用して初期ヒープサイズを設定し、-Xmx オプションを使用して最大ヒープサイズを設定します。

JVM に割り当てられたメモリーをより詳細に制御するには、ヒープサイズを指定します。ヒープサイズは、コンテナーの メモリー制限 (および要求) を最大限に活用し、それを超えないようにする必要があります。ヒープサイズとその他のメモリー要件は、指定されたメモリー制限内に収まる必要があります。設定でヒープサイズを指定せずに、メモリーリソースの制限 (および要求) を設定する場合、Cluster Operator はデフォルトのヒープサイズを自動的に適用します。Cluster Operator は、メモリーリソース設定の割合に基づいて、デフォルトの最大および最小ヒープ値を設定します。

次の表に、デフォルトのヒープ値を示します。

表6.1 コンポーネントのデフォルトのヒープ設定
コンポーネントヒープに割り当てられた使用可能なメモリーの割合上限

Kafka

50%

5 GB

ZooKeeper

75%

2 GB

Kafka Connect

75%

なし

MirrorMaker 2

75%

なし

MirrorMaker

75%

なし

Cruise Control

75%

なし

Kafka Bridge

50%

31 Gi

メモリー制限 (および要求) が指定されていない場合、JVM の最小ヒープサイズは 128M に設定されます。JVM の最大ヒープサイズは、必要に応じてメモリーを増やすことができるように定義されていません。これは、テストおよび開発での単一ノード環境に適しています。

適切なメモリー要求を設定すると、次のことを防ぐことができます。

  • ノードで実行されている他の Pod からのメモリーに圧力がかかる場合、OpenShift はコンテナーを強制終了します。
  • OpenShift がメモリー不足のノードにコンテナーをスケジューリングする。-Xms-Xmx に設定されている場合には、コンテナーはすぐにクラッシュし、存在しない場合、コンテナーは後でクラッシュします。

この例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。JVM メモリー使用量の合計は、最大ヒープサイズを超える可能性があります。

-Xmx および -Xms の設定例

# ...
jvmOptions:
  "-Xmx": "2g"
  "-Xms": "2g"
# ...

最初のヒープサイズ (-Xms) および最大ヒープサイズ (-Xmx) に同じ値を設定すると、JVM が必要以上のヒープを割り当てて起動後にメモリーを割り当てないようにすることができます。

重要

Kafka ブローカーコンテナーなど、多数のディスク I/O を実行するコンテナーには、オペレーティングシステムのページキャッシュとして使用できるメモリーが必要です。このようなコンテナーの場合、要求されるメモリーは、JVM が使用するメモリーよりも大幅に大きくする必要があります。

-XX オプション

-XX オプションは、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS オプションの設定に使用されます。

-XX 設定

jvmOptions:
  "-XX":
    "UseG1GC": true
    "MaxGCPauseMillis": 20
    "InitiatingHeapOccupancyPercent": 35
    "ExplicitGCInvokesConcurrent": true

-XX 設定から生成される JVM オプション

-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -XX:-UseParNewGC

注記

-XX オプションを指定しないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

javaSystemProperties

javaSystemProperties は、デバッグユーティリティーなどの追加の Java システムプロパティーの設定に使用されます。

javaSystemProperties の設定例

jvmOptions:
  javaSystemProperties:
    - name: javax.net.debug
      value: ssl

jvmOptions の詳細については、JvmOptions スキーマリファレンス を参照してください。

6.1.10. ガベッジコレクターのロギング

jvmOptions プロパティーでは、ガベージコレクター (GC) のロギングを有効または無効にすることもできます。GC ロギングはデフォルトで無効になっています。これを有効にするには、以下のように gcLoggingEnabled プロパティーを設定します。

GC ロギングの設定例

# ...
jvmOptions:
  gcLoggingEnabled: true
# ...

6.2. スキーマプロパティー

6.2.1. Kafka スキーマ参照

プロパティー説明

spec

Kafka および ZooKeeper クラスター、Topic Operator の仕様。

KafkaSpec

status

Kafka および ZooKeeper クラスター、Topic Operator のステータス。

KafkaStatus

6.2.2. KafkaSpec スキーマ参照

Kafka で使用

プロパティー説明

kafka

Kafka クラスターの設定。

KafkaClusterSpec

zookeeper

ZooKeeper クラスターの設定。

ZookeeperClusterSpec

entityOperator

Entity Operator の設定。

EntityOperatorSpec

clusterCa

クラスター認証局の設定。

CertificateAuthority

clientsCa

クライアント認証局の設定。

CertificateAuthority

cruiseControl

Cruise Control デプロイメントの設定。指定時に Cruise Control インスタンスをデプロイします。

CruiseControlSpec

kafkaExporter

Kafka Exporter の設定。Kafka Exporter は追加のメトリクスを提供できます (例: トピック/パーティションでのコンシューマーグループのラグなど)。

KafkaExporterSpec

maintenanceTimeWindows

メンテナンスタスク (証明書の更新) 用の時間枠の一覧。それぞれの時間枠は、cron 式で定義されます。

string array

6.2.3. KafkaClusterSpec スキーマ参照

KafkaSpec で使用

KafkaClusterSpec スキーマプロパティーの完全リスト

Kafka クラスターを設定します。

6.2.3.1. listeners

listeners プロパティーを使用して、Kafka ブローカーへのアクセスを提供するようにリスナーを設定します。

認証のないプレーン (暗号化されていない) リスナーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
    # ...
  zookeeper:
    # ...

6.2.3.2. config

config プロパティーを使用して、Kafka ブローカーオプションをキーとして設定します。

標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。

以下に関連する設定オプションは設定できません。

  • セキュリティー (暗号化、認証、および承認)
  • リスナーの設定
  • Broker ID の設定
  • ログデータディレクトリーの設定
  • ブローカー間の通信
  • ZooKeeper の接続

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプションを除き、Apache Kafka ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

  • listeners
  • advertised.
  • broker.
  • listener.
  • host.name
  • port
  • inter.broker.listener.name
  • sasl.
  • ssl.
  • security.
  • password.
  • principal.builder.class
  • log.dir
  • zookeeper.connect
  • zookeeper.set.acl
  • authorizer.
  • super.user

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。サポートされるその他すべてのオプションは Kafka に渡されます。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。zookeeper.connection.timeout.ms プロパティーを設定して、ZooKeeper 接続の確立に許可される最大時間を設定することもできます。

Kafka ブローカーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      num.partitions: 1
      num.recovery.threads.per.data.dir: 1
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
      log.retention.hours: 168
      log.segment.bytes: 1073741824
      log.retention.check.interval.ms: 300000
      num.network.threads: 3
      num.io.threads: 8
      socket.send.buffer.bytes: 102400
      socket.receive.buffer.bytes: 102400
      socket.request.max.bytes: 104857600
      group.initial.rebalance.delay.ms: 0
      ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      ssl.enabled.protocols: TLSv1.2
      ssl.protocol: TLSv1.2
      zookeeper.connection.timeout.ms: 6000
    # ...

6.2.3.3. brokerRackInitImage

ラックアウェアネス (Rack Awareness) が有効である場合、Kafka ブローカー Pod は init コンテナーを使用して OpenShift クラスターノードからラベルを収集します。このコンテナーに使用されるコンテナーイメージは、brokerRackInitImage プロパティーを使用して設定できます。brokerRackInitImage フィールドがない場合、以下のイメージが優先度順に使用されます。

  1. Cluster Operator 設定の STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
  2. registry.redhat.io/amq-streams/strimzi-rhel8-operator:2.4.0 container image.

brokerRackInitImage の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    brokerRackInitImage: my-org/my-image:latest
    # ...

注記

コンテナーイメージのオーバーライドは、別のコンテナーレジストリーを使用する必要がある特別な状況でのみ推奨されます。たとえば、AMQ Streams によって使用されるコンテナーレジストリーにネットワークがアクセスできない場合などがこれに該当します。この場合は、AMQ Streams イメージをコピーするか、ソースからビルドする必要があります。設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。

6.2.3.4. logging

Kafka には独自の設定可能なロガーがあります。

  • log4j.logger.org.I0Itec.zkclient.ZkClient
  • log4j.logger.org.apache.zookeeper
  • log4j.logger.kafka
  • log4j.logger.org.apache.kafka
  • log4j.logger.kafka.request.logger
  • log4j.logger.kafka.network.Processor
  • log4j.logger.kafka.server.KafkaApis
  • log4j.logger.kafka.network.RequestChannel$
  • log4j.logger.kafka.controller
  • log4j.logger.kafka.log.LogCleaner
  • log4j.logger.state.change.logger
  • log4j.logger.kafka.authorizer.logger

Kafka では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  kafka:
    # ...
    logging:
      type: inline
      loggers:
        kafka.root.logger.level: "INFO"
  # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: kafka-log4j.properties
  # ...

設定されていない利用可能なロガーのレベルは OFF に設定されています。

Cluster Operator を使用して Kafka がデプロイされた場合、Kafka のロギングレベルの変更は動的に適用されます。

外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリング更新がトリガーされます。

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.3.5. KafkaClusterSpec スキーマプロパティー
プロパティー説明

version

Kafka ブローカーのバージョン。デフォルトは 3.4.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。

string

replicas

クラスター内の Pod 数。

integer

image

Pod の Docker イメージ。デフォルト値は、設定した Kafka.spec.kafka.version によって異なります。

string

listeners

Kafka ブローカーのリスナーを設定します。

GenericKafkaListener 配列

config

次の接頭辞のある Kafka ブローカーの config プロパティーは設定できません: listeners, advertised., broker., listener., host.name, port, inter.broker.listener.name, sasl., ssl., security., password., log.dir, zookeeper.connect, zookeeper.set.acl, zookeeper.ssl, zookeeper.clientCnxnSocket, authorizer., super.user, cruise.control.metrics.topic, cruise.control.metrics.reporter.bootstrap.servers,node.id, process.roles, controller. (次は対象外: zookeeper.connection.timeout.ms, sasl.server.max.receive.size,ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, ssl.secure.random.implementation,cruise.control.metrics.topic.num.partitions, cruise.control.metrics.topic.replication.factor, cruise.control.metrics.topic.retention.ms,cruise.control.metrics.topic.auto.create.retries, cruise.control.metrics.topic.auto.create.timeout.ms,cruise.control.metrics.topic.min.insync.replicas,controller.quorum.election.backoff.max.ms, controller.quorum.election.timeout.ms, controller.quorum.fetch.timeout.ms).

map

storage

ストレージの設定 (ディスク)。更新はできません。タイプは、指定のオブジェクト内の storage.type プロパティーの値によって異なり、[ephemeral、persistent-claim、jbod] のいずれかでなければなりません。

EphemeralStoragePersistentClaimStorageJbodStorage

認可

Kafka ブローカーの承認設定。タイプは、指定のオブジェクト内の authorization.type プロパティーの値によって異なり、[simple、opa、keycloak、custom] のいずれかでなければなりません。

KafkaAuthorizationSimpleKafkaAuthorizationOpaKafkaAuthorizationKeycloakKafkaAuthorizationCustom

rack

broker.rack ブローカー設定の設定

Rack

brokerRackInitImage

broker.rack の初期化に使用される init コンテナーのイメージ。

string

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

jvmOptions

Pod の JVM オプション。

JvmOptions

jmxOptions

Kafka ブローカーの JMX オプション。

KafkaJmxOptions

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

logging

Kafka のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

template

Kafka クラスターリソースのテンプレート。テンプレートを使用すると、ユーザーは StatefulSetPod、および Service の生成方法を指定できます。

KafkaClusterTemplate

6.2.4. Generic KafkaListener スキーマ参照

KafkaClusterSpec で使用

GenericKafkaListener スキーマプロパティーの完全リスト

OpenShift 内外の Kafka ブローカーに接続するようにリスナーを設定します。

Kafka リソースでリスナーを設定します。

リスナー設定を示す Kafka リソースの例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external1
        port: 9094
        type: route
        tls: true
      - name: external2
        port: 9095
        type: ingress
        tls: true
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
    #...

6.2.4.1. listeners

Kafka リソースの listeners プロパティーを使用して Kafka ブローカーリスナーを設定します。リスナーは配列として定義されます。

リスナーの設定例

listeners:
  - name: plain
    port: 9092
    type: internal
    tls: false

名前およびポートは Kafka クラスター内で一意である必要があります。名前は最大 25 文字で、小文字と数字で設定されます。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。

各リスナーに一意の名前とポートを指定することで、複数のリスナーを設定できます。

6.2.4.2. type

タイプは internal として設定されるか、外部リスナーの場合は routeloadbalancernodeportingress または cluster-ip として設定されます。また、カスタムアクセスメカニズムの構築に使用できる内部リスナーの一種である cluster-ip リスナーを設定することもできます。

internal

tls プロパティーを使用して、暗号化の有無に関わらず内部リスナーを設定できます。

internal リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
    #...

route

OpenShift Routes および HAProxy ルーターを使用して Kafka を公開するように外部リスナーを設定します。

Kafka ブローカー Pod ごとに専用の Route が作成されます。追加の Route が作成され、Kafka ブートストラップアドレスとして提供されます。これらの Routes を使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。クライアントはデフォルトのルーターポートであるポート 443 に接続しますが、トラフィックは設定するポート (この例では 9094 ) にルーティングされます。

route リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external1
        port: 9094
        type: route
        tls: true
    #...

ingress

Kubernetes Ingress および Ingress NGINX Controller for Kubernetes を使用して、Kafka を公開するように外部リスナーを設定します。

各 Kafka ブローカー Pod に専用の Ingress リソースが作成されます。追加の Ingress リソースが作成され、Kafka ブートストラップアドレスとして提供されます。これらの Ingress リソースを使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。クライアントはデフォルトのコントローラーポートであるポート 443 に接続しますが、トラフィックは設定するポート (以下の例では 9095 にルーティングされます)。

GenericKafkaListenerConfigurationBootstrap および GenericKafkaListenerConfigurationBroker プロパティーを使用して、ブートストラップおよびブローカーごとのサービスによって使用されるホスト名を指定する必要があります。

Ingress リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external2
        port: 9095
        type: ingress
        tls: true
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
  #...

注記

Ingress を使用する外部リスナーは、現在 Ingress NGINX Controller for Kubernetes でのみテストされています。

loadbalancer

Loadbalancer タイプの Service を使用して Kafka を公開するように外部リスナーを設定します。

Kafka ブローカー Pod ごとに新しいロードバランサーサービスが作成されます。追加のロードバランサーが作成され、Kafka の ブートストラップ アドレスとして提供されます。ロードバランサーは指定のポート番号をリッスンします。以下の例ではポート 9094 です。

loadBalancerSourceRanges プロパティーを使用して、指定された IP アドレスへのアクセスを制限する ソース範囲 を設定できます。

loadbalancer リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        configuration:
          loadBalancerSourceRanges:
            - 10.0.0.0/8
            - 88.208.76.87/32
    #...

nodeport

NodePort タイプの Services を使用して Kafka を公開するように外部リスナーを設定します。

Kafka クライアントは OpenShift のノードに直接接続します。追加の NodePort タイプのサービスが作成され、Kafka ブートストラップアドレスとして提供されます。

Kafka ブローカー Pod にアドバタイズされたアドレスを設定する場合、AMQ Stremas では該当の Pod が稼働しているノードのアドレスが使用されます。preferredNodePortAddressType プロパティーを使用して、チェックした最初のアドレスタイプをノードアドレスとして設定することができます。

nodeport リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external4
        port: 9095
        type: nodeport
        tls: false
        configuration:
          preferredNodePortAddressType: InternalDNS
    #...

注記

ノードポートを使用して Kafka クラスターを公開する場合、現在 TLS ホスト名の検証はサポートされません。

cluster-ip

ブローカーごとの ClusterIP タイプ Service を使用して Kafka を公開するように内部リスナーを設定します。

リスナーは、ヘッドレスサービスとその DNS 名を使用してトラフィックを Kafka ブローカーにルーティングしません。ヘッドレスサービスの使用が不適切な場合は、このタイプのリスナーを使用して Kafka クラスターを公開できます。特定の Ingress コントローラーや OpenShift Gateway API を使用するものなど、カスタムアクセスメカニズムで使用できます。

Kafka ブローカー Pod ごとに新しい ClusterIP サービスが作成されます。このサービスには、ブローカーごとのポート番号を持つ Kafka ブートストラップ アドレスとして機能する ClusterIP アドレスが割り当てられます。たとえば、TCP ポート設定を使用して、Nginx Ingress Controller を介して Kafka クラスターを公開するようにリスナーを設定できます。

cluster-ip リスナーの設定例

#...
spec:
  kafka:
    #...
    listeners:
      - name: external-cluster-ip
        type: cluster-ip
        tls: false
        port: 9096
    #...

6.2.4.3. port

ポート番号は Kafka クラスターで使用されるポートで、クライアントによるアクセスに使用されるポートとは異なる場合があります。

  • loadbalancer リスナーは、指定されたポート番号を使用します。internal および cluster-ip リスナーも同様です。
  • ingress および route リスナーはアクセスにポート 443 を使用します。
  • nodeport リスナーは OpenShift によって割り当てられたポート番号を使用します。

クライアント接続の場合は、リスナーのブートストラップサービスのアドレスおよびポートを使用します。これは、Kafka リソースのステータス から取得できます。

クライアント接続のアドレスおよびポートを取得するコマンドの例

oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

注記

ブローカー間通信 (9090 および 9091) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。

6.2.4.4. tls

TLS プロパティーが必要です。

デフォルトでは、TLS による暗号化は有効になっていません。これを有効にするには、tls プロパティーを true に設定します。

ingress および ingress タイプのリスナーの場合、TLS 暗号化を有効にする必要があります。

6.2.4.5. 認証

リスナーの認証は以下のように指定できます。

  • mTLS (tls)
  • SCRAM-SHA-512 (scram-sha-512)
  • トークンベースの OAuth 2.0 (oauth)
  • Custom(カスタム)
6.2.4.6. networkPolicyPeers

ネットワークレベルでリスナーへのアクセスを制限するネットワークポリシーを設定するには、networkPolicyPeers を使用します。次の例では、plaintls リスナーの networkPolicyPeers の設定を示しています。

以下の例では、下記の点を前提としています。

  • ラベル app: kafka-sasl-consumer および app: kafka-sasl-producer と一致するアプリケーション Pod のみが plain リスナーに接続できます。アプリケーション Pod は Kafka ブローカーと同じ namespace で実行されている必要があります。
  • ラベル project: myproject および project: myproject2 と一致する namespace で稼働しているアプリケーション Pod のみ、tls リスナーに接続できます。

networkPolicyPeers プロパティーの構文は、NetworkPolicy リソースの from プロパティーと同じです。

ネットワークポリシー設定の例

listeners:
  #...
  - name: plain
    port: 9092
    type: internal
    tls: true
    authentication:
      type: scram-sha-512
    networkPolicyPeers:
      - podSelector:
          matchLabels:
            app: kafka-sasl-consumer
      - podSelector:
          matchLabels:
            app: kafka-sasl-producer
  - name: tls
    port: 9093
    type: internal
    tls: true
    authentication:
      type: tls
    networkPolicyPeers:
      - namespaceSelector:
          matchLabels:
            project: myproject
      - namespaceSelector:
          matchLabels:
            project: myproject2
# ...

6.2.4.7. GenericKafkaListener スキーマプロパティー
プロパティー説明

name

リスナーの名前。名前は、リスナーおよび関連する OpenShift オブジェクトの識別に使用されます。指定の Kafka クラスター内で一意となる必要があります。この名前には、小文字と数字を使用でき、最大 11 文字まで使用できます。

string

port

Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。

integer

type

リスナーのタイプ。現在サポートされているタイプは、internalrouteloadbalancernodeportingress です。

  • internal タイプは、OpenShift クラスター内でのみ Kafka を内部的に公開します。
  • route タイプは、OpenShift Routes を使用して Kafka を公開します。
  • loadbalancer タイプは、LoadBalancer タイプのサービスを使用して Kafka を公開します。
  • nodeport タイプは、NodePort タイプのサービスを使用して Kafka を公開します。
  • ingress タイプは、OpenShift Nginx Ingress を使用して、TLS パススルーで Kafka を公開します。
  • cluster-ip タイプは、ブローカーごとの ClusterIP サービスを使用します。

文字列 (ingress、internal、route、loadbalancer、cluster-ip、nodeport のいずれか)

tls

リスナーで TLS による暗号化を有効にします。これは必須プロパティーです。

boolean

authentication

このリスナーの認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls、scram-sha-512、oauth、custom] のいずれかでなければなりません。

KafkaListenerAuthenticationTlsKafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationOAuthKafkaListenerAuthenticationCustom

configuration

追加のリスナー設定。

GenericKafkaListenerConfiguration

networkPolicyPeers

このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメント を参照してください。

NetworkPolicyPeer アレイ

6.2.5. KafkaListenerAuthenticationTls スキーマ参照

GenericKafkaListener で使用

typeプロパティーは、KafkaListenerAuthenticationTlsタイプと、 KafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationOAuthKafkaListenerAuthenticationCustom とを区別して使用するための識別子です。KafkaListenerAuthenticationTls タイプには tls の値が必要です。

プロパティー説明

type

tls でなければなりません。

string

6.2.6. KafkaListenerAuthenticationScramSha512 スキーマ参照

GenericKafkaListener で使用

type プロパティーは、KafkaListenerAuthenticationScramSha512 タイプと、KafkaListenerAuthenticationTlsKafkaListenerAuthenticationOAuthKafkaListenerAuthenticationCustom とを区別して使用するための識別子です。KafkaListenerAuthenticationScramSha512 タイプには scram-sha-512 の値が必要です。

プロパティー説明

type

scram-sha-512 でなければなりません。

string

6.2.7. KafkaListenerAuthenticationOAuth スキーマ参照

GenericKafkaListener で使用

type プロパティーは、KafkaListenerAuthenticationOAuth タイプと、KafkaListenerAuthenticationTlsKafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationCustom とを区別して使用するための識別子です。KafkaListenerAuthenticationOAuth タイプには oauth の値が必要です。

プロパティー説明

accessTokenIsJwt

アクセストークンを JWT として処理するかどうかを設定します。承認サーバーが不透明なトークンを返す場合は、false に設定する必要があります。デフォルトは true です。

boolean

checkAccessTokenType

アクセストークンタイプのチェックを行うかどうかを設定します。承認サーバーの JWT トークンに 'typ' 要求が含まれない場合は、false に設定する必要があります。デフォルトは true です。

boolean

checkAudience

オーディエンスのチェックを有効または無効にします。オーディエンスのチェックによって、トークンの受信者が特定されます。オーディエンスチェックが有効な場合、OAuth クライアント ID も clientId プロパティーで設定する必要があります。Kafka ブローカは、aud(オーディエンス) クレームに clientId がないトークンを拒否します。デフォルト値は false です。

boolean

checkIssuer

発行元のチェックを有効または無効にします。デフォルトでは、validIssuerUri によって設定された値を使用して発行元がチェックされます。デフォルト値は true です。

boolean

clientAudience

承認サーバーのトークンエンドポイントにリクエストを送信するときに使用するオーディエンス。ブローカー間の認証や、clientIdsecret メソッドを用いた PLAIN 上の OAuth 2.0 の設定に使用されます。

string

clientId

Kafka ブローカーは、OAuth クライアント ID を使用して承認サーバーに対して認証し、イントロスペクションエンドポイント URI を使用することができます。

string

clientScope

承認サーバーのトークンエンドポイントにリクエストを送信するときに使用するスコープ。ブローカー間の認証や、clientIdsecret メソッドを用いた PLAIN 上の OAuth 2.0 の設定に使用されます。

string

clientSecret

OAuth クライアントシークレットが含まれる OpenShift シークレットへのリンク。Kafka ブローカーは、OAuth クライアントシークレットを使用して承認サーバーに対して認証し、イントロスペクションエンドポイント URI を使用することができます。

GenericSecretSource

connectTimeoutSeconds

承認サーバーへの接続時のタイムアウト (秒単位)。設定しない場合は、実際の接続タイムアウトは 60 秒になります。

integer

customClaimCheck

JWT トークンに適用される JSONPath フィルタークエリー、または追加のトークン検証のイントロスペクションエンドポイントの応答に適用される JSONPath フィルタークエリー。デフォルトでは設定されません。

string

disableTlsHostnameVerification

TLS ホスト名の検証を有効または無効にします。デフォルト値は false です。

boolean

enableECDSA

enableECDSA プロパティーは非推奨となりました。BouncyCastle 暗号プロバイダーをインストールして、ECDSA サポートを有効または無効にします。ECDSA サポートが常に有効になります。BouncyCastle ライブラリーは、AMQ Streams とパッケージ化されなくなりました。値は無視されます。

boolean

enableMetrics

OAuth メトリックを有効または無効にします。デフォルト値は false です。

boolean

enableOauthBearer

SASL_OAUTHBEARER での OAuth 認証を有効または無効にします。デフォルト値は true です。

boolean

enablePlain

SASL_PLAIN で OAuth 認証を有効または無効にします。このメカニズムが使用される場合、再認証はサポートされません。デフォルト値は false です。

boolean

failFast

起動時に回復可能な実行時エラーが発生する可能性があるため、Kafka ブローカープロセスの終了を有効または無効にします。デフォルト値は true です。

boolean

fallbackUserNameClaim

userNameClaim によって指定された要求が存在しない場合に、ユーザー ID に使用するフォールバックユーザー名要求。これは、client_credentials 認証によってクライアント ID が別の要求のみに提供される場合に便利です。userNameClaim が設定されている場合のみ有効です。

string

fallbackUserNamePrefix

ユーザー ID を設定するために fallbackUserNameClaim の値と使用される接頭辞。fallbackUserNameClaim が true で、要求の値が存在する場合のみ有効です。ユーザー名とクライアント ID を同じユーザー ID 領域にマッピングすると、名前の競合を防ぐことができ便利です。

string

groupsClaim

認証中にユーザーのグループ抽出に使用される JSONPath クエリー。抽出したグループは、カスタムオーソライザーで使用できます。デフォルトでは、グループは抽出されません。

string

groupsClaimDelimiter

グループの解析時に JSON 配列ではなく単一の文字列の値として抽出された場合に使用される区切り文字。デフォルト値は ',' (コンマ) です。

string

httpRetries

最初の HTTP リクエストが失敗した場合に試行する最大再試行回数。設定されていない場合、デフォルトでは再試行は行われません。

integer

httpRetryPauseMs

失敗した HTTP リクエストを再試行するまでの一時停止。設定されていない場合、デフォルトでは一時停止せず、ただちにリクエストを繰り返します。

integer

introspectionEndpointUri

不透明な JWT 以外のトークンの検証に使用できるトークンイントロスペクションエンドポイントの URI。

string

jwksEndpointUri

ローカルの JWT 検証に使用できる JWKS 証明書エンドポイントの URI。

string

jwksExpirySeconds

JWKS 証明書が有効とみなされる頻度を設定します。期限切れの間隔は、jwksRefreshSeconds で指定される更新間隔よりも 60 秒以上長くする必要があります。デフォルトは 360 秒です。

integer

jwksIgnoreKeyUse

JWKS エンドポイント応答の key 宣言の use 属性を無視するフラグ。デフォルト値は false です。

boolean

jwksMinRefreshPauseSeconds

連続する 2 回の更新の間に適用される最小の一時停止期間。不明な署名鍵が検出されると、更新は即座にスケジュールされますが、この最小一時停止の期間は待機します。デフォルトは 1 秒です。

integer

jwksRefreshSeconds

JWKS 証明書が更新される頻度を設定します。更新間隔は、jwksExpirySeconds で指定される期限切れの間隔よりも 60 秒以上短くする必要があります。デフォルトは 300 秒です。

integer

maxSecondsWithoutReauthentication

再認証せずに認証されたセッションが有効な状態でいられる最大期間 (秒単位)。これにより、Apache Kafka の再認証機能が有効になり、アクセストークンの有効期限が切れるとセッションが期限切れになります。最大期間の前または最大期間の到達時にアクセストークンが期限切れになると、クライアントは再認証する必要があります。そうでないと、サーバーは接続を切断します。デフォルトでは設定されません。アクセストークンが期限切れになっても認証されたセッションは期限切れになりません。このオプションは、SASL_OAUTHBEARER 認証メカニズムにのみ適用されます (enableOauthBearertrue の場合)。

integer

readTimeoutSeconds

承認サーバーへの接続時の読み取りタイムアウト (秒単位)。設定しない場合は、実際の読み取りタイムアウトは 60 秒になります。

integer

tlsTrustedCertificates

OAuth サーバーへの TLS 接続の信頼済み証明書。

CertSecretSource array

tokenEndpointUri

クライアントが clientIdsecret で認証する際に、SASL_PLAIN メカニズムで使用する Token Endpoint の URI です。設定されている場合、クライアントは SASL_PLAIN で認証を行うことができます。usernameclientId に、password を clientsecret に設定するか、username をアカウントのユーザー名に、password$accessToken: の接頭辞が付いたアクセストークンに設定します。このオプションが設定されていない場合、password は常にアクセストークンとして (接頭辞なしで) 解釈され、username はアカウントのユーザー名として解釈されます (いわゆる no-client-credentials モードです)。

string

type

oauth でなければなりません。

string

userInfoEndpointUri

Introspection Endpoint がユーザー ID に使用できる情報を返さない場合に、ユーザー ID 取得のフォールバックとして使用する User Info Endpoint の URL。

string

userNameClaim

ユーザー ID の取得に使用される JWT 認証トークン、Introspection Endpoint の応答、または User Info Endpoint の応答からの要求の名前。デフォルトは sub です。

string

validIssuerUri

認証に使用されるトークン発行者の URI。

string

validTokenType

Introspection Endpoint によって返される token_type 属性の有効な値。デフォルト値はなく、デフォルトではチェックされません。

string

6.2.8. GenericSecretSource スキーマ参照

KafkaClientAuthenticationOAuthKafkaListenerAuthenticationCustomKafkaListenerAuthenticationOAuth で使用

プロパティー説明

key

OpenShift シークレットでシークレット値が保存されるキー。

string

secretName

シークレット値が含まれる OpenShift シークレットの名前。

string

6.2.9. CertSecretSource スキーマ参照

ClientTlsKafkaAuthorizationKeycloakKafkaAuthorizationOpaKafkaClientAuthenticationOAuthKafkaListenerAuthenticationOAuth で使用

プロパティー説明

certificate

Secret のファイル証明書の名前。

string

secretName

証明書が含まれる Secret の名前。

string

6.2.10. KafkaListenerAuthenticationCustom スキーマ参照

GenericKafkaListener で使用

KafkaListenerAuthenticationCustom スキーマプロパティーの完全リスト

カスタム認証を設定するには、type プロパティーを custom に設定します。

カスタム認証では、kafka でサポートされているあらゆるタイプの認証が使用できます。

カスタム OAuth 認証の設定例

spec:
  kafka:
    config:
      principal.builder.class: SimplePrincipal.class
    listeners:
      - name: oauth-bespoke
        port: 9093
        type: internal
        tls: true
        authentication:
          type: custom
          sasl: true
          listenerConfig:
            oauthbearer.sasl.client.callback.handler.class: client.class
            oauthbearer.sasl.server.callback.handler.class: server.class
            oauthbearer.sasl.login.callback.handler.class: login.class
            oauthbearer.connections.max.reauth.ms: 999999999
            sasl.enabled.mechanisms: oauthbearer
            oauthbearer.sasl.jaas.config: |
              org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
          secrets:
            - name: example

sasl および tls の値を使用して、リスナーにマップするプロトコルを判別するプロトコルマップが生成されます。

  • SASL = True, TLS = True → SASL_SSL
  • SASL = False, TLS = True → SSL
  • SASL = True, TLS = False → SASL_PLAINTEXT
  • SASL = False, TLS = False → PLAINTEXT
6.2.10.1. listenerConfig

listenerConfig を使用して指定されたリスナー設定は、listener.name.<listener_name>-<port> の接頭辞が付けられます。たとえば、sasl.enabled.mechanismslistener.name.<listener_name>-<port>.sasl.enabled.mechanisms になります。

6.2.10.2. secrets

シークレットは、Kafka ブローカーノードのコンテナーの/opt/kafka/custom-authn-secrets/custom-listener-<listener_name>-<port>/<secret_name> にマウントされます。

たとえば、設定例ではマウントされたシークレット (example) は /opt/kafka/custom-authn-secrets/custom-listener-oauth-bespoke-9093/example にあります。

6.2.10.3. プリンシパルビルダー

Kafka クラスター設定でカスタムプリンシパルビルダーを設定できます。ただし、プリンシパルビルダーは以下の要件に依存します。

  • 指定されたプリンシパルビルダークラスがイメージに存在している。独自に構築する に、すでに存在しているかどうかを確認します。必要なクラスで AMQ Streams イメージを再構築する必要があります。
  • 他のリスナーが oauth タイプ認証をしていない。これは、OAuth リスナーが独自のプリンシパルビルダーを Kafka 設定に追加するためです。
  • 指定のプリンシパルビルダーは AMQ Streams と互換性がある。

AMQ Streams は Kafka クラスターの管理に使用するため、カスタムプリンシパルビルダーは認証用のピア証明書をサポートする必要があります。

注記

Kafka のデフォルトのプリンシパルビルダークラス は、ピア証明書の名前を基にしたプリンシパルのビルドをサポートします。カスタムプリンシパルビルダーは、SSL ピア証明書の名前を使用して user タイプのプリンシパルを指定する必要があります。

以下の例は、AMQ Streams の OAuth 要件を満たすカスタムプリンシパルビルダーを示しています。

カスタム OAuth 設定のプリンシパルビルダーの例

public final class CustomKafkaPrincipalBuilder implements KafkaPrincipalBuilder {

    public KafkaPrincipalBuilder() {}

    @Override
    public KafkaPrincipal build(AuthenticationContext context) {
        if (context instanceof SslAuthenticationContext) {
            SSLSession sslSession = ((SslAuthenticationContext) context).session();
            try {
                return new KafkaPrincipal(
                    KafkaPrincipal.USER_TYPE, sslSession.getPeerPrincipal().getName());
            } catch (SSLPeerUnverifiedException e) {
                throw new IllegalArgumentException("Cannot use an unverified peer for authentication", e);
            }
        }

        // Create your own KafkaPrincipal here
        ...
    }
}

6.2.10.4. KafkaListenerAuthenticationCustom スキーマ参照

type プロパティーは KafkaListenerAuthenticationCustom タイプと KafkaListenerAuthenticationTls, KafkaListenerAuthenticationScramSha512, KafkaListenerAuthenticationOAuth とを区別して使用するための識別子です。KafkaListenerAuthenticationCustom タイプには custom の値が必要です。

プロパティー説明

listenerConfig

特定のリスナーに使用される設定。すべての値の前に listener.name.<listener_name> を付けます。

map

sasl

このリスナーで SASL を有効または無効にします。

boolean

secrets

/opt/kafka/custom-authn-secrets/custom-listener-<listener_name>-<port>/<secret_name> にマウントされるシークレット。

GenericSecretSource アレイ

type

custom である必要があります。

string

6.2.11. GenericKafkaListenerConfiguration スキーマ参照

GenericKafkaListener で使用

GenericKafkaListenerConfiguration スキーマプロパティーの全リスト

Kafka リスナーの設定。

6.2.11.1. brokerCertChainAndKey

brokerCertChainAndKey プロパティーは、TLS 暗号化が有効になっているリスナーでのみ使用されます。プロパティーを使用して、独自の Kafka リスナー証明書を提供できます。

TLS 暗号化が有効な loadbalancer 外部リスナーの設定例

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      brokerCertChainAndKey:
        secretName: my-secret
        certificate: my-listener-certificate.crt
        key: my-listener-key.key
# ...

6.2.11.2. externalTrafficPolicy

externalTrafficPolicy プロパティーは、loadbalancernodeport のリスナーで使用されます。OpenShift の外で Kafka を公開する場合は、Local または Cluster を選択できます。Local は他のノードへのホップを避け、クライアントの IP を保持しますが、Cluster はそのどちらでもありません。デフォルトは Cluster です。

6.2.11.3. loadBalancerSourceRanges

loadBalancerSourceRanges プロパティーは、loadbalancer でのみ使用されます。OpenShift 外部で Kafka を公開する場合、ラベルやアノテーションの他にソースの範囲を使用して、サービスの作成方法をカスタマイズします。

ロードバランサーリスナー向けに設定されたソース範囲の例

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: false
    configuration:
      externalTrafficPolicy: Local
      loadBalancerSourceRanges:
        - 10.0.0.0/8
        - 88.208.76.87/32
      # ...
# ...

6.2.11.4. class

class プロパティーは、ingress リスナーでのみ使用されます。Ingress クラスの設定は class プロパティーで行います。

Ingress クラスの nginx-internal を使用した ingress タイプの外部リスナーの例

listeners:
  #...
  - name: external
    port: 9094
    type: ingress
    tls: true
    configuration:
      class: nginx-internal
    # ...
# ...

6.2.11.5. preferredNodePortAddressType

preferredNodePortAddressType プロパティーは、nodeport リスナーでのみ使用されます。

リスナーの設定で preferredNodePortAddressType プロパティーを使用して、ノードアドレスとしてチェックされる最初のアドレスタイプを指定します。たとえば、デプロイメントに DNS サポートがない場合や、内部 DNS または IP アドレスを介してブローカーを内部でのみ公開する場合、このプロパティーは便利です。該当タイプのアドレスが見つかった場合はそのアドレスが使用されます。アドレスタイプが見つからなかった場合、AMQ Streams は標準の優先順位でタイプの検索を続行します。

  1. ExternalDNS
  2. ExternalIP
  3. Hostname
  4. InternalDNS
  5. InternalIP

優先ノードポートアドレスタイプで設定された外部リスナーの例

listeners:
  #...
  - name: external
    port: 9094
    type: nodeport
    tls: false
    configuration:
      preferredNodePortAddressType: InternalDNS
      # ...
# ...

6.2.11.6. useServiceDnsDomain

useServiceDnsDomain プロパティーは、internal および cluster-ip リスナーでのみ使用されます。クラスターサービスの接尾辞 (通常は .cluster.local) を含む完全修飾 DNS 名を使用するかどうかを定義します。useServiceDnsDomainfalse に設定すると、アドバタイズされるアドレスはサービス接尾辞なしで生成されます。(例:my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc)useServiceDnsDomaintrue に設定すると、アドバタイズされたアドレスはサービスの接尾辞で生成されます。(例:my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc.cluster.local)デフォルトは false です。

サービス DNS ドメインを使用するよう設定された内部リスナーの例

listeners:
  #...
  - name: plain
    port: 9092
    type: internal
    tls: false
    configuration:
      useServiceDnsDomain: true
      # ...
# ...

OpenShift クラスターが .cluster.local とは異なるサービス接尾辞を使用している場合は、Cluster Operator の設定で KUBERNETES_SERVICE_DNS_DOMAIN 環境変数を使用して接尾辞を設定することができます。

6.2.11.7. GenericKafkaListenerConfiguration スキーマプロパティー
プロパティー説明

brokerCertChainAndKey

このリスナーに使用される証明書とプライベートキーのペアを保持する Secret への参照。証明書には、任意でチェーン全体を含めることができます。このフィールドは、TLS による暗号化が有効なリスナーでのみ使用できます。

CertAndKeySecretSource

externalTrafficPolicy

サービスによって外部トラフィックがローカルノードのエンドポイントまたはクラスター全体のエンドポイントにルーティングされるかどうかを指定します。Cluster を指定すると、別のノードへの 2 回目のホップが発生し、クライアントソースの IP が特定しにくくなる可能性があります。Local を指定すると、LoadBalancer および Nodeport タイプのサービスに対して 2 回目のホップが発生しないようにし、クライアントソースの IP を維持します (インフラストラクチャーでサポートされる場合)。指定のない場合、OpenShift は Cluster をデフォルトとして使用します。このフィールドは、loadbalancer または nodeport タイプリスナーとのみ使用できます。

string ([Local、Cluster] のいずれか)

loadBalancerSourceRanges

クライアントがロードバランサータイプのリスナーに接続できる CIDR 形式による範囲 (例: 10.0.0.0/8130.211.204.1/32) の一覧。プラットフォームでサポートされる場合、ロードバランサー経由のトラフィックは指定された CIDR 範囲に制限されます。このフィールドは、ロードバランサータイプのサービスのみに適用され、クラウドプロバイダーがこの機能をサポートしない場合は無視されます。このフィールドは、loadbalancer のリスナーでのみ使用できます。

string array

bootstrap

ブートストラップの設定。

GenericKafkaListenerConfigurationBootstrap

brokers

ブローカーごとの設定。

GenericKafkaListenerConfigurationBroker アレイ

ipFamilyPolicy

サービスによって使用される IP Family Policy を指定します。利用可能なオプションは、SingleStackPreferDualStackRequireDualStack です。SingleStack は単一の IP ファミリー用です。PreferDualStack は、デュアルスタック設定のクラスターでは 2 つの IP ファミリーを、シングルスタック設定のクラスターでは 1 つの IP ファミリーを対象としています。RequireDualStack は、デュアルスタック設定のクラスターに 2 つの IP ファミリーがないと失敗します。指定されていない場合、OpenShift はサービスタイプに基づいてデフォルト値を選択します。OpenShift 1.20 以降で利用できます。

string ([RequireDualStack、SingleStack、PreferDualStack] のいずれか)

ipFamilies

サービスによって使用される IP Families を指定します。利用可能なオプションは、IPv4IPv6 です。指定されていない場合、OpenShift は `ipFamilyPolicy の設定に基づいてデフォルト値を選択します。OpenShift 1.20 以降で利用できます。

string ([IPv6, IPv4] の 1 つ以上) array

createBootstrapService

ブートストラップサービスを作成するかどうか。ブートストラップサービスはデフォルトで作成されます (指定されない場合)。このフィールドは、loadBalancer タイプリスナーと併用できます。

boolean

class

使用するコントローラーを定義する Ingress および LoadBalancer の特定のクラスを設定します。このフィールドは、ingress および loadbalancer タイプのリスナーでのみ使用できます。指定しない場合、デフォルトのコントローラーが使用されます。Ingress リスナーの場合、Ingress リソースで ingressClassName プロパティーを設定します。loadbalancer リスナーの場合は、Service リソースで loadBalancerClass プロパティーを設定します。

string

finalizers

このリスナーに作成された LoadBalancer タイプの Services に設定されるファイナライザーのリストです。プラットフォームでサポートされている場合は、ファイナライザー service.kubernetes.io/load-balancer-cleanup を使用して、外部ロードバランサーがサービスと一緒に削除されるようにします。詳細は、https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#garbage-collecting-load-balancers を参照してください。このフィールドは、loadbalancer タイプのリスナーでのみ使用できます。

string array

maxConnectionCreationRate

このリスナーでいつでも許可される最大接続作成率。制限に達すると、新しい接続はスロットリングされます。

integer

maxConnections

ブローカーのこのリスナーでいつでも許可される最大接続数。制限に達すると、新しい接続はブロックされます。

integer

preferredNodePortAddressType

ノードアドレスとして使用するアドレスタイプを定義します。使用できるタイプ: ExternalDNSExternalIPInternalDNSInternalIPHostnameデフォルトでは、アドレスは以下の順序で使用されます (最初に見つかったアドレスが使用されます):

  • ExternalDNS
  • ExternalIP
  • InternalDNS
  • InternalIP
  • Hostname

このフィールドは、最初にチェックされる優先アドレスタイプの選択に使用されます。このアドレスタイプのアドレスが見つからない場合、他のタイプがデフォルトの順序でチェックされます。このフィールドは、nodeport タイプのリスナーでのみ使用できます。

string ([ExternalDNS、ExternalIP、Hostname、InternalIP、InternalDNS] のいずれか)

useServiceDnsDomain

OpenShift サービス DNS ドメインを使用するべきかどうかを設定します。true に設定すると、生成されるアドレスにはサービスの DNS ドメインの接尾辞が含まれます (デフォルトでは .cluster.local、環境変数 KUBERNETES_SERVICE_DNS_DOMAIN で設定可能です)。デフォルトは false です。このフィールドは、internal および cluster-ip タイプのリスナーでのみ使用できます。

boolean

6.2.12. CertAndKeySecretSource スキーマ参照

GenericKafkaListenerConfigurationKafkaClientAuthenticationTls で使用

プロパティー説明

certificate

Secret のファイル証明書の名前。

string

key

Secret の秘密鍵の名前。

string

secretName

証明書が含まれる Secret の名前。

string

6.2.13. GenericKafkaListenerConfigurationBootstrap スキーマ参照

GenericKafkaListenerConfiguration で使用

GenericKafkaListenerConfigurationBootstrap スキーマプロパティーの全リスト

nodePorthostloadBalancerIPannotations プロパティーに相当するブローカーサービスは、GenericKafkaListenerConfigurationBroker schema で設定されます。

6.2.13.1. alternativeNames

ブートストラップサービスの代替名を指定できます。名前はブローカー証明書に追加され、TLS ホスト名の検証に使用できます。alternativeNames プロパティーは、すべてのタイプのリスナーに適用されます。

ブートストラップアドレスを追加設定した外部 route リスナーの例です。

listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        alternativeNames:
          - example.hostname1
          - example.hostname2
# ...

6.2.13.2. host

host プロパティーは、route リスナーと ingress リスナーで使用され、ブートストラップサービスとパーブロカーサービスで使用されるホスト名を指定します。

Ingress コントローラーが自動的にホスト名を割り当てることはないため、ingress リスナーの設定には host のプロパティー値が必須となります。確実にホスト名が Ingress エンドポイントに解決されるようにしてください。AMQ Streams では、要求されたホストが利用可能で、適切に Ingress エンドポイントにルーティングされることを検証しません。

Ingress リスナーのホスト設定例

listeners:
  #...
  - name: external
    port: 9094
    type: ingress
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        host: broker-0.myingress.com
      - broker: 1
        host: broker-1.myingress.com
      - broker: 2
        host: broker-2.myingress.com
# ...

デフォルトでは、route リスナーのホストは OpenShift によって自動的に割り当てられます。ただし、ホストを指定して、割り当てられたルートをオーバーライドすることができます。

AMQ Streams では、要求されたホストが利用可能であることを検証しません。ホストが使用可能であることを確認する必要があります。

route リスナーのホスト設定例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myrouter.com
      brokers:
      - broker: 0
        host: broker-0.myrouter.com
      - broker: 1
        host: broker-1.myrouter.com
      - broker: 2
        host: broker-2.myrouter.com
# ...

6.2.13.3. nodePort

デフォルトでは、ブートストラップおよびブローカーサービスに使用されるポート番号は OpenShift によって自動的に割り当てられます。nodeport リスナーに割り当てられたノードポートを上書きするには、要求されたポート番号を指定します。

AMQ Streams は要求されたポートの検証を行いません。ポートが使用できることを確認する必要があります。

ノードポートのオーバーライドが設定された外部リスナーの例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: nodeport
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        nodePort: 32100
      brokers:
      - broker: 0
        nodePort: 32000
      - broker: 1
        nodePort: 32001
      - broker: 2
        nodePort: 32002
# ...

6.2.13.4. loadBalancerIP

ロードバランサーの作成時に特定の IP アドレスを要求するには、loadBalancerIP プロパティーを使用します。特定の IP アドレスでロードバランサーを使用する必要がある場合は、このプロパティーを使用します。クラウドプロバイダーがこの機能に対応していない場合、loadBalancerIP フィールドは無視されます。

特定のロードバランサー IP アドレスリクエストのある loadbalancer タイプの外部リスナーの例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        loadBalancerIP: 172.29.3.10
      brokers:
      - broker: 0
        loadBalancerIP: 172.29.3.1
      - broker: 1
        loadBalancerIP: 172.29.3.2
      - broker: 2
        loadBalancerIP: 172.29.3.3
# ...

6.2.13.5. annotations

annotations を使用して、リスナーに関連する OpenShift リソースにアノテーションを追加します。これらのアノテーションを使用すると、自動的に DNS 名をロードバランサーサービスに割り当てる 外部 DNS などの DNS ツールをインストルメント化できます。

annotations を使用した loadbalancer 型の外部リスナーの例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

6.2.13.6. GenericKafkaListenerConfigurationBootstrap スキーマのプロパティー
プロパティー説明

alternativeNames

ブートストラップサービスの追加の代替名。代替名は、TLS 証明書のサブジェクト代替名のリストに追加されます。

string array

host

ブートストラップホスト。このフィールドは、ホスト名を指定するために Ingress リソースまたは Route リソースで使用されます。このフィールドは、route(オプション) または ingress(必須) タイプのリスナーでのみ使用できます。

string

nodePort

ブートストラップサービスのノードポート。このフィールドは、nodeport タイプリスナーでのみ使用できます。

integer

loadBalancerIP

ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが loadBalancerIP の指定をサポートするかどうかによって異なります。このフィールドは、クラウドプロバイダーがこの機能をサポートしていない場合は無視されます。このフィールドは、loadbalancer タイプのリスナーでのみ使用できます。

string

annotations

IngressRouteService のいずれかのリソースに追加されるアノテーション。このフィールドを使用して、外部 DNS などの DNS プロバイダーを設定できます。このフィールドは、loadbalancernodeportrouteingress タイプのリスナーでのみ使用できます。

map

labels

IngressRouteService のいずれかのリソースに追加されるラベル。このフィールドは、loadbalancernodeportrouteingress タイプのリスナーでのみ使用できます。

map

6.2.14. GenericKafkaListenerConfigurationBroker スキーマ参照

GenericKafkaListenerConfiguration で使用

GenericKafkaListenerConfigurationBroker スキーマプロパティーの全リスト

ブートストラップサービスのオーバーライドを設定するGenericKafkaListenerConfigurationBootstrap schemaでは、nodePorthostloadBalancerIPannotations プロパティーの設定例を見ることができます。

ブローカーのアドバタイズされたアドレス

デフォルトでは、AMQ Streams は Kafka クラスターがそのクライアントにアドバタイズするホスト名とポートを自動的に決定しようとします。AMQ Streams が稼働しているインフラストラクチャーでは Kafka にアクセスできる正しいホスト名やポートを提供しない可能性があるため、デフォルトの動作はすべての状況に適しているわけではありません。

ブローカー ID を指定し、リスナーの configuration プロパティーでアドバタイズされたホスト名とポートをカスタマイズすることができます。その後、AMQ Streams では Kafka ブローカーでアドバタイズされたアドレスが自動設定され、ブローカー証明書に追加されるため、TLS ホスト名の検証が使用できるようになります。アドバタイズされたホストおよびポートのオーバーライドは、すべてのタイプのリスナーで利用できます。

アドバタイズされたアドレスのオーバーライドを設定した外部 route リスナーの例

listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      brokers:
      - broker: 0
        advertisedHost: example.hostname.0
        advertisedPort: 12340
      - broker: 1
        advertisedHost: example.hostname.1
        advertisedPort: 12341
      - broker: 2
        advertisedHost: example.hostname.2
        advertisedPort: 12342
# ...

6.2.14.1. GenericKafkaListenerConfigurationBroker スキーマプロパティー
プロパティー説明

broker

Kafka ブローカーの ID (ブローカー識別子)。ブローカー ID は 0 から始まり、ブローカーレプリカの数に対応します。

integer

advertisedHost

ブローカーの advertised.brokers で使用されるホスト名。

string

advertisedPort

ブローカーの advertised.brokers で使用されるポート番号。

integer

host

ブローカーホスト。このフィールドは、ホスト名を指定するために Ingress リソースまたは Route リソースで使用されます。このフィールドは、route(オプション) または ingress(必須) タイプのリスナーでのみ使用できます。

string

nodePort

ブローカーごとのサービスのノードポート。このフィールドは、nodeport タイプリスナーでのみ使用できます。

integer

loadBalancerIP

ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが loadBalancerIP の指定をサポートするかどうかによって異なります。このフィールドは、クラウドプロバイダーがこの機能をサポートしていない場合は無視されます。このフィールドは、loadbalancer タイプのリスナーでのみ使用できます。

string

annotations

Ingress または Service リソースに追加されるアノテーション。このフィールドを使用して、外部 DNS などの DNS プロバイダーを設定できます。このフィールドは、loadbalancernodeportingress タイプのリスナーでのみ使用できます。

map

labels

IngressRouteService のいずれかのリソースに追加されるラベル。このフィールドは、loadbalancernodeportrouteingress タイプのリスナーでのみ使用できます。

map

6.2.15. EphemeralStorage スキーマ参照

JbodStorageKafkaClusterSpecZookeeperClusterSpec で使用

type プロパティーは、EphemeralStorage タイプの使用を、PersistentClaimStorageから区別する識別子です。EphemeralStorage タイプには ephemeral の値が必要です。

プロパティー説明

id

ストレージ ID 番号。これは、'jbod' タイプのストレージで定義されるストレージボリュームのみで必須です。

integer

sizeLimit

type=ephemeral の場合、この EmptyDir ボリュームに必要なローカルストレージの合計容量を定義します (例: 1Gi)。

string

type

ephemeral でなければなりません。

string

6.2.16. PersistentClaimStorage スキーマ参照

JbodStorageKafkaClusterSpecZookeeperClusterSpec で使用

type プロパティーは、PersistentClaimStorage タイプの使用を、EphemeralStorageから区別する識別子です。PersistentClaimStorage タイプには persistent-claim の値が必要です。

プロパティー説明

type

persistent-claim でなければなりません。

string

size

type=persistent-claim の場合、永続ボリューム要求のサイズを定義します (例: 1Gi).。type=persistent-claim の場合には必須です。

string

selector

使用する特定の永続ボリュームを指定します。このようなボリュームを選択するラベルを表す key:value ペアが含まれます。

map

deleteClaim

クラスターのアンデプロイ時に永続ボリューム要求を削除する必要があるかどうかを指定します。

boolean

class

動的ボリュームの割り当てに使用するストレージクラス。

string

id

ストレージ ID 番号。これは、'jbod' タイプのストレージで定義されるストレージボリュームのみで必須です。

integer

overrides

個々のブローカーを上書きします。overrides フィールドでは、異なるブローカーに異なる設定を指定できます。

PersistentClaimStorageOverride array

6.2.17. PersistentClaimStorageOverride スキーマ参照

PersistentClaimStorage で使用

プロパティー説明

class

このブローカーの動的ボリュームの割り当てに使用するストレージクラス。

string

broker

Kafka ブローカーの ID (ブローカー ID)。

integer

6.2.18. JbodStorage スキーマ参照

KafkaClusterSpec で使用

type プロパティーは、JbodStorage タイプの使用を EphemeralStoragePersistentClaimStorage から区別する識別子です。JbodStorage タイプには jbod の値が必要です。

プロパティー説明

type

jbod でなければなりません。

string

volumes

JBOD ディスクアレイを表すストレージオブジェクトとしてのボリュームの一覧。

EphemeralStoragePersistentClaimStorage array

6.2.19. KafkaAuthorizationSimple スキーマ参照

KafkaClusterSpec で使用

KafkaAuthorizationSimple スキーマプロパティーの全リスト

AMQ Streams でのシンプルな認証は、Apache Kafka で提供されているデフォルトの ACL(Access Control Lists) 認証プラグインである AclAuthorizer プラグインを使用します。ACL を使用すると、ユーザーがアクセスできるリソースを細かく定義できます。

Kafka のカスタムリソースに簡易認証を使用するように設定します。authorization セクションの type プロパティーに simple という値を設定し、スーパーユーザーのリストを設定します。

アクセスルールは、ACLRule schema referenceで説明されているように、KafkaUser に対して設定されます。

6.2.19.1. superUsers

スーパーユーザーとして扱われるユーザープリンシパルのリスト。このリストのユーザープリンシパルは、ACL ルールをクエリーしなくても常に許可されます。

簡易承認の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
    # ...

注記

Kafka.spec.kafkaconfig プロパティーにある super.user 設定オプションは無視されます。この代わりに、authorization プロパティーでスーパーユーザーを指定します。詳細は Kafka ブローカーの設定 を参照してください。

6.2.19.2. KafkaAuthorizationSimple スキーマのプロパティー

type プロパティーは、KafkaAuthorizationSimple タイプの使用をKafkaAuthorizationOpaおよびKafkaAuthorizationKeycloakKafkaAuthorizationCustomと区別するための識別子です。KafkaAuthorizationSimple タイプには simple の値が必要です。

プロパティー説明

type

simple でなければなりません。

string

superUsers

スーパーユーザーの一覧。無制限のアクセス権を取得する必要のあるユーザープリンシパルの一覧が含まれなければなりません。

string array

6.2.20. KafkaAuthorizationOpa スキーマ参照

KafkaClusterSpec で使用

KafkaAuthorizationOpa スキーマプロパティーの全リスト

Open Policy Agentの認証を使用するには、authorization セクションの type プロパティーに opa という値を設定し、必要に応じて OPA のプロパティーを設定します。AMQ Streams は、Kafka 承認に Open Policy Agent プラグインをオーソライザーとして使用します。入力データのフォーマットやポリシーの例については、Open Policy Agent plugin for Kafka authorization を参照してください。

6.2.20.1. url

Open Policy Agent サーバーへの接続に使用される URL。URL には、オーソライザーによってクエリーされるポリシーが含まれる必要があります。必須。

6.2.20.2. allowOnError

一時的に利用できない場合など、オーソライザーによる Open Policy Agent へのクエリーが失敗した場合に、デフォルトで Kafka クライアントを許可または拒否するかどうかを定義します。デフォルトは false で、すべてのアクションが拒否されます。

6.2.20.3. initialCacheCapacity

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの初期容量。デフォルトは 5000 です。

6.2.20.4. maximumCacheSize

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの最大容量。デフォルトは 50000 です。

6.2.20.5. expireAfterMs

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、ローカルキャッシュに保持されるレコードの有効期限。キャッシュされた承認決定が Open Policy Agent サーバーからリロードされる頻度を定義します。ミリ秒単位です。デフォルトは 3600000 ミリ秒 (1 時間) です。

6.2.20.6. tlsTrustedCertificates

OPA サーバーへの TLS 接続用の信頼された証明書。

6.2.20.7. superUsers

スーパーユーザーとして扱われるユーザープリンシパルのリスト。このリストのユーザープリンシパルは、Open Policy Agent ポリシーをクエリーしなくても常に許可されます。

Open Policy Agent オーソライザーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: opa
      url: http://opa:8181/v1/data/kafka/allow
      allowOnError: false
      initialCacheCapacity: 1000
      maximumCacheSize: 10000
      expireAfterMs: 60000
      superUsers:
        - CN=fred
        - sam
        - CN=edward
    # ...

6.2.20.8. KafkaAuthorizationOpa スキーマのプロパティー

type プロパティーは、KafkaAuthorizationOpa タイプの使用を KafkaAuthorizationSimpleKafkaAuthorizationKeycloakKafkaAuthorizationCustomと区別するための識別子です。KafkaAuthorizationOpa タイプには opa の値が必要です。

プロパティー説明

type

opa でなければなりません。

string

url

Open Policy Agent サーバーへの接続に使用される URL。URL には、オーソライザーによってクエリーされるポリシーが含まれる必要があります。このオプションは必須です。

string

allowOnError

一時的に利用できない場合など、オーソライザーによる Open Policy Agent へのクエリーが失敗した場合に、デフォルトで Kafka クライアントを許可または拒否するかどうかを定義します。デフォルトは false で、すべてのアクションが拒否されます。

boolean

initialCacheCapacity

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの初期容量。デフォルトは 5000 です。

integer

maximumCacheSize

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの最大容量。デフォルトは 50000 です。

integer

expireAfterMs

すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、ローカルキャッシュに保持されるレコードの有効期限。キャッシュされた承認決定が Open Policy Agent サーバーからリロードされる頻度を定義します。ミリ秒単位です。デフォルトは 3600000 です。

integer

tlsTrustedCertificates

OPA サーバーへの TLS 接続用の信頼された証明書。

CertSecretSource array

superUsers

スーパーユーザーのリスト。これは、無制限のアクセス権限を持つユーザープリンシパルのリストです。

string array

enableMetrics

Open Policy Agent オーソライザープラグインでメトリクスを指定するかどうかを定義します。デフォルトは false です。

boolean

6.2.21. KafkaAuthorizationKeycloak スキーマ参照

KafkaClusterSpec で使用

type プロパティーは、KafkaAuthorizationKeycloak タイプの使用をKafkaAuthorizationSimpleKafkaAuthorizationOpaKafkaAuthorizationCustomと区別するための識別子です。KafkaAuthorizationKeycloak タイプには keycloak の値が必要です。

プロパティー説明

type

keycloak でなければなりません。

string

clientId

Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアント ID。

string

tokenEndpointUri

承認サーバートークンエンドポイント URI。

string

tlsTrustedCertificates

OAuth サーバーへの TLS 接続の信頼済み証明書。

CertSecretSource array

disableTlsHostnameVerification

TLS ホスト名の検証を有効または無効にします。デフォルト値は false です。

boolean

delegateToKafkaAcls

Red Hat Single Sign-On の Authorization Services ポリシーにより DENIED となった場合に、承認の決定を 'Simple' オーソライザーに委譲すべきかどうか。デフォルト値は false です。

boolean

grantsRefreshPeriodSeconds

連続する付与 (Grants) 更新実行の間隔 (秒単位)。デフォルト値は 60 です。

integer

grantsRefreshPoolSize

アクティブなセッションの付与 (Grants) の更新に使用するスレッドの数。スレッドが多いほど並列処理多くなるため、ジョブがより早く完了します。ただし、使用するスレッドが多いほど、承認サーバーの負荷が大きくなります。デフォルト値は 5 です。

integer

superUsers

スーパーユーザーの一覧。無制限のアクセス権を取得する必要のあるユーザープリンシパルの一覧が含まれなければなりません。

string array

connectTimeoutSeconds

承認サーバーへの接続時のタイムアウト (秒単位)。設定しない場合は、実際の接続タイムアウトは 60 秒になります。

integer

readTimeoutSeconds

承認サーバーへの接続時の読み取りタイムアウト (秒単位)。設定しない場合は、実際の読み取りタイムアウトは 60 秒になります。

integer

httpRetries

最初の HTTP リクエストが失敗した場合に試行する最大再試行回数。設定されていない場合、デフォルトでは再試行は行われません。

integer

enableMetrics

OAuth メトリックを有効または無効にします。デフォルト値は false です。

boolean

6.2.22. KafkaAuthorizationCustom スキーマリファレンス

KafkaClusterSpec で使用

KafkaAuthorizationCustom スキーマプロパティーの全リスト

AMQ Streams でカスタム認証を使用するには、独自の Authorizer プラグインを設定して、アクセスコントロールリスト (ACLs) を定義します。

ACL を使用すると、ユーザーがアクセスできるリソースを細かく定義できます。

Kafka のカスタムリソースにカスタム認証を使用するように設定します。authorization セクションの type プロパティーに値 custom を設定し、以下のプロパティーを設定します。

重要

カスタムオーソライザーは、org.apache.kafka.server.authorizer.Authorizer インターフェイスを実装し、super.users 設定プロパティーを使用して super.users の設定をサポートする必要があります。

6.2.22.1. authorizerClass

(必須) カスタム ACL をサポートするための org.apache.kafka.server.authorizer.Authorizer インターフェイスを実装した Java クラスです。

6.2.22.2. superUsers

スーパーユーザーとして扱われるユーザープリンシパルのリスト。このリストのユーザープリンシパルは、ACL ルールをクエリーしなくても常に許可されます。

Kafka.spec.kafka.config を使用して、カスタムオーサライザーを初期化するための設定を追加することができます。

Kafka.spec でのカスタム認証設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: custom
      authorizerClass: io.mycompany.CustomAuthorizer
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
    # ...
    config:
      authorization.custom.property1=value1
      authorization.custom.property2=value2
    # ...

Kafka カスタムリソースの設定に加えて、カスタムオーソライザークラスとその依存関係を含む JAR ファイルが Kafka ブローカーのクラスパス上で利用可能である必要があります。

AMQ Streams の Maven ビルドプロセスでは、docker-images/kafka/kafka-thirdparty-libs ディレクトリーの下にある pom.xml ファイルに依存関係として追加することで、生成された Kafka ブローカーコンテナーイメージにカスタムサードパーティーライブラリーを追加する仕組みがあります。ディレクトリーには、Kafka のバージョンごとに異なるフォルダーが含まれています。適切なフォルダーを選択します。pom.xml ファイルを修正する前に、サードパーティーのライブラリーが Maven リポジトリーで利用可能であり、その Maven リポジトリーが AMQ Streams のビルドプロセスからアクセス可能である必要があります。

注記

Kafka.spec.kafkaconfig プロパティーにある super.user 設定オプションは無視されます。この代わりに、authorization プロパティーでスーパーユーザーを指定します。詳細は Kafka ブローカーの設定 を参照してください。

カスタム承認では、oauth 認証を使用して groupsClaim 設定属性を設定する時に JWT トークンから抽出されたグループメンバーシップ情報を利用できます。グループは、以下のように authorize() 呼び出し中に OAuthKafkaPrincipal オブジェクトで利用できます。

    public List<AuthorizationResult> authorize(AuthorizableRequestContext requestContext, List<Action> actions) {

        KafkaPrincipal principal = requestContext.principal();
        if (principal instanceof OAuthKafkaPrincipal) {
            OAuthKafkaPrincipal p = (OAuthKafkaPrincipal) principal;

            for (String group: p.getGroups()) {
                System.out.println("Group: " + group);
            }
        }
    }
6.2.22.3. KafkaAuthorizationCustom スキーマのプロパティー

type プロパティーは、KafkaAuthorizationCustom タイプの使用を KafkaAuthorizationSimpleKafkaAuthorizationOpaKafkaAuthorizationKeycloakと区別する識別子です。タイプ KafkaAuthorizationCustom の値が custom である必要があります。

プロパティー説明

type

custom である必要があります。

string

authorizerClass

認証実装クラス。クラスパスで使用できる必要があります。

string

superUsers

スーパーユーザーのリスト。これは、無制限のアクセス権限を持つユーザープリンシパルです。

string array

supportsAdminApi

カスタムオーソライザーが、Kafka Admin API を使用して ACL を管理するための API をサポートしているかどうかを示します。デフォルトは false です。

boolean

6.2.23. Rack スキーマ参照

使用先: KafkaBridgeSpecKafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2Spec

Rack スキーマプロパティーの全リスト

rack オプションは、ラックの認識を設定します。ラックは、アベイラビリティーゾーン、データセンター、またはデータセンターの実際のラックを表すことができます。rackの設定は、topologyKey で行います。topologyKey は、OpenShift ノード上のラベルを識別するもので、その値にはトポロジーの名前が含まれています。このようなラベルの例としては、topology.kubernetes.io/zone(古い OpenShift バージョンでは failure-domain.beta.kubernetes.io/zone) があり、これには OpenShift ノードが実行されているアベイラビリティゾーンの名前が含まれています。Kafka クラスターが実行するラックを認識するように設定し、パーティションレプリカを異なるラックに分散したり、最も近いレプリカからのメッセージの消費したりするなどの追加機能を有効にできます。

OpenShift ノードラベルの詳細は、Well-Known Labels, Annotations and Taints を参照してください。ノードがデプロイされたゾーンやラックを表すノードラベルについては、OpenShift 管理者に相談します。

6.2.23.1. ラック間でのパーティションレプリカの分散

ラックアウェアネスを設定すると、AMQ Streams は各 Kafka ブローカーの broker.rack 設定を行います。broker.rack の 設定では、各ブローカにラック ID を割り当てます。broker.rack を設定すると、Kafka ブローカーはパーティションレプリカをできるだけ多くの異なるラックに分散して配置します。レプリカが複数のラックに分散されている場合、複数のレプリカが同時に失敗する可能性は、同じラックにある場合よりも低くなります。レプリカを分散すると回復性が向上し、可用性と信頼性にとっても重要です。Kafka でラックアウェアネスを有効にするには、以下の例のように、Kafka のカスタムリソースの .spec.kafka セクションに rack オプションを追加します。

Kafka の rack 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    # ...

注記

Pod が削除または再起動すると、ブローカーが実行されているラックは、変更されることがあります。その結果、異なるラックで実行しているレプリカが、同じラックを共有する可能性があります。RackAwareGoal で Cruise Control と KafkaRebalance リソースを使用して、レプリカが異なるラックに分散していることを確認します。

Kafka カスタムリソースでラックアウェアネスが有効になっている場合、AMQ Streams は自動的に OpenShift の preferredDuringSchedulingIgnoredDuringExecution アフィニティールールを追加して、Kafka ブローカーを異なるラックに分散させます。ただし、優先 ルールは、ブローカーが分散されることを保証しません。OpenShift と Kafka の設定に応じて、affinity ルールを追加したり、ZooKeeper と Kafka の両方に topologySpreadConstraints を設定したりして、できるだけ多くのラックにノードが適切に分散されるようにしてください。詳細は、「Pod スケジューリングの設定」 を参照してください。

6.2.23.2. 最も近いレプリカからのメッセージの消費

ラックアウェアネスをコンシューマーで使用して、最も近いレプリカからデータを取得することもできます。これは、Kafka クラスターが複数のデータセンターにまたがる場合に、ネットワークの負荷を軽減するのに役立ちます。また、パブリッククラウドで Kafka を実行する場合にコストを削減することもできます。ただし、レイテンシーが増加する可能性があります。

最も近いレプリカから利用するためには、Kafka クラスターでラックアウェアが設定されており、RackAwareReplicaSelector が有効になっている必要があります。レプリカセレクタープラグインは、クライアントが最も近いレプリカから消費できるようにするロジックを提供します。デフォルトの実装では、LeaderSelector を使用して、常にクライアントのリーダーレプリカを選択します。replica.selector.classRackAwareReplicaSelector を指定すると、デフォルトの実装から切り替わります。

レプリカ対応セレクターを有効にした rack 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    config:
      # ...
      replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
    # ...

Kafka ブローカーの設定に加えて、コンシューマーに client.rack オプションを指定する必要があります。client.rack オプションには、コンシューマーが稼動しているrack IDを指定する必要があります。RackAwareReplicaSelector は、マッチングした broker.rackclient.rackID を関連付けて、最も近いレプリカを見つけ、そこからデータを取得します。同じラック内に複数のレプリカがある場合、RackAwareReplicaSelector は常に最新のレプリカを選択します。ラック ID が指定されていない場合や、同じラック ID を持つレプリカが見つからない場合は、リーダーレプリカにフォールバックします。

図6.1 同じアベイラビリティーゾーンのレプリカから消費するクライアントの例

同じアベイラビリティーゾーン内のレプリカから消費されます。

コネクターが最も近いレプリカからのメッセージを消費するように、Kafka Connect、MirrorMaker 2、および Kafka Bridge を設定することもできます。KafkaConnectKafkaMirrorMaker2、および KafkaBridge カスタムリソースでラック認識を有効にします。この設定ではアフィニティールールは設定されませんが、affinity または topologySpreadConstraints を設定することもできます。詳細は、「Pod スケジューリングの設定」 を参照してください。

AMQ Streams を使用して Kafka Connect を展開する場合、KafkaConnect カスタムリソースの rack セクションを使用して、client.rack オプションを自動的に設定することができます。

Kafka Connect の rack 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
# ...
spec:
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone
  # ...

AMQ Streams を使用して MirrorMaker 2 を展開する場合、KafkaMirrorMaker2 カスタムリソースの rack セクションを使用して、client.rack オプションを自動的に設定できます。

MirrorMaker 2 の rack 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
# ...
spec:
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone
  # ...

AMQ Streams を使用して Kafka Bridge をデプロイする場合、KafkaBridge カスタムリソースの rack セクションを使用して、client.rack オプションを自動的に設定することができます。

Kafka Bridge の rack 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
# ...
spec:
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone
  # ...

6.2.23.3. Rack スキーマのプロパティー
プロパティー説明

topologyKey

OpenShift クラスターノードに割り当てられたラベルに一致するキー。ラベルの値は、ブローカーの broker.rack 設定、および Kafka Connect または MirrorMaker 2 の client.rack 設定を設定するために使用されます。

string

6.2.24. Probe スキーマ参照

CruiseControlSpecEntityTopicOperatorSpecEntityUserOperatorSpecKafkaBridgeSpecKafkaClusterSpecKafkaConnectSpecKafkaExporterSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpecTlsSidecarZookeeperClusterSpec で使用

プロパティー説明

failureThreshold

正常に実行された後に失敗とみなされるプローブの連続失敗回数の最小値。デフォルトは 3 です。最小値は 1 です。

integer

initialDelaySeconds

最初に健全性をチェックするまでの初期の遅延。デフォルトは 15 秒です。最小値は 0 です。

integer

periodSeconds

プローブを実行する頻度 (秒単位)。デフォルトは 10 秒です。最小値は 1 です。

integer

successThreshold

失敗後に、プローブが正常とみなされるための最小の連続成功回数。デフォルトは 1 です。liveness は 1 でなければなりません。最小値は 1 です。

integer

timeoutSeconds

ヘルスチェック試行のタイムアウト。デフォルトは 5 秒です。最小値は 1 です。

integer

6.2.25. JvmOptions スキーマ参照

CruiseControlSpecEntityTopicOperatorSpecEntityUserOperatorSpecKafkaBridgeSpecKafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpecZookeeperClusterSpec で使用

プロパティー説明

-XX

JVM への -XX オプションのマップ。

map

-Xms

JVM への -Xms オプション。

string

-Xmx

JVM への -Xmx オプション。

string

gcLoggingEnabled

ガベージコレクションのロギングが有効かどうかを指定します。デフォルトは false です。

boolean

javaSystemProperties

-D オプションを使用して、JVM に渡される追加のシステムプロパティーのマップ。

SystemProperty array

6.2.26. SystemProperty スキーマ参照

JvmOptions で使用

プロパティー説明

name

システムプロパティー名。

string

value

システムプロパティーの値。

string

6.2.27. KafkaJmxOptions スキーマ参照

KafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2SpecZookeeperClusterSpec で使用

KafkaJmxOptions スキーマプロパティーの全リスト

JMX 接続オプションを設定します。

ポート 9999 に接続して、Kafka ブローカー、ZooKeeper ノード、Kafka Connect、および MirrorMaker 2 から JMX メトリックを取得します。パスワードで保護された JMX ポート、または保護されていない JMX ポートを設定するには、jmxOptions プロパティーを使用します。パスワードで保護すると、未許可の Pod によるポートへの不正アクセスを防ぐことができます。

その後、コンポーネントに関するメトリクスを取得できます。

たとえば、Kafka ブローカーごとに、クライアントからのバイト/秒の使用度データや、ブローカーのネットワークの要求レートを取得することができます。

JMX ポートのセキュリティーを有効にするには、authentication フィールドの type パラメーターを password に設定します。

Kafka ブローカーと ZooKeeper ノード用のパスワードで保護された JMX 設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    # ...
  zookeeper:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    #...

次に、対応するブローカーを指定して、Pod をクラスターにデプロイし、ヘッドレスサービスを使用して JMX メトリクスを取得できます。

たとえば、ブローカー 0 から JMX メトリクスを取得するには、以下を指定します。

"CLUSTER-NAME-kafka-0.CLUSTER-NAME-kafka-brokers"

CLUSTER-NAME-kafka-0 はブローカー Pod の名前、CLUSTER-NAME-kafka-brokers はブローカー Pod の IP を返すヘッドレスサービスの名前です。

JMX ポートがセキュアである場合、Pod のデプロイメントで JMX Secret からユーザー名とパスワードを参照すると、そのユーザー名とパスワードを取得できます。

保護されていない JMX ポートの場合は、空のオブジェクト {} を使用して、ヘッドレスサービスの JMX ポートを開きます。保護されたポートと同じ方法で Pod をデプロイし、メトリクスを取得できますが、この場合はどの Pod も JMX ポートから読み取ることができます。

Kafka ブローカーと ZooKeeper ノードのオープンポート JMX 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions: {}
    # ...
  zookeeper:
    # ...
    jmxOptions: {}
    # ...

関連情報

6.2.27.1. KafkaJmxOptions スキーマプロパティー
プロパティー説明

authentication

JMX ポートに接続するための認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[password] の 1 つでなければなりません。

KafkaJmxAuthenticationPassword

6.2.28. KafkaJmxAuthenticationPassword スキーマ参照

KafkaJmxOptions で使用

type プロパティーは、KafkaJmxAuthenticationPassword タイプの使用と、今後追加される可能性のある他のサブタイプとを区別するための識別情報です。KafkaJmxAuthenticationPassword タイプには password の値が必要です。

プロパティー説明

type

password でなければなりません。

string

6.2.29. JmxPrometheusExporterMetrics スキーマ参照

CruiseControlSpecKafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpecZookeeperClusterSpec で使用

type プロパティーは、JmxPrometheusExporterMetrics タイプの使用と、将来追加される可能性のある他のサブタイプとを区別する識別子です。JmxPrometheusExporterMetrics タイプの値 jmxPrometheusExporter を持つ必要があります。

プロパティー説明

type

jmxPrometheusExporter でなければなりません。

string

valueFrom

Prometheus JMX Exporter 設定が保存される ConfigMap エントリー。この設定の構造の詳細は、 Prometheus JMXExporterを参照してください。

ExternalConfigurationReference

6.2.30. ExternalConfigurationReference のスキーマ参照

ExternalLoggingJmxPrometheusExporterMetrics で使用

プロパティー説明

configMapKeyRef

設定が含まれる ConfigMap のキーへの参照。詳細は、core/v1 configmapkeyselector の外部ドキュメント を参照してください。

ConfigMapKeySelector

6.2.31. InlineLogging スキーマ参照

CruiseControlSpecEntityTopicOperatorSpecEntityUserOperatorSpecKafkaBridgeSpecKafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpecZookeeperClusterSpec で使用

type プロパティーは、InlineLogging タイプの使用と、ExternalLogging.を区別するための識別子です。InlineLogging タイプには inline の値が必要です。

プロパティー説明

type

inline でなければなりません。

string

loggers

ロガー名からロガーレベルへのマップ。

map

6.2.32. ExternalLogging スキーマ参照

CruiseControlSpecEntityTopicOperatorSpecEntityUserOperatorSpecKafkaBridgeSpecKafkaClusterSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpecZookeeperClusterSpec で使用

type プロパティーは、ExternalLogging タイプの使用を、InlineLoggingと区別するための識別子です。ExternalLogging タイプには external の値が必要です。

プロパティー説明

type

external でなければなりません。

string

valueFrom

ロギング設定が保存される ConfigMap エントリーです。

ExternalConfigurationReference

6.2.33. KafkaClusterTemplate スキーマ参照

KafkaClusterSpec で使用

プロパティー説明

statefulset

Kafka StatefulSet のテンプレート。

StatefulSetTemplate

Pod

Kafka Pod のテンプレート。

PodTemplate

bootstrapService

Kafka ブートストラップ Service のテンプレート。

InternalServiceTemplate

brokersService

Kafka ブローカー Service のテンプレート。

InternalServiceTemplate

externalBootstrapService

Kafka 外部ブートストラップ Service のテンプレート。

ResourceTemplate

perPodService

OpenShift の外部からアクセスするために使用される Pod ごとの Kafka Services のテンプレート。

ResourceTemplate

externalBootstrapRoute

Kafka 外部ブートストラップ Route のテンプレート。

ResourceTemplate

perPodRoute

OpenShift の外部からアクセスするために使用される Kafka の Pod ごとの Routes のテンプレート。

ResourceTemplate

externalBootstrapIngress

Kafka 外部ブートストラップ Ingress のテンプレート。

ResourceTemplate

perPodIngress

OpenShift の外部からアクセスするために使用される Kafka の Pod ごとの Ingress のテンプレート。

ResourceTemplate

persistentVolumeClaim

すべての Kafka PersistentVolumeClaims のテンプレート。

ResourceTemplate

podDisruptionBudget

Kafka PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

kafkaContainer

Kafka ブローカーコンテナーのテンプレート。

ContainerTemplate

initContainer

Kafka init コンテナーのテンプレート。

ContainerTemplate

clusterCaCert

Kafka Cluster 証明書の公開鍵が含まれる Secret のテンプレート。

ResourceTemplate

serviceAccount

Kafka サービスアカウントのテンプレート。

ResourceTemplate

jmxSecret

Kafka Cluster JMX 認証の Secret のテンプレートです。

ResourceTemplate

clusterRoleBinding

Kafka ClusterRoleBinding のテンプレート。

ResourceTemplate

podSet

Kafka StrimziPodSet リソースのテンプレート。

ResourceTemplate

6.2.34. StatefulSetTemplate スキーマ参照

KafkaClusterTemplateZookeeperClusterTemplate で使用

プロパティー説明

metadata

リソースに適用済みのメタデータ。

MetadataTemplate

podManagementPolicy

この StatefulSet に使用される PodManagementPolicy。有効な値は Parallel および OrderedReady です。デフォルトは Parallel です。

string ([OrderedReady、Parallel] のいずれか)

6.2.35. MetadataTemplate スキーマ参照

BuildConfigTemplateDeploymentTemplateInternalServiceTemplatePodDisruptionBudgetTemplatePodTemplateResourceTemplateStatefulSetTemplate で使用

MetadataTemplate スキーマプロパティーの全リスト

Labels および Annotations は、リソースの識別および整理に使用され、metadata プロパティーで設定されます。

以下に例を示します。

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
        label2: value2
      annotations:
        annotation1: value1
        annotation2: value2
# ...

labels および annotations フィールドには、予約された文字列 strimzi.io が含まれないすべてのラベルやアノテーションを含めることができます。strimzi.io が含まれるラベルやアノテーションは、内部で AMQ Streams によって使用され、設定することはできません。

6.2.35.1. MetadataTemplate スキーマのプロパティー
プロパティー説明

labels

リソーステンプレートに追加されたラベル。StatefulSetsDeploymentsPodsServices などの異なるリソースに適用できます。

map

annotations

リソーステンプレートに追加されたアノテーション。StatefulSetsDeploymentsPodsServices などの異なるリソースに適用できます。

map

6.2.36. PodTemplate スキーマ参照

CruiseControlTemplateEntityOperatorTemplateKafkaBridgeTemplateKafkaClusterTemplateKafkaConnectTemplateKafkaExporterTemplateKafkaMirrorMakerTemplateZookeeperClusterTemplate で使用

PodTemplate スキーマプロパティーの全リスト

Kafka Pod のテンプレートを設定します。

PodTemplate の設定例

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
      annotations:
        anno1: value1
    imagePullSecrets:
      - name: my-docker-credentials
    securityContext:
      runAsUser: 1000001
      fsGroup: 0
    terminationGracePeriodSeconds: 120
# ...

6.2.36.1. hostAliases

hostAliases プロパティーを使用して、Pod の /etc/hosts ファイルに注入されるホストと IP アドレスのリストを指定します。

この設定は特に、クラスター外部の接続がユーザーによっても要求される場合に Kafka Connect または MirrorMaker で役立ちます。

hostAliases の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
#...
spec:
  # ...
  template:
    pod:
      hostAliases:
      - ip: "192.168.1.86"
        hostnames:
        - "my-host-1"
        - "my-host-2"
      #...

6.2.36.2. PodTemplate スキーマのプロパティー
プロパティー説明

metadata

リソースに適用済みのメタデータ。

MetadataTemplate

imagePullSecrets

この Pod で使用されるイメージのプルに使用する同じ namespace のシークレットへの参照の一覧です。Cluster Operator の環境変数 STRIMZI_IMAGE_PULL_SECRETSimagePullSecrets オプションが指定されている場合、imagePullSecrets 変数のみが使用され、STRIMZI_IMAGE_PULL_SECRETS 変数は無視されます。詳細は、core/v1 localobjectreference の外部ドキュメント を参照してください。

LocalObjectReference アレイ

securityContext

Pod レベルのセキュリティー属性と共通のコンテナー設定を設定します。詳細は、core/v1 podsecuritycontext の外部ドキュメント を参照してください。

PodSecurityContext

terminationGracePeriodSeconds

猶予期間とは、Pod で実行されているプロセスに終了シグナルが送信されてから、kill シグナルでプロセスを強制的に終了するまでの期間 (秒単位) です。この値は、プロセスの予想されるクリーンアップ時間よりも長く設定します。値は負の値ではない整数にする必要があります。値をゼロにすると、即座に削除されます。非常に大型な Kafka クラスターの場合は、正常終了期間を延長し、Kafka ブローカーの終了前に作業を別のブローカーに転送する時間を十分確保する必要があることがあります。デフォルトは 30 秒です。

integer

affinity

Pod のアフィニティールール。詳細は、core/v1 affinity の外部ドキュメント を参照してください。

Affinity

tolerations

Pod の許容 (Toleration)。詳細は、core/v1 toleration の外部ドキュメント を参照してください。

toleration アレイ

priorityClassName

優先順位を Pod に割り当てるために使用される優先順位クラス (Priority Class) の名前。Priority Class (優先順位クラス) の詳細は、Pod Priority and Preemption を参照してください。

string

schedulerName

この Pod のディスパッチに使用されるスケジューラーの名前。指定されていない場合、デフォルトのスケジューラーが使用されます。

string

hostAliases

Pod の HostAliases。HostAliases は、指定された場合に Pod の hosts ファイルに注入されるホストおよび IP のオプションのリストです。詳細は、external documentation for core/v1 hostalias を参照してください。

HostAlias アレイ

tmpDirSizeLimit

一時 EmptyDir ボリューム (/tmp) に必要なローカルストレージの合計量 (例: 1Gi) を定義します。デフォルト値は 5Mi です。

string

enableServiceLinks

サービスについての情報を Pod の環境変数に注入するかどうかを示します。

boolean

topologySpreadConstraints

Pod のトポロジー分散制約。詳細は、core/v1 topologyspreadconstraint の外部ドキュメント を参照してください。

TopologySpreadConstraint 配列

6.2.37. InternalServiceTemplate のスキーマ参照

CruiseControlTemplateKafkaBridgeTemplateKafkaClusterTemplateKafkaConnectTemplateZookeeperClusterTemplate で使用

プロパティー説明

metadata

リソースに適用済みのメタデータ。

MetadataTemplate

ipFamilyPolicy

サービスによって使用される IP Family Policy を指定します。利用可能なオプションは、SingleStackPreferDualStackRequireDualStack です。SingleStack は単一の IP ファミリー用です。PreferDualStack は、デュアルスタック設定のクラスターでは 2 つの IP ファミリーを、シングルスタック設定のクラスターでは 1 つの IP ファミリーを対象としています。RequireDualStack は、デュアルスタック設定のクラスターに 2 つの IP ファミリーがないと失敗します。指定されていない場合、OpenShift はサービスタイプに基づいてデフォルト値を選択します。OpenShift 1.20 以降で利用できます。

string ([RequireDualStack、SingleStack、PreferDualStack] のいずれか)

ipFamilies

サービスによって使用される IP Families を指定します。利用可能なオプションは、IPv4IPv6 です。指定されていない場合、OpenShift は `ipFamilyPolicy の設定に基づいてデフォルト値を選択します。OpenShift 1.20 以降で利用できます。

string ([IPv6, IPv4] の 1 つ以上) array

6.2.38. ResourceTemplate スキーマ参照

CruiseControlTemplateEntityOperatorTemplateKafkaBridgeTemplateKafkaClusterTemplateKafkaConnectTemplateKafkaExporterTemplateKafkaMirrorMakerTemplateKafkaUserTemplateZookeeperClusterTemplate で使用

プロパティー説明

metadata

リソースに適用済みのメタデータ。

MetadataTemplate

6.2.39. PodDisruptionBudgetTemplate スキーマ参照

CruiseControlTemplateKafkaBridgeTemplateKafkaClusterTemplateKafkaConnectTemplateKafkaMirrorMakerTemplateZookeeperClusterTemplate で使用

PodDisruptionBudgetTemplate スキーマプロパティーの全リスト

AMQ Streams は、新しい StrimziPodSetStatefulSet、または Deployment ごとに PodDisruptionBudget を作成します。デフォルトでは、Pod の Disruption Budget (停止状態の予算) は単一の Pod を指定時に利用不可能にすることのみ許可します。maxUnavailable プロパティーのデフォルト値を変更して、許容される利用不可能な Pod の数を増やすことができます。

PodDisruptionBudget のテンプレートの一例です。

# ...
template:
  podDisruptionBudget:
    metadata:
      labels:
        key1: label1
        key2: label2
      annotations:
        key1: label1
        key2: label2
    maxUnavailable: 1
# ...

6.2.39.1. PodDisruptionBudgetTemplate スキーマ参照
プロパティー説明

metadata

PodDisruptionBudgetTemplate リソースに適用するメタデータ。

MetadataTemplate

maxUnavailable

自動 Pod エビクションを許可するための利用不可能な Pod の最大数。Pod エビクションは、maxUnavailable の Pod 数またはそれより少ない Pod 数がエビクション後に利用できない場合に許可されます。この値を 0 に設定するとすべての自発的なエビクションを阻止するため、Pod を手動でエビクトする必要があります。デフォルトは 1 です。

integer

6.2.40. ContainerTemplate スキーマ参照

CruiseControlTemplateEntityOperatorTemplateKafkaBridgeTemplateKafkaClusterTemplateKafkaConnectTemplateKafkaExporterTemplateKafkaMirrorMakerTemplateZookeeperClusterTemplate で使用

ContainerTemplate スキーマプロパティーの全リスト

コンテナーのカスタムのセキュリティーコンテキストおよび環境変数を設定できます。

環境変数は、env プロパティーで name および value フィールドのあるオブジェクトのリストとして定義されます。以下の例は、Kafka ブローカーコンテナーに設定された 2 つのカスタム環境変数と 1 つのセキュリティーコンテキストを示しています。

# ...
template:
  kafkaContainer:
    env:
    - name: EXAMPLE_ENV_1
      value: example.env.one
    - name: EXAMPLE_ENV_2
      value: example.env.two
    securityContext:
      runAsUser: 2000
# ...

KAFKA_ で始まる環境変数は AMQ Streams 内部となるため、使用しないようにしてください。AMQ Streams によってすでに使用されているカスタム環境変数を設定すると、その環境変数は無視され、警告がログに記録されます。

6.2.40.1. ContainerTemplate スキーマのプロパティー
プロパティー説明

env

コンテナーに適用する必要のある環境変数。

ContainerEnvVar array

securityContext

コンテナーのセキュリティーコンテキスト。詳細は、core/v1 securitycontext の外部ドキュメント を参照してください。

SecurityContext

6.2.41. ContainerEnvVar スキーマ参照

ContainerTemplate で使用

プロパティー説明

name

環境変数のキー。

string

value

環境変数の値。

string

6.2.42. ZookeeperClusterSpec スキーマ参照

KafkaSpec で使用

ZookeeperClusterSpec スキーマプロパティーの全リスト

ZooKeeper クラスターを設定します。

6.2.42.1. config

config プロパティーを使用して、ZooKeeper のオプションをキーとして設定します。

標準の Apache ZooKeeper 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。

以下に関連する設定オプションは設定できません。

  • セキュリティー (暗号化、認証、および承認)
  • リスナーの設定
  • データディレクトリーの設定
  • ZooKeeper クラスターの設定

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプション以外の、ZooKeeper ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

  • server.
  • dataDir
  • dataLogDir
  • clientPort
  • authProvider
  • quorum.auth
  • requireClientAuthScheme

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。サポートされるその他すべてのオプションは ZooKeeper に渡されます。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。

ZooKeeper の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
      ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      ssl.enabled.protocols: TLSv1.2
      ssl.protocol: TLSv1.2
    # ...

6.2.42.2. logging

ZooKeeper には設定可能なロガーがあります。

  • zookeeper.root.logger

ZooKeeper は、Apachelog4j のロガー実装を使用しています。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  zookeeper:
    # ...
    logging:
      type: inline
      loggers:
        zookeeper.root.logger: "INFO"
    # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  zookeeper:
    # ...
    logging:
      type: external
      valueFrom:
        configMapKeyRef:
          name: customConfigMap
          key: zookeeper-log4j.properties
  # ...

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.42.3. ZookeeperClusterSpec スキーマプロパティー
プロパティー説明

replicas

クラスター内の Pod 数。

integer

image

Pod の Docker イメージ。

string

storage

ストレージの設定 (ディスク)。更新はできません。タイプは、指定のオブジェクト内の storage.type プロパティーの値によって異なり、[ephemeral、persistent-claim] のいずれかでなければなりません。

EphemeralStoragePersistentClaimStorage

config

ZooKeeper ブローカーの設定。次の接頭辞のあるプロパティーは設定できません: server.、 dataDir、dataLogDir、clientPort、authProvider、quorum.auth、requireClientAuthScheme、 snapshot.trust.empty、standaloneEnabled、reconfigEnabled、4lw.commands.whitelist、secureClientPort、ssl、serverCnxnFactory、sslQuorum (次の例外を除く: ssl.protocol、ssl.quorum.protocol、ssl.enabledProtocols、ssl.quorum.enabledProtocols、ssl.ciphersuites、ssl.quorum.ciphersuites、ssl.hostnameVerification、ssl.quorum.hostnameVerification)

map

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

jvmOptions

Pod の JVM オプション。

JvmOptions

jmxOptions

Zookeeper ノードの JMX オプション。

KafkaJmxOptions

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

logging

ZooKeeper のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

template

ZooKeeper クラスターリソースのテンプレート。テンプレートを使用すると、ユーザーは StatefulSetPod、および Service の生成方法を指定できます。

ZookeeperClusterTemplate

6.2.43. ZookeeperClusterTemplate スキーマ参照

ZookeeperClusterSpec で使用

プロパティー説明

statefulset

ZooKeeper StatefulSet のテンプレート。

StatefulSetTemplate

Pod

ZooKeeper Pod のテンプレート。

PodTemplate

clientService

ZooKeeper クライアント Service のテンプレート。

InternalServiceTemplate

nodesService

ZooKeeper ノード Service のテンプレート。

InternalServiceTemplate

persistentVolumeClaim

すべての ZooKeeper PersistentVolumeClaims のテンプレート。

ResourceTemplate

podDisruptionBudget

ZooKeeper PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

zookeeperContainer

ZooKeeper コンテナーのテンプレート。

ContainerTemplate

serviceAccount

ZooKeeper サービスアカウントのテンプレート。

ResourceTemplate

jmxSecret

Zookeeper Cluster JMX 認証の Secret のテンプレート。

ResourceTemplate

podSet

ZooKeeper StrimziPodSet リソースのテンプレート。

ResourceTemplate

6.2.44. EntityOperatorSpec スキーマ参照

KafkaSpec で使用

プロパティー説明

topicOperator

Topic Operator の設定。

EntityTopicOperatorSpec

userOperator

User Operator の設定。

EntityUserOperatorSpec

tlsSidecar

TLS サイドカーの設定。

TlsSidecar

template

Entity Operator リソースのテンプレート。テンプレートを使用すると、ユーザーは DeploymentPod の生成方法を指定できます。

EntityOperatorTemplate

6.2.45. EntityTopicOperatorSpec スキーマ参照

EntityOperatorSpec で使用

EntityTopicOperatorSpec スキーマプロパティーの全リスト

Topic Operator を設定します。

6.2.45.1. logging

Topic Operator には設定可能なロガーがあります。

  • rootLogger.level

Topic Operator では、Apachelog4j2 のロガー実装を使用しています。

Kafka リソース Kafka リソースの entityOperator.topicOperator フィールドの logging プロパティーを使用して、ロガーとロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j2.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
  # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: customConfigMap
            key: topic-operator-log4j2.properties
  # ...

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.45.2. EntityTopicOperatorSpec スキーマプロパティー
プロパティー説明

watchedNamespace

Topic Operator が監視する必要のある namespace。

string

image

Topic Operator に使用するイメージ。

string

reconciliationIntervalSeconds

定期的な調整の間隔。

integer

zookeeperSessionTimeoutSeconds

ZooKeeper セッションのタイムアウト。

integer

startupProbe

Pod の起動チェック。

Probe

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

topicMetadataMaxAttempts

トピックメタデータの取得を試行する回数。

integer

logging

ロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

jvmOptions

Pod の JVM オプション。

JvmOptions

6.2.46. EntityUserOperatorSpec スキーマ参照

EntityOperatorSpec で使用

EntityUserOperatorSpec スキーマプロパティーの全リスト

User Operator を設定します。

6.2.46.1. logging

User Operator には設定可能なロガーがあります。

  • rootLogger.level

User Operator では、Apachelog4j2 のロガー実装を使用しています。

Kafka リソースの entityOperator.userOperator フィールドの logging プロパティーを使用して、ロガーとロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j2.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
  # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: customConfigMap
            key: user-operator-log4j2.properties
   # ...

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.46.2. EntityUserOperatorSpec スキーマプロパティー
プロパティー説明

watchedNamespace

User Operator が監視する必要のある namespace。

string

image

User Operator に使用するイメージ。

string

reconciliationIntervalSeconds

定期的な調整の間隔。

integer

zookeeperSessionTimeoutSeconds

zookeeperSessionTimeoutSeconds プロパティーは非推奨となりました。ZooKeeper は、User Operator で使用されなくなったため、このプロパティーは非推奨となりました。ZooKeeper セッションのタイムアウト。

integer

secretPrefix

KafkaUser 名に追加され、Secret 名として使用される接頭辞。

string

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

logging

ロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

jvmOptions

Pod の JVM オプション。

JvmOptions

6.2.47. TlsSidecar スキーマ参照

CruiseControlSpecEntityOperatorSpec で使用

TlsSidecar スキーマプロパティーの全リスト

Pod で実行されるコンテナーである TLS サイドカーを設定しますが、サポートの目的で提供されます。。AMQ Streams では、TLS サイドカーは TLS を使用して、コンポーネントと ZooKeeper との間の通信を暗号化および復号化します。

TLS サイドカーは Entity Operator で使用されます。

TLS サイドカーは、Kafka.spec.entityOperatortlsSidecar プロパティーを使用して設定されます。

TLS サイドカーは、以下の追加オプションをサポートします。

  • image
  • resources
  • logLevel
  • readinessProbe
  • livenessProbe

resources プロパティーは、TLS サイドカーに割り当てられたメモリーと CPU のリソースを指定します。

image プロパティーは、使用されるコンテナーイメージを設定します。

readinessProbe プロパティーと livenessProbe プロパティーは、TLS サイドカーのhealthcheck プローブを設定します。

logLevel プロパティーは、ロギングレベルを指定します。以下のログレベルがサポートされます。

  • emerg
  • alert
  • crit
  • err
  • warning
  • notice
  • info
  • debug

デフォルト値は notice です。

TLS サイドカーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  entityOperator:
    # ...
    tlsSidecar:
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
    # ...

6.2.47.1. TlsSidecar スキーマのプロパティー
プロパティー説明

image

コンテナーの Docker イメージ。

string

livenessProbe

Pod の liveness チェック。

Probe

logLevel

TLS サイドカーのログレベル。デフォルト値は notice です。

string ([emerg、debug、crit、err、alert、warning、notice、info] のいずれか)

readinessProbe

Pod の readiness チェック。

Probe

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

6.2.48. EntityOperatorTemplate スキーマ参照

EntityOperatorSpec で使用

プロパティー説明

deployment

Entity Operator Deployment のテンプレート。

DeploymentTemplate

Pod

Entity Operator Pod のテンプレート。

PodTemplate

topicOperatorContainer

Entity Topic Operator コンテナーのテンプレート。

ContainerTemplate

userOperatorContainer

Entity User Operator コンテナーのテンプレート。

ContainerTemplate

tlsSidecarContainer

Entity Operator TLS サイドカーコンテナーのテンプレート。

ContainerTemplate

serviceAccount

Entity Operator サービスアカウントのテンプレート。

ResourceTemplate

entityOperatorRole

Entity Operator Role. のテンプレート。

ResourceTemplate

topicOperatorRoleBinding

Entity Topic Operator RoleBinding のテンプレート。

ResourceTemplate

userOperatorRoleBinding

Entity Topic Operator RoleBinding のテンプレート。

ResourceTemplate

6.2.49. DeploymentTemplate スキーマ参照

CruiseControlTemplateEntityOperatorTemplateKafkaBridgeTemplateKafkaConnectTemplateKafkaExporterTemplateKafkaMirrorMakerTemplate で使用

DeploymentTemplate スキーマプロパティーの完全なリスト

deploymentStrategy を使用して、デプロイ設定が変更されたときに古い Pod を新しい Pod に置き換えるために使用される戦略を指定します。

以下のいずれかの値を使用します。

  • RollingUpdate: Pod はダウンタイムなしで再起動されます。
  • Recreate: Pod は、新しい Pod が作成される前に終了されます。

Recreate デプロイメント戦略を使用すると、予備のリソースを必要としないという利点がありますが、欠点はアプリケーションのダウンタイムです。

Recreate に設定されたデプロイメント戦略を示す例。

# ...
template:
  deployment:
    deploymentStrategy: Recreate
# ...

この設定の変更によって、ローリング 更新が発生することはありません。

6.2.49.1. DeploymentTemplate スキーマプロパティー
プロパティー説明

metadata

リソースに適用済みのメタデータ。

MetadataTemplate

deploymentStrategy

デプロイ設定変更のための Pod 交換戦略。有効な値は RollingUpdate および Recreate です。デフォルトは RollingUpdate です。

string ([RollingUpdate、Recreate] のいずれか)

6.2.50. CertificateAuthority スキーマ参照

KafkaSpec で使用

TLS 証明書のクラスター内での使用方法の設定。これは、クラスター内の内部通信に使用される証明書および Kafka.spec.kafka.listeners.tls を介したクライアントアクセスに使用される証明書の両方に適用されます。

プロパティー説明

generateCertificateAuthority

true の場合、認証局の証明書が自動的に生成されます。それ以外の場合は、ユーザーは CA 証明書で Secret を提供する必要があります。デフォルトは true です。

boolean

generateSecretOwnerReference

true の場合、クラスターとクライアントの CA シークレットは、Kafka リソースに設定された ownerReference で設定されます。true の場合に Kafka リソースが削除されると、CA シークレットも削除されます。false の場合は、ownerReference が無効になります。false のときに Kafka リソースが削除されても、CA シークレットは保持され、再利用可能となります。デフォルトは true です。

boolean

validityDays

生成される証明書の有効日数。デフォルトは 365 です。

integer

renewalDays

証明書更新期間の日数。これは、証明書の期限が切れるまでの日数です。この間に、更新アクションを実行することができます。generateCertificateAuthority が true の場合、新しい証明書が生成されます。generateCertificateAuthority が true の場合、保留中の証明書の有効期限に関する追加のロギングが WARN レベルで実行されます。デフォルトは 30 です。

integer

certificateExpirationPolicy

generateCertificateAuthority=true の場合に CA 証明書の有効期限を処理する方法。デフォルトでは、既存の秘密鍵を再度使用して新規の CA 証明書が生成されます。

string ([replace-key、renew-certificate] のいずれか)

6.2.51. CruiseControlSpec スキーマ参照

KafkaSpec で使用

CruiseControlSpec スキーマプロパティーの完全なリスト

Cruise Control クラスターを設定します。

設定オプションは以下に関連しています。

  • ゴールの設定
  • リソース配分目標の容量制限
6.2.51.1. config

config プロパティーを使用して、Cruise Control オプションをキーとして設定します。

AMQ Streams によって直接管理されないプロパティーに限り、標準 Cruise Control 設定の提供が可能です。

設定できない設定オプションは、次のものに関連しています。

  • セキュリティー (暗号化、認証、および承認)
  • Kafka クラスターへの接続
  • クライアント ID の設定
  • ZooKeeper の接続
  • Web サーバー設定
  • 自己修復

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプションを除き、Cruise Control ドキュメント に記載されているオプションを指定および設定できます。禁止されている接頭辞のリストについては、config プロパティーの説明を参照してください。

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。サポートされている他のすべてのオプションは、Cruise Control に渡されます。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。webserver プロパティーを設定して、CORS (Cross-Origin Resource Sharing) を有効にすることもできます。

Cruise Control の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      # Note that `default.goals` (superset) must also include all `hard.goals` (subset)
      default.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
      hard.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal
      cpu.balance.threshold: 1.1
      metadata.max.age.ms: 300000
      send.buffer.bytes: 131072
      webserver.http.cors.enabled: true
      webserver.http.cors.origin: "*"
      webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type"
    # ...

6.2.51.2. Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) は、REST API へのアクセスを制御するための HTTP メカニズムです。制限は、アクセス方法またはクライアントアプリケーションの元の URL に対して行うことができます。configwebserver.http.cors.enabled プロパティーを使用して、Cruise Control で CORS を有効にできます。有効にすると、CORS は、AMQ Streams とは異なる元の URL を持つアプリケーションからの Cruise Control REST API への読み取りアクセスを許可します。これにより、指定されたオリジンからのアプリケーションが GET リクエストを使用して、Cruise Control API を介して Kafka クラスターに関する情報をフェッチできるようになります。たとえば、アプリケーションは、現在のクラスター負荷または最新の最適化提案に関する情報を取得できます。POST リクエストは許可されていません。

注記

Cruise Control で CORS を使用する方法の詳細については、Cruise Control Wiki の REST API を 参照してください。

Cruise Control の CORS の有効化

Kafka.spec.cruiseControl.config で CORS を有効化および設定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      webserver.http.cors.enabled: true 1
      webserver.http.cors.origin: "*" 2
      webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type" 3

    # ...
1
CORS を有効にします。
2
Access-Control-Allow-Origin HTTP 応答ヘッダーの許可されるオリジンを指定します。ワイルドカードを使用するか、単一のオリジンを URL として指定できます。ワイルドカードを使用すると、任意のオリジンからのリクエストに続いてレスポンスが返されます。
3
Access-Control-Expose-Headers HTTP 応答ヘッダーの指定されたヘッダー名を公開します。許可されたオリジンのアプリケーションは、指定されたヘッダーで応答を読み取ることができます。
6.2.51.3. Cruise Control REST API のセキュリティー

Cruise Control REST API は、HTTP 基本認証と SSL で保護されており、Kafka ブローカーの廃止など、破壊的な可能性のある Cruise Control 操作からクラスターを保護します。AMQStreams の Cruise Control は、これらの設定が有効になっている場合にのみ使用することをお勧めします。

ただし、次の Cruise Control 設定を指定することで、これらの設定を無効にすることができます。

  • ビルトイン HTTP Basic 認証を無効にするには、webserver.security.enablefalse に設定します。
  • ビルトイン SSL を無効にするには、webserver.ssl.enablefalse に設定します。

API 承認、認証、および SSL を無効にする Cruise Control の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    config:
      webserver.security.enable: false
      webserver.ssl.enable: false
# ...

6.2.51.4. brokerCapacity

Cruise Control は容量制限を使用して、リソース分散の最適化ゴールが破損しているかどうかを判断します。このタイプには 4 つのゴールがあります。

  • DiskUsageDistributionGoal - ディスク使用量の分布
  • CpuUsageDistributionGoal - CPU 使用量の分布
  • NetworkInboundUsageDistributionGoal - ネットワーク受信使用量の分布
  • NetworkOutboundUsageDistributionGoal - ネットワーク送信使用量の分布

Kafka ブローカーリソースの容量制限は、Kafka.spec.cruiseControlbrokerCapacity プロパティーに指定します。これらはデフォルトで有効になっており、デフォルト値を変更できます。容量制限は、以下のブローカーリソースに設定できます。

  • cpu - ミリコアまたは CPU コアの CPU リソース (デフォルト: 1)
  • inboundNetwork: バイト毎秒単位のインバウンドネットワークスループット (デフォルトは 10000 KiB/s)
  • outboundNetwork: バイト毎秒単位のアウトバウンドネットワークスループット (デフォルトは 10000 KiB/s)

ネットワークスループットの場合、1 秒あたりの標準の OpenShift バイト単位 (K、M、G) またはそれに相当するビバイト (2 の累乗)(Ki、Mi、Gi) の整数値を使用します。

注記

ディスクと CPU の容量制限は AMQ Streams で自動的に生成されるので、設定する必要はありません。CPU ゴールを使用するときに正確なリバランスの提案を保証するために、Kafka.spec.kafka.resources で CPU リクエストを CPU 制限と同じに設定できます。これにより、すべての CPU リソースが事前に予約され、常に利用できます。この設定を使用すると、CPU 目標に基づいてリバランス提案を準備するときに Cruise Control が CPU 使用率を適切に評価できます。Kafka.spec.kafka.resources の CPU 制限と同じ CPU 要求を設定できない場合は、CPU 容量を手動で設定して同じ精度にすることができます。

bibyte 単位での Cruise Control brokerCapacity の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      cpu: "2"
      inboundNetwork: 10000KiB/s
      outboundNetwork: 10000KiB/s
    # ...

6.2.51.5. 容量の上書き

ブローカーは、異種ネットワークまたは CPU リソースを持つノードで実行されている可能性があります。その場合は、ブローカーごとにネットワーク容量と CPU 制限を設定する overrides を指定します。オーバーライドにより、ブローカー間の正確な再調整が保証されます。次のブローカリソースに対してオーバーライド容量制限を設定できます。

  • cpu - ミリコアまたは CPU コアの CPU リソース (デフォルト: 1)
  • inboundNetwork: バイト毎秒単位のインバウンドネットワークスループット (デフォルトは 10000 KiB/s)
  • outboundNetwork: バイト毎秒単位のアウトバウンドネットワークスループット (デフォルトは 10000 KiB/s)

バイバイト単位を使用した Cruise Control 容量オーバーライド設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      cpu: "1"
      inboundNetwork: 10000KiB/s
      outboundNetwork: 10000KiB/s
      overrides:
      - brokers: [0]
        cpu: "2.755"
        inboundNetwork: 20000KiB/s
        outboundNetwork: 20000KiB/s
      - brokers: [1, 2]
        cpu: 3000m
        inboundNetwork: 30000KiB/s
        outboundNetwork: 30000KiB/s

詳細は、BrokerCapacity スキーマリファレンス を参照してください。

6.2.51.6. ログ設定

Cruise Control には独自の設定可能なロガーがあります。

  • rootLogger.level

Cruise Control では Apache log4j2 ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: inline
      loggers:
        rootLogger.level: "INFO"
    # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: external
      valueFrom:
        configMapKeyRef:
          name: customConfigMap
          key: cruise-control-log4j.properties
    # ...

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.51.7. CruiseControlSpec スキーマプロパティー
プロパティー説明

image

Pod の Docker イメージ。

string

tlsSidecar

tlsSidecar プロパティーは廃止されました。TLS サイドカーの設定。

TlsSidecar

resources

Cruise Control コンテナー用に予約された CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

livenessProbe

Cruise Control コンテナーの Pod liveness チェック

Probe

readinessProbe

Cruise Control コンテナーの Pod readiness チェック

Probe

jvmOptions

Cruise Control コンテナーの JVM オプション

JvmOptions

logging

Cruise Control のロギング設定 (Log4j 2)。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

template

Cruise Control のリソースである Deployments および Pods の生成方法を指定するテンプレート。

CruiseControlTemplate

brokerCapacity

Cruise Control の brokerCapacity の設定。

BrokerCapacity

config

Cruise Control の設定。設定オプションの完全リストは、https://github.com/linkedin/cruise-control/wiki/Configurations を参照してください。次の接頭辞を持つプロパティーは設定できません: failed.brokers.zk.path,webserver.http., webserver.api.urlprefix, webserver.session.path, webserver.accesslog., two.step., request.reason.required,metric.reporter.sampler.bootstrap.servers, capacity.config.file, self.healing., ssl., kafka.broker.failure.detection.enable, topic.config.provider.class (例外: ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, webserver.http.cors.enabled, webserver.http.cors.origin, webserver.http.cors.exposeheaders, webserver.security.enable, webserver.ssl.enable).

map

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

6.2.52. CruiseControlTemplate スキーマ参照

CruiseControlSpec で使用

プロパティー説明

deployment

Cruise Control Deployment のテンプレート。

DeploymentTemplate

Pod

Cruise Control Pods のテンプレート。

PodTemplate

apiService

Cruise Control API Service のテンプレート。

InternalServiceTemplate

podDisruptionBudget

Cruise Control PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

cruiseControlContainer

Cruise Control コンテナーのテンプレート。

ContainerTemplate

tlsSidecarContainer

tlsSidecarContainer プロパティーは廃止されました。Cruise Control TLS サイドカーコンテナーのテンプレート。

ContainerTemplate

serviceAccount

Cruise Control サービスアカウントのテンプレート。

ResourceTemplate

6.2.53. BrokerCapacity スキーマー参照

CruiseControlSpec で使用

プロパティー説明

disk

disk プロパティーは非推奨になりました。Cruise Control のディスク容量設定は非推奨になり、無視されています。今後、ディスクのブローカー容量 (バイト単位) で削除される予定です。標準の Open Shift バイト単位 (K、M、G、または T)、それらのビバイト (2 の累乗) に相当するもの (Ki、Mi、Gi、または Ti) の数値、または E 表記の有無にかかわらずバイト値を使用します。例: 100000M、100000Mi、104857600000、または 1e+11。

string

cpuUtilization

cpuUtilization プロパティーは非推奨になりました。Cruise Control の CPU 容量設定は非推奨になり、無視されています。今後、CPU リソースの使用率 (0-100) に対するブローカー容量 (バイト単位) で削除される予定です。

integer

cpu

コアまたはミリコア単位の CPU リソースのブローカー容量。たとえば、1、1.500、1500m などです。有効な CPU リソースユニットの詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu を参照してください。

string

inboundNetwork

インバウンドネットワークスループットのブローカー容量 (バイト/秒)。整数値は、標準の OpenShift バイト単位 (K、M、G) またはそれと同等のビバイト (Ki、Mi、Gi)/秒を使用します。たとえば、10000KiB/s です。

string

outboundNetwork

アウトバウンドネットワークスループットのブローカー容量 (バイト/秒)。整数値は、標準の OpenShift バイト単位 (K、M、G) またはそれと同等のビバイト (Ki、Mi、Gi)/秒を使用します。たとえば、10000KiB/s です。

string

overrides

個々のブローカーを上書きします。overrides プロパティーを使用すると、ブローカーごとに異なる容量設定を指定できます。

BrokerCapacityOverride アレイ

6.2.54. BrokerCapacityOverride スキーマリファレンス

使用先: BrokerCapacity

プロパティー説明

brokers

Kafka ブローカー (ブローカー識別子) のリスト。

整数配列

cpu

コアまたはミリコア単位の CPU リソースのブローカー容量。たとえば、1、1.500、1500m などです。有効な CPU リソースユニットの詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu を参照してください。

string

inboundNetwork

インバウンドネットワークスループットのブローカー容量 (バイト/秒)。整数値は、標準の OpenShift バイト単位 (K、M、G) またはそれと同等のビバイト (Ki、Mi、Gi)/秒を使用します。たとえば、10000KiB/s です。

string

outboundNetwork

アウトバウンドネットワークスループットのブローカー容量 (バイト/秒)。整数値は、標準の OpenShift バイト単位 (K、M、G) またはそれと同等のビバイト (Ki、Mi、Gi)/秒を使用します。たとえば、10000KiB/s です。

string

6.2.55. KafkaExporterSpec スキーマ参照

KafkaSpec で使用

プロパティー説明

image

Pod の Docker イメージ。

string

groupRegex

収集するコンシューマーグループを指定する正規表現。デフォルト値は .* です。

string

topicRegex

収集するトピックを指定する正規表現。デフォルト値は .* です。

string

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

logging

指定の重大度以上のログメッセージのみ。有効なレベル: [info debug、trace]デフォルトのログレベルは info です。

string

enableSaramaLogging

Kafka Exporter によって使用される Go クライアントライブラリーである Sarama ロギングを有効にします。

boolean

template

デプロイメントテンプレートおよび Pod のカスタマイズ。

KafkaExporterTemplate

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

6.2.56. KafkaExporterTemplate スキーマ参照

KafkaExporterSpec で使用

プロパティー説明

deployment

Kafka Exporter Deployment のテンプレート。

DeploymentTemplate

Pod

Kafka Exporter Pod のテンプレート。

PodTemplate

サービス

service プロパティーは非推奨になりました。Kafka Exporter サービスは削除されました。Kafka Exporter Service のテンプレート。

ResourceTemplate

container

Kafka Exporter コンテナーのテンプレート。

ContainerTemplate

serviceAccount

Kafka Exporter サービスアカウントのテンプレート。

ResourceTemplate

6.2.57. KafkaStatus スキーマ参照

Kafka で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

listeners

内部リスナーおよび外部リスナーのアドレス。

ListenerStatus array

clusterId

Kafka クラスター ID。

string

6.2.58. Condition スキーマ参照

使用先: KafkaBridgeStatusKafkaConnectorStatusKafkaConnectStatusKafkaMirrorMaker2StatusKafkaMirrorMakerStatusKafkaRebalanceStatusKafkaStatusKafkaTopicStatusKafkaUserStatus

プロパティー説明

type

リソース内の他の条件と区別するために使用される条件の固有識別子。

string

status

条件のステータス (True、False、または Unknown のいずれか)。

string

lastTransitionTime

タイプの条件がある状態から別の状態へと最後に変更した時間。必須形式は、UTC タイムゾーンの 'yyyy-MM-ddTHH:mm:ssZ' です。

string

reason

条件の最後の遷移の理由 (CamelCase の単一の単語)。

string

message

条件の最後の遷移の詳細を示す、人間が判読できるメッセージ。

string

6.2.59. ListenerStatus スキーマ参照

KafkaStatus で使用

プロパティー説明

type

type プロパティーは非推奨となり、name を使用して設定する必要があります。リスナーの名前。

string

name

リスナーの名前。

string

addresses

このリスナーのアドレス一覧。

ListenerAddress array

bootstrapServers

このリスナーを使用して Kafka クラスターに接続するための host:port ペアのコンマ区切りリスト。

string

certificates

指定のリスナーへの接続時に、サーバーのアイデンティティーを検証するために使用できる TLS 証明書の一覧。tls リスナーと external リスナーに対してのみ設定します。

string array

6.2.60. ListenerAddress スキーマ参照

ListenerStatus で使用

プロパティー説明

host

Kafka ブートストラップサービスの DNS 名または IP アドレス。

string

port

Kafka ブートストラップサービスのポート。

integer

6.2.61. KafkaConnect スキーマ参照

プロパティー説明

spec

Kafka Connect クラスターの仕様。

KafkaConnectSpec

status

Kafka Connect クラスターのステータス。

KafkaConnectStatus

6.2.62. KafkaConnectSpec スキーマ参照

KafkaConnect で使用

KafkaConnectSpec スキーマプロパティーの全リスト

Kafka Connect クラスターを設定します。

6.2.62.1. config

Kafka のオプションをキーとして設定するには、config プロパティーを使用します。

標準の Apache Kafka Connect 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。

以下に関連する設定オプションは設定できません。

  • Kafka クラスターブートストラップアドレス
  • セキュリティー (暗号化、認証、および承認)
  • リスナー / REST インターフェイスの設定
  • プラグインパスの設定

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプションを除き、Apache Kafka ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションは禁止されています。

  • ssl.
  • sasl.
  • security.
  • listeners
  • plugin.path
  • rest.
  • bootstrap.servers

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka Connect に渡されます。

重要

提供された config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Connect クラスターが起動しなかったり、不安定になる可能性があります。この状況で、KafkaConnect.spec.config オブジェクトの設定を修正すると、Cluster Operator は新しい設定をすべての Kafka Connect ノードにロールアウトできます。

以下のオプションにはデフォルト値があります。

  • group.id、デフォルト値 connect-cluster
  • offset.storage.topic、デフォルト値 connect-cluster-offsets
  • config.storage.topic、デフォルト値 connect-cluster-configs
  • status.storage.topic、デフォルト値 connect-cluster-status
  • key.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter
  • value.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter

このようなオプションは、KafkaConnect.spec.config プロパティーにない場合に自動的に設定されます。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用して、クライアント接続に許可される 3 つの ssl 設定オプションを使用します。暗号スイートは、セキュアな接続とデータ転送のためのアルゴリズムを組み合わせます。ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

Kafka Connect の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
    ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    ssl.enabled.protocols: TLSv1.2
    ssl.protocol: TLSv1.2
    ssl.endpoint.identification.algorithm: HTTPS
  # ...

TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。また、 ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

6.2.62.2. logging

Kafka Connect には独自の設定可能なロガーがあります。

  • connect.root.logger.level
  • log4j.logger.org.reflections

実行中の Kafka Connect プラグインに応じて、さらにロガーが追加されます。

curl リクエストを使用して、Kafka ブローカー Pod から稼働している Kafka Connect ロガーの完全リストを取得します。

curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/

Kafka Connect では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: connect-logging.log4j
  # ...

設定されていない利用可能なロガーのレベルは OFF に設定されています。

Cluster Operator を使用して Kafka Connect がデプロイされた場合、Kafka Connect のロギングレベルの変更は動的に適用されます。

外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリング更新がトリガーされます。

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.62.3. KafkaConnectSpec スキーマプロパティー
プロパティー説明

version

Kafka Connect のバージョン。デフォルトは 3.4.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。

string

replicas

Kafka Connect グループの Pod 数。

integer

image

Pod の Docker イメージ。

string

bootstrapServers

接続するブートストラップサーバー。これは <hostname>:_<port>_ pairs のコンマ区切りリストとして指定する必要があります。

string

tls

TLS 設定。

ClientTls

authentication

Kafka Connect の認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, scram-sha-256, scram-sha-512, plain, oauth] のいずれかでなければなりません。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

Kafka Connect の設定。次の接頭辞を持つプロパティーは設定できません: ssl.、sasl.、security.、listeners、plugin.path、rest.、bootstrap.servers、consumer.interceptor.classes、producer.interceptor.classes (ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols を除く)

map

resources

CPU とメモリーリソースおよび要求された初期リソースの上限。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

jvmOptions

Pod の JVM オプション。

JvmOptions

jmxOptions

JMX オプション。

KafkaJmxOptions

logging

Kafka Connect のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

clientRackInitImage

client.rack の初期化に使用される init コンテナーのイメージです。

string

rack

client.rack コンシューマー設定として使用されるノードラベルの設定。

Rack

tracing

Kafka Connect でのトレースの設定。タイプは、指定のオブジェクト内の tracing.type プロパティーの値によって異なり、[jaeger, opentelemetry] の 1 つでなければなりません。

JaegerTracingOpenTelemetryTracing

template

Kafka Connect および Kafka Mirror Maker 2 リソースのテンプレート。ユーザーはテンプレートにより、DeploymentPod および Service の生成方法を指定できます。

KafkaConnectTemplate

externalConfiguration

Secret または ConfigMap から Kafka Connect Pod にデータを渡し、これを使用してコネクターを設定します。

ExternalConfiguration

build

Connect コンテナーイメージを構築する方法を設定します。オプション:

ビルド

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

6.2.63. ClientTls スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

ClientTls スキーマプロパティーの完全リスト

KafkaConnect、KafkaBridge、KafkaMirror、KafkaMirrorMaker2 をクラスターに接続するための TLS 信頼証明書を設定します。

6.2.63.1. trustedCertificates

trustedCertificates プロパティーを使用してシークレットのリストを提供する。

6.2.63.2. ClientTls スキーマプロパティー
プロパティー説明

trustedCertificates

TLS 接続の信頼済み証明書。

CertSecretSource array

6.2.64. KafkaClientAuthenticationTls スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

KafkaClientAuthenticationTls スキーマプロパティーの全リスト

mTLS 認証を設定するには、type プロパティーを値 tls に設定します。mTLS は TLS 証明書を使用して認証します。

6.2.64.1. certificateAndKey

証明書は certificateAndKey プロパティーで指定され、常に OpenShift シークレットからロードされます。シークレットでは、公開鍵と秘密鍵の 2 つの鍵を使用して証明書を X509 形式で保存する必要があります。

User Operator によって作成されたシークレットを使用できます。または、認証に使用される鍵で独自の TLS 証明書ファイルを作成し、ファイルから Secret を作成することもできます。

oc create secret generic MY-SECRET \
--from-file=MY-PUBLIC-TLS-CERTIFICATE-FILE.crt \
--from-file=MY-PRIVATE.key
注記

mTLS 認証は、TLS 接続でのみ使用できます。

mTLS 設定の例

authentication:
  type: tls
  certificateAndKey:
    secretName: my-secret
    certificate: my-public-tls-certificate-file.crt
    key: private.key

6.2.64.2. KafkaClientAuthenticationTls スキーマプロパティー

typeプロパティーは、KafkaClientAuthenticationTlsタイプと、KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth の使用を区別するための識別子です。KafkaClientAuthenticationTls タイプには tls の値が必要です。

プロパティー説明

certificateAndKey

証明書と秘密鍵のペアを保持する Secret への参照。

CertAndKeySecretSource

type

tls でなければなりません。

string

6.2.65. KafkaClientAuthenticationScramSha256 スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

KafkaClientAuthenticationScramSha256スキーマプロパティーの全リスト

SASL ベースの SCRAM-SHA-256 認証を設定するには、type プロパティーを scram-sha-256 に設定します。SCRAM-SHA-256 認証メカニズムには、ユーザー名とパスワードが必要です。

6.2.65.1. username

username プロパティーでユーザー名を指定します。

6.2.65.2. passwordSecret

passwordSecret プロパティーで、パスワードが含まれる Secret へのリンクを指定します。

User Operator によって作成されたシークレットを使用できます。

必要に応じて、認証に使用するクリアテキストのパスワードが含まれるテキストファイルを作成できます。

echo -n PASSWORD > MY-PASSWORD.txt

次に、テキストファイルから Secret を作成し、パスワードに独自のフィールド名 (鍵) を設定できます。

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect の SCRAM-SHA-256 クライアント認証の Secret 例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm

secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password プロパティーには、実際のパスワードを指定しないでください。

Kafka Connect の SASL ベース SCRAM-SHA-256 クライアント認証の設定例

authentication:
  type: scram-sha-256
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-connect-password-field

6.2.65.3. KafkaClientAuthenticationScramSha256 スキーマプロパティー
プロパティー説明

passwordSecret

パスワードを保持する Secret への参照。

PasswordSecretSource

type

scram-sha-256 でなければなりません。

string

username

認証に使用されるユーザー名。

string

6.2.66. PasswordSecretSource スキーマ参照

使用先: KafkaClientAuthenticationOAuthKafkaClientAuthenticationPlainKafkaClientAuthenticationScramSha256KafkaClientAuthenticationScramSha512

プロパティー説明

password

パスワードが保存される Secret のキーの名前。

string

secretName

パスワードを含むシークレットの名前。

string

6.2.67. KafkaClientAuthenticationScramSha512 スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

KafkaClientAuthenticationScramSha512 スキーマプロパティーの全リスト

SASL ベースの SCRAM-SHA-512 認証を設定するには、type プロパティーを scram-sha-512 に設定します。SCRAM-SHA-512 認証メカニズムには、ユーザー名とパスワードが必要です。

6.2.67.1. username

username プロパティーでユーザー名を指定します。

6.2.67.2. passwordSecret

passwordSecret プロパティーで、パスワードが含まれる Secret へのリンクを指定します。

User Operator によって作成されたシークレットを使用できます。

必要に応じて、認証に使用するクリアテキストのパスワードが含まれるテキストファイルを作成できます。

echo -n PASSWORD > MY-PASSWORD.txt

次に、テキストファイルから Secret を作成し、パスワードに独自のフィールド名 (鍵) を設定できます。

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect の SCRAM-SHA-512 クライアント認証の Secret 例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm

secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password プロパティーには、実際のパスワードを指定しないでください。

Kafka Connect の SASL ベース SCRAM-SHA-512 クライアント認証の設定例

authentication:
  type: scram-sha-512
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-connect-password-field

6.2.67.3. KafkaClientAuthenticationScramSha512 スキーマプロパティー
プロパティー説明

passwordSecret

パスワードを保持する Secret への参照。

PasswordSecretSource

type

scram-sha-512 でなければなりません。

string

username

認証に使用されるユーザー名。

string

6.2.68. KafkaClientAuthenticationPlain スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

KafkaClientAuthenticationPlain スキーマプロパティーの全リスト

SASL ベースの PLAIN 認証を設定するには、type プロパティーを plain に設定します。SASL PLAIN 認証メカニズムには、ユーザー名とパスワードが必要です。

警告

SASL PLAIN メカニズムは、クリアテキストでユーザー名とパスワードをネットワーク全体に転送します。TLS による暗号化が有効になっている場合にのみ SASL PLAIN 認証を使用します。

6.2.68.1. username

username プロパティーでユーザー名を指定します。

6.2.68.2. passwordSecret

passwordSecret プロパティーで、パスワードが含まれる Secret へのリンクを指定します。

User Operator によって作成されたシークレットを使用できます。

必要に応じて、認証に使用するクリアテキストのパスワードが含まれるテキストファイルを作成します。

echo -n PASSWORD > MY-PASSWORD.txt

次に、テキストファイルから Secret を作成し、パスワードに独自のフィールド名 (鍵) を設定できます。

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect の PLAIN クライアント認証の Secret 例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-password-field-name: LFTIyFRFlMmU2N2Tm

secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password プロパティーには、実際のパスワードを指定しないでください。

SASL ベースの PLAIN クライアント認証の設定例

authentication:
  type: plain
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-password-field-name

6.2.68.3. KafkaClientAuthenticationPlain スキーマプロパティー

type プロパティーは、KafkaClientAuthenticationPlain タイプと、KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationOAuth の使用を区別するための識別子です。KafkaClientAuthenticationPlain タイプには plain の値が必要です。

プロパティー説明

passwordSecret

パスワードを保持する Secret への参照。

PasswordSecretSource

type

plain でなければなりません。

string

username

認証に使用されるユーザー名。

string

6.2.69. KafkaClientAuthenticationOAuth スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2ClusterSpecKafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

KafkaClientAuthenticationOAuth スキーマプロパティーの全リスト

OAuth クライアント認証を設定するには、type プロパティーを oauth に設定します。

OAuth 認証は、以下のオプションのいずれかを使用して設定できます。

  • クライアント ID およびシークレット
  • クライアント ID および更新トークン
  • アクセストークン
  • ユーザー名およびパスワード
  • TLS

クライアント ID およびシークレット

認証で使用されるクライアント ID およびクライアントシークレットとともに、tokenEndpointUri プロパティーで承認サーバーのアドレスを設定できます。OAuth クライアントは OAuth サーバーに接続し、クライアント ID およびシークレットを使用して認証し、Kafka ブローカーとの認証に使用するアクセストークンを取得します。clientSecret プロパティーで、クライアントシークレットを含む Secret へのリンクを指定します。

クライアント ID およびクライアントシークレットを使用した OAuth クライアント認証の例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  clientSecret:
    secretName: my-client-oauth-secret
    key: client-secret

必要に応じて、scopeaudience を指定できます。

クライアント ID および更新トークン

OAuth クライアント ID および更新トークンとともに、tokenEndpointUri プロパティーで OAuth サーバーのアドレスを設定できます。OAuth クライアントは OAuth サーバーに接続し、クライアント ID と更新トークンを使用して認証し、Kafka ブローカーとの認証に使用するアクセストークンを取得します。refreshToken プロパティーで、更新トークンが含まれる Secret へのリンクを指定します。

クライアント ID と更新トークンを使用した OAuth クライアント認証の例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token

アクセストークン

Kafka ブローカーとの認証に使用されるアクセストークンを直接設定できます。この場合、tokenEndpointUri は指定しません。accessToken プロパティーで、アクセストークンが含まれる Secret へのリンクを指定します。

アクセストークンのみを使用した OAuth クライアント認証の例

authentication:
  type: oauth
  accessToken:
    secretName: my-access-token-secret
    key: access-token

ユーザー名およびパスワード

OAuth のユーザー名とパスワードの設定では、OAuth リソースオーナーのパスワード付与 メカニズムを使用します。このメカニズムは非推奨であり、クライアント認証情報 (ID とシークレット) を使用できない環境での統合を有効にするためにのみサポートされています。アクセス管理システムが別のアプローチをサポートしていない場合、または認証にユーザーアカウントが必要な場合は、ユーザーアカウントの使用が必要になることがあります。

典型的なアプローチは、クライアントアプリケーションを表す認可サーバーに特別なユーザーアカウントを作成することです。次に、ランダムに生成された長いパスワードと非常に限られた権限セットをアカウントに与えます。たとえば、アカウントは Kafka クラスターにのみ接続できますが、他のサービスを使用したり、ユーザーインターフェイスにログインしたりすることはできません。

最初にリフレッシュトークンメカニズムの使用を検討してください。

tokenEndpointUri プロパティーで、認証に使用されるクライアント ID、ユーザー名、およびパスワードと共に、承認サーバーのアドレスを設定できます。OAuth クライアントは OAuth サーバーに接続し、ユーザー名、パスワード、クライアント ID、およびオプションでクライアントシークレットを使用して認証し、Kafka ブローカーでの認証に使用するアクセストークンを取得します。

passwordSecret プロパティーで、パスワードが含まれる Secret へのリンクを指定します。

通常、パブリック OAuth クライアントを使用して clientId も設定する必要があります。機密 OAuth クライアントを使用している場合は、clientSecret も設定する必要があります。

パブリッククライアントでのユーザー名とパスワードを使用した OAuth クライアント認証の例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  username: my-username
  passwordSecret:
    secretName: my-password-secret-name
    password: my-password-field-name
  clientId: my-public-client-id

機密クライアントでのユーザー名とパスワードを使用した OAuth クライアント認証の例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  username: my-username
  passwordSecret:
    secretName: my-password-secret-name
    password: my-password-field-name
  clientId: my-confidential-client-id
  clientSecret:
    secretName: my-confidential-client-oauth-secret
    key: client-secret

必要に応じて、scopeaudience を指定できます。

TLS

HTTPS プロトコルを使用して OAuth サーバーにアクセスする場合、信頼される認証局によって署名された証明書を使用し、そのホスト名が証明書に記載されている限り、追加の設定は必要ありません。

OAuth サーバーが自己署名証明書を使用している場合、または信頼されていない認証局によって署名されている場合は、カスタムリソースで信頼済み証明書の一覧を設定できます。tlsTrustedCertificates プロパティーには、証明書が保存されるキーの名前を持つシークレットの一覧が含まれます。証明書は X509 形式で保存する必要があります。

提供される TLS 証明書の例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token
  tlsTrustedCertificates:
    - secretName: oauth-server-ca
      certificate: tls.crt

OAuth クライアントはデフォルトで、OAuth サーバーのホスト名が、証明書サブジェクトまたは別の DNS 名のいずれかと一致することを確認します。必要でない場合は、ホスト名の検証を無効にできます。

無効にされた TLS ホスト名の検証例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token
  disableTlsHostnameVerification: true

6.2.69.1. KafkaClientAuthenticationOAuth スキーマプロパティー

type プロパティーは、KafkaClientAuthenticationOAuth タイプと、KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain の使用を区別するための識別子です。KafkaClientAuthenticationOAuth タイプには oauth の値が必要です。

プロパティー説明

accessToken

承認サーバーから取得したアクセストークンが含まれる OpenShift シークレットへのリンク。

GenericSecretSource

accessTokenIsJwt

アクセストークンを JWT として処理すべきかどうかを設定します。承認サーバーが不透明なトークンを返す場合は、false に設定する必要があります。デフォルトは true です。

boolean

audience

承認サーバーに対して認証を行うときに使用する OAuth オーディエンス。一部の承認サーバーでは、オーディエンスを明示的に設定する必要があります。許可される値は、承認サーバーの設定によります。デフォルトでは、トークンエンドポイントリクエストを実行する場合は audience は指定されません。

string

clientId

Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアント ID。

string

clientSecret

Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアントシークレットが含まれる OpenShift シークレットへのリンク。

GenericSecretSource

connectTimeoutSeconds

承認サーバーへの接続時のタイムアウト (秒単位)。設定しない場合は、実際の接続タイムアウトは 60 秒になります。

integer

disableTlsHostnameVerification

TLS ホスト名の検証を有効または無効にします。デフォルト値は false です。

boolean

enableMetrics

OAuth メトリックを有効または無効にします。デフォルト値は false です。

boolean

httpRetries

最初の HTTP リクエストが失敗した場合に試行する最大再試行回数。設定されていない場合、デフォルトでは再試行は行われません。

integer

httpRetryPauseMs

失敗した HTTP リクエストを再試行するまでの一時停止。設定されていない場合、デフォルトでは一時停止せず、ただちにリクエストを繰り返します。

integer

maxTokenExpirySeconds

アクセストークンの有効期間を指定の秒数に設定または制限します。これは、承認サーバーが不透明なトークンを返す場合に設定する必要があります。

integer

passwordSecret

パスワードを保持する Secret への参照。

PasswordSecretSource

readTimeoutSeconds

承認サーバーへの接続時の読み取りタイムアウト (秒単位)。設定しない場合は、実際の読み取りタイムアウトは 60 秒になります。

integer

refreshToken

承認サーバーからアクセストークンを取得するために使用できる更新トークンが含まれる OpenShift シークレットへのリンク。

GenericSecretSource

scope

承認サーバーに対して認証を行うときに使用する OAuth スコープ。一部の承認サーバーでこれを設定する必要があります。許可される値は、承認サーバーの設定によります。デフォルトでは、トークンエンドポイントリクエストを実行する場合は scope は指定されません。

string

tlsTrustedCertificates

OAuth サーバーへの TLS 接続の信頼済み証明書。

CertSecretSource array

tokenEndpointUri

承認サーバートークンエンドポイント URI。

string

type

oauth でなければなりません。

string

username

認証に使用されるユーザー名。

string

6.2.70. JaegerTracing スキーマ参照

タイプ JaegerTracing は非推奨になりました。

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpec

type プロパティーは、JaegerTracing タイプの使用を OpenTelemetryTracing と区別する識別子です。JaegerTracing タイプには jaeger の値が必要です。

プロパティー説明

type

jaeger でなければなりません。

string

6.2.71. OpenTelemetryTracing スキーマ参照

使用先: KafkaBridgeSpecKafkaConnectSpecKafkaMirrorMaker2SpecKafkaMirrorMakerSpec

type プロパティーは、OpenTelemetryTracing タイプの使用をJaegerTracing と区別する識別子です。タイプ OpenTelemetryTracing の値が opentelemetry である必要があります。

プロパティー説明

type

opentelemetry でなければなりません。

string

6.2.72. KafkaConnectTemplate スキーマ参照

使用先: KafkaConnectSpecKafkaMirrorMaker2Spec

プロパティー説明

deployment

Kafka Connect Deployment のテンプレート。

DeploymentTemplate

podSet

Kafka Connect StrimziPodSet リソースのテンプレート。

ResourceTemplate

pod

Kafka Connect Pod のテンプレート。

PodTemplate

apiService

Kafka Connect API Service のテンプレート。

InternalServiceTemplate

headlessService

Kafka Connect ヘッドレス Service のテンプレート。

InternalServiceTemplate

connectContainer

Kafka Connect コンテナーのテンプレート。

ContainerTemplate

initContainer

Kafka init コンテナーのテンプレート。

ContainerTemplate

podDisruptionBudget

Kafka Connect PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

serviceAccount

Kafka Connect サービスアカウントのテンプレート。

ResourceTemplate

clusterRoleBinding

Kafka Connect ClusterRoleBinding のテンプレート。

ResourceTemplate

buildPod

Kafka Connect Build Pods のテンプレート。build Pod は OpenShift でのみ使用されます。

PodTemplate

buildContainer

Kafka Connect Build コンテナーのテンプレート。build コンテナーは OpenShift でのみ使用されます。

ContainerTemplate

buildConfig

新しいコンテナーイメージをビルドするために使用される Kafka Connect BuildConfig のテンプレート。BuildConfig は OpenShift でのみ使用されます。

BuildConfigTemplate

buildServiceAccount

Kafka Connect Build サービスアカウントのテンプレート。

ResourceTemplate

jmxSecret

Kafka Connect Cluster JMX 認証の Secret のテンプレートです。

ResourceTemplate

6.2.73. BuildConfigTemplate スキーマ参照

使用先: KafkaConnectTemplate

プロパティー説明

metadata

PodDisruptionBudgetTemplate リソースに適用するメタデータ。

MetadataTemplate

pullSecret

ベースイメージをプルするためのクレデンシャルが含まれる Container Registry Secret。

string

6.2.74. ExternalConfiguration スキーマ参照

使用先: KafkaConnectSpecKafkaMirrorMaker2Spec

ExternalConfiguration スキーマプロパティーの完全リスト

Kafka Connect コネクターの設定オプションを定義する外部ストレージプロパティーを設定します。

ConfigMap またはシークレットを環境変数またはボリュームとして Kafka Connect Pod にマウントできます。ボリュームおよび環境変数は、KafkaConnect.specexternalConfiguration プロパティーで設定されます。

これが適用されると、コネクターの開発時に環境変数とボリュームを使用できます。

6.2.74.1. env

env プロパティーを使用して 1 つ以上の環境変数を指定します。これらの変数には ConfigMap または Secret からの値を含めることができます。

環境変数の値が含まれるシークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

注記

ユーザー定義の環境変数に、KAFKA_ または STRIMZI_ で始まる名前を付けることはできません。

シークレットから環境変数に値をマウントするには、valueFrom プロパティーおよび secretKeyRef を使用します。

Secret からの値に設定された環境変数の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

Secret をマウントする一般的なユースケースは、コネクターが Amazon AWS と通信するためのものです。コネクターは AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を読み取ることができる必要があります。

ConfigMap から環境変数に値をマウントするには、以下の例のように valueFrom プロパティーで configMapKeyRef を使用します。

ConfigMap からの値に設定された環境変数の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          configMapKeyRef:
            name: my-config-map
            key: my-key

6.2.74.2. volumes

ボリュームを使用して ConfigMap またはシークレットを Kafka Connect Pod にマウントします。

以下の場合、環境変数の代わりにボリュームを使用すると便利です。

  • Kafka Connect コネクターの設定に使用されるプロパティーファイルのマウント
  • TLS 証明書でのトラストストアまたはキーストアのマウント

ボリュームは、パス /opt/kafka/external-configuration/<volume-name> の Kafka Connect コンテナー内にマウントされます。たとえば、 connector-config という名前のボリュームのファイルは /opt/kafka/external-configuration/connector-config ディレクトリーにあります。

設定プロバイダーは設定外から値を読み込みます。プロバイダーメカニズムを使用して、制限された情報が Kafka ConnectREST インターフェイスを介して渡されないようにします。

  • FileConfigProvider ファイルのプロパティーから設定値をロードします。
  • DirectoryConfigProvider ディレクトリー構造内で個別のファイルから設定値をロードします。

複数のプロバイダー (カスタムプロバイダーを含む) を追加する場合は、コンマ区切りリストを使用します。カスタムプロバイダーを使用して、他のファイルの場所から値をロードできます。

FileConfigProvider を使用したプロパティー値の読み込み

以下の例では、mysecret という名前の Secret には、データベース名とパスワードを指定するコネクタープロパティーが含まれています。

データベースプロパティーのある Secret の例

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |- 1
    dbUsername: my-username 2
    dbPassword: my-password

1
プロパティーファイル形式のコネクター設定。
2
設定で使用されるデータベースのユーザー名およびパスワードプロパティー。

Secret および FileConfigProvider 設定プロバイダーは Kafka Connect 設定に指定されます。

  • Secret は connector-config という名前のボリュームにマウントされます。
  • FileConfigProvider にはエイリアス ファイル が付与されます。

Secret からの値に設定された外部ボリュームの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file 1
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider 2
  #...
  externalConfiguration:
    volumes:
      - name: connector-config 3
        secret:
          secretName: mysecret 4

1
設定プロバイダーのエイリアスは、他の設定パラメーターを定義するために使用されます。
2
FileConfigProvider はプロパティーファイルから値を提供します。プロバイダーパラメーターは config.providers からのエイリアスを使用し、config.providers.${alias}.class の形式を取ります。
3
Secret が含まれるボリュームの名前。各ボリュームは name プロパティーに名前を指定し、ConfigMap またはシークレットを参照する必要があります。
4
Secret の名前。

Secret のプロパティー値のプレースホルダーは、コネクター設定で参照されます。プレースホルダー構造は、configmaps:PATH-AND-FILE-NAME:PROPERTY です。FileConfigProvider は、コネクター設定でマウントされた Secret からデータベースの username および password プロパティーの値を読み取りおよび展開します。

外部値のプレースホルダーを示すコネクター設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: io.debezium.connector.mysql.MySqlConnector
  tasksMax: 2
  config:
    database.hostname: 192.168.99.1
    database.port: "3306"
    database.user: "${file:/opt/kafka/external-configuration/connector-config/mysecret:dbUsername}"
    database.password: "${file:/opt/kafka/external-configuration/connector-config/mysecret:dbPassword}"
    database.server.id: "184054"
    #...

DirectoryConfigProvider を使用した個別ファイルからのプロパティー値のロード

この例の Secret には個別のファイルに TLS トラストストアとキーストアユーザーのクレデンシャルが含まれています。

ユーザークレデンシャルのある Secret の例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  ca.crt: <public_key> # Public key of the clients CA
  user.crt: <user_certificate> # Public key of the user
  user.key: <user_private_key> # Private key of the user
  user.p12: <store> # PKCS #12 store for user certificates and keys
  user.password: <password_for_store> # Protects the PKCS #12 store

Secret および DirectoryConfigProvider 設定プロバイダーは Kafka Connect 設定に指定されます。

  • Secret は connector-config という名前のボリュームにマウントされます。
  • DirectoryConfigProvider には エイリアスの ディレクトリー が付与されます。

ユーザークレデンシャルファイルに設定された外部ボリュームの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: directory
    config.providers.directory.class: org.apache.kafka.common.config.provider.DirectoryConfigProvider 1
  #...
  externalConfiguration:
    volumes:
      - name: cluster-ca
        secret:
          secretName: my-cluster-cluster-ca-cert
      - name: my-user
        secret:
          secretName: my-user

1
DirectoryConfigProvider はディレクトリー内のファイルからの値を提供します。プロバイダーパラメーターは config.providers からのエイリアスを使用し、config.providers.${alias}.class の形式を取ります。

クレデンシャルのプレースホルダーはコネクター設定で参照されます。プレースホルダー構造は directory:PATH:FILE-NAME です。DirectoryConfigProvider は、コネクター設定でマウントされた Secret からクレデンシャルを読み取りおよび展開します。

外部値のプレースホルダーを示すコネクター設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: io.debezium.connector.mysql.MySqlConnector
  tasksMax: 2
  config:
    # ...
    database.history.producer.security.protocol: SSL
    database.history.producer.ssl.truststore.type: PEM
    database.history.producer.ssl.truststore.certificates: "${directory:/opt/kafka/external-configuration/cluster-ca:ca.crt}"
    database.history.producer.ssl.keystore.type: PEM
    database.history.producer.ssl.keystore.certificate.chain: "${directory:/opt/kafka/external-configuration/my-user:user.crt}"
    database.history.producer.ssl.keystore.key: "${directory:/opt/kafka/external-configuration/my-user:user.key}"
    #...

6.2.74.3. ExternalConfiguration スキーマプロパティー
プロパティー説明

env

Secret または ConfigMap からのデータを環境変数として Kafka Connect Pod で利用できるようにします。

ExternalConfigurationEnv array

volumes

Secret または ConfigMap からのデータをボリュームとして Kafka Connect Pod で利用できるようにします。

ExternalConfigurationVolumeSource array

6.2.75. ExternalConfigurationEnv スキーマ参照

ExternalConfiguration で使用

プロパティー説明

name

Kafka Connect Pod に渡される環境変数の名前。環境変数に、KAFKA_ または STRIMZI_ で始まる名前を付けることはできません。

string

valueFrom

Kafka Connect Pod に渡される環境変数の値。Secret または ConfigMap フィールドのいずれかへ参照として渡すことができます。このフィールドでは、Secret または ConfigMap を 1 つだけ指定する必要があります。

ExternalConfigurationEnvVarSource

6.2.76. ExternalConfigurationEnvVarSource スキーマ参照

ExternalConfigurationEnv で使用

プロパティー説明

configMapKeyRef

ConfigMap のキーへの参照。詳細は、core/v1 configmapkeyselector の外部ドキュメント を参照してください。

ConfigMapKeySelector

secretKeyRef

Secret のキーへの参照。詳細は、core/v1 secretkeyselector の外部ドキュメント を参照してください。

SecretKeySelector

6.2.77. ExternalConfigurationVolumeSource スキーマ参照

ExternalConfiguration で使用

プロパティー説明

configMap

ConfigMap のキーへの参照。Secret または ConfigMap を 1 つだけ指定する必要があります。詳細は、core/v1 configmapvolumesource の外部ドキュメント を参照してください。

ConfigMapVolumeSource

name

Kafka Connect Pod に追加されるボリュームの名前。

string

secret

Secret のキーへの参照。Secret または ConfigMap を 1 つだけ指定する必要があります。詳細は、core/v1 secretvolumesource の外部ドキュメント を参照してください。

SecretVolumeSource

6.2.78. Build スキーマ参照

使用先: KafkaConnectSpec

Build スキーマプロパティーの全リスト

Kafka Connect デプロイメントの追加コネクターを設定します。

6.2.78.1. 出力

追加のコネクタープラグインで新しいコンテナーイメージをビルドするには、イメージをプッシュ、保存、およびプルできるコンテナーレジストリーが AMQ Streams に必要です。AMQ Streams は独自のコンテナーレジストリーを実行しないため、レジストリーを指定する必要があります。AMQ Streams は、プライベートコンテナーレジストリーだけでなく、QuayDocker Hub などのパブリックレジストリーもサポートします。コンテナーレジストリーは、KafkaConnect カスタムリソースの .spec.build.output セクションで設定されます。output 設定は必須で、dockerimagestream の 2 つのタイプをサポートします。

Docker レジストリーの使用

Docker レジストリーを使用するには、typedocker として指定し、image フィールドに新しいコンテナーイメージのフルネームを指定する必要があります。フルネームには以下が含まれる必要があります。

  • レジストリーのアドレス
  • ポート番号 (標準以外のポートでリッスンしている場合)
  • 新しいコンテナーイメージのタグ

有効なコンテナーイメージ名の例:

  • docker.io/my-org/my-image/my-tag
  • quay.io/my-org/my-image/my-tag
  • image-registry.image-registry.svc:5000/myproject/kafka-connect-build:latest

Kafka Connect デプロイメントごとに個別のイメージを使用する必要があります。これは、最も基本的なレベルで異なるタグを使用する可能性があることを意味します。

レジストリーに認証が必要な場合は、pushSecret を使用してレジストリーのクレデンシャルで Secret の名前を設定します。Secret には、kubernetes .io/dockerconfigjson タイプと .dockerconfigjson ファイルを使用して Docker 認証情報を追加します。プライベートレジストリーからイメージをプルする方法の詳細は、Create a Secret based on existing Docker credentials を参照してください。

output 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      type: docker 1
      image: my-registry.io/my-org/my-connect-cluster:latest 2
      pushSecret: my-registry-credentials 3
  #...

1
(必須) AMQ Streams によって使用される出力のタイプ。
2
(必須) リポジトリーとタグを含む、使用されるイメージのフルネーム。
3
(任意) コンテナーレジストリーのクレデンシャルが含まれるシークレットの名前。

OpenShift ImageStream の使用

Docker の代わりに OpenShift ImageStream を使用して、新しいコンテナーイメージを保存できます。Kafka Connect をデプロイする前に、ImageStream を手動で作成する必要があります。ImageStream を使用するには、typeimagestream に設定し、image プロパティーを使用して ImageStream と使用するタグの名前を指定します。例: my-connect-image-stream:latest

output 設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      type: imagestream 1
      image: my-connect-build:latest 2
  #...

1
(必須) AMQ Streams によって使用される出力のタイプ。
2
(必須) ImageStream およびタグの名前。
6.2.78.2. plugins

コネクタープラグインは、特定タイプの外部システムへの接続に必要な実装を定義するファイルのセットです。コンテナーイメージに必要なコネクタープラグインは、KafkaConnect カスタムリソースの .spec.build.plugins プロパティーを使用して設定する必要があります。各コネクタープラグインには、Kafka Connect デプロイメント内で一意となる名前が必要です。さらに、プラグインアーティファクトもリストする必要があります。これらのアーティファクトは AMQ Streams によってダウンロードされ、新しいコンテナーイメージに追加され、Kafka Connect デプロイメントで使用されます。コネクタープラグインアーティファクトには、シリアライザーやデシリアライザーなどの追加のコンポーネントを含めることもできます。各コネクタープラグインは、異なるコネクターとそれらの依存関係が適切に サンドボックス化 されるように、個別のディレクトリーにダウンロードされます。各プラグインは、1 つ以上の artifact で設定する必要があります。

2 つのコネクタープラグインを持つ plugins の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins: 1
      - name: debezium-postgres-connector
        artifacts:
          - type: tgz
            url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/2.1.3.Final/debezium-connector-postgres-2.1.3.Final-plugin.tar.gz
            sha512sum: c4ddc97846de561755dc0b021a62aba656098829c70eb3ade3b817ce06d852ca12ae50c0281cc791a5a131cb7fc21fb15f4b8ee76c6cae5dd07f9c11cb7c6e79
      - name: camel-telegram
        artifacts:
          - type: tgz
            url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.11.5/camel-telegram-kafka-connector-0.11.5-package.tar.gz
            sha512sum: d6d9f45e0d1dbfcc9f6d1c7ca2046168c764389c78bc4b867dab32d24f710bb74ccf2a007d7d7a8af2dfca09d9a52ccbc2831fc715c195a3634cca055185bd91
  #...

1
(必須) コネクタープラグインおよびそれらのアーティファクトの一覧。

AMQ Streams では、以下のタイプのアーティファクトがサポートされます。

  • 直接ダウンロードして使用する JAR ファイル
  • ダウンロードおよび解凍された TGZ アーカイブ
  • ダウンロードおよび解凍された ZIP アーカイブ
  • Maven コーディネートを使用する Maven アーティファクト
  • 直接ダウンロードおよび使用されるその他のアーティファクト
重要

AMQ Streams は、ダウンロードしたアーティファクトのセキュリティースキャンを実行しません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドと Kafka Connect デプロイメントで同じアーティファクトが使用されるようにする必要があります。

JAR アーティファクトの使用

JAR アーティファクトは、コンテナーイメージにダウンロードされ、追加された JAR ファイルを表します。JAR アーティファクトを使用するには、type プロパティーを jar に設定し、url プロパティーを使用してダウンロードする場所を指定します。

さらに、アーティファクトの SHA-512 チェックサムを指定することもできます。指定された場合、AMQ Streams は新しいコンテナーイメージのビルド中にアーティファクトのチェックサムを検証します。

JAR アーティファクトの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: jar 1
            url: https://my-domain.tld/my-jar.jar 2
            sha512sum: 589...ab4 3
          - type: jar
            url: https://my-domain.tld/my-jar2.jar
  #...

1
(必須) アーティファクトのタイプ。
2
(必須) アーティファクトのダウンロード元 URL。
3
(任意) アーティファクトを検証する SHA-512 チェックサム。

TGZ アーティファクトの使用

TGZ アーティファクトは、Gzip 圧縮を使用して圧縮された TAR アーカイブをダウンロードするために使用されます。複数の異なるファイルで設定される場合でも、TGZ アーティファクトに Kafka Connect コネクター全体を含めることができます。TGZ アーティファクトは、新しいコンテナーイメージのビルド時に AMQ Streams によって自動的にダウンロードおよび展開されます。TGZ アーティファクトを使用するには、type プロパティーを tgz に設定し、url プロパティーを使用してダウンロードする場所を指定します。

さらに、アーティファクトの SHA-512 チェックサムを指定することもできます。指定された場合、展開して新しいコンテナーイメージをビルドする前に、チェックサムが AMQ Streams によって検証されます。

TGZ アーティファクトの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: tgz 1
            url: https://my-domain.tld/my-connector-archive.tgz 2
            sha512sum: 158...jg10 3
  #...

1
(必須) アーティファクトのタイプ。
2
(必須) アーカイブのダウンロード元 URL。
3
(任意) アーティファクトを検証する SHA-512 チェックサム。

ZIP アーティファクトの使用

ZIP アーティファクトは ZIP 圧縮アーカイブのダウンロードに使用されます。前のセクションで説明した TGZ アーティファクトと同じ方法で ZIP アーティファクトを使用します。唯一の違いは、type: tgz ではなく type: zip を指定することです。

Maven アーティファクトの使用

Maven アーティファクトは、コネクタープラグインアーティファクトを Maven コーディネートとして指定するために使用されます。Maven コーディネートは、プラグインアーティファクトおよび依存関係を特定し、Maven リポジトリーから検索および取得できるようにします。

注記

コネクタービルドプロセスがアーティファクトをコンテナーイメージに追加するには、Maven リポジトリーへのアクセス権が必要です。

Maven アーティファクトの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: maven 1
            repository: https://mvnrepository.com 2
            group: org.apache.camel.kafkaconnector 3
            artifact: camel-kafka-connector 4
            version: 0.11.0 5
  #...

1
(必須) アーティファクトのタイプ。
2
(任意) アーティファクトのダウンロード元となる Maven リポジトリー。リポジトリーを指定しないと、デフォルトで Maven Central リポジトリー が使用されます。
3
(必須) Maven グループ ID。
4
(必須) Maven アーティファクトタイプ。
5
(必須) Maven バージョン番号。

other アーティファクトの使用

other アーティファクトは、コンテナーイメージにダウンロードおよび追加されたファイルの種類を表します。結果となるコンテナーイメージのアーティファクトに特定の名前を使用する場合は、fileName フィールドを使用します。ファイル名が指定されていない場合、URL ハッシュを基にファイルの名前が付けられます。

さらに、アーティファクトの SHA-512 チェックサムを指定することもできます。指定された場合、AMQ Streams は新しいコンテナーイメージのビルド中にアーティファクトのチェックサムを検証します。

other アーティファクトの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: other  1
            url: https://my-domain.tld/my-other-file.ext  2
            sha512sum: 589...ab4  3
            fileName: name-the-file.ext  4
  #...

1
(必須) アーティファクトのタイプ。
2
(必須) アーティファクトのダウンロード元 URL。
3
(任意) アーティファクトを検証する SHA-512 チェックサム。
4
(任意) 結果となるコンテナーイメージに保存されるファイルの名前。
6.2.78.3. Build スキーマのプロパティー
プロパティー説明

output

新たにビルドされたイメージの保存先を設定します。必須。タイプは、指定のオブジェクト内の output.type プロパティーの値によって異なり、[docker、imagestream] のいずれかでなければなりません。

DockerOutput, ImageStreamOutput

resources

ビルド用に予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

plugins

Kafka Connect に追加する必要のあるコネクタープラグインのリスト。必須。

Plugin アレイ

6.2.79. DockerOutput スキーマ参照

Build で使用

type プロパティーは、DockerOutput タイプの使用を、ImageStreamOutput と区別するための識別子です。DockerOutput タイプには docker の値が必要です。

プロパティー説明

image

新たにビルドされたイメージのタグ付けおよびプッシュに使用されるフルネーム。例: quay.io/my-organization/my-custom-connect:latest必須。

string

pushSecret

新たにビルドされたイメージをプッシュするための、クレデンシャルが含まれる Container Registry Secret。

string

additionalKanikoOptions

新しい Connect イメージをビルドする際に、Kaniko エグゼキューターに渡される追加オプションを設定します。指定できるオプションは --customPlatform、--insecure、--insecure-pull、--insecure-registry、--log-format、--log-timestamp、--registry-mirror、--reproducible、--single-snapshot、--skip-tls-verify、--skip-tls-verify-pull、--skip-tls-verify-registry、--verbosity、--snapshotMode、--use-new-run です。これらのオプションは、Kaniko エグゼキューターが使用される OpenShift でのみ使用されます。OpenShift では無視されます。オプションは、Kaniko GitHub repository に記載されています。このフィールドを変更しても、Kafka Connect イメージのビルドは新たにトリガーされません。

string array

type

docker でなければなりません。

string

6.2.80. ImageStreamOutput スキーマ参照

Build で使用

type プロパティーは、InlineLogging タイプの使用と、DockerOutput を区別するための識別子です。ImageStreamOutput タイプには imagestream の値が必要です。

プロパティー説明

image

新たにビルドされたイメージがプッシュされる ImageStream の名前およびタグ。例: my-custom-connect:latest必須。

string

type

ImageStream の例

string

6.2.81. Plugin スキーマ参照

Build で使用

プロパティー説明

name

コネクタープラグインの一意名。コネクターアーティファクトが保存されるパスの生成に使用されます。名前は KafkaConnect リソース内で一意である必要があります。この名前は、^[a-z][-_a-z0-9]*[a-z]$ のパターンに従う必要があります。必須。

string

artifacts

このコネクタープラグインに属するアーティファクトの一覧。必須。

JarArtifact, TgzArtifact, ZipArtifact, MavenArtifact, OtherArtifact アレイ

6.2.82. JarArtifact スキーマ参照

Plugin で使用

プロパティー説明

url

ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。jar, zip, tgz および other アーティファクトで必要です。maven アーティファクトタイプには該当しません。

string

sha512sum

アーティファクトの SHA512 チェックサム。オプション:指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。maven アーティファクトタイプには該当しません。

string

insecure

デフォルトでは、TLS を使用する接続を検証して安全かどうかを確認します。使用するサーバー証明書は有効で信頼でき、サーバー名が含まれる必要があります。このオプションを true に設定すると、すべての TLS 検証が無効になり、サーバーが安全ではないと見なされる場合でもアーティファクトがダウンロードされます。

boolean

type

jar でなければなりません。

string

6.2.83. TgzArtifact スキーマ参照

Plugin で使用

プロパティー説明

url

ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。jar, zip, tgz および other アーティファクトで必要です。maven アーティファクトタイプには該当しません。

string

sha512sum

アーティファクトの SHA512 チェックサム。オプション:指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。maven アーティファクトタイプには該当しません。

string

insecure

デフォルトでは、TLS を使用する接続を検証して安全かどうかを確認します。使用するサーバー証明書は有効で信頼でき、サーバー名が含まれる必要があります。このオプションを true に設定すると、すべての TLS 検証が無効になり、サーバーが安全ではないと見なされる場合でもアーティファクトがダウンロードされます。

boolean

type

tgz でなければなりません。

string

6.2.84. ZipArtifact スキーマ参照

Plugin で使用

プロパティー説明

url

ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。jar, zip, tgz および other アーティファクトで必要です。maven アーティファクトタイプには該当しません。

string

sha512sum

アーティファクトの SHA512 チェックサム。オプション:指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。maven アーティファクトタイプには該当しません。

string

insecure

デフォルトでは、TLS を使用する接続を検証して安全かどうかを確認します。使用するサーバー証明書は有効で信頼でき、サーバー名が含まれる必要があります。このオプションを true に設定すると、すべての TLS 検証が無効になり、サーバーが安全ではないと見なされる場合でもアーティファクトがダウンロードされます。

boolean

type

zip でなければなりません。

string

6.2.85. MavenArtifact スキーマ参照

Plugin で使用

type プロパティーは、MavenArtifact タイプと JarArtifact, TgzArtifact, ZipArtifact, OtherArtifact の使用を区別するための識別子です。MavenArtifact タイプには maven の値が必要です。

プロパティー説明

repository

アーティファクトのダウンロード元となる Maven リポジトリー。maven アーティファクトタイプにのみ適用されます。

string

group

Maven グループ ID。maven アーティファクトタイプにのみ適用されます。

string

artifact

Maven artifact ID。maven アーティファクトタイプにのみ適用されます。

string

version

Maven のバージョン番号。maven アーティファクトタイプにのみ適用されます。

string

type

maven でなければなりません。

string

6.2.86. OtherArtifact スキーマ参照

Plugin で使用

プロパティー説明

url

ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。jar, zip, tgz および other アーティファクトで必要です。maven アーティファクトタイプには該当しません。

string

sha512sum

アーティファクトの SHA512 チェックサム。オプション:指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。maven アーティファクトタイプには該当しません。

string

fileName

保存されるアーティファクトの名前。

string

insecure

デフォルトでは、TLS を使用する接続を検証して安全かどうかを確認します。使用するサーバー証明書は有効で信頼でき、サーバー名が含まれる必要があります。このオプションを true に設定すると、すべての TLS 検証が無効になり、サーバーが安全ではないと見なされる場合でもアーティファクトがダウンロードされます。

boolean

type

other でなければなりません。

string

6.2.87. KafkaConnectStatus スキーマ参照

KafkaConnect で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

url

Kafka Connect コネクターの管理および監視用の REST API エンドポイントの URL。

string

connectorPlugins

この Kafka Connect デプロイメントで使用できるコネクタープラグインの一覧。

ConnectorPlugin array

labelSelector

このリソースを提供する Pod のラベルセレクター。

string

replicas

このリソースを提供するために現在使用されている Pod の数。

integer

6.2.88. ConnectorPlugin スキーマ参照

使用先: KafkaConnectStatusKafkaMirrorMaker2Status

プロパティー説明

type

コネクタープラグインのタイプ。sink タイプと source タイプを利用できます。

string

version

コネクタープラグインのバージョン。

string

class

コネクタープラグインのクラス。

string

6.2.89. KafkaTopic スキーマ参照

プロパティー説明

spec

トピックの仕様。

KafkaTopicSpec

status

トピックのステータス。

KafkaTopicStatus

6.2.90. KafkaTopicSpec スキーマ参照

KafkaTopic で使用

プロパティー説明

partitions

トピックに存在するパーティション数。この数はトピック作成後に減らすことはできません。トピック作成後に増やすことはできますが、その影響について理解することが重要となります。特にセマンティックパーティションのあるトピックで重要となります。これがない場合、デフォルトは num.partitions のブローカー設定になります。

integer

replicas

トピックのレプリカ数。これがない場合、デフォルトは default.replication.factor のブローカー設定になります。

integer

config

トピックの設定。

map

topicName

トピックの名前。これがない場合、デフォルトではトピックの metadata.name に設定されます。トピック名が有効な OpenShift リソース名ではない場合を除き、これを設定しないことが推奨されます。

string

6.2.91. KafkaTopicStatus スキーマ参照

KafkaTopic で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

topicName

トピック名。

string

6.2.92. KafkaUser スキーマ参照

プロパティー説明

spec

ユーザーの仕様。

KafkaUserSpec

status

Kafka User のステータス。

KafkaUserStatus

6.2.93. KafkaUserSpec スキーマ参照

KafkaUser で使用

プロパティー説明

authentication

この Kafka ユーザーに対して有効になっている認証メカニズム。サポートされる認証メカニズムは、scram-sha-512tls、および tls-external です。

  • SCRAM-sha-512 は、SASL SCRAM-SHA-512 認証情報でシークレットを生成します。
  • TLS は、相互 TLS 認証のユーザー証明書でシークレットを生成します。
  • TLS-external はユーザー証明書を生成しません。ただし、User Operator の外部で生成されるユーザー証明書を使用して相互 TLS 認証を使用するようにユーザーを準備します。このユーザーに設定された ACL およびクォータは CN=<username> 形式で設定されます。

認証はオプションです。認証が設定されていない場合には、認証情報は生成されません。ユーザーに設定された ACL およびクォータは、SASL 認証に適した <username> 形式で設定されます。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, tls-external, scram-sha-512] のいずれかでなければなりません。

KafkaUserTlsClientAuthentication, KafkaUserTlsExternalClientAuthentication, KafkaUserScramSha512ClientAuthentication

認可

この Kafka ユーザーの承認ルール。タイプは、指定のオブジェクト内の authorization.type プロパティーの値によって異なり、[simple] の 1 つでなければなりません。

KafkaUserAuthorizationSimple

quotas

クライアントによって使用されるブローカーリソースを制御する要求のクォータ。ネットワーク帯域幅および要求レートクォータの適用が可能です。Kafka ユーザークォータの Kafka ドキュメントは http://kafka.apache.org/documentation/#design_quotas を参照してください。

KafkaUserQuotas

template

Kafka User Secrets の生成方法を指定するテンプレート。

KafkaUserTemplate

6.2.94. KafkaUserTlsClientAuthentication スキーマ参照

KafkaUserSpec で使用

type プロパティーは KafkaUserTlsClientAuthentication タイプと、KafkaUserTlsExternalClientAuthentication, KafkaUserScramSha512ClientAuthentication の使用を区別するための識別子です。KafkaUserTlsClientAuthentication タイプには tls の値が必要です。

プロパティー説明

type

tls でなければなりません。

string

6.2.95. KafkaUserTlsExternalClientAuthentication スキーマ参照

KafkaUserSpec で使用

type プロパティーは KafkaUserTlsExternalClientAuthentication タイプと KafkaUserTlsClientAuthentication, KafkaUserScramSha512ClientAuthentication の使用を区別するための識別子です。KafkaUserTlsExternalClientAuthentication タイプには tls-external の値が必要です。

プロパティー説明

type

tls-external でなければなりません。

string

6.2.96. KafkaUserScramSha512ClientAuthentication スキーマ参照

KafkaUserSpec で使用

type プロパティーは KafkaUserScramSha512ClientAuthentication タイプと KafkaUserTlsClientAuthentication, KafkaUserTlsExternalClientAuthentication の使用を区別するための識別子です。KafkaUserScramSha512ClientAuthentication タイプには scram-sha-512 の値が必要です。

プロパティー説明

password

ユーザーのパスワードを指定します。設定されていない場合、新規パスワードは User Operator によって生成されます。

Password

type

scram-sha-512 でなければなりません。

string

6.2.97. Password スキーマ参照

使用先: KafkaUserScramSha512ClientAuthentication

プロパティー説明

valueFrom

パスワードを読み取る必要のあるシークレット。

PasswordSource

6.2.98. PasswordSource スキーマ参照

使用先: Password

プロパティー説明

secretKeyRef

リソースの namespace で Secret のキーを選択します。詳細は、core/v1 secretkeyselector の外部ドキュメント を参照してください。

SecretKeySelector

6.2.99. KafkaUserAuthorizationSimple スキーマ参照

KafkaUserSpec で使用

type プロパティーは、KafkaUserAuthorizationSimple タイプを使用する際に、今後追加される可能性のある他のサブタイプと区別する識別子です。KafkaUserAuthorizationSimple タイプには simple の値が必要です。

プロパティー説明

type

simple でなければなりません。

string

ACL

このユーザーに適用される必要のある ACL ルールの一覧。

AclRule array

6.2.100. AclRule スキーマ参照

KafkaUserAuthorizationSimple で使用

AclRule スキーマプロパティーの全リスト

ブローカーが AclAuthorizer を使用する場合に KafkaUser のアクセス制御ルールを設定します。

認証を使用した KafkaUser の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operations:
          - Read
          - Describe
      - resource:
          type: group
          name: my-group
          patternType: prefix
        operations:
          - Read

6.2.100.1. resource

resource プロパティーを使用して、ルールが適用されるリソースを指定します。

簡易承認は、type プロパティーに指定される、以下の 4 つのリソースタイプをサポートします。

  • トピック (topic)
  • コンシューマーグループ (group)
  • クラスター (cluster)
  • トランザクション ID (transactionalId)

Topic、Group、および Transactional ID リソースでは、name プロパティーでルールが適用されるリソースの名前を指定できます。

クラスタータイプのリソースには名前がありません。

名前は、patternType プロパティーを使用して literal または prefix として指定されます。

  • リテラル (literal) 名には、name フィールドに指定された名前がそのまま使われます。
  • 接頭辞名では、name 値を接頭辞として使用し、名前がその値で始まるすべてのリソースにルールを適用します。

patternTypeliteral として設定されている場合、名前を * に設定して、ルールがすべてのリソースに適用されるように指示します。

ユーザーがすべてのトピックからメッセージを読み込める ACL ルールの例

    acls:
      - resource:
          type: topic
          name: "*"
          patternType: literal
        operations:
          - Read

6.2.100.2. type

ルールの typeallow (操作の許可) または deny (操作の拒否、現在未サポート) です。

type フィールドの設定は任意です。type の指定がない場合、ACL ルールは allow ルールとして処理されます。

6.2.100.3. operations

ルールが許可または拒否する operation のリストを指定します。

以下の操作がサポートされます。

  • Read
  • Write
  • Delete
  • Alter
  • Describe
  • All
  • IdempotentWrite
  • ClusterAction
  • Create
  • AlterConfigs
  • DescribeConfigs

特定の操作のみが各リソースで機能します。

AclAuthorizer、ACL、およびサポートされるリソースと操作の組み合わせの詳細は、Authorization and ACL を参照してください。

6.2.100.4. host

host プロパティーを使用して、ルールが許可または拒否されるリモートホストを指定します。

アスタリスク (*) を使用して、すべてのホストからの操作を許可または拒否します。host フィールドの設定は任意です。host を指定しないと、値 * がデフォルトで使用されます。

6.2.100.5. AclRule スキーマのプロパティー
プロパティー説明

host

ACL ルールに記述されているアクションを許可または拒否するホスト。

string

操作 (operation)

operation プロパティーは廃止されたため、spec.authorization.acls*.operations を使用して設定する必要があります。許可または拒否される操作。サポートされる操作: Read、Write、Create、Delete、Alter、Describe、ClusterAction、AlterConfigs、DescribeConfigs、IdempotentWrite、All

string ([Read、Write、Delete、Alter、Describe、All、IdempotentWrite、ClusterAction、Create、AlterConfigs、DescribeConfigs] のいずれか)

operations

許可または拒否される操作の一覧。サポートされる操作: Read、Write、Create、Delete、Alter、Describe、ClusterAction、AlterConfigs、DescribeConfigs、IdempotentWrite、All

string ([Read, Write, Delete, Alter, Describe, All, IdempotentWrite, ClusterAction, Create, AlterConfigs, DescribeConfigs] のいずれか 1 つ以上) array

resource

指定の ACL ルールが適用されるリソースを示します。タイプは、指定のオブジェクト内の resource.type プロパティーの値によって異なり、[topic、group、cluster、transactionalId] のいずれかでなければなりません。

AclRuleTopicResourceAclRuleGroupResourceAclRuleClusterResourceAclRuleTransactionalIdResource

type

ルールのタイプ。現在サポートされているタイプは allow のみです。allow タイプの ACL ルールを使用すると、ユーザーは指定した操作を実行できます。デフォルト値は allow です。

string ([allow、deny] のいずれか)

6.2.101. AclRuleTopicResource スキーマ参照

AclRule で使用

type プロパティーは、AclRuleTopicResource タイプを使用する際に AclRuleGroupResourceAclRuleClusterResourceAclRuleTransactionalIdResource タイプと区別する識別子です。AclRuleTopicResource タイプには topic の値が必要です。

プロパティー説明

type

topic でなければなりません。

string

name

指定の ACL ルールが適用されるリソースの名前。patternType フィールドと組み合わせて、接頭辞のパターンを使用できます。

string

patternType

リソースフィールドで使用されるパターンを指定します。サポートされるタイプは literalprefix です。literal パターンタイプでは、リソースフィールドは完全なトピック名の定義として使用されます。prefix パターンタイプでは、リソース名は接頭辞としてのみ使用されます。デフォルト値は literal です。

string ([prefix、literal] のいずれか)

6.2.102. AclRuleGroupResource スキーマ参照

AclRule で使用

type プロパティーは、AclRuleGroupResource タイプを使用する際に AclRuleTopicResourceAclRuleClusterResourceAclRuleTransactionalIdResource タイプと区別する識別子です。AclRuleGroupResource タイプには group の値が必要です。

プロパティー説明

type

group でなければなりません。

string

name

指定の ACL ルールが適用されるリソースの名前。patternType フィールドと組み合わせて、接頭辞のパターンを使用できます。

string

patternType

リソースフィールドで使用されるパターンを指定します。サポートされるタイプは literalprefix です。literal パターンタイプでは、リソースフィールドは完全なトピック名の定義として使用されます。prefix パターンタイプでは、リソース名は接頭辞としてのみ使用されます。デフォルト値は literal です。

string ([prefix、literal] のいずれか)

6.2.103. AclRuleClusterResource スキーマ参照

AclRule で使用

type プロパティーは、AclRuleClusterResource タイプを使用する際に AclRuleTopicResourceAclRuleGroupResourceAclRuleTransactionalIdResource タイプと区別する識別子です。AclRuleClusterResource タイプには cluster の値が必要です。

プロパティー説明

type

cluster でなければなりません。

string

6.2.104. AclRuleTransactionalIdResource スキーマ参照

AclRule で使用

type プロパティーは、AclRuleTransactionalIdResource タイプを使用する際に AclRuleTopicResourceAclRuleGroupResourceAclRuleClusterResource タイプと区別する識別子です。AclRuleTransactionalIdResource タイプには transactionalId の値が必要です。

プロパティー説明

type

transactionalId でなければなりません。

string

name

指定の ACL ルールが適用されるリソースの名前。patternType フィールドと組み合わせて、接頭辞のパターンを使用できます。

string

patternType

リソースフィールドで使用されるパターンを指定します。サポートされるタイプは literalprefix です。literal パターンタイプでは、リソースフィールドはフルネームの定義として使用されます。prefix パターンタイプでは、リソース名は接頭辞としてのみ使用されます。デフォルト値は literal です。

string ([prefix、literal] のいずれか)

6.2.105. KafkaUserQuotas スキーマ参照

KafkaUserSpec で使用

KafkaUserQuotas スキーマプロパティーの全リスト

Kafka では、ユーザーは quotas を設定してクライアントによるリソースの使用を制御できます。

6.2.105.1. quotas

クライアントを設定して、以下のタイプのクォータを使用できます。

  • ネットワーク使用率 クォータは、クォータを共有するクライアントの各グループのバイトレートしきい値を指定します。
  • CPU 使用率クォータは、クライアントからのブローカー要求のウィンドウを指定します。ウィンドウは、クライアントが要求を行う時間の割合 (パーセント) です。クライアントはブローカーの I/O スレッドおよびネットワークスレッドで要求を行います。
  • パーティション変更クォータは、クライアントが 1 秒ごとに実行できるパーティション変更の数を制限します。

パーティション変更クォータにより、Kafka クラスターが同時にトピック操作に圧倒されないようにします。パーティション変更は、次のタイプのユーザー要求に応答して発生します。

  • 新しいトピック用のパーティションの作成
  • 既存のトピックへのパーティションの追加
  • トピックからのパーティションの削除

パーティション変更クオータを設定して、ユーザー要求に対して変更が許可されるレートを制御できます。

Kafka クライアントにクォータを使用することは、さまざまな状況で役に立つ場合があります。レートが高すぎる要求を送信する Kafka プロデューサーを誤って設定したとします。このように設定が間違っていると、他のクライアントにサービス拒否を引き起こす可能性があるため、問題のあるクライアントはブロックする必要があります。ネットワーク制限クォータを使用すると、他のクライアントがこの状況の著しい影響を受けないようにすることが可能です。

AMQ Streams はユーザーレベルのクォータをサポートしますが、クライアントレベルのクォータはサポートしません。

Kafka ユーザークォータの設定例

spec:
  quotas:
    producerByteRate: 1048576
    consumerByteRate: 2097152
    requestPercentage: 55
    controllerMutationRate: 10

Kafka ユーザークォータの詳細は Apache Kafka ドキュメント を参照してください。

6.2.105.2. KafkaUserQuotas スキーマ参照
プロパティー説明

consumerByteRate

グループのクライアントにスロットリングが適用される前に、各クライアントグループがブローカーから取得できる最大 bps (ビット毎秒) のクオータ。ブローカーごとに定義されます。

integer

controllerMutationRate

トピックの作成リクエスト、パーティションの作成リクエスト、トピックの削除リクエストで変更が受け入れられるレートのクオータ。レートは、作成または削除されたパーティション数で累積されます。

number

producerByteRate

グループのクライアントにスロットリングが適用される前に、各クライアントグループがブローカーにパブリッシュできる最大 bps (ビット毎秒) のクオータ。ブローカーごとに定義されます。

integer

requestPercentage

各クライアントグループの最大 CPU 使用率のクォータ。ネットワークと I/O スレッドの比率 (パーセント) として指定。

integer

6.2.106. KafkaUserTemplate スキーマ参照

KafkaUserSpec で使用

KafkaUserTemplate スキーマプロパティーの全リスト

User Operator によって作成されるシークレットの追加ラベルおよびアノテーションを指定します。

KafkaUserTemplate を示す例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  template:
    secret:
      metadata:
        labels:
          label1: value1
        annotations:
          anno1: value1
  # ...

6.2.106.1. KafkaUserTemplate スキーマのプロパティー
プロパティー説明

secret

KafkaUser リソースのテンプレート。テンプレートを使用すると、ユーザーはパスワードまたは TLS 証明書のある Secret の生成方法を指定できます。

ResourceTemplate

6.2.107. KafkaUserStatus スキーマ参照

KafkaUser で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

username

ユーザー名。

string

secret

認証情報が保存される Secret の名前。

string

6.2.108. KafkaMirrorMaker スキーマ参照

KafkaMirrorMaker タイプが非推奨になりました。代わりに KafkaMirrorMaker2 を使用してください。

プロパティー説明

spec

Kafka MirrorMaker の仕様。

KafkaMirrorMakerSpec

status

Kafka MirrorMaker のステータス。

KafkaMirrorMakerStatus

6.2.109. KafkaMirrorMakerSpec スキーマ参照

KafkaMirrorMaker で使用

KafkaMirrorMakerSpec スキーマプロパティーの完全リスト

Kafka MirrorMaker を設定します。

6.2.109.1. include

include プロパティーを使用して、Kafka MirrorMaker がソースからターゲット Kafka クラスターにミラーリングするトピックのリストを設定します。

このプロパティーでは、簡単な単一のトピック名から複雑なパターンまですべての正規表現が許可されます。たとえば、A|B を使用してトピック A と B をミラーリングでき、* を使用してすべてのトピックをミラーリングできます。また、複数の正規表現をコンマで区切って Kafka MirrorMaker に渡すこともできます。

6.2.109.2. KafkaMirrorMakerConsumerSpec および KafkaMirrorMakerProducerSpec

KafkaMirrorMakerConsumerSpec および KafkaMirrorMaker ProducerSpec を使用して、ソース (コンシューマー) およびターゲット (プロデューサー) クラスターを設定します。

Kafka MirrorMaker は常に 2 つの Kafka クラスター (ソースおよびターゲット) と連携します。接続を確立するため、ソースおよびターゲット Kafka クラスターのブートストラップサーバーは HOSTNAME:PORT ペアのコンマ区切りリストとして指定されます。それぞれのコンマ区切りリストには、HOSTNAME:PORT ペアとして指定された 1 つ以上の Kafka ブローカーまたは Kafka ブローカーを示す 1 つの Service が含まれます。

6.2.109.3. logging

Kafka MirrorMaker には、独自の設定可能なロガーがあります。

  • mirrormaker.root.logger

MirrorMaker では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、Apache logging services を参照してください。

inline および external ロギングの例は次のとおりです。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  # ...
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: mirror-maker-log4j.properties
  # ...

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.109.4. KafkaMirrorMakerSpec スキーマプロパティー
プロパティー説明

version

Kafka MirrorMaker のバージョン。デフォルトは 3.4.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ドキュメントを参照してください。

string

replicas

Deployment の Pod 数。

integer

image

Pod の Docker イメージ。

string

consumer

ソースクラスターの設定。

KafkaMirrorMakerConsumerSpec

producer

ターゲットクラスターの設定。

KafkaMirrorMakerProducerSpec

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

whitelist

whitelist プロパティーは非推奨となり、spec.include を使用して設定する必要があります。ミラーリングに含まれるトピックの一覧。このオプションは、Java スタイルの正規表現を使用するあらゆる正規表現を許可します。式 'A|B' を使用して、A と B という名前の 2 つのトピックをミラーリングすることができます。または、特殊なケースとして、正規表現 * を使用してすべてのトピックをミラーリングできます。複数の正規表現をコンマで区切って指定することもできます。

string

include

ミラーリングに含まれるトピックの一覧。このオプションは、Java スタイルの正規表現を使用するあらゆる正規表現を許可します。式 'A|B' を使用して、A と B という名前の 2 つのトピックをミラーリングすることができます。または、特殊なケースとして、正規表現 * を使用してすべてのトピックをミラーリングできます。複数の正規表現をコンマで区切って指定することもできます。

string

jvmOptions

Pod の JVM オプション。

JvmOptions

logging

MirrorMaker のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

tracing

Kafka MirrorMaker でのトレースの設定。タイプは、指定のオブジェクト内の tracing.type プロパティーの値によって異なり、[jaeger, opentelemetry] の 1 つでなければなりません。

JaegerTracingOpenTelemetryTracing

template

Kafka MirrorMaker のリソースである Deployments および Pods の生成方法を指定するテンプレート。

KafkaMirrorMakerTemplate

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

6.2.110. KafkaMirrorMakerConsumerSpec スキーマ参照

KafkaMirrorMakerSpec で使用

KafkaMirrorMakerConsumerSpec スキーマプロパティーの完全リスト

MirrorMaker コンシューマーを設定します。

6.2.110.1. numStreams

consumer.numStreams プロパティーを使用して、コンシューマーのストリームの数を設定します。

コンシューマースレッドの数を増やすと、ミラーリングトピックのスループットを増やすことができます。コンシューマースレッドは、Kafka MirrorMaker に指定されたコンシューマーグループに属します。トピックパーティションはコンシューマースレッド全体に割り当てられ、メッセージが並行して消費されます。

6.2.110.2. offsetCommitInterval

consumer.offsetCommitInterval プロパティーを使用して、コンシューマーのオフセット自動コミット間隔を設定します。

Kafka MirrorMaker によってソース Kafka クラスターのデータが消費された後に、オフセットがコミットされる通常の間隔を指定できます。間隔はミリ秒単位で設定され、デフォルト値は 60,000 です。

6.2.110.3. config

consumer.config プロパティーを使用して、コンシューマーの Kafka オプションを設定します。

config プロパティーには、Kafka MirrorMaker コンシューマー設定オプションが鍵として含まれ、値は以下の JSON タイプのいずれかに設定されます。

  • 文字列
  • 数値
  • ブール値

TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。また、 ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

例外

コンシューマー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。

しかし、以下に関連する AMQ Streams によって自動的に設定され、直接管理されるオプションには例外があります。

  • Kafka クラスターブートストラップアドレス
  • セキュリティー (暗号化、認証、および承認)
  • コンシューマーグループ ID
  • インターセプター

以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka MirrorMaker に渡されます。

重要

Cluster Operator では、提供された config オブジェクトのキーまたは値は検証されません。無効な設定が指定されると、Kafka MirrorMaker が起動しなかったり、不安定になったりする場合があります。このような場合、KafkaMirrorMaker.spec.consumer.config オブジェクトの設定を修正し、Cluster Operator によって Kafka MirrorMaker の新しい設定がロールアウトされるようにします。

6.2.110.4. groupId

consumer.groupId プロパティーを使用して、コンシューマーにコンシューマーグループ ID を設定します。

Kafka MirrorMaker は Kafka コンシューマーを使用してメッセージを消費し、他の Kafka コンシューマークライアントと同様に動作します。ソース Kafka クラスターから消費されるメッセージは、ターゲット Kafka クラスターにミラーリングされます。パーティションの割り当てには、コンシューマーがコンシューマーグループの一部である必要があるため、グループ ID が必要です。

6.2.110.5. KafkaMirrorMakerConsumerSpec スキーマプロパティー
プロパティー説明

numStreams

作成するコンシューマーストリームスレッドの数を指定します。

integer

offsetCommitInterval

オフセットの自動コミット間隔をミリ秒単位で指定します。デフォルト値は 60000 です。

integer

bootstrapServers

Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。

string

groupId

このコンシューマーが属するコンシューマーグループを識別する一意の文字列。

string

authentication

クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, scram-sha-256, scram-sha-512, plain, oauth] のいずれかでなければなりません。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker コンシューマーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、group.id、sasl.、security.、interceptor.classes (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols).

map

tls

MirrorMaker をクラスターに接続するための TLS 設定。

ClientTls

6.2.111. KafkaMirrorMakerProducerSpec スキーマ参照

KafkaMirrorMakerSpec で使用

KafkaMirrorMakerProducerSpec スキーマプロパティーの完全リスト

MirrorMaker プロデューサーを設定します。

6.2.111.1. abortOnSendFailure

producer.abortOnSendFailure プロパティーを使用して、プロデューサーからメッセージ送信の失敗を処理する方法を設定します。

デフォルトでは、メッセージを Kafka MirrorMaker から Kafka クラスターに送信する際にエラーが発生した場合、以下が行われます。

  • Kafka MirrorMaker コンテナーが OpenShift で終了します。
  • その後、コンテナーが再作成されます。

abortOnSendFailure オプションを false に設定した場合、メッセージ送信エラーは無視されます。

6.2.111.2. config

producer.config プロパティーを使用して、プロデューサーの Kafka オプションを設定します。

config プロパティーには、Kafka MirrorMaker プロデューサー設定オプションが鍵として含まれ、値は以下の JSON タイプのいずれかに設定されます。

  • 文字列
  • 数値
  • ブール値

TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。また、 ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

例外

プロデューサー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。

しかし、以下に関連する AMQ Streams によって自動的に設定され、直接管理されるオプションには例外があります。

  • Kafka クラスターブートストラップアドレス
  • セキュリティー (暗号化、認証、および承認)
  • インターセプター

以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka MirrorMaker に渡されます。

重要

Cluster Operator では、提供された config オブジェクトのキーまたは値は検証されません。無効な設定が指定されると、Kafka MirrorMaker が起動しなかったり、不安定になったりする場合があります。このような場合、KafkaMirrorMaker.spec.producer.config オブジェクトの設定を修正し、Cluster Operator によって Kafka MirrorMaker の新しい設定がロールアウトされるようにします。

6.2.111.3. KafkaMirrorMakerProducerSpec スキーマプロパティー
プロパティー説明

bootstrapServers

Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。

string

abortOnSendFailure

送信失敗時に MirrorMaker が終了するように設定するフラグ。デフォルト値は true です。

boolean

authentication

クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, scram-sha-256, scram-sha-512, plain, oauth] のいずれかでなければなりません。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker プロデューサーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、sasl.、security.、interceptor.classes (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols).

map

tls

MirrorMaker をクラスターに接続するための TLS 設定。

ClientTls

6.2.112. KafkaMirrorMakerTemplate スキーマ参照

KafkaMirrorMakerSpec で使用

プロパティー説明

deployment

Kafka MirrorMaker Deployment のテンプレート。

DeploymentTemplate

Pod

Kafka MirrorMaker Pods のテンプレート。

PodTemplate

podDisruptionBudget

Kafka MirrorMaker PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

mirrorMakerContainer

Kafka MirrorMaker コンテナーのテンプレート。

ContainerTemplate

serviceAccount

Kafka MirrorMaker サービスアカウントのテンプレート。

ResourceTemplate

6.2.113. KafkaMirrorMakerStatus スキーマ参照

KafkaMirrorMaker で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

labelSelector

このリソースを提供する Pod のラベルセレクター。

string

replicas

このリソースを提供するために現在使用されている Pod の数。

integer

6.2.114. KafkaBridge スキーマ参照

プロパティー説明

spec

Kafka Bridge の仕様。

KafkaBridgeSpec

status

Kafka Bridge のステータス。

KafkaBridgeStatus

6.2.115. KafkaBridgeSpec スキーマ参照

KafkaBridge で使用

KafkaBridgeSpec スキーマプロパティーの全リスト

Kafka Bridge クラスターを設定します。

設定オプションは以下に関連しています。

  • Kafka クラスターブートストラップアドレス
  • セキュリティー (暗号化、認証、および承認)
  • コンシューマー設定
  • プロデューサーの設定
  • HTTP の設定
6.2.115.1. logging

Kafka Bridge には独自の設定可能なロガーがあります。

  • logger.bridge
  • logger.<operation-id>

logger.<operation-id> ロガーの <operation-id> を置き換えると、特定の操作のログレベルを設定できます。

  • createConsumer
  • deleteConsumer
  • subscribe
  • unsubscribe
  • poll
  • assign
  • commit
  • send
  • sendToPartition
  • seekToBeginning
  • seekToEnd
  • seek
  • healthy
  • ready
  • openapi

各操作は OpenAPI 仕様にしたがって定義されます。各操作にはブリッジが HTTP クライアントから要求を受信する対象の API エンドポイントがあります。各エンドポイントのログレベルを変更すると、送信および受信 HTTP リクエストに関する詳細なログ情報を作成できます。

各ロガーはその 名前http.openapi.operation.<operation-id> として割り当てる必要があります。たとえば、send 操作ロガーのロギングレベルを設定すると、以下が定義されます。

logger.send.name = http.openapi.operation.send
logger.send.level = DEBUG

Kafka Bridge では Apache log4j2 ロガー実装が使用されます。ロガーは log4j2.properties ファイルで定義されます。このファイルには healthy および ready エンドポイントの以下のデフォルト設定が含まれています。

logger.healthy.name = http.openapi.operation.healthy
logger.healthy.level = WARN
logger.ready.name = http.openapi.operation.ready
logger.ready.level = WARN

その他すべての操作のログレベルは、デフォルトで INFO に設定されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、カスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。namekey が設定されていない場合は、デフォルトのロギングが使用されます。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。ログレベルの詳細は、Apache logging services を参照してください。

ここで、inline および external ロギングの例を示します。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      logger.bridge.level: "INFO"
      # enabling DEBUG just for send operation
      logger.send.name: "http.openapi.operation.send"
      logger.send.level: "DEBUG"
  # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: bridge-logj42.properties
  # ...

設定されていない利用可能なロガーのレベルは OFF に設定されています。

Cluster Operator を使用して Kafka Bridge がデプロイされた場合、Kafka Bridge のロギングレベルの変更は動的に適用されます。

外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリング更新がトリガーされます。

ガベッジコレクター (GC)

ガベッジコレクターのロギングは jvmOptions プロパティーを使用して 有効 (または無効) にすることもできます。

6.2.115.2. KafkaBridgeSpec スキーマプロパティー
プロパティー説明

replicas

Deployment の Pod 数。

integer

image

Pod の Docker イメージ。

string

bootstrapServers

Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。

string

tls

Kafka Bridge をクラスターに接続するための TLS 設定。

ClientTls

authentication

クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, scram-sha-256, scram-sha-512, plain, oauth] のいずれかでなければなりません。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

http

HTTP 関連の設定。

KafkaBridgeHttpConfig

adminClient

Kafka AdminClient 関連の設定。

KafkaBridgeAdminClientSpec

consumer

Kafka コンシューマーに関連する設定。

KafkaBridgeConsumerSpec

producer

Kafka プロデューサーに関連する設定。

KafkaBridgeProducerSpec

resources

予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

jvmOptions

現時点でサポートされていない Pod の JVM オプション。

JvmOptions

logging

Kafka Bridge のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

clientRackInitImage

client.rack の初期化に使用される init コンテナーのイメージです。

string

rack

client.rack コンシューマー設定として使用されるノードラベルの設定。

Rack

enableMetrics

Kafka Bridge のメトリクスを有効にします。デフォルトは false です。

boolean

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

template

Kafka Bridge リソースのテンプレート。テンプレートを使用すると、ユーザーは DeploymentPod の生成方法を指定できます。

KafkaBridgeTemplate

tracing

Kafka Bridge でのトレースの設定。タイプは、指定のオブジェクト内の tracing.type プロパティーの値によって異なり、[jaeger, opentelemetry] の 1 つでなければなりません。

JaegerTracingOpenTelemetryTracing

6.2.116. KafkaBridgeHttpConfig スキーマ参照

KafkaBridgeSpec で使用

KafkaBridgeHttpConfig スキーマプロパティーの完全リスト

Kafka Bridge の Kafka クラスターへの HTTP アクセスを設定します。

デフォルトの HTTP 設定では、8080 番ポートで Kafka Bridge をリッスンします。

6.2.116.1. cors

HTTP プロパティーは、Kafka クラスターへの HTTP アクセスを有効にする他に、CPRS (Cross-Origin Resource Sharing) により Kafka Bridge のアクセス制御を有効化または定義する機能を提供します。CORS は、複数のオリジンから指定のリソースにブラウザーでアクセスできるようにする HTTP メカニズムです。CORS を設定するには、許可されるリソースオリジンのリストと、HTTP のアクセス方法を定義します。オリジンには、URL または Java 正規表現を使用できます。

Kafka Bridge HTTP の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
    port: 8080
    cors:
      allowedOrigins: "https://strimzi.io"
      allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
  # ...

6.2.116.2. KafkaBridgeHttpConfig スキーマプロパティー
プロパティー説明

port

サーバーがリッスンするポート。

integer

cors

HTTP Bridge の CORS 設定。

KafkaBridgeHttpCors

6.2.117. KafkaBridgeHttpCors スキーマ参照

KafkaBridgeHttpConfig で使用

プロパティー説明

allowedOrigins

許可されるオリジンのリスト。Java の正規表現を使用できます。

string array

allowedMethods

許可される HTTP メソッドのリスト。

string array

6.2.118. KafkaBridgeAdminClientSpec スキーマプロパティー

KafkaBridgeSpec で使用

プロパティー説明

config

ブリッジによって作成された AdminClient インスタンスに使用される Kafka AdminClient 設定。

map

6.2.119. KafkaBridgeConsumerSpec スキーマ参照

KafkaBridgeSpec で使用

KafkaBridgeConsumerSpec スキーマプロパティーの完全リスト

Kafka Bridge のコンシューマーオプションを鍵として設定します。

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプションを除き、コンシューマー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

  • ssl.
  • sasl.
  • security.
  • bootstrap.servers
  • group.id

禁止されているオプションの 1 つが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka に渡されます。

重要

config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。Cluster Operator が新しい設定をすべての Kafka Bridge ノードにロールアウトできるように設定を修正します。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。

Kafka Bridge コンシューマーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  consumer:
    config:
      auto.offset.reset: earliest
      enable.auto.commit: true
      ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      ssl.enabled.protocols: TLSv1.2
      ssl.protocol: TLSv1.2
      ssl.endpoint.identification.algorithm: HTTPS
    # ...

6.2.119.1. KafkaBridgeConsumerSpec スキーマプロパティー
プロパティー説明

config

ブリッジによって作成されたコンシューマーインスタンスに使用される Kafka コンシューマーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、group.id、sasl.、security. (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols).

map

6.2.120. KafkaBridgeProducerSpec スキーマ参照

KafkaBridgeSpec で使用

KafkaBridgeProducerSpec スキーマプロパティーの完全リスト

Kafka Bridge のプロデューサーオプションを鍵として設定します。

値は以下の JSON タイプのいずれかになります。

  • 文字列
  • 数値
  • ブール値

AMQ Streams で直接管理されるオプションを除き、プロデューサー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

  • ssl.
  • sasl.
  • security.
  • bootstrap.servers

禁止されているオプションの 1 つが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka に渡されます。

重要

config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。Cluster Operator が新しい設定をすべての Kafka Bridge ノードにロールアウトできるように設定を修正します。

禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。

Kafka Bridge プロデューサーの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  producer:
    config:
      acks: 1
      delivery.timeout.ms: 300000
      ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      ssl.enabled.protocols: TLSv1.2
      ssl.protocol: TLSv1.2
      ssl.endpoint.identification.algorithm: HTTPS
    # ...

6.2.120.1. KafkaBridgeProducerSpec スキーマプロパティー
プロパティー説明

config

ブリッジによって作成されたプロデューサーインスタンスに使用される Kafka プロデューサーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、sasl.、security. (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols).

map

6.2.121. KafkaBridgeTemplate スキーマ参照

KafkaBridgeSpec で使用

プロパティー説明

deployment

Kafka Bridge Deployment のテンプレート。

DeploymentTemplate

Pod

Kafka Bridge Pod のテンプレート。

PodTemplate

apiService

Kafka Bridge API Service のテンプレート。

InternalServiceTemplate

podDisruptionBudget

Kafka Bridge PodDisruptionBudget のテンプレート。

PodDisruptionBudgetTemplate

bridgeContainer

Kafka Bridge コンテナーのテンプレート。

ContainerTemplate

clusterRoleBinding

Kafka Bridge ClusterRoleBinding のテンプレート。

ResourceTemplate

serviceAccount

Kafka Bridge サービスアカウントのテンプレート。

ResourceTemplate

initContainer

Kafka Bridge init コンテナーのテンプレート。

ContainerTemplate

6.2.122. KafkaBridgeStatus スキーマ参照

KafkaBridge で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

url

外部クライアントアプリケーションが Kafka Bridge にアクセスできる URL。

string

labelSelector

このリソースを提供する Pod のラベルセレクター。

string

replicas

このリソースを提供するために現在使用されている Pod の数。

integer

6.2.123. KafkaConnector スキーマ参照

プロパティー説明

spec

Kafka Connector の仕様。

KafkaConnectorSpec

status

Kafka Connector のステータス。

KafkaConnectorStatus

6.2.124. KafkaConnectorSpec スキーマ参照

KafkaConnector で使用

プロパティー説明

class

Kafka Connector のクラス。

string

tasksMax

Kafka Connector のタスクの最大数。

integer

autoRestart

コネクターとタスク設定の自動再起動。

AutoRestart

config

Kafka Connector の設定。次のプロパティーは設定できません: connector.class、tasks.max

map

pause

コネクターを一時停止すべきかどうか。デフォルトは false です。

boolean

6.2.125. AutoRestart スキーマリファレンス

使用先: KafkaConnectorSpecKafkaMirrorMaker2ConnectorSpec

AutoRestart スキーマプロパティーの完全なリスト

FAILED 状態のコネクターとタスクの自動再起動を設定します。

有効にすると、バックオフアルゴリズムによって、失敗した各コネクターとそのタスクに自動再起動が適用されます。

オペレーターは、調整時に自動再始動を試みます。最初の試行が失敗した場合、オペレーターはさらに 6 回まで試行します。再起動の試行間隔が 2 分から 30 分に増加します。再起動するたびに、失敗したコネクターとタスクは FAILED から RESTARTING に遷移します。最後の試行後に再起動が失敗した場合は、コネクターの設定に問題がある可能性があります。コネクターとタスクは FAILED 状態のままであるため、手動で再起動する必要があります。これを行うには、KafKaConnector カスタムリソースに strimzi.io/restart: "true" のアノテーションを付けます。

Kafka Connect コネクターの場合、KafkaConnector リソースの autoRestart プロパティーを使用して、失敗したコネクターとタスクの自動再起動を有効にします。

Kafka Connect の失敗したコネクターの自動再起動の有効化

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
spec:
  autoRestart:
    enabled: true

MirrorMaker 2 の場合、KafkaMirrorMaker2 リソースのコネクターの autoRestart プロパティーを使用して、失敗したコネクターとタスクの自動再起動を有効にします。

MirrorMaker 2 の障害が発生したコネクターの自動再起動を有効にする

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mm2-cluster
spec:
  mirrors:
  - sourceConnector:
      autoRestart:
        enabled: true
      # ...
    heartbeatConnector:
      autoRestart:
        enabled: true
      # ...
    checkpointConnector:
      autoRestart:
        enabled: true
      # ...

6.2.125.1. AutoRestart スキーマプロパティー
プロパティー説明

enabled

失敗したコネクターとタスクの自動再起動を有効にするか無効にするか。

boolean

6.2.126. KafkaConnectorStatus スキーマ参照

KafkaConnector で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

autoRestart

自動再起動のステータス。

AutoRestartStatus

connectorStatus

Kafka Connect REST API によって報告されるコネクターのステータス。

map

tasksMax

Kafka Connector のタスクの最大数。

integer

topics

Kafka Connector によって使用されるトピックのリスト。

string array

6.2.127. AutoRestartStatus スキーマリファレンス

使用先: KafkaConnectorStatusKafkaMirrorMaker2Status

プロパティー説明

count

コネクターまたはタスクが再起動された回数。

integer

connectorName

再始動されるコネクターの名前。

string

lastRestartTimestamp

自動再起動が最後に試行された時刻。必須形式は、UTC タイムゾーンの 'yyyy-MM-ddTHH:mm:ssZ' です。

string

6.2.128. KafkaMirrorMaker2 スキーマ参照

プロパティー説明

spec

Kafka MirrorMaker 2 クラスターの仕様。

KafkaMirrorMaker2Spec

status

Kafka MirrorMaker 2 クラスターのステータス。

KafkaMirrorMaker2Status

6.2.129. KafkaMirrorMaker2Spec スキーマ参照

KafkaMirrorMaker2 で使用

プロパティー説明

version

Kafka Connect のバージョン。デフォルトは 3.4.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。

string

replicas

Kafka Connect グループの Pod 数。

integer

image

Pod の Docker イメージ。

string

connectCluster

Kafka Connect に使用されるクラスターエイリアス。エイリアスは spec.clusters にある一覧のクラスターと一致する必要があります。

string

clusters

ミラーリング用の Kafka クラスター。

KafkaMirrorMaker2ClusterSpec array

mirrors

MirrorMaker 2 コネクターの設定。

KafkaMirrorMaker2MirrorSpec array

resources

CPU とメモリーリソースおよび要求された初期リソースの上限。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。

ResourceRequirements

livenessProbe

Pod の liveness チェック。

Probe

readinessProbe

Pod の readiness チェック。

Probe

jvmOptions

Pod の JVM オプション。

JvmOptions

jmxOptions

JMX オプション。

KafkaJmxOptions

logging

Kafka Connect のロギング設定。タイプは、指定のオブジェクト内の logging.type プロパティーの値によって異なり、[inline、external] のいずれかでなければなりません。

InlineLoggingExternalLogging

clientRackInitImage

client.rack の初期化に使用される init コンテナーのイメージです。

string

rack

client.rack コンシューマー設定として使用されるノードラベルの設定。

Rack

tracing

Kafka Connect でのトレースの設定。タイプは、指定のオブジェクト内の tracing.type プロパティーの値によって異なり、[jaeger, opentelemetry] の 1 つでなければなりません。

JaegerTracingOpenTelemetryTracing

template

Kafka Connect および Kafka Mirror Maker 2 リソースのテンプレート。ユーザーはテンプレートにより、DeploymentPod および Service の生成方法を指定できます。

KafkaConnectTemplate

externalConfiguration

Secret または ConfigMap から Kafka Connect Pod にデータを渡し、これを使用してコネクターを設定します。

ExternalConfiguration

metricsConfig

メトリクスの設定。タイプは、指定のオブジェクト内の metricsConfig.type プロパティーの値によって異なり、[jmxPrometheusExporter] のいずれかでなければなりません。

JmxPrometheusExporterMetrics

6.2.130. KafkaMirrorMaker2ClusterSpec スキーマ参照

KafkaMirrorMaker2Spec で使用

KafkaMirrorMaker2ClusterSpec スキーマプロパティーの完全リスト

ミラーリング用の Kafka クラスターを設定します。

6.2.130.1. config

Kafka のオプションを設定するには、config プロパティーを使用します。

標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。

TLS バージョンの特定の 暗号スイート を使用するクライアント接続に、許可された ssl プロパティーを設定 することができます。また、 ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

6.2.130.2. KafkaMirrorMaker2ClusterSpec スキーマプロパティー
プロパティー説明

alias

Kafka クラスターの参照に使用されるエイリアス。

string

bootstrapServers

Kafka クラスターへの接続を確立するための host:port ペアのコンマ区切りリスト。

string

tls

MirrorMaker 2 コネクターをクラスターに接続するための TLS 設定。

ClientTls

authentication

クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の authentication.type プロパティーの値によって異なり、[tls, scram-sha-256, scram-sha-512, plain, oauth] のいずれかでなければなりません。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker 2 クラスター設定。次の接頭辞を持つプロパティーは設定できません: ssl.、sasl.、security.、listeners、plugin.path、rest.、bootstrap.servers、consumer.interceptor.classes、producer.interceptor.classes (ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols を除く)

map

6.2.131. KafkaMirrorMaker2MirrorSpec スキーマ参照

KafkaMirrorMaker2Spec で使用

プロパティー説明

sourceCluster

Kafka MirrorMaker 2 コネクターによって使用されるソースクラスターのエイリアス。エイリアスは spec.clusters にある一覧のクラスターと一致する必要があります。

string

targetCluster

Kafka MirrorMaker 2 コネクターによって使用されるターゲットクラスターのエイリアス。エイリアスは spec.clusters にある一覧のクラスターと一致する必要があります。

string

sourceConnector

Kafka MirrorMaker 2 ソースコネクターの仕様。

KafkaMirrorMaker2ConnectorSpec

heartbeatConnector

Kafka MirrorMaker 2 ハートビートコネクターの仕様。

KafkaMirrorMaker2ConnectorSpec

checkpointConnector

Kafka MirrorMaker 2 チェックポイントコネクターの仕様。

KafkaMirrorMaker2ConnectorSpec

topicsPattern

ミラーリングするトピックに一致する正規表現 (例: "topic1|topic2|topic3")。コンマ区切りリストもサポートされます。

string

topicsBlacklistPattern

topicsBlacklistPattern プロパティーは非推奨となり、.spec.mirrors.topicsExcludePattern を使用して設定する必要があります。ミラーリングから除外するトピックに一致する正規表現。コンマ区切りリストもサポートされます。

string

topicsExcludePattern

ミラーリングから除外するトピックに一致する正規表現。コンマ区切りリストもサポートされます。

string

groupsPattern

ミラーリングされるコンシューマーグループに一致する正規表現。コンマ区切りリストもサポートされます。

string

groupsBlacklistPattern

groupsBlacklistPattern プロパティーは非推奨となり、.spec.mirrors.groupsExcludePattern を使用して設定する必要があります。ミラーリングから除外するコンシューマーグループに一致する正規表現。コンマ区切りリストもサポートされます。

string

groupsExcludePattern

ミラーリングから除外するコンシューマーグループに一致する正規表現。コンマ区切りリストもサポートされます。

string

6.2.132. KafkaMirrorMaker2ConnectorSpec スキーマ参照

KafkaMirrorMaker2MirrorSpec で使用

プロパティー説明

tasksMax

Kafka Connector のタスクの最大数。

integer

config

Kafka Connector の設定。次のプロパティーは設定できません: connector.class、tasks.max

map

autoRestart

コネクターとタスク設定の自動再起動。

AutoRestart

pause

コネクターを一時停止すべきかどうか。デフォルトは false です。

boolean

6.2.133. KafkaMirrorMaker2Status スキーマ参照

KafkaMirrorMaker2 で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

url

Kafka Connect コネクターの管理および監視用の REST API エンドポイントの URL。

string

autoRestartStatuses

MirrorMaker 2 コネクターの自動再起動ステータスのリスト。

AutoRestartStatus 配列

connectorPlugins

この Kafka Connect デプロイメントで使用できるコネクタープラグインの一覧。

ConnectorPlugin array

connectors

Kafka Connect REST API によって報告される、MirrorMaker 2 コネクターのステータスのリスト。

map array

labelSelector

このリソースを提供する Pod のラベルセレクター。

string

replicas

このリソースを提供するために現在使用されている Pod の数。

integer

6.2.134. KafkaRebalance スキーマ参照

プロパティー説明

spec

Kafka のリバランス (再分散) の仕様。

KafkaRebalanceSpec

status

Kafka のリバランス (再分散) のステータス。

KafkaRebalanceStatus

6.2.135. KafkaRebalanceSpec スキーマ参照

KafkaRebalance で使用

プロパティー説明

mode

リバランスを実行するモード。サポートされているモードは fulladd-brokersremove-brokers です。指定しない場合、full モードがデフォルトで使用されます。

  • full モードでは、クラスター内のすべてのブローカーでリバランスが実行されます。
  • add-brokers モードは、クラスターをスケールアップした後に使用して、一部のレプリカを新しく追加されたブローカーに移動できます。
  • remove-brokers モードは、クラスターをスケールダウンして削除するブローカーからレプリカを移動する前に使用できます。

文字列 (remove-brokers、full、add-brokers のいずれか)

brokers

スケールアップの場合に新しく追加されたブローカーのリスト、またはリバランスに使用するためにスケールダウンの場合に削除されるブローカーのリスト。このリストは、リバランスモードの add-brokers および removed-brokers でのみ使用できます。これは、full モードで無視されます。

整数配列

goals

リバランスプロポーザルの生成および実行に使用されるゴールのリスト (優先度順)。サポートされるゴールは https://github.com/linkedin/cruise-control#goals を参照してください。空のゴールリストを指定すると、default.goals Cruise Control 設定パラメーターに宣言されたゴールが使用されます。

string array

skipHardGoalCheck

最適化プロポーザルの生成で、Kafka CR に指定されたハードゴールのスキップを許可するかどうか。これは、これらのハードゴールの一部が原因で分散ソリューションが検索できない場合に便利です。デフォルトは false です。

boolean

rebalanceDisk

ブローカー内のディスク分散を有効にし、同じブローカーのディスク間でディスク領域の使用率を分散します。ディスクが複数割り当てられた JBOD ストレージを使用する Kafka デプロイメントにのみ適用されます。有効にすると、ブローカー間の分散は無効になります。デフォルトは false です。

boolean

excludedTopics

一致するトピックが最適化プロポーザルの計算から除外される正規表現。この正規表現は java.util.regex.Pattern クラスによって解析されます。サポートされる形式の詳細は、このクラスのドキュメントを参照してください。

string

concurrentPartitionMovementsPerBroker

各ブローカーに出入りする継続中であるパーティションレプリカの移動の上限。デフォルトは 5 です。

integer

concurrentIntraBrokerPartitionMovements

各ブローカー内のディスク間で継続中のパーティションレプリカ移動の上限。デフォルトは 2 です。

integer

concurrentLeaderMovements

継続中のパーティションリーダーシップ移動の上限。デフォルトは 1000 です。

integer

replicationThrottle

レプリカの移動に使用される帯域幅の上限 (バイト/秒単位)。デフォルトでは制限はありません。

integer

replicaMovementStrategies

生成された最適化プロポーザルでのレプリカ移動の実行順序を決定するために使用されるストラテジークラス名のリスト。デフォルトでは、生成された順序でレプリカの移動が実行される BaseReplicaMovementStrategy が使用されます。

string array

6.2.136. KafkaRebalanceStatus スキーマ参照

KafkaRebalance で使用

プロパティー説明

conditions

ステータス条件の一覧。

Condition array

observedGeneration

最後に Operator によって調整された CRD の生成。

integer

sessionId

この KafkaRebalance リソースに関する Cruise Control へのリクエストのセッション識別子。これは、継続中のリバランス操作の状態を追跡するために、Kafka Rebalance operator によって使用されます。

string

optimizationResult

最適化の結果を示す JSON オブジェクト。

map

付録A サブスクリプションの使用

AMQ Streams は、ソフトウェアサブスクリプションから提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。

アカウントへのアクセス

  1. access.redhat.com に移動します。
  2. アカウントがない場合は、作成します。
  3. アカウントにログインします。

サブスクリプションのアクティベート

  1. access.redhat.com に移動します。
  2. My Subscriptions に移動します。
  3. Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。

Zip および Tar ファイルのダウンロード

zip または tar ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合は、この手順は必要ありません。

  1. ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
  2. INTEGRATION AND AUTOMATION カテゴリーで、AMQ Streams for Apache Kafka エントリーを見つけます。
  3. 必要な AMQ Streams 製品を選択します。Software Downloads ページが開きます。
  4. コンポーネントの Download リンクをクリックします。

DNF を使用したパッケージのインストール

パッケージとすべてのパッケージ依存関係をインストールするには、以下を使用します。

dnf install <package_name>

ローカルディレクトリーからダウンロード済みのパッケージをインストールするには、以下を使用します。

dnf install <path_to_download_package>

改訂日時: 2023-05-27

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.