検索

OpenShift でのAMQ Streams の設定

download PDF
Red Hat AMQ Streams 2.1

OpenShift ContainerPlatform での AMQ Streams 2.1のデプロイメントの設定および管理

概要

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. Kafkaブローカーに接続するためのリスナー設定

リスナーは、Kafka ブローカーへの接続に使用されます。AMQ Streamsは、Kafka リソースを介してリスナーを設定するためのプロパティを備えたジェネリックな GenericKafkaListener スキーマを提供しています。

GenericKafkaListener は、リスナー設定に柔軟なアプローチを提供します。プロパティーを指定して、OpenShift クラスター内で接続する 内部 リスナーを設定したり、OpenShift クラスター外部で接続する外部 リスナーを設定したりできます。

各リスナーは Kafka リソースの配列として定義されます。名前とポートが一意であれば、必要なリスナーをいくつでも設定できます。

たとえば、異なる認証メカニズムを必要とするネットワークからのアクセスを処理する場合などに、複数の外部リスナーを設定することがあります。また、OpenShift ネットワークを外部ネットワークに参加させる必要があることがあります。この場合、OpenShift サービスの DNS ドメイン (通常は.cluster.local) が使用されないように内部リスナーを構成することができます (useServiceDnsDomain プロパティを使用)。

リスナーで利用可能な設定オプションの詳細は、GenericKafkaListener schema reference を参照してください。

Kafka ブローカーへのアクセスをセキュアにするためのリスナー設定

リスナーを設定して、認証を使用したセキュアな接続を確立できます。詳細は、Kafkaブローカーへのアクセスの保護 を参照してください。

OpenShift 外部のクライアントアクセスに対する外部リスナーの設定

ロードバランサーなどの指定された接続メカニズムを使用して、OpenShift 環境外部のクライアントアクセスに対して外部リスナーを設定できます。外部クライアントを接続するための設定オプションの詳細は、OpenShiftクラスター外のクライアントからのKafkaへのアクセス を参照してください。

リスナー証明書

TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は Kafka リスナー証明書 を参照してください。

注記

外部リスナーの使用時に Kafka クラスターをスケーリングする場合、すべての Kafka ブローカーのローリングアップデートがトリガーされる可能性があります。これは設定によって異なります。

1.3. 本書の表記慣例

ユーザーが置き換えた値

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

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

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

1.4. 関連情報

第2章 Streams for Apache Kafka の設定

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

注記

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

Streams for Apache Kafka デプロイメントの監視

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

2.1. Kafka クラスターの設定

ここでは、AMQ Streams クラスターで Kafka デプロイメントを設定する方法を説明します。Kafka クラスターは ZooKeeper クラスターとデプロイされます。デプロイメントには、Kafka トピックおよびユーザーを管理する Topic Operator および User Operator も含まれます。

Kafka の設定は、Kafka リソースを使って行います。設定オプションは、Kafka リソース内の ZooKeeper および Entity Operator でも利用できます。Entity Operator は Topic Operator と User Operator で構成されます。

Kafka リソースの完全なスキーマは Kafka スキーマ参照」 に記載されています。Apache Kafka の詳細については、Apache Kafka のドキュメント を参照してください。

リスナーの設定

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

Kafka へのアクセスの承認

ユーザーが実行するアクションを許可または拒否するように Kafka クラスターを設定できます。詳細は、Kafkaブローカーへのアクセスの保護 を参照してください。

TLS 証明書の管理

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

2.1.1. Kafka の設定

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

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

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

  • リソース要求 (CPU/メモリー)
  • 最大および最小メモリー割り当ての JVM オプション
  • リスナー (およびクライアントの認証)
  • 認証
  • ストレージ
  • ラックアウェアネス (Rack Awareness)
  • メトリクス
  • 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.1.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.1"
          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
        # ...
        tlsSidecar: 35
        # ...
    1
    レプリカノードの数。クラスターにトピックがすでに定義されている場合は、クラスターをスケーリング できます。
    2
    Kafka バージョン。アップグレード手順 に従うと、サポート対象のバージョンに変更できます。
    3
    指定された Kafka loggers and log levels が ConfigMap を介して直接的 (inline) または間接的 (external) に追加されます。カスタム 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 として、または external リスナーに対して指定されるリスナータイプ (routeloadbalancernodeport、または ingress)。
    12
    各リスナーの TLS 暗号化を有効にします。デフォルトは false です。route リスナーに TLS 暗号化は必要ありません。
    13
    クラスターサービスサフィックス (通常は cluster.local) を含む完全修飾 DNS 名が割り当てられているかどうかを定義します。
    14
    15
    16
    外部の認証局によって管理される Kafka リスナー証明書 の任意設定。brokerCertChainAndKey は、サーバー証明書および秘密鍵が含まれる Secret を指定します。TLS による暗号化が有効な任意のリスナーで Kafka リスナー証明書を設定できます。
    17
    承認は Kafka ブローカーで簡易、OAUTH2.0、または OPA 承認を有効化 します。簡易承認では、AclAuthorizer Kafka プラグインが使用されます。
    18
    19
    20
    Storageephemeralpersistent-claimjbod のいずれかに設定されています。
    21
    22
    永続ストレージには、動的ボリュームプロビジョニングのためのストレージ idclass など、追加の設定オプション があります。
    23
    ラックアウェアネス (Rack awareness) は、異なるラック全体でレプリカを分散するために設定されます。topologykey はクラスターノードのラベルと一致する必要があります。
    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 ブローカーから抽出する任意のコンポーネントです。
    34
    Kafka クラスターのリバランス に使用される Cruise Control の任意設定。
    35
    Cruise Conrol の TLS サイドカーの設定。Cruise Control は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

2.1.2. Entity Operator の設定

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

Entity Operator は以下で構成されます。

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

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

注記

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

これらの operator は、Kafka クラスターのトピックおよびユーザーを管理するために自動的に設定されます。

2.1.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.1.2.2. Topic Operator 設定プロパティー

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

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

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.1.2.3. User Operator 設定プロパティー

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

watchedNamespace
User Operator によって KafkaUsers が監視される OpenShift namespace。デフォルトは、Kafka クラスターがデプロイされた namespace です。
reconciliationIntervalSeconds
定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは 120 です。
image
image プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、image を参照してください。
resources
resources プロパティーを使用すると、User Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、resources を参照してください。
ログ
logging プロパティーは、User Operator のロギングを設定します。詳細は ログ を参照してください。
secretPrefix
secretPrefix プロパティーは、KafkaUser リソースから作成されたすべての Secret の名前にプレフィックスを追加します。例えば、STRIMZI_SECRET_PREFIX=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.1.3. Kafka および ZooKeeper のストレージタイプ

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

  • 一時ストレージ
  • 永続ストレージ
  • JBOD ストレージ
注記

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

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

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

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

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

警告

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

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

効率的なデータストレージインフラストラクチャーは、AMQ Streams のパフォーマンスを最適化するために不可欠です。

ブロックストレージが必要です。NFS などのファイルストレージは、Kafka では機能しません。

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

注記

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

2.1.3.1.1. ファイルシステム

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

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

2.1.3.1.2. Apache Kafka および ZooKeeper ストレージ

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

3 つのタイプのデータストレージがサポートされます。

  • 一時データストレージ (開発用のみで推奨されます)
  • 永続ストレージ
  • JBOD (Just a Bunch of Disks、Kafka のみに適しています)

詳細は Kafka および ZooKeeper ストレージ を参照してください。

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

注記

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

2.1.3.2. 一時ストレージ

一時ストレージは emptyDir ボリュームを使用してデータを保存します。一時ストレージを使用するには、type フィールドを ephemeral に設定します。

重要

emptyDir ボリュームは永続的ではなく、保存されたデータは Pod の再起動時に失われます。新規 Pod の起動後に、クラスターの他のノードからすべてのデータを復元する必要があります。一時ストレージは、単一ノードの ZooKeeper クラスターやレプリケーション係数が 1 の Kafka トピックでの使用には適していません。この設定により、データが失われます。

一時ストレージの例

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

2.1.3.2.1. ログディレクトリー

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

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

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

2.1.3.3. 永続ストレージ

永続ストレージは Persistent Volume Claim (永続ボリューム要求、PVC) を使用して、データを保存するための永続ボリュームをプロビジョニングします。永続ボリューム要求を使用すると、ボリュームのプロビジョニングを行う ストレージクラス に応じて、さまざまなタイプのボリュームをプロビジョニングできます。永続ボリューム要求と使用できるデータタイプには、多くのタイプの SAN ストレージや ローカル永続ボリューム などがあります。

永続ストレージを使用するには、typepersistent-claim に設定する必要があります。永続ストレージでは、追加の設定オプションがサポートされます。

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

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

size が 1000Gi の永続ストレージ設定の例 (抜粋)

# ...
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.1.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:
      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
  # ...
  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.1.3.3.2. 永続ボリューム要求の命名

永続ストレージが使用されると、以下の名前で永続ボリューム要求が作成されます。

data-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。
data-cluster-name-zookeeper-idx
ZooKeeper ノード Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。
2.1.3.3.3. ログディレクトリー

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

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

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

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

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

注記

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

前提条件

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

手順

  1. Kafka リソースで、Kafka クラスター、ZooKeeper クラスター、またはその両方に割り当てられた永続ボリュームのサイズを増やします。

    • Kafka クラスターに割り当てられたボリュームサイズを増やすには、spec.kafka.storage プロパティーを編集します。
    • ZooKeeper クラスターに割り当てたボリュームサイズを増やすには、spec.zookeeper.storage プロパティーを編集します。

      たとえば、ボリュームサイズを 1000Gi から 2000Gi に増やすには、以下のように編集します。

      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 によって再起動されます。これは自動的に行われます。

関連情報

2.1.3.5. JBOD ストレージの概要

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

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

2.1.3.5.1. JBOD の設定

AMQ Streams で JBOD を使用するには、ストレージ typejbod に設定する必要があります。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
# ...

id は、JBOD ボリュームの作成後に変更することはできません。

ユーザーは JBOD 設定に対してボリュームを追加または削除できます。

2.1.3.5.2. JBOD および 永続ボリューム要求

永続ストレージを使用して JBOD ボリュームを宣言する場合、永続ボリューム要求の命名スキームは以下のようになります。

data-id-cluster-name-kafka-idx
id は、Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの ID に置き換えます。
2.1.3.5.3. ログディレクトリー

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

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

2.1.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. 新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てます。

関連情報

トピックの再割り当てについて、詳しくは 「パーティション再割り当てツール」 を参照してください。

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

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

重要

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

前提条件

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

手順

  1. 削除するディスクからすべてのパーティションを再度割り当てます。削除するディスクに割り当てられたままになっているパーティションのデータは削除される可能性があります。
  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.1.4. クラスターのスケーリング

ブローカーを追加または削除して、Kafka クラスターをスケーリングします。クラスターにトピックがすでに定義されている場合は、パーティションを再度割り当てる必要があります。

kafka-reassign-partitions.sh ツールを使用して、パーティションを再度割り当てます。このツールは、再割り当てを行うトピックを指定する再割り当て JSON ファイルを使用します。

特定のパーティションを移動させたい場合は、再割り当て JSON ファイルを生成するか、手動でファイルを作成します。

2.1.4.1. ブローカーのスケーリング設定

Kafka.spec.kafka.replicas の設定を行い、ブローカーの数を追加または削減します。

ブローカーの追加

トピックのスループットを向上させる主な方法は、そのトピックのパーティション数を増やすことです。これにより、追加のパーティションによってクラスター内の異なるブローカー間でトピックの負荷が共有されます。ただし、各ブローカーが特定のリソース (通常は I/O) によって制約される場合、パーティションを増やしてもスループットは向上しません。代わりに、ブローカーをクラスターに追加する必要があります。

ブローカーをクラスターに追加する場合、Kafka ではパーティションは自動的に割り当てられません。どのパーティションを既存のブローカーから新しいブローカーに再割り当てするかを決めなければなりません。

すべてのブローカーの間でパーティションが再分配されると、各ブローカーのリソース使用量が減少します。

ブローカーの削除

StatefulSets を使用してブローカー Pod を管理する場合、クラスターから任意の Pod を削除することはできません。クラスターから削除できるのは、番号が最も大きい 1 つまたは複数の Pod のみです。たとえば、12 個のブローカーがあるクラスターでは、Pod の名前は cluster-name-kafka-0 から cluster-name-kafka-11 になります。1 つのブローカー分をスケールダウンする場合、cluster-name-kafka-11 が削除されます。

クラスターからブローカーを削除する前に、そのブローカーにパーティションが割り当てられていないことを確認します。また、使用が停止されたブローカーの各パーティションを引き継ぐ、残りのブローカーを決める必要もあります。ブローカーに割り当てられたパーティションがなければ、クラスターを安全にスケールダウンできます。

2.1.4.2. パーティション再割り当てツール

現在、Topic Operator は別のブローカーへのレプリカの再割り当てをサポートしていないため、ブローカー Pod に直接接続してレプリカをブローカーに再度割り当てる必要があります。

ブローカー Pod 内では、kafka-reassign-partitions.sh ツールを使用して、パーティションを異なるブローカーに再度割り当てることができます。

これには、以下の 3 つのモードがあります。

--generate
トピックとブローカーのセットを取得し、再割り当て JSON ファイル を生成します。これにより、トピックのパーティションがブローカーに割り当てられます。これはトピック全体で動作するため、一部のトピックのパーティションを再度割り当てる場合は使用できません。
--execute
再割り当て JSON ファイル を取得し、クラスターのパーティションおよびブローカーに適用します。その結果、パーティションを取得したブローカーは、パーティションリーダーのフォロワーになります。新規ブローカーが ISR (同期レプリカ) に参加できたら、古いブローカーはフォロワーではなくなり、そのレプリカが削除されます。
--verify
--verify は、--execute ステップと同じ 再割り当て JSON ファイル を使用して、ファイル内のすべてのパーティションが目的のブローカーに移動されたかどうかをチェックします。再割り当てが完了すると、--verify は有効なトラフィックスロットル (--throttle) も削除します。スロットルを削除しないと、再割り当てが完了した後もクラスターは影響を受け続けます。

クラスターでは、1 度に 1 つの再割り当てのみを実行でき、実行中の再割り当てをキャンセルすることはできません。再割り当てをキャンセルする必要がある場合は、割り当てが完了するのを待ってから別の再割り当てを実行し、最初の再割り当ての結果を元に戻します。kafka-reassign-partitions.sh によって、元に戻すための再割り当て JSON が出力の一部として生成されます。大規模な再割り当ては、進行中の再割り当てを停止する必要がある場合に備えて、複数の小さな再割り当てに分割するようにしてください。

2.1.4.2.1. パーティション再割り当ての JSON ファイル

再割り当て JSON ファイル には特定の構造があります。

{
  "version": 1,
  "partitions": [
    <PartitionObjects>
  ]
}

ここで <PartitionObjects> は、以下のようなコンマ区切りのオブジェクトリストになります。

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ]
}
注記

Kafka は "log_dirs" プロパティーもサポートしますが、AMQ Streams では使用しないでください。

以下は、トピック topic-a のパーティション 4 をブローカー 247 に割り当て、トピック topic-b のパーティション 2 をブローカー 157 に割り当てる再割り当て JSON ファイルの例です。

パーティション再割り当てファイルの例

{
  "version": 1,
  "partitions": [
    {
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7]
    },
    {
      "topic": "topic-b",
      "partition": 2,
      "replicas": [1,5,7]
    }
  ]
}

JSON に含まれていないパーティションは変更されません。

2.1.4.2.2. JBOD ボリューム間のパーティション再割り当て

Kafka クラスターで JBOD ストレージを使用する場合は、特定のボリュームとログディレクトリー (各ボリュームに単一のログディレクトリーがある) との間でパーティションの再割り当てを選択することができます。パーティションを特定のボリュームに再割り当てするには、再割り当て JSON ファイルで log_dirs オプションを <PartitionObjects> に追加します。

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ],
  "log_dirs": [ <AssignedLogDirs> ]
}

log_dirs オブジェクトに含まれるログディレクトリーの数は、replicas オブジェクトで指定されるレプリカ数と同じである必要があります。値は、ログディレクトリーへの絶対パスか、any キーワードである必要があります。

ログディレクトリーを指定するパーティション再割り当てファイルの例

{
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7].
      "log_dirs": [ "/var/lib/kafka/data-0/kafka-log2", "/var/lib/kafka/data-0/kafka-log4", "/var/lib/kafka/data-0/kafka-log7" ]
}

パーティション再割り当てスロットリングの適用

パーティションの再割り当てには、ブローカーの間で大量のデータを転送する必要があるため、処理が遅くなる可能性があります。クライアントへの悪影響を防ぐため、再割り当て処理をススロットルできます。--throttle パラメーターを kafka-reassign-partitions.sh ツールと共に使用して、再割り当てをスロットルします。ブローカー間のパーティションの移動の最大しきい値をバイト単位で指定します。たとえば --throttle 5000000 は、パーティションを移動する最大しきい値を 50 MBps に設定します。

スロットリングにより、再割り当ての完了に時間がかかる場合があります。

  • スロットルが低すぎると、新たに割り当てられたブローカーは公開されるレコードに対応できず、再割り当ては完了しません。
  • スロットルが高すぎると、クライアントに影響します。

たとえば、プロデューサーの場合は、確認応答を待つ通常のレイテンシーよりも高い可能性があります。コンシューマーの場合は、ポーリング間のレイテンシーが大きいことが原因でスループットが低下する可能性があります。

2.1.4.3. 再割り当て JSON ファイルの生成

この手順では、再割り当て JSON ファイルを生成する方法を説明します。kafka-reassign-partitions.sh ツールと共に再割り当てファイルを使用して、Kafka クラスターのスケーリング後にパーティションの再割り当てを実行します。

この手順では、TLS を使用するセキュアな再割り当てプロセスを説明します。TLS による暗号化および認証を使用する Kafka クラスターが必要です。

前提条件

  • Cluster Operator が実行中である。
  • 内部 TLS 認証および暗号化で設定された Kafka リソースを基にして Kafka クラスターが稼働中である。

    TLS での Kafka 設定

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        listeners:
          # ...
          - name: tls
            port: 9093
            type: internal
            tls: true 1
            authentication:
              type: tls 2
        # ...

    1
    内部リスナーの TLS 暗号化を有効にします。
    2
    相互 TLS として指定 されるリスナー認証メカニズム。
  • 稼働中の Kafka クラスターには、再割り当てするトピックおよびパーティションのセットが含まれます。

    my-topic のトピック設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaTopic
    metadata:
      name: my-topic
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      partitions: 10
      replicas: 3
      config:
        retention.ms: 7200000
        segment.bytes: 1073741824
        # ...

  • Kafka ブローカーからトピックを生成および使用するパーミッションを指定する ACL ルールとともに KafkaUser が設定されています。

    my-topic および my-cluster での操作を許可する ACL ルールを使用した Kafka ユーザーの設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication: 1
        type: tls
      authorization:
        type: simple 2
        acls:
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: cluster
              name: my-cluster
              patternType: literal
            operation: Alter
            host: "*"
          # ...
      # ...

    1
    相互 tls として定義されたユーザー認証メカニズム。
    2
    ACL ルールの承認および付随するリスト。
    注記

    トピックへのTLSアクセスには、最低でも Describe 操作のパーミッションが必要です。

手順

  1. Kafka クラスタの <cluster_name>-cluster-ca-cert シークレットからクラスタ CA 証明書とパスワードを抽出します。

    oc get secret <cluster_name>-cluster-ca-cert -o jsonpath='{.data.ca\.p12}' | base64 -d > ca.p12
    oc get secret <cluster_name>-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 -d > ca.password

    <cluster_name> は、Kafka クラスターの名前に置き換えます。Kafka リソースを使用して Kafka をデプロイすると、Kafka クラスタ名 (<cluster_name>-cluster-ca-cert) でクラスタ CA 証明書のシークレットが作成されます。例: my-cluster-cluster-ca-cert

  2. AMQ Streams の Kafka イメージを使用してインタラクティブな Pod コンテナーを新たに実行し、稼働中の Kafka ブローカーに接続します。

    oc run --restart=Never --image=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 <interactive_pod_name> -- /bin/sh -c "sleep 3600"

    <interactive_pod_name> は Pod の名前に置き換えます。

  3. クラスター CA 証明書をインタラクティブな Pod コンテナーにコピーします。

    oc cp ca.p12 <interactive_pod_name>:/tmp
  4. Kafka ブローカーへのアクセス権限を持つ Kafka ユーザーのシークレットから、ユーザー CA 証明書およびパスワードを抽出します。

    oc get secret <kafka_user> -o jsonpath='{.data.user\.p12}' | base64 -d > user.p12
    oc get secret <kafka_user> -o jsonpath='{.data.user\.password}' | base64 -d > user.password

    <kafka_user> は Kafka ユーザーの名前に置き換えます。KafkaUser リソースを使用して Kafka ユーザーを作成すると、ユーザー CA 証明書のあるシークレットが Kafka ユーザー名で作成されます。例: my-user

  5. ユーザー CA 証明書をインタラクティブな Pod コンテナーにコピーします。

    oc cp user.p12 <interactive_pod_name>:/tmp

    CA 証明書を使用すると、インタラクティブな Pod コンテナーが TLS を使用して Kafka ブローカーに接続できます。

  6. config.properties ファイルを作成し、Kafka クラスターへの認証に使用されるトラストストアおよびキーストアを指定します。

    前の手順で展開した証明書とパスワードを使用します。

    bootstrap.servers=<kafka_cluster_name>-kafka-bootstrap:9093 1
    security.protocol=SSL 2
    ssl.truststore.location=/tmp/ca.p12 3
    ssl.truststore.password=<truststore_password> 4
    ssl.keystore.location=/tmp/user.p12 5
    ssl.keystore.password=<keystore_password> 6
    1
    Kafka クラスターに接続するためのブートストラップサーバーアドレス。独自の Kafka クラスター名を使用して、<kafka_cluster_name> を置き換えます。
    2
    暗号化に TLS を使用する場合のセキュリティープロトコルオプション。
    3
    トラストストアの場所には、Kafka クラスターの公開鍵証明書 (ca.p12) が含まれます。
    4
    トラストストアにアクセスするためのパスワード (ca.password)。
    5
    キーストアの場所には、Kafka ユーザーの公開鍵証明書 (user.p12) が含まれます。
    6
    キーストアにアクセスするためのパスワード (user.password)。
  7. config.properties ファイルをインタラクティブな Pod コンテナーにコピーします。

    oc cp config.properties <interactive_pod_name>:/tmp/config.properties
  8. 移動するトピックを指定する topics.json という名前の JSON ファイルを準備します。

    トピック名をカンマ区切りの一覧として指定します。

    topic-a および topic-b のすべてのパーティションを再割り当てする JSON ファイルの例

    {
      "version": 1,
      "topics": [
        { "topic": "topic-a"},
        { "topic": "topic-b"}
      ]
    }

  9. topics.json ファイルをインタラクティブな Pod コンテナーにコピーします。

    oc cp topics.json <interactive_pod_name>:/tmp/topics.json
  10. インタラクティブな Pod コンテナーでシェルプロセスを開始します。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace> を Pod が実行されている OpenShift namespace に置き換えます。

  11. kafka-reassign-partitions.sh コマンドを使用して、再割り当て JSON を生成します。

    topic-atopic-b のすべてのパーティションをブローカー 012 に移動させるコマンド例

    bin/kafka-reassign-partitions.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --topics-to-move-json-file /tmp/topics.json \
      --broker-list 0,1,2 \
      --generate

2.1.4.4. Kafka クラスターのスケールアップ

再割り当てファイルを使用して、Kafka クラスター内のブローカーの数を増やします。

再割り当てファイルには、拡大された Kafka クラスター内のブローカーにパーティションを再度割り当てる方法を記述する必要があります。

この手順では、TLS を使用する安全なスケーリングプロセスについて説明します。TLS による暗号化および認証を使用する Kafka クラスターが必要です。

前提条件

  • 内部 TLS 認証および暗号化で設定された Kafka リソースを基にして Kafka クラスターが稼働中である。
  • reassignment.jsonという名前の再割り当てJSONファイルを生成している。
  • 実行中の Kafka ブローカーに接続されている対話型 Pod コンテナーを実行している。
  • KafkaUserとして接続されている。このユーザーは、Kafka クラスターとそのトピックの管理権限を指定する ACL ルールで設定されていること。

再割り当て JSON ファイルの生成 を参照してください。

手順

  1. kafka.spec.kafka.replicas 設定オプションを増やして、新しいブローカーを必要なだけ追加します。
  2. 新しいブローカー Pod が起動したことを確認します。
  3. まだ確認していない場合には、インタラクティブな Pod コンテナーを実行 して reassignment.json という名前の再割り当てJSONファイルを生成します。
  4. reassignment.json ファイルをインタラクティブな Pod コンテナにコピーします。

    oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json

    <interactive_pod_name> は Pod の名前に置き換えます。

  5. インタラクティブな Pod コンテナーでシェルプロセスを開始します。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace> を Pod が実行されている OpenShift namespace に置き換えます。

  6. インタラクティブな Pod コンテナから kafka-reassign-partitions.sh スクリプトを使用して、パーティションの再割り当てを実行します。

    bin/kafka-reassign-partitions.sh --bootstrap-server
     <cluster_name>-kafka-bootstrap:9093 \
     --command-config /tmp/config.properties \
     --reassignment-json-file /tmp/reassignment.json \
     --execute

    <cluster_name> は、Kafka クラスターの名前に置き換えます。例: my-cluster-kafka-bootstrap:9093

    レプリケーションにスロットリングを適用する場合、--throttle とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下はその例です。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 5000000 \
      --execute

    このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡したターゲットの再割り当てです。

    再割り当ての最中にスロットルを変更する必要がある場合は、同じコマンドに別のスロットル率を指定して実行します。以下はその例です。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 10000000 \
      --execute
  7. ブローカー Pod のいずれかから kafka-reassign-partitions.sh コマンドラインツールを使用して、再割り当てが完了したかどうかを確認します。これは先ほどの手順と同じコマンドですが、--verify オプションの代わりに --execute オプションを使用します。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --verify

    --verify コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な --verify によって、結果的に再割り当てスロットルも削除されます。

  8. 割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。

2.1.4.5. Kafka クラスターのスケールダウン

再割り当てファイルを使用して、Kafka クラスター内のブローカーの数を減らします。

再割り当てファイルでは、Kafka クラスターの残りのブローカーにパーティションを再割り当てする方法を記述する必要があります。最も番号の大きい Pod のブローカーが最初に削除されます。

この手順では、TLS を使用する安全なスケーリングプロセスについて説明します。TLS による暗号化および認証を使用する Kafka クラスターが必要です。

前提条件

  • 内部 TLS 認証および暗号化で設定された Kafka リソースを基にして Kafka クラスターが稼働中である。
  • reassignment.jsonという名前の再割り当てJSONファイルを生成している。
  • 実行中の Kafka ブローカーに接続されている対話型 Pod コンテナーを実行している。
  • KafkaUserとして接続されている。このユーザーは、Kafka クラスターとそのトピックの管理権限を指定する ACL ルールで設定されている。

再割り当て JSON ファイルの生成 を参照してください。

手順

  1. まだ確認していない場合には、インタラクティブな Pod コンテナーを実行 して reassignment.json という名前の再割り当てJSONファイルを生成します。
  2. reassignment.json ファイルをインタラクティブな Pod コンテナにコピーします。

    oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json

    <interactive_pod_name> は Pod の名前に置き換えます。

  3. インタラクティブな Pod コンテナーでシェルプロセスを開始します。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace> を Pod が実行されている OpenShift namespace に置き換えます。

  4. インタラクティブな Pod コンテナーから kafka-reassign-partitions.sh スクリプトを使用して、パーティションの再割り当てを実行します。

    bin/kafka-reassign-partitions.sh --bootstrap-server
     <cluster_name>-kafka-bootstrap:9093 \
     --command-config /tmp/config.properties \
     --reassignment-json-file /tmp/reassignment.json \
     --execute

    <cluster_name> は、Kafka クラスターの名前に置き換えます。例: my-cluster-kafka-bootstrap:9093

    レプリケーションにスロットリングを適用する場合、--throttle とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下はその例です。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 5000000 \
      --execute

    このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡したターゲットの再割り当てです。

    再割り当ての最中にスロットルを変更する必要がある場合は、同じコマンドに別のスロットル率を指定して実行します。以下はその例です。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 10000000 \
      --execute
  5. ブローカー Pod のいずれかから kafka-reassign-partitions.sh コマンドラインツールを使用して、再割り当てが完了したかどうかを確認します。これは先ほどの手順と同じコマンドですが、--verify オプションの代わりに --execute オプションを使用します。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --verify

    --verify コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な --verify によって、結果的に再割り当てスロットルも削除されます。

  6. 割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。
  7. すべてのパーティションの再割り当てが終了すると、削除されるブローカーはクラスター内のいずれのパーティションにも対応しないはずです。これは、ブローカーのデータログディレクトリーにライブパーティションのログが含まれていないことを確認すると検証できます。ブローカーのログディレクトリーに、拡張正規表現 [a-zA-Z0-9.-]+\.[a-z0-9]+-delete$ と一致しないディレクトリーが含まれる場合、ブローカーにはライブパーティションがあるため、停止してはなりません。

    これを確認するには、以下のコマンドを実行します。

    oc exec my-cluster-kafka-0 -c kafka -it -- \
      /bin/bash -c \
      "ls -l /var/lib/kafka/kafka-log_<n>_ | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'"

    n は削除された Pod の数に置き換えます。

    上記のコマンドによって出力が生成される場合、ブローカーにはライブパーティションがあります。この場合、再割り当てが終了していないか、再割り当て JSON ファイルが適切ではありません。

  8. ブローカーにライブパーティションがないことを確認できたら、Kafka リソースの Kafka.spec.kafka.replicas プロパティーを編集してブローカーの数を減らすことができます。

2.1.5. ローリングアップデートのメンテナンス時間枠

メンテナンス時間枠によって、Kafka および ZooKeeper クラスターの特定のローリングアップデートが便利な時間に開始されるようにスケジュールできます。

2.1.5.1. メンテナンス時間枠の概要

ほとんどの場合、Cluster Operator は対応する Kafka リソースの変更に対応するために Kafka または ZooKeeper クラスターのみを更新します。これにより、Kafka リソースの変更を適用するタイミングを計画し、Kafka クライアントアプリケーションへの影響を最小限に抑えることができます。

ただし、Kafka リソースの変更がなくても Kafka および ZooKeeper クラスターの更新が発生することがあります。たとえば、Cluster Operator によって管理される CA (認証局) 証明書が期限切れ直前である場合にローリング再起動の実行が必要になります。

サービスの 可用性 は Pod のローリング再起動による影響を受けないはずですが (ブローカーおよびトピックの設定が適切である場合)、Kafka クライアントアプリケーションの パフォーマンス は影響を受ける可能性があります。メンテナンス時間枠によって、Kafka および ZooKeeper クラスターのこのような自発的なアップデートが便利な時間に開始されるようにスケジュールできます。メンテナンス時間枠がクラスターに設定されていない場合は、予測できない高負荷が発生する期間など、不便な時間にこのような自発的なローリングアップデートが行われる可能性があります。

2.1.5.2. メンテナンス時間枠の定義

Kafka.spec.maintenanceTimeWindows プロパティーに文字列の配列を入力して、メンテナンス時間枠を設定します。各文字列は、UTC (協定世界時、Coordinated Universal Time) であると解釈される cron 式 です。UTC は実用的にはグリニッジ標準時と同じです。

以下の例では、日、月、火、水、および木曜日の午前 0 時に開始し、午前 1 時 59 分 (UTC) に終わる、単一のメンテナンス時間枠が設定されます。

# ...
maintenanceTimeWindows:
  - "* * 0-1 ? * SUN,MON,TUE,WED,THU *"
# ...

実際には、必要な CA 証明書の更新が設定されたメンテナンス時間枠内で完了できるように、Kafka リソースの Kafka.spec.clusterCa.renewalDays および Kafka.spec.clientsCa.renewalDays プロパティーとともにメンテナンス期間を設定する必要があります。

注記

AMQ Streams では、指定の期間にしたがってメンテナンス操作を正確にスケジュールしません。その代わりに、調整ごとにメンテナンス期間が現在「オープン」であるかどうかを確認します。これは、特定の時間枠内でのメンテナンス操作の開始が、最大で Cluster Operator の調整が行われる間隔の長さ分、遅れる可能性があることを意味します。したがって、メンテナンス時間枠は最低でもその間隔の長さにする必要があります。

関連情報

2.1.5.3. メンテナンス時間枠の設定

サポートされるプロセスによってトリガーされるローリングアップデートのメンテナンス時間枠を設定できます。

前提条件

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

手順

  1. Kafka リソースの maintenanceTimeWindows プロパティー を追加または編集します。たとえば、0800 から 1059 までと、1400 から 1559 までのメンテナンスを可能にするには、以下のように maintenanceTimeWindows を設定します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
      zookeeper:
        # ...
      maintenanceTimeWindows:
        - "* * 8-10 * * ?"
        - "* * 14-15 * * ?"
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

関連情報

ローリングアップデートの実行:

2.1.6. ターミナルからの 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.1.7. 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.1.8. 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.1.9. 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 を管理する StatefulSet または StrimziPodSet (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 を管理する StatefulSet または StrimziPodSet (UseStrimziPodSets フィーチャーゲート が有効になっている場合)。
  • Kafka Pod によって使用されるサービスアカウント。
  • Kafka ブローカーに設定された PodDisruptionBudget。
cluster-name-kafka-idx
Kafka StatefulSet または StrimziPodSet によって作成された Pod。
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 補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
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.2. Kafka Connect クラスターの設定

このセクションでは、AMQ StreamsクラスターでKafka Connectのデプロイメントを構成する方法について説明します。

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

コネクタプラグインのデプロイの詳細は コネクタプラグインを使用した Kafka Connectの拡張 を参照してください。

2.2.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 プロパティで指定します。

コネクターを管理するには、Kafka Connect REST API を使用するか、KafkaConnector カスタムリソースを使用します。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/1.3.1.Final/debezium-connector-postgres-1.3.1.Final-plugin.tar.gz
                sha512sum: 962a12151bdf9a5a30627eebac739955a4fd95a08d373b86bdcea2b4d0c27dd6e1edd5cb548045e115e33a9e69b1b2a352bee24df035a0447cb820077af00c03
          - name: camel-telegram
            artifacts:
              - type: tgz
                url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.7.0/camel-telegram-kafka-connector-0.7.0-package.tar.gz
                sha512sum: a9b1ac63e3284bea7836d7d24d84208c49cdf5600070e6bd1535de654f6920b74ad950d51733e8020bf4187870699819f54ef5859c7846ee4081507f48873479
      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
    OAuth ベアラートークン、SASL ベースの SCRAM-SHA-256/SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、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 はクラスターノードのラベルと一致する必要があります。
    19
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    20
  2. リソースを作成または更新します。

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

2.2.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.2.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
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Read
            host: "*"
          # access to status.storage.topic
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Read
            host: "*"
          # access to config.storage.topic
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Read
            host: "*"
          # consumer group
          - resource:
              type: group
              name: connect-cluster
              patternType: literal
            operation: Read
            host: "*"
  2. リソースを作成または更新します。

    oc apply -f KAFKA-USER-CONFIG-FILE

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

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

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

2.2.5. 変更データキャプチャーのための Debezium との統合

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

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

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

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

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

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

本章では、Kafka クラスター間でデータを複製するために AMQ Streams クラスターで Kafka MirrorMaker デプロイメントを設定する方法を説明します。

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

MirrorMaker を使用している場合は、KafkaMirrorMaker リソースを設定します。

重要

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 カスタムリソースを使用します。

以下の手順は、リソースの設定方法を示しています。

KafkaMirrorMaker リソースの完全なスキーマは、KafkaMirrorMaker schema のスキーマ参照 に記載されています。

2.3.1. Kafka MirrorMaker の設定

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

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

前提条件

  • 以下を実行する方法については、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
    OAuth ベアラートークン または SASL ベースの SCRAM-SHA-256/SCRAM-SHA-512 または PLAIN メカニズムを使用するか、ここで紹介されているような TLS メカニズム を使用したコンシューマーまたはプロデューサーの認証。
    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
    警告

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

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

    oc apply -f <your-file>

2.3.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.4. Kafka MirrorMaker 2.0 クラスターの設定

ここでは、AMQ Streams クラスターで Kafka MirrorMaker 2.0 デプロイメントを設定する方法を説明します。

MirrorMaker 2.0 は、データセンター内またはデータセンター全体の 2 台以上の Kafka クラスター間でデータを複製するために使用されます。

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

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

MirrorMaker 2.0 を使用している場合は、KafkaMirrorMaker2 リソースを設定します。KafkaMirrorMaker2 リソースの完全なスキーマは、KafkaMirrorMaker2 のスキーマ参照 に記載されています。

MirrorMaker 2.0 では、クラスターの間でデータを複製する全く新しい方法が導入されました。

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

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

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

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

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

MirrorMaker 2.0 は Kafka Connect フレームワークをベースとし、コネクター によってクラスター間のデータ転送が管理されます。MirrorMaker 2.0 の MirrorSourceConnector は、ソースクラスターからターゲットクラスターにトピックを複製します。

あるクラスターから別のクラスターにデータを ミラーリング するプロセスは非同期です。推奨されるパターンは、ソース Kafka クラスターとともにローカルでメッセージが作成され、ターゲットの Kafka クラスターの近くでリモートで消費されることです。

MirrorMaker 2.0 は、複数のソースクラスターで使用できます。

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

MirrorMaker 2.0 のレプリケーション

デフォルトでは、ソースクラスターの新規トピックのチェックは 10 分ごとに行われます。頻度は、refresh.topics.interval.seconds をソースコネクター設定に追加することで変更できます。ただし、操作の頻度が増えると、全体的なパフォーマンスに影響する可能性があります。

2.4.2. クラスターの設定

active/passive または active/active クラスター設定で MirrorMaker 2.0 を使用できます。

  • active/active 設定では、両方のクラスターがアクティブで、同じデータを同時に提供します。これは、地理的に異なる場所で同じデータをローカルで利用可能にする場合に便利です。
  • active/passive 設定では、アクティブなクラスターからのデータはパッシブなクラスターで複製され、たとえば、システム障害時のデータ復旧などでスタンバイ状態を維持します。

プロデューサーとコンシューマーがアクティブなクラスターのみに接続することを前提とします。

MirrorMaker 2.0 クラスターは、ターゲットの宛先ごとに必要です。

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

MirrorMaker 2.0 アーキテクチャーでは、active/active クラスター設定で双方向レプリケーションがサポートされます。

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

図2.2 トピック名の変更

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

ソースクラスターにフラグを付けると、トピックはそのクラスターに複製されません。

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

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

MirrorMaker 2.0 アーキテクチャーでは、active/passive クラスター設定でー方向レプリケーションがサポートされます。

active/passiveのクラスター設定を使用してバックアップを作成したり、データを別のクラスターに移行したりできます。この場合、リモートトピックの名前を自動的に変更したくないことがあります。

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

2.4.2.3. トピック設定の同期

トピック設定は、ソースクラスターとターゲットクラスター間で自動的に同期化されます。設定プロパティーを同期化することで、リバランスの必要性が軽減されます。

2.4.2.4. データの整合性

MirrorMaker 2.0 は、ソーストピックを監視し、設定変更をリモートトピックに伝播して、不足しているパーティションを確認および作成します。MirrorMaker 2.0 のみがリモートトピックに書き込みできます。

2.4.2.5. オフセットの追跡

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

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

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

MirrorMaker 2.0 は、MirrorCheckpointConnector を使用して、オフセット追跡の チェックポイントを生成します。

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

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

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

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

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

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

コンシューマーオフセットは、ターゲットクラスターでアクティブではないコンシューマーグループに対してのみ同期されます。

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

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

2.4.2.7. 接続性チェック

ハートビート 内部トピックによって、クラスター間の接続性が確認されます。

ハートビート トピックは、ソースクラスターから複製されます。

ターゲットクラスターは、トピックを使用して以下を確認します。

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

MirrorMaker 2.0 は MirrorHeartbeatConnector を使用して、これらのチェックを実行する ハートビート を生成します。

2.4.3. コネクター設定

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

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

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

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

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

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.4. タスクの最大数を指定

コネクターは、Kafka にデータを出し入れするタスクを作成します。各コネクターは、タスクを実行するワーカー Pod のグループ全体に分散される 1 つ以上のタスクで構成されます。

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

tasksMax プロパティーを使用して、MirrorMaker 設定でコネクタータスクの最大数を指定できます。タスクの最大数を指定しない場合、デフォルト設定のタスク数は 1 つです。インフラストラクチャーが処理のオーバーヘッドをサポートする場合、この数字を大きくするとスループットが向上されます。

MirrorMaker コネクターの tasksMax 設定

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
  # ...

ソースコネクターの場合、可能なタスクの最大数は、ソースクラスターからレプリケートされるパーティションごとに 1 つです。チェックポイントコネクターの場合、可能なタスクの最大数は、ソースクラスターからレプリケートされるグループごとに 1 つです。これらのコネクターに対して開始されるタスクの数は、可能な最大タスク数と tasksMax の値のいずれか低い値です。

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

2.4.5. 大量のメッセージの処理

MirrorMaker 2.0 デプロイメントが大量のメッセージを処理する場合は、それをサポートするように設定を調整する必要がある場合があります。

データレプリケーションのフラッシュパイプラインは、source topic → (Kafka Connect) source message queue → producer buffer → target topic です。オフセットフラッシュタイムアウト期間 (offset.flush.timeout.ms) は、プロデューサーバーッファー (producer.buffer.memory) が、コミットされるデータのフラッシュおよびオフセットを待つ時間です。プロデューサーバーッファーが大きく、オフセットフラッシュタイムアウト期間が不十分なために、フラッシュに失敗したり、オフセットのコミットに失敗したりするタイプのエラーが発生する状況は回避してください。

このタイプのエラーは、プロデューサーバッファー内にあるメッセージが多すぎるため、オフセットフラッシュタイムアウトに達する前にすべてのメッセージをフラッシュできないことを意味します。

このタイプのエラーが発生した場合は、次の設定変更を試してください。

  • producer.buffer.memory のデフォルト値 (バイト) を減らす
  • offset.flush.timeout.ms のデフォルト値 (ミリ秒) を増やす

この変更は、未処理のメッセージの基になる Kafka Connect キューを管理可能なサイズに保つのに役立つはずです。目的の効果を得るには、値を調整する必要がある場合があります。

これらの設定を変更してもエラーが解消されない場合は、次の手順を実行して、並行して実行されるタスクの数を増やしてみてください。

  • tasksMax プロパティーを使用して タスク数を増やす
  • replicas プロパティーを使用してタスクを実行するワーカーのノード数を増やす

大量のメッセージを処理するための MirrorMaker 2.0 の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.1.0
  replicas: 5
  connectCluster: "my-cluster-target"
  clusters:
  - alias: "my-cluster-source"
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092
  - alias: "my-cluster-target"
    config:
      offset.flush.timeout.ms: 10000
      producer.buffer.memory: 8388608
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 10

2.4.5.1. メッセージフローの確認

Prometheus と Grafana を使用してデプロイメントをモニタリングしている場合は、MirrorMaker 2.0 メッセージフローを確認できます。AMQ Streams で提供される MirrorMaker 2.0 Grafana ダッシュボードの例は、フラッシュパイプラインに関連する次のメトリクスを示しています。

  • Kafka Connect の未処理メッセージキューにあるメッセージの数
  • プロデューサーバーッファーの使用可能なバイト数
  • オフセットコミットタイムアウト (ミリ秒)

これらのメトリクスを使用して、メッセージの量に基づいて設定を調整する必要があるかどうかを判断できます。

2.4.6. ACL ルールの同期

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

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

注記

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

2.4.7. Kafka MirrorMaker 2.0 の設定

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

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

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

    • クラスター対クラスター
    • トピック対トピック
注記

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

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

MirrorMaker 2.0 の最小設定

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.1.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: {}

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

前提条件

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

手順

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

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

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker2
    spec:
      version: 3.1.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
          config:
            replication.factor: 1 21
            offset-syncs.topic.replication.factor: 1 22
            sync.topic.acls.enabled: "false" 23
            refresh.topics.interval.seconds: 60 24
            replication.policy.separator: "" 25
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy" 26
        heartbeatConnector: 27
          config:
            heartbeats.topic.replication.factor: 1 28
        checkpointConnector: 29
          config:
            checkpoints.topic.replication.factor: 1 30
            refresh.groups.interval.seconds: 600 31
            sync.group.offsets.enabled: true 32
            sync.group.offsets.interval.seconds: 60 33
            emit.checkpoints.interval.seconds: 60 34
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy"
        topicsPattern: ".*" 35
        groupsPattern: "group1|group2|group3" 36
      resources: 37
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 38
        type: inline
        loggers:
          connect.root.logger.level: "INFO"
      readinessProbe: 39
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      jvmOptions: 40
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 41
      template: 42
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 43
          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 44
      externalConfiguration: 45
        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
    OAuth ベアラートークン、SASL ベースの SCRAM-SHA-256/SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、ソースクラスターの認証。
    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.0 コネクターによって使用されるソースクラスターの クラスターエイリアス
    18
    MirrorMaker 2.0 コネクターによって使用されるターゲットクラスターの クラスターエイリアス
    19
    リモートトピックを作成する MirrorSourceConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    20
    コネクターによる作成が可能なタスクの最大数。タスクは、データのレプリケーションを処理し、並行して実行されます。インフラストラクチャーが処理のオーバーヘッドをサポートする場合、この値を大きくするとスループットが向上されます。Kafka Connect は、クラスターのメンバー間でタスクを分散します。ワーカーよりも多くのタスクがある場合は、ワーカーには複数のタスクが割り当てられます。シンクコネクターでは、消費される各トピックパーティションに 1 つタスクがあるようになることを目指します。ソースコネクターでは、並行して実行できるタスクの数は外部システムによって異なる場合もあります。並列処理を実現できない場合、コネクターは最大数より少ないタスクを作成します。
    21
    ターゲットクラスターで作成されるミラーリングされたトピックのレプリケーション係数。
    22
    ソースおよびターゲットクラスターのオフセットをマップする MirrorSourceConnector offset-syncs 内部トピックのレプリケーション係数。
    23
    ACL ルールの同期 が有効になっていると、同期されたトピックに ACL が適用されます。デフォルトは true です。この機能は User Operator と互換性がありません。User Operator を使用している場合は、このプロパティーを false に設定します。
    24
    新規トピックのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
    25
    リモートトピック名の変更に使用する区切り文字を定義します。
    26
    リモートトピック名の自動変更をオーバーライドするポリシーを追加します。その名前の前にソースクラスターの名前を追加する代わりに、トピックが元の名前を保持します。このオプションの設定は、active/passive バックアップおよびデータ移行に役立ちます。トピックオフセットの同期を設定するには、このプロパティーも checkpointConnector.config に設定する必要があります。
    27
    接続チェックを実行する MirrorHeartbeatConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    28
    ターゲットクラスターで作成されたハートビートトピックのレプリケーション係数。
    29
    オフセットを追跡する MirrorCheckpointConnector の設定。デフォルトの設定オプションは config によって上書きされます。
    30
    ターゲットクラスターで作成されたチェックポイントトピックのレプリケーション係数。
    31
    新規コンシューマーグループのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
    32
    コンシューマーグループのオフセットを同期する任意設定。これは、active/passive 設定でのリカバリーに便利です。同期はデフォルトでは有効になっていません。
    33
    コンシューマーグループオフセットの同期が有効な場合は、同期の頻度を調整できます。
    34
    オフセット追跡のチェック頻度を調整します。オフセット同期の頻度を変更する場合、これらのチェックの頻度も調整する必要がある場合があります。
    35
    正規表現パターンとして定義された ソースクラスターからのトピックレプリケーション。ここで、すべてのトピックを要求します。
    36
    正規表現パターンとして定義された ソースクラスターからのコンシューマーグループレプリケーション。ここで、3 つのコンシューマーグループを名前で要求します。コンマ区切りリストを使用できます。
    37
    サポートされているリソース (現在は cpumemory) の予約と、消費可能な最大リソースを指定するための制限を要求します。
    38
    指定された Kafka loggers and log levels が ConfigMap を介して直接的に (inline) または間接的に (external) に追加されます。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。Kafka Connect log4j.rootLogger ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
    39
    コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック
    40
    Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション
    41
    高度なオプション:コンテナーイメージの設定。これは特別な状況でのみ推奨されます。
    42
    テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
    43
    44
    45
    環境変数として Kafka MirrorMaker にマウントされた OpenShift Secret の 外部設定設定プロバイダープラグイン を使用して、外部ソースから設定値を読み込む こともできます。
  2. リソースを作成または更新します。

    oc apply -f MIRRORMAKER-CONFIGURATION-FILE

2.4.8. Kafka MirrorMaker 2.0 デプロイメントの保護

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

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

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

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

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

注記

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

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

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

例には、ソースおよびターゲットの Kafka クラスターでの操作を可能にするために MirrorMaker 2.0 が必要とする ACL も示されています。

前提条件

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

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

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

手順

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

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

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

    TLS 認証を使用したソース Kafka クラスターの設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-source-cluster
    spec:
      kafka:
        version: 3.1.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.1"
        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 認証を使用したターゲット Kafka クラスターの設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-target-cluster
    spec:
      kafka:
        version: 3.1.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.1"
        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. ソースおよびターゲットの Kafka クラスターでの操作を可能にするために MirrorMaker 2.0 が必要とする ACL を設定します。

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

    TLS クライアント認証のソースユーザーの設定例

    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
            operation: Create
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: DescribeConfigs
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: Write
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Read
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: DescribeConfigs
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operation: Describe
          - resource: # Needed for every group for which offsets are synced
              type: group
              name: "*"
            operation: Describe
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: Read

    TLS クライアント認証のターゲットユーザーの設定例

    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
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Create
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Create
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Create
          # MirrorSourceConnector
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Create
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Alter
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: AlterConfigs
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Write
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operation: Describe
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Create
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Describe
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Write
          - resource: # Needed for every group for which the offset is synced
              type: group
              name: "*"
            operation: Read
          - resource: # Needed for every group for which the offset is synced
              type: group
              name: "*"
            operation: Describe
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Read
          # MirrorHeartbeatConnector
          - resource:
              type: topic
              name: heartbeats
            operation: Create
          - resource:
              type: topic
              name: heartbeats
            operation: Describe
          - resource:
              type: topic
              name: heartbeats
            operation: Write

    注記

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

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

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

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

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

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

    TLS 認証を使用した MirrorMaker 2.0 の設定例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker-2
    spec:
      version: 3.1.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: ".*"
          groupsPattern: ".*"

    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>

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

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

前提条件

  • 稼働中の Cluster Operator。

手順

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

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

    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.0 コネクターは再起動されます。再起動要求が許可されると、アノテーションは KafkaMirrorMaker2 カスタムリソースから削除されます。

2.4.10. Kafka MirrorMaker 2.0 コネクタータスクの再起動の実行

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

前提条件

  • 稼働中の Cluster Operator。

手順

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

    oc get KafkaMirrorMaker2
  2. Kafka MirrorMaker 2.0 コネクターの名前と、KafkaMirrorMaker2 カスタムリソースから再起動されるタスクの 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.0 コネクタータスクは再起動されます。再起動タスクの要求が受け入れられると、KafkaMirrorMaker2 のカスタムリソースからアノテーションが削除されます。

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

ここでは、AMQ Streams クラスターで Kafka Bridge デプロイメントを設定する方法を説明します。

Kafka Bridge では、HTTP ベースのクライアントと Kafka クラスターを統合するための API が提供されます。

Kafka Bridge を使用している場合は、KafkaBridge リソースを設定します。

KafkaBridge リソースの完全なスキーマは KafkaBridge スキーマ参照」 に記載されています。

2.5.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
    OAuth ベアラートークン、SASL ベースの SCRAM-SHA-256/SCRAM-SHA-512 またはPLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、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.5.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.6. 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.6.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 クラスターに対してのみ 1 度にカスタマイズできます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。

関連情報

  • Cluster Operator の設定に関する詳細は、「Cluster Operator の使用」 を参照してください。
  • イメージプルポリシーに関する詳細は、「Disruptions」を参照してください。

2.6.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.7. Pod スケジューリングの設定

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

2.7.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 のアフィニティーおよび非アフィニティー
  • ノードのアフィニティー
注記

OpenShift 1.16 および 1.17 では、topologySpreadConstraint のサポートはデフォルトで無効にされています。topologySpreadConstraint を使用するには、Kubernetes API サーバーおよびスケジューラーで Even PodsSpread フィーチャーゲートを有効にする必要があります。

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

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

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

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

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

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

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

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

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

2.7.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.7.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.7.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.7.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.8. ロギングの設定

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.8.1. Kafka コンポーネントおよび Operator のロギングオプション

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

2.8.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.8.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 シークレットまたは設定マップから設定データを読み込みます。

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

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

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

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

注記

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

3.1. 設定マップからの設定値の読み込み

この手順では、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章 OpenShift クラスター外の Kafka へのアクセス

外部リスナーを使用して AMQ Streams の Kafka クラスターを OpenShift 環境外のクライアントに公開します。

外部リスナー設定で Kafka を公開するため type を指定します。

  • nodeportNodePort タイプの Services を使用します。
  • loadbalancer が使用する LoadbalancerServices
  • ingress はKubernetes IngressNGINX Ingress Controller for Kubernetes を使用しています。
  • route は、OpenShift Routes と HAProxy ルーターを使用します。

リスナーの設定の詳細については、GenericKafkaListener schema reference を参照してください。

各接続タイプの長所と短所については、StrimziでのApache Kafkaへのアクセスを参照してください。

注記

route は OpenShift でのみサポートされます。

4.1. ノードポートを使用した Kafka へのアクセス

この手順では、ノードポートを使用して外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。

ブローカーに接続するには、Kafka bootstrap アドレスのホスト名とポート番号、および認証に使用される証明書が必要です。

前提条件

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

手順

  1. 外部リスナーを nodeport タイプに設定して Kafka リソースを設定します。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: nodeport
            tls: true
            authentication:
              type: tls
            # ...
        # ...
      zookeeper:
        # ...
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

    NodePort タイプのサービスは、各 Kafka ブローカーと、外部のブートストラップサービスのために作成されます。ブートストラップサービスは外部トラフィックを Kafka ブローカーにルーティングします。接続に使用されるノードアドレスは、Kafka カスタムリソースの status に伝搬されます。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

  3. Kafka リソースのステータスから、Kafka クラスタにアクセスする際に使用するブートストラップアドレスを取得します。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    以下はその例です。

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="external")].bootstrapServers}{"\n"}'
  4. TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

4.2. ロードバランサーを使用した Kafka へのアクセス

この手順では、ロードバランサーを使用して外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。

ブローカーに接続するには、ブートストラップロードバランサーのアドレスと、TLS による暗号化に使用される証明書が必要です。

前提条件

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

手順

  1. 外部リスナーを loadbalancer タイプに設定して Kafka リソースを設定します。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: loadbalancer
            tls: true
            # ...
        # ...
      zookeeper:
        # ...
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

    loadbalancer タイプのサービスおよびロードバランサーは、各 Kafka ブローカーと外部 bootstrap service について作成されます。ブートストラップサービスは外部トラフィックをすべての Kafka ブローカーにルーティングします。接続に使用したDNS名やIPアドレスは、各サービスの status に伝わります。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

  3. Kafka リソースのステータスから、Kafka クラスタへのアクセスに使用できるブートストラップサービスのアドレスを取得します。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    以下はその例です。

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="external")].bootstrapServers}{"\n"}'
  4. TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

4.3. ingress を使用した Kafka へのアクセス

このの手順では、Nginx Ingress を使用して OpenShift 外部の外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法を説明します。

ブローカーに接続するには、Ingress ブートストラップアドレス のホスト名 (アドバタイズされたアドレス) と、認証に使用される証明書が必要です。

Ingress を使用したアクセスでは、ポートは常に 443 になります。

TLS パススルー

Kafka は TCP 上でバイナリープロトコルを使用しますが、NGINX Ingress Controller for Kubernetes は HTTP プロトコルで動作するように設計されています。Ingress から Kafka コネクションを渡せるようにするため、AMQ Streams では NGINX Ingress Controller for Kubernetes の TLS パススルー機能が使用されます。TLS パススルーが NGINX Ingress Controller for Kubernetes デプロイメントで有効になっているようにしてください。

Ingress を使用して Kafka を公開する場合、TLS パススルー機能を使用するため、TLS による暗号化を無効にできません。

TLS パススルーの有効化に関する詳細は、TLS パススルーのドキュメント を参照してください。

前提条件

手順

  1. 外部リスナーを ingress タイプに設定して Kafka リソースを設定します。

    ブートストラップサービスおよび Kafka ブローカーの Ingress ホストを指定します。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: ingress
            tls: true
            authentication:
              type: tls
            configuration: 1
              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
        # ...
      zookeeper:
        # ...
    1
    ブートストラップサービスおよび Kafka ブローカーの Ingress ホスト。
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

    Kafka ブローカーごとに ClusterIP タイプのサービスが作成され、さらに bootstrap service も追加されています。これらのサービスは、トラフィックを Kafka ブローカーにルーティングするために Ingress コントローラーによって使用されます。また、Ingressコントローラを使ってサービスを公開するために、各サービスに Ingress リソースを作成します。Ingress ホストは各サービスの status に伝播されます。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

    Kafka クラスターに接続するためのブートストラップアドレスとして、configuration で指定したブートストラップホストのアドレスと、Kafka クライアントのポート 443 (BOOTSTRAP-HOST:443)を使用します。

  3. ブローカーの認証局の公開証明書を取得します。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

4.4. OpenShift ルートを使用した Kafka へのアクセス

この手順では、ルートを使用して OpenShift 外部の外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。

ブローカーに接続するには、ルートブートストラップアドレス のホスト名と、TLS による暗号化に使用される証明書が必要です。

ルートを使用したアクセスでは、ポートは常に 443 になります。

前提条件

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

手順

  1. 外部リスナーを route タイプに設定した Kafka リソースを設定します。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      labels:
        app: my-cluster
      name: my-cluster
      namespace: myproject
    spec:
      kafka:
        # ...
        listeners:
          - name: listener1
            port: 9094
            type: route
            tls: true
            # ...
        # ...
      zookeeper:
        # ...
    警告

    OpenShift Route アドレスは、Kafka クラスターの名前、リスナーの名前、および作成される namespace の名前で構成されます。たとえば、my-cluster-kafka-listener1-bootstrap-myproject (CLUSTER-NAME-kafka-LISTENER-NAME-bootstrap-NAMESPACE) となります。アドレスの全体の長さが上限の 63 文字を超えないように注意してください。

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

    oc apply -f <kafka_configuration_file>

    ClusterIP タイプサービスは、各 Kafka ブローカーと、外部 bootstrap service に対して作成されます。サービスは、トラフィックを OpenShift ルートから Kafka ブローカーにルーティングします。また、HAProxyロードバランサーを使ってサービスを公開するために、各サービスにOpenShift Routeリソースを作成します。接続に使用される DNS アドレスは、各サービスの status に伝播されます。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

  3. Kafka リソースのステータスから、Kafka クラスタへのアクセスに使用できるブートストラップサービスのアドレスを取得します。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    以下はその例です。

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="listener1")].bootstrapServers}{"\n"}'
  4. ブローカーの認証局の公開証明書を取得します。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

第5章 Kafka へのセキュアなアクセスの管理

各クライアントの Kafka ブローカーへのアクセスを管理することで、Kafka クラスターを保護できます。

Kafka ブローカーとクライアント間のセキュアな接続には、以下が含まれます。

  • データ交換の暗号化
  • アイデンティティー証明に使用する認証
  • ユーザーが実行するアクションを許可または拒否する承認

本章では、以下を取り上げ、Kafka ブローカーとクライアント間でセキュアな接続を設定する方法を説明します。

  • Kafka クラスターおよびクライアントのセキュリティーオプション
  • Kafka ブローカーをセキュアにする方法
  • OAuth 2.0 トークンベースの認証および承認に承認サーバーを使用する方法

5.1. Kafka のセキュリティーオプション

Kafka リソースを使用して、Kafka の認証および承認に使用されるメカニズムを設定します。

5.1.1. リスナー認証

OpenShift クラスター内のクライアントの場合は、plain (暗号化なし)または tls internal リスナーを作成できます。OpenShift クラスター外のクライアントの場合は、external リスナーを作成し、nodeportloadbalanceringress、または route (OpenShift 上)などの接続メカニズムを指定します。

外部クライアントを接続するための設定オプションの詳細は、OpenShiftクラスター外からのKafkaへのアクセスを参照してください。

サポートされる認証オプションは次のとおりです。

  1. 相互 TLS 認証 (TLS による暗号化が有効なリスナーのみ)
  2. SCRAM-SHA-512 認証
  3. OAuth 2.0 のトークンベースの認証
  4. カスタム認証

選択する認証オプションは、Kafka ブローカーへのクライアントアクセスを認証する方法によって異なります。

注記

カスタム認証を使用する前に、標準の認証オプションを試してみてください。カスタム認証では、kafka でサポートされているあらゆるタイプの認証が可能です。柔軟性を高めることができますが、複雑さも増します。

図5.1 Kafka リスナーの認証オプション

リスナー認証設定のオプション

リスナーの authentication プロパティーは、そのリスナーに固有の認証メカニズムを指定するために使用されます。

authentication プロパティーが指定されていない場合、リスナーはそのリスナー経由で接続するクライアントを認証しません。認証がないと、リスナーではすべての接続が許可されます。

認証は、User Operator を使用して KafkaUsers を管理する場合に設定する必要があります。

以下の例で指定されるものは次のとおりです。

  • SCRAM-SHA-512 認証に設定された plain リスナー
  • 相互 TLS 認証を使用する tls リスナー
  • 相互 TLS 認証を使用する external リスナー

各リスナーは、Kafka クラスター内で一意の名前およびポートで設定されます。

注記

ブローカー間通信 (9091 または 9090) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。

リスナー認証設定の例

# ...
listeners:
  - name: plain
    port: 9092
    type: internal
    tls: true
    authentication:
      type: scram-sha-512
  - name: tls
    port: 9093
    type: internal
    tls: true
    authentication:
      type: tls
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
# ...

5.1.1.1. 相互 TLS 認証

相互 TLS 認証は、Kafka ブローカーと ZooKeeper Pod 間の通信で常に使用されます。

AMQ Streams では、Kafka が TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、Kafka ブローカーとクライアントとの間で暗号化された通信が行われるよう設定できます。相互 (双方向) 認証の場合、サーバーとクライアントの両方が証明書を提示します。相互認証を設定すると、ブローカーはクライアントを認証し (クライアント認証)、クライアントはブローカーを認証します (サーバー認証)。

注記

TLS 認証は一般的には一方向で、一方が他方のアイデンティティーを認証します。たとえば、Web ブラウザーと Web サーバーの間で HTTPS が使用される場合、ブラウザーは Web サーバーのアイデンティティーの証明を取得します。

5.1.1.2. SCRAM-SHA-512 認証

SCRAM (Salted Challenge Response Authentication Mechanism) は、パスワードを使用して相互認証を確立できる認証プロトコルです。AMQ Streams では、Kafka が SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 を使用するよう設定し、暗号化されていないクライアントの接続と暗号化されたクライアントの接続の両方で認証を提供できます。

TLS クライアント接続で SCRAM-SHA-512 認証が使用される場合、TLS プロトコルは暗号化を提供しますが、認証には使用されません。

SCRAM の以下のプロパティーは、暗号化されていない接続でも SCRAM-SHA-512 を安全に使用できるようにします。

  • 通信チャネル上では、パスワードはクリアテキストで送信されません。代わりに、クライアントとサーバーはお互いにチャレンジを生成し、認証するユーザーのパスワードを認識していることを証明します。
  • サーバーとクライアントは、認証を交換するたびに新しいチャレンジを生成します。よって、この交換はリレー攻撃に対する回復性を備えています。

KafkaUser.spec.authentication.typescram-sha-512 に設定すると、User Operator は、大文字と小文字の ASCII 文字と数字で構成されるランダムな 12 文字のパスワードを生成します。

5.1.1.3. ネットワークポリシー

デフォルトでは、AMQ Streams では、Kafka ブローカーで有効になっているリスナーごとに NetworkPolicy リソースが自動的に作成されます。この NetworkPolicy により、アプリケーションはすべての namespace のリスナーに接続できます。リスナー設定の一部としてネットワークポリシーを使用します。

ネットワークレベルでのリスナーへのアクセスを指定のアプリケーションまたは namespace のみに制限するには、networkPolicyPeers プロパティーを使用します。リスナーごとに、異なる networkPolicyPeers 設定を指定できます。ネットワークポリシーピアの詳細は、NetworkPolicyPeer API reference を参照してください。

カスタムネットワークポリシーを使用する場合は、Cluster Operator 設定で STRIMZI_NETWORK_POLICY_GENERATION 環境変数を false に設定できます。詳細は、Cluster Operator configuration を参照してください。

注記

AMQ Streams でネットワークポリシーを使用するためには、OpenShift の構成が ingress NetworkPolicies をサポートしている必要があります。

5.1.1.4. 追加のリスナー設定オプション

GenericKafkaListenerConfiguration スキーマのプロパティーを使用して、設定をリスナーに追加できます。

5.1.2. Kafka の承認

Kafka.spec.kafka リソースの authorization プロパティーを使用すると Kafka ブローカーの承認を設定できます。authorization プロパティーがないと、承認が有効になりず、クライアントには制限がありません。承認を有効にすると、承認は有効なすべてのリスナーに適用されます。承認方法は type フィールドで定義されます。

サポートされる承認オプションは次のとおりです。

図5.2 Kafka クラスター承認オプション

kafks 承認設定のオプション

5.1.2.1. スーパーユーザー

スーパーユーザーは、アクセスの制限に関係なく Kafka クラスターのすべてのリソースにアクセスでき、すべての承認メカニズムでサポートされます。

Kafka クラスターのスーパーユーザーを指定するには、superUsers プロパティーにユーザープリンシパルのリストを追加します。ユーザーが TLS クライアント認証を使用する場合、ユーザー名は CN= で始まる証明書のサブジェクトのコモンネームになります。

スーパーユーザーを使用した設定例

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
    # ...

5.2. Kafka クライアントのセキュリティーオプション

KafkaUser リソースを使用して、Kafka クライアントの認証メカニズム、承認メカニズム、およびアクセス権限を設定します。セキュリティーの設定では、クライアントはユーザーとして表されます。

Kafka ブローカーへのユーザーアクセスを認証および承認できます。認証によってアクセスが許可され、承認によって許容されるアクションへのアクセスが制限されます。

Kafka ブローカーへのアクセスが制限されない スーパーユーザー を作成することもできます。

認証および承認メカニズムは、Kafka ブローカーへのアクセスに使用されるリスナーの仕様 と一致する必要があります。

Kafka ブローカーへのアクセスのセキュリティーを確保する設定

Kafkaブローカーに安全にアクセスするためのKafkaUserリソースの構成の詳細は、以下のセクションを参照してください。

5.2.1. ユーザー処理用の Kafka クラスターの特定

KafkaUser リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka リソースの名前から派生) を定義するラベルが含まれています。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster

このラベルは、KafkaUser リソースを特定し、新しいユーザーを作成するために、User Operator によって使用されます。また、以降のユーザーの処理でも使用されます。

ラベルが Kafka クラスターと一致しない場合、User Operator は KafkaUser を識別できず、ユーザーは作成されません。

KafkaUser リソースの状態が空のままの場合は、ラベルを確認します。

5.2.2. ユーザー認証

ユーザー認証は、KafkaUser.specauthentication プロパティーを使用して設定されます。ユーザーに有効な認証メカニズムは、type フィールドを使用して指定されます。

サポートされる認証タイプ

  • TLSクライアント認証のための tls
  • 外部証明書を使用した TLS クライアント認証の tls-external
  • scram-sha-512(SCRAM-SHA-512 認証用)

tls または scram-sha-512 が指定された場合、User Operator がユーザーを作成する際に、認証用のクレデンシャルを作成します。tls-external が指定されている場合、ユーザーは TLS クライアント認証を使用することが予想されますが、認証情報は作成されません。独自の証明書を指定する場合は、このオプションを使用します。認証タイプが指定されていない場合、User Operator はユーザーまたはそのクレデンシャルを作成しません。

tls-external を使用して、User Operator 以外で発行された証明書を使用して TLS クライアントの認証を行います。User Operator は TLS 証明書またはシークレットを生成しません。tls メカニズムを使用する場合と同様に、User Operator を使用して ACL ルールおよびクォータを管理できます。これは、ACL ルールおよびクォータを指定する際に CN=USER-NAME 形式を使用することを意味します。USER-NAME は、TLS 証明書で指定したコモンネームです。

5.2.2.1. TLS クライアント認証

TLSクライアント認証を使用するには、KafkaUser リソースの type フィールドを tls に設定します。

TLS クライアント認証が有効になっているユーザーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  # ...

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

すべての鍵は X.509 形式です。

Secret には、PEM 形式および PKCS #12 形式の秘密鍵と証明書が含まれます。

Kafka と Secret との通信をセキュアにする方法については、11章TLS 証明書の管理 を参照してください。

ユーザー認証情報を含むシークレットの例

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 of the client CA
  user.crt: # User certificate that contains the public key of the user
  user.key: # Private key of the user
  user.p12: # PKCS #12 archive file for storing certificates and keys
  user.password: # Password for protecting the PKCS #12 archive file

5.2.2.2. User Operator の外部で発行された証明書を使用した TLS クライアント認証

User Operator の外部で発行された証明書を使用して TLS クライアント認証を使用するには、KafkaUser リソースの type フィールドを tls-external に設定します。シークレットおよび認証情報はユーザー用には作成されません。

User Operator の外部で発行された証明書を使用する TLS クライアント認証を持つユーザーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls-external
  # ...

5.2.2.3. SCRAM-SHA-512 認証

SCRAM-SHA-512 認証メカニズムを使用するには、KafkaUser リソースの type フィールドを scram-sha-512 に設定します。

SCRAM-SHA-512 認証が有効になっているユーザーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
  # ...

ユーザーが User Operator によって作成されると、KafkaUser リソースと同じ名前で新しいシークレットが作成されます。シークレットの password キーには、生成されたパスワードが含まれ、base64 でエンコードされます。パスワードを使用するにはデコードする必要があります。

ユーザー認証情報を含むシークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  password: Z2VuZXJhdGVkcGFzc3dvcmQ= 1
  sasl.jaas.config: b3JnLmFwYWNoZS5rYWZrYS5jb21tb24uc2VjdXJpdHkuc2NyYW0uU2NyYW1Mb2dpbk1vZHVsZSByZXF1aXJlZCB1c2VybmFtZT0ibXktdXNlciIgcGFzc3dvcmQ9ImdlbmVyYXRlZHBhc3N3b3JkIjsK 2

1
base64 でエンコードされた生成されたパスワード。
2
base64 でエンコードされた SASL SCRAM-SHA-512 認証の JAAS 設定文字列。

生成されたパスワードをデコードします。

echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
5.2.2.3.1. カスタムパスワード設定

ユーザーが作成されると、AMQ Streams は無作為にパスワードを生成します。AMQ Streams によって生成されたパスワードの代わりに、独自のパスワードを使用できます。これを行うには、パスワードでシークレットを作成し、KafkaUser リソースでこれを参照します。

SCRAM-SHA-512 認証に設定されたパスワードを持つユーザーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
    password:
      valueFrom:
        secretKeyRef:
          name: my-secret 1
          key: my-password 2
  # ...

1
事前に定義されたパスワードが含まれるシークレットの名前。
2
シークレット内に格納されているパスワードのキー。

5.2.3. ユーザーの承認

ユーザーの承認は、KafkaUser.specauthorization プロパティーを使用して設定されます。ユーザーに有効な承認タイプは、type フィールドを使用して指定します。

簡易承認を使用するには、KafkaUser.spec.authorizationtype プロパティーを simple に設定します。簡易承認は、Kafka Admin API を使用して Kafka クラスター内で ACL ルールを管理します。User Operator の ACL 管理が有効であるかどうかは、Kafka クラスターの承認設定によって異なります。

  • 簡易承認では、ACL 管理が常に有効になります。
  • OPA 承認の場合、ACL 管理は常に無効になります。承認ルールは OPA サーバーで設定されます。
  • Red Hat Single Sign-On の承認では、Red Hat Single Sign-On で ACL ルールを直接管理できます。設定のフォールバックオプションとして、承認を簡単なオーソライザーに委譲することもできます。簡単なオーソライザーへの委譲が有効になっている場合、User Operator は ACL ルールの管理も有効にします。
  • カスタム承認プラグインを使用したカスタム承認では、Kafka カスタムリソースの .spec.kafka.authorization 設定の supportsAdminApi プロパティーを使用して、サポートを有効または無効にする必要があります。

ACL 管理が有効になっていない場合は、AMQ Streams に ACL ルールが含まれる場合はリソースを拒否します。

User Operator のスタンドアロンデプロイメントを使用している場合、ACL 管理はデフォルトで有効にされます。STRIMZI_ACLS_ADMIN_API_SUPPORTED 環境変数を使用してこれを無効にすることができます。

承認が指定されていない場合は、User Operator によるユーザーのアクセス権限のプロビジョニングは行われません。このような KafkaUser がリソースにアクセスできるかどうかは、使用されているオーソライザーによって異なります。たとえば、AclAuthorizer の場合、これは allow.everyone.if.no.acl.found 設定によって決定されます。

5.2.3.1. ACL ルール

AclAuthorizer は ACL ルールを使用して Kafka ブローカーへのアクセスを管理します。

ACL ルールによって、acls プロパティーで指定したユーザーにアクセス権限が付与されます。

AclRule オブジェクトの詳細は、AclRule schema reference を参照してください。

5.2.3.2. Kafka ブローカーへのスーパーユーザーアクセス

ユーザーを Kafka ブローカー設定のスーパーユーザーのリストに追加すると、KafkaUser の ACL で定義された承認制約に関係なく、そのユーザーにはクラスターへのアクセスが無制限に許可されます。

ブローカーへのスーパーユーザーアクセスの設定に関する詳細は「Kafka の承認」を参照してください。

5.2.3.3. ユーザークォータ

KafkaUser リソースの spec を設定してクォータを強制し、ユーザーが Kafka ブローカーへの設定されたアクセスレベルを超えないようにします。サイズベースのネットワーク使用量と時間ベースの CPU 使用率のしきい値を設定できます。また、パーティション mutation (変更) クォータを追加して、ユーザー要求に対して受け入れられるパーティション変更のリクエストのレートを制御することもできます。

ユーザークォータをともなう KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  quotas:
    producerByteRate: 1048576 1
    consumerByteRate: 2097152 2
    requestPercentage: 55 3
    controllerMutationRate: 10 4

1
ユーザーが Kafka ブローカーにプッシュできるデータ量の、秒あたりのバイトクォータ。
2
ユーザーが Kafka ブローカーからフェッチできるデータ量の、秒あたりのバイトクォータ。
3
クライアントグループあたりの時間割合で示される、CPU 使用制限。
4
1 秒あたり許容される同時パーティション作成および削除操作 (mutations) の数

これらのプロパティーの詳細は、KafkaUserQuotas schema reference を参照してください。

5.3. Kafka ブローカーへのアクセスのセキュア化

Kafka ブローカーへのセキュアなアクセスを確立するには、以下を設定し、適用します。

  • 以下を行う Kafka リソース。

    • 指定された認証タイプでリスナーを作成します。
    • Kafka クラスター全体の承認を設定します。
  • Kafka ブローカーにリスナー経由でセキュアにアクセスするための KafkaUser リソース。

Kafka リソースを設定して以下を設定します。

  • リスナー認証
  • Kafka リスナーへのアクセスを制限するネットワークポリシー
  • Kafka の承認
  • ブローカーへのアクセスが制限されないスーパーユーザー

認証は、リスナーごとに独立して設定されます。承認は、常に Kafka クラスター全体に対して設定されます。

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

独自の証明書をインストールして、Cluster Operator によって生成された証明書を置き換えることができます。外部認証局によって管理される Kafka リスナー証明書を使用するようにリスナーを設定することもできます。PKCS #12 形式 (.p12) および PEM 形式 (.crt) の証明書を利用できます。

KafkaUser を使用して、特定のクライアントが Kafka にアクセスするために使用する認証および承認メカニズムを有効にします。

KafkaUser リソースを設定して以下を設定します。

  • 有効なリスナー認証と一致する認証
  • 有効な Kafka 承認と一致する承認
  • クライアントによるリソースの使用を制御するクォータ

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

アクセス構成プロパティの詳細は、スキーマリファレンスを参照してください。

5.3.1. Kafka ブローカーのセキュア化

この手順では、AMQ Streams の実行時に Kafka ブローカーをセキュアにするためのステップを説明します。

Kafka ブローカーに実装されたセキュリティーは、アクセスを必要とするクライアントに実装されたセキュリティーとの互換性を維持する必要があります。

  • Kafka.spec.kafka.listeners[*].authentication matches KafkaUser.spec.authentication
  • Kafka.spec.kafka.authorizationKafkaUser.spec.authorization と一致します。

この手順では、TLS 認証を使用した簡易承認とリスナーの設定を説明します。リスナーの設定の詳細については、GenericKafkaListener schema reference を参照してください。

代わりに、リスナー認証 には SCRAM-SHA または OAuth 2.0、Kafka 承認 には OAuth 2.0 または OPA を使用することができます。

手順

  1. Kafka リソースを設定します。

    1. 承認には authorization プロパティーを設定します。
    2. listeners プロパティーを設定し、認証でリスナーを作成します。

      以下はその例です。

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      spec:
        kafka:
          # ...
          authorization: 1
            type: simple
            superUsers: 2
              - CN=client_1
              - user_2
              - CN=client_3
          listeners:
            - name: tls
              port: 9093
              type: internal
              tls: true
              authentication:
                type: tls 3
          # ...
        zookeeper:
          # ...
      1
      2
      Kafka へのアクセスを制限されないユーザープリンシパルのリスト。CN は、TLS による認証が使用される場合のクライアント証明書のコモンネームです。
      3
      リスナーの認証メカニズムは各リスナーに対して設定でき、相互 TLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定 できます。

      外部リスナーを設定している場合、設定は選択した接続のメカニズムによって異なります。

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

    oc apply -f <kafka_configuration_file>

    Kafka クラスターは、TLS 認証を使用する Kafka ブローカーリスナーと共に設定されます。

    Kafka ブローカー Pod ごとにサービスが作成されます。

    サービスが作成され、Kafka クラスターに接続するための ブートストラップアドレス として機能します。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

5.3.2. Kafka へのユーザーアクセスのセキュア化

KafkaUser リソースのプロパティーを使用して Kafka ユーザーを設定します。

oc apply を使用すると、ユーザーを作成または編集できます。oc delete を使用すると、既存のユーザーを削除できます。

以下はその例です。

  • oc apply -f USER-CONFIG-FILE
  • oc delete KafkaUser USER-NAME

KafkaUser 認証および承認メカニズムを設定する場合、必ず同等の Kafka 設定と一致するようにしてください。

  • KafkaUser.spec.authenticationKafka.spec.kafka.listeners[*].authentication と一致します。
  • KafkaUser.spec.authorizationKafka.spec.kafka.authorization と一致します。

この手順では、TLS 認証でユーザーを作成する方法を説明します。SCRAM-SHA 認証でユーザーを作成することも可能です。

必要な認証は、Kafka ブローカーリスナーに設定された認証のタイプ によって異なります。

注記

Kafka ユーザーと Kafka ブローカー間の認証は、それぞれの認証設定によって異なります。たとえば、TLS が Kafka 設定で有効になっていない場合は、TLS でユーザーを認証できません。

前提条件

KafkaUser の認証タイプは、Kafka ブローカーに設定された認証と一致する必要があります。

手順

  1. KafkaUser リソースを設定します。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication: 1
        type: tls
      authorization:
        type: simple 2
        acls:
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Read
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
          - resource:
              type: group
              name: my-group
              patternType: literal
            operation: Read
    1
    相互 tls または scram-sha-512 として定義されたユーザー認証メカニズム。
    2
    ACL ルールのリストが必要な簡易承認。
  2. KafkaUser リソースを作成または更新します。

    oc apply -f USER-CONFIG-FILE

    KafkaUser リソースと同じ名前の Secret と共に、ユーザーが作成されます。Secret には、TLS クライアント認証の秘密鍵と公開鍵が含まれます。

Kafka ブローカーへの接続をセキュアにするために Kafka クライアントをプロパティーで設定する詳細は『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「OpenShift 外にあるクライアントへのアクセス設定」を参照してください。

5.3.3. ネットワークポリシーを使用した Kafka リスナーへのアクセス制限

networkPolicyPeers プロパティーを使用すると、リスナーへのアクセスを指定のアプリケーションのみに制限できます。

前提条件

  • Ingress NetworkPolicies をサポートする OpenShift クラスター。
  • 稼働中の Cluster Operator。

手順

  1. Kafka リソースを開きます。
  2. networkPolicyPeers プロパティーで、Kafka クラスターへのアクセスが許可されるアプリケーション Pod または namespace を定義します。

    以下は、ラベル appkafka-client に設定されているアプリケーションからの接続のみを許可するよう tls リスナーを設定する例になります。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
            networkPolicyPeers:
              - podSelector:
                  matchLabels:
                    app: kafka-client
        # ...
      zookeeper:
        # ...
  3. リソースを作成または更新します。

    次のように oc apply を使用します。

    oc apply -f your-file

5.4. OAuth 2.0 トークンベース認証の使用

AMQ Streams は、OAUTHBEARER および PLAIN メカニズムを使用して、OAuth 2.0 認証 の使用をサポートします。

OAuth 2.0 は、アプリケーション間で標準的なトークンベースの認証および承認を有効にし、中央の承認サーバーを使用してリソースに制限されたアクセス権限を付与するトークンを発行します。

OAuth 2.0 認証を設定した後に OAuth 2.0 承認 を設定できます。

Kafka ブローカーおよびクライアントの両方が OAuth 2.0 を使用するように設定する必要があります。OAuth 2.0 認証は、simple または OPA ベースの Kafka authorization と併用することもできます。

OAuth 2.0 のトークンベースの認証を使用すると、アプリケーションクライアントはアカウントのクレデンシャルを公開せずにアプリケーションサーバー (リソースサーバー と呼ばれる) のリソースにアクセスできます。

アプリケーションクライアントは、アクセストークンを認証の手段として渡します。アプリケーションサーバーはこれを使用して、付与するアクセス権限のレベルを決定することもできます。承認サーバーは、アクセスの付与とアクセスに関する問い合わせを処理します。

AMQ Streams のコンテキストでは以下が行われます。

  • Kafka ブローカーは OAuth 2.0 リソースサーバーとして動作します。
  • Kafka クライアントは OAuth 2.0 アプリケーションクライアントとして動作します。

Kafka クライアントは Kafka ブローカーに対して認証を行います。ブローカーおよびクライアントは、必要に応じて OAuth 2.0 承認サーバーと通信し、アクセストークンを取得または検証します。

AMQ Streams のデプロイメントでは、OAuth 2.0 インテグレーションは以下を提供します。

  • Kafka ブローカーのサーバー側 OAuth 2.0 サポート。
  • Kafka MirrorMaker、Kafka Connect、および Kafka Bridge のクライアント側 OAuth 2.0 サポート。

5.4.1. OAuth 2.0 認証メカニズム

AMQ Streams は、OAuth 2.0 認証で OAUTHBEARER および PLAIN メカニズムをサポートします。どちらのメカニズムも、Kafka クライアントが Kafka ブローカーで認証されたセッションを確立できるようにします。クライアント、承認サーバー、および Kafka ブローカー間の認証フローは、メカニズムごとに異なります。

可能な限り、OAUTHBEARER を使用するようにクライアントを設定することが推奨されます。OAUTHBEARER では、クライアントクレデンシャルは Kafka ブローカーと共有されることがないため、PLAIN よりも高レベルのセキュリティーが提供されます。OAUTHBEARER をサポートしない Kafka クライアントの場合のみ、PLAIN の使用を検討してください。

クライアントの接続に OAuth 2.0 認証を使用するように Kafka ブローカーリスナーを設定します。必要な場合は、同じ oauth リスナーで OAUTHBEARER および PLAIN メカニズムを使用できます。各メカニズムをサポートするプロパティーは、oauth リスナー設定で明示的に指定する必要があります。

OAUTHBEARER の概要

OAUTHBEARER は、Kafka ブローカーの oauth リスナー設定で自動的に有効になります。enableOauthBearer プロパティーを true に設定できますが、これは必須ではありません。

  # ...
  authentication:
    type: oauth
    # ...
    enableOauthBearer: true

また、多くの Kafka クライアントツールでは、プロトコルレベルで OAUTHBEARER の基本サポートを提供するライブラリーを使用します。AMQ Streams では、アプリケーションの開発をサポートするために、アップストリームの Kafka Client Java ライブラリーに OAuth コールバックハンドラー が提供されます (ただし、他のライブラリーは対象外)。そのため、独自のコールバックハンドラーを作成する必要はありません。アプリケーションクライアントはコールバックハンドラーを使用してアクセストークンを提供できます。Go などの他言語で書かれたクライアントは、カスタムコードを使用して承認サーバーに接続し、アクセストークンを取得する必要があります。

OAUTHBEARER を使用する場合、クライアントはクレデンシャルを交換するために Kafka ブローカーでセッションを開始します。ここで、クレデンシャルはコールバックハンドラーによって提供されるベアラートークンの形式を取ります。コールバックを使用して、以下の 3 つの方法のいずれかでトークンの提供を設定できます。

  • クライアント ID および Secret (OAuth 2.0 クライアントクレデンシャルメカニズム を使用)
  • 設定時に手動で取得された有効期限の長いアクセストークン
  • 設定時に手動で取得された有効期限の長い更新トークン
注記

OAUTHBEARER 認証は、プロトコルレベルで OAUTHBEARER メカニズムをサポートする Kafka クライアントでのみ使用できます。

PLAIN の概要

PLAIN を使用するには、Kafka ブローカーの oauth リスナー設定で有効にする必要があります。

以下の例では、デフォルトで有効になっている OAUTHBEARER に加え、PLAIN も有効になっています。PLAIN のみを使用する場合は、enableOauthBearerfalse に設定して OAUTHBEARER を無効にすることができます。

  # ...
  authentication:
    type: oauth
    # ...
    enablePlain: true
    tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token

PLAIN は、すべての Kafka クライアントツールによって使用される簡単な認証メカニズムです。PLAIN を OAuth 2.0 認証で使用できるようにするために、AMQ Streams では OAuth 2.0 over PLAIN サーバー側のコールバックが提供されます。

PLAIN の AMQ Streams 実装では、クライアントのクレデンシャルは ZooKeeper に保存されません。代わりに、OAUTHBEARER 認証が使用される場合と同様に、クライアントのクレデンシャルは準拠した承認サーバーの背後で一元的に処理されます。

OAuth 2.0 over PLAIN コールバックを併用する場合、以下のいずれかの方法を使用して Kafka クライアントは Kafka ブローカーで認証されます。

  • クライアント ID およびシークレット (OAuth 2.0 クライアントクレデンシャルメカニズムを使用)
  • 設定時に手動で取得された有効期限の長いアクセストークン

どちらの方法でも、クライアントは Kafka ブローカーにクレデンシャルを渡すために、PLAIN username および password プロパティーを提供する必要があります。クライアントはこれらのプロパティーを使用してクライアント ID およびシークレット、または、ユーザー名およびアクセストークンを渡します。

クライアント ID およびシークレットは、アクセストークンの取得に使用されます。

アクセストークンは、password プロパティーの値として渡されます。$accessToken: プレフィックスの有無に関わらずアクセストークンを渡します。

  • リスナー設定でトークンエンドポイント(tokenEndpointUri)を設定する場合は、プレフィックスが必要です。
  • リスナー設定でトークンエンドポイント(tokenEndpointUri)を設定しない場合は、プレフィックスは必要ありません。Kafka ブローカーは、パスワードを raw アクセストークンとして解釈します。

アクセストークンとして password が設定されている場合、username はKafka ブローカーがアクセストークンから取得するプリンシパル名と同じものを設定する必要があります。userNameClaimfallbackUserNameClaimfallbackUsernamePrefix、および userInfoEndpointUri プロパティーを使用すると、リスナーにユーザー名抽出オプションを指定できます。ユーザー名の抽出プロセスも、承認サーバーによって異なります。特に、クライアント ID をアカウント名にマッピングする方法により異なります。

5.4.2. OAuth 2.0 Kafka ブローカーの設定

OAuth 2.0 の Kafka ブローカー設定には、以下が関係します。

  • 承認サーバーでの OAuth 2.0 クライアントの作成
  • Kafka カスタムリソースでの OAuth 2.0 認証の設定
注記

承認サーバーに関連する Kafka ブローカーおよび Kafka クライアントはどちらも OAuth 2.0 クライアントと見なされます。

5.4.2.1. 承認サーバーの OAuth 2.0 クライアント設定

セッションの開始中に受信されたトークンを検証するように Kafka ブローカーを設定するには、承認サーバーで OAuth 2.0 の クライアント 定義を作成し、以下のクライアントクレデンシャルが有効な状態で 機密情報 として設定することが推奨されます。

  • kafka のクライアント ID (例)
  • 認証メカニズムとしてのクライアント ID およびシークレット
注記

承認サーバーのパブリックでないイントロスペクションエンドポイントを使用する場合のみ、クライアント ID およびシークレットを使用する必要があります。高速のローカル JWT トークンの検証と同様に、パブリック承認サーバーのエンドポイントを使用する場合は、通常クレデンシャルは必要ありません。

5.4.2.2. Kafka クラスターでの OAuth 2.0 認証設定

Kafka クラスターで OAuth 2.0 認証を使用するには、たとえば、認証方法が oauth の Kafka クラスターカスタムリソースの TLS リスナー設定を指定します。

OAuth 2.0 の認証方法タイプの割り当て

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
      #...

plainplainexternal リスナーを設定することができますが、plain や TLS 暗号化を無効にした external リスナーを OAuth 2.0 で使用すると、ネットワークの盗聴やトークンの盗難による不正アクセスの脆弱性が生じるため、使用しないことをお勧めします。

external リスナーを type: oauth で設定し、セキュアなトランスポート層がクライアントと通信するようにします。

OAuth 2.0 の外部リスナーとの使用

# ...
listeners:
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: oauth
    #...

tls プロパティーはデフォルトで false に設定されているため、有効にする必要があります。

認証のタイプを OAuth 2.0 として定義した場合、検証のタイプに基づいて、 高速のローカル JWT 検証 または イントロスペクションエンドポイントを使用したトークンの検証 のいずれかとして、設定を追加します。

説明や例を用いてリスナー向けに OAuth 2.0 を設定する手順は、「Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。

5.4.2.3. 高速なローカル JWT トークン検証の設定

高速なローカル JWT トークンの検証では、JWTトークンの署名がローカルでチェックされます。

ローカルチェックでは、トークンに対して以下が確認されます。

  • アクセストークンに Bearer の (typ) 要求値が含まれ、トークンがタイプに準拠することを確認します。
  • 有効であるか (期限切れでない) を確認します。
  • トークンに validIssuerURI と一致する発行元があることを確認します。

リスナーの設定時に validIssuerURI 属性を指定することで、認証サーバーから発行されていないトークンは拒否されます。

高速のローカル JWT トークン検証の実行中に、承認サーバーの通信は必要はありません。OAuth 2.0 の承認サーバーによって公開されるエンドポイントの jwksEndpointUri 属性を指定して、高速のローカル JWT トークン検証をアクティベートします。エンドポイントには、署名済み JWT トークンの検証に使用される公開鍵が含まれます。これらは、Kafka クライアントによってクレデンシャルとして送信されます。

注記

承認サーバーとの通信はすべて TLS による暗号化を使用して実行する必要があります。

証明書トラストストアを AMQ Streams プロジェクト namespace の OpenShift シークレットとして設定し、tlsTrustedCertificates 属性を使用してトラストストアファイルが含まれる OpenShift シークレットを示すことができます。

JWT トークンからユーザー名を適切に取得するため、userNameClaim の設定を検討してください。Kafka ACL 承認を使用する場合は、認証中にユーザー名でユーザーを特定する必要があります。JWT トークンの sub 要求は、通常は一意な ID でユーザー名ではありません。

高速なローカル JWT トークン検証の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    #...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
          validIssuerUri: <https://<auth-server-address>/auth/realms/tls>
          jwksEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/certs>
          userNameClaim: preferred_username
          maxSecondsWithoutReauthentication: 3600
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt
    #...

5.4.2.4. OAuth 2.0 イントロスペクションエンドポイントの設定

OAuth 2.0 のイントロスペクションエンドポイントを使用したトークンの検証では、受信したアクセストークンは不透明として対処されます。Kafka ブローカーは、アクセストークンをイントロスペクションエンドポイントに送信します。このエンドポイントは、検証に必要なトークン情報を応答として返します。ここで重要なのは、特定のアクセストークンが有効である場合は最新情報を返すことで、トークンの有効期限に関する情報も返します。

OAuth 2.0 のイントロスペクションベースの検証を設定するには、高速のローカル JWT トークン検証に指定された jwksEndpointUri 属性ではなく、introspectionEndpointUri 属性を指定します。通常、イントロスペクションエンドポイントは保護されているため、承認サーバーに応じて clientId および clientSecret を指定する必要があります。

イントロスペクションエンドポイントの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
          clientId: kafka-broker
          clientSecret:
            secretName: my-cluster-oauth
            key: clientSecret
          validIssuerUri: <https://<auth-server-address>/auth/realms/tls>
          introspectionEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/token/introspect>
          userNameClaim: preferred_username
          maxSecondsWithoutReauthentication: 3600
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

5.4.3. Kafka ブローカーの再認証の設定

KafkaクライアントとKafkaブローカー間のOAuth 2.0セッションにKafka session re-authentication を使用するように、oauth リスナーを設定できます。このメカニズムは、定義された期間後に、クライアントとブローカー間の認証されたセッションを期限切れにします。セッションの有効期限が切れると、クライアントは既存のコネクションを破棄せずに再使用して、新しいセッションを即座に開始します。

セッションの再認証はデフォルトで無効になっています。これを有効にするには、oauth リスナー設定で maxSecondsWithoutReauthentication の時間値を設定します。OAUTHBEARER および PLAIN 認証では、同じプロパティーを使用してセッションの再認証が設定されます。設定例については、「Kafka ブローカーの OAuth 2.0 サポートの設定」 を参照してください。

セッションの再認証は、クライアントによって使用される Kafka クライアントライブラリーによってサポートされる必要があります。

セッションの再認証は、高速ローカル JWT またはイントロスペクションエンドポイントのトークン検証と使用できます。

クライアントの再認証

ブローカーの認証されたセッションが期限切れになると、クライアントは接続を切断せずに新しい有効なアクセストークンをブローカーに送信し、既存のセッションを再認証する必要があります。

トークンの検証に成功すると、既存の接続を使用して新しいクライアントセッションが開始されます。クライアントが再認証に失敗した場合、さらにメッセージを送受信しようとすると、ブローカーは接続を閉じます。ブローカーで再認証メカニズムが有効になっていると、Kafka クライアントライブラリー 2.2 以降を使用する Java クライアントが自動的に再認証されます。

更新トークンが使用される場合、セッションの再認証は更新トークンにも適用されます。セッションが期限切れになると、クライアントは更新トークンを使用してアクセストークンを更新します。その後、クライアントは新しいアクセストークンを使用して既存のセッションに再認証されます。

OAUTHBEARER および PLAIN のセッションの有効期限

セッションの再認証が設定されている場合、OAUTHBEARER と PLAIN 認証ではセッションの有効期限は異なります。

クライアント ID とシークレットによる方法を使用する OAUTHBEARER および PLAIN の場合:

  • ブローカーの認証されたセッションは、設定された maxSecondsWithoutReauthentication で期限切れになります。
  • アクセストークンが設定期間前に期限切れになると、セッションは設定期間前に期限切れになります。

有効期間の長いアクセストークンによる方法を使用する PLAIN の場合:

  • ブローカーの認証されたセッションは、設定された maxSecondsWithoutReauthentication で期限切れになります。
  • アクセストークンが設定期間前に期限切れになると、再認証に失敗します。セッションの再認証は試行されますが、PLAIN にはトークンを更新するメカニズムがありません。

maxSecondsWithoutReauthentication設定されていない 場合、OAUTHBEARER および PLAIN クライアントは、再認証しなくてもブローカーへの接続を無限に保持できます。認証されたセッションは、アクセストークンの期限が切れても終了しません。ただし、keycloak 承認を使用したり、カスタムオーソライザーをインストールして、承認を設定する場合に考慮できます。

5.4.4. OAuth 2.0 Kafka クライアントの設定

Kafka クライアントは以下のいずれかで設定されます。

  • 承認サーバーから有効なアクセストークンを取得するために必要なクレデンシャル (クライアント ID およびシークレット)。
  • 承認サーバーから提供されたツールを使用して取得された、有効期限の長い有効なアクセストークンまたは更新トークン。

アクセストークンは、Kafka ブローカーに送信される唯一の情報です。アクセストークンを取得するために承認サーバーでの認証に使用されるクレデンシャルは、ブローカーに送信されません。

クライアントによるアクセストークンの取得後、承認サーバーと通信する必要はありません。

クライアント ID とシークレットを使用した認証が最も簡単です。有効期間の長いアクセストークンまたは更新トークンを使用すると、承認サーバーツールに追加の依存関係があるため、より複雑になります。

注記

有効期間が長いアクセストークンを使用している場合は、承認サーバーでクライアントを設定し、トークンの最大有効期間を長くする必要があります。

Kafka クライアントが直接アクセストークンで設定されていない場合、クライアントは承認サーバーと通信して Kafka セッションの開始中にアクセストークンのクレデンシャルを交換します。Kafka クライアントは以下のいずれかを交換します。

  • クライアント ID およびシークレット
  • クライアント ID、更新トークン、および (任意の) シークレット

5.4.5. OAuth 2.0 クライアント認証フロー

OAuth 2.0 認証フローは、基礎となる Kafka クライアントおよび Kafka ブローカー設定によって異なります。フローは、使用する承認サーバーによってもサポートされる必要があります。

Kafka ブローカーリスナー設定は、クライアントがアクセストークンを使用して認証する方法を決定します。クライアントはクライアント ID およびシークレットを渡してアクセストークンをリクエストできます。

リスナーが PLAIN 認証を使用するように設定されている場合、クライアントはクライアント ID およびシークレット、または、ユーザー名およびアクセストークンで認証できます。これらの値は PLAIN メカニズムの username および password プロパティーとして渡されます。

リスナー設定は、以下のトークン検証オプションをサポートします。

  • 承認サーバーと通信しない、JWT の署名確認およびローカルトークンのイントロスペクションをベースとした高速なローカルトークン検証を使用できます。承認サーバーは、トークンで署名を検証するために使用される公開証明書のある JWKS エンドポイントを提供します。
  • 承認サーバーが提供するトークンイントロスペクションエンドポイントへの呼び出しを使用することができます。新しい Kafka ブローカー接続が確立されるたびに、ブローカーはクライアントから受け取ったアクセストークンを承認サーバーに渡します。Kafka ブローカーは応答を確認して、トークンが有効かどうかを確認します。
注記

承認サーバーは不透明なアクセストークンの使用のみを許可する可能性があり、この場合はローカルトークンの検証は不可能です。

Kafka クライアントクレデンシャルは、以下のタイプの認証に対して設定することもできます。

  • 以前に生成された有効期間の長いアクセストークンを使用した直接ローカルアクセス。
  • 新しいアクセストークンを発行するための承認サーバーとの通信(クライアント ID およびシークレットまたは更新トークンを使用)

5.4.5.1. SASL OAUTHBEARER メカニズムを使用したクライアント認証フローの例

SASL OAUTHBEARER メカニズムを使用して、Kafka 認証に以下の通信フローを使用できます。

クライアントではクライアント ID とシークレットが使用され、ブローカーによって検証が承認サーバーに委譲される場合

Client using client ID and secret with broker delegating validation to authorization server

  1. Kafka クライアントは、クライアント ID およびシークレットを使用して承認サーバーからアクセストークンを要求し、必要に応じて更新トークンを要求します。
  2. 承認サーバーは新しいアクセストークンを生成します。
  3. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用してアクセストークンを渡すことで Kafka ブローカーで認証されます。
  4. Kafka ブローカーは、独自のクライアント ID およびシークレットを使用し、承認サーバーでトークンイントロスペクションエンドポイントを呼び出すことで、アクセストークンを検証します。
  5. トークンが有効な場合、Kafka クライアントセッションが確立されます。

クライアントではクライアント ID およびシークレットが使用され、ブローカーによって高速のローカルトークン検証が実行される場合。

Client using client ID and secret with broker performing fast local token validation

  1. Kafka クライアントは、クライアント ID およびシークレットを使用し、オプションで更新トークンを使用して、トークンエンドポイントから承認サーバーで認証します。
  2. 承認サーバーは新しいアクセストークンを生成します。
  3. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用してアクセストークンを渡すことで Kafka ブローカーで認証されます。
  4. Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。

クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって検証が承認サーバーに委譲される場合。

Client using long-lived access token with broker delegating validation to authorization server

  1. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
  2. Kafka ブローカーは、独自のクライアント ID およびシークレットを使用して、承認サーバーでトークンイントロスペクションエンドポイントを呼び出し、アクセストークンを検証します。
  3. トークンが有効な場合、Kafka クライアントセッションが確立されます。

クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって高速のローカル検証が実行される場合。

Client using long-lived access token with broker performing fast local validation

  1. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
  2. Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。
警告

トークンが取り消された場合に承認サーバーとのチェックが行われないため、高速のローカル JWT トークン署名の検証は有効期限の短いトークンにのみ適しています。トークンの有効期限はトークンに書き込まれますが、失効はいつでも発生する可能性があるため、承認サーバーと通信せずに対応することはできません。発行されたトークンはすべて期限切れになるまで有効とみなされます。

5.4.5.2. SASL PLAIN メカニズムを使用したクライアント認証フローの例

OAuth PLAIN メカニズムを使用すると、Kafka 認証に以下の通信フローを使用できます。

クライアント ID およびシークレットが使用され、ブローカーによってクライアントのアクセストークンが取得されたクライアント

Client using a client ID and secret with the broker obtaining the access token for the client

  1. Kafka クライアントは、clientId をユーザー名として、secret をパスワードとして渡します。
  2. Kafka ブローカーは、トークンエンドポイントを使用して clientId および secret を承認サーバーに渡します。
  3. 承認サーバーは、新しいアクセストークンまたはエラー (クライアントクレデンシャルが有効でない場合) を返します。
  4. Kafka ブローカーは、以下のいずれかの方法でトークンを検証します。

    1. トークンイントロスペクションエンドポイントが指定されている場合、Kafka ブローカーは承認サーバーでエンドポイントを呼び出すことで、アクセストークンを検証します。トークンの検証に成功した場合には、セッションが確立されます。
    2. ローカルトークンのイントロスペクションが使用される場合、要求は承認サーバーに対して行われません。Kafka ブローカーは、JWT トークン署名チェックを使用して、アクセストークンをローカルで検証します。

クライアント ID およびシークレットなしで有効期限の長いアクセストークンを使用するクライアント

Client using a long-lived access token without a client ID and secret

  1. Kafka クライアントはユーザー名とパスワードを渡します。パスワードは、クライアントを実行する前に手動で取得および設定されたアクセストークンの値を提供します。
  2. Kafka ブローカーリスナーが認証のトークンエンドポイントで設定されているかどうかに応じて、$accessToken: 文字列のプレフィックスの有無にかかわらず、パスワードは渡されます。

    1. トークンエンドポイントが設定されている場合、パスワードの前に $accessToken: を付け、password パラメーターにクライアントシークレットではなくアクセストークンが含まれていることをブローカーに知らせる必要があります。Kafka ブローカーは、ユーザー名をアカウントのユーザー名として解釈します。
    2. トークンエンドポイントが Kafka ブローカーリスナーで設定されていない場合(no-client-credentials mode を強制)、パスワードは接頭辞なしでアクセストークンを提供する必要があります。Kafka ブローカーは、ユーザー名をアカウントのユーザー名として解釈します。このモードでは、クライアントはクライアント ID およびシークレットを使用せず、password パラメーターは常に raw アクセストークンとして解釈されます。
  3. Kafka ブローカーは、以下のいずれかの方法でトークンを検証します。

    1. トークンイントロスペクションエンドポイントが指定されている場合、Kafka ブローカーは承認サーバーでエンドポイントを呼び出すことで、アクセストークンを検証します。トークンの検証に成功した場合には、セッションが確立されます。
    2. ローカルトークンイントロスペクションが使用されている場合には、承認サーバーへの要求はありません。Kafka ブローカーは、JWT トークン署名チェックを使用して、アクセストークンをローカルで検証します。

5.4.6. OAuth 2.0 認証の設定

OAuth 2.0 は、Kafka クライアントと AMQ Streams コンポーネントとの対話に使用されます。

AMQ Streams に OAuth 2.0 を使用するには、以下を行う必要があります。

5.4.6.1. OAuth 2.0 承認サーバーとしての Red Hat Single Sign-On の設定

この手順では、Red Hat Single Sign-On を承認サーバーとしてデプロイし、AMQ Streams と統合するための設定方法を説明します。

承認サーバーは、一元的な認証および承認の他、ユーザー、クライアント、およびパーミッションの一元管理を実現します。Red Hat Single Sign-On にはレルムの概念があります。レルム はユーザー、クライアント、パーミッション、およびその他の設定の個別のセットを表します。デフォルトの マスターレルム を使用できますが、新しいレルムを作成することもできます。各レルムは独自の OAuth 2.0 エンドポイントを公開します。そのため、アプリケーションクライアントとアプリケーションサーバーはすべて同じレルムを使用する必要があります。

AMQ Streams で OAuth 2.0 を使用するには、Red Hat Single Sign-On のデプロイメントを使用して認証レルムを作成および管理します。

注記

Red Hat Single Sign-On がすでにデプロイされている場合は、デプロイメントの手順を省略して、現在のデプロイメントを使用できます。

作業を開始する前に

Red Hat Single Sign-On を使用するための知識が必要です。

インストールおよび管理の手順は、以下を参照してください。

前提条件

  • AMQ Streams および Kafka が稼働している必要があります。

Red Hat Single Sign-On デプロイメントに関する条件:

手順

  1. Red Hat Single Sign-On を OpenShift クラスターにデプロイします。

    OpenShift Web コンソールでデプロイメントの進捗を確認します。

  2. Red Hat Single Sign-On の Admin Console にログインし、AMQ Streams の OAuth 2.0 ポリシーを作成します。

    ログインの詳細は、Red Hat Single Sign-On のデプロイ時に提供されます。

  3. レルムを作成し、有効にします。

    既存のマスターレルムを使用できます。

  4. 必要に応じて、レルムのセッションおよびトークンのタイムアウトを調整します。
  5. kafka-broker というクライアントを作成します。
  6. Settings タブで以下を設定します。

    • Access TypeConfidential に設定します。
    • Standard Flow EnabledOFF に設定し、このクライアントからの Web ログインを無効にします。
    • Service Accounts EnabledON に設定し、このクライアントが独自の名前で認証できるようにします。
  7. 続行する前に Save クリックします。
  8. Credentials タブにある、AMQ Streams の Kafka クラスター設定で使用するシークレットを書き留めておきます。
  9. Kafka ブローカーに接続するすべてのアプリケーションクライアントに対して、このクライアント作成手順を繰り返し行います。

    新しいクライアントごとに定義を作成します。

    設定では、名前をクライアント ID として使用します。

次のステップ

承認サーバーのデプロイおよび設定後に、Kafka ブローカーが OAuth 2.0 を使用するように設定 します。

5.4.6.2. Kafka ブローカーの OAuth 2.0 サポートの設定

この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。

TLS リスナーを設定して、暗号化されたインターフェースで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。

承認サーバーが信頼できる CA によって署名された証明書を使用し、OAuth 2.0 サーバーのホスト名と一致する場合、TLS 接続はデフォルト設定を使用して動作します。それ以外の場合は、プローバー証明書でトラストストアを設定するか、証明書のホスト名の検証を無効にする必要があります。

Kafka ブローカーの設定する場合、新たに接続された Kafka クライアントの OAuth 2.0 認証中にアクセストークンを検証するために使用されるメカニズムには、以下の 2 つのオプションがあります。

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

Kafka ブローカーリスナーの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。

前提条件

  • AMQ Streams および Kafka が稼働している必要があります。
  • OAuth 2.0 の承認サーバーがデプロイされている必要があります。

手順

  1. エディターで、Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新します。

    oc edit kafka my-cluster
  2. Kafka ブローカーの listeners 設定を行います。

    各タイプのリスナーは独立しているため、同じ設定にする必要はありません。

    以下は、外部リスナーに設定された設定オプションの例になります。

    例 1:高速なローカル JWT トークン検証の設定

    #...
    - name: external
      port: 9094
      type: loadbalancer
      tls: true
      authentication:
        type: oauth 1
        validIssuerUri: <https://<auth-server-address>/auth/realms/external> 2
        jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 3
        userNameClaim: preferred_username 4
        maxSecondsWithoutReauthentication: 3600 5
        tlsTrustedCertificates: 6
        - secretName: oauth-server-cert
          certificate: ca.crt
        disableTlsHostnameVerification: true 7
        jwksExpirySeconds: 360 8
        jwksRefreshSeconds: 300 9
        jwksMinRefreshPauseSeconds: 1 10

    1
    oauth に設定されたリスナータイプ。
    2
    認証に使用されるトークン発行者の URI。
    3
    ローカルの JWT 検証に使用される JWKS 証明書エンドポイントの URI。
    4
    トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。userNameClaim の値は、使用される認証フローと承認サーバーによって異なります。
    5
    (任意設定): セッションの有効期限がアクセストークンと同じ期間になるよう強制する Kafka の再認証メカニズムを有効にします。指定された値がアクセストークンの有効期限が切れるまでの残り時間未満の場合、クライアントは実際にトークンの有効期限が切れる前に再認証する必要があります。デフォルトでは、アクセストークンの期限が切れてもセッションは期限切れにならず、クライアントは再認証を試行しません。
    6
    (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
    7
    (任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
    8
    JWKS 証明書が期限切れになる前に有効であるとみなされる期間。デフォルトは 360 秒です。デフォルトよりも長い時間を指定する場合は、無効になった証明書へのアクセスが許可されるリスクを考慮してください。
    9
    JWKS 証明書を更新する間隔。この間隔は、有効期間よりも 60 秒以上短くする必要があります。デフォルトは 300 秒です。
    10
    JWKS 公開鍵の更新が連続して試行される間隔の最小一時停止時間 (秒単位)。不明な署名キーが検出されると、JWKS キーの更新は、最後に更新を試みてから少なくとも指定された期間は一時停止し、通常の定期スケジュール以外でスケジュールされます。キーの更新は指数バックオフ(指数バックオフ)のルールに従い、jwksRefreshSeconds に到達するまで、一時停止を増やして失敗した更新を再試行します。デフォルト値は 1 です。

    例 2:イントロスペクションエンドポイントを使用したトークン検証の設定

    - name: external
      port: 9094
      type: loadbalancer
      tls: true
      authentication:
        type: oauth
        validIssuerUri: <https://<auth-server-address>/auth/realms/external>
        introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect> 1
        clientId: kafka-broker 2
        clientSecret: 3
          secretName: my-cluster-oauth
          key: clientSecret
        userNameClaim: preferred_username 4
        maxSecondsWithoutReauthentication: 3600 5

    1
    トークンイントロスペクションエンドポイントの URI。
    2
    クライアントを識別するためのクライアント ID。
    3
    認証にはクライアントシークレットとクライアント ID が使用されます。
    4
    トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。userNameClaim の値は、使用される承認サーバーによって異なります。
    5
    (任意設定): セッションの有効期限がアクセストークンと同じ期間になるよう強制する Kafka の再認証メカニズムを有効にします。指定された値がアクセストークンの有効期限が切れるまでの残り時間未満の場合、クライアントは実際にトークンの有効期限が切れる前に再認証する必要があります。デフォルトでは、アクセストークンの期限が切れてもセッションは期限切れにならず、クライアントは再認証を試行しません。

    OAuth 2.0 認証の適用方法や、承認サーバーのタイプによっては、追加 (任意) の設定を使用できます。

      # ...
      authentication:
        type: oauth
        # ...
        checkIssuer: false 1
        checkAudience: true 2
        fallbackUserNameClaim: client_id 3
        fallbackUserNamePrefix: client-account- 4
        validTokenType: bearer 5
        userInfoEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 6
        enableOauthBearer: false 7
        enablePlain: true 8
        tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token 9
        customClaimCheck: "@.custom == 'custom-value'" 10
        clientAudience: AUDIENCE 11
        clientScope: SCOPE 12
        connectTimeoutSeconds: 60 13
        readTimeoutSeconds: 60 14
        groupsClaim: "$.groups" 15
        groupsClaimDelimiter: "," 16
    1
    承認サーバーが iss クレームを提供しない場合は、発行者チェックを行うことができません。このような場合、checkIssuerfalse に設定し、validIssuerUri を指定しないようにします。デフォルトは true です。
    2
    オーソリゼーションサーバーが aud(オーディエンス)クレームを提供していて、オーディエンスチェックを実施したい場合は、checkAudiencetrue に設定します。オーディエンスチェックによって、トークンの目的の受信者が特定されます。これにより、Kafka ブローカーは aud 要求に clientId を持たないトークンを拒否します。デフォルトは false です。
    3
    承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。クライアントが独自の名前で認証される場合、サーバーによって クライアント ID が提供されることがあります。更新トークンまたはアクセストークンを取得するために、ユーザー名およびパスワードを使用してユーザーが認証される場合、サーバーによってクライアント ID の他に ユーザー名 が提供されることがあります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
    4
    fallbackUserNameClaim が適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producer というクライアントが存在し、producer という通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。
    5
    (introspectionEndpointUri を使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。
    6
    (introspectionEndpointUri を使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfo エンドポイントの URI をフォールバックとして設定します。userNameClaimfallbackUserNameClaim、および fallbackUserNamePrefix の設定が userinfo エンドポイントの応答に適用されます。
    7
    これを false に設定してリスナーで OAUTHBEARER メカニズムを無効にします。PLAIN または OAUTHBEARER のいずれかを有効にする必要があります。デフォルトは true です。
    8
    リスナーで PLAIN 認証を有効にするには、true に設定します。これは、すべてのプラットフォームのすべてのクライアントでサポートされています。
    9
    PLAIN メカニズムの追加設定。これが指定されている場合、クライアントは $accessToken: プレフィックスを使用してアクセストークンを password として渡すことで、PLAIN 経由で認証できます。実稼働環境の場合は、常に https:// urls を使用してください。
    10
    これを JsonPath フィルタークエリーに設定すると、検証中に追加のカスタムルールを JWT アクセストークンに適用できます。アクセストークンに必要なデータが含まれていないと拒否されます。introspectionEndpointUri を使用する場合、カスタムチェックはイントロスペクションエンドポイントの応答 JSON に適用されます。
    11
    トークンエンドポイントに渡される audience パラメーター。オーディエンスは、ブローカー間認証用にアクセストークンを取得する場合に使用されます。また、clientIdsecret を使った PLAIN クライアント認証の上にある OAuth 2.0 のクライアント名にも使われています。これは、承認サーバーに応じて、トークンの取得機能とトークンの内容のみに影響します。リスナーによるトークン検証ルールには影響しません。
    12
    scope パラメーターがトークンエンドポイントに渡されます。スコープは、ブローカー間認証用にアクセストークンを取得する場合に使用されます。また、clientIdsecret を使った PLAIN クライアント認証の上にある OAuth 2.0 のクライアント名にも使われています。これは、承認サーバーに応じて、トークンの取得機能とトークンの内容のみに影響します。リスナーによるトークン検証ルールには影響しません。
    13
    承認サーバーへの接続時のタイムアウト(秒単位)。デフォルト値は 60 です。
    14
    承認サーバーへの接続時の読み取りタイムアウト(秒単位)。デフォルト値は 60 です。
    15
    JWT トークンまたはイントロスペクションエンドポイントの応答からグループ情報を抽出するために使用される JsonPath クエリー。デフォルトでは設定されません。これは、カスタム承認者がユーザーグループに基づいて承認を決定するために使用できます。
    16
    1 つのコンマ区切りの文字列として返されるときにグループ情報を解析するのに使用される区切り文字。デフォルト値は 「,」(コンマ) です。
  3. エディターを保存して終了し、ローリングアップデートの完了を待ちます。
  4. 更新をログで確認するか、または Pod 状態の遷移を監視して確認します。

    oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
    oc get pod -w

    ローリングアップデートによって、ブローカーが OAuth 2.0 認証を使用するように設定されます。

5.4.6.3. OAuth 2.0 を使用するよう Kafka Java クライアントを設定

この手順では、Kafka ブローカーとの対話に OAuth 2.0 を使用するように Kafka プロデューサーおよびコンシューマー API を設定する方法を説明します。

クライアントコールバックプラグインを pom.xml ファイルに追加し、システムプロパティーを設定します。

前提条件

  • AMQ Streams および Kafka が稼働している必要があります。
  • OAuth 2.0 承認サーバーがデプロイされ、Kafka ブローカーへの OAuth のアクセスが設定されている必要があります。
  • Kafka ブローカーが OAuth 2.0 に対して設定されている必要があります。

手順

  1. OAuth 2.0 サポートのあるクライアントライブラリーを Kafka クライアントの pom.xml ファイルに追加します。

    <dependency>
     <groupId>io.strimzi</groupId>
     <artifactId>kafka-oauth-client</artifactId>
     <version>0.10.0.redhat-00002</version>
    </dependency>
  2. コールバックのシステムプロパティーを設定します。

    以下はその例です。

    System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 1
    System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client_name>"); 2
    System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client_secret>"); 3
    System.setProperty(ClientConfig.OAUTH_SCOPE, "<scope_value>") 4
    System.setProperty(ClientConfig.OAUTH_AUDIENCE, "<audience_value") 5
    1
    承認サーバーのトークンエンドポイントの URI です。
    2
    クライアント ID。承認サーバーで client を作成するときに使用される名前です。
    3
    承認サーバーで client を作成するときに作成されるクライアントシークレット。
    4
    (任意設定): トークンエンドポイントからトークンを要求するための scope。認証サーバーでは、クライアントによるスコープの指定が必要になることがあります。
    5
    (オプション)トークンエンドポイントからトークンを要求するための audience。認証サーバーでは、クライアントによるオーディエンスの指定が必要になることがあります。
  3. Kafka クライアント設定の TLS で暗号化された接続で OAUTHBEARER または PLAIN メカニズムを有効にします。

    以下はその例です。

    Kafka クライアントの OAUTHBEARER の有効化

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
    props.put("security.protocol", "SASL_SSL");
    props.put("sasl.mechanism", "OAUTHBEARER");
    props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

    Kafka クライアントの PLAIN の有効化

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"$CLIENT_ID_OR_ACCOUNT_NAME\" password=\"$SECRET_OR_ACCESS_TOKEN\" ;");
    props.put("security.protocol", "SASL_SSL"); 1
    props.put("sasl.mechanism", "PLAIN");

    1
    この例では、TLS 接続で SASL_SSL を使用します。ローカル開発のみでは、暗号化されていない接続で SASL_PLAINTEXT を使用します。
  4. Kafka クライアントが Kafka ブローカーにアクセスできることを確認します。

5.4.6.4. Kafka コンポーネントの OAuth 2.0 の設定

この手順では、承認サーバーを使用して OAuth 2.0 認証を使用するように Kafka コンポーネントを設定する方法を説明します。

以下の認証を設定できます。

  • Kafka Connect
  • Kafka MirrorMaker
  • Kafka Bridge

この手順では、Kafka コンポーネントと承認サーバーは同じサーバーで稼働しています。

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

Kafka コンポーネントの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。

前提条件

  • AMQ Streams および Kafka が稼働している必要があります。
  • OAuth 2.0 承認サーバーがデプロイされ、Kafka ブローカーへの OAuth のアクセスが設定されている必要があります。
  • Kafka ブローカーが OAuth 2.0 に対して設定されている必要があります。

手順

  1. クライアントシークレットを作成し、これを環境変数としてコンポーネントにマウントします。

    以下は、Kafka Bridge の Secret を作成する例になります。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Secret
    metadata:
     name: my-bridge-oauth
    type: Opaque
    data:
     clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 1
    1
    clientSecret キーは base64 形式である必要があります。
  2. Kafka コンポーネントのリソースを作成または編集し、OAuth 2.0 認証が認証プロパティーに設定されるようにします。

    OAuth 2.0 認証では、以下を使用できます。

    • クライアント ID およびシークレット
    • クライアント ID および更新トークン
    • アクセストークン
    • TLS

    KafkaClientAuthenticationOAuth スキーマ参照は、それぞれの例を提供します

    以下は、クライアント ID、シークレット、および TLS を使用して OAuth 2.0 が Kafka Bridge クライアントに割り当てられる例になります。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaBridge
    metadata:
      name: my-bridge
    spec:
      # ...
      authentication:
        type: oauth 1
        tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 2
        clientId: kafka-bridge
        clientSecret:
          secretName: my-bridge-oauth
          key: clientSecret
        tlsTrustedCertificates: 3
        - secretName: oauth-server-cert
          certificate: tls.crt
    1
    oauth に設定された認証タイプ。
    2
    認証用のトークンエンドポイントの URI。
    3
    承認サーバーへの TLS 接続用の信用できる証明書。

    OAuth 2.0 認証の適用方法や、承認サーバーのタイプによって、使用できる追加の設定オプションがあります。

    # ...
    spec:
      # ...
      authentication:
        # ...
        disableTlsHostnameVerification: true 1
        checkAccessTokenType: false 2
        accessTokenIsJwt: false 3
        scope: any 4
        audience: kafka 5
        connectTimeoutSeconds: 60 6
        readTimeoutSeconds: 60 7
    1
    (任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
    2
    承認サーバーによって、JWT トークン内部で typ (タイプ) 要求が返されない場合は、checkAccessTokenType: false を適用するとトークンタイプがチェックされず次に進むことができます。デフォルトは true です。
    3
    不透明なトークンを使用している場合、アクセストークンが JWT トークンとして処理されないように accessTokenIsJwt: false を適用することができます。
    4
    (任意設定): トークンエンドポイントからトークンを要求するための scope。認証サーバーでは、クライアントによるスコープの指定が必要になることがあります。この場合では any になります。
    5
    (オプション)トークンエンドポイントからトークンを要求するための audience。認証サーバーでは、クライアントによるオーディエンスの指定が必要になることがあります。今回の場合は kafka です。
    6
    (オプション) 承認サーバーへの接続時のタイムアウト(秒単位)。デフォルト値は 60 です。
    7
    (オプション): 承認サーバーへの接続時の読み取りタイムアウト(秒単位)。デフォルト値は 60 です。
  3. Kafka リソースのデプロイメントに変更を適用します。

    oc apply -f your-file
  4. 更新をログで確認するか、または Pod 状態の遷移を監視して確認します。

    oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
    oc get pod -w

    ローリングアップデートでは、OAuth 2.0 認証を使用して Kafka ブローカーと対話するコンポーネントが設定されます。

5.5. OAuth 2.0 トークンベース承認の使用

トークンベースの認証に OAuth 2.0 と Red Hat Single Sign-On を使用している場合、Red Hat Single Sign-On を使用して承認ルールを設定し、Kafka ブローカーへのクライアントのアクセスを制限することもできます。認証はユーザーのアイデンティティーを確立します。承認は、そのユーザーのアクセスレベルを決定します。

AMQ Streams は、Red Hat Single Sign-On の 承認サービス による OAuth 2.0 トークンベースの承認をサポートします。これにより、セキュリティーポリシーとパーミッションの一元的な管理が可能になります。

Red Hat Single Sign-On で定義されたセキュリティーポリシーおよびパーミッションは、Kafka ブローカーのリソースへのアクセスを付与するために使用されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。

Kafka では、デフォルトですべてのユーザーがブローカーに完全アクセスできます。また、アクセス制御リスト(ACL)を基にして承認を設定するために AclAuthorizer プラグインが提供されます。

ZooKeeper には、 ユーザー名 を基にしてリソースへのアクセスを付与または拒否する ACL ルールが保存されます。ただし、Red Hat Single Sign-On を使用した OAuth 2.0 トークンベースの承認では、より柔軟にアクセス制御を Kafka ブローカーに実装できます。さらに、Kafka ブローカーで OAuth 2.0 の承認および ACL が使用されるように設定することができます。

5.5.1. OAuth 2.0 の承認メカニズム

AMQ Streams の OAuth 2.0 での承認では、Red Hat Single Sign-On サーバーの Authorization Services REST エンドポイントを使用して、Red Hat Single Sign-On を使用するトークンベースの認証が拡張されます。これは、定義されたセキュリティーポリシーを特定のユーザーに適用し、そのユーザーの異なるリソースに付与されたパーミッションの一覧を提供します。ポリシーはロールとグループを使用して、パーミッションをユーザーと照合します。OAuth 2.0 の承認では、Red Hat Single Sign-On の Authorization Services から受信した、ユーザーに付与された権限のリストを基にして、権限がローカルで強制されます。

5.5.1.1. Kafka ブローカーのカスタムオーソライザー

AMQ Streams では、Red Hat Single Sign-On の オーソライザー (KeycloakRBACAuthorizer) が提供されます。Red Hat Single Sign-On によって提供される Authorization Services で Red Hat Single Sign-On REST エンドポイントを使用できるようにするには、Kafka ブローカーでカスタムオーソライザーを設定します。

オーソライザーは必要に応じて付与された権限のリストを承認サーバーから取得し、ローカルで Kafka ブローカーに承認を強制するため、クライアントの要求ごとに迅速な承認決定が行われます。

5.5.2. OAuth 2.0 承認サポートの設定

この手順では、Red Hat Single Sign-On の Authorization Services を使用して、OAuth 2.0 承認を使用するように Kafka ブローカーを設定する方法を説明します。

作業を開始する前に

特定のユーザーに必要なアクセス、または制限するアクセスについて検討してください。Red Hat Single Sign-On では、Red Hat Single Sign-On の グループロールクライアント、および ユーザー の組み合わせを使用して、アクセスを設定できます。

通常、グループは組織の部門または地理的な場所を基にしてユーザーを照合するために使用されます。また、ロールは職務を基にしてユーザーを照合するために使用されます。

Red Hat Single Sign-On を使用すると、ユーザーおよびグループを LDAP で保存できますが、クライアントおよびロールは LDAP で保存できません。ユーザーデータへのアクセスとストレージを考慮して、承認ポリシーの設定方法を選択する必要がある場合があります。

注記

スーパーユーザー は、Kafka ブローカーに実装された承認にかかわらず、常に制限なく Kafka ブローカーにアクセスできます。

前提条件

  • AMQ Streams は、トークンベースの認証 に Red Hat Single Sign-On と OAuth 2.0 を使用するように設定されている必要があります。承認を設定するときに、同じ Red Hat Single Sign-On サーバーエンドポイントを使用する必要があります。
  • OAuth 2.0 認証は、再認証を有効にするために maxSecondsWithoutReauthentication オプションで設定する必要があります。

手順

  1. Red Hat Single Sign-On の Admin Console にアクセスするか、Red Hat Single Sign-On の Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
  2. 承認サービスを使用して、クライアントのリソース、承認スコープ、ポリシー、およびパーミッションを定義します。
  3. ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
  4. エディターで Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新して、Kafka ブローカーで Red Hat Single Sign-On による承認が使用されるように設定します。

    oc edit kafka my-cluster
  5. Kafka ブローカーの kafka 設定を指定して、keycloak による承認を使用し、承認サーバーと Red Hat Single Sign-On の Authorization Services にアクセスできるようにします。

    以下はその例です。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        authorization:
          type: keycloak 1
          tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token> 2
          clientId: kafka 3
          delegateToKafkaAcls: false 4
          disableTlsHostnameVerification: false 5
          superUsers: 6
          - CN=fred
          - sam
          - CN=edward
          tlsTrustedCertificates: 7
          - secretName: oauth-server-cert
            certificate: ca.crt
          grantsRefreshPeriodSeconds: 60 8
          grantsRefreshPoolSize: 5 9
          connectTimeoutSeconds: 60 10
          readTimeoutSeconds: 60 11
        #...
    1
    タイプ keycloak によって Red Hat Single Sign-On の承認が有効になります。
    2
    Red Hat Single Sign-On トークンエンドポイントの URI。実稼働環境の場合は、常に https:// urls を使用してください。トークンベースの oauth 認証を設定する場合、jwksEndpointUri をローカル JWT 検証の URI として指定します。tokenEndpointUri URI のホスト名は同じである必要があります。
    3
    承認サービスが有効になっている Red Hat Single Sign-On の OAuth 2.0 クライアント定義のクライアント ID。通常、kafka が ID として使用されます。
    4
    (オプション) Red Hat Single Sign-On Authorization Services ポリシーでアクセスが拒否された場合、Kafka AclAuthorizer に権限を委譲します。デフォルトは false です。
    5
    (任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
    6
    (任意設定): 指定の スーパーユーザー
    7
    (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
    8
    (任意設定): 連続する付与 (Grants) 更新実行の間隔。これは、アクティブなセッションが Red Hat Single Sign-On でユーザーのパーミッション変更を検出する最大時間です。デフォルト値は 60 です。
    9
    (任意設定): アクティブなセッションの付与 (Grants) の更新 (並行して) に使用するスレッドの数。デフォルト値は 5 です。
    10
    (オプション): Red Hat Single Sign-On トークンエンドポイントへの接続時のタイムアウト(秒単位)。デフォルト値は 60 です。
    11
    (オプション): Red Hat Single Sign-On トークンエンドポイントへの接続時の読み取りタイムアウト(秒単位)。デフォルト値は 60 です。
  6. エディターを保存して終了し、ローリングアップデートの完了を待ちます。
  7. 更新をログで確認するか、または Pod 状態の遷移を監視して確認します。

    oc logs -f ${POD_NAME} -c kafka
    oc get pod -w

    ローリングアップデートによって、ブローカーが OAuth 2.0 承認を使用するように設定されます。

  8. クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定したパーミッションを検証し、必要なアクセス権限があり、付与されるべきでないアクセス権限がないことを確認します。

5.5.3. Red Hat Single Sign-On の Authorization Services でのポリシーおよびパーミッションの管理

本セクションでは、Red Hat Single Sign-On Authorization Services および Kafka によって使用される承認モデルについて説明し、各モデルの重要な概念を定義します。

Kafka にアクセスするためのパーミッションを付与するには、Red Hat Single Sign-On で OAuth クライアント仕様を作成して、Red Hat Single Sign-On Authorization Services オブジェクトを Kafka リソースにマップできます。Kafka パーミッションは、Red Hat Single Sign-On Authorization Services ルールを使用して、ユーザーアカウントまたはサービスアカウントに付与されます。

トピックの作成や一覧表示など、一般的な Kafka 操作に必要なさまざまなユーザーパーミッションのを紹介します。

5.5.3.1. Kafka および Red Hat Single Sign-On 承認モデルの概要

Kafka および Red Hat Single Sign-On Authorization Services は、異なる承認モデルを使用します。

Kafka 承認モデル

Kafka の承認モデルはリソース型を使用します。Kafka クライアントがブローカーでアクションを実行すると、ブローカーは設定済みの KeycloakRBACAuthorizer を使用して、アクションおよびリソースタイプを基にしてクライアントのパーミッションをチェックします。

Kafka は、アクセスを制御するために 5 つのリソースタイプを使用します。TopicGroupClusterTransactionalId、および DelegationToken。各リソースタイプには、利用可能なパーミッションセットがあります。

トピック

  • 作成
  • Write
  • 読み取り
  • Delete
  • Describe
  • DescribeConfigs
  • Alter
  • AlterConfigs

グループ

  • 読み取り
  • Describe
  • Delete

クラスター

  • 作成
  • Describe
  • Alter
  • DescribeConfigs
  • AlterConfigs
  • IdempotentWrite
  • ClusterAction

TransactionalId

  • Describe
  • Write

DelegationToken

  • Describe
Red Hat Single Sign-On の Authorization Services モデル

Red Hat Single Sign-On の Authorization Services には、パーミッションを定義および付与するための 4 つの概念があります。これらは リソース承認スコープポリシー、および パーミッション です。

リソース
リソースは、リソースを許可されたアクションと一致するために使用されるリソース定義のセットです。リソースは、個別のトピックであったり、名前が同じプレフィックスで始まるすべてのトピックであったりします。リソース定義は、利用可能な承認スコープのセットに関連付けられます。これは、リソースで利用可能なすべてのアクションのセットを表します。多くの場合、これらのアクションのサブセットのみが実際に許可されます。
承認スコープ
承認スコープは、特定のリソース定義で利用可能なすべてのアクションのセットです。新規リソースを定義するとき、すべてのスコープのセットからスコープを追加します。
ポリシー

ポリシーは、アカウントのリストと照合するための基準を使用する承認ルールです。ポリシーは以下と一致できます。

  • クライアント ID またはロールに基づくサービスアカウント
  • ユーザー名、グループ、またはロールに基づくユーザーアカウント
パーミッション
パーミッションは、特定のリソース定義の承認スコープのサブセットをユーザーのセットに付与します。

関連情報

5.5.3.2. Red Hat Single Sign-On Authorization Services の Kafka 承認モデルへのマッピング

Kafka 承認モデルは、Kafka へのアクセスを制御する Red Hat Single Sign-On ロールおよびリソースを定義するベースとして使用されます。

ユーザーアカウントまたはサービスアカウントに Kafka パーミッションを付与するには、まず Kafka ブローカーの Red Hat Single Sign-On に OAuth クライアント仕様を作成します。次に、クライアントに Red Hat Single Sign-On の Authorization Services ルールを指定します。通常、ブローカーを表す OAuth クライアントのクライアント ID は kafka です。AMQ Streamsで提供されている設定ファイルの例では、OAuthのクライアントIDとしてkafkaを使用しています。

注記

複数の Kafka クラスターがある場合は、それらすべてに単一の OAuth クライアント(kafka)を使用できます。これにより、承認ルールを定義および管理するための単一の統合されたスペースが提供されます。ただし、異なる OAuth クライアント ID(例 my-cluster-kafka または cluster-dev-kafka)を使用し、各クライアント設定内の各クラスターの承認ルールを定義することもできます。

Kafka クライアント 定義では、Red Hat Single Sign-On 管理コンソールで Authorization Enabled オプションが有効になっている必要があります。

すべてのパーミッションは、kafka クライアントのスコープ内に存在します。異なる OAuth クライアント ID で異なる Kafka クラスターを設定した場合、同じ Red Hat Single Sign-On レルムの一部であっても、それぞれに個別のパーミッションセットが必要です。

Kafka クライアントが OAUTHBEARER 認証を使用する場合、Red Hat Single Sign-On オーソライザー(KeycloakRBACAuthorizer) は現在のセッションのアクセストークンを使用して、Red Hat Single Sign-On サーバーからグラントのリストを取得します。許可を取得するために、オーソライザーは Red Hat Single Sign-On の Authorization Services ポリシーおよびパーミッションを評価します。

Kafka パーミッションの承認スコープ

通常、Red Hat Single Sign-On 初期設定では、承認スコープをアップロードして、各 Kafka リソースタイプで実行できるすべての可能なアクションのリストを作成します。この手順は、パーミッションを定義する前に 1 度のみ実行されます。承認スコープをアップロードする代わりに、手動で追加できます。

承認スコープには、リソースタイプに関係なく、可能なすべての Kafka パーミッションが含まれる必要があります。

  • 作成
  • Write
  • 読み取り
  • Delete
  • Describe
  • Alter
  • DescribeConfig
  • AlterConfig
  • ClusterAction
  • IdempotentWrite
注記

パーミッションが必要ない場合(例: IdempotentWrite)、承認スコープの一覧から省略できます。ただし、そのパーミッションは Kafka リソースをターゲットにすることはできません。

パーミッションチェックのリソースパターン

リソースパターンは、パーミッションチェックの実行時にターゲットリソースに対するパターンの照合に使用されます。一般的なパターン形式は RESOURCE-TYPE:PATTERN-NAME です。

リソースタイプは Kafka 承認モデルをミラーリングします。このパターンでは、次の 2 つの一致オプションが可能です。

  • 完全一致(パターンが * で終了しない場合)
  • プレフィックス一致(パターンが * で終了する)

リソースのパターン例

Topic:my-topic
Topic:orders-*
Group:orders-*
Cluster:*

さらに、一般的なパターンフォーマットは、kafka-cluster:CLUSTER-NAMEの前にコンマを付けることができ、CLUSTER-NAMEはKafkaカスタムリソースのmetadata.nameを参照します。

クラスタープレフィックスが付けられたリソースのパターン例

kafka-cluster:my-cluster,Topic:*
kafka-cluster:*,Group:b_*

kafka-cluster の接頭辞がない場合は、kafka-cluster:* とみなします。

リソースを定義するときに、リソースに関連する可能な承認スコープのリストを関連付けることができます。ターゲットリソースタイプに妥当なアクションを設定します。

任意の承認スコープを任意のリソースに追加できますが、リソースタイプでサポートされるスコープのみがアクセス制御の対象として考慮されます。

アクセスパーミッションを適用するポリシー

ポリシーは、1 つ以上のユーザーアカウントまたはサービスアカウントにパーミッションをターゲットにするために使用されます。以下がターゲットの対象になります。

  • 特定のユーザーまたはサービスアカウント
  • レルムロールまたはクライアントロール
  • ユーザーグループ
  • クライアント IP アドレスに一致する JavaScript ルール

ポリシーには一意の名前が割り当てられ、複数のリソースに対して複数の対象パーミッションを指定するために再使用できます。

アクセスを付与するためのパーミッション

詳細なパーミッションを使用して、ユーザーへのアクセスを付与するポリシー、リソース、および承認スコープをまとめます。

各パーミッションの名前によって、どのユーザーにどのパーミッションが付与されるかが明確に定義される必要があります。例えば、Dev Team B は x で始まるトピックから読むことができます

関連情報

5.5.3.3. Kafka 操作に必要なパーミッションの例

以下の例は、Kafka で一般的な操作を実行するために必要なユーザーパーミッションを示しています。

トピックを作成します

トピックを作成するには、特定のトピック、または Cluster:kafka-cluster に対して Create パーミッションが必要です。

bin/kafka-topics.sh --create --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

トピックの一覧表示

指定のトピックでユーザーに Describe パーミッションがある場合には、トピックが一覧表示されます。

bin/kafka-topics.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

トピックの詳細の表示

トピックの詳細を表示するには、トピックに対して Describe および DescribeConfigs の権限が必要です。

bin/kafka-topics.sh --describe --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

トピックへのメッセージの生成

トピックへのメッセージを作成するには、トピックに対する DescribeWrite の権限が必要です。

トピックが作成されておらず、トピックの自動生成が有効になっている場合は、トピックを作成するパーミッションが必要になります。

bin/kafka-console-producer.sh  --topic my-topic \
  --broker-list my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties

トピックからのメッセージの消費

トピックからのメッセージを消費するためには、トピックに DescribeRead のパーミッションが必要です。通常、トピックからの消費は、コンシューマグループにコンシューマオフセットを格納することに依存しており、これにはコンシューマグループに対する追加の Describe および Read 権限が必要です。

マッチングには2つの resources が必要です。以下はその例です。

Topic:my-topic
Group:my-group-*
bin/kafka-console-consumer.sh --topic my-topic --group my-group-1 --from-beginning \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --consumer.config /tmp/config.properties

べき等プロデューサーを使用したトピックへのメッセージの生成

トピックへの生成のためのパーミッションと同様に、追加の IdempotentWrite パーミッションが Cluster リソースに必要です。

マッチングには2つの resources が必要です。以下はその例です。

Topic:my-topic
Cluster:kafka-cluster
bin/kafka-console-producer.sh  --topic my-topic \
  --broker-list my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties --producer-property enable.idempotence=true --request-required-acks -1

コンシューマーグループのリスト

コンシューマーグループの一覧表示時に、ユーザーが Describe 権限を持っているグループのみが返されます。また、ユーザーが Cluster:kafka-cluster に対して Describe パーミッションを持っている場合は、すべてのコンシューマーグループが返されます。

bin/kafka-consumer-groups.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

コンシューマーグループの詳細の表示

コンシューマグループの詳細を表示するには、グループとグループに関連するトピックに対して Describe 権限が必要です。

bin/kafka-consumer-groups.sh --describe --group my-group-1 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

トピック設定の変更

トピックの構成を変更するには、トピックに DescribeAlter の権限が必要です。

bin/kafka-topics.sh --alter --topic my-topic --partitions 2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

Kafka ブローカー設定の表示

kafka-configs.sh を使ってブローカーの設定を取得するためには、Cluster:kafka-clusterDescribeConfigs パーミッションが必要です。

bin/kafka-configs.sh --entity-type brokers --entity-name 0 --describe --all \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

Kafka ブローカー設定の変更

Kafkaブローカーの構成を変更するには、Cluster:kafka-clusterDescribeConfigs および AlterConfigs パーミッションが必要です。

bin/kafka-configs --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

トピックを削除します

トピックを削除するには、トピックにDescribeDelete の権限が必要です。

bin/kafka-topics.sh --delete --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

リードパーティションの選択

トピックパーティションのリーダー選択を実行するには、Cluster:kafka-clusterAlter パーミッションが必要です。

bin/kafka-leader-election.sh --topic my-topic --partition 0 --election-type PREFERRED  /
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --admin.config /tmp/config.properties

パーティションの再割り当て

パーティション再割り当てファイルを生成するためには、関係するトピックに対して Describe 権限が必要です。

bin/kafka-reassign-partitions.sh --topics-to-move-json-file /tmp/topics-to-move.json --broker-list "0,1" --generate \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties > /tmp/partition-reassignment.json

パーティションの再割り当てを実行するには、Cluster:kafka-cluster に対して DescribeAlter のパーミッションが必要です。また、関係するトピックには、Describeのパーミッションが必要です。

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --execute \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties

パーティションの再割り当てを確認するには、Cluster:kafka-clusterおよび関連する各トピックに対してDescribeおよびAlterConfigsのパーミッションが必要です。

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --verify \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties

5.5.4. Red Hat Single Sign-On の Authorization Services の試行

この例では、Red Hat Single Sign-On Authorization Services をkeycloak認証で使用する方法を説明します。Red Hat Single Sign-On の Authorization Services を使用して、Kafka クライアントにアクセス制限を強制します。Red Hat Single Sign-On の Authorization Services では、承認スコープ、ポリシー、およびパーミッションを使用してアクセス制御をリソースに定義および適用します。

Red Hat Single Sign-On の Authorization Services REST エンドポイントは、認証されたユーザーのリソースに付与されたパーミッションの一覧を提供します。許可 (パーミッション) のリストは、Kafka クライアントによって認証されたセッションが確立された後に最初のアクションとして Red Hat Single Sign-On サーバーから取得されます。付与の変更が検出されるように、バックグラウンドで一覧が更新されます。付与は、各ユーザーセッションが迅速な承認決定を提供するために、Kafka ブローカーにてローカルでキャッシュおよび適用されます。

AMQ Streams では 、設定ファイルのサンプルが含まれています。これには、Red Hat Single Sign-On を設定するための以下のサンプルファイルが含まれます。

kafka-ephemeral-oauth-single-keycloak-authz.yaml
Red Hat Single Sign-On を使用して OAuth 2.0 トークンベースの承認に設定された Kafka カスタムリソースの例。カスタムリソースを使用して、keycloak 承認およびトークンベースの oauth 認証を使用する Kafka クラスターをデプロイできます。
kafka-authz-realm.json
サンプルグループ、ユーザー、ロール、およびクライアントで設定された Red Hat Single Sign-On レルムの例。レルムを Red Hat Single Sign-On インスタンスにインポートし、Kafka にアクセスするための詳細なパーミッションを設定できます。

Red Hat Single Sign-On で例を試す場合は、これらのファイルを使用して、本セクションの順序で説明したタスクを実行します。

認証

トークンベースの oauth 認証を設定する場合、jwksEndpointUri をローカル JWT 検証の URI として指定します。keycloak 承認を設定するとき、a tokenEndpointUri を Red Hat Single Sign-On トークンエンドポイントの URI として指定します。両方の URI のホスト名は同じである必要があります。

グループまたはロールポリシーを使用した対象パーミッション

Red Hat Single Sign-On では、サービスアカウントが有効になっている機密性の高いクライアントを、クライアント ID とシークレットを使用して、独自の名前のサーバーに対して認証できます。これは、通常、特定ユーザーのエージェント (Web サイトなど) としてではなく、独自の名前で動作するマイクロサービスに便利です。サービスアカウントには、通常のユーザーと同様にロールを割り当てることができます。ただし、グループを割り当てることはできません。そのため、サービスアカウントを使用してマイクロサービスへのパーミッションをターゲットにする場合は、グループポリシーを使用できないため、代わりにロールポリシーを使用する必要があります。逆に、ユーザー名およびパスワードを使用した認証が必要な通常のユーザーアカウントにのみ特定のパーミッションを制限する場合は、ロールポリシーではなく、グループポリシーを使用すると、副次的に実現することができます。これは、ClusterManager で始まるパーミッションの例で使用されるものです。通常、クラスター管理の実行は CLI ツールを使用して対話的に行われます。結果的に生成されるアクセストークンを使用して Kafka ブローカーに対して認証を行う前に、ユーザーのログインを要求することは妥当です。この場合、アクセストークンはクライアントアプリケーションではなく、特定のユーザーを表します。

5.5.4.1. Red Hat Single Sign-On 管理コンソールへのアクセス

Red Hat Single Sign-On を設定してから、管理コンソールに接続し、事前設定されたレルムを追加します。kafka-authz-realm.json ファイルのサンプルを使用して、レルムをインポートします。管理コンソールのレルムに定義された承認ルールを確認できます。このルールは、Red Hat Single Sign-On レルムの例を使用するよう設定された Kafka クラスターのリソースへのアクセスを許可します。

前提条件

  • 実行中の OpenShift クラスター。
  • 事前設定されたレルムが含まれる AMQ Streams の examples/security/keycloak-authorization/kafka-authz-realm.json ファイル。

手順

  1. Red Hat Single Sign-On ドキュメントの「Server Installation and Configuration」の説明にしたがって、Red Hat Single Sign-On Operator を使用して Red Hat Single Sign-On サーバーをインストールします。
  2. Red Hat Single Sign-On インスタンスが実行されるまで待ちます。
  3. 管理コンソールにアクセスできるように外部ホスト名を取得します。

    NS=sso
    oc get ingress keycloak -n $NS

    この例では、Red Hat Single Sign-On サーバーが sso namespace で実行されていることを前提としています。

  4. admin ユーザーのパスワードを取得します。

    oc get -n $NS pod keycloak-0 -o yaml | less

    パスワードはシークレットとして保存されるため、Red Hat Single Sign-On インスタンスの設定 YAML ファイルを取得して、シークレット名(secretKeyRef.name)を特定します。

  5. シークレットの名前を使用して、クリアテキストのパスワードを取得します。

    SECRET_NAME=credential-keycloak
    oc get -n $NS secret $SECRET_NAME -o yaml | grep PASSWORD | awk '{print $2}' | base64 -D

    この例では、シークレットの名前が credential-keycloak であることを前提としています。

  6. ユーザー名 admin と取得したパスワードを使用して、管理コンソールにログインします。

    https://HOSTNAME を使用して OpenShift Ingress にアクセスします。

    管理コンソールを使用して、サンプルレルムを Red Hat Single Sign-On にアップロードできるようになりました。

  7. Add Realm をクリックして、サンプルレルムをインポートします。
  8. examples/security/keycloak-authorization/kafka-authz-realm.json ファイルを追加してから Create をクリックします。

    これで、管理コンソールの現在のレルムとして kafka-authz が含まれるようになりました。

    デフォルトビューには、Master レルムが表示されます。

  9. Red Hat Single Sign-On 管理コンソールで Clients > kafka > Authorization > Settings の順に移動し、Decision StrategyAffirmative に設定されていることを確認します。

    肯定的な (Affirmative) ポリシーとは、クライアントが Kafka クラスターにアクセスするためには少なくとも 1 つのポリシーが満たされている必要があることを意味します。

  10. Red Hat Single Sign-On 管理コンソールで、GroupsUsersRoles、および Clients と移動して、レルム設定を表示します。

    グループ
    Groups は、ユーザーグループの作成やユーザー権限の設定に使用します。グループは、名前が割り当てられたユーザーのセットです。地域、組織、または部門単位に区分するために使用されます。グループは LDAP アイデンティティープロバイダーにリンクできます。Kafka リソースにパーミッションを付与するなど、カスタム LDAP サーバー管理ユーザーインターフェースを使用して、ユーザーをグループのメンバーにすることができます。
    ユーザー
    Users は、ユーザーを作成するために使用されます。この例では、alicebob が定義されています。aliceClusterManager グループのメンバーであり、bobClusterManager-my-cluster グループのメンバーです。ユーザーは LDAP アイデンティティープロバイダーに保存できます。
    ロール
    Rolesは、ユーザーやクライアントが特定の権限を持っていることを示すものです。ロールはグループに似た概念です。通常ロールは、組織ロールでユーザーを タグ付け するために使用され、必要なパーミッションを持ちます。ロールは LDAP アイデンティティープロバイダーに保存できません。LDAP が必須である場合は、代わりにグループを使用し、Red Hat Single Sign-On ロールをグループに追加して、ユーザーにグループを割り当てるときに対応するロールも取得するようにします。
    Clients

    Clientsは特定の構成を持つことができます。この例では、kafkakafka-cliteam-a-clientteam-b-clientの各クライアントが設定されています。

    • kafkaクライアントは、Kafkaブローカーがアクセストークンの検証に必要なOAuth 2.0 通信を行うために使用されます。このクライアントには、Kafka ブローカーで承認を実行するために使用される承認サービスリソース定義、ポリシー、および承認スコープも含まれます。認証設定はkafkaクライアントの Authorization タブで定義され、Settings タブでAuthorization Enabled をオンにすると表示されます。
    • kafka-cli クライアントは、アクセストークンまたは更新トークンを取得するためにユーザー名とパスワードを使用して認証するときに Kafka コマンドラインツールによって使用されるパブリッククライアントです。
    • team-a-client および team-b-client クライアントは、特定の Kafka トピックに部分的にアクセスできるサービスを表す機密クライアントです。
  11. Red Hat Single Sign-On 管理コンソールで、Authorization > Permissions の順に移動し、レルムに定義されたリソースおよびポリシーを使用する付与されたパーミッションを確認します。

    たとえば、kafka クライアントには以下のパーミッションがあります。

    Dev Team A can write to topics that start with x_ on any cluster
    Dev Team B can read from topics that start with x_ on any cluster
    Dev Team B can update consumer group offsets that start with x_ on any cluster
    ClusterManager of my-cluster Group has full access to cluster config on my-cluster
    ClusterManager of my-cluster Group has full access to consumer groups on my-cluster
    ClusterManager of my-cluster Group has full access to topics on my-cluster
    Dev Team A
    Dev チーム A レルムロールは、任意のクラスターで x_ で始まるトピックに書き込みできます。これは、Topic:x_*というリソース、DescribeWriteのスコープ、そしてDev Team Aのポリシーを組み合わせたものです。Dev Team Aポリシーは、Dev Team Aというレルムロールを持つすべてのユーザーにマッチします。
    Dev Team B
    Dev チーム B レルムロールは、任意のクラスターで x_ で始まるトピックから読み取ることができます。これは、Topic:x_*、 Group:x_*のリソース、DescribeReadのスコープ、およびDev Team Bのポリシーを組み合わせたものです。Dev Team Bポリシーは、Dev Team Bというレルムロールを持つすべてのユーザーにマッチします。一致するユーザーおよびクライアントはトピックから読み取りでき、名前が x_ で始まるトピックおよびコンシューマーグループの消費されたオフセットを更新できます。

5.5.4.2. Red Hat Single Sign-On 承認をでの Kafka クラスターのデプロイメント

Red Hat Single Sign-On サーバーに接続するように設定された Kafka クラスターをデプロイします。サンプルのkafka-ephemeral-oauth-single-keycloak-authz.yamlファイルを使用して、KafkaカスタムリソースとしてKafkaクラスタを展開します。この例では、keycloak 承認と oauth 認証を使用して単一ノードの Kafka クラスターをデプロイします。

前提条件

  • Red Hat Single Sign-On 承認サーバーが OpenShift クラスターにデプロイされ、サンプルレルムでロードされている。
  • Cluster Operator が OpenShift クラスターにデプロイされている。
  • AMQ Streams の examples/security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml カスタムリソース。

手順

  1. デプロイした Red Hat Single Sign-On インスタンスのホスト名を使用して、Kafka ブローカーのトラストストア証明書を準備し、Red Hat Single Sign-On サーバーと通信します。

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.crt

    OpenShift Ingress はセキュアな (HTTPS) 接続の確立に使用されるため、証明書が必要です。

  2. シークレットとして OpenShift に証明書をデプロイします。

    oc create secret generic oauth-server-cert --from-file=/tmp/sso.crt -n $NS
  3. ホスト名を環境変数として設定します。

    SSO_HOST=SSO-HOSTNAME
  4. サンプル Kafka クラスターを作成およびデプロイします。

    cat examples/security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml | sed -E 's#\${SSO_HOST}'"#$SSO_HOST#" | oc create -n $NS -f -

5.5.4.3. CLI Kafka クライアントセッションの TLS 接続の準備

対話型 CLI セッション用の新規 Pod を作成します。TLS 接続用の Red Hat Single Sign-On 証明書を使用してトラストストアを設定します。トラストストアは、Red Hat Single Sign-On および Kafka ブローカーに接続します。

前提条件

  • Red Hat Single Sign-On 承認サーバーが OpenShift クラスターにデプロイされ、サンプルレルムでロードされている。

    Red Hat Single Sign-On 管理コンソールで、クライアントに割り当てられたロールが Clients > Service Account Roles に表示されることを確認します。

  • Red Hat Single Sign-On に接続するように設定された Kafka クラスターが OpenShift クラスターにデプロイされている。

手順

  1. AMQ Streams の Kafka イメージを使用してインタラクティブな Pod コンテナーを新たに実行し、稼働中の Kafka ブローカーに接続します。

    NS=sso
    oc run -ti --restart=Never --image=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 kafka-cli -n $NS -- /bin/sh
    注記

    イメージのダウンロードの待機中に oc がタイムアウトする場合、その後の試行によって an AlreadyExists エラーが発生することがあります。

  2. Pod コンテナーにアタッチします。

    oc attach -ti kafka-cli -n $NS
  3. Red Hat Single Sign-On インスタンスのホスト名を使用して、TLS を使用してクライアントコネクションの証明書を準備します。

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.crt
  4. Kafka ブローカーへの TLS 接続のトラストストアを作成します。

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias sso -storepass $STOREPASS -import -file /tmp/sso.crt -noprompt
  5. Kafka ブートストラップアドレスを Kafka ブローカーのホスト名および tls リスナーポート(9093)のホスト名として使用し、Kafka ブローカーの証明書を準備します。

    KAFKA_HOST_PORT=my-cluster-kafka-bootstrap:9093
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $KAFKA_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/my-cluster-kafka.crt
  6. Kafka ブローカーの証明書をトラストストアに追加します。

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias my-cluster-kafka -storepass $STOREPASS -import -file /tmp/my-cluster-kafka.crt -noprompt

    承認されたアクセスを確認するために、セッションを開いたままにします。

5.5.4.4. CLI Kafka クライアントセッションを使用した Kafka への承認されたアクセスの確認

対話型 CLI セッションを使用して、Red Hat Single Sign-On レルムを通じて適用される承認ルールを確認します。Kafka のサンプルプロデューサーおよびコンシューマークライアントを使用してチェックを適用し、異なるレベルのアクセスを持つユーザーおよびサービスアカウントでトピックを作成します。

team-a-client クライアントおよび team-b-client クライアントを使用して、承認ルールを確認します。alice admin ユーザーを使用して、Kafka で追加の管理タスクを実行します。

この例で使用される AMQ Streams Kafka イメージには、Kafka プロデューサーおよびコンシューマーバイナリーが含まれます。

前提条件

クライアントおよび管理ユーザーの設定

  1. team-a-client クライアントの認証プロパティーで Kafka 設定ファイルを準備します。

    SSO_HOST=SSO-HOSTNAME
    
    cat > /tmp/team-a-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-a-client" \
      oauth.client.secret="team-a-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF

    SASL OAUTHBEARER メカニズムが使用されます。このメカニズムにはクライアント ID とクライアントシークレットが必要です。これは、クライアントが最初に Red Hat Single Sign-On サーバーに接続してアクセストークンを取得することを意味します。その後、クライアントは Kafka ブローカーに接続し、アクセストークンを使用して認証します。

  2. team-b-client クライアントの認証プロパティーで Kafka 設定ファイルを準備します。

    cat > /tmp/team-b-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-b-client" \
      oauth.client.secret="team-b-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF
  3. curl を使用して管理者ユーザー alice を認証し、パスワード付与認証を実行して更新トークンを取得します。

    USERNAME=alice
    PASSWORD=alice-password
    
    GRANT_RESPONSE=$(curl -X POST "https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" -H 'Content-Type: application/x-www-form-urlencoded' -d "grant_type=password&username=$USERNAME&password=$PASSWORD&client_id=kafka-cli&scope=offline_access" -s -k)
    
    REFRESH_TOKEN=$(echo $GRANT_RESPONSE | awk -F "refresh_token\":\"" '{printf $2}' | awk -F "\"" '{printf $1}')

    更新トークンは、有効期間がなく、期限切れにならないオフライントークンです。

  4. admin ユーザー alice の認証プロパティーで Kafka 設定ファイルを準備します。

    cat > /tmp/alice.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.refresh.token="$REFRESH_TOKEN" \
      oauth.client.id="kafka-cli" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF

    kafka-cli パブリッククライアントは、sasl.jaas .configoauth.client. id に使用されます。これはパブリッククライアントであるため、シークレットは必要ありません。クライアントは直前の手順で認証された更新トークンで認証されます。更新トークンは背後でアクセストークンを要求します。これは、認証のために Kafka ブローカーに送信されます。

承認されたアクセスでのメッセージの生成

team-a-clientの設定を使って、a_x_で始まるトピックへのメッセージを作成できるかどうかを確認します。

  1. トピックmy-topicに書き込みます。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic my-topic \
      --producer.config=/tmp/team-a-client.properties
    First message

    以下のリクエストは、Not authorized to access topics: [my-topic] エラーを返します。

    team-a-clientDev Team Aロールを持っており、a_で始まるトピックに対してサポートされているすべてのアクションを実行する権限を与えられていますが、x_で始まるトピックへの書き込みのみ可能です。my-topic という名前のトピックは、これらのルールのいずれにも一致しません。

  2. トピックa_messagesに書き込む。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-a-client.properties
    First message
    Second message

    メッセージは Kafka に正常に生成されます。

  3. CTRL+C を押して CLI アプリケーションを終了します。
  4. リクエストについて、Kafka コンテナーログで Authorization GRANTED のデバッグログを確認します。

    oc logs my-cluster-kafka-0 -f -n $NS

承認されたアクセスでのメッセージの消費

team-a-client 設定を使用して、トピック a_messages からメッセージを消費します。

  1. トピック a_messages からメッセージをフェッチします。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties

    team-a-clientDev Team A ロールは、名前が a_ で始まるコンシューマーグループのみにアクセスできるため、リクエストはエラーを返します。

  2. team-a-client プロパティーを更新し、使用が許可されているカスタムコンシューマーグループを指定します。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_1

    コンシューマーは a_messages トピックからすべてのメッセージを受信します。

承認されたアクセスでの Kafka の管理

team-a-client はクラスターレベルのアクセスのないアカウントですが、一部の管理操作と使用することができます。

  1. トピックを一覧表示します。

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list

    a_messages トピックが返されます。

  2. コンシューマーグループを一覧表示します。

    bin/kafka-consumer-groups.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list

    a_consumer_group_1 コンシューマーグループが返されます。

    クラスター設定の詳細を取得します。

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties \
      --entity-type brokers --describe --entity-default

    操作には team-a-client にないクラスターレベルのパーミッションが必要なため、リクエストはエラーを返します。

異なるパーミッションを持つクライアントの使用

team-b-client 設定を使用して、b_ で始まるトピックにメッセージを生成します。

  1. トピックa_messagesに書き込む。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1

    以下のリクエストは、Not authorized to access topics: [a_messages] エラーを返します。

  2. トピックb_messagesに書き込む。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic b_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1
    Message 2
    Message 3

    メッセージは Kafka に正常に生成されます。

  3. トピックx_messagesに書き込む。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1

    Not authorized to access topics: [x_messages] エラーが返され、team-b-client はトピック x_messages からのみ読み取りできます。

  4. team-a-client を使用してトピック x_messages に書き込みます。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1

    このリクエストは、Not authorized to access topics: [x_messages] エラーを返します。team-a-clientx_messages トピックに書き込みできますが、トピックが存在しない場合に作成するパーミッションがありません。team-a-clientx_messages トピックに書き込みできるようにするには、管理者 power user はパーティションやレプリカの数などの適切な設定で作成する必要があります。

承認された管理ユーザーでの Kafka の管理

管理ユーザー alice を使用して Kafka を管理します。alice には Kafka クラスターの全機能を管理する完全なアクセス権限があります。

  1. aliceとしてx_messagesトピックを作成します。

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --topic x_messages --create --replication-factor 1 --partitions 1

    トピックが正常に作成されました。

  2. aliceとしてすべてのトピックを一覧表示します。

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-b-client.properties --list

    管理者ユーザーのaliceはすべてのトピックを一覧表示できますが、team-a-clientteam-b-clientは自分がアクセスできるトピックのみを一覧表示できます。

    Dev Team AロールとDev Team Bロールは、どちらもx_ で始まるトピックに対するDescribe権限を持っていますが、他のチームのトピックに対するDescribe権限を持っていないため、他のチームのトピックを見ることができません。

  3. team-a-client を使用して、x_messages トピックにメッセージを生成します。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1
    Message 2
    Message 3

    alicex_messages トピックを作成すると、メッセージが正常に Kafka に生成されます。

  4. team-b-client を使って、x_messages トピックにメッセージを生成します。

    bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 4
    Message 5

    このリクエストは、Not authorized to access topics: [x_messages] エラーを返します。

  5. team-b-clientを使って、x_messagesトピックからメッセージを消費します。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-b-client.properties --group x_consumer_group_b

    コンシューマーは、x_messagesトピックからすべてのメッセージを受け取ります。

  6. team-a-clientを使って、x_messagesトピックからメッセージを消費します。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group x_consumer_group_a

    このリクエストは、Not authorized to access topics: [x_messages] エラーを返します。

  7. team-a-clientを使って、a_で始まるコンシューマーグループからのメッセージを消費します。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_a

    このリクエストは、Not authorized to access topics: [x_messages] エラーを返します。

    Dev Team Aには、x_で始まるトピックのRead権限がありません。

  8. aliceを使って、x_messagesトピックへのメッセージを生成します。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/alice.properties

    メッセージは Kafka に正常に生成されます。

    alice は、すべてのトピックに対して読み取りまたは書き込みを行うことができます。

  9. alice を使用してクラスター設定を読み取ります。

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --entity-type brokers --describe --entity-default

    この例のクラスター設定は空です。

第6章 Strimzi Operator の使用

Strimzi の operator を使用して Kafka クラスターと Kafka トピックおよびユーザーを管理します。

6.1. Cluster Operator の使用

Cluster Operator は Kafka クラスターや他の Kafka コンポーネントをデプロイするために使用されます。

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator のデプロイ」を参照してください。

6.1.1. Cluster Operator の設定

Cluster Operator は、サポートされる環境変数を使用してロギング設定から設定できます。

環境変数は、Cluster Operator イメージのデプロイメンのコンテナー設定に関連します。image設定の詳細については、image を参照してください。

STRIMZI_NAMESPACE

Operator が操作する namespace のカンマ区切りのリスト。設定されていない場合や、空の文字列や * に設定された場合、Cluster Operator はすべての namespace で操作します。Cluster Operator デプロイメントでは OpenShift Downward API を使用して、これを Cluster Operator がデプロイされる namespace に自動設定することがあります。

Cluster Operator namespace の設定例

env:
  - name: STRIMZI_NAMESPACE
    valueFrom:
      fieldRef:
        fieldPath: metadata.namespace

STRIMZI_FULL_RECONCILIATION_INTERVAL_MS
任意設定、デフォルトは 120000 ミリ秒です。定期的な調整の間隔 (秒単位)。
STRIMZI_OPERATION_TIMEOUT_MS
任意設定、デフォルトは 300000 ミリ秒です。内部操作のタイムアウト (ミリ秒単位)。この値は、標準の OpenShift 操作の時間が通常よりも長いクラスターで (Docker イメージのダウンロードが遅い場合など) AMQ Streams を使用する場合に増やす必要があります。
STRIMZI_ZOOKEEPER_ADMIN_SESSION_TIMEOUT_MS
任意設定、デフォルトは 10000 ミリ秒です。

Cluster Operator の ZooKeeper 管理クライアントのセッションタイムアウト(ミリ秒単位)。タイムアウトの問題が原因で Cluster Operator からの ZooKeeper 要求が定期的に失敗する場合は、この値を大きくする必要があります。maxSessionTimeout 設定で ZooKeeper サーバー側に最大許容セッション時間が設定されます。デフォルトでは、このセッションの最大値は、tickTime (デフォルトは 2000)のデフォルト値の 20 倍、つまり 40000 ミリ秒です。タイムアウト時間を伸ばす必要がある場合は、maxSessionTimeout ZooKeeper サーバー設定値を変更する必要があります。

STRIMZI_OPERATIONS_THREAD_POOL_SIZE
任意設定で、デフォルトは 10 です。クラスターオペレーターによって実行されるさまざまな非同期およびブロッキング操作に使用されるワーカースレッドのプールサイズです。
STRIMZI_OPERATOR_NAMESPACE

AMQ Streams Cluster Operator が稼働している namespace の名前。この変数は手動で設定しないでください。OpenShift Downward API を使用します。

env:
  - name: STRIMZI_OPERATOR_NAMESPACE
    valueFrom:
      fieldRef:
        fieldPath: metadata.namespace
STRIMZI_OPERATOR_NAMESPACE_LABELS

オプション。AMQ Streams Cluster Operator が稼働している namespace のラベル。namespace ラベルは、ネットワークポリシーで namespace セレクターを設定するために使用されます。これにより、AMQ Streams Cluster Operator はこれらのラベルを持つ namespace からのオペランドのみにアクセスできます。設定されていない場合、ネットワークポリシーの namespace セレクターは、OpenShift クラスターのすべての namespace から AMQ Streams Cluster Operator にアクセスできるように設定されます。

env:
  - name: STRIMZI_OPERATOR_NAMESPACE_LABELS
    value: label1=value1,label2=value2
STRIMZI_LABELS_EXCLUSION_PATTERN

任意設定、デフォルトの正規表現パターンは ^app.kubernetes.io/(?!part-of).* です。メインのカスタムリソースからサブリソースへのラベル伝搬をフィルターするために使用される正規表現除外パターンを指定します。ラベル除外フィルターは、spec.kafka.template.pod.metadata.labels などのテンプレートセクションのラベルには適用されません。

env:
  - name: STRIMZI_LABELS_EXCLUSION_PATTERN
    value: "^key1.*"
STRIMZI_CUSTOM_{COMPONENT_NAME}_LABELS

オプション。{COMPONENT_NAME} カスタムリソースで作成されるすべての Pod に適用する 1 つ以上のカスタムラベル。Cluster Operator は、カスタムリソースの作成時か、または次の調整時に Pod にラベルを付けます。

以下のコンポーネントには、環境変数が存在します。

  • KAFKA
  • KAFKA_CONNECT
  • KAFKA_CONNECT_BUILD
  • ZOOKEEPER
  • ENTITY_OPERATOR
  • KAFKA_MIRROR_MAKER2
  • KAFKA_MIRROR_MAKER
  • CRUISE_CONTROL
  • KAFKA_BRIDGE
  • KAFKA_EXPORTER
STRIMZI_CUSTOM_RESOURCE_SELECTOR

オプション。Operator によって処理されるカスタムリソースのフィルタリングに使用されるラベルセレクターを指定します。Operator は、指定されたラベルが設定されているカスタムリソースでのみ動作します。これらのラベルのないリソースは Operator によって認識されません。ラベルセレクターは、KafkaKafkaConnectKafkaBridgeKafkaMirrorMaker、および KafkaMirrorMaker2 リソースに適用されます。KafkaRebalanceKafkaConnector リソースは、対応する Kafka および Kafka Connect クラスターに一致するラベルがある場合にのみ操作されます。

env:
  - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR
    value: label1=value1,label2=value2
STRIMZI_KAFKA_IMAGES
必須。Kafka バージョンから、そのバージョンの Kafka ブローカーが含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。(例: 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0)。これはKafka.spec.kafka.versionプロパティが指定されていて、KafkaリソースのKafka.spec.kafka.imageが指定されていない場合に使用されます。
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
オプションです。デフォルトは registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 です。Kafkaリソースのkafka-init-image としてイメージが指定されていない場合に、初期設定作業(ラックサポート)のためにブローカーの前に開始される init コンテナのデフォルトとして使用するイメージ名。
STRIMZI_KAFKA_CONNECT_IMAGES
必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。(例: 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0)。これは、KafkaConnect.spec.versionプロパティが指定され、KafkaConnect.spec.imageが指定されていない場合に使用されます。
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES
必須。Kafka バージョンから、そのバージョンの Kafka Mirror Maker が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。(例: 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0)。これは、KafkaMirrorMaker.spec.version プロパティーが指定されていても KafkaMirrorMaker.spec.image プロパティーが指定されていない場合に使用されます。
STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE
オプションです。デフォルトは registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 です。Kafka リソースのKafka.spec.entityOperator.topicOperator.image として指定されたイメージがない場合に、Topic Operator のデプロイ時にデフォルトとして使用するイメージ名。
STRIMZI_DEFAULT_USER_OPERATOR_IMAGE
オプションです。デフォルトは registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 です。KafkaリソースのKafka.spec.entityOperator.userOperator.imageにイメージが指定されていない場合に、ユーザーオペレーターをデプロイする際にデフォルトで使用するイメージ名です。
STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE
オプションです。デフォルトは registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 です。KafkaリソースのKafka.spec.entityOperator.tlsSidecar.imageにイメージが指定されていない場合に、Entity OperatorのTLSサポートを提供するサイドカーコンテナをデプロイする際にデフォルトで使用するイメージ名です。
STRIMZI_IMAGE_PULL_POLICY
オプション。AMQ Streams の Cluster Operator によって管理されるすべての Pod のコンテナーに適用される ImagePullPolicy。有効な値は AlwaysIfNotPresent、および Never です。指定のない場合、OpenShift のデフォルトが使用されます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。
STRIMZI_IMAGE_PULL_SECRETS
オプション。Secret 名のカンマ区切りのリスト。ここで参照されるシークレットには、コンテナーイメージがプルされるコンテナーレジストリーへのクレデンシャルが含まれます。シークレットは、Cluster Operator によって作成されるすべての PodsimagePullSecrets フィールドで使用されます。このリストを変更すると、Kafka、Kafka Connect、および Kafka MirrorMaker のすべてのクラスターのローリングアップデートが実行されます。
STRIMZI_KUBERNETES_VERSION

オプション。API サーバーから検出された OpenShift バージョン情報をオーバーライドします。

OpenShift バージョンオーバーライドの設定例

env:
  - name: STRIMZI_KUBERNETES_VERSION
    value: |
           major=1
           minor=16
           gitVersion=v1.16.2
           gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b
           gitTreeState=clean
           buildDate=2019-10-15T19:09:08Z
           goVersion=go1.12.10
           compiler=gc
           platform=linux/amd64

KUBERNETES_SERVICE_DNS_DOMAIN

オプション。デフォルトの OpenShift DNS サフィックスを上書きします。

デフォルトでは、OpenShfit クラスターで割り当てられるサービスに、デフォルトのサフィックス cluster.local を使用する DNS ドメイン名があります。

ブローカーが kafka-0 の場合の例は次のとおりです。

<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc.cluster.local

DNS ドメイン名は、ホスト名の検証に使用される Kafka ブローカー証明書に追加されます。

クラスターで異なる DNS サフィックスを使用している場合、Kafka ブローカーとの接続を確立するために、KUBERNETES_SERVICE_DNS_DOMAIN 環境変数をデフォルトから現在使用中の DNS サフィックスに変更します。

STRIMZI_CONNECT_BUILD_TIMEOUT_MS
任意設定、デフォルトは 300000 ミリ秒です。追加のコネクターで新しい Kafka Connect イメージをビルドする場合のタイムアウト (ミリ秒単位)。AMQ Streams を使用して多くのコネクターが含まれるコンテナーイメージをビルドしたり、低速なコンテナーレジストリーを使用する場合は、この値を大きくする必要があります。
STRIMZI_NETWORK_POLICY_GENERATION
任意設定、デフォルトは true です。AMQ Streams がネットワークポリシーリソースを生成するかどうかを制御します。ネットワークポリシーにより、Kafka コンポーネント間の接続が許可されます。

ネットワークポリシーの生成を無効にするには、この環境変数を false に設定します。たとえば、カスタムのネットワークポリシーを使用する場合は、これを行うことができます。カスタムネットワークポリシーを使用すると、コンポーネント間の接続をより詳細に制御できます。

STRIMZI_DNS_CACHE_TTL
任意設定で、デフォルトは 30 です。ローカル DNS リゾルバーで成功した名前のルックアップをキャッシュする秒数。負の値を指定すると、キャッシュの期限はありません。ゼロはキャッシュされないことを意味します。これは、長いキャッシュポリシーが適用されることが原因の接続エラーを回避するのに役立ちます。
STRIMZI_FEATURE_GATES
オプション。フィーチャーゲートで制御される機能を有効または無効にします。

6.1.1.1. ConfigMap による設定のロギング

Cluster Operator のロギングは、strimzi-cluster-operator ConfigMap によって設定されます。

ロギング設定が含まれる ConfigMap は、Cluster Operator のインストール時に作成されます。この ConfigMap は、install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml ファイルに記述されます。このConfigMapのデータフィールドlog4j2.propertiesを変更することで、Cluster Operatorのロギングを設定します。

ロギング設定を更新するには、050-ConfigMap-strimzi-cluster-operator.yaml ファイルを編集し、以下のコマンドを実行します。

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

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

oc edit configmap strimzi-cluster-operator

リロード間隔の頻度を変更するには、作成された ConfigMapmonitorInterval オプションで秒単位の時間を設定します。

クラスタオペレータのデプロイ時にConfigMapがない場合、デフォルトのロギング値が使用されます。

Cluster Operator のデプロイ後に ConfigMap が誤って削除される場合、最後に読み込まれたロギング設定が使用されます。新規のロギング設定を読み込むために新規 ConfigMap を作成します。

注記

ConfigMap から monitorInterval オプションを削除しないでください。

6.1.1.2. ネットワークポリシーによる Cluster Operator アクセスの制限

Cluster Operator は、管理するリソースと同じ namespace または別の namespace で実行できます。デフォルトでは、STRIMZI_OPERATOR_NAMESPACE環境変数は、OpenShift Downward APIを使用して、クラスターオペレーターがどのネームスペースで実行されているかを見つけるように構成されています。Cluster Operator がリソースと同じ namespace で実行されている場合は、ローカルアクセスのみが必要で、AMQ Sreams によって許可されます。

Cluster Operator が管理するリソースとは別の namespace で実行されている場合、ネットワークポリシーが設定されている場合を除き、OpenShift クラスターのすべての namespace は Cluster Operator へのアクセスが許可されます。オプションの STRIMZI_OPERATOR_NAMESPACE_LABELS 環境変数を使用して、namespace ラベルを使用して Cluster Operator のネットワークポリシーを確立します。namespace ラベルを追加すると、Cluster Operator へのアクセスは指定された namespace に限定されます。

Cluster Operator デプロイメントに設定されたネットワークポリシー

#...
env:
  # ...
  - name: STRIMZI_OPERATOR_NAMESPACE_LABELS
    value: label1=value1,label2=value2
  #...

6.1.1.3. 定期的な調整

Cluster Operator は OpenShift クラスターから受信する必要なクラスターリソースに関するすべての通知に対応しますが、Operator が実行されていない場合や、何らかの理由で通知が受信されない場合、必要なリソースは実行中の OpenShift クラスターの状態と同期しなくなります。

フェイルオーバーを適切に処理するために、Cluster Operator によって定期的な調整プロセスが実行され、必要なリソースすべてで一貫した状態になるように、必要なリソースの状態を現在のクラスターデプロイメントと比較できます。[STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 変数を使用して、定期的な調整の時間間隔を設定できます。

6.1.1.4. ロールベースアクセス制御 (RBAC) のプロビジョニング

クラスターオペレーターが機能するためには、OpenShiftクラスター内で、KafkaKafkaConnectなどのリソースや、ConfigMapsPodDeploymentsStatefulSetsServicesなどの管理されたリソースとやりとりする権限が必要です。このようなパーミッションは、OpenShift のロールベースアクセス制御 (RBAC) リソースに記述されます。

  • ServiceAccount
  • Role および ClusterRole
  • RoleBinding および ClusterRoleBinding

Cluster Operator は、ClusterRoleBinding を使用して独自の ServiceAccount で実行される他に、OpenShift リソースへのアクセスを必要とするコンポーネントの RBAC リソースを管理します。

また OpenShift には、ServiceAccount で動作するコンポーネントが、その ServiceAccount にはない他の ServiceAccounts の権限を付与しないようにするための特権昇格の保護機能も含まれています。Cluster Operator は、ClusterRoleBindings と、それが管理するリソースで必要な RoleBindings を作成できる必要があるため、Cluster Operator にも同じ権限が必要です。

6.1.1.5. 委譲された権限

Cluster Operator が必要な Kafka リソースのリソースをデプロイする場合、以下のように ServiceAccountsRoleBindings、および ClusterRoleBindings も作成します。

  • Kafka ブローカー Pod は、cluster-name-kafka という ServiceAccount を使用します。

    • ラック機能が使用されると、strimzi-cluster-name-kafka-init ClusterRoleBinding は、strimzi-kafka-broker と呼ばれる ClusterRole 経由で、クラスター内のノードへの ServiceAccount アクセスを付与するために使用されます。
    • ラック機能が使用されておらず、クラスターがノードポートを介して公開されていない場合、バインディングは作成されません。
  • ZooKeeper Pod では cluster-name-zookeeper という ServiceAccount が使用されます。
  • Entity Operator Pod では cluster-name-entity-operator という ServiceAccount が使用されます。

    • Topic Operator はステータス情報のある OpenShift イベントを生成するため、ServiceAccountstrimzi-entity-operator という ClusterRole にバインドされ、strimzi-entity-operator RoleBinding 経由でこのアクセス権限を付与します。
  • KafkaConnectリソースのPodは、cluster-name--cluster-connect という ServiceAccountを使用します。
  • KafkaMirrorMaker の Pod は、cluster-name-mirror-maker という ServiceAccount を使用します。
  • KafkaMirrorMaker2 の Pod は、cluster-name-mirrormaker2という ServiceAccount を使用します。
  • KafkaBridge の Pod は、cluster-name-bridge という ServiceAccount を使用します。

6.1.1.6. ServiceAccount

Cluster Operator は ServiceAccount を使用して最適に実行されます。

Cluster Operator の ServiceAccount の例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi

その後、Cluster Operator の Deployment で、これを spec.template.spec.serviceAccountName に指定する必要があります。

Cluster Operator の Deployment の部分的な例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
spec:
  replicas: 1
  selector:
    matchLabels:
      name: strimzi-cluster-operator
      strimzi.io/kind: cluster-operator
  template:
      # ...

12 行目で、strimzi-cluster-operator ServiceAccountserviceAccountName として指定されています。

6.1.1.7. ClusterRoles

Cluster Operator は、必要なリソースへのアクセス権限を付与する ClusterRole を使用して操作する必要があります。OpenShift クラスターの設定によっては、クラスター管理者が ClusterRoles を作成する必要があることがあります。

注記

クラスター管理者の権限は ClusterRoles の作成にのみ必要です。Cluster Operator はクラスター管理者アカウントで実行されません。

ClusterRoles は、 最小権限の原則に従い、Kafka、Kafka Connect、および ZooKeeper クラスターを操作するために Cluster Operator が必要とする権限のみが含まれます。最初に割り当てられた一連の権限により、Cluster Operator で StatefulSetsDeploymentsPods、および ConfigMaps などの OpenShift リソースを管理できます。

Cluster Operator は ClusterRoles を使用して、namespace スコープリソースのレベルおよびクラスタースコープリソースのレベルで権限を付与します。

Cluster Operator の namespaced リソースのある ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-cluster-operator-namespaced
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to access and manage rolebindings to grant Strimzi components cluster permissions
      - rolebindings
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to access and manage roles to grant the entity operator permissions
      - roles
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      # The cluster operator needs to access and delete pods, this is to allow it to monitor pod health and coordinate rolling updates
      - pods
      # The cluster operator needs to access and manage service accounts to grant Strimzi components cluster permissions
      - serviceaccounts
      # The cluster operator needs to access and manage config maps for Strimzi components configuration
      - configmaps
      # The cluster operator needs to access and manage services and endpoints to expose Strimzi components to network traffic
      - services
      - endpoints
      # The cluster operator needs to access and manage secrets to handle credentials
      - secrets
      # The cluster operator needs to access and manage persistent volume claims to bind them to Strimzi components for persistent data
      - persistentvolumeclaims
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "kafka.strimzi.io"
    resources:
      # The cluster operator runs the KafkaAssemblyOperator, which needs to access and manage Kafka resources
      - kafkas
      - kafkas/status
      # The cluster operator runs the KafkaConnectAssemblyOperator, which needs to access and manage KafkaConnect resources
      - kafkaconnects
      - kafkaconnects/status
      # The cluster operator runs the KafkaConnectorAssemblyOperator, which needs to access and manage KafkaConnector resources
      - kafkaconnectors
      - kafkaconnectors/status
      # The cluster operator runs the KafkaMirrorMakerAssemblyOperator, which needs to access and manage KafkaMirrorMaker resources
      - kafkamirrormakers
      - kafkamirrormakers/status
      # The cluster operator runs the KafkaBridgeAssemblyOperator, which needs to access and manage BridgeMaker resources
      - kafkabridges
      - kafkabridges/status
      # The cluster operator runs the KafkaMirrorMaker2AssemblyOperator, which needs to access and manage KafkaMirrorMaker2 resources
      - kafkamirrormaker2s
      - kafkamirrormaker2s/status
      # The cluster operator runs the KafkaRebalanceAssemblyOperator, which needs to access and manage KafkaRebalance resources
      - kafkarebalances
      - kafkarebalances/status
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "core.strimzi.io"
    resources:
      # The cluster operator uses StrimziPodSets to manage the Kafka and ZooKeeper pods
      - strimzipodsets
      - strimzipodsets/status
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      # The cluster operator needs the extensions api as the operator supports Kubernetes version 1.11+
      # apps/v1 was introduced in Kubernetes 1.14
      - "extensions"
    resources:
      # The cluster operator needs to access and manage deployments to run deployment based Strimzi components
      - deployments
      - deployments/scale
      # The cluster operator needs to access replica sets to manage Strimzi components and to determine error states
      - replicasets
      # The cluster operator needs to access and manage replication controllers to manage replicasets
      - replicationcontrollers
      # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components
      - networkpolicies
      # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster
      - ingresses
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "apps"
    resources:
      # The cluster operator needs to access and manage deployments to run deployment based Strimzi components
      - deployments
      - deployments/scale
      - deployments/status
      # The cluster operator needs to access and manage stateful sets to run stateful sets based Strimzi components
      - statefulsets
      # The cluster operator needs to access replica-sets to manage Strimzi components and to determine error states
      - replicasets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      # The cluster operator needs to be able to create events and delegate permissions to do so
      - events
    verbs:
      - create
  - apiGroups:
      # Kafka Connect Build on OpenShift requirement
      - build.openshift.io
    resources:
      - buildconfigs
      - buildconfigs/instantiate
      - builds
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - networking.k8s.io
    resources:
      # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components
      - networkpolicies
      # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster
      - ingresses
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - route.openshift.io
    resources:
      # The cluster operator needs to access and manage routes to expose Strimzi components for external access
      - routes
      - routes/custom-host
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - policy
    resources:
      # The cluster operator needs to access and manage pod disruption budgets this limits the number of concurrent disruptions
      # that a Strimzi component experiences, allowing for higher availability
      - poddisruptionbudgets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update

2 番目の一連の権限には、クラスタースコープリソースに必要な権限が含まれます。

Cluster Operator のクラスタースコープリソースのある ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-cluster-operator-global
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to create and manage cluster role bindings in the case of an install where a user
      # has specified they want their cluster role bindings generated
      - clusterrolebindings
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - storage.k8s.io
    resources:
      # The cluster operator requires "get" permissions to view storage class details
      # This is because only a persistent volume of a supported storage class type can be resized
      - storageclasses
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      # The cluster operator requires "list" permissions to view all nodes in a cluster
      # The listing is used to determine the node addresses when NodePort access is configured
      # These addresses are then exposed in the custom resource states
      - nodes
    verbs:
      - list

strimzi-kafka-broker ClusterRole は、ラック機能に使用される Kafka Pod の init コンテナーが必要とするアクセス権限を表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。

Cluster Operator の ClusterRole により、OpenShift ノードへのアクセスを Kafka ブローカー Pod に委譲できます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-kafka-broker
  labels:
    app: strimzi
rules:
  - apiGroups:
      - ""
    resources:
      # The Kafka Brokers require "get" permissions to view the node they are on
      # This information is used to generate a Rack ID that is used for High Availability configurations
      - nodes
    verbs:
      - get

strimzi-topic-operatorClusterRole は、Topic Operator が必要とするアクセスを表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。

Cluster Operator のClusterRole により、イベントへのアクセスを Topic Operator に委譲できます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-entity-operator
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "kafka.strimzi.io"
    resources:
      # The entity operator runs the KafkaTopic assembly operator, which needs to access and manage KafkaTopic resources
      - kafkatopics
      - kafkatopics/status
      # The entity operator runs the KafkaUser assembly operator, which needs to access and manage KafkaUser resources
      - kafkausers
      - kafkausers/status
    verbs:
      - get
      - list
      - watch
      - create
      - patch
      - update
      - delete
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      # The entity operator needs to be able to create events
      - create
  - apiGroups:
      - ""
    resources:
      # The entity operator user-operator needs to access and manage secrets to store generated credentials
      - secrets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update

strimzi-kafka-client ClusterRole は、クライアントのラックアウェアネスを使用する Kafka クライアントをベースとしたコンポーネントが必要とするアクセス権限を表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。

Cluster Operator の ClusterRole により、OpenShift ノードへのアクセスを Kafka クライアントベースの Pod に委譲できます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-kafka-client
  labels:
    app: strimzi
rules:
  - apiGroups:
      - ""
    resources:
      # The Kafka clients (Connect, Mirror Maker, etc.) require "get" permissions to view the node they are on
      # This information is used to generate a Rack ID (client.rack option) that is used for consuming from the closest
      # replicas when enabled
      - nodes
    verbs:
      - get

6.1.1.8. ClusterRoleBindings

Operator には ClusterRoleBindingsClusterRoleServiceAccount に関連付ける RoleBindings が必要です。ClusterRoleBindings は、クラスタースコープのリソースを含む ClusterRole に必要です。

Cluster Operator の ClusterRoleBinding の例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-cluster-operator-global
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings は、委譲に必要な ClusterRole にも必要です。

Kafka ブローカーラックアウェアネスの Cluster Operator の ClusterRoleBinding の例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator-kafka-broker-delegation
  labels:
    app: strimzi
# The Kafka broker cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka brokers.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-kafka-broker
  apiGroup: rbac.authorization.k8s.io

および

Kafka クライアントラックアウェアネスの Cluster Operator の ClusterRoleBinding の例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator-kafka-client-delegation
  labels:
    app: strimzi
# The Kafka clients cluster role must be bound to the cluster operator service account so that it can delegate the
# cluster role to the Kafka clients using it for consuming from closest replica.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-kafka-client
  apiGroup: rbac.authorization.k8s.io

namespaced リソースのみが含まれる ClusterRoles は、RoleBindings のみを使用してバインドされます。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-cluster-operator-namespaced
  apiGroup: rbac.authorization.k8s.io
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: strimzi-cluster-operator-entity-operator-delegation
  labels:
    app: strimzi
# The Entity Operator cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Entity Operator.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-entity-operator
  apiGroup: rbac.authorization.k8s.io

6.1.2. デフォルトのプロキシー設定を使用した Cluster Operator の設定

HTTP プロキシーの背後で Kafka クラスターを実行している場合は、クラスターとの間でデータを出し入れできます。たとえば、プロキシー外からデータをプッシュおよびプルするコネクターで Kafka Connect を実行できます。または、プロキシーを使用して承認サーバーに接続できます。

プロキシー環境変数を指定するように Cluster Operator デプロイメントを設定します。クラスタオペレータは標準的なプロキシ設定(HTTP_PROXYHTTPS_PROXYNO_PROXY)を環境変数として受け入れます。プロキシー設定はすべての AMQ Streams コンテナーに適用されます。

プロキシーアドレスの形式は http://IP-ADDRESS:PORT-NUMBER です。名前とパスワードでプロキシーを設定する場合、形式は http://USERNAME:PASSWORD@IP-ADDRESS:PORT-NUMBER です。

前提条件

この手順では、CustomResourceDefinitionsClusterRoles、および ClusterRoleBindings を作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーは system:admin などの OpenShift クラスター管理者に限定されます。

手順

  1. クラスタオペレータにプロキシ環境変数を追加するには、そのDeployment構成(install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml)を更新します。

    Cluster Operator のプロキシー設定の例

    apiVersion: apps/v1
    kind: Deployment
    spec:
      # ...
      template:
        spec:
          serviceAccountName: strimzi-cluster-operator
          containers:
            # ...
            env:
            # ...
            - name: "HTTP_PROXY"
              value: "http://proxy.com" 1
            - name: "HTTPS_PROXY"
              value: "https://proxy.com" 2
            - name: "NO_PROXY"
              value: "internal.com, other.domain.com" 3
      # ...

    1
    プロキシーサーバーのアドレス。
    2
    プロキシーサーバーの安全なアドレス。
    3
    プロキシーサーバーの例外として直接アクセスされるサーバーのアドレス。URL はカンマで区切られます。

    または、Deployment を直接編集します。

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

    oc create -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml

6.1.3. Cluster Operator での FIPS モードの設定

FIPS(Federal Information Processing Standards)は、コンピューターセキュリティーおよび相互運用性の標準です。FIPS 対応の OpenShift クラスターで AMQ Streams を実行する場合に、AMQ Streams コンテナーイメージで使用される OpenJDK は自動的に FIPS モードに切り替わります。これにより、AMQ Streams がクラスターで実行されなくなります。AMQ Streams をクラスターにデプロイする場合、以下のようなエラーが表示されます。

Exception in thread "main" io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
	...
Caused by: java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY
	...
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY
	...

FIPS 対応のクラスターで AMQ Streams を実行する必要がある場合には、Cluster Operator のデプロイメント設定で FIPS_MODE 環境変数を disabled に設定すると、OpenJDK FIPS モードを無効にできます。AMQ Streams デプロイメントは FIPS に準拠しませんが、AMQ Streams Operator とそのすべてのオペランドは FIPS 対応の OpenShift クラスターで実行できます。

手順

  1. Cluster Operator で FIPS モードを無効にするには、Deployment 設定 (install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml)を更新し、FIPS_MODE 環境変数を追加します。

    Cluster Operator の FIPS 設定例

    apiVersion: apps/v1
    kind: Deployment
    spec:
      # ...
      template:
        spec:
          serviceAccountName: strimzi-cluster-operator
          containers:
            # ...
            env:
            # ...
            - name: "FIPS_MODE"
              value: "disabled" 1
      # ...

    1
    FIPS モードを無効にします。

    または、Deployment を直接編集します。

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

    oc apply -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml

6.2. Topic Operator の使用

KafkaTopic リソースを使用してトピックを作成、編集、または削除する場合、Topic Operator によって変更が確実に Kafka クラスターで反映されます。

OpenShift での AMQ Streams のデプロイおよびアップグレード』には、Topic Operator をデプロイする手順が記載されています。

6.2.1. Kafka トピックリソース

KafkaTopic リソースは、パーティションやレプリカの数を含む、トピックの設定に使用されます。

KafkaTopic の完全なスキーマは、「KafkaTopic スキーマ参照」で確認できます。

6.2.1.1. トピック処理用の Kafka クラスターの特定

KafkaTopic リソースには、このリソースが属する Kafka クラスターの適した名前 (Kafka リソースの名前から派生) を定義するラベルが含まれます。

以下はその例です。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
  labels:
    strimzi.io/cluster: my-cluster

ラベルは、KafkaTopic リソースを特定し、新しいトピックを作成するために、Topic Operator によって使用されます。また、以降のトピックの処理でも使用されます。

ラベルが Kafka クラスターと一致しない場合、Topic Operator は KafkaTopic を識別できず、トピックは作成されません。

6.2.1.2. Kafka トピックの使用に関する推奨事項

トピックを使用する場合は、整合性を保ちます。常に KafkaTopic リソースで作業を行うか、直接 OpenShift でトピックを扱います。特定のトピックで、両方の方法を頻繁に切り替えないでください。

トピックの性質を反映するトピック名を使用し、後で名前を変更できないことに注意してください。

Kafka でトピックを作成する場合は、有効な OpenShift リソース名である名前を使用します。それ以外の場合は、Topic Operator は対応する KafkaTopic を OpenShift ルールに準じた名前で作成する必要があります。

注記

OpenShift での識別子と名前の要件については、Object Names and IDs を参照してください。

6.2.1.3. Kafka トピックの命名規則

Kafka と OpenShift では、Kafka と KafkaTopic.metadata.name でのトピックの命名にそれぞれ独自の検証ルールを適用します。トピックごとに有効な名前があり、他のトピックには無効です。

spec.topicName プロパティーを使用すると、OpenShift の Kafka トピックでは無効な名前を使用して、Kafka で有効なトピックを作成できます。

spec.topicName<