AMQ Streams on OpenShift の使用

Red Hat AMQ 2021.q2

OpenShift Container Platform 上で AMQ Streams 1.7 を使用

概要

本ガイドでは、Red Hat AMQ Streams をインストール、設定、および管理して、大規模なメッセージングネットワークを構築する方法を説明します。

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

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

第1章 AMQ Streams の概要

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

本ガイドでは、Kafka コンポーネントの設定方法と、AMQ Streams Operator の使用方法を説明します。手順は、デプロイメントの変更方法や、Cruise Control や分散トレーシングなどの追加機能を導入する方法に関連しています。

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

注記

AMQ Streams を使用する方法ステップごとのデプロイメント手順は、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。

1.1. Kafka の機能

Kafka の基盤のデータストリーム処理機能とコンポーネントアーキテクチャーによって以下が提供されます。

スループットが非常に高く、レイテンシーが低い状態でデータを共有するマイクロサービスおよびその他のアプリケーション。
メッセージの順序の保証。
アプリケーションの状態を再構築するためにデータストレージからメッセージを巻き戻し/再生。
キーバリューログの使用時に古いレコードを削除するメッセージ圧縮。
クラスター設定での水平スケーラビリティー。
耐障害性を制御するデータのレプリケーション。
即座にアクセスするために大容量のデータを保持。

1.2. Kafka のユースケース

Kafka の機能は、以下に適しています。

イベント駆動型のアーキテクチャー。
アプリケーションの状態変更をイベントのログとしてキャプチャーするイベントソーシング。
メッセージのブローカー。
Web サイトアクティビティーの追跡。
メトリクスによるオペレーションの監視。
ログの収集および集計。
分散システムのログのコミット。
アプリケーションがリアルタイムでデータに対応できるようにするストリーム処理。

1.3. AMQ Streams による Kafka のサポート

AMQ Streams は、Kafka を OpenShift で実行するためのコンテナーイメージおよび Operator を提供します。AMQ Streams Operator は、AMQ Streams の実行に必要です。AMQ Streams で提供される Operator は、Kafka を効果的に管理するために、専門的なオペレーション情報で目的に合うよう構築されています。

Operator は以下のプロセスを単純化します。

Kafka クラスターのデプロイおよび実行。
Kafka コンポーネントのデプロイおよび実行。
Kafka へアクセスするための設定。
Kafka へのアクセスをセキュア化。
Kafka のアップグレード。
ブローカーの管理。
トピックの作成および管理。
ユーザーの作成および管理。

1.4. AMQ Streams の Operator

AMQ Streams では Operator を使用して Kafka をサポートし、Kafka のコンポーネントおよび依存関係を OpenShift にデプロイして管理します。

Operator は、OpenShift アプリケーションのパッケージ化、デプロイメント、および管理を行う方法です。AMQ Streams Operator は OpenShift の機能を拡張し、Kafka デプロイメントに関連する共通タスクや複雑なタスクを自動化します。Kafka 操作の情報をコードに実装することで、Kafka の管理タスクは簡素化され、必要な手動の作業が少なくなります。

Operator

AMQ Streams は、OpenShift クラスター内で実行中の Kafka クラスターを管理するための Operator を提供します。

Cluster Operator: Apache Kafka クラスター、Kafka Connect、Kafka MirrorMaker、Kafka Bridge、Kafka Exporter、および Entity Operator をデプロイおよび管理します。
Entitiy Operator: Topic Operator および User Operator を構成します。
Topic Operator: Kafka トピックを管理します。
User Operator: Kafka ユーザーを管理します。

Cluster Operator は、Kafka クラスターと同時に、Topic Operator および User Operator を Entity Operator 設定の一部としてデプロイできます。

AMQ Streams アーキテクチャー内の Operator

Operators within the AMQ Streams architecture

1.4.1. Cluster Operator

AMQ Streams では、Cluster Operator を使用して以下のクラスターをデプロイおよび管理します。

Kafka (ZooKeeper、Entity Operator、Kafka Exporter、Cruise Control を含む)
Kafka Connect
Kafka MirrorMaker
Kafka Bridge

クラスターのデプロイメントにはカスタムリソースが使用されます。

たとえば、以下のように Kafka クラスターをデプロイします。

クラスター設定のある Kafka リソースが OpenShift クラスター内で作成されます。
Kafka リソースに宣言された内容を基にして、該当する Kafka クラスターが Cluster Operator によってデプロイされます。

Cluster Operator で以下もデプロイできます (Kafka リソースの設定より)。

KafkaTopic カスタムリソースより Operator スタイルのトピック管理を提供する Topic Operator
KafkaUser カスタムリソースより Operator スタイルのユーザー管理を提供する User Operator

デプロイメントの Entity Operator 内の Topic Operator および User Operator 関数。

Cluster Operator のアーキテクチャー例

The Cluster Operator creates and deploys Kafka and ZooKeeper clusters

1.4.2. Topic Operator

Topic Operator は、OpenShift リソースより Kafka クラスターのトピックを管理する方法を提供します。

Topic Operator のアーキテクチャー例

The Topic Operator manages topics for a Kafka cluster via KafkaTopic resources

Topic Operator の役割は、対応する Kafka トピックと同期して Kafka トピックを記述する KafkaTopic OpenShift リソースのセットを保持することです。

KafkaTopic とトピックの関係は次のとおりです。

KafkaTopic が作成されると、Topic Operator によってトピックが作成されます。
KafkaTopic が削除されると、Topic Operator によってトピックが削除されます。
KafkaTopic が変更されると、Topick Operator によってトピックが更新されます。

上記と逆になるトピックと KafkaTopic の関係は次のとおりです。

トピックが Kafka クラスター内で作成されると、Operator によって KafkaTopic が作成されます。
トピックが Kafka クラスターから削除されると、Operator によって KafkaTopic が削除されます。
トピックが Kafka クラスターで変更されると、Operator によって KafkaTopic が更新されます。

このため、KafkaTopic をアプリケーションのデプロイメントの一部として宣言でき、トピックの作成は Topic Operator によって行われます。アプリケーションは、必要なトピックからの作成または消費のみに対処する必要があります。

Topic Operator は、各トピックの情報を トピックストア で維持します。トピックストアは、Kafka トピックまたは OpenShift KafkaTopic カスタムリソースからの更新と継続的に同期されます。ローカルのインメモリートピックストアに適用される操作からの更新は、ディスク上のバックアップトピックストアに永続化されます。トピックが再設定されたり、別のブローカーに再割り当てされた場合、KafkaTopic は常に最新の状態になります。

1.4.3. User Operator

User Operator は、Kafka ユーザーが記述される KafkaUser リソースを監視して Kafka クラスターの Kafka ユーザーを管理し、Kafka ユーザーが Kafka クラスターで適切に設定されるようにします。

たとえば、KafkaUser とユーザーの関係は次のようになります。

KafkaUser が作成されると、User Operator によって記述されるユーザーが作成されます。
KafkaUser が削除されると、User Operator によって記述されるユーザーが削除されます。
KafkaUser が変更されると、User Operator によって記述されるユーザーが更新されます。

User Operator は Topic Operator とは異なり、Kafka クラスターからの変更は OpenShift リソースと同期されません。アプリケーションで直接 Kafka トピックを Kafka で作成することは可能ですが、ユーザーが User Operator と同時に直接 Kafka クラスターで管理されることは想定されません。

User Operator では、アプリケーションのデプロイメントの一部として KafkaUser リソースを宣言できます。ユーザーの認証および承認メカニズムを指定できます。たとえば、ユーザーがブローカーへのアクセスを独占しないようにするため、Kafka リソースの使用を制御する ユーザークォータ を設定することもできます。

ユーザーが作成されると、ユーザークレデンシャルが Secret に作成されます。アプリケーションはユーザーとそのクレデンシャルを使用して、認証やメッセージの生成または消費を行う必要があります。

User Operator は認証のクレデンシャルを管理する他に、KafkaUser 宣言にユーザーのアクセス権限の記述を含めることで承認も管理します。

1.5. AMQ Streams のカスタムリソース

AMQ Streams を使用した Kafka コンポーネントの OpenShift クラスターへのデプロイメントは、カスタムリソースの適用により高度な設定が可能です。カスタムリソースは、OpenShift リソースを拡張するために CRD (カスタムリソース定義、Custom Resource Definition) によって追加される API のインスタンスとして作成されます。

CRD は、OpenShift クラスターでカスタムリソースを記述するための設定手順として機能し、デプロイメントで使用する Kafka コンポーネントごとに AMQ Streams で提供されます。CRD およびカスタムリソースは YAML ファイルとして定義されます。YAML ファイルのサンプルは AMQ Streams ディストリビューションに同梱されています。

また、CRD を使用すると、CLI へのアクセスや設定検証などのネイティブ OpenShift 機能を AMQ Streams リソースで活用することもできます。

その他のリソース

「Extend the Kubernetes API with CustomResourceDefinitions」

1.5.1. AMQ Streams カスタムリソースの例

AMQ Streams 固有リソースのインスタンス化および管理に使用されるスキーマを定義するため、CRD をクラスターに 1 度インストールする必要があります。

CRD をインストールして新規カスタムリソースタイプをクラスターに追加した後に、その仕様に基づいてリソースのインスタンスを作成できます。

クラスターの設定によりますが、インストールには通常、クラスター管理者権限が必要です。

注記

カスタムリソースの管理は、AMQ Streams 管理者のみが行えます。詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「AMQ Streams の管理者の指名」を参照してください。

kind:Kafka などの新しい kind リソースは、OpenShift クラスター内で CRD によって定義されます。

Kubernetes API サーバーを使用すると、kind を基にしたカスタムリソースの作成が可能になり、カスタムリソースが OpenShift クラスターに追加されたときにカスタムリソースの検証および格納方法を CRD から判断します。

警告

CRD が削除されると、そのタイプのカスタムタイプも削除されます。さらに、Pod や Statefulset などのカスタムリソースによって作成されたリソースも削除されます。

AMQ Streams 固有の各カスタムリソースは、リソースの kind の CRD によって定義されるスキーマに準拠します。AMQ Streams コンポーネントのカスタムリソースには、specで定義される共通の設定プロパティーがあります。

CRD とカスタムリソースの関係を理解するため、Kafka トピックの CRD の例を見てみましょう。

Kafka トピックの CRD

apiVersion: kafka.strimzi.io/v1beta2
kind: CustomResourceDefinition
metadata: 1
  name: kafkatopics.kafka.strimzi.io
  labels:
    app: strimzi
spec: 2
  group: kafka.strimzi.io
  versions:
    v1beta2
  scope: Namespaced
  names:
    # ...
    singular: kafkatopic
    plural: kafkatopics
    shortNames:
    - kt 3
  additionalPrinterColumns: 4
      # ...
  subresources:
    status: {} 5
  validation: 6
    openAPIV3Schema:
      properties:
        spec:
          type: object
          properties:
            partitions:
              type: integer
              minimum: 1
            replicas:
              type: integer
              minimum: 1
              maximum: 32767
      # ...

1: CRD を識別するためのトピック CRD、その名前および名前のメタデータ。
2: この CRD に指定された項目には、トピックの API にアクセスするため URL に使用されるグルShortNameープ (ドメイン) 名、複数名、およびサポートされるスキーマバージョンが含まれます。他の名前は、CLI のインスタンスリソースを識別するために使用されます。例: oc get kafkatopic my-topic または oc get kafkatopics
3: ShortName は CLI コマンドで使用できます。たとえば、oc get kafkatopic の代わりに oc get kt を略名として使用できます。
4: カスタムリソースで get コマンドを使用する場合に示される情報。
5: リソースのスキーマ参照に記載されている CRD の現在のステータス。
6: openAPIV3Schema 検証によって、トピックカスタムリソースの作成が検証されます。たとえば、トピックには 1 つ以上のパーティションと 1 つのレプリカが必要です。

注記

ファイル名に、インデックス番号とそれに続く「Crd」が含まれるため、AMQ Streams インストールファイルと提供される CRD YAML ファイルを識別できます。

KafkaTopic カスタムリソースに該当する例は次のとおりです。

Kafka トピックカスタムリソース

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic 1
metadata:
  name: my-topic
  labels:
    strimzi.io/cluster: my-cluster 2
spec: 3
  partitions: 1
  replicas: 1
  config:
    retention.ms: 7200000
    segment.bytes: 1073741824
status:
  conditions: 4
    lastTransitionTime: "2019-08-20T11:37:00.706Z"
    status: "True"
    type: Ready
  observedGeneration: 1
  / ...

1: kind および apiVersion によって、インスタンスであるカスタムリソースの CRD が特定されます。
2: トピックまたはユーザーが属する Kafka クラスターの名前 (Kafka リソースの名前と同じ) を定義する、KafkaTopic および KafkaUser リソースのみに適用可能なラベル。
3: 指定内容には、トピックのパーティション数およびレプリカ数や、トピック自体の設定パラメーターが示されています。この例では、メッセージがトピックに保持される期間や、ログのセグメントファイルサイズが指定されています。
4: KafkaTopic リソースのステータス条件。lastTransitionTime で type 条件が Ready に変更されています。

プラットフォーム CLI からカスタムリソースをクラスターに適用できます。カスタムリソースが作成されると、Kubernetes API の組み込みリソースと同じ検証が使用されます。

KafkaTopic の作成後、Topic Operator は通知を受け取り、該当する Kafka トピックが AMQ Streams で作成されます。

1.6. リスナーの設定

リスナーは、Kafka ブローカーへの接続に使用されます。

AMQ Streams は、Kafka リソース経由でリスナーを設定するプロパティーと汎用 GenericKafkaListener スキーマを提供します。

GenericKafkaListener は、柔軟なリスナー設定を実現します。

プロパティーを指定して、OpenShift クラスター内で接続する内部リスナーを設定したり、OpenShift クラスター外部で接続する外部リスナーを設定したりできます。

汎用リスナーの設定

各リスナーは、Kafka リソースの配列として定義されます。

リスナーの設定に関する詳細は、「GenericKafkaListener スキーマ参照」を参照してください。

汎用リスナー設定は、非推奨 である KafkaListeners スキーマ参照を使用した従来のリスナー設定の代わりに使用します。ただし、後方互換性によって、以前の形式を新しい形式に変換することができます。

KafkaListeners スキーマは plain、tls、および external リスナーのサブプロパティーを使用し、それぞれに固定ポートを使用します。スキーマのアーキテクチャー固有の制限により、3 つのリスナーのみを設定でき、設定オプションはリスナーのタイプに制限されます。

GenericKafkaListener スキーマでは、名前とポートが一意であれば、必要なリスナーをいくつでも設定できます。

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

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

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

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

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

リスナー証明書

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

1.7. 本書の表記慣例

置き換え可能なテキスト

本書では、置き換え可能なテキストは、monospace フォントのイタリック体、大文字、およびハイフンで記載されています。

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

sed -i 's/namespace: .*/namespace: MY-NAMESPACE/' install/cluster-operator/*RoleBinding*.yaml

第2章デプロイメント設定

本章では、カスタムリソースを使用してサポートされるデプロイメントのさまざまな側面を設定する方法について説明します。

Kafka クラスター
Kafka Connect クラスター
Source2Image がサポートされる Kafka Connect クラスター
Kafka MirrorMaker
Kafka Bridge
Cruise Control

注記

カスタムリソースに適用されるラベルは、Kafka MirrorMaker を構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。

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 スキーマ参照」に記載されています。

リスナーの設定

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

Kafka へのアクセスの承認

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

TLS 証明書の管理

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

その他のリソース

Apache Kafka の詳細は、Apache Kafka の Web サイトを参照してください。

2.1.1. Kafka の設定

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

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

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

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

Kafka バージョン

Kafka config の log.message.format.version および inter.broker.protocol.version プロパティーは、指定された Kafka バージョン (spec.kafka.version) によってサポートされるバージョンです。プロパティーは、メッセージに追加されるログ形式のバージョンと、Kafka クラスターで使用される Kafka プロトコルのバージョンを表します。Kafka バージョンのアップグレード時に、これらのプロパティーの更新が必要になります。詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka のアップグレード」を参照してください。

前提条件

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

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

手順

Kafka リソースの spec プロパティーを編集します。
設定可能なプロパティーは以下の例のとおりです。
```
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    replicas: 3 1
    version: 2.7.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
      log.message.format.version: 2.7
      inter.broker.protocol.version: 2.7
      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
ConfigMap にて直接的 (inline) または間接的 (external) に追加される Kafka のロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties キー下に配置する必要があります。Kafka kafka.root.logger.level ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。
4
現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
5
コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
6
Kafka を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
7
高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
8
リスナーは、ブートストラップアドレスでクライアントが Kafka クラスターに接続する方法を設定します。リスナーは、OpenShift クラスター内部または外部からの接続の内部または外部リスナーとして設定されます。
9
リスナーを識別するための名前。Kafka クラスター内で一意である必要があります。
10
Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。
11
internal として指定されたリスナータイプ。外部リスナーの場合は route、loadbalancer、nodeport、または ingress として指定。
12
各リスナーの TLS 暗号化を有効にします。デフォルトは false です。route リスナーには TLS 暗号化は必要ありません。
13
クラスターサービスサフィックス (通常は .cluster.local) を含む完全修飾 DNS 名が割り当てられているかどうかを定義します。
14
相互 TLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定されるリスナー認証メカニズム。
15
外部リスナー設定は、route、loadbalancer、または nodeport からなど、Kafka クラスターが OpenShift 外部で公開される方法を指定します。
16
外部の認証局によって管理される Kafka リスナー証明書の任意設定。brokerCertChainAndKey プロパティーは、サーバー証明書および秘密鍵が含まれる Secret を指定します。TLS による暗号化が有効な任意のリスナーで Kafka リスナー証明書を設定できます。
17
承認は Kafka ブローカーで簡易、OAUTH2.0、または OPA 承認を有効にします。簡易承認では AclAuthorizer Kafka プラグインが使用されます。
18
config によってブローカー設定が指定されます。標準の Apache Kafka 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。
19
特定の 暗号スイート または TLS バージョンを有効にするための、TLS による暗号化が有効になっているリスナーの SSL プロパティー。
20
ストレージは、ephemeral、persistent-claim、または jbod として設定されます。
21
永続ボリュームのストレージサイズが増やされることがあり、追加のボリュームが JBOD ストレージに追加されることがあります。
22
永続ストレージには、動的ボリュームプロビジョニングのためのストレージ id や class などの追加の設定オプションがあります。
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
指定された ZooKeeper ロガーおよびログレベル。
29
Topic Operator および User Operator の設定を指定する、Entity Operator 設定。
30
Entity Operator の TLS サイドカー設定。Entity Operator は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。
31
指定された Topic Operator ロガーおよびログレベル。この例では、inline ロギングが使用されます。
32
指定された User Operator ロガーおよびログレベル。
33
Kafka Exporter の設定。Kafka Exporter は、特にコンシューマーラグデータなどのメトリクスデータを Kafka ブローカーから抽出する任意のコンポーネントです。
34
Kafka クラスターのリバランスに使用される Cruise Control の任意設定。
35
Cruise Conrol の TLS サイドカーの設定。Cruise Control は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。
リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-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 にオペレーターが含まれます。

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

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

Kafka.spec の entityOperator プロパティーを使用して 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 スキーマ参照」を参照してください。

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

Topic Operator の設定例

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

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

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

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

その他のリソース

一時ストレージの詳細は、「一時ストレージのスキーマ参照」を参照してください。
永続ストレージの詳細は、「永続ストレージのスキーマ参照」を参照してください。
JBOD ストレージの詳細は、「JBOD スキーマ参照」を参照してください。
Kafka のスキーマに関する詳細は、「Kafka スキーマ参照」を参照してください。

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

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

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

ブロックストレージには、以下などを選択できます。

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

注記

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

2.1.3.1.1. ファイルシステム

XFS ファイルシステムを使用するようにストレージシステムを設定することが推奨されます。AMQ Streams は ext4 ファイルシステムとも互換性がありますが、最適化するには追加の設定が必要になることがあります。

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 ストレージやローカル永続ボリュームなどがあります。

永続ストレージを使用するには、type を persistent-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 が使用されます。
ZooKeeper ノード 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. Persistent Volume Claim (永続ボリューム要求、PVC) の命名

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

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 クラスター。

手順

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:
    # ...
```
リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
OpenShift では、Cluster Operator からの要求に応じて、選択された永続ボリュームの容量が増やされます。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。

その他のリソース

OpenShift での永続ボリュームのサイズ変更に関する詳細は、「Resizing Persistent Volumes using Kubernetes」を参照してください。

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 を使用するには、ストレージ type を jbod に設定する必要があります。volumes プロパティーを使用すると、JBOD ストレージアレイまたは設定を構成するディスクを記述できます。以下は、JBOD 設定例の抜粋になります。

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

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

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

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

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

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 クラスター。

手順

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

リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てします。

その他のリソース

トピックの再割り当てに関する詳細は「パーティションの再割り当て」を参照してください。

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

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

重要

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

前提条件

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

手順

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

Kafka リソースの spec.kafka.storage.volumes プロパティーを編集します。volumes アレイから 1 つまたは複数のボリュームを削除します。たとえば、ID が 1 と 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
    # ...
  zookeeper:
    # ...

リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```

その他のリソース

トピックの再割り当てに関する詳細は「パーティションの再割り当て」を参照してください。

2.1.4. クラスターのスケーリング

2.1.4.1. Kafka クラスターのスケーリング

2.1.4.1.1. ブローカーのクラスターへの追加

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

追加のブローカーをクラスターに追加する場合、Kafka ではパーティションは自動的に割り当てられません。既存のブローカーから新規のブローカーに移動するパーティションを決定する必要があります。

すべてのブローカー間でパーティションが再分散されたら、各ブローカーのリソース使用率が低下するはずです。

2.1.4.1.2. クラスターからのブローカーの削除

AMQ Streams では 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 (In-Sync Replica、同期レプリカ) に参加できたら、古いブローカーはフォロワーではなくなり、そのレプリカが削除されます。
--verify: --verify は、--execute ステップと同じ 再割り当て JSON ファイル を使用して、ファイル内のすべてのパーティションが目的のブローカーに移動されたかどうかを確認します。再割り当てが完了すると、--verify は有効なスロットルも削除します。スロットルを削除しないと、再割り当てが完了した後もクラスターは影響を受け続けます。

クラスターでは、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 をブローカー 2、4、および 7 に割り当て、トピック topic-b のパーティション 2 をブローカー 1、5、および 7 に割り当てる、再割り当て 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" ]
}

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

この手順では、kafka-reassign-partitions.sh ツールを使用して、指定のトピックセットすべてのパーティションを再割り当てする再割り当て JSON ファイルを生成する方法を説明します。

前提条件

稼働中の Cluster Operator。
Kafka リソース
パーティションを再割り当てするトピックセット。

手順

移動するトピックを一覧表示する topics.json という名前の JSON ファイルを準備します。これには、以下の構造が必要です。
```
{
  "version": 1,
  "topics": [
    <TopicObjects>
  ]
}
```
ここで <TopicObjects> は、以下のようなコンマ区切りのオブジェクトリストになります。
```
{
  "topic": <TopicName>
}
```
たとえば、topic-a と topic-b のすべてのパーティションを再割り当てするには、以下のような topics.json ファイルを準備する必要があります。
```
{
  "version": 1,
  "topics": [
    { "topic": "topic-a"},
    { "topic": "topic-b"}
  ]
}
```

topics.json ファイルをブローカー Pod の 1 つにコピーします。

cat topics.json | oc exec -c kafka <BrokerPod> -i -- \
  /bin/bash -c \
  'cat > /tmp/topics.json'

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

oc exec <BrokerPod> -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --topics-to-move-json-file /tmp/topics.json \
  --broker-list <BrokerList> \
  --generate

たとえば、topic-a および topic-b のすべてのパーティションをブローカー 4 および 7 に移動する場合は、以下を実行します。

oc exec <BrokerPod> -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --topics-to-move-json-file /tmp/topics.json \
  --broker-list 4,7 \
  --generate

2.1.4.4. 手動による再割り当て JSON ファイルの作成

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

2.1.4.5. 再割り当てスロットル

パーティションの再割り当てには、ブローカーの間で大量のデータを転送する必要があるため、処理が遅くなる可能性があります。クライアントへの悪影響を防ぐため、再割り当て処理をスロットルで調整することができます。これにより、再割り当ての完了に時間がかかる可能性があります。

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

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

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

この手順では、Kafka クラスターでブローカーの数を増やす方法を説明します。

前提条件

既存の Kafka クラスター。
拡大されたクラスターでパーティションをブローカーに再割り当てする方法が記述される reassignment.json というファイル名の 再割り当て JSON ファイル。

手順

Kafka.spec.kafka.replicas 設定オプションを増やして、新しいブローカーを必要なだけ追加します。
新しいブローカー Pod が起動したことを確認します。

後でコマンドを実行するブローカー Pod に reassignment.json ファイルをコピーします。

cat reassignment.json | \
  oc exec broker-pod -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

以下に例を示します。

cat reassignment.json | \
  oc exec my-cluster-kafka-0 -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

同じブローカー Pod から kafka-reassign-partitions.sh コマンドラインツールを使用して、パーティションの再割り当てを実行します。
```
oc exec broker-pod -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --execute
```
レプリケーションをスロットルで調整する場合、--throttle とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下に例を示します。
```
oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --throttle 5000000 \
  --execute
```
このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡した目的の再割り当てです。

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

oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --throttle 10000000 \
  --execute

ブローカー Pod のいずれかから kafka-reassign-partitions.sh コマンドラインツールを使用して、再割り当てが完了したかどうかを定期的に確認します。これは先ほどの手順と同じコマンドですが、--execute オプションの代わりに --verify オプションを使用します。

oc exec broker-pod -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --verify

例:

oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --verify

--verify コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な --verify によって、結果的に再割り当てスロットルも削除されます。割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。

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

この手順では、Kafka クラスターでブローカーの数を減らす方法を説明します。

前提条件

既存の Kafka クラスター。
最も番号の大きい Pod(s) のブローカーが削除された後にクラスターのブローカーにパーティションを再割り当てする方法が記述されている、reassignment.json という名前の 再割り当て JSON ファイル。

手順

後でコマンドを実行するブローカー Pod に reassignment.json ファイルをコピーします。

cat reassignment.json | \
  oc exec broker-pod -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

以下に例を示します。

cat reassignment.json | \
  oc exec my-cluster-kafka-0 -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

同じブローカー Pod から kafka-reassign-partitions.sh コマンドラインツールを使用して、パーティションの再割り当てを実行します。
```
oc exec broker-pod -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --execute
```
レプリケーションをスロットルで調整する場合、--throttle とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下に例を示します。
```
oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --throttle 5000000 \
  --execute
```
このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡した目的の再割り当てです。

oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --throttle 10000000 \
  --execute

oc exec broker-pod -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --verify

例:

oc exec my-cluster-kafka-0 -c kafka -it -- \
  bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file /tmp/reassignment.json \
  --verify

--verify コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な --verify によって、結果的に再割り当てスロットルも削除されます。割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。
すべてのパーティションの再割り当てが終了すると、削除されるブローカーはクラスター内のいずれのパーティションにも対応しないはずです。これは、ブローカーのデータログディレクトリーにライブパーティションのログが含まれていないことを確認すると検証できます。ブローカーのログディレクトリーに、拡張正規表現 \.[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(s) の数に置き換えます。
上記のコマンドによって出力が生成される場合、ブローカーにはライブパーティションがあります。この場合、再割り当てが終了していないか、再割り当て JSON ファイルが適切ではありません。
ブローカーにライブパーティションがないことが確認できたら、Kafka リソースの Kafka.spec.kafka.replicas を編集できます。これにより、StatefulSet がスケールダウンされ、番号が最も大きいブローカー Pod(s) が削除されます。

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 の調整が行われる間隔の長さ分、遅れる可能性があることを意味します。したがって、メンテナンス時間枠は最低でもその間隔の長さにする必要があります。

その他のリソース

Cluster Operator 設定についての詳細は、「Cluster Operator の設定」を参照してください。

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

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

前提条件

OpenShift クラスターが必要です。
Cluster Operator が稼働している必要があります。

手順

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 * * ?"
```
リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```

その他のリソース

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

「StatefulSet アノテーションを使用したローリングアップデートの実行」
「Pod アノテーションを使用したローリングアップデートの実行」

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

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

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

前提条件

OpenShift クラスターが利用できる必要があります。
Kafka クラスターが稼働している必要があります。
Cluster Operator が稼働している必要があります。

手順

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 のデプロイおよびアップグレード』を参照してください。

手順

削除する Pod の名前を見つけます。
たとえば、クラスターの名前が cluster-name の場合、Pod の名前は cluster-name-kafka-index になります。index はゼロで始まり、レプリカーの合計数で終わる値です。
OpenShift で Pod リソースにアノテーションを付けます。
oc annotate を使用します。
```
oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true
```
基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。

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

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

警告

前提条件

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

手順

削除する Pod の名前を見つけます。
たとえば、クラスターの名前が cluster-name の場合、Pod の名前は cluster-name-zookeeper-index になります。index はゼロで始まり、レプリカーの合計数で終わる値です。
OpenShift で Pod リソースにアノテーションを付けます。
oc annotate を使用します。
```
oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true
```
基盤となる永続ボリューム要求 (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 ノード Pod の管理を担当する StatefulSet。
cluster-name-zookeeper-idx: Zookeeper StatefulSet によって作成された 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-zookeeper: Zookeeper ノードで使用されるサービスアカウント。
cluster-name-zookeeper: ZooKeeper ノードに設定された Pod の Disruption Budget。
cluster-name-network-policy-zookeeper: ZooKeeper サービスへのアクセスを管理するネットワークポリシー。
data-cluster-name-zookeeper-idx: ZooKeeper ノード Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。

Kafka ブローカー

cluster-name-kafka: Kafka ブローカー Pod の管理を担当する StatefulSet。
cluster-name-kafka-idx: Kafka StatefulSet によって作成された 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-kafka: Kafka ブローカーによって使用されるサービスアカウント。
cluster-name-kafka: Kafka ブローカーに設定された Pod の Disruption Budget。
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: Topic および User 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-operator-certs: Kafka および ZooKeeper と通信するための Entity Operator キーのあるシークレット。
cluster-name-entity-operator: Entity 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 でのデプロイメント。
cluster-name-kafka-exporter-random-string: Kafka Exporter デプロイメントによって作成された Pod。
cluster-name-kafka-exporter: コンシューマーラグメトリクスの収集に使用されるサービス。
cluster-name-kafka-exporter: Kafka Exporter によって使用されるサービスアカウント。

Cruise Control

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

cluster-name-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-cruise-control: Cruise Control との通信に使用されるサービス。
cluster-name-cruise-control: Cruise Control によって使用されるサービスアカウント。
cluster-name-network-policy-cruise-control: Cruise Control サービスへのアクセスを管理するネットワークポリシー。

2.2. Kafka Connect/S2I クラスターの設定

ここでは、AMQ Streams クラスターにて Kafka Connect や S2I (Source-to-Image) のある Kafka Connect デプロイメントを設定する方法を説明します。

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

Kafka Connect を使用している場合は、KafkaConnect または KafkaConnectS2I リソースを設定します。S2I (Source-to-Image) フレームワークを使用して Kafka Connect をデプロイする場合は、KafkaConnectS2I リソースを使用します。

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

重要

build 設定が KafkaConnect リソースに導入されたため、AMQ Streams はデータコネクションに必要なコネクタープラグインでコンテナーイメージを自動的にビルドできるようになりました。そのため、S2I (Source-to-Image) 対応の Kafka Connect のサポートが非推奨になりました。この変更に備えるため、Kafka Connect S2I インスタンスを Kafka Connect インスタンスに移行できます。

その他のリソース

2.2.1. Kafka Connect の設定

Kafka Connect を使用して、Kafka クラスターへの外部データ接続を設定します。

KafkaConnect または KafkaConnectS2I リソースのプロパティーを使用して、Kafka Connect デプロイメントを設定します。この手順の例は、KafkaConnect リソースの場合ですが、プロパティーは KafkaConnectS2I リソースと同じです。

Kafka Connector の設定

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

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

コネクターを管理するには、Kafka Connect REST API を使用するか、KafkaConnector カスタムリソースを使用します。KafkaConnector リソースは、リンク先の Kafka Connect クラスターと同じ namespace にデプロイする必要があります。これらの方法を使用して、コネクターを作成、再割り当て、または削除するための詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」を参照してください。

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

前提条件

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

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

手順

KafkaConnect または KafkaConnectS2I リソースの 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 または KafkaConnectS2I を使用します。
2: Kafka Connect クラスターの KafkaConnectors を有効にします。
3: レプリカノードの数。
4: OAuth ベアラートークン、SASL ベースの 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: 現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
13: ConfigMap にて直接的 (inline) または間接的 (external) に追加される Kafka Connect のロガーおよびログレベルを指定します。カスタム 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: 環境変数は、Jaeger を使用した分散トレーシングにも設定されます。

リソースを作成または更新します。
```
oc apply -f KAFKA-CONNECT-CONFIG-FILE
```
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 Connect クラスターグループ。
2: コネクターオフセットを保存する Kafka トピック。
3: コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4: コネクターおよびタスクステータスの更新を保存する Kafka トピック。

注記

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

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

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

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

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

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

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

コンシューマーグループおよび内部トピックのプロパティーは AMQ Streams によって自動設定されますが、 KafkaConnect または KafkaConnectS2I リソースの 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 Connect クラスターグループ。
2: コネクターオフセットを保存する Kafka トピック。
3: コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4: コネクターおよびタスクステータスの更新を保存する Kafka トピック。

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

簡易 (simple) 承認は、Kafka AclAuthorizer プラグインによって処理される ACL ルールを使用し、適切なレベルのアクセス権限が提供されます。簡易 (simple) 承認を使用するように KafkaUser リソースを設定するための詳細は、「AclRule スキーマ参照」を参照してください。

注記

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

前提条件

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

手順

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: "*"

リソースを作成または更新します。
```
oc apply -f KAFKA-USER-CONFIG-FILE
```

2.2.4. Kafka コネクターの再起動の実行

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

前提条件

Cluster Operator が稼働している必要があります。

手順

再起動する Kafka コネクターを制御する KafkaConnector カスタムリソースの名前を見つけます。
```
oc get KafkaConnector
```
コネクターを再起動するには、OpenShift で KafkaConnector リソースにアノテーションを付けます。以下は oc annotate を使用した例になります。
```
oc annotate KafkaConnector KAFKACONNECTOR-NAME strimzi.io/restart=true
```
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka コネクターは再起動されます。Kafka Connect が再起動リクエストを受け入れると、アノテーションは KafkaConnector カスタムリソースから削除されます。

その他のリソース

『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」。

2.2.5. Kafka コネクタータスクの再起動の実行

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

前提条件

Cluster Operator が稼働している必要があります。

手順

再起動する Kafka コネクタータスクを制御する KafkaConnector カスタムリソースの名前を見つけます。
```
oc get KafkaConnector
```
KafkaConnector カスタムリソースから再起動するタスクの ID を検索します。タスク ID は 0 から始まる負の値ではない整数です。
```
oc describe KafkaConnector KAFKACONNECTOR-NAME
```
コネクタータスクを再起動するには、OpenShift で KafkaConnector リソースにアノテーションを付けます。たとえば、oc annotate を使用してタスク 0 を再起動します。
```
oc annotate KafkaConnector KAFKACONNECTOR-NAME strimzi.io/restart-task=0
```
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka コネクタータスクは再起動されます。Kafka Connect が再起動リクエストを受け入れると、アノテーションは KafkaConnector カスタムリソースから削除されます。

その他のリソース

『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」。

2.2.6. S2I を使用する Kafka Connect から Kafka Connect への移行

S2I を使用する Kafka Connect と KafkaConnectS2I リソースのサポートは非推奨になりました。これは、データ接続に必要なコネクタープラグインでコンテナーイメージを自動的にビルドするために使用される KafkaConnect リソースに build 設定プロパティーが導入されたためです。

この手順では、S2I インスタンスのある Kafka Connect を標準の Kafka Connect インスタンスに移行する方法を説明します。これには、KafkaConnectS2I リソースに代わる、新しい KafkaConnect カスタムリソースを設定します。設定後、KafkaConnectS2I リソースは削除されます。

警告

移行プロセスでは、KafkaConnectS2I インスタンスが削除された時点から、新しい KafkaConnect インスタンスが正常にデプロイされるまで、ダウンタイムが発生します。この間、コネクターは実行されず、データは処理されません。ただし、変更後に停止した時点からコネクターが続行されるはずです。

前提条件

S2I を使用する Kafka Connect がKafkaConnectS2I 設定を使用してデプロイされている。
S2I を使用する Kafka Connect が、S2I ビルドを使用して追加されたコネクターでイメージを使用している。
シンクおよびソースコネクターインスタンスは KafkaConnector リソースまたは Kafka Connect REST API を使用して作成された。

手順

KafkaconnectS2I リソースに使用される名前と同じ名前を使用して、新しい KafkaConnect カスタムリソースを作成します。
KafkaConnectS2I リソースプロパティーを KafkaConnect リソースにコピーします。
指定した場合は、同じ spec.config プロパティーを使用するようにしてください。
- group.id
- offset.storage.topic
- config.storage.topic
- status.storage.topic
  これらのプロパティーが指定されていない場合は、デフォルトが使用されます。この場合は、KafkaConnect リソース設定にも指定しません。
次に、KafkaConnect リソース固有の設定を新しいリソースに追加します。
build 設定を追加して、Kafka Connect デプロイメントに追加するすべてのコネクターおよびその他のライブラリーを設定します。
注記
この代わりに、コネクターで新しいイメージを手動でビルドし、.spec.image プロパティーを使用して指定することもできます。
古い KafkaConnectS2I リソースを削除します。
```
oc delete -f MY-KAFKA-CONNECT-S2I-CONFIG-FILE
```
MY-KAFKA-CONNECT-S2I-CONFIG-FILE を、KafkaConnectS2I リソース設定が含まれるファイルの名前に置き換えます。
代わりに、リソースの名前を指定できます。
```
oc delete kafkaconnects2i MY-KAFKA-CONNECT-S2I
```
MY-KAFKA-CONNECT-S2I を KafkaConnectS2I リソースの名前に置き換えます。
S2I を使用する Kafka Connect のデプロイメントと Pod が削除されるまで待ちます。
警告
他のリソースを削除する必要はありません。
新しい KafkaConnect リソースをデプロイします。
```
oc apply -f MY-KAFKA-CONNECT-CONFIG-FILE
```
MY-KAFKA-CONNECT-CONFIG-FILE を、新しい KafkaConnect リソース設定が含まれるファイルの名前に置き換えます。
新しいイメージのビルド、デプロイメントの作成、および Pod の起動が行われるまで待ちます。
Kafka Connect コネクターの管理に KafkaConnector リソースを使用している場合は、予想されるコネクターがすべて存在し、稼働していることを確認します。
```
oc get kctr --selector strimzi.io/cluster=MY-KAFKA-CONNECT-CLUSTER -o name
```
MY-KAFKA-CONNECT-CLUSTER は、Kafka Connect クラスターの名前に置き換えます。
コネクターは Kafka Connect ストレージより自動的に復元されます。Kafka Connect REST API を使用してコネクターを管理している場合でも、手作業で再作成する必要はありません。

その他のリソース

2.2.7. 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.8. Kafka Connect (S2I) クラスターリソースの一覧

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

connect-cluster-name-connect-source: 新たにビルドされた Docker イメージのベースイメージとして使用される ImageStream。
connect-cluster-name-connect: あたらしい Kafka Connect Docker イメージのビルドを担当する BuildConfig。
connect-cluster-name-connect: 新たにビルドされた Docker イメージがプッシュされる ImageStream。
connect-cluster-name-connect: Kafka Connect ワーカーノード Pod の作成を担当する DeploymentConfig。
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.9. 変更データキャプチャーのための 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 の設定

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

2.3.1. Kafka MirrorMaker の設定

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

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

前提条件

以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
- Cluster Operator
- Kafka クラスター
ソースおよびターゲットの Kafka クラスターが使用できる必要があります。

手順

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
  whitelist: "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
コンシューマーのグループ ID。
4
コンシューマーストリームの数。
5
オフセットの自動コミット間隔 (ミリ秒単位)。
6
コンシューマーまたはプロデューサーの TLS 証明書が X.509 形式で保存される、キー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
7
OAuth ベアラートークン、SASL ベースの 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
現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
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
環境変数は、Jaeger を使用した分散トレーシングにも設定されます。
23
Jaeger の分散トレーシングは有効になっています。
警告
abortOnSendFailure プロパティーが false に設定されると、プロデューサーはトピックの次のメッセージを送信しようとします。失敗したメッセージは再送されないため、元のメッセージが失われる可能性があります。
リソースを作成または更新します。
```
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 リソースを設定します。

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

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

MirrorMaker 2.0 によってデータが複製される方法は、以下に説明されています。

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

以下の手順では、MirrorMaker 2.0 に対してリソースが設定される方法について取り上げます。

MirrorMaker 2.0 を使用した Kafka クラスター間でのデータの同期

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

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 つのクラスターにおけるレプリケーション

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

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 bidirectional architecture

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

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

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

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

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

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

2.4.2.3. トピック設定の同期

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

2.4.2.4. データの整合性

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

2.4.2.5. オフセットの追跡

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

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

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

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

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

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

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

トピックオフセットの同期を使用するには、以下を行います。

sync.group.offsets.enabled を KafkaMirrorMaker2 リソースのチェックポイントコネクター設定に追加し、プロパティーを true に設定して同期を有効にします。同期はデフォルトで無効になっています。
IdentityReplicationPolicy をソースおよびチェックポイントコネクター設定に追加し、ターゲットクラスターのトピックが元の名前を保持するようにします。

トピックオフセットの同期を機能させるため、ターゲットクラスターのコンシューマーグループは、ソースクラスターのグループと同じ ID を使用できません。

同期を有効にすると、ソースクラスターからオフセットの同期が定期的に行われます。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. ACL ルールの同期

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

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

注記

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

2.4.4. MirrorMaker 2.0 を使用した Kafka クラスター間でのデータの同期

MirrorMaker 2.0 を使用して、設定を介して Kafka クラスター間のデータを同期します。

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

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

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

注記

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

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

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 2.7.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 による暗号化および認証を使用する設定を説明します。

前提条件

以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
- Cluster Operator
- Kafka クラスター
ソースおよびターゲットの Kafka クラスターが使用できる必要があります。

手順

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

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

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

前提条件

Cluster Operator が稼働している必要があります。

手順

再起動する Kafka MirrorMaker 2.0 コネクターを制御する KafkaMirrorMaker2 カスタムリソースの名前を見つけます。
```
oc get KafkaMirrorMaker2
```
KafkaMirrorMaker2 カスタムリソースから再起動される Kafka MirrorMaker 2.0 コネクターの名前を見つけます。
```
oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
```
コネクターを再起動するには、OpenShift で KafkaMirrorMaker2 リソースにアノテーションを付けます。以下の例では、my-source->my-target.MirrorSourceConnector という名前のコネクターが oc annotate によって再起動されます。
```
oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector=my-source->my-target.MirrorSourceConnector"
```
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka MirrorMaker 2.0 コネクターは再起動されます。再起動リクエストが許可されると、アノテーションは KafkaMirrorMaker2 カスタムリソースから削除されます。

その他のリソース

Kafka MirrorMaker 2.0 クラスターの設定

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

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

前提条件

Cluster Operator が稼働している必要があります。

手順

再起動する Kafka MirrorMaker 2.0 コネクターを制御する KafkaMirrorMaker2 カスタムリソースの名前を見つけます。
```
oc get KafkaMirrorMaker2
```
KafkaMirrorMaker2 カスタムリソースから再起動される Kafka MirrorMaker 2.0 コネクターの名前と、タスクの ID を見つけます。タスク ID は 0 から始まる負の値ではない整数です。
```
oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
```
コネクタータスクを再起動するには、OpenShift で KafkaMirrorMaker2 リソースにアノテーションを付けます。以下の例では、my-source->my-target.MirrorSourceConnector という名前のコネクターのタスク 0 が oc annotate によって再起動されます。
```
oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector-task=my-source->my-target.MirrorSourceConnector:0"
```
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka MirrorMaker 2.0 コネクタータスクは再起動されます。再起動タスクリクエストが許可されると、アノテーションは KafkaMirrorMaker2 カスタムリソースから削除されます。

その他のリソース

Kafka MirrorMaker 2.0 クラスターの設定

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 のデプロイおよびアップグレード』を参照してください。

手順

KafkaBridge リソースの spec プロパティーを編集します。
設定可能なプロパティーは以下の例のとおりです。
```
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  replicas: 3 1
  bootstrapServers: my-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 クラスターに接続するためのブートストラップサーバー。
3
ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
4
OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズムを使用する、Kafka Bridge クラスターの認証。デフォルトでは、Kafka Bridge は認証なしで Kafka ブローカーに接続します。
5
Kafka ブローカーへの HTTP アクセス。
6
選択されたリソースおよびアクセスメソッドを指定する CORS アクセス。リクエストの追加の HTTP ヘッダーには Kafka クラスターへのアクセスが許可されるオリジンが記述されています。
7
コンシューマー設定オプション。
8
プロデューサー設定オプション。
9
現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
10
ConfigMap にて直接的 (inline) または間接的 (external) に追加される Kafka Bridge のロガーおよびログレベルを指定します。カスタム 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
環境変数は、Jaeger を使用した分散トレーシングにも設定されます。
リソースを作成または更新します。
```
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 では、AMQ Streams の operator によって管理される Deployments、StatefulSets、Pods、および Services などの複数の OpenShift リソースが作成されます。特定の OpenShift リソースの管理を担当する operator のみがそのリソースを変更できます。operator によって管理される OpenShift リソースを手動で変更しようとすると、operator はその変更を元に戻します。

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

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

このような変更は、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 スキーマ参照」を参照
KafkaConnectS2I.spec: 「KafkaConnectTemplate スキーマ参照」を参照
KafkaMirrorMaker.spec: 「KafkaMirrorMakerTemplate スキーマ参照」を参照
KafkaMirrorMaker2.spec: 「KafkaConnectTemplate スキーマ参照」を参照
KafkaBridge.spec: 「KafkaBridgeTemplate スキーマ参照」を参照
KafkaUser.spec: 「KafkaUserTemplate スキーマ参照」を参照

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

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

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  labels:
    app: my-cluster
spec:
  kafka:
    # ...
    template:
      statefulset:
        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.7. Pod スケジューリングの設定

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

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

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

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

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

Pod のアフィニティーおよび非アフィニティー
ノードのアフィニティー

注記

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

その他のリソース

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 の非アフィニティーの設定

前提条件

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

手順

クラスターデプロイメントを指定するリソースの affinity プロパティーを編集します。ラベルを使用して、同じノードでスケジュールすべきでない Pod を指定します。topologyKey を kubernetes.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:
    # ...

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f KAFKA-CONFIG-FILE
```

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

前提条件

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

手順

AMQ Streams コンポーネントをスケジュールする必要のあるノードにラベルを付けます。
oc label を使用してこれを行うことができます。
```
oc label node NAME-OF-NODE node-type=fast-network
```
または、既存のラベルによっては再利用が可能です。

クラスターデプロイメントを指定するリソースの 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:
    # ...

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f KAFKA-CONFIG-FILE
```

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

前提条件

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

手順

専用ノードとして使用するノードを選択します。
これらのノードにスケジュールされているワークロードがないことを確認します。
選択したノードにテイントを設定します。
oc adm taint を使用してこれを行うことができます。
```
oc adm taint node NAME-OF-NODE dedicated=Kafka:NoSchedule
```
さらに、選択したノードにラベルも追加します。
oc label を使用してこれを行うことができます。
```
oc label node NAME-OF-NODE dedicated=Kafka
```

クラスターデプロイメントを指定するリソースの 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:
    # ...

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f KAFKA-CONFIG-FILE
```

2.8. 外部ロギング

リソースのロギングレベルを設定する場合、リソース YAML の spec.logging プロパティーで直接 インライン で指定できます。

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

または external ロギングを指定することもできます。

spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: keyInConfigMap

外部ロギングでは、ロギングプロパティーは ConfigMap に定義されます。ConfigMap の名前は spec.logging.valueFrom.configMapKeyRef.name プロパティーで参照されます。spec.logging.valueFrom.configMapKeyRef.name および spec.logging.valueFrom.configMapKeyRef.key プロパティーは必須です。name または key が設定されていない場合、デフォルトのロギングが使用されます。

ConfigMap を使用する利点は、ロギングプロパティーが 1 カ所で維持され、複数のリソースにアクセスできることです。

2.8.1. ロギングの ConfigMap の作成

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

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

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

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

ここでは、ConfigMap によって Kafka リソースのルートロガーが定義される方法を実証します。

手順

ConfigMap を作成します。
ConfigMap を YAML ファイルとして作成するか、コマンドラインで oc を使用してプロパティーファイルから Config Map を作成します。
Kafka のルートロガー定義が含まれる ConfigMap の例:
```
kind: ConfigMap
apiVersion: kafka.strimzi.io/v1beta2
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"
# ...
```
logging.valueFrom.configMapKeyRef.name を ConfigMap の名前に設定し、logging.valueFrom.configMapKeyRef.key をこの ConfigMap のキーに設定し、リソースの spec で外部ロギングを定義します。
```
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: keyInConfigMap
```
リソースを作成または更新します。
```
oc apply -f kafka.yaml
```

第3章外部リスナーの設定

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

コネクション type を指定して、外部リスナー設定で Kafka を公開します。

nodeport は NodePort タイプの Services を使用します。
loadbalancer は Loadbalancer タイプの Services を使用します。
ingress は、Kubernetes Ingress および NGINX Ingress Controller for Kubernetes を使用します。
route は OpenShift Routes および HAProxy ルーターを使用します。

リスナーの設定に関する詳細は、「GenericKafkaListener スキーマ参照」を参照してください。

注記

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

その他のリソース

Accessing Apache Kafka in Strimzi

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

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

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

前提条件

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

手順

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

以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: external
        port: 9094
        type: nodeport
        tls: true
        authentication:
          type: tls
        # ...
    # ...
  zookeeper:
    # ...

リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
NodePort タイプサービスは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。ブートストラップサービスは外部トラフィックを Kafka ブローカーにルーティングします。接続に使用されるノードアドレスは、Kafka カスタムリソースの status に伝播されます。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、Kafka リソースと同じ名前で作成されます。
Kafka リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップアドレスを取得します。
```
oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
```
TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。
```
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

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

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

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

前提条件

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

手順

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

以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: external
        port: 9094
        type: loadbalancer
        tls: true
        # ...
    # ...
  zookeeper:
    # ...

リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
loadbalancer タイプサービスおよびロードバランサーは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。ブートストラップサービスは外部トラフィックをすべての Kafka ブローカーにルーティングします。接続に使用される DNS 名と IP アドレスは、各サービスの status に伝播されます。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、Kafka リソースと同じ名前で作成されます。
Kafka リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップサービスのアドレスを取得します。
```
oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
```
TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。
```
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

3.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 パススルーのドキュメントを参照してください。

前提条件

OpenShift クラスターが必要です。
TLS パススルーが有効になっている、デプロイ済みの NGINX Ingress Controller for Kubernetes。
稼働中の Cluster Operator。

手順

外部リスナーを 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 ホスト。

リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
ClusterIP タイプサービスは、各 Kafka ブローカーと、追加の ブートストラップサービス に対して作成されます。これらのサービスは、トラフィックを Kafka ブローカーにルーティングするために Ingress コントローラーによって使用されます。また、各サービスに Ingress リソースが作成され、Ingress コントローラーを使用してそれらのリソースが公開されます。Ingress ホストは各サービスの status に伝播されます。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、Kafka リソースと同じ名前で作成されます。
configuration で指定したブートストラップホストのアドレスと、Kafka クライアントのポート 443 (BOOTSTRAP-HOST:443) を、Kafka クラスターに接続する ブートストラップアドレス として使用します。
ブローカーの認証局の公開証明書を取得します。
```
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

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

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

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

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

前提条件

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

手順

外部リスナーを 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 文字を超えないように注意してください。
リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
ClusterIP タイプサービスは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。サービスは、トラフィックを OpenShift ルートから Kafka ブローカーにルーティングします。また、各サービスに OpenShift Route リソースも作成され、HAProxy ロードバランサーを使用してそれらのリソースが公開されます。接続に使用される DNS アドレスは、各サービスの status に伝播されます。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、Kafka リソースと同じ名前で作成されます。
Kafka リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップサービスのアドレスを取得します。
```
oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
```
ブローカーの認証局の公開証明書を取得します。
```
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

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

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

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

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

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

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

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

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

4.1.1. リスナー認証

OpenShift クラスター内のクライアントの場合は、plain (暗号化なし) または tls 内部リスナーを作成できます。

OpenShift クラスター外のクライアントの場合は、外部リスナーを作成して接続メカニズムを指定します。接続メカニズムは nodeport、loadbalancer、ingress、または route (OpenShift の場合) のいずれかです。

外部クライアントを接続するための設定オプションの詳細は、「外部リスナーの設定」を参照してください。

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

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

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

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

options for listener authentication configuration

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

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

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

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

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

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

注記

ブローカー間通信 (9091) およびメトリクス (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
# ...

4.1.1.1. 相互 TLS 認証

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

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

注記

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

4.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.type を scram-sha-512 に設定すると、User Operator によって、大文字と小文字の ASCII 文字と数字で構成された無作為の 12 文字のパスワードが生成されます。

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

AMQ Streams では、Kafka ブローカーで有効になっているリスナーごとに NetworkPolicy リソースが自動的に作成されます。デフォルトでは、すべてのアプリケーションと namespace にアクセスする権限が NetworkPolicy によってリスナーに付与されます。

ネットワークレベルでのリスナーへのアクセスを指定のアプリケーションまたは namespace のみに制限するには、networkPolicyPeers プロパティーを使用します。

リスナーの認証設定の一部としてネットワークポリシーを使用します。リスナーごとに、異なる networkPolicyPeers 設定を指定できます。

詳細は、「リスナーネットワークポリシー」のセクションおよび「NetworkPolicyPeer API reference」を参照してください。

注記

AMQ Streams でネットワークポリシーを使用するには、ingress NetworkPolicies が OpenShift の設定でサポートされる必要があります。

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

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

4.1.2. Kafka の承認

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

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

簡易承認
OAuth 2.0 での承認 (OAuth 2.0 トークンベースの認証を使用している場合)
Open Policy Agent (OPA) での承認

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

options for kafks authorization configuration

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

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

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

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

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

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

4.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 リソースのステータスが空のままであれば、ラベルを確認してください。

4.2.2. ユーザー認証

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

サポートされる認証メカニズム

TLS クライアント認証
SCRAM-SHA-512 認証

認証メカニズムを指定しないと、User Operator によってユーザーまたはそのクレデンシャルが作成されません。

その他のリソース

クライアントに相互 TLS 認証または SCRAM-SHA 認証を使用する場合

4.2.2.1. TLS クライアント認証

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

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

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

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

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

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

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

ユーザークレデンシャルのある Secret の例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  ca.crt: # Public key 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

4.2.2.2. SCRAM-SHA-512 認証

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

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

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 でエンコードされます。パスワードを使用するにはデコードする必要があります。

ユーザークレデンシャルのある Secret の例

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

4.2.3. ユーザーの承認

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

簡易承認を使用するには、KafkaUser.spec.authorization で type プロパティーを simple に設定します。簡易承認では、デフォルトの Kafka 承認プラグインである AclAuthorizer が使用されます。

代わりに、OPA 承認を使用することもできます。OAuth 2.0 トークンベースの認証をすでに使用している場合は、OAuth 2.0 承認を使用することもできます。

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

4.2.3.1. ACL ルール

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

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

AclRule オブジェクトの詳細は、「AclRule スキーマ参照」を参照してください。

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

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

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

4.2.3.3. ユーザークォータ

KafkaUser リソースの spec を設定してクォータを強制し、バイトしきい値または CPU 使用の時間制限に基づいてユーザーが Kafka ブローカーへのアクセスを超過しないようにすることができます。

ユーザークォータをともなう 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

1: ユーザーが Kafka ブローカーにプッシュできるデータ量の、秒あたりのバイトクォータ。
2: ユーザーが Kafka ブローカーからフェッチできるデータ量の、秒あたりのバイトクォータ。
3: クライアントグループあたりの時間割合で示される、CPU 使用制限。

これらのプロパティーの詳細は、「KafkaUserQuotas スキーマ参照」を参照してください。

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

その他のリソース

スキーマの詳細は、以下を参照してください。

Kafka の場合は「Kafkaスキーマ参照」
KafkaUser の場合は「KafkaUserスキーマ参照」

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

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

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

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

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

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

手順

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
  承認は、AclAuthorizerKafka プラグインを使用して Kafka ブローカーで simple 承認を有効にします。
  2
  Kafka へのアクセスを制限されないユーザープリンシパルのリスト。CN は、TLS による認証が使用される場合のクライアント証明書の共通名です。
  3
  リスナーの認証メカニズムは各リスナーに対して設定でき、相互 TLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定できます。
  外部リスナーを設定している場合、設定は選択した接続のメカニズムによって異なります。
Kafka リソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```
Kafka クラスターは、TLS 認証を使用する Kafka ブローカーリスナーと共に設定されます。
Kafka ブローカー Pod ごとにサービスが作成されます。
サービスが作成され、Kafka クラスターに接続するための ブートストラップアドレス として機能します。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、Kafka リソースと同じ名前で作成されます。

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

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

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

以下に例を示します。

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

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

KafkaUser.spec.authentication は Kafka.spec.kafka.listeners[*].authentication と一致
KafkaUser.spec.authorization は Kafka.spec.kafka.authorization と一致

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

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

注記

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

前提条件

TLS による認証および暗号化を使用して Kafka ブローカーリスナーで設定された稼働中の Kafka クラスターが必要です。
稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。

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

手順

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 ルールのリストが必要な簡易承認。

KafkaUser リソースを作成または更新します。
```
oc apply -f USER-CONFIG-FILE
```
KafkaUser リソースと同じ名前の Secret と共に、ユーザーが作成されます。Secret には、TLS クライアント認証の秘密鍵と公開鍵が含まれます。

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

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

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

前提条件

Ingress NetworkPolicies をサポートする OpenShift クラスター。
Cluster Operator が稼働している必要があります。

手順

Kafka リソースを開きます。

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

以下は、ラベル app が kafka-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:
    # ...

リソースを作成または更新します。
oc apply を使用します。
```
oc apply -f your-file
```

その他のリソース

スキーマの詳細は、「NetworkPolicyPeer API reference」および「GenericKafkaListener スキーマ参照」を参照してください。

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

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

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

Kafka ブローカーおよびクライアントの両方が OAuth 2.0 を使用するように設定する必要があります。OAuth 2.0 認証を設定した後に OAuth 2.0 承認を設定できます。

注記

OAuth 2.0 認証は、Kafka 承認と併用できます。

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 サポート。

その他のリソース

OAuth 2.0 のサイト

4.4.1. OAuth 2.0 認証メカニズム

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

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

必要であれば、同じ oauth リスナーで OAUTHBEARER と PLAIN を両方有効にすることができます。

OAUTHBEARER の概要

Kafka は OAUTHBEARER 認証メカニズムをサポートしますが、明示的に設定する必要があります。また、多くの Kafka クライアントツールでは、プロトコルレベルで OAUTHBEARER の基本サポートを提供するライブラリーを使用します。

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

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

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

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

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

注記

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

PLAIN の概要

PLAIN は、すべての Kafka クライアントツール (kafkacat などの開発者ツールを含む) によって使用される簡易認証メカニズムです。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 クライアントクレデンシャルメカニズムを使用)
設定時に手動で取得された有効期限の長いアクセストークン

PLAIN 認証を使用し、username および password を提供するように、クライアントを有効にする必要があります。パスワードの最初に $accessToken: が付けられ、その後にアクセストークンの値が続く場合は、Kafka ブローカーはパスワードをアクセストークンとして解釈します。それ以外の場合は、Kafka ブローカーは username をクライアント ID として解釈し、password をクライアントシークレットとして解釈します。

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

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

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

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

その他のリソース

「Kafka ブローカーの OAuth 2.0 サポートの設定」

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

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

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

注記

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

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

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

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

注記

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

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

plain、tls、および external リスナーを設定できますが、OAuth 2.0 では TLS による暗号化が無効になっている plain リスナーまたは external リスナーを使用しないことが推奨されます。これは、ネットワークでのデータ漏えいの脆弱性や、トークンの盗難による不正アクセスへの脆弱性が発生するためです。

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 サポートの設定」を参照してください。

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

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

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

Kafka クライアントと Kafka ブローカー間の OAuth 2.0 セッションに Kafka セッション再認証 を使用するように、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 承認を使用したり、カスタムオーソライザーをインストールしたりして、承認を設定する場合に考慮されます。

その他のリソース

「OAuth 2.0 Kafka ブローカーの設定」
「Kafka ブローカーの OAuth 2.0 サポートの設定」
KafkaListenerAuthenticationOAuth スキーマ参照
KIP-368

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

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

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

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

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

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

注記

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

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

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

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

ここでは、Kafka セッションの開始時における Kafka クライアント、Kafka ブローカー、および承認ブローカー間の通信フローを説明および可視化します。フローは、クライアントとサーバーの設定によって異なります。

Kafka クライアントがアクセストークンをクレデンシャルとして Kafka ブローカーに送信する場合、トークンを検証する必要があります。

使用する承認サーバーや利用可能な設定オプションによっては、以下の使用が適している場合があります。

承認サーバーと通信しない、JWT の署名確認およびローカルトークンのイントロスペクションをベースとした高速なローカルトークン検証。
承認サーバーによって提供される OAuth 2.0 のイントロスペクションエンドポイント。

高速のローカルトークン検証を使用するには、トークンでの署名検証に使用される公開証明書のある JWKS エンドポイントを提供する承認サーバーが必要になります。

この他に、承認サーバーで OAuth 2.0 のイントロスペクションエンドポイントを使用することもできます。新しい Kafka ブローカー接続が確立されるたびに、ブローカーはクライアントから受け取ったアクセストークンを承認サーバーに渡し、応答を確認してトークンが有効であるかどうかを確認します。

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

以前に生成された有効期間の長いアクセストークンを使用した直接ローカルアクセス。
新しいアクセストークンの発行についての承認サーバーとの通信。

注記

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

4.4.5.1. クライアント認証フローの例

Kafka クライアントおよびブローカーが以下に設定されている場合の、Kafka セッション認証中のコミュニケーションフローを確認できます。

クライアントではクライアント ID とシークレットが使用され、ブローカーによって検証が承認サーバーに委譲される場合。
クライアントではクライアント ID およびシークレットが使用され、ブローカーによって高速のローカルトークン検証が実行される場合。
クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって検証が承認サーバーに委譲される場合。
クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって高速のローカル検証が実行される場合。

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

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

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

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

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

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

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

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

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

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

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

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

警告

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

4.4.6. OAuth 2.0 認証の設定

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

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

承認サーバーをデプロイし、AMQ Streams と統合するためにそのデプロイメントを設定します。
OAuth 2.0 を使用するよう設定された Kafka ブローカーリスナーで Kafka クラスターをデプロイまたは更新します。
OAuth 2.0 を使用するように Java ベースの Kafka クライアントを更新します。
OAuth 2.0 を使用するように Kafka コンポーネントクライアントを更新します。

4.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 デプロイメントに関する条件:

「Red Hat Single Sign-On でサポートされる構成」を確認しておく必要があります。
インストールには、system:admin などの cluster-admin ロールを持つユーザーが必要です。

手順

Red Hat Single Sign-On を OpenShift クラスターにデプロイします。
OpenShift Web コンソールでデプロイメントの進捗を確認します。
Red Hat Single Sign-On の Admin Console にログインし、AMQ Streams の OAuth 2.0 ポリシーを作成します。
ログインの詳細は、Red Hat Single Sign-On のデプロイ時に提供されます。
レルムを作成し、有効にします。
既存のマスターレルムを使用できます。
必要に応じて、レルムのセッションおよびトークンのタイムアウトを調整します。
kafka-broker というクライアントを作成します。
Settings タブで以下を設定します。
- Access Type を Confidential に設定します。
- Standard Flow Enabled を OFF に設定し、このクライアントからの Web ログインを無効にします。
- Service Accounts Enabled を ON に設定し、このクライアントが独自の名前で認証できるようにします。
続行する前に Save クリックします。
Credentials タブにある、AMQ Streams の Kafka クラスター設定で使用するシークレットを書き留めておきます。
Kafka ブローカーに接続するすべてのアプリケーションクライアントに対して、このクライアント作成手順を繰り返し行います。
新しいクライアントごとに定義を作成します。
設定では、名前をクライアント ID として使用します。

次のステップ

承認サーバーのデプロイおよび設定後に、Kafka ブローカーが OAuth 2.0 を使用するように設定します。

4.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 つのオプションがあります。

高速なローカル JWT トークン検証の設定
イントロスペクションエンドポイントを使用したトークン検証の設定

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

Kafka ブローカーリスナーの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。

KafkaListenerAuthenticationOAuth スキーマ参照
Kafka へのアクセス管理

前提条件

AMQ Streams および Kafka が稼働している必要があります。
OAuth 2.0 の承認サーバーがデプロイされている必要があります。

手順

エディターで、Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新します。
```
oc edit kafka my-cluster
```
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
    enableECDSA: "true" 11
```
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 キーの更新は、最後に更新を試みてから少なくとも指定された期間は一時停止し、通常の定期スケジュール以外でスケジュールされます。キーの更新はエクスポネンシャルバックオフ (exponential backoff) のルールに従い、jwksRefreshSeconds に到達するまで、一時停止を増やして失敗した更新の再試行を行います。デフォルト値は 1 です。
11
(任意設定): ECDSA を使用して承認サーバーで JWT トークンを署名する場合は、これを有効にする必要があります。BouncyCastle 暗号ライブラリーを使用して追加の暗号プロバイダーがインストールされます。デフォルトは false です。
例 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
```
1
承認サーバーが iss クレームを提供しない場合は、発行者チェックを行うことができません。このような場合、checkIssuer を false に設定し、validIssuerUri を指定しないようにします。デフォルトは true です。
2
承認サーバーによって aud (オーディエンス) クレームが提供され、オーディエンスチェックを強制する場合は、checkAudience を true に設定します。オーディエンスチェックによって、トークンの目的の受信者が特定されます。そのため、Kafka ブローカーによって、aud クレームに clientId のないトークンは拒否されます。デフォルトは false です。
3
承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。クライアントが独自の名前で認証される場合、サーバーによって クライアント ID が提供されることがあります。更新トークンまたはアクセストークンを取得するために、ユーザー名およびパスワードを使用してユーザーが認証される場合、サーバーによってクライアント ID の他に ユーザー名 が提供されることがあります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
4
fallbackUserNameClaim が適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producer というクライアントが存在し、producer という通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。
5
(introspectionEndpointUri を使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。
6
(introspectionEndpointUri を使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfo エンドポイントの URI をフォールバックとして設定します。userNameClaim、fallbackUserNameClaim、および fallbackUserNamePrefix 設定が userinfo エンドポイントの応答に適用されます。
7
これを false`to disable the OAUTHBEARER mechanism on the listener. At least one of PLAIN or OAUTHBEARER has to be enabled. Default is `true に設定します。
8
リスナーで PLAIN メカニズムを有効にするには、これを true に設定します。これは、すべてのプラットフォームのすべてのクライアントでサポートされます。Kafka クライアントで PLAIN メカニズムを有効にし、username および password を設定する必要があります。このメカニズムは、OAuth アクセストークンを使用するか、OAuth クライアント ID およびシークレット (クライアントクレデンシャル) を使用して、認証するために使用できます。クライアントによって、文字列 $accessToken: で始まる password が設定された場合、パスワードはサーバー上のアクセストークンとして解釈され、username はアカウントのユーザー名として解釈されます。それ以外の場合は、ユーザーはクライアント ID として解釈され、パスワードはクライアントシークレットとして解釈されます。デフォルトは false です。
9
これは、前のポイントで説明されているように、enablePlain が true に設定されている場合にクライアントクレデンシャル認証をサポートするように設定する必要があります。
10
これを JsonPath フィルタークエリーに設定すると、検証中に追加のカスタムルールを JWT アクセストークンに適用できます。アクセストークンに必要なデータが含まれていないと拒否されます。introspectionEndpointUri を使用する場合、カスタムチェックはイントロスペクションエンドポイントの応答 JSON に適用されます。
エディターを保存して終了し、ローリングアップデートの完了を待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get pod -w
```
ローリングアップデートによって、ブローカーが OAuth 2.0 認証を使用するように設定されます。

次のステップ

OAuth 2.0 を使用するように Kafka クライアントを設定します。

4.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 に対して設定されている必要があります。

手順

OAuth 2.0 サポートのあるクライアントライブラリーを Kafka クライアントの pom.xml ファイルに追加します。

<dependency>
 <groupId>io.strimzi</groupId>
 <artifactId>kafka-oauth-client</artifactId>
 <version>0.7.1.redhat-00003</version>
</dependency>

コールバックのシステムプロパティーを設定します。
以下に例を示します。
```
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
```
1
承認サーバーのトークンエンドポイントの URI です。
2
クライアント ID。承認サーバーで client を作成するときに使用される名前です。
3
承認サーバーで client を作成するときに作成されるクライアントシークレット。

Kafka クライアント設定の TLS で暗号化された接続で SASL OAUTHBEARER メカニズムを有効にします。

以下に例を示します。

props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
props.put("security.protocol", "SASL_SSL"); 1
props.put("sasl.mechanism", "OAUTHBEARER");
props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

1: この例では、TLS 接続で SASL_SSL を使用します。暗号化されていない接続では SASL_PLAINTEXT を使用します。

Kafka クライアントが Kafka ブローカーにアクセスできることを確認します。

次のステップ

OAuth 2.0 を使用するように Kafka コンポーネントを設定します。

4.4.6.4. Kafka コンポーネントの OAuth 2.0 の設定

この手順では、承認サーバーを使用して OAuth 2.0 認証を使用するように Kafka コンポーネントを設定する方法を説明します。

以下の認証を設定できます。

Kafka Connect
Kafka MirrorMaker
Kafka Bridge

この手順では、Kafka コンポーネントと承認サーバーは同じサーバーで稼働しています。

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

Kafka コンポーネントの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。

KafkaClientAuthenticationOAuth スキーマ参照

前提条件

AMQ Streams および Kafka が稼働している必要があります。
OAuth 2.0 承認サーバーがデプロイされ、Kafka ブローカーへの OAuth のアクセスが設定されている必要があります。
Kafka ブローカーが OAuth 2.0 に対して設定されている必要があります。

手順

クライアントシークレットを作成し、これを環境変数としてコンポーネントにマウントします。
以下は、Kafka Bridge の Secret を作成する例になります。
```
apiVersion: kafka.strimzi.io/v1beta2
kind: Secret
metadata:
 name: my-bridge-oauth
type: Opaque
data:
 clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 1
```
1
clientSecret キーは base64 形式である必要があります。
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
```
1
(任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
2
承認サーバーによって、JWT トークン内部で typ (タイプ) 要求が返されない場合は、checkAccessTokenType: false を適用するとトークンタイプがチェックされず次に進むことができます。デフォルトは true です。
3
不透明なトークンを使用している場合、アクセストークンが JWT トークンとして処理されないように accessTokenIsJwt: false を適用することができます。
4
(任意設定): トークンエンドポイントからトークンを要求するための scope。認証サーバーでは、クライアントによるスコープの指定が必要になることがあります。この場合では any になります。
Kafka リソースのデプロイメントに変更を適用します。
```
oc apply -f your-file
```
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get pod -w
```
ローリングアップデートでは、OAuth 2.0 認証を使用して Kafka ブローカーと対話するコンポーネントが設定されます。

4.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 が使用されるように設定することができます。

その他のリソース

4.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 から受信した、ユーザーに付与された権限のリストを基にして、権限がローカルで強制されます。

4.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 ブローカーに承認を強制するため、クライアントの要求ごとに迅速な承認決定が行われます。

4.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 オプションで設定する必要があります。

手順

Red Hat Single Sign-On の Admin Console にアクセスするか、Red Hat Single Sign-On の Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
承認サービスを使用して、クライアントのリソース、承認スコープ、ポリシー、およびパーミッションを定義します。
ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
エディターで Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新して、Kafka ブローカーで Red Hat Single Sign-On による承認が使用されるように設定します。
```
oc edit kafka my-cluster
```
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
    #...
```
1
タイプ keycloak によって Red Hat Single Sign-On の承認が有効になります。
2
Red Hat Single Sign-On トークンエンドポイントの URI。本番環境では常に HTTP を使用してください。
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 です。
エディターを保存して終了し、ローリングアップデートの完了を待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c kafka
oc get pod -w
```
ローリングアップデートによって、ブローカーが OAuth 2.0 承認を使用するように設定されます。
クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定したパーミッションを検証し、必要なアクセス権限があり、付与されるべきでないアクセス権限がないことを確認します。

第5章 AMQ Streams operator の使用

AMQ Streams の operator を使用して Kafka クラスターと Kafka トピックおよびユーザーを管理します。

5.1. Cluster Operator の使用

Cluster Operator は Kafka クラスターや他の Kafka コンポーネントをデプロイするために使用されます。

Cluster Operator は YAML インストールファイルを使用してデプロイされます。

注記

OpenShift では、Kafka Connect デプロイメントに Source2Image 機能を組み込み、追加のコネクターを加えるための便利な方法として利用できます。

その他のリソース

『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Cluster Operator のデプロイ」
「Kafka クラスターの設定」

5.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_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_CUSTOM_RESOURCE_SELECTOR

任意設定。Operator によって処理されるカスタムリソースのフィルタリングに使用されるラベルセレクターを指定します。Operator は、指定されたラベルが設定されているカスタムリソースでのみ動作します。これらのラベルのないリソースは Operator によって認識されません。ラベルセレクターは、Kafka、KafkaConnect、KafkaConnectS2I、KafkaBridge、KafkaMirrorMaker、および KafkaMirrorMaker2 リソースに適用されます。KafkaRebalance および KafkaConnector リソースは、対応する Kafka および Kafka Connect クラスターに一致するラベルがある場合にのみ操作されます。

env:
  - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR
    value: label1=value1,label2=value2

STRIMZI_KAFKA_IMAGES

必須。Kafka バージョンから、そのバージョンの Kafka ブローカーが含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。例:

2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0

これは、Kafka.spec.kafka.version プロパティーが指定され、Kafka リソースの Kafka.spec.kafka.image は指定されていない場合に使用されます。

STRIMZI_DEFAULT_KAFKA_INIT_IMAGE

任意設定で、デフォルトは registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0 です。Kafka リソースで kafka-init-image として指定されたイメージがない場合に、初期設定作業 (ラックサポート) のブローカーの前に開始される init コンテナーのデフォルトとして使用するイメージ名。

STRIMZI_KAFKA_CONNECT_IMAGES

必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。例:

2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0

これは、 KafkaConnect.spec.version プロパティーが指定され、KafkaConnect.spec.image は指定されていない場合に使用されます。

STRIMZI_KAFKA_CONNECT_S2I_IMAGES

2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0

これは、KafkaConnectS2I.spec.version プロパティーが指定され、KafkaConnectS2I.spec.image は指定されていない場合に使用されます。

STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

必須。Kafka バージョンから、そのバージョンの Kafka Mirror Maker が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの <version>=<image> ペアです。例:

2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0

これは、KafkaMirrorMaker.spec.version プロパティーが指定され、KafkaMirrorMaker.spec.image は指定されていない場合に使用されます。

STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE

任意設定で、デフォルトは registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0 です。Kafka リソースに Kafka.spec.entityOperator.topicOperator.image として指定されたイメージがない場合に、Topic Operator のデプロイ時にデフォルトとして使用するイメージ名。

STRIMZI_DEFAULT_USER_OPERATOR_IMAGE

任意設定で、デフォルトは registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0 です。Kafka リソースに Kafka.spec.entityOperator.userOperator.image として指定されたイメージがない場合に、User Operator のデプロイ時にデフォルトとして使用するイメージ名。

STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE

任意設定で、デフォルトは registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0 です。Kafka リソースで Kafka.spec.entityOperator.tlsSidecar.image として指定されたイメージがない場合に、Entity Operator の TLS サポートを提供するサイドカーコンテナーをデプロイする際にデフォルトとして使用するイメージ名。

STRIMZI_IMAGE_PULL_POLICY

任意設定。AMQ Streams の Cluster Operator によって管理されるすべての Pod のコンテナーに適用される ImagePullPolicy。有効な値は、Always、IfNotPresent、および Never です。指定のない場合、OpenShift のデフォルトが使用されます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。

STRIMZI_IMAGE_PULL_SECRETS

任意設定。Secret 名のカンマ区切りのリスト。ここで参照されるシークレットには、コンテナーイメージがプルされるコンテナーレジストリーへのクレデンシャルが含まれます。シークレットは、Cluster Operator によって作成されるすべての Pods の imagePullSecrets フィールドで使用されます。このリストを変更すると、Kafka、Kafka Connect、および Kafka MirrorMaker のすべてのクラスターのローリングアップデートが実行されます。

STRIMZI_KUBERNETES_VERSION

任意設定。API サーバーから検出された Kubernetes バージョン情報をオーバーライドします。

Kubernetes バージョンオーバーライドの設定例

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 を使用して多くのコネクターが含まれるコンテナーイメージをビルドしたり、低速なコンテナーレジストリーを使用する場合は、この値を大きくする必要があります。

5.1.1.1. ConfigMap による設定のロギング

Cluster Operator のロギングは strimzi-cluster-operator ConfigMap によって設定されます。

ロギング設定を含む ConfigMap は、Cluster Operator のインストール時に作成されます。この ConfigMap は、ファイル install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml に記述されています。Cluster Operator のロギングを設定するには、この ConfigMap のデータフィールド log4j2.properties を変更します。

ロギング設定を更新するには、050-ConfigMap-strimzi-cluster-operator.yaml ファイルを編集して以下のコマンドを実行します。

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

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

oc edit cm strimzi-cluster-operator

リロード間隔の頻度を変更するには、作成された ConfigMap の monitorInterval オプションで、秒単位の時間を設定します。

Cluster Operator のデプロイ時に ConfigMap がない場合、デフォルトのロギング値が使用されます。

Cluster Operator のデプロイ後に ConfigMap が誤って削除された場合、最後にロードされたロギング設定が使用されます。ConfigMap を新たに作成し、新しいロギング設定を読み込みます。

注記

ConfigMap から monitorInterval オプションを削除しないでください。

5.1.1.2. ネットワークポリシーによる Cluster Operator アクセスの制限

Cluster Operator は、管理するリソースと同じ namespace または別の namespace で実行できます。デフォルトでは、STRIMZI_OPERATOR_NAMESPACE 環境変数は、OpenShift Downward API を使用して Cluster Operator が稼働している namespace を検索するように設定されます。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
  #...

5.1.1.3. 定期的な調整

Cluster Operator は OpenShift クラスターから受信する必要なクラスターリソースに関するすべての通知に対応しますが、Operator が実行されていない場合や、何らかの理由で通知が受信されない場合、必要なリソースは実行中の OpenShift クラスターの状態と同期しなくなります。

フェイルオーバーを適切に処理するために、Cluster Operator によって定期的な調整プロセスが実行され、必要なリソースすべてで一貫した状態になるように、必要なリソースの状態を現在のクラスターデプロイメントと比較できます。[STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 変数を使用して、定期的な調整の時間間隔を設定できます。

5.1.2. ロールベースアクセス制御 (RBAC) のプロビジョニング

Cluster Operator が機能するには、Kafka、KafkaConnect などのリソースや ConfigMaps、Pods、Deployments、StatefulSets、および Services の管理リソースと対話するために OpenShift クラスター内でパーミッションが必要になります。このようなパーミッションは、OpenShift のロールベースアクセス制御 (RBAC) リソースに記述されます。

ServiceAccount
Role および ClusterRole
RoleBinding および ClusterRoleBinding

Cluster Operator は、ClusterRoleBinding を使用して独自の ServiceAccount で実行される他に、OpenShift リソースへのアクセスを必要とするコンポーネントの RBAC リソースを管理します。

また OpenShift には、ServiceAccount で動作するコンポーネントが、その ServiceAccount にはない他の ServiceAccounts の権限を付与しないようにするための特権昇格の保護機能も含まれています。Cluster Operator は、ClusterRoleBindings と、それが管理するリソースで必要な RoleBindings を作成できる必要があるため、Cluster Operator にも同じ権限が必要です。

5.1.2.1. 委譲された権限

Cluster Operator が必要な Kafka リソースのリソースをデプロイする場合、以下のように ServiceAccounts、RoleBindings、および 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 は、cluster-name-entity-operator という ServiceAccount を使用します。
- Topic Operator はステータス情報のある OpenShift イベントを生成し、ServiceAccount が strimzi-entity-operator という ClusterRole にバインドされるようにします。strimzi-entity-operator はこのアクセス権限を strimzi-entity-operator RoleBinding 経由で付与します。
KafkaConnect および KafkaConnectS2I リソースの 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 を使用します。

5.1.2.2. `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:
      # ...

strimzi-cluster-operator ServiceAccount が serviceAccountName として指定されている 12 行目に注目してください。

5.1.2.3. `ClusterRoles`

Cluster Operator は、必要なリソースへのアクセス権限を付与する ClusterRoles を使用して操作する必要があります。OpenShift クラスターの設定によっては、クラスター管理者が ClusterRoles を作成する必要があることがあります。

注記

クラスター管理者の権限は ClusterRoles の作成にのみ必要です。Cluster Operator はクラスター管理者アカウントで実行されません。

ClusterRoles は、 最小権限の原則に従い、Kafka、Kafka Connect、および ZooKeeper クラスターを操作するために Cluster Operator が必要とする権限のみが含まれます。最初に割り当てられた一連の権限により、Cluster Operator で StatefulSets、Deployments、Pods、および 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 KafkaConnectS2IAssemblyOperator, which needs to access and manage KafkaConnectS2I resources
      - kafkaconnects2is
      - kafkaconnects2is/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:
      # 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:
      # OpenShift S2I requirements
      - apps.openshift.io
    resources:
      - deploymentconfigs
      - deploymentconfigs/scale
      - deploymentconfigs/status
      - deploymentconfigs/finalizers
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      # OpenShift S2I requirements
      - build.openshift.io
    resources:
      - buildconfigs
      - buildconfigs/instantiate
      - builds
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      # OpenShift S2I requirements
      - image.openshift.io
    resources:
      - imagestreams
      - imagestreams/status
    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-operator の ClusterRole は、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

5.1.2.4. `ClusterRoleBindings`

Operator には ClusterRoleBindings と、ClusterRole をServiceAccount に関連付ける RoleBindings が必要です。ClusterRoleBindings は、クラスタースコープリロースが含まれる ClusterRoles に必要です。

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 は、委譲に必要な ClusterRoles にも必要です。

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

5.2. Topic Operator の使用

KafkaTopic リソースを使用してトピックを作成、編集、または削除する場合、Topic Operator によって変更が確実に Kafka クラスターで反映されます。

『OpenShift での AMQ Streams のデプロイおよびアップグレード』には、Topic Operator をデプロイする手順が記載されています。

5.2.1. Kafka トピックリソース

KafkaTopic リソースは、パーティションやレプリカの数を含む、トピックの設定に使用されます。

KafkaTopic の完全なスキーマは、「KafkaTopic スキーマ参照」で確認できます。

5.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 を識別できず、トピックは作成されません。

5.2.1.2. Kafka トピックの使用に関する推奨事項

トピックを使用する場合は、整合性を保ちます。常に KafkaTopic リソースで作業を行うか、直接 OpenShift でトピックを扱います。特定のトピックで、両方の方法を頻繁に切り替えないでください。

トピックの性質を反映するトピック名を使用し、後で名前を変更できないことに注意してください。

Kafka でトピックを作成する場合は、有効な OpenShift リソース名である名前を使用します。それ以外の場合は、Topic Operator は対応する KafkaTopic を OpenShift ルールに準じた名前で作成する必要があります。

注記

OpenShift の識別子および名前の推奨事項については、OpenShift コミュニティーの記事「Identifiers and Names」を参照してください。

5.2.1.3. Kafka トピックの命名規則

Kafka と OpenShift では、Kafka と KafkaTopic.metadata.name でのトピックの命名にそれぞれ独自の検証ルールを適用します。トピックごとに有効な名前があり、他のトピックには無効です。

spec.topicName プロパティーを使用すると、OpenShift の Kafka トピックでは無効な名前を使用して、Kafka で有効なトピックを作成できます。

spec.topicName プロパティーは Kafka の命名検証ルールを継承します。

249 文字を超える名前は使用できません。
Kafka トピックの有効な文字は ASCII 英数字、.、_、および - です。
名前を . または .. にすることはできませんが、. は exampleTopic. や .exampleTopic のように名前で使用できます。

spec.topicName は変更しないでください。

以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: topicName-1 1
  # ...

1: OpenShift では大文字は無効です。

上記は下記のように変更できません。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: name-2
  # ...

注記

Kafka Streams など一部の Kafka クライアントアプリケーションは、プログラムを使用して Kafka でトピックを作成できます。これらのトピックに、OpenShift リソース名としては無効な名前が付いている場合、Topic Operator はそれらのトピックに Kafka 名に基づく有効な metadata.name を付けます。無効な文字が置き換えられ、ハッシュが名前に追加されます。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: mytopic---c55e57fe2546a33f9e603caf57165db4072e827e
spec:
  topicName: myTopic
  # ...

5.2.2. Topic Operator のトピックストア

Topic Operator は Kafka を使用して、トピック設定をキーと値のペアとして記述するトピックメタデータを保存します。トピックストアは、Kafka トピックを使用して状態を永続化する Kafka Streams のキーバリューメカニズムを基にしています。

トピックメタデータはインメモリーでキャッシュされ、Topic Operator 内にてローカルでアクセスされます。ローカルのインメモリーキャッシュに適用される操作からの更新は、ディスク上のバックアップトピックストアに永続化されます。トピックストアは、Kafka トピックまたは OpenShift KafkaTopic カスタムリソースからの更新と継続的に同期されます。操作は、このような方法で設定されたトピックストアで迅速に処理されますが、インメモリーキャッシュがクラッシュした場合は、永続ストレージから自動的にデータが再入力されます。

5.2.2.1. 内部トピックストアトピック

内部トピックは、トピックストアでのトピックメタデータの処理をサポートします。

__strimzi_store_topic: トピックメタデータを保存するための入力トピック
__strimzi-topic-operator-kstreams-topic-store-changelog: 圧縮されたトピックストア値のログの維持

警告

これらのトピックは、Topic Operator の実行に不可欠であるため、削除しないでください。

5.2.2.2. ZooKeeper からのトピックメタデータの移行

これまでのリリースの AMQ Streams では、トピックメタデータは ZooKeeper に保存されていました。新しいプロセスによってこの要件は除外されたため、メタデータは Kafka クラスターに取り込まれ、Topic Operator の制御下となります。

AMQ Streams 1.7 にアップグレードする場合、Topic Operator によってトピックストアが制御されるようにシームレスに移行されます。メタデータは ZooKeeper から検出および移行され、古いストアは削除されます。

5.2.2.3. ZooKeeper を使用してトピックメタデータを保存する AMQ Streams バージョンへのダウングレード

トピックメタデータの保存に ZooKeeper を使用する 0.22 より前のバージョンの AMQ Streams に戻す場合でも、Cluster Operator を前のバージョンにダウングレードしてから、Kafka ブローカーおよびクライアントアプリケーションを前の Kafka バージョンにダウングレードします。

ただし、kafka-admin コマンドを使用して Kafka クラスターのブートストラップアドレスを指定し、トピックストア用に作成されたトピックを削除する必要もあります。以下に例を示します。

oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete

このコマンドは、Kafka クラスターへのアクセスに使用されるリスナーおよび認証のタイプに対応している必要があります。

Topic Operator は、Kafka のトピックの状態から ZooKeeper トピックメタデータを再構築します。

5.2.2.4. Topic Operator トピックのレプリケーションおよびスケーリング

Topic Operator によって管理されるトピックには、トピックレプリケーション係数を 3 に設定し、最低でも 2 つの In-Sync レプリカを設定することが推奨されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: my-topic
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 1 1
  replicas: 3 2
  config:
    min.insync.replicas=2 3
  #...

1: トピックのパーティション数。通常、1 つのパーティションで十分です。
2: レプリカトピックパーティションの数。現在、これを KafkaTopic リソースで変更できませんが、kafka-reassign-partitions.sh ツールを使用して変更できます。
3: メッセージが正常に書き込まれる必要があるレプリカパーティションの最小数。この条件を満たさない場合は例外が発生します。

注記

In-Sync レプリカは、プロデューサーアプリケーションの acks 設定とともに使用されます。acks 設定は、メッセージの正常受信が確認される前に、メッセージがレプリケートされなければならないフォロワーパーティションの数を決定します。Topic Operator は acks=all で実行されます。すべての In-Sync レプリカによってメッセージが確認される必要があります。

ブローカーを追加または削除して Kafka クラスターをスケーリングする場合、レプリケーション係数設定は変更されず、レプリカは自動的に再割り当てされません。ただし、kafka-reassign-partitions.sh ツールを使用してレプリケーション係数を変更し、レプリカをブローカーに手動で再割り当てすることができます。

また、AMQ Streams の Cruise Control の統合ではトピックのレプリケーション係数を変更することはできませんが、Kafka をリバランスするために生成された最適化プロポーザルには、パーティションレプリカを転送し、パーティションリーダーを変更するコマンドが含まれます。

5.2.2.5. トピック変更の処理

Topic Operator にとって解決しなければならない基本的な問題として、信頼できる唯一の情報源 (SSOT: single source of truth) がないことがあります。KafkaTopic リソースと Kafka トピックの両方とも、Topic Operator に関係なく変更される可能性があります面倒なことに、Topic Operator は KafkaTopic リソースと Kafka トピックで変更を常にリアルタイムで監視できるとは限りません。たとえば、Topic Operator が停止した場合などがこれに該当します。

これを解決するために、Topic Operator はトピックストアの各トピックに関する情報を維持します。Kafka クラスターまたは OpenShift で変更が生じると、他のシステムの状態とトピックストアの両方を確認し、すべての同期が保たれるように何を変更する必要があるかを判断します。同じことが Topic Operator の起動時に必ず実行され、また Topic Operator の稼働中にも定期的に行われます。

たとえば、Topic Operator が実行されていないときに my-topic という KafkaTopic が作成された場合を考えてみましょう。Topic Operator の起動時、トピックストアには my-topic に関する情報が含まれないため、最後に実行された後に KafkaTopic が作成されたと推測できます。Topic Operator によって my-topic に対応するトピックが作成され、さらにトピックストアに my-topic のメタデータも格納されます。

Kafka トピック設定を更新するか、KafkaTopic カスタムリソースで変更を適用する場合、Kafka クラスターの調整後にトピックストアが更新されます。

また、トピックストアは Kafka トピックでトピック設定が変更され、かつ OpenShift KafkaTopic カスタムリソースで更新される場合に、変更が矛盾しない限り、Topic Operator による管理を可能にします。たとえば、同じトピック設定キーに変更を加えることはできますが、別の値への変更のみが可能です。変更に矛盾がある場合、Kafka の設定が優先され、KafkaTopic はそれに応じて更新されます。

注記

KafkaTopic リソースを使用すると、oc delete -f KAFKA-TOPIC-CONFIG-FILE コマンドを使用してトピックを削除することもできます。これを可能にするには、Kafka リソースの spec.kafka.config で delete.topic.enable を true (デフォルト) に設定する必要があります。

その他のリソース

AMQ Streams のダウングレード
プロデューサー設定のチューニングとデータの持続性
クラスターおよびパーティション再割り当てのスケーリング
Cruise Control によるクラスターのリバランス

5.2.3. Kafka トピックの設定

KafkaTopic リソースのプロパティーを使用して Kafka トピックを設定します。

oc apply を使用すると、トピックを作成または編集できます。oc delete を使用すると、既存のトピックを削除できます。

以下に例を示します。

oc apply -f <topic-config-file>
oc delete KafkaTopic <topic-name>

この手順では、10 個のパーティションと 2 つのレプリカがあるトピックを作成する方法を説明します。

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

以下を考慮してから変更を行うことが重要になります。

Kafka は KafkaTopic リソースによる以下の変更をサポートしません。
- spec.topicName を使用したトピック名の変更
- spec.partitions を使用したパーティションサイズの減少
spec.replicas を使用して最初に指定したレプリカの数を変更することはできません。
キーのあるトピックの spec.partitions を増やすと、レコードをパーティション化する方法が変更されます。これは、トピックがセマンティックパーティションを使用するとき、特に問題になる場合があります。

前提条件

TLS 認証および暗号化を使用してリスナーで設定された稼働中の Kafka クラスターが必要です。
稼働中の Topic Operator が必要です (通常は Entity Operator でデプロイされます)。
トピックを削除する場合は、Kafka リソースの spec.kafka.config が delete.topic.enable=true (デフォルト) である必要があります。

手順

作成する KafkaTopic が含まれるファイルを準備します。
KafkaTopic の例
```
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: orders
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 10
  replicas: 2
```
ヒント
トピックを変更する場合、現行バージョンのリソースは、oc get kafkatopic orders -o yaml を使用して取得できます。
OpenShift で KafkaTopic リソースを作成します。
```
oc apply -f TOPIC-CONFIG-FILE
```

5.2.4. リソース要求および制限のある Topic Operator の設定

CPU やメモリーなどのリソースを Topic Operator に割り当て、Topic Operator が消費できるリソースの量に制限を設定できます。

前提条件

Cluster Operator が稼働している必要があります。

手順

必要に応じてエディターで Kafka クラスター設定を更新します。
```
oc edit kafka MY-CLUSTER
```

Kafka リソースの spec.entityOperator.topicOperator.resources プロパティーで、Topic Operator のリソース要求および制限を設定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # Kafka and ZooKeeper sections...
  entityOperator:
    topicOperator:
      resources:
        requests:
          cpu: "1"
          memory: 500Mi
        limits:
          cpu: "1"
          memory: 500Mi

新しい設定を適用してリソースを作成または更新します。
```
oc apply -f KAFKA-CONFIG-FILE
```

5.3. User Operator の使用

KafkaUser リソースを使用してユーザーを作成、編集、または削除する場合、User Operator によって変更が確実に Kafka クラスターで反映されます。

『OpenShift での AMQ Streams のデプロイおよびアップグレード』には、User Operator をデプロイする手順が記載されています。

スキーマの詳細は、「KafkaUser スキーマ参照」を参照してください。

Kafka へのアクセスの認証および承認

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

KafkUser を使用してユーザーを管理し、Kafka ブローカーへのアクセスをセキュアにする方法の詳細は、「Kafka ブローカーへのアクセスのセキュア化」を参照してください。

5.3.1. リソース要求および制限のある User Operator の設定

CPU やメモリーなどのリソースを User Operator に割り当て、User Operator が消費できるリソースの量に制限を設定できます。

前提条件

Cluster Operator が稼働している必要があります。

手順

必要に応じてエディターで Kafka クラスター設定を更新します。
```
oc edit kafka MY-CLUSTER
```
Kafka リソースの spec.entityOperator.userOperator.resources プロパティーで、User Operator のリソース要求および制限を設定します。
```
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # Kafka and ZooKeeper sections...
  entityOperator:
    userOperator:
      resources:
        requests:
          cpu: "1"
          memory: 500Mi
        limits:
          cpu: "1"
          memory: 500Mi
```
ファイルを保存し、エディターを終了します。Cluster Operator によって変更が自動的に適用されます。

5.4. Prometheus メトリクスを使用した Operator の監視

AMQ Streams の operator は Prometheus メトリクスを公開します。メトリクスは自動で有効になり、以下の情報が含まれます。

調整の数
operator が処理しているカスタムリソースの数
調整の期間
operator からの JVM メトリクス

この他に、Grafana ダッシュボードのサンプルが提供されます。

詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「AMQ Streams のメトリクスおよびダッシュボードの設定」を参照してください。

第6章 Kafka Bridge

本章では、AMQ Streams Kafka Bridge について概説し、その REST API を使用して AMQ Streams と対話するために役立つ情報を提供します。

ローカル環境で Kafka Bridge を試すには、本章で後述する「Kafka Bridge クイックスタート」を参照してください。
詳細な設定手順は、「Kafka Bridge クラスターの設定」を参照してください。
API ドキュメントは、「Kafka Bridge API reference」を参照してください。

6.1. Kafka Bridge の概要

AMQ Streams Kafka Bridge をインターフェースとして使用し、Kafka クラスターに対して特定タイプの HTTP リクエストを行うことができます。

6.1.1. Kafka Bridge インターフェース

Kafka Bridge では、HTTP ベースのクライアントと Kafka クラスターとの対話を可能にする RESTful インターフェースが提供されます。また、クライアントアプリケーションによる Kafka プロトコルの変換は必要なく、Web API コネクションの利点が AMQ Streams に提供されます。

API には consumers と topics の 2 つの主なリソースがあります。これらのリソースは、Kafka クラスターでコンシューマーおよびプロデューサーと対話するためにエンドポイント経由で公開され、アクセスが可能になります。リソースと関係があるのは Kafka ブリッジのみで、Kafka に直接接続されたコンシューマーやプロデューサーとは関係はありません。

6.1.1.1. HTTP リクエスト

Kafka Bridge は、以下の方法で Kafka クラスターへの HTTP リクエストをサポートします。

トピックにメッセージを送信する。
トピックからメッセージを取得する。
トピックのパーティションリストを取得する。
コンシューマーを作成および削除する。
コンシューマーをトピックにサブスクライブし、このようなトピックからメッセージを受信できるようにする。
コンシューマーがサブスクライブしているトピックの一覧を取得する。
トピックからコンシューマーのサブスクライブを解除する。
パーティションをコンシューマーに割り当てる。
コンシューマーオフセットの一覧をコミットする。
パーティションで検索して、コンシューマーが最初または最後のオフセットの位置、または指定のオフセットの位置からメッセージを受信できるようにする。

上記の方法で、JSON 応答と HTTP 応答コードのエラー処理を行います。メッセージは JSON またはバイナリー形式で送信できます。

クライアントは、ネイティブの Kafka プロトコルを使用する必要なくメッセージを生成して使用できます。

その他のリソース

リクエストおよび応答の例など、API ドキュメントを確認するには、『Strimzi Kafka Bridge Documentation 』を参照してください。

6.1.2. Kafka Bridge でサポートされるクライアント

Kafka Bridge を使用して、内部および外部の HTTP クライアントアプリケーションの両方を Kafka クラスターに統合できます。

内部クライアント: 内部クライアントとは、Kafka Bridge 自体と同じ OpenShift クラスターで実行されるコンテナーベースの HTTP クライアントのことです。内部クライアントは、ホストの Kafka Bridge および KafkaBridge のカスタムリソースで定義されたポートにアクセスできます。
外部クライアント: 外部クライアントとは、Kafka Bridge がデプロイおよび実行される OpenShift クラスター外部で実行される HTTP クライアントのことです。外部クライアントは、OpenShift Route、ロードバランサーサービス、または Ingress を使用して Kafka Bridge にアクセスできます。

HTTP 内部および外部クライアントの統合

Internal and external HTTP producers and consumers exchange data with the Kafka brokers through the Kafka Bridge

6.1.3. Kafka Bridge のセキュリティー保護

AMQ Streams には、現在 Kafka Bridge の暗号化、認証、または承認は含まれていません。そのため、外部クライアントから Kafka Bridge に送信されるリクエストは以下のようになります。

暗号化されず、HTTPS ではなく HTTP を使用する必要がある。
認証なしで送信される。

ただし、以下のような他の方法で Kafka Bridge をセキュアにできます。

Kafka Bridge にアクセスできる Pod を定義する OpenShift ネットワークポリシー。
認証または承認によるリバースプロキシー (例: OAuth2 プロキシー)。
API ゲートウェイ。
TLS 終端をともなう Ingress または OpenShift ルート。

Kafka Bridge では、Kafka Broker への接続時に TLS 暗号化と、TLS および SASL 認証がサポートされます。OpenShift クラスター内で以下を設定できます。

Kafka Bridge と Kafka クラスター間の TLS または SASL ベースの認証。
Kafka Bridge と Kafka クラスター間の TLS 暗号化接続。

詳細は、「Kafka Bridge の設定」を参照してください。

Kafka ブローカーで ACL を使用することで、Kafka Bridge を使用して消費および生成できるトピックを制限することができます。

6.1.4. OpenShift 外部の Kafka Bridge へのアクセス

デプロイメント後、AMQ Streams Kafka Bridge には同じ OpenShift クラスターで実行しているアプリケーションのみがアクセスできます。これらのアプリケーションは、kafka-bridge-name-bridge-service サービスを使用して API にアクセスします。

OpenShift クラスター外部で実行しているアプリケーションに Kafka Bridge がアクセスできるようにする場合は、以下の機能のいずれかを使用して Kafka Bridge を手動で公開できます。

LoadBalancer または NodePort タイプのサービス
Ingress リソース
OpenShift ルート

サービスを作成する場合には、selector で以下のラベルを使用して、サービスがトラフィックをルーティングする Pod を設定します。

  # ...
  selector:
    strimzi.io/cluster: kafka-bridge-name 1
    strimzi.io/kind: KafkaBridge
  #...

1: OpenShift クラスターでの Kafka Bridge カスタムリソースの名前。

6.1.5. Kafka Bridge へのリクエスト

データ形式と HTTP ヘッダーを指定し、有効なリクエストが Kafka Bridge に送信されるようにします。

6.1.5.1. コンテンツタイプヘッダー

API リクエストおよびレスポンス本文は、常に JSON としてエンコードされます。

コンシューマー操作の実行時に、POST リクエストの本文が空でない場合は、以下の Content-Type ヘッダーが含まれている必要があります。
```
Content-Type: application/vnd.kafka.v2+json
```

プロデューサー操作の実行時に、POST リクエストは、生成されたメッセージの 埋め込みデータ形式 を指定する Content-Type ヘッダーを提供する必要があります。これは、json または binary のいずれかになります。

埋め込みデータ形式	Content-Type ヘッダー
JSON	`Content-Type: application/vnd.kafka.json.v2+json`
バイナリー	`Content-Type: application/vnd.kafka.binary.v2+json`

次のセクションで説明どおり、埋め込みデータ形式はコンシューマーごとに設定されます。

POST リクエストに空のボディーがある場合は、Content-Type を設定しないでください。空のボディーを使用して、デフォルト値のコンシューマーを作成できます。

6.1.5.2. 埋め込みデータ形式

埋め込みデータ形式は、Kafka メッセージが Kafka Bridge によりプロデューサーからコンシューマーに HTTP で送信される際の形式です。サポートされる埋め込みデータ形式には、JSON とバイナリーの 2 種類があります。

/consumers/groupid エンドポイントを使用してコンシューマーを作成する場合、POST リクエスト本文で JSON またはバイナリーいずれかの埋め込みデータ形式を指定する必要があります。これは、以下の例のように format フィールドで指定します。

{
  "name": "my-consumer",
  "format": "binary", 1
...
}

1: バイナリー埋め込みデータ形式。

コンシューマーの作成時に指定する埋め込みデータ形式は、コンシューマーが消費する Kafka メッセージのデータ形式と一致する必要があります。

バイナリー埋め込みデータ形式を指定する場合は、以降のプロデューサーリクエストで、リクエスト本文にバイナリーデータが Base64 でエンコードされた文字列として含まれる必要があります。たとえば、/topics/topicname エンドポイントを使用してメッセージを送信する場合は、records.value を Base64 でエンコードする必要があります。

{
  "records": [
    {
      "key": "my-key",
      "value": "ZWR3YXJkdGhldGhyZWVsZWdnZWRjYXQ="
    },
  ]
}

プロデューサーリクエストは、埋め込みデータ形式に対応する Content-Type ヘッダーも提供する必要があります (例: Content-Type: application/vnd.kafka.binary.v2+json)。

6.1.5.3. メッセージの形式

/topics エンドポイントを使用してメッセージを送信する場合は、records パラメーターでリクエストボディーにメッセージペイロードを入力します。

records パラメーターには、以下のオプションフィールドを含めることができます。

メッセージの headers
メッセージの key
メッセージの value
宛先の partition

トピックへの POST リクエストの例

curl -X POST \
  http://localhost:8080/topics/my-topic \
  -H 'content-type: application/vnd.kafka.json.v2+json' \
  -d '{
    "records": [
        {
            "key": "my-key",
            "value": "sales-lead-0001"
            "partition": 2
            "headers": [
              {
                "key": "key1",
                "value": "QXBhY2hlIEthZmthIGlzIHRoZSBib21iIQ==" 1
              }
            ]
        },
    ]
}'

1: バイナリー形式のヘッダー値。Base64 としてエンコードされます。

6.1.5.4. Accept ヘッダー

コンシューマーを作成したら、以降のすべての GET リクエストには Accept ヘッダーが以下のような形式で含まれる必要があります。

Accept: application/vnd.kafka.EMBEDDED-DATA-FORMAT.v2+json

EMBEDDED-DATA-FORMAT は、json または binary のどちらかです。

たとえば、サブスクライブされたコンシューマーのレコードを JSON 埋め込みデータ形式で取得する場合、この Accept ヘッダーが含まれるようにします。

Accept: application/vnd.kafka.json.v2+json

6.1.6. CORS

CORS (Cross-Origin Resource Sharing) を使用すると、Kafka Bridge HTTP の設定で Kafka クラスターにアクセスするために許可されるメソッドおよび元の URL を指定できます。

Kafka Bridge の CORS 設定例

# ...
cors:
  allowedOrigins: "https://strimzi.io"
  allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
  # ...

CORS では、異なるドメイン上のオリジンソース間での シンプルな リクエストおよび プリフライト リクエストが可能です。

シンプルなリクエストは、GET、HEAD、および POST メソッドを使用する標準のリクエストに適しています。

プリフライトリクエストは、実際のリクエストが安全に送信できることを確認する最初のチェックとして HTTP OPTIONS リクエストを送信します。確認時に、実際のリクエストが送信されます。プリフライトリクエストは、PUT および DELETE などのより安全な手段が必要な方法や標準でないヘッダーを使用する方法に適しています。

すべての要求には、HTTP リクエストのソースであるヘッダーの Origin 値が必要です。

6.1.6.1. シンプルなリクエスト

たとえば、このシンプルなリクエストヘッダーは、オリジンを https://strimzi.io と指定します。

Origin: https://strimzi.io

ヘッダー情報がリクエストに追加されます。

curl -v -X GET HTTP-ADDRESS/bridge-consumer/records \
-H 'Origin: https://strimzi.io'\
-H 'content-type: application/vnd.kafka.v2+json'

Kafka Bridge からの応答として、Access-Control-Allow-Origin ヘッダーが返されます。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: * 1

1: 返されたアスタリスク (*) は、どのドメインでもリソースにアクセスできることを意味します。

6.1.6.2. プリフライトリクエスト

最初のプリフライトリクエストは、OPTIONS メソッドを使用して Kafka Bridge に送信されます。HTTP OPTIONS リクエストはヘッダー情報を送信し、Kafka Bridge が実際のリクエストを許可することを確認します。

ここでは、プリフライトリクエストは https://strimzi.io からの POST リクエストが有効であることを確認します。

OPTIONS /my-group/instances/my-user/subscription HTTP/1.1
Origin: https://strimzi.io
Access-Control-Request-Method: POST 1
Access-Control-Request-Headers: Content-Type 2

1: 実際のリクエストは POST リクエストであると Kafka Bridge が警告されます。
2: 実際のリクエストは Content-Type ヘッダーで送信されます。

プリフライトリクエストのヘッダー情報に OPTIONS が追加されます。

curl -v -X OPTIONS -H 'Origin: https://strimzi.io' \
-H 'Access-Control-Request-Method: POST' \
-H 'content-type: application/vnd.kafka.v2+json'

Kafka Bridge は最初のリクエストに応答し、リクエストが受け入れられることを確認します。応答ヘッダーは、許可されるオリジン、メソッド、およびヘッダーを返します。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://strimzi.io
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS,PATCH
Access-Control-Allow-Headers: content-type

オリジンまたはメソッドが拒否されると、エラーメッセージが返されます。

プリフライトリクエストで確認されたため、実際のリクエストには Access-Control-Request-Method ヘッダーは必要ありませんが、オリジンのヘッダーが必要です。

curl -v -X POST HTTP-ADDRESS/topics/bridge-topic \
-H 'Origin: https://strimzi.io' \
-H 'content-type: application/vnd.kafka.v2+json'

応答は、送信元 URL が許可されることを示します。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://strimzi.io

その他のリソース

Fetch CORS 仕様

6.1.7. Kafka Bridge API リソース

リクエストやレスポンスの例などを含む REST API エンドポイントおよび説明の完全リストは、「Kafka Bridge API reference」を参照してください。

6.1.8. Kafka Bridge デプロイメント

Cluster Operator を使用して、Kafka Bridge を OpenShift クラスターにデプロイします。

Kafka Bridge をデプロイすると、Cluster Operator により OpenShift クラスターに Kafka Bridge オブジェクトが作成されます。オブジェクトには、デプロイメント、サービス、および Pod が含まれ、それぞれ Kafka Bridge のカスタムリソースに付与された名前が付けられます。

その他のリソース

デプロイメントの手順は『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka Bridge を OpenShift クラスターへデプロイ」を参照してください。
Kafka Bridge の設定に関する詳細は、「Kafka Bridge クラスターの設定」を参照してください。
KafkaBridge リソースのホストおよびポートの設定に関する詳細は、「Kafka Bridge の設定」を参照してください。
外部クライアントの統合に関する詳細は、「OpenShift 外部の Kafka Bridge へのアクセス」を参照してください。

6.2. Kafka Bridge クイックスタート

このクイックスタートを使用して、ローカルの開発環境で AMQ Streams の Kafka Bridge を試すことができます。以下の方法について説明します。

OpenShift クラスターに Kafka Bridge をデプロイする。
ポート転送を使用して Kafka Bridge サービスをローカルマシンに公開する。
Kafka クラスターのトピックおよびパーティションへのメッセージを生成する。
Kafka Bridge コンシューマーを作成する。
基本的なコンシューマー操作を実行する (たとえば、コンシューマーをトピックにサブスクライブする、生成したメッセージを取得するなど)。

このクイックスタートでは、HTTP リクエストはターミナルにコピーおよび貼り付けできる curl コマンドを使用します。OpenShift クラスターへのアクセスが必要になります。ローカルの OpenShift クラスターを実行および管理するには、Minikube、CodeReady Containers、または MiniShift などのツールを使用します。

前提条件を確認し、本章に指定されている順序でタスクを行うようにしてください。

データ形式について

このクイックスタートでは、バイナリーではなく JSON 形式でメッセージを生成および消費します。リクエスト例で使用されるデータ形式および HTTP ヘッダーの詳細は、「Kafka Bridge へのリクエスト」を参照してください。

クイックスタートの前提条件

ローカルまたはリモート OpenShift クラスターにアクセスできるクラスター管理者権限が必要です。
AMQ Streams がインストールされている必要があります。
Cluster Operator によってデプロイされた稼働中の Kafka クラスターが OpenShift namespace に必要です。
Entity Operator がデプロイされ、Kafka クラスターの一部として稼働している必要があります。

6.2.1. OpenShift クラスターへの Kafka Bridge のデプロイメント

AMQ Streams には、AMQ Streams Kafka Bridge の設定を指定する YAML サンプルが含まれています。このファイルに最小限の変更を加え、Kafka Bridge のインスタンスを OpenShift クラスターにデプロイします。

手順

examples/bridge/kafka-bridge.yaml ファイルを編集します。
```
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: quickstart 1
spec:
  replicas: 1
  bootstrapServers: <cluster-name>-kafka-bootstrap:9092 2
  http:
    port: 8080
```
1
Kafka Bridge のデプロイ時に、デプロイメントの名前およびその他の関連するリソースの名前に -bridge が追加されます。この例では、Kafka Bridge デプロイメントには quickstart-bridge という名前が付けられ、付随する Kafka Bridge サービスには quickstart-bridge-service という名前が付けられます。
2
bootstrapServers プロパティーで、Kafka クラスターの名前を <cluster-name> として入力します。
Kafka Bridge を OpenShift クラスターにデプロイします。
```
oc apply -f examples/bridge/kafka-bridge.yaml
```
quickstart-bridge デプロイメント、サービス、および他の関連リソースが OpenShift クラスターに作成されます。

Kafka Bridge が正常にデプロイされたことを確認します。

oc get deployments

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
quickstart-bridge                  1/1     1            1          34m
my-cluster-connect                 1/1     1            1          24h
my-cluster-entity-operator         1/1     1            1          24h
#...

次のステップ

Kafka Bridge を OpenShift クラスターにデプロイしたら、Kafka Bridge サービスをローカルマシンに公開します。

その他のリソース

Kafka Bridge の設定に関する詳細は、「Kafka Bridge クラスターの設定」を参照してください。

6.2.2. Kafka Bridge サービスのローカルマシンへの公開

次に、ポート転送を使用して AMQ Streams の Kafka Bridge サービスを http://localhost:8080 上でローカルマシンに公開します。

注記

ポート転送は、開発およびテストの目的でのみ適切です。

手順

OpenShift クラスターの Pod の名前をリストします。

oc get pods -o name

pod/kafka-consumer
# ...
pod/quickstart-bridge-589d78784d-9jcnr
pod/strimzi-cluster-operator-76bcf9bc76-8dnfm

ポート 8080 で quickstart-bridge Pod に接続します。
```
oc port-forward pod/quickstart-bridge-589d78784d-9jcnr 8080:8080 &
```
注記
ローカルマシンのポート 8080 がすでに使用中の場合は、代わりの HTTP ポート (8008 など) を使用します。

これで、API リクエストがローカルマシンのポート 8080 から Kafka Bridge Pod のポート 8080 に転送されるようになります。

6.2.3. トピックおよびパーティションへのメッセージの作成

次に、topics エンドポイントを使用して、トピックへのメッセージを JSON 形式で生成します。以下に示すように、メッセージの宛先パーティションをリクエスト本文に指定できます。partitions エンドポイントは、全メッセージの単一の宛先パーティションをパスパラメーターとして指定する代替方法を提供します。

手順

テキストエディターを使用して、3 つのパーティションがある Kafka トピックの YAML 定義を作成します。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: bridge-quickstart-topic
  labels:
    strimzi.io/cluster: <kafka-cluster-name> 1
spec:
  partitions: 3 2
  replicas: 1
  config:
    retention.ms: 7200000
    segment.bytes: 1073741824

1: Kafka Bridge がデプロイされる Kafka クラスターの名前。
2: トピックのパーティション数。

ファイルを bridge-quickstart-topic.yaml として examples/topic ディレクトリーに保存します。
OpenShift クラスターにトピックを作成します。
```
oc apply -f examples/topic/bridge-quickstart-topic.yaml
```
Kafka Bridge を使用して、作成したトピックに 3 つのメッセージを生成します。
```
curl -X POST \
  http://localhost:8080/topics/bridge-quickstart-topic \
  -H 'content-type: application/vnd.kafka.json.v2+json' \
  -d '{
    "records": [
        {
            "key": "my-key",
            "value": "sales-lead-0001"
        },
        {
            "value": "sales-lead-0002",
            "partition": 2
        },
        {
            "value": "sales-lead-0003"
        }
    ]
}'
```
- sales-lead-0001 は、キーのハッシュに基づいてパーティションに送信されます。
- sales-lead-0002 は、パーティション 2 に直接送信されます。
- sales-lead-0003 は、ラウンドロビン方式を使用して bridge-quickstart-topic トピックのパーティションに送信されます。
リクエストが正常に行われると、Kafka Bridge は offsets アレイを 200 コードと application/vnd.kafka.v2+json の content-type ヘッダーとともに返します。各メッセージで、offsets アレイは以下を記述します。
- メッセージが送信されたパーティション。
- パーティションの現在のメッセージオフセット。
  応答の例
```
#...
{
  "offsets":[
    {
      "partition":0,
      "offset":0
    },
    {
      "partition":2,
      "offset":0
    },
    {
      "partition":0,
      "offset":1
    }
  ]
}
```

次のステップ

トピックおよびパーティションへのメッセージを作成したら、Kafka Bridge コンシューマーを作成します。

その他のリソース

API リファレンスドキュメントの「POST /topics/{topicname}」
API リファレンスドキュメントの「POST /topics/{topicname}/partitions/{partitionid}」

6.2.4. Kafka Bridge コンシューマーの作成

Kafka クラスターで何らかのコンシューマー操作を実行するには、まず consumers エンドポイントを使用してコンシューマーを作成する必要があります。コンシューマーは Kafka Bridge コンシューマー と呼ばれます。

手順

bridge-quickstart-consumer-group という名前の新しいコンシューマーグループに Kafka Bridge コンシューマーを作成します。
```
curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group \
  -H 'content-type: application/vnd.kafka.v2+json' \
  -d '{
    "name": "bridge-quickstart-consumer",
    "auto.offset.reset": "earliest",
    "format": "json",
    "enable.auto.commit": false,
    "fetch.min.bytes": 512,
    "consumer.request.timeout.ms": 30000
  }'
```
- コンシューマーには bridge-quickstart-consumer という名前を付け、埋め込みデータ形式は json として設定します。
- 一部の基本的な設定が定義されます。
- コンシューマーはログへのオフセットに自動でコミットしません。これは、enable.auto.commit が false に設定されているからです。このクイックスタートでは、オフセットを跡で手作業でコミットします。
  リクエストが正常に行われると、Kafka Bridge はレスポンス本文でコンシューマー ID (instance_id) とベース URL (base_uri) を 200 コードとともに返します。
  応答の例
```
#...
{
  "instance_id": "bridge-quickstart-consumer",
  "base_uri":"http://<bridge-name>-bridge-service:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer"
}
```
ベース URL (base_uri) をコピーし、このクイックスタートの他のコンシューマー操作で使用します。

次のステップ

上記で作成した Kafka Bridge コンシューマーをトピックにサブスクライブできます<

AMQ Streams on OpenShift の使用

OpenShift Container Platform 上で AMQ Streams 1.7 を使用

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

第1章 AMQ Streams の概要

1.1. Kafka の機能

1.2. Kafka のユースケース

1.3. AMQ Streams による Kafka のサポート

1.4. AMQ Streams の Operator

Operator

1.4.1. Cluster Operator

1.4.2. Topic Operator

1.4.3. User Operator

1.5. AMQ Streams のカスタムリソース

1.5.1. AMQ Streams カスタムリソースの例

1.6. リスナーの設定

1.7. 本書の表記慣例

第2章 デプロイメント設定

2.1. Kafka クラスターの設定

2.1.1. Kafka の設定

2.1.2. Entity Operator の設定

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

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

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

2.1.3. Kafka および ZooKeeper のストレージタイプ

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

2.1.3.1.1. ファイルシステム

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

2.1.3.2. 一時ストレージ

2.1.3.2.1. ログディレクトリー

2.1.3.3. 永続ストレージ

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

2.1.3.3.2. Persistent Volume Claim (永続ボリューム要求、PVC) の命名

2.1.3.3.3. ログディレクトリー

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

2.1.3.5. JBOD ストレージの概要

2.1.3.5.1. JBOD の設定

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

2.1.3.5.3. ログディレクトリー

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

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

2.1.4. クラスターのスケーリング

2.1.4.1. Kafka クラスターのスケーリング

2.1.4.1.1. ブローカーのクラスターへの追加

2.1.4.1.2. クラスターからのブローカーの削除

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

2.1.4.2.1. 再割り当て JSON ファイル

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

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

2.1.4.4. 手動による再割り当て JSON ファイルの作成

2.1.4.5. 再割り当てスロットル

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

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

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

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

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

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

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

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

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

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

2.2. Kafka Connect/S2I クラスターの設定

2.2.1. Kafka Connect の設定

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

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

2.2.4. Kafka コネクターの再起動の実行

2.2.5. Kafka コネクタータスクの再起動の実行

2.2.6. S2I を使用する Kafka Connect から Kafka Connect への移行

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

2.2.8. Kafka Connect (S2I) クラスターリソースの一覧

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

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

2.3.1. Kafka MirrorMaker の設定

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

2.4. Kafka MirrorMaker 2.0 クラスターの設定

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

2.4.2. クラスターの設定

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

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

2.4.2.3. トピック設定の同期

2.4.2.4. データの整合性

第2章デプロイメント設定

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

第3章外部リスナーの設定