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

本章では、サポートされるデプロイメントの異なる側面を設定する方法について説明します。

Kafka クラスター
Kafka Connect クラスター
Source2Image がサポートされる Kafka Connect クラスター
Kafka Mirror Maker
Kafka Bridge
OAuth 2.0 のトークンベースの認証
OAuth 2.0 のトークンベースの承認

3.1. Kafka クラスターの設定
リンクのコピー

Kafka リソースの完全なスキーマは「Kafka スキーマ参照」に記載されています。指定の Kafka リソースに適用されたすべてのラベルは、Kafka クラスターを構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。

3.1.1. Kafka YAML の設定例
リンクのコピー

Kafka デプロイメントで利用可能な設定オプションを理解するには、ここに提供されるサンプル YAML ファイルを参照してください。

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    replicas: 3 
    version: 1.4 
    resources: 
      requests:
        memory: 64Gi
        cpu: "8"
      limits: 
        memory: 64Gi
        cpu: "12"
    jvmOptions: 
      -Xms: 8192m
      -Xmx: 8192m
    listeners: 
      tls:
        authentication:
          type: tls
      external: 
        type: route
        authentication:
          type: tls
        configuration:
          brokerCertChainAndKey: 
            secretName: my-secret
            certificate: my-certificate.crt
            key: my-key.key
    authorization: 
      type: simple
    config: 
      auto.create.topics.enable: "false"
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
    storage: 
      type: persistent-claim 
      size: 10000Gi 
    rack: 
      topologyKey: failure-domain.beta.kubernetes.io/zone
    metrics: 
      lowercaseOutputName: true
      rules: 
      # Special cases and very specific rules
      - pattern : kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
        name: kafka_server_$1_$2
        type: GAUGE
        labels:
          clientId: "$3"
          topic: "$4"
          partition: "$5"
        # ...
  zookeeper: 
    replicas: 3
    resources:
      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 8Gi
        cpu: "2"
    jvmOptions:
      -Xms: 4096m
      -Xmx: 4096m
    storage:
      type: persistent-claim
      size: 1000Gi
    metrics:
      # ...
  entityOperator: 
    topicOperator:
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
    userOperator:
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
  kafkaExporter: 
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    replicas: 3


    version: 1.4


    resources:


      requests:
        memory: 64Gi
        cpu: "8"
      limits:


        memory: 64Gi
        cpu: "12"
    jvmOptions:


      -Xms: 8192m
      -Xmx: 8192m
    listeners:


      tls:
        authentication:


          type: tls
      external:


        type: route
        authentication:
          type: tls
        configuration:
          brokerCertChainAndKey:


            secretName: my-secret
            certificate: my-certificate.crt
            key: my-key.key
    authorization:


      type: simple
    config:


      auto.create.topics.enable: "false"
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
    storage:


      type: persistent-claim


      size: 10000Gi


    rack:


      topologyKey: failure-domain.beta.kubernetes.io/zone
    metrics:


      lowercaseOutputName: true
      rules:


      # Special cases and very specific rules
      - pattern : kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
        name: kafka_server_$1_$2
        type: GAUGE
        labels:
          clientId: "$3"
          topic: "$4"
          partition: "$5"
        # ...
  zookeeper:


    replicas: 3
    resources:
      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 8Gi
        cpu: "2"
    jvmOptions:
      -Xms: 4096m
      -Xmx: 4096m
    storage:
      type: persistent-claim
      size: 1000Gi
    metrics:
      # ...
  entityOperator:


    topicOperator:
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
    userOperator:
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
  kafkaExporter:


    # ...

Copy to Clipboard

Toggle word wrap

1: レプリカは、ブローカーノードの数を指定します。
2: アップグレード手順にしたがうと変更できる Kafka バージョン。
3: リソース要求は、指定のコンテナーに対して予約するリソースを指定します。
4: リソースの制限は、コンテナーによって消費可能な最大リソースを指定します。
5: JVM オプションは、JVM の最小 (-Xms) および最大 (-Xmx) メモリー割り当てを指定できます。
6: リスナーは、ブートストラップアドレスでクライアントが Kafka クラスターに接続する方法を設定します。リスナーは、plain (暗号化なし)、tls、または external として設定されます。
7: リスナーの認証メカニズムは各リスナーに対して設定でき、相互 TLS または SCRAM-SHA として指定できます。
8: 外部リスナー設定は、route、loadbalancer、または nodeport からなど、Kafka クラスターが外部の OpenShift に公開される方法を指定します。
9: 外部の認証局によって管理される Kafka リスナー証明書の任意設定。brokerCertChainAndKey プロパティーは、サーバー証明書および秘密鍵を保持する Secret を指定します。Kafka リスナー証明書も TLS リスナーに対して設定できます。
10: 承認は SimpleAclAuthorizer Kafka プラグインを使用して Kafka ブローカーで simple 承認を有効にします。
11: 設定によって、ブローカー設定が指定されます。標準の Apache Kafka 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。
12: ストレージは、ephemeral、persistent-claim、または jbod として設定されます。
13: 永続ボリュームのストレージサイズが増やされることがあり、追加のボリュームが JBOD ストレージに追加されることがあります。
14: 永続ストレージには、動的ボリュームプロビジョニングのためのストレージ id や class などの追加の設定オプションがあります。
15: ラックアウェアネスは、異なるラック全体でレプリカを分散ために設定されます。topology キーはクラスターノードのラベルと一致する必要があります。
16: Prometheus と使用する Kafka メトリクスの設定。
17: JMX Exporter でメトリクスを Grafana ダッシュボードにエクスポートする Kafka ルール。AMQ Streams によって提供されるルールのセットは Kafka リソース設定にコピーされることがあります。
18: Kafka 設定と似たプロパティーが含まれる、ZooKeeper 固有の設定。
19: Topic Operator および User Operator の設定を指定する、Entity Operator 設定。
20: データを Prometheus メトリクスとして公開するために使用される Kafka Exporter 設定。

3.1.2. データストレージに関する留意事項
リンクのコピー

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

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

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

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

注記

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

3.1.2.1. ファイルシステム
リンクのコピー

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

3.1.2.2. Apache Kafka および ZooKeeper ストレージ
リンクのコピー

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

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

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

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

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

注記

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

3.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 スキーマ参照」を参照してください。

3.1.3.1. 一時ストレージ
リンクのコピー

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

重要

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

一時ストレージの例

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

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

Copy to Clipboard

Toggle word wrap

3.1.3.1.1. ログディレクトリー
リンクのコピー

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

/var/lib/kafka/data/kafka-log_idx_: idx は、Kafka ブローカー Pod インデックスです。例: /var/lib/kafka/data/kafka-log0

永続ストレージは 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: 1000Gi
# ...

Copy to Clipboard

Toggle word wrap

以下の例は、ストレージクラスの使用例を示しています。

特定のストレージクラスを指定する永続ストレージ設定の例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

最後に、selector を使用して特定のラベルが付いた永続ボリュームを選択し、SSD などの必要な機能を提供できます。

セレクターを指定する永続ストレージ設定の例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

3.1.3.2.1. ストレージクラスのオーバーライド
リンクのコピー

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

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

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

apiVersion: kafka.strimzi.io/v1beta1
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
  # ...

apiVersion: kafka.strimzi.io/v1beta1
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
  # ...

Copy to Clipboard

Toggle word wrap

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

broker 0 の永続ボリュームでは my-storage-class-zone-1a が使用されます。
broker 1 の永続ボリュームでは my-storage-class-zone-1b が使用されます。
broker 2 の永続ボリュームでは my-storage-class-zone-1c が使用されます。

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

3.1.3.2.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 のデータを保存するために使用されるボリュームの永続ボリューム要求です。

3.1.3.2.3. ログディレクトリー
リンクのコピー

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

/var/lib/kafka/data/kafka-log_idx_: idx は、Kafka ブローカー Pod インデックスです。例: /var/lib/kafka/data/kafka-log0

3.1.3.3. 永続ボリュームのサイズ変更
リンクのコピー

既存の 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/v1beta1 kind: Kafka metadata: name: my-cluster spec: kafka: # ... storage: type: persistent-claim size: 2000Gi class: my-storage-class # ... zookeeper: # ...
  Copy to Clipboard Toggle word wrap
リソースを作成または更新します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
OpenShift では、Cluster Operator からの要求に応じて、選択された永続ボリュームの容量が増やされます。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。

その他のリソース

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

3.1.3.4. JBOD ストレージの概要
リンクのコピー

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

3.1.3.4.2. JBOD および永続ボリューム要求 (PVC)
リンクのコピー

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

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

3.1.3.4.3. ログディレクトリー
リンクのコピー

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

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

3.1.3.5. JBOD ストレージへのボリュームの追加
リンクのコピー

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

注記

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

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
JBOD ストレージのある Kafka クラスター。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てします。

その他のリソース

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

3.1.3.6. 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/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.1.4. Kafka ブローカーレプリカ
リンクのコピー

Kafka クラスターは多くのブローカーを使って実行できます。Kafka.spec.kafka.replicas の Kafka クラスターに使用されるブローカーの数を設定できます。クラスターに最適なブローカー数は、特定のユースケースに基づいて決定する必要があります。

3.1.4.1. ブローカーノード数の設定
リンクのコピー

この手順では、新規クラスターの Kafka ブローカーノードの数を設定する方法を説明します。これは、パーティションのない新しいクラスターのみに適用できます。クラスターにトピックがすでに定義されている場合は、「クラスターのスケーリング」を参照してください。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
トピックが定義されていない Kafka クラスター。

手順

Kafka リソースの replicas プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    replicas: 3
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    replicas: 3
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

クラスターにトピックがすでに定義されている場合は、「クラスターのスケーリング」を参照してください。

3.1.5. Kafka ブローカーの設定
リンクのコピー

AMQ Streams では、Kafka クラスターの Kafka ブローカーの設定をカスタマイズできます。Apache Kafka ドキュメントの「Broker Configs」セクションに記載されているほとんどのオプションを指定および設定できます。以下に関係する設定オプションは設定できません。

セキュリティー (暗号化、認証、および承認)
リスナーの設定
Broker ID の設定
ログデータディレクトリーの設定
ブローカー間の通信
ZooKeeper の接続

これらのオプションは AMQ Streams によって自動的に設定されます。

3.1.5.1. Kafka ブローカーの設定
リンクのコピー

Kafka.spec.kafka の config プロパティーには Kafka ブローカー設定オプションがキーとして含まれ、それらの値は以下の JSON タイプの 1 つになります。

文字列
Number
ブール値

AMQ Streams によって直接管理されるオプション以外は、Apache Kafka ドキュメントの「Broker Configs」セクションにあるすべてのオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて変更できません。

listeners
advertised.
broker.
listener.
host.name
port
inter.broker.listener.name
sasl.
ssl.
security.
password.
principal.builder.class
log.dir
zookeeper.connect
zookeeper.set.acl
authorizer.
super.user

制限されたオプションが config プロパティーに指定された場合、そのオプションは無視され、Cluster Operator のログファイルに警告メッセージが出力されます。サポートされるその他すべてのオプションは Kafka に渡されます。

Kafka ブローカー設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      num.partitions: 1
      num.recovery.threads.per.data.dir: 1
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
      log.retention.hours: 168
      log.segment.bytes: 1073741824
      log.retention.check.interval.ms: 300000
      num.network.threads: 3
      num.io.threads: 8
      socket.send.buffer.bytes: 102400
      socket.receive.buffer.bytes: 102400
      socket.request.max.bytes: 104857600
      group.initial.rebalance.delay.ms: 0
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      num.partitions: 1
      num.recovery.threads.per.data.dir: 1
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
      log.retention.hours: 168
      log.segment.bytes: 1073741824
      log.retention.check.interval.ms: 300000
      num.network.threads: 3
      num.io.threads: 8
      socket.send.buffer.bytes: 102400
      socket.receive.buffer.bytes: 102400
      socket.request.max.bytes: 104857600
      group.initial.rebalance.delay.ms: 0
    # ...

Copy to Clipboard

Toggle word wrap

3.1.5.2. Kafka ブローカーの設定
リンクのコピー

既存の Kafka ブローカーを設定するか、指定した設定で新しい Kafka ブローカーを作成します。

前提条件

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

手順

クラスターデプロイメントを指定する Kafka リソースが含まれる YAML 設定ファイルを開きます。

Kafka リソースの spec.kafka.config プロパティーで、Kafka 設定を 1 つまたは複数入力します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    config:
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    config:
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

新しい設定を適用してリソースを作成または更新します。
oc apply を使用します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap
kafka.yaml は、設定するリソースの YAML 設定ファイルに置き換えます (例: kafka-persistent.yaml)。

3.1.6. Kafka ブローカーリスナー
リンクのコピー

Kafka ブローカーで有効なリスナーを設定できます。以下のタイプのリスナーがサポートされます。

ポート 9092 のプレーンリスナー (TLS による暗号化なし)
ポート 9093 の TLS リスナー (TLS による暗号化を使用)
OpenShift の外部からアクセスするためのポート 9094 の外部リスナー

OAuth 2.0

OAuth 2.0 トークンベースの認証を使用している場合、承認サーバーに接続するようにリスナーを設定できます。詳細は、「OAuth 2.0 トークンベース認証の使用」を参照してください。

リスナー証明書

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

3.1.6.1. Kafka リスナー
リンクのコピー

Kafka.spec.kafka リソースの listeners プロパティーを使用して Kafka ブローカーリスナーを設定できます。listeners プロパティーには 3 つのサブプロパティーが含まれます。

plain
tls
external

各リスナーは、listeners オブジェクトに指定のプロパティーがある場合にのみ定義されます。

すべてのリスナーが有効な listeners プロパティーの例

# ...
listeners:
  plain: {}
  tls: {}
  external:
    type: loadbalancer
# ...

# ...
listeners:
  plain: {}
  tls: {}
  external:
    type: loadbalancer
# ...

Copy to Clipboard

Toggle word wrap

プレーンリスナーのみが有効な listeners プロパティーの例

# ...
listeners:
  plain: {}
# ...

# ...
listeners:
  plain: {}
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.2. Kafka リスナーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

認証のないプレーン (暗号化されていない) リスナーの設定例:

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      plain: {}
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      plain: {}
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.1.6.3. リスナー認証
リンクのコピー

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

相互 TLS 認証 (TLS による暗号化のリスナーのみ)
SCRAM-SHA 認証

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

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

3.1.6.3.1. リスナーの認証設定
リンクのコピー

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

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

リスナー認証設定の例

# ...
listeners:
  plain:
    authentication:
      type: scram-sha-512
  tls:
    authentication:
      type: tls
  external:
    type: loadbalancer
    tls: true
    authentication:
      type: tls
# ...

# ...
listeners:
  plain:
    authentication:
      type: scram-sha-512
  tls:
    authentication:
      type: tls
  external:
    type: loadbalancer
    tls: true
    authentication:
      type: tls
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.3.2. 相互 TLS 認証
リンクのコピー

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

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

注記

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

3.1.6.3.2.1. クライアントに相互 TLS 認証を使用する場合
リンクのコピー

以下の場合、Kafka クライアントの認証に相互 TLS 認証が推奨されます。

相互 TLS 認証を使用した認証がクライアントでサポートされる場合。
パスワードの代わりに TLS 証明書を使用する必要がある場合。
期限切れの証明書を使用しないように、クライアントアプリケーションを定期的に再設定および再起動できる場合。

3.1.6.3.3. SCRAM-SHA 認証
リンクのコピー

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

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

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

3.1.6.3.3.1. サポートされる SCRAM クレデンシャル
リンクのコピー

AMQ Streams では SCRAM-SHA-512 のみがサポートされます。KafkaUser.spec.authentication.type を scram-sha-512 に設定すると、User Operator によって、大文字と小文字の ASCII 文字と数字で構成された無作為の 12 文字のパスワードが生成されます。

3.1.6.3.3.2. クライアントに SCRAM-SHA 認証を使用する場合
リンクのコピー

以下の場合、Kafka クライアントの認証に SCRAM-SHA が推奨されます。

SCRAM-SHA-512 を使用した認証がクライアントでサポートされる場合。
TLS 証明書の代わりにパスワードを使用する必要がある場合。
暗号化されていない通信に認証が必要な場合。

3.1.6.4. 外部リスナー
リンクのコピー

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

その他のリソース

Accessing Apache Kafka in Strimzi

3.1.6.4.1. 外部リスナーでアドバタイズされたアドレスのカスタマイズ
リンクのコピー

デフォルトでは、AMQ Streams は Kafka クラスターがそのクライアントにアドバタイズするホスト名とポートを自動的に決定しようとします。AMQ Streams が稼働しているインフラストラクチャーでは Kafka にアクセスできる正しいホスト名やポートを提供しない可能性があるため、デフォルトの動作はすべての状況に適しているわけではありません。外部リスナーの overrides プロパティーで、アドバタイズされたホスト名およびポートをカスタマイズできます。その後、TLS ホスト名の検証で使用できるようにするため、AMQ Streams では Kafka ブローカーでアドバタイズされたアドレスが自動的に設定され、ブローカー証明書に追加されます。アドバタイズされたホストおよびポートのオーバーライドは、すべてのタイプの外部リスナーで利用できます。

アドバタイズされたアドレスのオーバーライドが設定された外部リスナーの例

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      brokers:
      - broker: 0
        advertisedHost: example.hostname.0
        advertisedPort: 12340
      - broker: 1
        advertisedHost: example.hostname.1
        advertisedPort: 12341
      - broker: 2
        advertisedHost: example.hostname.2
        advertisedPort: 12342
# ...

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      brokers:
      - broker: 0
        advertisedHost: example.hostname.0
        advertisedPort: 12340
      - broker: 1
        advertisedHost: example.hostname.1
        advertisedPort: 12341
      - broker: 2
        advertisedHost: example.hostname.2
        advertisedPort: 12342
# ...

Copy to Clipboard

Toggle word wrap

さらに、ブートストラップサービスの名前を指定することもできます。この名前はブローカー証明書に追加され、TLS ホスト名の検証に使用できます。すべてのタイプの外部リスナーで、ブートストラップアドレスを追加できます。

追加のブートストラップアドレスが設定された外部リスナーの例

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      bootstrap:
        address: example.hostname
# ...

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      bootstrap:
        address: example.hostname
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.4.2. ルート外部リスナー
リンクのコピー

タイプ route の外部リスナーは、OpenShift のRoutes および HAProxy ルーターを使用して Kafka を公開します。

注記

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

3.1.6.4.2.1. OpenShift Routes を使用した Kafka の公開
リンクのコピー

OpenShift Routes および HAProxy ルーターを使用して Kafka を公開する場合、各 Kafka ブローカー Pod に専用の Route が作成されます。追加の Route が作成され、Kafka ブートストラップアドレスとして提供されます。これらの Routes を使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。

TLS による暗号化は常に Routes と使用されます。

デフォルトでは、ルートホストは OpenShift によって自動的に割り当てられます。ただし、 overrides プロパティーに要求されたホストを指定すると、割り当てられたルートをオーバーライドすることができます。AMQ Streams では、要求されたホストが利用可能であるか検証されません。そのため、ホストが利用可能であることをユーザーが確認する必要があります。

OpenShift ルートホストのオーバーライドが設定されたタイプ routes の外部リスナーの例

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      bootstrap:
        host: bootstrap.myrouter.com
      brokers:
      - broker: 0
        host: broker-0.myrouter.com
      - broker: 1
        host: broker-1.myrouter.com
      - broker: 2
        host: broker-2.myrouter.com
# ...

# ...
listeners:
  external:
    type: route
    authentication:
      type: tls
    overrides:
      bootstrap:
        host: bootstrap.myrouter.com
      brokers:
      - broker: 0
        host: broker-0.myrouter.com
      - broker: 1
        host: broker-1.myrouter.com
      - broker: 2
        host: broker-2.myrouter.com
# ...

Copy to Clipboard

Toggle word wrap

Routes を使用した Kafka へのアクセスに関する詳細は「OpenShift ルートを使用した Kafka へのアクセス」を参照してください。

3.1.6.4.2.2. OpenShift ルートを使用した Kafka へのアクセス
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

外部リスナーが有効で、タイプ route に設定されている Kafka クラスターをデプロイします。

Routes を使用するよう設定された外部リスナーがある設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: route
        # ...
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: route
        # ...
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
ブートストラップ Route のアドレスを見つけます。
```
oc get routes _cluster-name_-kafka-bootstrap -o=jsonpath='{.status.ingress[0].host}{"\n"}'
```
```
oc get routes _cluster-name_-kafka-bootstrap -o=jsonpath='{.status.ingress[0].host}{"\n"}'
```
Copy to Clipboard Toggle word wrap
このアドレスと Kafkaクライアントの 443 番ポートをブートストラップアドレスとして使用します。
ブローカーの認証局の公開証明書を取得します。
```
oc get secret _<cluster-name>_-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
```
oc get secret _<cluster-name>_-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Copy to Clipboard Toggle word wrap
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

その他のリソース

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

3.1.6.4.3. ロードバランサー外部リスナー
リンクのコピー

タイプが loadbalancer の外部リスナーは、Loadbalancer タイプの Services を使用して、Kafka を公開します。

3.1.6.4.3.1. ロードバランサーを使用した Kafka の公開
リンクのコピー

Loadbalancer タイプの Services を使用して Kafka を公開すると、Kafka ブローカー Pod ごとに新しいロードバランサーサービスが作成されます。追加のロードバランサーが作成され、Kafkaの ブートストラップ アドレスとして提供されます。ロードバランサーは 9094 番ポートで接続をリッスンします。

デフォルトでは、TLS による暗号化は有効になっています。これを無効にするには、tls フィールドを false に設定します。

タイプが loadbalancer の外部リスナーの例

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
# ...

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
# ...

Copy to Clipboard

Toggle word wrap

ロードバランサーを使用した Kafka へのアクセスに関する詳細は「ロードバランサーを使用した Kafka へのアクセス」を参照してください。

3.1.6.4.3.2. 外部ロードバランサーリスナーの DNS 名のカスタマイズ
リンクのコピー

loadbalancer リスナーでは、dnsAnnotations プロパティーを使用して追加のアノテーションをロードバランサーサービスに追加できます。これらのアノテーションを使用すると、自動的に DNS 名をロードバランサーサービスに割り当てる ExternalDNS などの DNS ツールをインストルメント化できます。

dnsAnnotations を使用するタイプ loadbalancer の外部リスナーの例

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
    overrides:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
    overrides:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.4.3.3. ロードバランサー IP アドレスのカスタマイズ
リンクのコピー

loadbalancer リスナーで、ロードバランサーの作成時に loadBalancerIP プロパティーを使用すると、特定の IP アドレスをリクエストできます。特定の IP アドレスでロードバランサーを使用する必要がある場合は、このプロパティーを使用します。クラウドプロバイダーがこの機能に対応していない場合、loadBalancerIP フィールドは無視されます。

特定のロードバランサー IP アドレスリクエストのある loadbalancer タイプの外部リスナーの例

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
    overrides:
      bootstrap:
        loadBalancerIP: 172.29.3.10
      brokers:
      - broker: 0
        loadBalancerIP: 172.29.3.1
      - broker: 1
        loadBalancerIP: 172.29.3.2
      - broker: 2
        loadBalancerIP: 172.29.3.3
# ...

# ...
listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
    overrides:
      bootstrap:
        loadBalancerIP: 172.29.3.10
      brokers:
      - broker: 0
        loadBalancerIP: 172.29.3.1
      - broker: 1
        loadBalancerIP: 172.29.3.2
      - broker: 2
        loadBalancerIP: 172.29.3.3
# ...

Copy to Clipboard

Toggle word wrap

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

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

外部リスナーが有効で、タイプ loadbalancer に設定されている Kafka クラスターをデプロイします。

ロードバランサーを使用するよう設定された外部リスナーがある設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: loadbalancer
        authentication:
          type: tls
        # ...
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: loadbalancer
        authentication:
          type: tls
        # ...
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
ブートストラップロードバランサーのホスト名を見つけます。
oc get を使用してこれを行うことができます。
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.status.loadBalancer.ingress[0].hostname}{"\n"}'
```
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.status.loadBalancer.ingress[0].hostname}{"\n"}'
```
Copy to Clipboard Toggle word wrap
ホスト名が見つからない場合 (コマンドによって返されなかった場合)、ロードバランサーの IP アドレスを使用します。
oc get を使用してこれを行うことができます。
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'
```
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'
```
Copy to Clipboard Toggle word wrap
ホスト名または IP アドレスと Kafkaクライアントの 9094 番ポートをブートストラップアドレスとして使用します。
TLS による暗号化が無効になっている場合を除き、ブローカーの認証局の公開証明書を取得します。
oc get を使用してこれを行うことができます。
```
oc get secret cluster-name-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
```
oc get secret cluster-name-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Copy to Clipboard Toggle word wrap
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

その他のリソース

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

3.1.6.4.4. ノードポートの外部リスナー
リンクのコピー

タイプが nodeport の外部リスナーは、NodePort タイプの Services を使用して、Kafka を公開します。

3.1.6.4.4.1. ノードポートを使用した Kafka の公開
リンクのコピー

NodePort タイプの Services を使用して Kafka を公開する場合、Kafka クライアントは OpenShift のノードに直接接続されます。各クライアントの OpenShift ノード上のポートへのアクセスを有効にする必要があります (ファイアウォール、セキュリティーグループなど)。各 Kafka ブローカー Pod が別々のポートでアクセス可能になります。追加の NodePort 型 Service が作成され、Kafka ブートストラップアドレスとして提供されます。

Kafka ブローカー Pod にアドバタイズされたアドレスを設定する場合、AMQ Stremas では該当の Pod が稼働しているノードのアドレスが使用されます。ノードアドレスを選択する場合、以下の優先順位で異なるアドレスタイプが使用されます。

ExternalDNS
ExternalIP
Hostname
InternalDNS
InternalIP

デフォルトでは、TLS による暗号化は有効になっています。これを無効にするには、tls フィールドを false に設定します。

注記

ノードポートを使用して Kafka クラスターを公開する場合、現在 TLS ホスト名の検証はサポートされません。

デフォルトでは、ブートストラップおよびブローカーサービスに使用されるポート番号は OpenShift によって自動的に割り当てられます。ただし、overrides プロパティーに要求されたポート番号を指定すると、割り当てられたノードポートをオーバーライドすることができます。AMQ Streams では、要求されたポートで検証を実行しません。そのため、ポートが使用可能であることをユーザーが確認する必要があります。

ノードポートのオーバーライドが設定された外部リスナーの例

# ...
listeners:
  external:
    type: nodeport
    tls: true
    authentication:
      type: tls
    overrides:
      bootstrap:
        nodePort: 32100
      brokers:
      - broker: 0
        nodePort: 32000
      - broker: 1
        nodePort: 32001
      - broker: 2
        nodePort: 32002
# ...

# ...
listeners:
  external:
    type: nodeport
    tls: true
    authentication:
      type: tls
    overrides:
      bootstrap:
        nodePort: 32100
      brokers:
      - broker: 0
        nodePort: 32000
      - broker: 1
        nodePort: 32001
      - broker: 2
        nodePort: 32002
# ...

Copy to Clipboard

Toggle word wrap

ノードポートを使用した Kafka へのアクセスに関する詳細は「ノードポートを使用した Kafka へのアクセス」を参照してください。

3.1.6.4.4.2. 外部ノードポートリスナーの DNS 名のカスタマイズ
リンクのコピー

nodeport リスナーでは、dnsAnnotations プロパティーを使用して追加のアノテーションをノードポートサービスに追加できます。これらのアノテーションを使用すると、自動的に DNS 名をクラスターノードに割り当てる ExternalDNS などの DNS ツールをインストルメント化できます。

dnsAnnotations を使用するタイプ nodeport の外部リスナーの例

# ...
listeners:
  external:
    type: nodeport
    tls: true
    authentication:
      type: tls
    overrides:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

# ...
listeners:
  external:
    type: nodeport
    tls: true
    authentication:
      type: tls
    overrides:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.4.4.3. ノードポートを使用した Kafka へのアクセス
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

外部リスナーが有効で、タイプ nodeport に設定されている Kafka クラスターをデプロイします。

ノードポートを使用するよう設定された外部リスナーがある設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: nodeport
        tls: true
        # ...
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: nodeport
        tls: true
        # ...
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
ブートストラップサービスのポート番号を見つけます。
oc get を使用してこれを行うことができます。
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.spec.ports[0].nodePort}{"\n"}'
```
```
oc get service cluster-name-kafka-external-bootstrap -o=jsonpath='{.spec.ports[0].nodePort}{"\n"}'
```
Copy to Clipboard Toggle word wrap
Kafka ブートストラップアドレスでポートを使用する必要があります。
OpenShift ノードのアドレスを見つけます。
oc get を使用してこれを行うことができます。
```
oc get node node-name -o=jsonpath='{range .status.addresses[*]}{.type}{"\t"}{.address}{"\n"}'
```
```
oc get node node-name -o=jsonpath='{range .status.addresses[*]}{.type}{"\t"}{.address}{"\n"}'
```
Copy to Clipboard Toggle word wrap
異なるアドレスが返される場合は、以下の順序を基にしてアドレスタイプを選択します。
1. ExternalDNS
2. ExternalIP
3. Hostname
4. InternalDNS
5. InternalIP
  アドレスと前述のステップで見つけたポートを、Kafka ブートストラップアドレスで使用します。
TLS による暗号化が無効になっている場合を除き、ブローカーの認証局の公開証明書を取得します。
oc get を使用してこれを行うことができます。
```
oc get secret cluster-name-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
```
oc get secret cluster-name-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
```
Copy to Clipboard Toggle word wrap
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。

その他のリソース

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

3.1.6.4.5. OpenShift Ingress 外部リスナー
リンクのコピー

タイプが ingress の外部リスナーは、Kubernetes Ingress と NGINX Ingress Controller for Kubernetes を使用して Kafka を公開します。

3.1.6.4.5.1. Kubernetes Ingress を使用した Kafka の公開
リンクのコピー

Kubernetes Ingress と NGINX Ingress Controller for Kubernetes を使用して Kafka が公開されると、Kafka ブローカー Pod ごとに専用の Ingress リソースが作成されます。追加の Ingress リソースが作成され、Kafka ブートストラップアドレスとして提供されます。これらの Ingress リソースを使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。

注記

Ingress を使用する外部リスナーは、現在 NGINX Ingress Controller for Kubernetes でのみテストされています。

AMQ Streams では、NGINX Ingress Controller for Kubernetes の TLS パススルー機能が使用されます。TLS パススルーが NGINX Ingress Controller for Kubernetes デプロイメントで有効になっていることを確認してください。TLS パススルーの有効化に関する詳細は、TLS パススルーのドキュメントを参照してください。Ingress を使用して Kafka を公開する場合、TLS パススルー機能を使用するため、TLS による暗号化を無効にできません。

Ingress コントローラーはホスト名を自動的に割り当てません。spec.kafka.listeners.external.configuration セクションに、ブートストラップおよびブローカーごとのサービスによって使用されるホスト名を指定する必要があります。また、確実にホスト名が Ingress エンドポイントに解決することを確認する必要があります。AMQ Streams では、要求されたホストが利用可能で、適切に Ingress エンドポイントにルーティングされることを検証しません。

タイプが ingress の外部リスナーの例

# ...
listeners:
  external:
    type: ingress
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        host: broker-0.myingress.com
      - broker: 1
        host: broker-1.myingress.com
      - broker: 2
        host: broker-2.myingress.com
# ...

# ...
listeners:
  external:
    type: ingress
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        host: broker-0.myingress.com
      - broker: 1
        host: broker-1.myingress.com
      - broker: 2
        host: broker-2.myingress.com
# ...

Copy to Clipboard

Toggle word wrap

Ingress を使用した Kafka へのアクセスに関する詳細は「ingress を使用した Kafka へのアクセス」を参照してください。

3.1.6.4.5.2. Ingress クラスの設定
リンクのコピー

デフォルトでは、Ingress クラスは nginx に設定されます。class プロパティーを使用して Ingress クラスを変更できます。

Ingress クラス nginx-internal を使用するタイプ ingress の外部リスナーの例

# ...
listeners:
  external:
    type: ingress
    class: nginx-internal
    # ...
# ...

# ...
listeners:
  external:
    type: ingress
    class: nginx-internal
    # ...
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.4.5.3. 外部 ingress リスナーの DNS 名のカスタマイズ
リンクのコピー

ingress リスナーでは、dnsAnnotations プロパティーを使用して追加のアノテーションを ingress リソースに追加できます。これらのアノテーションを使用すると、自動的に DNS 名を ingress リソースに割り当てる ExternalDNS などの DNS ツールをインストルメント化できます。

dnsAnnotations を使用するタイプ ingress の外部リスナーの例

# ...
listeners:
  external:
    type: ingress
    authentication:
      type: tls
    configuration:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: bootstrap.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-0.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-0.myingress.com
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-1.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-1.myingress.com
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-2.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-2.myingress.com
# ...

# ...
listeners:
  external:
    type: ingress
    authentication:
      type: tls
    configuration:
      bootstrap:
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: bootstrap.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-0.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-0.myingress.com
      - broker: 1
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-1.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-1.myingress.com
      - broker: 2
        dnsAnnotations:
          external-dns.alpha.kubernetes.io/hostname: broker-2.myingress.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
        host: broker-2.myingress.com
# ...

Copy to Clipboard

Toggle word wrap

3.1.6.4.5.4. ingress を使用した Kafka へのアクセス
リンクのコピー

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

前提条件

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

手順

外部リスナーが有効で、タイプ ingress に設定されている Kafka クラスターをデプロイします。

Ingress を使用するよう設定された外部リスナーがある設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: ingress
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      external:
        type: ingress
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

configuration セクションのホストが適切に Ingress エンドポイントに解決することを確認してください。
リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

その他のリソース

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

3.1.6.5. ネットワークポリシー
リンクのコピー

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

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

認証および承認と合わせてネットワークポリシーを使用します。

リスナーごとに、異なる networkPolicyPeers 設定を指定できます。

3.1.6.5.1. リスナーのネットワークポリシー設定
リンクのコピー

以下に、plain および tls リスナーの networkPolicyPeers 設定の例を示します。

# ...
listeners:
  plain:
    authentication:
      type: scram-sha-512
    networkPolicyPeers:
      - podSelector:
          matchLabels:
            app: kafka-sasl-consumer
      - podSelector:
          matchLabels:
            app: kafka-sasl-producer
  tls:
    authentication:
      type: tls
    networkPolicyPeers:
      - namespaceSelector:
          matchLabels:
            project: myproject
      - namespaceSelector:
          matchLabels:
            project: myproject2
# ...

# ...
listeners:
  plain:
    authentication:
      type: scram-sha-512
    networkPolicyPeers:
      - podSelector:
          matchLabels:
            app: kafka-sasl-consumer
      - podSelector:
          matchLabels:
            app: kafka-sasl-producer
  tls:
    authentication:
      type: tls
    networkPolicyPeers:
      - namespaceSelector:
          matchLabels:
            project: myproject
      - namespaceSelector:
          matchLabels:
            project: myproject2
# ...

Copy to Clipboard

Toggle word wrap

この例では以下が設定されています。

ラベル app: kafka-sasl-consumer および app: kafka-sasl-producer と一致するアプリケーション Pod のみが plain リスナーに接続できます。アプリケーション Pod は Kafka ブローカーと同じ namespace で実行されている必要があります。
ラベル project: myproject および project: myproject2 と一致する namespace で稼働するアプリケーション Pod のみが tls リスナーに接続できます。

networkPolicyPeers フィールドの構文は、NetworkPolicy リソースの from フィールドと同じです。スキーマの詳細は、「NetworkPolicyPeer API reference」および「KafkaListeners スキーマ参照」を参照してください。

注記

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

3.1.6.5.2. networkPolicyPeers を使用した Kafka リスナーへのアクセス制限
リンクのコピー

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

前提条件

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

手順

Kafka リソースを開きます。

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      tls:
        networkPolicyPeers:
          - podSelector:
              matchLabels:
                app: kafka-client
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      tls:
        networkPolicyPeers:
          - podSelector:
              matchLabels:
                app: kafka-client
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

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

その他のリソース

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

3.1.7. 認証および承認
リンクのコピー

AMQ Streams では認証および承認がサポートされます。認証は、リスナーごとに独立して設定できます。承認は、常に Kafka クラスター全体に対して設定されます。

3.1.7.1. 認証
リンクのコピー

認証は、authentication プロパティーのリスナー設定の一部として設定されます。認証メカニズムは type フィールドで定義されます。

authentication プロパティーがない場合、指定のリスナーで認証が有効になりません。認証がないと、リスナーではすべての接続が許可されます。

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

TLS クライアント認証
SASL SCRAM-SHA-512
OAuth 2.0 のトークンベースの認証

3.1.7.1.1. TLS クライアント認証
リンクのコピー

TLS クライアント認証は、type を tls に指定して有効にします。TLS クライアント認証は tls リスナーでのみサポートされます。

タイプ tls の authentication の例

# ...
authentication:
  type: tls
# ...

# ...
authentication:
  type: tls
# ...

Copy to Clipboard

Toggle word wrap

3.1.7.2. Kafka ブローカーでの認証の設定
リンクのコピー

前提条件

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

手順

クラスターデプロイメントを指定する Kafka リソースが含まれる YAML 設定ファイルを開きます。

Kafka リソースの spec.kafka.listeners プロパティーで、認証を有効にするリスナーに authentication フィールドを追加します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      tls:
        authentication:
          type: tls
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      tls:
        authentication:
          type: tls
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

新しい設定を適用してリソースを作成または更新します。
oc apply を使用します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap
kafka.yaml は、設定するリソースの YAML 設定ファイルに置き換えます (例: kafka-persistent.yaml)。

その他のリソース

サポートされる認証メカニズムの詳細は、「認証」を参照してください。
Kafka のスキーマに関する詳細は、「Kafka スキーマ参照」を参照してください。

3.1.7.3. 承認
リンクのコピー

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

以下を設定できます。

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

3.1.7.3.1. 簡易承認
リンクのコピー

AMQ Streams の簡易承認では、SimpleAclAuthorizer が使用されます。これは、Apache Kafka で提供されるデフォルトのアクセス制御リスト (ACL) 承認プラグインです。ACL を使用すると、ユーザーがアクセスできるリソースを細かく定義できます。簡易承認を有効にするには、type フィールドを simple に設定します。

簡易承認の例

# ...
authorization:
  type: simple
# ...

# ...
authorization:
  type: simple
# ...

Copy to Clipboard

Toggle word wrap

ユーザーのアクセスルールは、アクセス制御リスト (ACL) を使用して定義されます。必要に応じて、superUsers フィールドにスーパーユーザーのリストを指定できます。

3.1.7.3.2. スーパーユーザー
リンクのコピー

スーパーユーザーは、ACL で定義されたアクセス制限に関係なく、Kafka クラスターのすべてのリソースにアクセスできます。Kafka クラスターのスーパーユーザーを指定するには、superUsers フィールドにユーザープリンシパルのリストを入力します。ユーザーが TLS クライアント認証を使用する場合、ユーザー名は CN= で始まる証明書のサブジェクトの共通名になります。

スーパーユーザーの指定例

# ...
authorization:
  type: simple
  superUsers:
    - CN=fred
    - sam
    - CN=edward
# ...

# ...
authorization:
  type: simple
  superUsers:
    - CN=fred
    - sam
    - CN=edward
# ...

Copy to Clipboard

Toggle word wrap

注記

Kafka.spec.kafka の config プロパティーにある super.user 設定オプションは無視されます。この代わりに、authorization プロパティーでスーパーユーザーを指定します。詳細は「Kafka ブローカーの設定」を参照してください。

3.1.7.4. Kafka ブローカーでの承認の設定
リンクのコピー

承認を設定し、特定の Kafka ブローカーのスーパーユーザーを指定します。

前提条件

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

手順

Kafka.spec.kafka リソースで authorization プロパティーを追加または編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=fred
        - sam
        - CN=edward
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=fred
        - sam
        - CN=edward
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

サポートされる承認方法の詳細は、「承認」を参照してください。
Kafka のスキーマに関する詳細は、「Kafka スキーマ参照」を参照してください。
ユーザー認証の設定に関する詳細は、「Kafka User リソース」を参照してください。

3.1.8. ZooKeeper レプリカ
リンクのコピー

通常、ZooKeeper クラスターまたはアンサンブルは、一般的に 3、5、7 個の奇数個のノードで実行されます。

効果的なクォーラムを維持するには、過半数のノードが利用可能である必要があります。ZooKeeper クラスターでクォーラムを損失すると、クライアントへの応答が停止し、Kafka ブローカーが機能しなくなります。AMQ Streams では、 ZooKeeper クラスターの安定性および高可用性が重要になります。

3 ノードクラスター: 3 ノードの ZooKeeper クラスターでは、クォーラムを維持するために、少なくとも 2 つのノードが稼働している必要があります。このクラスターは、利用できないノードが 1 つのみであれば対応できます。
5 ノードクラスター: 5 ノードの ZooKeeper クラスターでは、クォーラムを維持するために、少なくとも 3 つのノードが稼働している必要があります。このクラスターは、利用できないノードが 2 つの場合まで対応できます。
7 ノードクラスター: 7 ノードの ZooKeeper クラスターでは、クォーラムを維持するために、少なくとも 4 つのノードが稼働している必要があります。このクラスターは、利用できないノードが 3 つの場合まで対応できます。

注記

開発の目的で、単一ノードの ZooKeeper を実行することも可能です。

クラスターのノードの数が多いほどクォーラムを維持するコストも高くなるため、ノードの数が多いほどパフォーマンスが向上するとは限りません。可用性の要件に応じて、使用するノードの数を決定します。

3.1.8.1. ZooKeeper ノードの数
リンクのコピー

ZooKeeper ノードの数は、Kafka.spec.zookeeper の replicas プロパティーを使用して設定できます。

レプリカの設定を示す例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    replicas: 3
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    replicas: 3
    # ...

Copy to Clipboard

Toggle word wrap

3.1.8.2. ZooKeeper レプリカの数の変更
リンクのコピー

前提条件

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

手順

クラスターデプロイメントを指定する Kafka リソースが含まれる YAML 設定ファイルを開きます。

Kafka リソースの spec.zookeeper.replicas プロパティーで、複製された ZooKeeper サーバーの数を入力します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    replicas: 3
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    replicas: 3
    # ...

Copy to Clipboard

Toggle word wrap

新しい設定を適用してリソースを作成または更新します。
oc apply を使用します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap
kafka.yaml は、設定するリソースの YAML 設定ファイルに置き換えます (例: kafka-persistent.yaml)。

3.1.9. ZooKeeper の設定
リンクのコピー

AMQ Streams では、Apache ZooKeeper ノードの設定をカスタマイズできます。ZooKeeper のドキュメントに記載されているほとんどのオプションを指定および設定できます。

以下に関連するオプションは設定できません。

セキュリティー (暗号化、認証、および承認)
リスナーの設定
データディレクトリーの設定
ZooKeeper クラスターの構成

これらのオプションは AMQ Streams によって自動的に設定されます。

3.1.9.1. ZooKeeper の設定
リンクのコピー

ZooKeeper ノードは、Kafka.spec.zookeeper の config プロパティーを使用して設定されます。このプロパティーには、ZooKeeper 設定オプションがキーとして含まれます。値は、以下の JSON タイプの 1 つを使用して記述できます。

文字列
Number
ブール値

ユーザーは、AMQ Streams で直接管理されるオプションを除き、ZooKeeper ドキュメントに記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

server.
dataDir
dataLogDir
clientPort
authProvider
quorum.auth
requireClientAuthScheme

禁止されているオプションの 1 つが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションは、すべて ZooKeeper に渡されます。

重要

Cluster Operator では、提供された config オブジェクトのキーまたは値は検証されません。無効な設定を指定すると、ZooKeeper クラスターが起動しなかったり、不安定になる可能性があります。このような場合、Kafka.spec.zookeeper.config オブジェクトの設定を修正し、Cluster Operator によって新しい設定がすべての ZooKeeper ノードにロールアウトされるようにします。

選択したオプションのデフォルト値は次のとおりです。

timeTick、デフォルト値 2000
initLimit、デフォルト値 5
syncLimit、デフォルト値 2
autopurge.purgeInterval、デフォルト値 1

これらのオプションは、Kafka.spec.zookeeper.config プロパティーにない場合に自動的に設定されます。

ZooKeeper 設定を示す例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
    # ...

Copy to Clipboard

Toggle word wrap

3.1.9.2. ZooKeeper の設定
リンクのコピー

前提条件

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

手順

クラスターデプロイメントを指定する Kafka リソースが含まれる YAML 設定ファイルを開きます。

Kafka リソースの spec.zookeeper.config プロパティーで、ZooKeeper 設定を 1 つまたは複数入力します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
    # ...

Copy to Clipboard

Toggle word wrap

新しい設定を適用してリソースを作成または更新します。
oc apply を使用します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap
kafka.yaml は、設定するリソースの YAML 設定ファイルに置き換えます (例: kafka-persistent.yaml)。

3.1.10. ZooKeeper の接続
リンクのコピー

ZooKeeper サービスは暗号化および認証でセキュア化され、AMQ Streams の一部でない外部アプリケーションでの使用は想定されていません。

しかし、kafka-topics ツールなどの ZooKeeper への接続を必要とする Kafka CLI ツールを使用する場合は、Kafka コンテナー内でターミナルを使用し、localhost:2181 を ZooKeeper アドレスとして使用して、TLS トンネルのローカル側を ZooKeeper に接続できます。

3.1.10.1. ターミナルからの ZooKeeper への接続
リンクのコピー

Kafka コンテナー内でターミナルを開き、ZooKeeper の接続を必要とする Kafka CLI ツールを使用します。

前提条件

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

手順

OpenShift コンソールを使用してターミナルを開くか、CLI から exec コマンドを実行します。
以下に例を示します。
```
oc exec -it my-cluster-kafka-0 -- bin/kafka-topics.sh --list --zookeeper localhost:2181
```
```
oc exec -it my-cluster-kafka-0 -- bin/kafka-topics.sh --list --zookeeper localhost:2181
```
Copy to Clipboard Toggle word wrap
必ず localhost:2181 を使用してください。
ZooKeeper に対して Kafka コマンドを実行できるようになりました。

3.1.11. Entitiy Operator
リンクのコピー

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

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

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

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

注記

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

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

3.1.11.1. Entity Operator の設定プロパティー
リンクのコピー

Entity Operator は Kafka.spec の entityOperator を使用して設定できます。

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

tlsSidecar
topicOperator
userOperator
template

tlsSidecar プロパティーは、ZooKeeper との通信に使用される TLS サイドカーコンテナーの設定に使用できます。TLS サイドカーコンテナーの設定に関する詳細は、「TLS サイドカー」を参照してください。

template プロパティーを使用すると、ラベル、アノテーション、アフィニティー、容認 (Toleration) などの Entity Operator Pod の詳細を設定できます。

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

3.1.11.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 プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、「コンテナーイメージ」を参照してください。
resources: resources プロパティーを使用すると、Topic Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、「CPU およびメモリーリソース」を参照してください。
logging: logging プロパティーは、Topic Operator のロギングを設定します。詳細は「Operator ロガー」を参照してください。

Topic Operator 設定の例

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

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

Copy to Clipboard

Toggle word wrap

3.1.11.3. User Operator 設定プロパティー
リンクのコピー

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

watchedNamespace: User Operator によって KafkaUsers が監視される OpenShift namespace。デフォルトは、Kafka クラスターがデプロイされた namespace です。
reconciliationIntervalSeconds: 定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは 120 です。
zookeeperSessionTimeoutSeconds: ZooKeeper セッションのタイムアウト (秒単位)。デフォルトは 6 です。
image: image プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、「コンテナーイメージ」を参照してください。
resources: resources プロパティーを使用すると、User Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、「CPU およびメモリーリソース」を参照してください。
logging: logging プロパティーは、User Operator のロギングを設定します。詳細は「Operator ロガー」を参照してください。

User Operator 設定の例

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

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

Copy to Clipboard

Toggle word wrap

3.1.11.4. Operator ロガー
リンクのコピー

Topic Operator および User Operator には設定可能なロガーがあります。

rootLogger.level

これらの Operator では Apache log4j2 ロガー実装が使用されます。

logging リソースの Kafka プロパティーを使用して、ロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j2.properties を使用して記述されます。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
# ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
# ...

Copy to Clipboard

Toggle word wrap

外部ロギング

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

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

Copy to Clipboard

Toggle word wrap

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。GC ロギングの詳細は「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.1.11.5. Entity Operator の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka リソースの entityOperator プロパティーを編集します。以下に例を示します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.12. CPU およびメモリーリソース
リンクのコピー

AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。

AMQ Streams では、以下の 2 つのタイプのリソースがサポートされます。

CPU
メモリー

AMQ Streams では、CPU およびメモリーリソースの指定に OpenShift 構文が使用されます。

3.1.12.1. リソースの制限および要求
リンクのコピー

リソースの制限と要求は、以下のリソースで resources プロパティーを使用して設定されます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

その他のリソース

OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。

3.1.12.1.1. リソース要求
リンクのコピー

要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。

重要

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

リソース要求は requests プロパティーで指定されます。AMQ Streams では、現在以下のリソース要求がサポートされます。

cpu
memory

1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。

すべてのリソースを対象とするリソース要求の設定例

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.1.12.1.2. リソース制限
リンクのコピー

制限によって、指定のコンテナーが消費可能な最大リソースが指定されます。制限は予約されず、常に利用できるとは限りません。コンテナーは、リソースが利用できる場合のみ、制限以下のリソースを使用できます。リソース制限は、常にリソース要求よりも高くする必要があります。

リソース制限は limits プロパティーで指定されます。AMQ Streams では、現在以下のリソース制限がサポートされます。

cpu
memory

1 つまたは複数のサポートされる制限に対してリソースを設定できます。

リソース制限の設定例

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.1.12.1.3. サポートされる CPU 形式
リンクのコピー

CPU の要求および制限は以下の形式でサポートされます。

整数値 (5 CPU コア) または少数 (2.5 CPU コア) の CPU コアの数。
数値または ミリ CPU / ミリコア (100m)。1000 ミリコア は 1 CPU コアと同じです。

CPU ユニットの例

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

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

Copy to Clipboard

Toggle word wrap

注記

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

その他のリソース

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

3.1.12.1.4. サポートされるメモリー形式
リンクのコピー

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。

メモリーをメガバイトで指定するには、M 接尾辞を使用します。例: 1000M
メモリーをギガバイトで指定するには、G 接尾辞を使用します。例: 1G
メモリーをメビバイトで指定するには、Mi 接尾辞を使用します。例: 1000Mi
メモリーをギビバイトで指定するには、Gi 接尾辞を使用します。例: 1Gi

異なるメモリー単位の使用例

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

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

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.1.12.2. リソース要求および制限の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.1.13. Kafka ロガー
リンクのコピー

Kafka には独自の設定可能なロガーがあります。

kafka.root.logger.level
log4j.logger.org.I0Itec.zkclient.ZkClient
log4j.logger.org.apache.zookeeper
log4j.logger.kafka
log4j.logger.org.apache.kafka
log4j.logger.kafka.request.logger
log4j.logger.kafka.network.Processor
log4j.logger.kafka.server.KafkaApis
log4j.logger.kafka.network.RequestChannel$
log4j.logger.kafka.controller
log4j.logger.kafka.log.LogCleaner
log4j.logger.state.change.logger
log4j.logger.kafka.authorizer.logger

ZooKeeper にも設定可能なロガーもあります。

zookeeper.root.logger

Kafka と ZooKeeper では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  # ...
  logging:
    type: inline
    loggers:
      kafka.root.logger.level: "INFO"
  # ...
  zookeeper:
    # ...
    logging:
      type: inline
      loggers:
        zookeeper.root.logger: "INFO"
  # ...
  entityOperator:
    # ...
    topicOperator:
      # ...
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...
    userOperator:
      # ...
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  # ...
  logging:
    type: inline
    loggers:
      kafka.root.logger.level: "INFO"
  # ...
  zookeeper:
    # ...
    logging:
      type: inline
      loggers:
        zookeeper.root.logger: "INFO"
  # ...
  entityOperator:
    # ...
    topicOperator:
      # ...
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...
    userOperator:
      # ...
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
    # ...

Copy to Clipboard

Toggle word wrap

外部ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

Copy to Clipboard

Toggle word wrap

log4j2.properties を使用して ConfigMap 内にロギング設定を記述するため、Operator によって Apache log4j2 ロガー実装が使用されます。詳細は「Operator ロガー」を参照してください。

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。ガべージコレクションの詳細は、「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.1.14. Kafka のラックアウェアネス (Rack awareness)
リンクのコピー

AMQ Streams のラックアウェアネス (Rack awareness) 機能は、Kafka ブローカー Pod および Kafka トピックレプリカを異なるラック全体に分散できるようにします。ラック認識を有効にすることで、Kafka ブローカーや Kafka ブローカーがホストしているトピックの可用性を向上できるようにします。

注記

「ラック」(Rack) は、可用性ゾーン、データセンター、またはデータセンターの実際のラックを表す可能性があります。

3.1.14.1. Kafka ブローカーでのラック認識 (Rack awareness) の設定
リンクのコピー

Kafka のラック認識 (Rack awareness) は、Kafka.spec.kafka の rack プロパティーで設定できます。rack オブジェクトには、topologyKeyという名前の必須フィールドが 1 つあります。このキーは、OpenShift クラスターノードに割り当てられたラベルの 1 つと一致する必要があります。このラベルは、Kafka ブローカー Pod をノードにスケジュールする際に OpenShift によって使用されます。OpenShift クラスターがクラウドプロバイダープラットフォームで稼働している場合、そのラベルはノードが稼働している可用性ゾーンを表す必要があります。通常、ノードには、topologyKey の値として簡単に使用できる failure-domain.beta.kubernetes.io/zone のラベルが付けられます。これにより、ブローカー Pod がゾーン全体に分散され、Kafka ブローカー内にブローカーの broker.rack 設定パラメーターも設定されます。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

ノードがデプロイされたゾーンやラックを表すノードラベルについては、OpenShift 管理者に相談します。

ラベルをトポロジーキーとして使用し、Kafka リソースの rack プロパティーを編集します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: failure-domain.beta.kubernetes.io/zone
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: failure-domain.beta.kubernetes.io/zone
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

Kafka ラック認識に init コンテナーイメージを設定するための詳細は「コンテナーイメージ」を参照してください。

3.1.15. ヘルスチェック
リンクのコピー

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

OpenShift では、以下の 2 つのタイプのおよびヘルスチェックプローブがサポートされます。

Liveness プローブ
Readiness プローブ

プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。AMQ Streams コンポーネントでは、両タイプのプローブが使用されます。

ユーザーは、Liveness および Readiness プローブに選択されたオプションを設定できます。

3.1.15.1. ヘルスチェックの設定
リンクのコピー

Liveness および Readiness プローブは、以下のリソースの livenessProbe および readinessProbe プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

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

initialDelaySeconds
timeoutSeconds
periodSeconds
successThreshold
failureThreshold

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

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

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

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

Copy to Clipboard

Toggle word wrap

3.1.15.2. ヘルスチェックの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの livenessProbe または readinessProbe プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.16. Prometheus メトリクス
リンクのコピー

AMQ Streams では、Apache Kafka および ZooKeeper によってサポートされる JMX メトリクスを Prometheus メトリクスに変換するために、Prometheus JMX エクスポーターを使用した Prometheus メトリクスがサポートされます。有効になったメトリクスは、9404 番ポートで公開されます。

Prometheus および Grafana の設定に関する詳細は「メトリクス」を参照してください。

3.1.16.1. メトリクスの設定
リンクのコピー

Prometheus メトリクスは、以下のリソースに metrics プロパティーを設定して有効化されます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec

metrics プロパティーがリソースに定義されていない場合、Prometheus メトリクスは無効になります。追加設定なしで Prometheus メトリクスのエクスポートを有効にするには、空のオブジェクト ({}) を設定します。

追加設定なしでメトリクスを有効にする例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

metrics プロパティーには、Prometheus JMX エスクポーターの追加設定が含まれることがあります。

追加の Prometheus JMX Exporter 設定を使用したメトリクスを有効化する例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

3.1.16.2. Prometheus メトリクスの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの metrics プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.17. JMX オプション
リンクのコピー

AMQ Streams では、JMX ポートを 9999 番で開放することで、Kafka ブローカーから JMX メトリクスを取得することがサポートされます。各 Kafka ブローカーに関するさまざまなメトリクスを取得できます。たとえば、BytesPerSecond の値やブローカーのネットワークの要求レートなどの、使用データを取得できます。AMQ Streams では、パスワードとユーザー名で保護された JMX ポートの開放や、保護されていない JMX ポートの開放がサポートされます。

3.1.17.1. JMX オプションの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

以下のリソースで jmxOptions プロパティーを使用すると JMX オプションを設定できます。

Kafka.spec.kafka

Kafka ブローカーで開放された JMX ポートの、ユーザー名とパスワードの保護を設定できます。

JMX ポートのセキュリティー保護

JMX ポートをセキュアにすると、非承認の Pod によるポートへのアクセスを防ぐことができます。現在、JMX ポートをセキュアにする唯一の方法がユーザー名とパスワードを使用することです。JMX ポートのセキュリティーを有効にするには、authentication フィールドの type パラメーターを password に設定します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

これにより、ヘッドレスサービスを使用し、対応するブローカーを指定して Pod をクラスター内部にデプロイし、JMX メトリクスを取得することができます。ブローカー 0 から JMX メトリクスを取得するには、指定するヘッドレスサービスの前にブローカー 0 を追加します。

"<cluster-name>-kafka-0-<cluster-name>-<headless-service-name>"

"<cluster-name>-kafka-0-<cluster-name>-<headless-service-name>"

Copy to Clipboard

Toggle word wrap

JMX ポートがセキュアである場合、Pod のデプロイメントで JMX シークレットからユーザー名とパスワードを参照すると、そのユーザー名とパスワードを取得できます。

開放された JMX ポートの使用

JMX ポートのセキュリティーを無効にする場合は、authentication フィールドに何も入力しません。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions: {}
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions: {}
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

これにより、ヘッドレスサービスで JMX ポートを開放し、上記と似た方法で Pod をクラスター内にデプロイすることができます。唯一の違いは、すべての Pod が JMX ポートから読み取りできることです。

3.1.18. JVM オプション
リンクのコピー

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

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

JVM 設定オプションによって、さまざまなプラットフォームおよびアーキテクチャーのパフォーマンスが最適化されます。AMQ Streams では、これらのオプションの一部を設定できます。

3.1.18.1. JVM 設定
リンクのコピー

JVM オプションは、以下のリソースの jvmOptions プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

使用可能な JVM オプションの選択されたサブセットのみを設定できます。以下のオプションがサポートされます。

-Xms および -Xmx

-Xms は、JVM の起動時に最初に割り当てられる最小ヒープサイズを設定します。-Xmx は、最大ヒープサイズを設定します。

注記

-Xmx や -Xms などの JVM 設定で使用できる単位は、対応するイメージの JDK java バイナリーによって許可される単位です。そのため、1g または 1G は 1,073,741,824 バイトを意味し、Gi は接尾辞として有効な単位ではありません。これは、1G は 1,000,000,000 バイト、1Gi は 1,073,741,824 バイトを意味する OpenShift の慣例に準拠しているメモリー要求および制限に使用される単位とは対照的です。

-Xms および -Xmx に使用されるデフォルト値は、コンテナーにメモリー要求の制限が設定されているかどうかによって異なります。

メモリーの制限がある場合は、JVM の最小および最大メモリーは制限に対応する値に設定されます。
メモリーの制限がない場合、JVM の最小メモリーは 128M に設定され、JVM の最大メモリーは定義されません。これにより、JVM のメモリーを必要に応じて拡張できます。これは、テストおよび開発での単一ノード環境に適しています。

重要

-Xmx を明示的に設定するには、以下の点に注意する必要があります。

JVM のメモリー使用量の合計は、-Xmx によって設定された最大ヒープの約 4 倍になります。
適切な OpenShift メモリー制限を設定せずに -Xmx が設定された場合、OpenShift ノードで、実行されている他の Pod からメモリー不足が発生するとコンテナーが強制終了される可能性があります。
適切な OpenShift メモリー要求を設定せずに -Xmx が設定された場合、コンテナーはメモリー不足のノードにスケジュールされる可能性があります。この場合、コンテナーは起動せずにクラッシュします (-Xms が -Xmx に設定されている場合は即座にクラッシュし、そうでない場合はその後にクラッシュします)。

-Xmx を明示的に設定する場合は、以下を行うことが推奨されます。

メモリー要求とメモリー制限を同じ値に設定します。
-Xmx の 4.5 倍以上のメモリー要求を使用します。
-Xms を -Xmx と同じ値に設定することを検討してください。

重要

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

-Xmx および -Xms の設定例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

上記の例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB になります。

最初のヒープサイズ (-Xms) および最大ヒープサイズ (-Xmx) に同じ値を設定すると、JVM が必要以上のヒープを割り当てて起動後にメモリーを割り当てないようにすることができます。Kafka および ZooKeeper Pod では、このような割り当てによって不要なレイテンシーが発生する可能性があります。Kafka Connect では、割り当ての過剰を防ぐことが最も重要になります。これは、コンシューマーの数が増えるごとに割り当て過剰の影響がより深刻になる分散モードで特に重要です。

-server

-server はサーバー JVM を有効にします。このオプションは true または false に設定できます。

-server の設定例 (抜粋)

# ...
jvmOptions:
  "-server": true
# ...

# ...
jvmOptions:
  "-server": true
# ...

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

-XX

-XX オブジェクトは、JVM の高度なランタイムオプションの設定に使用できます。-server および -XX オプションは、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS オプションの設定に使用されます。

-XX オブジェクトの使用例

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

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

Copy to Clipboard

Toggle word wrap

上記の設定例の場合、JVM オプションは以下のようになります。

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

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

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

3.1.18.1.1. ガベッジコレクターのロギング
リンクのコピー

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

GC ロギングを有効にする例

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

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

Copy to Clipboard

Toggle word wrap

3.1.18.2. JVM オプションの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、または KafkaBridgeリソースの jvmOptions プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.19. コンテナーイメージ
リンクのコピー

AMQ Streams では、コンポーネントに使用されるコンテナーイメージを設定できます。コンテナーイメージのオーバーライドは、別のコンテナーレジストリーを使用する必要がある特別な状況でのみ推奨されます。たとえば、AMQ Streams によって使用されるコンテナーリポジトリーにネットワークがアクセスできない場合などがこれに該当します。そのような場合は、AMQ Streams イメージをコピーするか、ソースからビルドする必要があります。設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。

3.1.19.1. コンテナーイメージの設定
リンクのコピー

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

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

3.1.19.1.1. Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定
リンクのコピー

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

STRIMZI_KAFKA_IMAGES
STRIMZI_KAFKA_CONNECT_IMAGES
STRIMZI_KAFKA_CONNECT_S2I_IMAGES
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

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

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

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

Kafka の場合は spec.kafka.image および spec.kafka.version。
Kafka Connect、Kafka Connect S2I、および Kafka MirrorMaker の場合は spec.image および spec.version。

警告

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

3.1.19.1.2. 他のリソースでの image プロパティーの設定
リンクのコピー

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

Kafka ブローカー TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_KAFKA_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
ZooKeeper ノードの場合:
ZooKeeper ノードの TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ZOOKEEPER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Topic Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
User Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
Entity Operator TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Exporter の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Bridge の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.4.0 コンテナーイメージ。
Kafka ブローカーイニシャライザーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。

警告

コンテナーイメージのオーバーライドは、別のコンテナーレジストリーを使用する必要がある特別な状況でのみ推奨されます。たとえば、AMQ Streams によって使用されるコンテナーリポジトリーにネットワークがアクセスできない場合などがこれに該当します。そのような場合は、AMQ Streams イメージをコピーするか、ソースからビルドする必要があります。設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。

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

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

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

Copy to Clipboard

Toggle word wrap

3.1.19.2. コンテナーイメージの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの image プロパティーを編集します。以下に例を示します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.20. TLS サイドカー
リンクのコピー

サイドカーは、Pod で実行されるコンテナーですが、サポートの目的で提供されます。AMQ Streams では、TLS サイドカーは TLS を使用して、各種のコンポーネントと ZooKeeper との間のすべての通信を暗号化および復号化します。ZooKeeper にはネイティブの TLS サポートがありません。

TLS サイドカーは以下で使用されます。

Kafka ブローカー
ZooKeeper ノード
Entitiy Operator

3.1.20.1. TLS サイドカー設定
リンクのコピー

TLS サイドカーは、以下で tlsSidecar プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
Kafka.spec.entityOperator

TLS サイドカーは、以下の追加オプションをサポートします。

image
resources
logLevel
readinessProbe
livenessProbe

resources プロパティーを使用すると、TLS サイドカーに割り当てられるメモリーおよび CPU リソースを指定できます。

image プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、「コンテナーイメージ」を参照してください。

logLevel プロパティーは、ログレベルを指定するために使用されます。以下のログレベルがサポートされます。

emerg
alert
crit
err
warning
notice
info
debug

デフォルト値は notice です。

readinessProbe および livenessProbe プロパティーの設定に関する詳細は「ヘルスチェックの設定」を参照してください。

TLS サイドカーの設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    tlsSidecar:
      image: my-org/my-image:latest
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
      logLevel: debug
      readinessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    tlsSidecar:
      image: my-org/my-image:latest
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
      logLevel: debug
      readinessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

3.1.20.2. TLS サイドカーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka リソースの tlsSidecar プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    tlsSidecar:
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    tlsSidecar:
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.21. Pod スケジューリングの設定
リンクのコピー

重要

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

3.1.21.1. 他のアプリケーションに基づく Pod のスケジューリング
リンクのコピー

3.1.21.1.1. 重要なアプリケーションがノードを共有しないようにする
リンクのコピー

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

3.1.21.1.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

affinity プロパティーの形式は、OpenShift の仕様に準拠します。詳細は、Kubernetes のノードおよび Pod のアフィニティーに関するドキュメントを参照してください。

3.1.21.1.3. Kafka コンポーネントでの Pod の非アフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.21.2. 特定のノードへの Pod のスケジューリング
リンクのコピー

3.1.21.2.1. ノードのスケジューリング
リンクのコピー

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

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

3.1.21.2.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.1.21.2.3. Kafka コンポーネントでのノードのアフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.21.3. 専用ノードの使用
リンクのコピー

3.1.21.3.1. 専用ノード
リンクのコピー

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

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

専用ノードで Kafka Pod をスケジュールするには、ノードのアフィニティーと許容 (toleration) を設定します。

3.1.21.3.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.1.21.3.3. 許容 (Toleration)
リンクのコピー

許容 (Toleration) は、以下のリソースの tolerations プロパティーを使用して設定できます。

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

tolerations プロパティーの形式は、OpenShift の仕様に準拠します。詳細は、Kubernetes の「Taints and Tolerations」を参照してください。

3.1.21.3.4. 専用ノードの設定と Pod のスケジューリング
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.1.22. Kafka Exporter
リンクのコピー

Kafka リソースを設定すると、クラスターに Kafka Exporter を自動的にデプロイできます。

Kafka Exporter は、主にオフセット、コンシューマーグループ、コンシューマーラグ、およびトピックに関連するデータである分析用のデータを Prometheus メトリクスとして抽出します。

Kafka Exporter の詳細と、パフォーマンスのためにコンシューマーラグを監視する重要性の理由については、「Kafka Exporter」を参照してください。

3.1.22.1. Kafka Exporter の設定
リンクのコピー

KafkaExporter プロパティーを使用して、Kafka リソースの Kafka Exporter を設定します。

Kafka リソースとそのプロパティーの概要は、「Kafka YAML の設定例」を参照してください。

この手順では、Kafka Exporter 設定に関連するプロパティーを取り上げます。

これらのプロパティーは、Kafka クラスターのデプロイメントまたは再デプロイメントの一部として設定できます。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  kafkaExporter:
    image: my-org/my-image:latest 
    groupRegex: ".*" 
    topicRegex: ".*" 
    resources: 
      requests:
        cpu: 200m
        memory: 64Mi
      limits:
        cpu: 500m
        memory: 128Mi
    logging: debug 
    enableSaramaLogging: true 
    template: 
      pod:
        metadata:
          labels:
            label1: value1
        imagePullSecrets:
          - name: my-docker-credentials
        securityContext:
          runAsUser: 1000001
          fsGroup: 0
        terminationGracePeriodSeconds: 120
    readinessProbe: 
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe: 
      initialDelaySeconds: 15
      timeoutSeconds: 5
# ...

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


    groupRegex: ".*"


    topicRegex: ".*"


    resources:


      requests:
        cpu: 200m
        memory: 64Mi
      limits:
        cpu: 500m
        memory: 128Mi
    logging: debug


    enableSaramaLogging: true


    template:


      pod:
        metadata:
          labels:
            label1: value1
        imagePullSecrets:
          - name: my-docker-credentials
        securityContext:
          runAsUser: 1000001
          fsGroup: 0
        terminationGracePeriodSeconds: 120
    readinessProbe:


      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:


      initialDelaySeconds: 15
      timeoutSeconds: 5
# ...

Copy to Clipboard

Toggle word wrap

1: 高度な任意手順: 特別な場合のみ推奨されるコンテナーイメージの設定。
2: メトリクスに含まれるコンシューマーグループを指定する正規表現。
3: メトリクスに含まれるトピックを指定する正規表現。
4: 予約する CPU およびメモリーリソース。
5: 指定の重大度 (debug、info、warn、error、fatal) 以上でメッセージをログに記録するためのログ設定。
6: Sarama ロギングを有効にするブール値 (Kafka Exporter によって使用される Go クライアントライブラリー)。
7: デプロイメントテンプレートおよび Pod のカスタマイズ。
8: ヘルスチェックの readiness プローブ。
9: ヘルスチェックの liveness プローブ。

リソースを作成または更新します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap

次のステップ

Kafka Exporter の設定およびデプロイ後に、Grafana を有効にして Kafka Exporter ダッシュボードを表示できます。

その他のリソース

「KafkaExporterTemplate スキーマ参照」

3.1.23. Kafka クラスターのローリングアップデートの実行
リンクのコピー

この手順では、OpenShift アノテーションを使用して、既存の Kafka クラスターのローリングアップデートを手動でトリガーする方法を説明します。

前提条件

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

手順

手動で更新する Kafka Pod を制御する StatefulSet の名前を見つけます。
たとえば、Kafka クラスターの名前が my-cluster の場合、対応する StatefulSet の名前は my-cluster-kafka になります。
OpenShift で StatefulSet リソースにアノテーションを付けます。以下は oc annotate を使用した例になります。
```
oc annotate statefulset cluster-name-kafka strimzi.io/manual-rolling-update=true
```
```
oc annotate statefulset cluster-name-kafka strimzi.io/manual-rolling-update=true
```
Copy to Clipboard Toggle word wrap
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。アノテーションが調整プロセスで検出されれば、アノテーションが付いた StatefulSet 内のすべての Pod でローリングアップデートがトリガーされます。すべての Pod のローリングアップデートが完了すると、アノテーションは StatefulSet から削除されます。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
Kafka クラスターのデプロイメントに関する詳細は、「Kafka クラスターのデプロイメント」を参照してください。

3.1.24. ZooKeeper クラスターのローリングアップデートの実行
リンクのコピー

この手順では、OpenShift アノテーションを使用して、既存の ZooKeeper クラスターのローリングアップデートを手動でトリガーする方法を説明します。

前提条件

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

手順

手動で更新する ZooKeeper Pod を制御する StatefulSet の名前を見つけます。
たとえば、Kafka クラスターの名前が my-cluster の場合、対応する StatefulSet の名前は my-cluster-zookeeper になります。
OpenShift で StatefulSet リソースにアノテーションを付けます。以下は oc annotate を使用した例になります。
```
oc annotate statefulset cluster-name-zookeeper strimzi.io/manual-rolling-update=true
```
```
oc annotate statefulset cluster-name-zookeeper strimzi.io/manual-rolling-update=true
```
Copy to Clipboard Toggle word wrap
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。アノテーションが調整プロセスで検出されれば、アノテーションが付いた StatefulSet 内のすべての Pod でローリングアップデートがトリガーされます。すべての Pod のローリングアップデートが完了すると、アノテーションは StatefulSet から削除されます。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
ZooKeeper クラスターのデプロイメントに関する詳細は、「Kafka クラスターのデプロイメント」を参照してください。

3.1.25. クラスターのスケーリング
リンクのコピー

3.1.25.1. Kafka クラスターのスケーリング
リンクのコピー

3.1.25.1.1. ブローカーのクラスターへの追加
リンクのコピー

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

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

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

3.1.25.1.2. クラスターからのブローカーの削除
リンクのコピー

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

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

3.1.25.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 が出力の一部として生成されます。大規模な再割り当ては、進行中の再割り当てを停止する必要がある場合に備えて、複数の小さな再割り当てに分割するようにしてください。

3.1.25.2.1. 再割り当て JSON ファイル
リンクのコピー

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

注記

Kafka は "log_dirs" プロパティーもサポートしますが、Red Hat 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]
    }
  ]
}

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

Copy to Clipboard

Toggle word wrap

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

3.1.25.2.2. JBOD ボリューム間でのパーティションの再割り当て
リンクのコピー

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

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

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

Copy to Clipboard

Toggle word wrap

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" ]
}

{
      "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" ]
}

Copy to Clipboard

Toggle word wrap

3.1.25.3. 再割り当て JSON ファイルの生成
リンクのコピー

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

前提条件

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

手順

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

3.1.25.4. 手動による再割り当て JSON ファイルの作成
リンクのコピー

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

3.1.25.5. 再割り当てスロットル
リンクのコピー

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

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

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

3.1.25.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 broker-pod -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

Copy to Clipboard

Toggle word wrap

以下に例を示します。

cat reassignment.json | \
  oc exec my-cluster-kafka-0 -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'

Copy to Clipboard

Toggle word wrap

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

例:

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

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

Copy to Clipboard

Toggle word wrap

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

3.1.25.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 broker-pod -c kafka -i -- /bin/bash -c \
  'cat > /tmp/reassignment.json'

Copy to Clipboard

Toggle word wrap

以下に例を示します。

cat reassignment.json | \
  oc exec my-cluster-kafka-0 -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'

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

例:

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

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

Copy to Clipboard

Toggle word wrap

--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$'"
```
```
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$'"
```
Copy to Clipboard Toggle word wrap
N は削除された Pod(s) の数に置き換えます。
上記のコマンドによって出力が生成される場合、ブローカーにはライブパーティションがあります。この場合、再割り当てが終了していないか、再割り当て JSON ファイルが適切ではありません。
ブローカーにライブパーティションがないことが確認できたら、Kafka リソースの Kafka.spec.kafka.replicas を編集できます。これにより、StatefulSet がスケールダウンされ、番号が最も大きいブローカー Pod(s) が削除されます。

3.1.26. Kafka ノードの手動による削除
リンクのコピー

その他のリソース

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

警告

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

前提条件

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

手順

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

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
Kafka クラスターのデプロイメントに関する詳細は、「Kafka クラスターのデプロイメント」を参照してください。

3.1.27. ZooKeeper ノードの手動による削除
リンクのコピー

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

警告

前提条件

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

手順

削除する 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

oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true

Copy to Clipboard

Toggle word wrap

基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに次の調整の実行を待ちます。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
ZooKeeper クラスターのデプロイメントに関する詳細は、「Kafka クラスターのデプロイメント」を参照してください。

3.1.28. ローリングアップデートのメンテナンス時間枠
リンクのコピー

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

3.1.28.1. メンテナンス時間枠の概要
リンクのコピー

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

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

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

3.1.28.2. メンテナンス時間枠の定義
リンクのコピー

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

注記

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

その他のリソース

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

3.1.28.3. メンテナンス時間枠の設定
リンクのコピー

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

前提条件

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

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  maintenanceTimeWindows:
    - "* * 8-10 * * ?"
    - "* * 14-15 * * ?"

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  maintenanceTimeWindows:
    - "* * 8-10 * * ?"
    - "* * 14-15 * * ?"

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

Kafka クラスターのローリングアップデートの実行については、「Kafka クラスターのローリングアップデートの実行」を参照してください。
ZooKeeper クラスターのローリングアップデートの実行については、「ZooKeeper クラスターのローリングアップデートの実行」を参考してください。

3.1.29. CA 証明書の手動更新
リンクのコピー

Kafka.spec.clusterCa.generateCertificateAuthority および Kafka.spec.clientsCa.generateCertificateAuthority オブジェクトが false に設定されていない限り、クラスターおよびクライアント CA 証明書は、それぞれの証明書の更新期間の開始時に自動で更新されます。セキュリティー上の理由で必要であれば、証明書の更新期間が始まる前に、これらの証明書のいずれかまたは両方を手動で更新できます。更新された証明書は、古い証明書と同じ秘密鍵を使用します。

前提条件

Cluster Operator が稼働している必要があります。
CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。

手順

strimzi.io/force-renew アノテーションを、更新対象の CA 証明書が含まれる Secret に適用します。

Expand

証明書	Secret	annotate コマンド
クラスター CA	<cluster-name>-cluster-ca-cert	`oc annotate secret <cluster-name>-cluster-ca-cert strimzi.io/force-renew=true`
クライアント CA	<cluster-name>-clients-ca-cert	`oc annotate secret <cluster-name>-clients-ca-cert strimzi.io/force-renew=true`

次回の調整で、アノテーションを付けた Secret の新規 CA 証明書が Cluster Operator によって生成されます。メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新規 CA 証明書が生成されます。

Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。

その他のリソース

3.1.30. 秘密鍵の置換
リンクのコピー

クラスター CA およびクライアント CA 証明書によって使用される秘密鍵を交換できます。秘密鍵を交換すると、Cluster Operator は新しい秘密鍵の新規 CA 証明書を生成します。

前提条件

Cluster Operator が稼働している必要があります。
CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。

手順

strimzi.io/force-replace アノテーションを、更新対象の秘密鍵が含まれる Secret に適用します。

Expand

秘密鍵	Secret	annotate コマンド
クラスター CA	<cluster-name>-cluster-ca	`oc annotate secret <cluster-name>-cluster-ca strimzi.io/force-replace=true`
クライアント CA	<cluster-name>-clients-ca	`oc annotate secret <cluster-name>-clients-ca strimzi.io/force-replace=true`

次回の調整時に、Cluster Operator は以下を生成します。

アノテーションを付けた Secret の新しい秘密鍵
新規 CA 証明書

メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新しい秘密鍵と CA 証明書が生成されます。

Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。

その他のリソース

3.1.31. Kafka クラスターの一部として作成されたリソースの一覧
リンクのコピー

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

cluster-name-kafka: Kafka ブローカー Pod の管理を担当する StatefulSet。
cluster-name-kafka-brokers: DNS が Kafka ブローカー Pod の IP アドレスを直接解決するのに必要なサービス。
cluster-name-kafka-bootstrap: サービスは、Kafka クライアントのブートストラップサーバーとして使用できます。
cluster-name-kafka-external-bootstrap: OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。
cluster-name-kafka-pod-id: トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。
cluster-name-kafka-external-bootstrap: OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効になっていて、タイプ route に設定されている場合にのみ作成されます。
cluster-name-kafka-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。
strimzi-namespace-name-cluster-name-kafka-init: Kafka ブローカーによって使用されるクラスターロールバインディング。
cluster-name-zookeeper: ZooKeeper ノード Pod の管理を担当する StatefulSet。
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 ノードに設定された Pod の Disruption Budget。
cluster-name-entity-operator: Topic および User Operator とのデプロイメント。このリソースは、Cluster Operator によって Entity Operator がデプロイされた場合のみ作成されます。
cluster-name-entity-topic-operator-config: Topic Operator の補助設定のある ConfigMap。このリソースは、Cluster Operator によって Entity Operator がデプロイされた場合のみ作成されます。
cluster-name-entity-user-operator-config: User Operator の補助設定のある ConfigMap。このリソースは、Cluster Operator によって Entity Operator がデプロイされた場合のみ作成されます。
cluster-name-entity-operator-certs: Kafka および ZooKeeper と通信するための Entity Operator キーのあるシークレット。このリソースは、Cluster Operator によって Entity Operator がデプロイされた場合のみ作成されます。
cluster-name-entity-operator: Entity Operator によって使用されるサービスアカウント。
strimzi-cluster-name-topic-operator: Entity Operator によって使用されるロールバインディング。
strimzi-cluster-name-user-operator: Entity Operator によって使用されるロールバインディング。
cluster-name-cluster-ca: クラスター通信の暗号化に使用されるクラスター CA のあるシークレット。
cluster-name-cluster-ca-cert: クラスター CA 公開鍵のあるシークレット。このキーは、Kafka ブローカーのアイデンティティーの検証に使用できます。
cluster-name-clients-ca: Kafka ブローカーと Kafka クライアントとの間の通信を暗号化するために使用されるクライアント CA のあるシークレット。
cluster-name-clients-ca-cert: クライアント CA 公開鍵のあるシークレット。このキーは、Kafka ブローカーのアイデンティティーの検証に使用できます。
cluster-name-cluster-operator-certs: Kafka および ZooKeeper と通信するための Cluster Operator キーのあるシークレット。
data-cluster-name-kafka-idx: Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。
data-id-cluster-name-kafka-idx: Kafka ブローカー Pod idx のデータを保存するために使用されるボリューム id の永続ボリューム要求です。このリソースは、永続ボリュームをプロビジョニングしてデータを保存する場合に、JBOD ボリュームに永続ストレージが選択された場合のみ作成されます。
data-cluster-name-zookeeper-idx: ZooKeeper ノード Pod idx のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。
cluster-name-jmx: Kafka ブローカーポートのセキュア化に使用される JMX ユーザー名およびパスワードのあるシークレット。

3.2. Kafka Connect クラスターの設定
リンクのコピー

KafkaConnect リソースの完全なスキーマは「KafkaConnect スキーマ参照」に記載されています。指定の KafkaConnect リソースに適用されたすべてのラベルは、Kafka Connect クラスターを構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。

3.2.1. レプリカ
リンクのコピー

Kafka Connect クラスターは、1 つ以上のノードで構成されます。ノードの数は KafkaConnect および KafkaConnectS2I リソースで定義されます。Kafka Connect クラスターを複数のノードで実行すると、可用性とスケーラビリティーが向上します。ただし、OpenShift で Kafka Connect を実行する場合は、高可用性のために Kafka Connect で複数のノードを実行する必要はありません。Kafka Connect がデプロイされたノードがクラッシュした場合、OpenShift によって Kafka Connect Pod が別のノードに自動的に再スケジュールされます。ただし、他のノードがすでに稼働しているため、Kafka Connect を複数のノードで実行すると、より高速なフェイルオーバーを実現できます。

3.2.1.1. ノード数の設定
リンクのコピー

Kafka Connect ノードの数は、KafkaConnect.spec および KafkaConnectS2I.spec の replicas プロパティーを使用して設定されます。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの replicas プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  replicas: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  replicas: 3
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.2. ブートストラップサーバー
リンクのコピー

Kafka Connect クラスターは、常に Kafka クラスターと組み合わせて動作します。Kafka クラスターはブートストラップサーバーのリストとして指定されます。OpenShift では、そのリストに cluster-name-kafka-bootstrap という名前の Kafka クラスターブートストラップサービスが含まれ、さらに平文トラフィックの場合はポート 9092、暗号化されたトラフィックの場合はポート 9093 が含まれることが理想的です。

ブートストラップサーバーのリストは、KafkaConnect.spec および KafkaConnectS2I.spec の bootstrapServers プロパティーで設定されます。サーバーは、1 つ以上の Kafka ブローカーを指定するコンマ区切りリスト、または hostname:_port_ ペアとして指定される Kafka ブローカーを示すサービスとして定義される必要があります。

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

3.2.2.1. ブートストラップサーバーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの bootstrapServers プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.3. TLS を使用した Kafka ブローカーへの接続
リンクのコピー

デフォルトでは、Kafka Connect はプレーンテキスト接続を使用して Kafka ブローカーへの接続を試みます。TLS を使用する場合は、追加の設定が必要です。

3.2.3.1. Kafka Connect での TLS サポート
リンクのコピー

TLS サポートは、KafkaConnect.spec および KafkaConnectS2I.spec の tls プロパティーで設定されます。tls プロパティーには、保存される証明書のキー名があるシークレットのリストが含まれます。証明書は X509 形式で保存する必要があります。

複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-other-secret
        certificate: certificate.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-other-secret
        certificate: certificate.crt
  # ...

Copy to Clipboard

Toggle word wrap

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

同じシークレットに複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-secret
        certificate: ca2.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-secret
        certificate: ca2.crt
  # ...

Copy to Clipboard

Toggle word wrap

3.2.3.2. Kafka Connect での TLS の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS サーバー認証に使用される証明書の Secret の名前と、Secret に保存された証明書のキー (存在する場合)。

手順

(任意手順): 認証で使用される TLS 証明書が存在しない場合はファイルで準備し、Secret を作成します。
注記
Kafka クラスターの Cluster Operator によって作成されるシークレットは直接使用されることがあります。
oc create を使用してこれを行うことができます。
```
oc create secret generic my-secret --from-file=my-file.crt
```
```
oc create secret generic my-secret --from-file=my-file.crt
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの tls プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-cert
        certificate: ca.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-cert
        certificate: ca.crt
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.4. 認証での Kafka ブローカーへの接続
リンクのコピー

デフォルトでは、Kafka Connect は認証なしで Kafka ブローカーへの接続を試みます。認証は KafkaConnect および KafkaConnectS2I リソースにより有効になります。

3.2.4.1. Kafka Connect での認証サポート
リンクのコピー

認証は、KafkaConnect.spec および KafkaConnectS2I.spec の authentication プロパティーで設定されます。authentication プロパティーによって、使用する認証メカニズムのタイプと、メカニズムに応じた追加設定の詳細が指定されます。サポートされる認証タイプは次のとおりです。

TLS クライアント認証
SCRAM-SHA-512 メカニズムを使用した SASL ベースの認証
PLAIN メカニズムを使用した SASL ベースの認証
OAuth 2.0 のトークンベースの認証

3.2.4.1.1. TLS クライアント認証
リンクのコピー

TLS クライアント認証を使用するには、type プロパティーを tls の値に設定します。TLS クライアント認証は TLS 証明書を使用して認証します。証明書は certificateAndKey プロパティーで指定され、常に OpenShift シークレットからロードされます。シークレットでは、公開鍵と秘密鍵の 2 つの鍵を使用して証明書を X509 形式で保存する必要があります。

注記

TLS クライアント認証は TLS 接続でのみ使用できます。Kafka Connect の TLS 設定の詳細は「TLS を使用した Kafka ブローカーへの接続」を参照してください。

TLS クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

Copy to Clipboard

Toggle word wrap

3.2.4.1.2. SASL ベースの SCRAM-SHA-512 認証
リンクのコピー

Kafka Connect で SASL ベースの SCRAM-SHA-512 認証が使用されるようにするには、type プロパティーを scram-sha-512 に設定します。この認証メカニズムには、ユーザー名とパスワードが必要です。

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの SCRAM-SHA-512 クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.2.4.1.3. SASL ベースの PLAIN 認証
リンクのコピー

Kafka Connect で SASL ベースの PLAIN 認証が使用されるようにするには、type プロパティーを plain に設定します。この認証メカニズムには、ユーザー名とパスワードが必要です。

警告

SASL PLAIN メカニズムでは、ネットワーク全体でユーザー名とパスワードがプレーンテキストで転送されます。TLS 暗号化が有効になっている場合にのみ SASL PLAIN 認証を使用します。

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーにはそのような Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの PLAIN クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: plain
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: plain
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.2.4.2. Kafka Connect での TLS クライアント認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS クライアント認証に使用される公開鍵と秘密鍵がある Secret、および Secret に保存される公開鍵と秘密鍵のキー (存在する場合)。

手順

(任意手順): 認証に使用される鍵が存在しない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
oc create を使用してこれを行うことができます。
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: my-public.crt
      key: my-private.key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: my-public.crt
      key: my-private.key
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.4.3. Kafka Connect での SCRAM-SHA-512 認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
認証に使用するユーザーのユーザー名。
認証に使用されるパスワードがある Secret の名前と、Secret に保存されたパスワードのキー (存在する場合)。

手順

(任意手順): 認証で使用されるパスワードがない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
oc create を使用してこれを行うことができます。
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
OpenShift では oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.5. Kafka Connect の設定
リンクのコピー

AMQ Streams では、Apache Kafka ドキュメントに記載されている特定のオプションを編集して、Apache Kafka Connect ノードの設定をカスタマイズできます。

以下に関連する設定オプションは設定できません。

Kafka クラスターブートストラップアドレス
セキュリティー (暗号化、認証、および承認)
リスナー / REST インターフェースの設定
プラグインパスの設定

これらのオプションは AMQ Streams によって自動的に設定されます。

3.2.5.1. Kafka Connect の設定
リンクのコピー

Kafka Connect は、KafkaConnect.spec および KafkaConnectS2I.spec の config プロパティーを使用して設定されます。このプロパティーには、Kafka Connect 設定オプションがキーとして含まれます。値は以下の JSON タイプのいずれかになります。

String
Number
ブール値

AMQ Streams で直接管理されるオプションを除き、Apache Kafka ドキュメントに記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションは禁止されています。

ssl.
sasl.
security.
listeners
plugin.path
rest.
bootstrap.servers

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka Connect に渡されます。

重要

提供された config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Connect クラスターが起動しなかったり、不安定になる可能性があります。この状況で、KafkaConnect.spec.config または KafkaConnectS2I.spec.config オブジェクトの設定を修正すると、Cluster Operator は新しい設定をすべての Kafka Connect ノードにロールアウトできます。

以下のオプションにはデフォルト値があります。

group.id、デフォルト値 connect-cluster
offset.storage.topic、デフォルト値 connect-cluster-offsets
config.storage.topic、デフォルト値 connect-cluster-configs
status.storage.topic、デフォルト値 connect-cluster-status
key.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter
value.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter

これらのオプションは、KafkaConnect.spec.config または KafkaConnectS2I.spec.config プロパティーになかった場合に自動的に設定されます。

Kafka Connect の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

Copy to Clipboard

Toggle word wrap

3.2.5.2. 複数インスタンスの Kafka Connect 設定
リンクのコピー

Kafka Connect のインスタンスを複数実行している場合は、以下のプロパティーのデフォルト設定に注意してください。

# ...
  group.id: connect-cluster 
  offset.storage.topic: connect-cluster-offsets 
  config.storage.topic: connect-cluster-configs 
  status.storage.topic: connect-cluster-status  
# ...

# ...
  group.id: connect-cluster


  offset.storage.topic: connect-cluster-offsets


  config.storage.topic: connect-cluster-configs


  status.storage.topic: connect-cluster-status


# ...

Copy to Clipboard

Toggle word wrap

1: インスタンスが属する Kafka Connect クラスターグループ。
2: コネクターオフセットを保存する Kafka トピック。
3: コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4: コネクターおよびタスクステータスの更新を保存する Kafka トピック。

注記

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

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

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

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

3.2.5.3. Kafka Connect の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの config プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.6. CPU およびメモリーリソース
リンクのコピー

AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。

AMQ Streams では、以下の 2 つのタイプのリソースがサポートされます。

CPU
メモリー

AMQ Streams では、CPU およびメモリーリソースの指定に OpenShift 構文が使用されます。

3.2.6.1. リソースの制限および要求
リンクのコピー

リソースの制限と要求は、以下のリソースで resources プロパティーを使用して設定されます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

その他のリソース

OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。

3.2.6.1.1. リソース要求
リンクのコピー

要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。

重要

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

リソース要求は requests プロパティーで指定されます。AMQ Streams では、現在以下のリソース要求がサポートされます。

cpu
memory

1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。

すべてのリソースを対象とするリソース要求の設定例

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.2.6.1.2. リソース制限
リンクのコピー

リソース制限は limits プロパティーで指定されます。AMQ Streams では、現在以下のリソース制限がサポートされます。

cpu
memory

1 つまたは複数のサポートされる制限に対してリソースを設定できます。

リソース制限の設定例

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.2.6.1.3. サポートされる CPU 形式
リンクのコピー

CPU の要求および制限は以下の形式でサポートされます。

整数値 (5 CPU コア) または少数 (2.5 CPU コア) の CPU コアの数。
数値または ミリ CPU / ミリコア (100m)。1000 ミリコア は 1 CPU コアと同じです。

CPU ユニットの例

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

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

Copy to Clipboard

Toggle word wrap

注記

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

その他のリソース

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

3.2.6.1.4. サポートされるメモリー形式
リンクのコピー

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。

メモリーをメガバイトで指定するには、M 接尾辞を使用します。例: 1000M
メモリーをギガバイトで指定するには、G 接尾辞を使用します。例: 1G
メモリーをメビバイトで指定するには、Mi 接尾辞を使用します。例: 1000Mi
メモリーをギビバイトで指定するには、Gi 接尾辞を使用します。例: 1Gi

異なるメモリー単位の使用例

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

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

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.2.6.2. リソース要求および制限の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.2.7. Kafka Connect ロガー
リンクのコピー

Kafka Connect には独自の設定可能なロガーがあります。

connect.root.logger.level
log4j.logger.org.reflections

Kafka Connect では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

Copy to Clipboard

Toggle word wrap

外部ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

Copy to Clipboard

Toggle word wrap

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。GC ロギングの詳細は「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.2.8. Healthcheck
リンクのコピー

OpenShift では、以下の 2 つのタイプのおよびヘルスチェックプローブがサポートされます。

Liveness プローブ
Readiness プローブ

プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。AMQ Streams コンポーネントでは、両タイプのプローブが使用されます。

ユーザーは、Liveness および Readiness プローブに選択されたオプションを設定できます。

3.2.8.1. ヘルスチェックの設定
リンクのコピー

Liveness および Readiness プローブは、以下のリソースの livenessProbe および readinessProbe プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

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

initialDelaySeconds
timeoutSeconds
periodSeconds
successThreshold
failureThreshold

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

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

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

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

Copy to Clipboard

Toggle word wrap

3.2.8.2. ヘルスチェックの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの livenessProbe または readinessProbe プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.9. Prometheus メトリクス
リンクのコピー

Prometheus および Grafana の設定に関する詳細は「メトリクス」を参照してください。

3.2.9.1. メトリクスの設定
リンクのコピー

Prometheus メトリクスは、以下のリソースに metrics プロパティーを設定して有効化されます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec

追加設定なしでメトリクスを有効にする例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

metrics プロパティーには、Prometheus JMX エスクポーターの追加設定が含まれることがあります。

追加の Prometheus JMX Exporter 設定を使用したメトリクスを有効化する例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

3.2.9.2. Prometheus メトリクスの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの metrics プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.10. JVM オプション
リンクのコピー

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

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

3.2.10.1. JVM 設定
リンクのコピー

JVM オプションは、以下のリソースの jvmOptions プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

使用可能な JVM オプションの選択されたサブセットのみを設定できます。以下のオプションがサポートされます。

-Xms および -Xmx

-Xms は、JVM の起動時に最初に割り当てられる最小ヒープサイズを設定します。-Xmx は、最大ヒープサイズを設定します。

注記

-Xms および -Xmx に使用されるデフォルト値は、コンテナーにメモリー要求の制限が設定されているかどうかによって異なります。

メモリーの制限がある場合は、JVM の最小および最大メモリーは制限に対応する値に設定されます。
メモリーの制限がない場合、JVM の最小メモリーは 128M に設定され、JVM の最大メモリーは定義されません。これにより、JVM のメモリーを必要に応じて拡張できます。これは、テストおよび開発での単一ノード環境に適しています。

重要

-Xmx を明示的に設定するには、以下の点に注意する必要があります。

JVM のメモリー使用量の合計は、-Xmx によって設定された最大ヒープの約 4 倍になります。
適切な OpenShift メモリー制限を設定せずに -Xmx が設定された場合、OpenShift ノードで、実行されている他の Pod からメモリー不足が発生するとコンテナーが強制終了される可能性があります。
適切な OpenShift メモリー要求を設定せずに -Xmx が設定された場合、コンテナーはメモリー不足のノードにスケジュールされる可能性があります。この場合、コンテナーは起動せずにクラッシュします (-Xms が -Xmx に設定されている場合は即座にクラッシュし、そうでない場合はその後にクラッシュします)。

-Xmx を明示的に設定する場合は、以下を行うことが推奨されます。

メモリー要求とメモリー制限を同じ値に設定します。
-Xmx の 4.5 倍以上のメモリー要求を使用します。
-Xms を -Xmx と同じ値に設定することを検討してください。

重要

-Xmx および -Xms の設定例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

上記の例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB になります。

-server

-server はサーバー JVM を有効にします。このオプションは true または false に設定できます。

-server の設定例 (抜粋)

# ...
jvmOptions:
  "-server": true
# ...

# ...
jvmOptions:
  "-server": true
# ...

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

-XX

-XX オブジェクトの使用例

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

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

Copy to Clipboard

Toggle word wrap

上記の設定例の場合、JVM オプションは以下のようになります。

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

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

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

3.2.10.1.1. ガベッジコレクターのロギング
リンクのコピー

GC ロギングを有効にする例

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

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

Copy to Clipboard

Toggle word wrap

3.2.10.2. JVM オプションの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、または KafkaBridgeリソースの jvmOptions プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.11. コンテナーイメージ
リンクのコピー

3.2.11.1. コンテナーイメージの設定
リンクのコピー

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

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

3.2.11.1.1. Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定
リンクのコピー

STRIMZI_KAFKA_IMAGES
STRIMZI_KAFKA_CONNECT_IMAGES
STRIMZI_KAFKA_CONNECT_S2I_IMAGES
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

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

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

Kafka の場合は spec.kafka.image および spec.kafka.version。
Kafka Connect、Kafka Connect S2I、および Kafka MirrorMaker の場合は spec.image および spec.version。

警告

3.2.11.1.2. 他のリソースでの image プロパティーの設定
リンクのコピー

Kafka ブローカー TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_KAFKA_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
ZooKeeper ノードの場合:
ZooKeeper ノードの TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ZOOKEEPER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Topic Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
User Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
Entity Operator TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Exporter の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Bridge の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.4.0 コンテナーイメージ。
Kafka ブローカーイニシャライザーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。

警告

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

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

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

Copy to Clipboard

Toggle word wrap

3.2.11.2. コンテナーイメージの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの image プロパティーを編集します。以下に例を示します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.12. Pod スケジューリングの設定
リンクのコピー

重要

3.2.12.1. 他のアプリケーションに基づく Pod のスケジューリング
リンクのコピー

3.2.12.1.1. 重要なアプリケーションがノードを共有しないようにする
リンクのコピー

3.2.12.1.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.2.12.1.3. Kafka コンポーネントでの Pod の非アフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.12.2. 特定のノードへの Pod のスケジューリング
リンクのコピー

3.2.12.2.1. ノードのスケジューリング
リンクのコピー

3.2.12.2.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.2.12.2.3. Kafka コンポーネントでのノードのアフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.12.3. 専用ノードの使用
リンクのコピー

3.2.12.3.1. 専用ノード
リンクのコピー

専用ノードで Kafka Pod をスケジュールするには、ノードのアフィニティーと許容 (toleration) を設定します。

3.2.12.3.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.2.12.3.3. 許容 (Toleration)
リンクのコピー

許容 (Toleration) は、以下のリソースの tolerations プロパティーを使用して設定できます。

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

tolerations プロパティーの形式は、OpenShift の仕様に準拠します。詳細は、Kubernetes の「Taints and Tolerations」を参照してください。

3.2.12.3.4. 専用ノードの設定と Pod のスケジューリング
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.2.13. 外部設定およびシークレットの使用
リンクのコピー

コネクターは、Kafka Connect の HTTP REST インターフェースまたは KafkaConnectors を使用して作成、再設定、および削除されます。これらの方法の詳細は、「コネクターの作成および管理」を参照してください。コネクター設定は、HTTP リクエストの一部として Kafka Connect に渡され、Kafka 自体に保存されます。

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

3.2.13.1. コネクター設定の外部への保存
リンクのコピー

ConfigMap またはシークレットをボリュームまたは環境変数として Kafka Connect Pod にマウントできます。ボリュームおよび環境変数は、KafkaConnect.spec および KafkaConnectS2I.spec の externalConfiguration プロパティーで設定されます。

3.2.13.1.1. 環境変数としての外部設定
リンクのコピー

env プロパティーは、1 つ以上の環境変数を指定するために使用されます。これらの変数には ConfigMap または Secret からの値を含めることができます。

注記

ユーザー定義の環境変数に、KAFKA_ または STRIMZI_ で始まる名前を付けることはできません。

シークレットから環境変数に値をマウントするには、以下の例のように valueFrom プロパティーおよび secretKeyRef を使用します。

シークレットからの値に設定された環境変数の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret
            key: my-key

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret
            key: my-key

Copy to Clipboard

Toggle word wrap

シークレットを環境変数にマウントする一般的なユースケースとして、コネクターが Amazon AWS と通信する必要があり、クレデンシャルで AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY 環境変数を読み取る必要がある場合が挙げられます。

ConfigMap から環境変数に値をマウントするには、以下の例のように valueFromプロパティーで configMapKeyRef を使用します。

ConfigMap からの値に設定された環境変数の例

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

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

Copy to Clipboard

Toggle word wrap

3.2.13.1.2. ボリュームとしての外部設定
リンクのコピー

ConfigMap またはシークレットをボリュームとして Kafka Connect Pod にマウントすることもできます。以下の場合、環境変数の代わりにボリュームを使用すると便利です。

TLS 証明書でのトラストストアまたはキーストアのマウント
Kafka Connect コネクターの設定に使用されるプロパティーファイルのマウント

externalConfiguration リソースの volumes プロパティーで、ボリュームとしてマウントされる ConfigMap またはシークレットをリストします。各ボリュームは name プロパティーに名前を指定し、ConfigMap またはシークレットを参照する必要があります。

外部設定のあるボリュームの例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    volumes:
      - name: connector1
        configMap:
          name: connector1-configuration
      - name: connector1-certificates
        secret:
          secretName: connector1-certificates

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    volumes:
      - name: connector1
        configMap:
          name: connector1-configuration
      - name: connector1-certificates
        secret:
          secretName: connector1-certificates

Copy to Clipboard

Toggle word wrap

ボリュームは、パス /opt/kafka/external-configuration/<volume-name> の Kafka Connect コンテナー内にマウントされます。たとえば、connector1 という名前のボリュームのファイルは /opt/kafka/external-configuration/connector1 ディレクトリーにあります。

コネクター設定でマウントされたプロパティーファイルから値を読み取るには、FileConfigProvider を使用する必要があります。

3.2.13.2. 環境変数としてのシークレットのマウント
リンクのコピー

OpenShift シークレットを作成し、これを環境変数として Kafka Connect にマウントできます。

前提条件

稼働中の Cluster Operator。

手順

環境変数としてマウントされる情報が含まれるシークレットを作成します。以下に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

Copy to Clipboard

Toggle word wrap

Kafka Connect リソースを作成または編集します。シークレットを参照するように、KafkaConnect または KafkaConnectS2I カスタムリソースの externalConfiguration セクションを設定します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

Copy to Clipboard

Toggle word wrap

変更を Kafka Connect デプロイメントに適用します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

コネクターの開発時に、環境変数が使用できるようになりました。

その他のリソース

Kafka Connect の外部設定の詳細は、「ExternalConfiguration スキーマ参照」を参照してください。

3.2.13.3. シークレットのボリュームとしてのマウント
リンクのコピー

OpenShift シークレットを作成してボリュームとして Kafka Connect にマウントし、これを使用して Kafka Connect コネクターを設定します。

前提条件

稼働中の Cluster Operator。

手順

コネクター設定の設定オプションを定義するプロパティーファイルが含まれるシークレットを作成します。以下に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |-
    dbUsername: my-user
    dbPassword: my-password

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |-
    dbUsername: my-user
    dbPassword: my-password

Copy to Clipboard

Toggle word wrap

Kafka Connect リソースを作成または編集します。シークレットを参照するように、config セクションの FileConfigProvider と、KafkaConnect または KafkaConnectS2I カスタムリソースの externalConfiguration セクションを設定します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider
  #...
  externalConfiguration:
    volumes:
      - name: connector-config
        secret:
          secretName: mysecret

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider
  #...
  externalConfiguration:
    volumes:
      - name: connector-config
        secret:
          secretName: mysecret

Copy to Clipboard

Toggle word wrap

変更を Kafka Connect デプロイメントに適用します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

コネクター設定のある JSON ペイロードのマウントされたプロパティーファイルから値を使用します。以下に例を示します。

{
   "name":"my-connector",
   "config":{
      "connector.class":"MyDbConnector",
      "tasks.max":"3",
      "database": "my-postgresql:5432"
      "username":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbUsername}",
      "password":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbPassword}",
      # ...
   }
}

{
   "name":"my-connector",
   "config":{
      "connector.class":"MyDbConnector",
      "tasks.max":"3",
      "database": "my-postgresql:5432"
      "username":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbUsername}",
      "password":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbPassword}",
      # ...
   }
}

Copy to Clipboard

Toggle word wrap

その他のリソース

Kafka Connect の外部設定の詳細は、「ExternalConfiguration スキーマ参照」を参照してください。

3.2.14. KafkaConnector リソースの有効化
リンクのコピー

Kafka Connect クラスターの KafkaConnectors を有効にするには、strimzi.io/use-connector-resources アノテーションを KafkaConnect または KafkaConnectS2I カスタムリソースに追加します。

前提条件

稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースを編集します。strimzi.io/use-connector-resources アノテーションを追加します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect-cluster
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect-cluster
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...

Copy to Clipboard

Toggle word wrap

oc apply を使用してリソースを作成または更新します。
```
oc apply -f kafka-connect.yaml
```
```
oc apply -f kafka-connect.yaml
```
Copy to Clipboard Toggle word wrap

その他のリソース

3.2.15. 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。

3.3. Source2Image がサポートされる Kafka Connect クラスター
リンクのコピー

KafkaConnectS2I リソースの完全なスキーマは「KafkaConnectS2I スキーマ参照」に記載されています。指定の KafkaConnectS2I リソースに適用されたすべてのラベルは、Source2Image がサポートされる Kafka Connect クラスターを構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。

3.3.1. レプリカ
リンクのコピー

3.3.1.1. ノード数の設定
リンクのコピー

Kafka Connect ノードの数は、KafkaConnect.spec および KafkaConnectS2I.spec の replicas プロパティーを使用して設定されます。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの replicas プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  replicas: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  replicas: 3
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.2. ブートストラップサーバー
リンクのコピー

3.3.2.1. ブートストラップサーバーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの bootstrapServers プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.3. TLS を使用した Kafka ブローカーへの接続
リンクのコピー

3.3.3.1. Kafka Connect での TLS サポート
リンクのコピー

複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-other-secret
        certificate: certificate.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-other-secret
        certificate: certificate.crt
  # ...

Copy to Clipboard

Toggle word wrap

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

同じシークレットに複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-secret
        certificate: ca2.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
metadata:
  name: my-cluster
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-secret
        certificate: ca.crt
      - secretName: my-secret
        certificate: ca2.crt
  # ...

Copy to Clipboard

Toggle word wrap

3.3.3.2. Kafka Connect での TLS の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS サーバー認証に使用される証明書の Secret の名前と、Secret に保存された証明書のキー (存在する場合)。

手順

(任意手順): 認証で使用される TLS 証明書が存在しない場合はファイルで準備し、Secret を作成します。
注記
Kafka クラスターの Cluster Operator によって作成されるシークレットは直接使用されることがあります。
oc create を使用してこれを行うことができます。
```
oc create secret generic my-secret --from-file=my-file.crt
```
```
oc create secret generic my-secret --from-file=my-file.crt
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの tls プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-cert
        certificate: ca.crt
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-cert
        certificate: ca.crt
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.4. 認証での Kafka ブローカーへの接続
リンクのコピー

3.3.4.1. Kafka Connect での認証サポート
リンクのコピー

TLS クライアント認証
SCRAM-SHA-512 メカニズムを使用した SASL ベースの認証
PLAIN メカニズムを使用した SASL ベースの認証
OAuth 2.0 のトークンベースの認証

3.3.4.1.1. TLS クライアント認証
リンクのコピー

注記

TLS クライアント認証は TLS 接続でのみ使用できます。Kafka Connect の TLS 設定の詳細は、「TLS を使用した Kafka ブローカーへの接続」を参照してください。

TLS クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

Copy to Clipboard

Toggle word wrap

3.3.4.1.2. SASL ベースの SCRAM-SHA-512 認証
リンクのコピー

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの SCRAM-SHA-512 クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.3.4.1.3. SASL ベースの PLAIN 認証
リンクのコピー

警告

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーにはそのような Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの PLAIN クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: plain
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-cluster
spec:
  # ...
  authentication:
    type: plain
    username: my-connect-user
    passwordSecret:
      secretName: my-connect-user
      password: my-connect-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.3.4.2. Kafka Connect での TLS クライアント認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS クライアント認証に使用される公開鍵と秘密鍵がある Secret、および Secret に保存される公開鍵と秘密鍵のキー (存在する場合)。

手順

(任意手順): 認証に使用される鍵が存在しない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
oc create を使用してこれを行うことができます。
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: my-public.crt
      key: my-private.key
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: my-public.crt
      key: my-private.key
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.4.3. Kafka Connect での SCRAM-SHA-512 認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
認証に使用するユーザーのユーザー名。
認証に使用されるパスワードがある Secret の名前と、Secret に保存されたパスワードのキー (存在する場合)。

手順

(任意手順): 認証で使用されるパスワードがない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
oc create を使用してこれを行うことができます。
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
Copy to Clipboard Toggle word wrap

KafkaConnect または KafkaConnectS2I リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
OpenShift では oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.5. Kafka Connect の設定
リンクのコピー

AMQ Streams では、Apache Kafka ドキュメントに記載されている特定のオプションを編集して、Apache Kafka Connect ノードの設定をカスタマイズできます。

以下に関連する設定オプションは設定できません。

Kafka クラスターブートストラップアドレス
セキュリティー (暗号化、認証、および承認)
リスナー / REST インターフェースの設定
プラグインパスの設定

これらのオプションは AMQ Streams によって自動的に設定されます。

3.3.5.1. Kafka Connect の設定
リンクのコピー

String
Number
ブール値

ssl.
sasl.
security.
listeners
plugin.path
rest.
bootstrap.servers

重要

以下のオプションにはデフォルト値があります。

group.id、デフォルト値 connect-cluster
offset.storage.topic、デフォルト値 connect-cluster-offsets
config.storage.topic、デフォルト値 connect-cluster-configs
status.storage.topic、デフォルト値 connect-cluster-status
key.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter
value.converter、デフォルト値 org.apache.kafka.connect.json.JsonConverter

これらのオプションは、KafkaConnect.spec.config または KafkaConnectS2I.spec.config プロパティーになかった場合に自動的に設定されます。

Kafka Connect の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

Copy to Clipboard

Toggle word wrap

3.3.5.2. 複数インスタンスの Kafka Connect 設定
リンクのコピー

Kafka Connect のインスタンスを複数実行している場合は、以下のプロパティーのデフォルト設定に注意してください。

# ...
  group.id: connect-cluster 
  offset.storage.topic: connect-cluster-offsets 
  config.storage.topic: connect-cluster-configs 
  status.storage.topic: connect-cluster-status  
# ...

# ...
  group.id: connect-cluster


  offset.storage.topic: connect-cluster-offsets


  config.storage.topic: connect-cluster-configs


  status.storage.topic: connect-cluster-status


# ...

Copy to Clipboard

Toggle word wrap

1: インスタンスが属する Kafka Connect クラスターグループ。
2: コネクターオフセットを保存する Kafka トピック。
3: コネクターおよびタスクステータスの設定を保存する Kafka トピック。
4: コネクターおよびタスクステータスの更新を保存する Kafka トピック。

注記

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

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

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

3.3.5.3. Kafka Connect の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースの config プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.6. CPU およびメモリーリソース
リンクのコピー

AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。

AMQ Streams では、以下の 2 つのタイプのリソースがサポートされます。

CPU
メモリー

AMQ Streams では、CPU およびメモリーリソースの指定に OpenShift 構文が使用されます。

3.3.6.1. リソースの制限および要求
リンクのコピー

リソースの制限と要求は、以下のリソースで resources プロパティーを使用して設定されます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

その他のリソース

OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。

3.3.6.1.1. リソース要求
リンクのコピー

要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。

重要

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

リソース要求は requests プロパティーで指定されます。AMQ Streams では、現在以下のリソース要求がサポートされます。

cpu
memory

1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。

すべてのリソースを対象とするリソース要求の設定例

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.3.6.1.2. リソース制限
リンクのコピー

リソース制限は limits プロパティーで指定されます。AMQ Streams では、現在以下のリソース制限がサポートされます。

cpu
memory

1 つまたは複数のサポートされる制限に対してリソースを設定できます。

リソース制限の設定例

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.3.6.1.3. サポートされる CPU 形式
リンクのコピー

CPU の要求および制限は以下の形式でサポートされます。

整数値 (5 CPU コア) または少数 (2.5 CPU コア) の CPU コアの数。
数値または ミリ CPU / ミリコア (100m)。1000 ミリコア は 1 CPU コアと同じです。

CPU ユニットの例

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

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

Copy to Clipboard

Toggle word wrap

注記

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

その他のリソース

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

3.3.6.1.4. サポートされるメモリー形式
リンクのコピー

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。

メモリーをメガバイトで指定するには、M 接尾辞を使用します。例: 1000M
メモリーをギガバイトで指定するには、G 接尾辞を使用します。例: 1G
メモリーをメビバイトで指定するには、Mi 接尾辞を使用します。例: 1000Mi
メモリーをギビバイトで指定するには、Gi 接尾辞を使用します。例: 1Gi

異なるメモリー単位の使用例

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

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

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.3.6.2. リソース要求および制限の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.3.7. S2I ロガーのある Kafka Connect
リンクのコピー

Source2Image がサポートされる Kafka Connect には独自の設定可能なロガーがあります。

connect.root.logger.level
log4j.logger.org.reflections

Kafka Connect では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

Copy to Clipboard

Toggle word wrap

外部ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnectS2I
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

Copy to Clipboard

Toggle word wrap

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。GC ロギングの詳細は「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.3.8. Healthcheck
リンクのコピー

OpenShift では、以下の 2 つのタイプのおよびヘルスチェックプローブがサポートされます。

Liveness プローブ
Readiness プローブ

プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。AMQ Streams コンポーネントでは、両タイプのプローブが使用されます。

ユーザーは、Liveness および Readiness プローブに選択されたオプションを設定できます。

3.3.8.1. ヘルスチェックの設定
リンクのコピー

Liveness および Readiness プローブは、以下のリソースの livenessProbe および readinessProbe プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

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

initialDelaySeconds
timeoutSeconds
periodSeconds
successThreshold
failureThreshold

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

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

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

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

Copy to Clipboard

Toggle word wrap

3.3.8.2. ヘルスチェックの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの livenessProbe または readinessProbe プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.9. Prometheus メトリクス
リンクのコピー

Prometheus および Grafana の設定に関する詳細は「メトリクス」を参照してください。

3.3.9.1. メトリクスの設定
リンクのコピー

Prometheus メトリクスは、以下のリソースに metrics プロパティーを設定して有効化されます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec

追加設定なしでメトリクスを有効にする例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics: {}
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

metrics プロパティーには、Prometheus JMX エスクポーターの追加設定が含まれることがあります。

追加の Prometheus JMX Exporter 設定を使用したメトリクスを有効化する例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metrics:
      lowercaseOutputName: true
      rules:
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
          name: "kafka_server_$1_$2_total"
        - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*, topic=(.+)><>Count"
          name: "kafka_server_$1_$2_total"
          labels:
            topic: "$3"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

3.3.9.2. Prometheus メトリクスの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの metrics プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    metrics:
      lowercaseOutputName: true
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.10. JVM オプション
リンクのコピー

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

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

3.3.10.1. JVM 設定
リンクのコピー

JVM オプションは、以下のリソースの jvmOptions プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

使用可能な JVM オプションの選択されたサブセットのみを設定できます。以下のオプションがサポートされます。

-Xms および -Xmx

-Xms は、JVM の起動時に最初に割り当てられる最小ヒープサイズを設定します。-Xmx は、最大ヒープサイズを設定します。

注記

-Xms および -Xmx に使用されるデフォルト値は、コンテナーにメモリー要求の制限が設定されているかどうかによって異なります。

メモリーの制限がある場合は、JVM の最小および最大メモリーは制限に対応する値に設定されます。
メモリーの制限がない場合、JVM の最小メモリーは 128M に設定され、JVM の最大メモリーは定義されません。これにより、JVM のメモリーを必要に応じて拡張できます。これは、テストおよび開発での単一ノード環境に適しています。

重要

-Xmx を明示的に設定するには、以下の点に注意する必要があります。

JVM のメモリー使用量の合計は、-Xmx によって設定された最大ヒープの約 4 倍になります。
適切な OpenShift メモリー制限を設定せずに -Xmx が設定された場合、OpenShift ノードで、実行されている他の Pod からメモリー不足が発生するとコンテナーが強制終了される可能性があります。
適切な OpenShift メモリー要求を設定せずに -Xmx が設定された場合、コンテナーはメモリー不足のノードにスケジュールされる可能性があります。この場合、コンテナーは起動せずにクラッシュします (-Xms が -Xmx に設定されている場合は即座にクラッシュし、そうでない場合はその後にクラッシュします)。

-Xmx を明示的に設定する場合は、以下を行うことが推奨されます。

メモリー要求とメモリー制限を同じ値に設定します。
-Xmx の 4.5 倍以上のメモリー要求を使用します。
-Xms を -Xmx と同じ値に設定することを検討してください。

重要

-Xmx および -Xms の設定例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

上記の例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB になります。

-server

-server はサーバー JVM を有効にします。このオプションは true または false に設定できます。

-server の設定例 (抜粋)

# ...
jvmOptions:
  "-server": true
# ...

# ...
jvmOptions:
  "-server": true
# ...

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

-XX

-XX オブジェクトの使用例

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

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

Copy to Clipboard

Toggle word wrap

上記の設定例の場合、JVM オプションは以下のようになります。

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

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

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

3.3.10.1.1. ガベッジコレクターのロギング
リンクのコピー

GC ロギングを有効にする例

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

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

Copy to Clipboard

Toggle word wrap

3.3.10.2. JVM オプションの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、または KafkaBridgeリソースの jvmOptions プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.11. コンテナーイメージ
リンクのコピー

3.3.11.1. コンテナーイメージの設定
リンクのコピー

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

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

3.3.11.1.1. Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定
リンクのコピー

STRIMZI_KAFKA_IMAGES
STRIMZI_KAFKA_CONNECT_IMAGES
STRIMZI_KAFKA_CONNECT_S2I_IMAGES
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

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

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

Kafka の場合は spec.kafka.image および spec.kafka.version。
Kafka Connect、Kafka Connect S2I、および Kafka MirrorMaker の場合は spec.image および spec.version。

警告

3.3.11.1.2. 他のリソースでの image プロパティーの設定
リンクのコピー

Kafka ブローカー TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_KAFKA_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
ZooKeeper ノードの場合:
ZooKeeper ノードの TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ZOOKEEPER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Topic Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
User Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
Entity Operator TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Exporter の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Bridge の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.4.0 コンテナーイメージ。
Kafka ブローカーイニシャライザーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。

警告

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

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

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

Copy to Clipboard

Toggle word wrap

3.3.11.2. コンテナーイメージの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの image プロパティーを編集します。以下に例を示します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.12. Pod スケジューリングの設定
リンクのコピー

重要

3.3.12.1. 他のアプリケーションに基づく Pod のスケジューリング
リンクのコピー

3.3.12.1.1. 重要なアプリケーションがノードを共有しないようにする
リンクのコピー

3.3.12.1.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.3.12.1.3. Kafka コンポーネントでの Pod の非アフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.12.2. 特定のノードへの Pod のスケジューリング
リンクのコピー

3.3.12.2.1. ノードのスケジューリング
リンクのコピー

3.3.12.2.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.3.12.2.3. Kafka コンポーネントでのノードのアフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.12.3. 専用ノードの使用
リンクのコピー

3.3.12.3.1. 専用ノード
リンクのコピー

専用ノードで Kafka Pod をスケジュールするには、ノードのアフィニティーと許容 (toleration) を設定します。

3.3.12.3.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.3.12.3.3. 許容 (Toleration)
リンクのコピー

許容 (Toleration) は、以下のリソースの tolerations プロパティーを使用して設定できます。

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

tolerations プロパティーの形式は、OpenShift の仕様に準拠します。詳細は、Kubernetes の「Taints and Tolerations」を参照してください。

3.3.12.3.4. 専用ノードの設定と Pod のスケジューリング
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.3.13. 外部設定およびシークレットの使用
リンクのコピー

3.3.13.1. コネクター設定の外部への保存
リンクのコピー

3.3.13.1.1. 環境変数としての外部設定
リンクのコピー

注記

ユーザー定義の環境変数に、KAFKA_ または STRIMZI_ で始まる名前を付けることはできません。

シークレットから環境変数に値をマウントするには、以下の例のように valueFrom プロパティーおよび secretKeyRef を使用します。

シークレットからの値に設定された環境変数の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret
            key: my-key

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret
            key: my-key

Copy to Clipboard

Toggle word wrap

ConfigMap から環境変数に値をマウントするには、以下の例のように valueFromプロパティーで configMapKeyRef を使用します。

ConfigMap からの値に設定された環境変数の例

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

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

Copy to Clipboard

Toggle word wrap

3.3.13.1.2. ボリュームとしての外部設定
リンクのコピー

TLS 証明書でのトラストストアまたはキーストアのマウント
Kafka Connect コネクターの設定に使用されるプロパティーファイルのマウント

外部設定のあるボリュームの例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    volumes:
      - name: connector1
        configMap:
          name: connector1-configuration
      - name: connector1-certificates
        secret:
          secretName: connector1-certificates

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    volumes:
      - name: connector1
        configMap:
          name: connector1-configuration
      - name: connector1-certificates
        secret:
          secretName: connector1-certificates

Copy to Clipboard

Toggle word wrap

コネクター設定でマウントされたプロパティーファイルから値を読み取るには、FileConfigProvider を使用する必要があります。

3.3.13.2. 環境変数としてのシークレットのマウント
リンクのコピー

OpenShift シークレットを作成し、これを環境変数として Kafka Connect にマウントできます。

前提条件

稼働中の Cluster Operator。

手順

環境変数としてマウントされる情報が含まれるシークレットを作成します。以下に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

Copy to Clipboard

Toggle word wrap

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

Copy to Clipboard

Toggle word wrap

変更を Kafka Connect デプロイメントに適用します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

コネクターの開発時に、環境変数が使用できるようになりました。

その他のリソース

Kafka Connect の外部設定の詳細は、「ExternalConfiguration スキーマ参照」を参照してください。

3.3.13.3. シークレットのボリュームとしてのマウント
リンクのコピー

OpenShift シークレットを作成してボリュームとして Kafka Connect にマウントし、これを使用して Kafka Connect コネクターを設定します。

前提条件

稼働中の Cluster Operator。

手順

コネクター設定の設定オプションを定義するプロパティーファイルが含まれるシークレットを作成します。以下に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |-
    dbUsername: my-user
    dbPassword: my-password

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |-
    dbUsername: my-user
    dbPassword: my-password

Copy to Clipboard

Toggle word wrap

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider
  #...
  externalConfiguration:
    volumes:
      - name: connector-config
        secret:
          secretName: mysecret

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider
  #...
  externalConfiguration:
    volumes:
      - name: connector-config
        secret:
          secretName: mysecret

Copy to Clipboard

Toggle word wrap

変更を Kafka Connect デプロイメントに適用します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

コネクター設定のある JSON ペイロードのマウントされたプロパティーファイルから値を使用します。以下に例を示します。

{
   "name":"my-connector",
   "config":{
      "connector.class":"MyDbConnector",
      "tasks.max":"3",
      "database": "my-postgresql:5432"
      "username":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbUsername}",
      "password":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbPassword}",
      # ...
   }
}

{
   "name":"my-connector",
   "config":{
      "connector.class":"MyDbConnector",
      "tasks.max":"3",
      "database": "my-postgresql:5432"
      "username":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbUsername}",
      "password":"${file:/opt/kafka/external-configuration/connector-config/connector.properties:dbPassword}",
      # ...
   }
}

Copy to Clipboard

Toggle word wrap

その他のリソース

Kafka Connect の外部設定の詳細は、「ExternalConfiguration スキーマ参照」を参照してください。

3.3.14. KafkaConnector リソースの有効化
リンクのコピー

前提条件

稼働中の Cluster Operator が必要です。

手順

KafkaConnect または KafkaConnectS2I リソースを編集します。strimzi.io/use-connector-resources アノテーションを追加します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect-cluster
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect-cluster
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...

Copy to Clipboard

Toggle word wrap

oc apply を使用してリソースを作成または更新します。
```
oc apply -f kafka-connect.yaml
```
```
oc apply -f kafka-connect.yaml
```
Copy to Clipboard Toggle word wrap

その他のリソース

3.3.15. Source2Image がサポートされる Kafka Connect クラスターの一部として作成されたリソースの一覧
リンクのコピー

以下のリソースは、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。

3.3.16. OpenShift ビルドおよび S2I (Source-to-Image) を使用したコンテナーイメージの作成
リンクのコピー

OpenShift ビルドと S2I (Source-to-Image) フレームワークを使用して、新しいコンテナーイメージを作成できます。OpenShift ビルドは、S2I がサポートされるビルダーイメージとともに、ユーザー提供のソースコードおよびバイナリーを取得し、これらを使用して新しいコンテナーイメージを構築します。構築後、コンテナーイメージは OpenShfit のローカルコンテナーイメージリポジトリーに格納され、デプロイメントで使用可能になります。

S2I がサポートされる Kafka Connect ビルダーイメージは、registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 イメージの一部として、Red Hat Container Catalog で提供されます。このS2I イメージは、バイナリー (プラグインおよびコネクターとともに) を取得し、/tmp/kafka-plugins/s2i ディレクトリーに格納されます。このディレクトリーから、Kafka Connect デプロイメントとともに使用できる新しい Kafka Connect イメージを作成します。改良されたイメージの使用を開始すると、Kafka Connect は /tmp/kafka-plugins/s2i ディレクトリーからサードパーティープラグインをロードします。

手順

コマンドラインで oc apply コマンドを使用し、Kafka Connect の S2I クラスターを作成およびデプロイします。
```
oc apply -f examples/kafka-connect/kafka-connect-s2i.yaml
```
```
oc apply -f examples/kafka-connect/kafka-connect-s2i.yaml
```
Copy to Clipboard Toggle word wrap

Kafka Connect プラグインでディレクトリーを作成します。

tree ./my-plugins/
./my-plugins/
├── debezium-connector-mongodb
│   ├── bson-3.4.2.jar
│   ├── CHANGELOG.md
│   ├── CONTRIBUTE.md
│   ├── COPYRIGHT.txt
│   ├── debezium-connector-mongodb-0.7.1.jar
│   ├── debezium-core-0.7.1.jar
│   ├── LICENSE.txt
│   ├── mongodb-driver-3.4.2.jar
│   ├── mongodb-driver-core-3.4.2.jar
│   └── README.md
├── debezium-connector-mysql
│   ├── CHANGELOG.md
│   ├── CONTRIBUTE.md
│   ├── COPYRIGHT.txt
│   ├── debezium-connector-mysql-0.7.1.jar
│   ├── debezium-core-0.7.1.jar
│   ├── LICENSE.txt
│   ├── mysql-binlog-connector-java-0.13.0.jar
│   ├── mysql-connector-java-5.1.40.jar
│   ├── README.md
│   └── wkb-1.0.2.jar
└── debezium-connector-postgres
    ├── CHANGELOG.md
    ├── CONTRIBUTE.md
    ├── COPYRIGHT.txt
    ├── debezium-connector-postgres-0.7.1.jar
    ├── debezium-core-0.7.1.jar
    ├── LICENSE.txt
    ├── postgresql-42.0.0.jar
    ├── protobuf-java-2.6.1.jar
    └── README.md

$ tree ./my-plugins/
./my-plugins/
├── debezium-connector-mongodb
│   ├── bson-3.4.2.jar
│   ├── CHANGELOG.md
│   ├── CONTRIBUTE.md
│   ├── COPYRIGHT.txt
│   ├── debezium-connector-mongodb-0.7.1.jar
│   ├── debezium-core-0.7.1.jar
│   ├── LICENSE.txt
│   ├── mongodb-driver-3.4.2.jar
│   ├── mongodb-driver-core-3.4.2.jar
│   └── README.md
├── debezium-connector-mysql
│   ├── CHANGELOG.md
│   ├── CONTRIBUTE.md
│   ├── COPYRIGHT.txt
│   ├── debezium-connector-mysql-0.7.1.jar
│   ├── debezium-core-0.7.1.jar
│   ├── LICENSE.txt
│   ├── mysql-binlog-connector-java-0.13.0.jar
│   ├── mysql-connector-java-5.1.40.jar
│   ├── README.md
│   └── wkb-1.0.2.jar
└── debezium-connector-postgres
    ├── CHANGELOG.md
    ├── CONTRIBUTE.md
    ├── COPYRIGHT.txt
    ├── debezium-connector-postgres-0.7.1.jar
    ├── debezium-core-0.7.1.jar
    ├── LICENSE.txt
    ├── postgresql-42.0.0.jar
    ├── protobuf-java-2.6.1.jar
    └── README.md

Copy to Clipboard

Toggle word wrap

oc start-build コマンドで、準備したディレクトリーを使用してイメージの新しいビルドを開始します。
```
oc start-build my-connect-cluster-connect --from-dir ./my-plugins/
```
```
oc start-build my-connect-cluster-connect --from-dir ./my-plugins/
```
Copy to Clipboard Toggle word wrap
注記
ビルドの名前は、デプロイされた Kafka Connect クラスターと同じになります。
ビルドが完了したら、Kafka Connect のデプロイメントによって新しいイメージが自動的に使用されます。

3.4. Kafka MirrorMaker の設定
リンクのコピー

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

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

重要

MirrorMaker 2.0 はテクノロジープレビュー機能です。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあります。Red Hat は、本番環境でのテクノロジープレビュー機能の実装は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

MirrorMaker

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

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

Kafka MirrorMaker の設定

サポート対象のプロパティーも以下で詳細に説明されています。

Kafka MirrorMaker 設定プロパティー

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

注記

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

MirrorMaker 2.0

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

3.4.1. Kafka MirrorMaker の設定
リンクのコピー

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

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

前提条件

AMQ Streams および Kafka がデプロイされている必要があります。
ソースおよびターゲットの Kafka クラスターが使用できる必要があります。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
metadata:
  name: my-mirror-maker
spec:
  replicas: 3 
  consumer:
    bootstrapServers: my-source-cluster-kafka-bootstrap:9092 
    groupId: "my-group" 
    numStreams: 2 
    offsetCommitInterval: 120000 
    tls: 
      trustedCertificates:
      - secretName: my-source-cluster-ca-cert
        certificate: ca.crt
    authentication: 
      type: tls
      certificateAndKey:
        secretName: my-source-secret
        certificate: public.crt
        key: private.key
    config: 
      max.poll.records: 100
      receive.buffer.bytes: 32768
  producer:
    bootstrapServers: my-target-cluster-kafka-bootstrap:9092
    abortOnSendFailure: false 
    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
  whitelist: "my-topic|other-topic" 
  resources: 
    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      cpu: "2"
      memory: 2Gi
  logging: 
    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  readinessProbe: 
    initialDelaySeconds: 15
    timeoutSeconds: 5
  livenessProbe:
    initialDelaySeconds: 15
    timeoutSeconds: 5
  metrics: 
    lowercaseOutputName: true
    rules:
      - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
        name: "kafka_server_$1_$2_total"
      - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*,
        topic=(.+)><>Count"
        name: "kafka_server_$1_$2_total"
        labels:
          topic: "$3"
  jvmOptions: 
    "-Xmx": "1g"
    "-Xms": "1g"
  image: my-org/my-image:latest 
  template: 
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
metadata:
  name: my-mirror-maker
spec:
  replicas: 3


  consumer:
    bootstrapServers: my-source-cluster-kafka-bootstrap:9092


    groupId: "my-group"


    numStreams: 2


    offsetCommitInterval: 120000


    tls:


      trustedCertificates:
      - secretName: my-source-cluster-ca-cert
        certificate: ca.crt
    authentication:


      type: tls
      certificateAndKey:
        secretName: my-source-secret
        certificate: public.crt
        key: private.key
    config:


      max.poll.records: 100
      receive.buffer.bytes: 32768
  producer:
    bootstrapServers: my-target-cluster-kafka-bootstrap:9092
    abortOnSendFailure: false


    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
  whitelist: "my-topic|other-topic"


  resources:


    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      cpu: "2"
      memory: 2Gi
  logging:


    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  readinessProbe:


    initialDelaySeconds: 15
    timeoutSeconds: 5
  livenessProbe:
    initialDelaySeconds: 15
    timeoutSeconds: 5
  metrics:


    lowercaseOutputName: true
    rules:
      - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*><>Count"
        name: "kafka_server_$1_$2_total"
      - pattern: "kafka.server<type=(.+), name=(.+)PerSec\\w*,
        topic=(.+)><>Count"
        name: "kafka_server_$1_$2_total"
        labels:
          topic: "$3"
  jvmOptions:


    "-Xmx": "1g"
    "-Xms": "1g"
  image: my-org/my-image:latest


  template:


      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"

Copy to Clipboard

Toggle word wrap

1: レプリカノードの数。
2: コンシューマーおよびプロデューサーのブートストラップサーバー。
3: コンシューマーのグループ ID。
4: コンシューマーストリームの数。
5: オフセットの自動コミット間隔 (ミリ秒単位)。
6: コンシューマーまたはプロデューサーの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。詳細は、「KafkaMirrorMakerTls スキーマ参照」を参照してください。
7: OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズムを使用する、コンシューマーおよびプロデューサーの認証。
8: コンシューマーおよびプロデューサーの Kafka 設定オプション。
9: true に設定された場合、Kafka MirrorMaker が終了し、メッセージの送信失敗後にコンテナーが再起動します。
10: ソースからターゲット Kafka クラスターにミラーリングされたトピック。
11: 現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
12: ConfigMap より直接的 (inline) または間接的 (external) に追加されたロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties または log4j2.properties キー下に配置する必要があります。MirrorMaker には mirrormaker.root.logger と呼ばれる単一のロガーがあります。ログレベルは INFO、ERROR、WARN、TRACE、DEBUG、FATAL、または OFF に設定できます。
13: コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
14: Prometheus メトリクス。この例では、Prometheus JMX エクスポーターの設定で有効になっています。metrics: {} を使用すると追加設定なしでメトリクスを有効にすることができます。
15: Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
16: 高度な任意手順: 特別な場合のみ推奨されるコンテナーイメージの設定。
17: テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。

警告

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

リソースを作成または更新します。
```
oc apply -f <your-file>
```
```
oc apply -f <your-file>
```
Copy to Clipboard Toggle word wrap

3.4.2. Kafka MirrorMaker 設定プロパティー
リンクのコピー

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

サポートされるプロパティーの詳細は以下を参照してください。

3.4.2.1. レプリカ
リンクのコピー

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

複数の MirrorMaker レプリカを実行して、可用性とスケーラビリティーを向上できます。OpenShift で Kafka MirrorMaker を実行する場合、高可用性を実現するために Kafka MirrorMaker の複数のレプリカを実行する必要はありません。Kafka MirrorMaker がデプロイされたノードがクラッシュした場合、OpenShift では自動的に Kafka MirrorMaker Pod が別のノードに再スケジュールされます。ただし、複数のレプリカで Kafka MirrorMaker を実行すると、他のノードが稼働しているため、フェイルオーバー時間が短縮されます。

3.4.2.2. ブートストラップサーバー
リンクのコピー

consumer.bootstrapServers および producer.bootstrapServers プロパティーを使用して、コンシューマーおよびプロデューサーのブートストラップサーバーのリストを設定します。

Kafka MirrorMaker は常に 2 つの Kafka クラスター (ソースおよびターゲット) と連携します。ソースおよびターゲット Kafka クラスターは、<hostname>:‍<port> ペアのコンマ区切りリストを 2 つ形式として用いて指定されます。それぞれのコンマ区切りリストには、<hostname>:<port> ペアとして指定された 1 つ以上の Kafka ブローカーまたは Kafka ブローカーを示す 1 つの Service が含まれます。

ブートストラップサーバーリストは、同じ OpenShift クラスターにデプロイする必要がない Kafka クラスターを参照できます。AMQ Streams によってデプロイされたまたはされていない Kafka クラスターを参照することもできますが、外部でアクセス可能な別の OpenShift クラスターである必要があります。

同じ OpenShift クラスターである場合、各リストに <cluster-name>-kafka-bootstrap という名前の Kafka クラスターブートストラップサービスが含まれ、さらに平文トラフィックの場合はポート 9092、暗号化されたトラフィックの場合はポート 9093 が含まれることが理想的です。AMQ Streams によって異なる OpenShift クラスターにデプロイされた場合、リストの内容はクラスターを公開するために使用された方法によって異なります (ルート、ノードポート、またはロードバランサー)。

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

3.4.2.3. ホワイトリスト
リンクのコピー

whitelist プロパティーを使用して、Kafka MirrorMaker がソースからターゲット Kafka クラスターにミラーリングするトピックのリストを設定します。

このプロパティーでは、簡単な単一のトピック名から複雑なパターンまですべての正規表現が許可されます。たとえば、「A|B」を使用してトピック A と B をミラーリングでき、「*」を使用してすべてのトピックをミラーリングできます。また、複数の正規表現をコンマで区切って Kafka MirrorMaker に渡すこともできます。

3.4.2.4. コンシューマーグループ ID
リンクのコピー

consumer.groupId プロパティーを使用して、コンシューマーにコンシューマーグループ ID を設定します。

Kafka MirrorMaker は Kafka コンシューマーを使用してメッセージを消費し、他の Kafka コンシューマークライアントと同様に動作します。ソース Kafka クラスターから消費されるメッセージは、ターゲット Kafka クラスターにミラーリングされます。パーティションの割り当てには、コンシューマーがコンシューマーグループの一部である必要があるため、グループ ID が必要です。

3.4.2.5. コンシューマーストリーム
リンクのコピー

consumer.numStreams プロパティーを使用して、コンシューマーのストリームの数を設定します。

コンシューマースレッドの数を増やすと、ミラーリングトピックのスループットを増やすことができます。コンシューマースレッドは、Kafka MirrorMaker に指定されたコンシューマーグループに属します。トピックパーティションはコンシューマースレッド全体に割り当てられ、メッセージが並行して消費されます。

3.4.2.6. オフセットの自動コミット間隔
リンクのコピー

consumer.offsetCommitInterval プロパティーを使用して、コンシューマーのオフセット自動コミット間隔を設定します。

Kafka MirrorMaker によってソース Kafka クラスターのデータが消費された後に、オフセットがコミットされる通常の間隔を指定できます。間隔はミリ秒単位で設定され、デフォルト値は 60,000 です。

3.4.2.7. メッセージ送信の失敗での中止
リンクのコピー

producer.abortOnSendFailure プロパティーを使用して、プロデューサーからメッセージ送信の失敗を処理する方法を設定します。

デフォルトでは、メッセージを Kafka MirrorMaker から Kafka クラスターに送信する際にエラーが発生した場合、以下が行われます。

Kafka MirrorMaker コンテナーが OpenShift で終了します。
その後、コンテナーが再作成されます。

abortOnSendFailure オプションを false に設定した場合、メッセージ送信エラーは無視されます。

3.4.2.8. Kafka プロデューサーおよびコンシューマー
リンクのコピー

consumer.config および producer.config プロパティーを使用して、コンシューマーおよびプロデューサーの Kafka オプションを設定します。

config プロパティーには、Kafka MirrorMaker コンシューマーとプロデューサーの設定オプションがキーとして含まれ、値は以下の JSON タイプの 1 つに設定されます。

文字列
Number
ブール値

例外

標準の Kafka コンシューマーおよびプロデューサーオプションを指定および設定できます。

しかし、以下に関連する AMQ Streams によって自動的に設定され直接管理されるオプションには例外があります。

Kafka クラスターブートストラップアドレス
セキュリティー (暗号化、認証、および承認)
コンシューマーグループ ID

以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

ssl.
sasl.
security.
bootstrap.servers
group.id

禁止されているオプションが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka MirrorMaker に渡されます。

重要

Cluster Operator では、提供された config オブジェクトのキーまたは値は検証されません。無効な設定が指定されると、Kafka MirrorMaker が起動しなかったり、不安定になったりする場合があります。このような場合、KafkaMirrorMaker.spec.consumer.config または KafkaMirrorMaker.spec.producer.config オブジェクトの設定を修正し、Cluster Operator によって Kafka MirrorMaker の新しい設定がロールアウトされるようにします。

3.4.2.9. CPU およびメモリーリソース
リンクのコピー

reources.requests および resources.limits プロパティーを使用して、リソース要求および制限を設定します。

AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。

AMQ Streams では、以下のリソースタイプの要求および制限がサポートされます。

cpu
memory

AMQ Streams では、このようなリソースの指定に OpenShift の構文が使用されます。

OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。

リソース要求

要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。

重要

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

1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。

リソース制限

1 つまたは複数のサポートされる制限に対してリソースを設定できます。

サポートされる CPU 形式

CPU の要求および制限は以下の形式でサポートされます。

整数値 (5 CPU コア) または少数 (2.5 CPU コア) の CPU コアの数。
数値または ミリ CPU / ミリコア (100m)。1000 ミリコア は 1 CPU コアと同じです。

注記

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

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

サポートされるメモリー形式

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。

メモリーをメガバイトで指定するには、M 接尾辞を使用します。例: 1000M
メモリーをギガバイトで指定するには、G 接尾辞を使用します。例: 1G
メモリーをメビバイトで指定するには、Mi 接尾辞を使用します。例: 1000Mi
メモリーをギビバイトで指定するには、Gi 接尾辞を使用します。例: 1Gi

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

3.4.2.10. Kafka MirrorMaker ロガー
リンクのコピー

Kafka MirrorMaker には、独自の設定可能なロガーがあります。

mirrormaker.root.logger

MirrorMaker では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

inline および external ロギングの例は次のとおりです。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  # ...

Copy to Clipboard

Toggle word wrap

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

Copy to Clipboard

Toggle word wrap

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。GC ロギングの詳細は「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.4.2.11. Healthcheck
リンクのコピー

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

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

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

initialDelaySeconds
timeoutSeconds
periodSeconds
successThreshold
failureThreshold

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

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

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

Copy to Clipboard

Toggle word wrap

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

3.4.2.12. Prometheus メトリクス
リンクのコピー

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

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

追加設定なしで Prometheus メトリクスのエクスポートを有効にするには、空のオブジェクト ({}) を設定します。

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

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

Prometheus および Grafana の設定に関する詳細は「メトリクス」を参照してください。

3.4.2.13. JVM オプション
リンクのコピー

jvmOptions プロパティーを使用して、コンポーネントが稼働している JVM のサポートされるオプションを設定します。

サポートされる JVM オプションは、さまざまなプラットフォームやアーキテクチャーのパフォーマンスを最適化するのに便利です。

サポートされるオプションの詳細は、「JVM 設定」を参照してください。

3.4.2.14. コンテナーイメージ
リンクのコピー

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

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

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

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

詳細は、「コンテナーイメージの設定」を参照してください。

3.4.3. 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。

3.4.4. AMQ Streams の MirrorMaker 2.0 との使用
リンクのコピー

このセクションでは、AMQ Streams の MirrorMaker 2.0 との使用について説明します。

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

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

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

注記

MirrorMaker 2.0 には、以前のバージョンの MirrorMaker ではサポートされない機能があります。

3.4.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 は、複数のソースクラスターで使用できます。

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

3.4.4.2. クラスターの設定
リンクのコピー

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

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

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

3.4.4.2.1. 双方向レプリケーション
リンクのコピー

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

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

図3.2 トピックの名前変更

MirrorMaker 2.0 bidirectional architecture

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

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

3.4.4.2.2. トピック設定の同期
リンクのコピー

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

3.4.4.2.3. データの整合性
リンクのコピー

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

3.4.4.2.4. オフセットの追跡
リンクのコピー

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

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

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

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

3.4.4.2.5. 接続性チェック
リンクのコピー

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

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

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

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

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

3.4.4.3. ACL ルールの同期
リンクのコピー

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

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

注記

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

3.4.4.4. MirrorMaker 2.0 を使用した Kafka クラスター間でのデータの同期
リンクのコピー

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

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

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

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

前提条件

AMQ Streams および Kafka がデプロイされている必要があります。
ソースおよびターゲットの Kafka クラスターが使用できる必要があります。

手順

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

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

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 2.4.0 
  replicas: 3 
  connectCluster: "my-cluster-target" 
  clusters: 
  - alias: "my-cluster-source" 
    authentication: 
      certificateAndKey:
        certificate: source.crt
        key: source.key
        secretName: my-user-source
      type: tls
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092 
    tls: 
      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-source-cluster-ca-cert
  - alias: "my-cluster-target" 
    authentication: 
      certificateAndKey:
        certificate: target.crt
        key: target.key
        secretName: my-user-target
      type: tls
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092 
    config: 
      config.storage.replication.factor: 1
      offset.storage.replication.factor: 1
      status.storage.replication.factor: 1
    tls: 
      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-target-cluster-ca-cert
  mirrors: 
  - sourceCluster: "my-cluster-source" 
    targetCluster: "my-cluster-target" 
    sourceConnector: 
      config:
        replication.factor: 1 
        offset-syncs.topic.replication.factor: 1 
        sync.topic.acls.enabled: "false" 
    heartbeatConnector: 
      config:
        heartbeats.topic.replication.factor: 1 
    checkpointConnector: 
      config:
        checkpoints.topic.replication.factor: 1 
    topicsPattern: ".*" 
    groupsPattern: "group1|group2|group3"

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 2.4.0


  replicas: 3


  connectCluster: "my-cluster-target"


  clusters:


  - alias: "my-cluster-source"


    authentication:


      certificateAndKey:
        certificate: source.crt
        key: source.key
        secretName: my-user-source
      type: tls
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092


    tls:


      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-source-cluster-ca-cert
  - alias: "my-cluster-target"


    authentication:


      certificateAndKey:
        certificate: target.crt
        key: target.key
        secretName: my-user-target
      type: tls
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092


    config:


      config.storage.replication.factor: 1
      offset.storage.replication.factor: 1
      status.storage.replication.factor: 1
    tls:


      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-target-cluster-ca-cert
  mirrors:


  - sourceCluster: "my-cluster-source"


    targetCluster: "my-cluster-target"


    sourceConnector:


      config:
        replication.factor: 1


        offset-syncs.topic.replication.factor: 1


        sync.topic.acls.enabled: "false"


    heartbeatConnector:


      config:
        heartbeats.topic.replication.factor: 1


    checkpointConnector:


      config:
        checkpoints.topic.replication.factor: 1


    topicsPattern: ".*"


    groupsPattern: "group1|group2|group3"

Copy to Clipboard

Toggle word wrap

1: Kafka Connect のバージョン。
2: レプリカノードの数。
3: Kafka Connect のクラスターエイリアス。
4: 同期される Kafka クラスターの指定。
5: ソースの Kafka クラスターのクラスターエイリアス。
6: OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズムを使用する、ソースクラスターの認証。
7: ソース Kafka クラスターに接続するためのブートストラップサーバー。
8: ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。詳細は、「KafkaMirrorMaker2Tls スキーマ参照」を参照してください。
9: ターゲット Kafka クラスターのクラスターエイリアス。
10: ターゲット Kafka クラスターの認証は、ソース Kafka クラスターと同様に設定されます。
11: ターゲット Kafka クラスターに接続するためのブートストラップサーバー。
12: Kafka Connect の設定。標準の Apache Kafka 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。
13: ターゲット Kafka クラスターの TLS による暗号化は、ソース Kafka クラスターと同様に設定されます。
14: MirrorMaker 2.0 コネクター。
15: MirrorMaker 2.0 コネクターによって使用されるソースクラスターのエイリアス。
16: MirrorMaker 2.0 コネクターによって使用されるターゲットクラスターのエイリアス。
17: リモートトピックを作成する MirrorSourceConnector の設定。デフォルトの設定オプションは config によって上書きされます。
18: ターゲットクラスターで作成されるミラーリングされたトピックのレプリケーション係数。
19: ソースおよびターゲットクラスターのオフセットをマップする MirrorSourceConnector offset-syncs 内部トピックのレプリケーション係数。
20: 有効にすると、同期されたトピックに ACL が適用されます。デフォルトは true です。
21: 接続性チェックを実行する MirrorHeartbeatConnector の設定。デフォルトの設定オプションは config によって上書きされます。
22: ターゲットクラスターで作成されたハートビートトピックのレプリケーション係数。
23: オフセットを追跡する MirrorCheckpointConnector の設定。デフォルトの設定オプションは config によって上書きされます。
24: ターゲットクラスターで作成されたチェックポイントトピックのレプリケーション係数。
25: 正規表現パターンとして定義されたソースクラスターからのトピックレプリケーション。ここで、すべてのトピックを要求します。
26: 正規表現パターンとして定義されたソースクラスターからのコンシューマーグループレプリケーション。ここで、3 つのコンシューマーグループを名前で要求します。コンマ区切りリストを使用できます。

リソースを作成または更新します。
```
oc apply -f <your-file>
```
```
oc apply -f <your-file>
```
Copy to Clipboard Toggle word wrap

3.5. Kafka Bridge の設定
リンクのコピー

KafkaBridge リソースの完全なスキーマは「KafkaBridge スキーマ参照」に記載されています。指定の KafkaBridge リソースに適用されたすべてのラベルは、Kafka Bridge クラスターを構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。

3.5.1. レプリカ
リンクのコピー

Kafka Bridge では複数のノードを実行できます。ノードの数は KafkaBridge リソースで定義されます。複数のノードで Kafka Bridge を実行すると、可用性とスケーラビリティーが向上します。ただし、OpenShift で Kafka Bridge を実行する場合は、高可用性のために Kafka Bridge で複数のノードを実行する必要は全くありません。

重要

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

3.5.1.1. ノード数の設定
リンクのコピー

Kafka Bridge ノードの数は、KafkaBridge.spec の replicas プロパティーを使用して設定されます。

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaBridge リソースの replicas プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  replicas: 3
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  replicas: 3
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.2. ブートストラップサーバー
リンクのコピー

Kafka Bridge は、常に Kafka クラスターと組み合わせて動作します。Kafka クラスターはブートストラップサーバーのリストとして指定されます。OpenShift では、そのリストに cluster-name-kafka-bootstrap という名前の Kafka クラスターブートストラップサービスが含まれ、さらに平文トラフィックの場合はポート 9092、暗号化されたトラフィックの場合はポート 9093 が含まれることが理想的です。

ブートストラップサーバーのリストは、KafkaBridge.kafka.spec の bootstrapServers プロパティーで設定されます。サーバーは、1 つ以上の Kafka ブローカーを指定するコンマ区切りリスト、または hostname:_port_ ペアとして指定される Kafka ブローカーを示すサービスとして定義される必要があります。

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

3.5.2.1. ブートストラップサーバーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaBridge リソースの bootstrapServers プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  bootstrapServers: my-cluster-kafka-bootstrap:9092
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.3. TLS を使用した Kafka ブローカーへの接続
リンクのコピー

デフォルトでは、Kafka Bridge はプレーンテキスト接続を使用して Kafka ブローカーへの接続を試みます。TLS を使用する場合は、追加の設定が必要です。

3.5.3.1. Kafka ブリッジへの Kafka 接続の TLS サポート
リンクのコピー

Kafka 接続の TLS サポートは、KafkaBridge.spec の tls プロパティーに設定されます。tls プロパティーには、保存される証明書のキー名があるシークレットのリストが含まれます。証明書は X509 形式で保存する必要があります。

複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
    trustedCertificates:
    - secretName: my-secret
      certificate: ca.crt
    - secretName: my-other-secret
      certificate: certificate.crt
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
    trustedCertificates:
    - secretName: my-secret
      certificate: ca.crt
    - secretName: my-other-secret
      certificate: certificate.crt
  # ...

Copy to Clipboard

Toggle word wrap

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

同じシークレットに複数の証明書がある TLS 設定の例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
    trustedCertificates:
    - secretName: my-secret
      certificate: ca.crt
    - secretName: my-secret
      certificate: ca2.crt
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
    trustedCertificates:
    - secretName: my-secret
      certificate: ca.crt
    - secretName: my-secret
      certificate: ca2.crt
  # ...

Copy to Clipboard

Toggle word wrap

3.5.3.2. Kafka Bridge での TLS の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS サーバー認証に使用される証明書の Secret の名前と、Secret に保存された証明書のキー (存在する場合)。

手順

(任意手順): 認証で使用される TLS 証明書が存在しない場合はファイルで準備し、Secret を作成します。
注記
Kafka クラスターの Cluster Operator によって作成されるシークレットは直接使用されることがあります。
```
oc create secret generic my-secret --from-file=my-file.crt
```
```
oc create secret generic my-secret --from-file=my-file.crt
```
Copy to Clipboard Toggle word wrap

KafkaBridge リソースの tls プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
	  trustedCertificates:
	  - secretName: my-cluster-cluster-cert
	    certificate: ca.crt
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  tls:
	  trustedCertificates:
	  - secretName: my-cluster-cluster-cert
	    certificate: ca.crt
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.4. 認証での Kafka ブローカーへの接続
リンクのコピー

デフォルトでは、Kafka Bridge は認証なしで Kafka ブローカーへの接続を試みます。認証は KafkaBridge リソースを使用して有効化されます。

3.5.4.1. Kafka Bridge での認証サポート
リンクのコピー

認証は、KafkaBridge.spec の authentication プロパティーで設定されます。authentication プロパティーによって、使用する認証メカニズムのタイプと、メカニズムに応じた追加設定の詳細が指定されます。現在サポートされている認証タイプは次のとおりです。

TLS クライアント認証
SCRAM-SHA-512 メカニズムを使用した SASL ベースの認証
PLAIN メカニズムを使用した SASL ベースの認証
OAuth 2.0 のトークンベースの認証

3.5.4.1.1. TLS クライアント認証
リンクのコピー

注記

TLS クライアント認証は TLS 接続でのみ使用できます。Kafka Bridge の TLS 設定の詳細は、「TLS を使用した Kafka ブローカーへの接続」を参照してください。

TLS クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: tls
    certificateAndKey:
      secretName: my-secret
      certificate: public.crt
      key: private.key
  # ...

Copy to Clipboard

Toggle word wrap

3.5.4.1.2. SCRAM-SHA-512 認証
リンクのコピー

Kafka Bridge で SASL ベースの SCRAM-SHA-512 認証が使用されるようにするには、type プロパティーを scram-sha-512 に設定します。この認証メカニズムには、ユーザー名とパスワードが必要です。

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの SCRAM-SHA-512 クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-bridge-user
    passwordSecret:
      secretName: my-bridge-user
      password: my-bridge-password-key
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: my-bridge-user
    passwordSecret:
      secretName: my-bridge-user
      password: my-bridge-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.5.4.1.3. SASL ベースの PLAIN 認証
リンクのコピー

Kafka Bridge で SASL ベースの PLAIN 認証が使用されるようにするには、type プロパティーを plain に設定します。この認証メカニズムには、ユーザー名とパスワードが必要です。

警告

username プロパティーでユーザー名を指定します。
passwordSecret プロパティーで、パスワードを含む Secret へのリンクを指定します。secretName プロパティーには Secret の名前が含まれ、password プロパティーには Secret 内にパスワードが格納されるキーの名前が含まれます。

重要

password フィールドには、実際のパスワードを指定しないでください。

SASL ベースの PLAIN クライアント認証の設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: plain
    username: my-bridge-user
    passwordSecret:
      secretName: my-bridge-user
      password: my-bridge-password-key
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: plain
    username: my-bridge-user
    passwordSecret:
      secretName: my-bridge-user
      password: my-bridge-password-key
  # ...

Copy to Clipboard

Toggle word wrap

3.5.4.2. Kafka Bridge での TLS クライアント認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
TLS クライアント認証に使用される公開鍵と秘密鍵がある Secret、および Secret に保存される公開鍵と秘密鍵のキー (存在する場合)。

手順

(任意手順): 認証に使用される鍵が存在しない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
```
oc create secret generic my-secret --from-file=my-public.crt --from-file=my-private.key
```
Copy to Clipboard Toggle word wrap

KafkaBridge リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
  type: tls
  certificateAndKey:
    secretName: my-secret
    certificate: my-public.crt
    key: my-private.key
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
  type: tls
  certificateAndKey:
    secretName: my-secret
    certificate: my-public.crt
    key: my-private.key
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.4.3. Kafka Bridge での SCRAM-SHA-512 認証の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。
認証に使用するユーザーのユーザー名。
認証に使用されるパスワードがある Secret の名前と、Secret に保存されたパスワードのキー (存在する場合)。

手順

(任意手順): 認証で使用されるパスワードがない場合はファイルで準備し、Secret を作成します。
注記
User Operator によって作成されたシークレットを使用できます。
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
```
echo -n '<password>' > <my-password.txt>
oc create secret generic <my-secret> --from-file=<my-password.txt>
```
Copy to Clipboard Toggle word wrap

KafkaBridge リソースの authentication プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: scram-sha-512
    username: _<my-username>_
    passwordSecret:
      secretName: _<my-secret>_
      password: _<my-password.txt>_
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.5. Kafka Bridge の設定
リンクのコピー

AMQ Streams では、コンシューマー向けの Apache Kafka 設定ドキュメントおよびプロデューサー向けの Apache Kafka 設定ドキュメントに記載されている特定のオプションを編集して、Apache Kafka Bridge ノードの設定をカスタマイズできます。

以下に関連している設定オプションを設定できます。

Kafka クラスターブートストラップアドレス
セキュリティー (暗号化、認証、および承認)
コンシューマー設定
プロデューサーの設定
HTTP の設定

3.5.5.1. Kafka Bridge コンシューマーの設定
リンクのコピー

Kafka Bridge コンシューマーは、KafkaBridge.spec.consumer でプロパティーを使用して設定されます。このプロパティーには、Kafka Bridge コンシューマーの設定オプションがキーとして含まれます。値は以下の JSON タイプのいずれかになります。

String
Number
ブール値

AMQ Streams で直接管理されるオプションを除き、コンシューマー向けの Apache Kafka 設定ドキュメントに記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

ssl.
sasl.
security.
bootstrap.servers
group.id

禁止されているオプションの 1 つが config プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka に渡されます。

重要

提供された config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。この状況で、KafkaBridge.spec.consumer.config オブジェクトの設定を修正すると、Cluster Operator は新しい設定をすべての Kafka Bridge ノードにロールアウトできます。

Kafka Bridge コンシューマーの設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  consumer:
    config:
      auto.offset.reset: earliest
      enable.auto.commit: true
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  consumer:
    config:
      auto.offset.reset: earliest
      enable.auto.commit: true
  # ...

Copy to Clipboard

Toggle word wrap

3.5.5.2. Kafka Bridge プロデューサーの設定
リンクのコピー

Kafka Bridge プロデューサーは、KafkaBridge.spec.producer でプロパティーを使用して設定されます。このプロパティーには、Kafka Bridge プロデューサーの設定オプションがキーとして含まれます。値は以下の JSON タイプのいずれかになります。

String
Number
ブール値

AMQ Streams で直接管理されるオプションを除き、プロデューサー向けの Apache Kafka 設定ドキュメントに記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。

ssl.
sasl.
security.
bootstrap.servers

重要

提供された config オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。この状況で、KafkaBridge.spec.producer.config オブジェクトの設定を修正すると、Cluster Operator は新しい設定をすべての Kafka Bridge ノードにロールアウトできます。

Kafka Bridge プロデューサーの設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  producer:
    config:
      acks: 1
      delivery.timeout.ms: 300000
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  producer:
    config:
      acks: 1
      delivery.timeout.ms: 300000
  # ...

Copy to Clipboard

Toggle word wrap

3.5.5.3. Kafka Bridge HTTP の設定
リンクのコピー

Kafka Bridge HTTP の設定は、KafkaBridge.spec.http でプロパティーを使用して設定されます。このプロパティーには、Kafka Bridge HTTP の設定オプションが含まれます。

port

Kafka Bridge HTTP の設定例

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
    port: 8080
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
    port: 8080
  # ...

Copy to Clipboard

Toggle word wrap

3.5.5.4. Kafka Bridge の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

KafkaBridge リソースの kafka、http、consumer、または producer プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  bootstrapServers: my-cluster-kafka:9092
  http:
    port: 8080
  consumer:
    config:
      auto.offset.reset: earliest
  producer:
    config:
      delivery.timeout.ms: 300000
  # ...

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  bootstrapServers: my-cluster-kafka:9092
  http:
    port: 8080
  consumer:
    config:
      auto.offset.reset: earliest
  producer:
    config:
      delivery.timeout.ms: 300000
  # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.6. CPU およびメモリーリソース
リンクのコピー

AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。

AMQ Streams では、以下の 2 つのタイプのリソースがサポートされます。

CPU
メモリー

AMQ Streams では、CPU およびメモリーリソースの指定に OpenShift 構文が使用されます。

3.5.6.1. リソースの制限および要求
リンクのコピー

リソースの制限と要求は、以下のリソースで resources プロパティーを使用して設定されます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

その他のリソース

OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。

3.5.6.1.1. リソース要求
リンクのコピー

要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。

重要

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

リソース要求は requests プロパティーで指定されます。AMQ Streams では、現在以下のリソース要求がサポートされます。

cpu
memory

1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。

すべてのリソースを対象とするリソース要求の設定例

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  requests:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.5.6.1.2. リソース制限
リンクのコピー

リソース制限は limits プロパティーで指定されます。AMQ Streams では、現在以下のリソース制限がサポートされます。

cpu
memory

1 つまたは複数のサポートされる制限に対してリソースを設定できます。

リソース制限の設定例

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

# ...
resources:
  limits:
    cpu: 12
    memory: 64Gi
# ...

Copy to Clipboard

Toggle word wrap

3.5.6.1.3. サポートされる CPU 形式
リンクのコピー

CPU の要求および制限は以下の形式でサポートされます。

整数値 (5 CPU コア) または少数 (2.5 CPU コア) の CPU コアの数。
数値または ミリ CPU / ミリコア (100m)。1000 ミリコア は 1 CPU コアと同じです。

CPU ユニットの例

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

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

Copy to Clipboard

Toggle word wrap

注記

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

その他のリソース

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

3.5.6.1.4. サポートされるメモリー形式
リンクのコピー

メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。

メモリーをメガバイトで指定するには、M 接尾辞を使用します。例: 1000M
メモリーをギガバイトで指定するには、G 接尾辞を使用します。例: 1G
メモリーをメビバイトで指定するには、Mi 接尾辞を使用します。例: 1000Mi
メモリーをギビバイトで指定するには、Gi 接尾辞を使用します。例: 1Gi

異なるメモリー単位の使用例

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

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

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.5.6.2. リソース要求および制限の設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    resources:
      requests:
        cpu: "8"
        memory: 64Gi
      limits:
        cpu: "12"
        memory: 128Gi
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

その他のリソース

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

3.5.7. Kafka Bridge ロガー
リンクのコピー

Kafka Bridge には独自の設定可能なロガーがあります。

log4j.logger.io.strimzi.kafka.bridge
log4j.logger.http.openapi.operation.<operation-id>

log4j.logger.http.openapi.operation.<operation-id> ロガーの <operation-id> 置き換えると、特定の操作のログレベルを設定できます。

createConsumer
deleteConsumer
subscribe
unsubscribe
poll
assign
commit
send
sendToPartition
seekToBeginning
seekToEnd
seek
healthy
ready
openapi

各操作は OpenAPI 仕様にしたがって定義されます。各操作にはブリッジが HTTP クライアントから要求を受信する対象の API エンドポイントがあります。各エンドポイントのログレベルを変更すると、送信および受信 HTTP 要求に関する詳細なログ情報を作成できます。

Kafka Bridge では Apache log4j ロガー実装が使用されます。ロガーは log4j.properties ファイルで定義されます。このファイルには healthy および ready エンドポイントの以下のデフォルト設定が含まれています。

log4j.logger.http.openapi.operation.healthy=WARN, out
log4j.additivity.http.openapi.operation.healthy=false
log4j.logger.http.openapi.operation.ready=WARN, out
log4j.additivity.http.openapi.operation.ready=false

log4j.logger.http.openapi.operation.healthy=WARN, out
log4j.additivity.http.openapi.operation.healthy=false
log4j.logger.http.openapi.operation.ready=WARN, out
log4j.additivity.http.openapi.operation.ready=false

Copy to Clipboard

Toggle word wrap

その他すべての操作のログレベルは、デフォルトで INFO に設定されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      log4j.logger.io.strimzi.kafka.bridge: "INFO"
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      log4j.logger.io.strimzi.kafka.bridge: "INFO"
  # ...

Copy to Clipboard

Toggle word wrap

外部ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaBridge
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaBridge
spec:
  # ...
  logging:
    type: external
    name: customConfigMap
  # ...

Copy to Clipboard

Toggle word wrap

その他のリソース

ガベッジコレクター (GC) ロギングを有効 (または無効) にすることもできます。GC ロギングの詳細は「JVM 設定」を参照してください。
ログレベルの詳細は、「Apache logging services」を参照してください。

3.5.8. JVM オプション
リンクのコピー

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

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

3.5.8.1. JVM 設定
リンクのコピー

JVM オプションは、以下のリソースの jvmOptions プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

使用可能な JVM オプションの選択されたサブセットのみを設定できます。以下のオプションがサポートされます。

-Xms および -Xmx

-Xms は、JVM の起動時に最初に割り当てられる最小ヒープサイズを設定します。-Xmx は、最大ヒープサイズを設定します。

注記

-Xms および -Xmx に使用されるデフォルト値は、コンテナーにメモリー要求の制限が設定されているかどうかによって異なります。

メモリーの制限がある場合は、JVM の最小および最大メモリーは制限に対応する値に設定されます。
メモリーの制限がない場合、JVM の最小メモリーは 128M に設定され、JVM の最大メモリーは定義されません。これにより、JVM のメモリーを必要に応じて拡張できます。これは、テストおよび開発での単一ノード環境に適しています。

重要

-Xmx を明示的に設定するには、以下の点に注意する必要があります。

JVM のメモリー使用量の合計は、-Xmx によって設定された最大ヒープの約 4 倍になります。
適切な OpenShift メモリー制限を設定せずに -Xmx が設定された場合、OpenShift ノードで、実行されている他の Pod からメモリー不足が発生するとコンテナーが強制終了される可能性があります。
適切な OpenShift メモリー要求を設定せずに -Xmx が設定された場合、コンテナーはメモリー不足のノードにスケジュールされる可能性があります。この場合、コンテナーは起動せずにクラッシュします (-Xms が -Xmx に設定されている場合は即座にクラッシュし、そうでない場合はその後にクラッシュします)。

-Xmx を明示的に設定する場合は、以下を行うことが推奨されます。

メモリー要求とメモリー制限を同じ値に設定します。
-Xmx の 4.5 倍以上のメモリー要求を使用します。
-Xms を -Xmx と同じ値に設定することを検討してください。

重要

-Xmx および -Xms の設定例 (抜粋)

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

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

Copy to Clipboard

Toggle word wrap

上記の例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB になります。

-server

-server はサーバー JVM を有効にします。このオプションは true または false に設定できます。

-server の設定例 (抜粋)

# ...
jvmOptions:
  "-server": true
# ...

# ...
jvmOptions:
  "-server": true
# ...

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

-XX

-XX オブジェクトの使用例

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

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

Copy to Clipboard

Toggle word wrap

上記の設定例の場合、JVM オプションは以下のようになります。

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

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

Copy to Clipboard

Toggle word wrap

注記

いずれのオプション (-server および -XX) も指定されないと、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS のデフォルト設定が使用されます。

3.5.8.1.1. ガベッジコレクターのロギング
リンクのコピー

GC ロギングを有効にする例

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

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

Copy to Clipboard

Toggle word wrap

3.5.8.2. JVM オプションの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、または KafkaBridgeリソースの jvmOptions プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jvmOptions:
      "-Xmx": "8g"
      "-Xms": "8g"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.9. Healthcheck
リンクのコピー

OpenShift では、以下の 2 つのタイプのおよびヘルスチェックプローブがサポートされます。

Liveness プローブ
Readiness プローブ

プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。AMQ Streams コンポーネントでは、両タイプのプローブが使用されます。

ユーザーは、Liveness および Readiness プローブに選択されたオプションを設定できます。

3.5.9.1. ヘルスチェックの設定
リンクのコピー

Liveness および Readiness プローブは、以下のリソースの livenessProbe および readinessProbe プロパティーを使用して設定できます。

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.KafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMaker.spec
KafkaBridge.spec

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

initialDelaySeconds
timeoutSeconds
periodSeconds
successThreshold
failureThreshold

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

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

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

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

Copy to Clipboard

Toggle word wrap

3.5.9.2. ヘルスチェックの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの livenessProbe または readinessProbe プロパティーを編集します。以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.10. コンテナーイメージ
リンクのコピー

3.5.10.1. コンテナーイメージの設定
リンクのコピー

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

Kafka.spec.kafka
Kafka.spec.kafka.tlsSidecar
Kafka.spec.zookeeper
Kafka.spec.zookeeper.tlsSidecar
Kafka.spec.entityOperator.topicOperator
Kafka.spec.entityOperator.userOperator
Kafka.spec.entityOperator.tlsSidecar
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaBridge.spec

3.5.10.1.1. Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定
リンクのコピー

STRIMZI_KAFKA_IMAGES
STRIMZI_KAFKA_CONNECT_IMAGES
STRIMZI_KAFKA_CONNECT_S2I_IMAGES
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

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

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

Kafka の場合は spec.kafka.image および spec.kafka.version。
Kafka Connect、Kafka Connect S2I、および Kafka MirrorMaker の場合は spec.image および spec.version。

警告

3.5.10.1.2. 他のリソースでの image プロパティーの設定
リンクのコピー

Kafka ブローカー TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_KAFKA_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
ZooKeeper ノードの場合:
ZooKeeper ノードの TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ZOOKEEPER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Topic Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
User Operator の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。
Entity Operator TLS サイドカーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Exporter の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0 コンテナーイメージ。
Kafka Bridge の場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.4.0 コンテナーイメージ。
Kafka ブローカーイニシャライザーの場合:
1. Cluster Operator 設定から STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 環境変数に指定されたコンテナーイメージ。
2. registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0 コンテナーイメージ。

警告

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

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

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

Copy to Clipboard

Toggle word wrap

3.5.10.2. コンテナーイメージの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

Kafka、KafkaConnect、または KafkaConnectS2I リソースの image プロパティーを編集します。以下に例を示します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.11. Pod スケジューリングの設定
リンクのコピー

重要

3.5.11.1. 他のアプリケーションに基づく Pod のスケジューリング
リンクのコピー

3.5.11.1.1. 重要なアプリケーションがノードを共有しないようにする
リンクのコピー

3.5.11.1.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.5.11.1.3. Kafka コンポーネントでの Pod の非アフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: application
                      operator: In
                      values:
                        - postgresql
                        - mongodb
                topologyKey: "kubernetes.io/hostname"
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.11.2. 特定のノードへの Pod のスケジューリング
リンクのコピー

3.5.11.2.1. ノードのスケジューリング
リンクのコピー

3.5.11.2.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.5.11.2.3. Kafka コンポーネントでのノードのアフィニティーの設定
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    template:
      pod:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: node-type
                    operator: In
                    values:
                    - fast-network
    # ...
  zookeeper:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.11.3. 専用ノードの使用
リンクのコピー

3.5.11.3.1. 専用ノード
リンクのコピー

専用ノードで Kafka Pod をスケジュールするには、ノードのアフィニティーと許容 (toleration) を設定します。

3.5.11.3.2. アフィニティー
リンクのコピー

アフィニティーは、以下のリソースの affinity プロパティーを使用して設定できます。

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

アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。

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

3.5.11.3.3. 許容 (Toleration)
リンクのコピー

許容 (Toleration) は、以下のリソースの tolerations プロパティーを使用して設定できます。

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

tolerations プロパティーの形式は、OpenShift の仕様に準拠します。詳細は、Kubernetes の「Taints and Tolerations」を参照してください。

3.5.11.3.4. 専用ノードの設定と Pod のスケジューリング
リンクのコピー

前提条件

OpenShift クラスターが必要です。
稼働中の Cluster Operator が必要です。

手順

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

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

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

apiVersion: kafka.strimzi.io/v1beta1
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:
    # ...

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap

3.5.12. 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。

3.6. OAuth 2.0 トークンベース認証の使用
リンクのコピー

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

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

AMQ Streams では、OAuth 2.0 準拠の承認サーバーの認証で OAuth 2.0 がサポートされます。また、Keycloak を承認サーバーとして使用する場合にも OAuth 2.0 のトークンベースの承認がサポートされ、この承認サービスの機能を利用して、Kafka リソースに対するユーザーの権限が一元管理されます。ただし、OAuth 2.0 認証は、使用する承認サーバーに関係なく ACL ベースの 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 のサイト

3.6.1. OAuth 2.0 認証メカニズム
リンクのコピー

Kafka SASL OAUTHBEARER メカニズムは、Kafka ブローカーで認証されたセッションを確立するために使用されます。

Kafka クライアントは、形式がアクセストークンであるクレデンシャルの交換に SASL OAUTHBEARER メカニズムを使用して Kafka ブローカーでセッションを開始します。

Kafka ブローカーおよびクライアントは、OAuth 2.0 を使用するように設定する必要があります。

3.6.2. OAuth 2.0 Kafka ブローカーの設定
リンクのコピー

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

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

注記

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

3.6.2.1. 承認サーバーの OAuth 2.0 クライアント設定
リンクのコピー

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

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

注記

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

3.6.2.2. Kafka クラスターでの OAuth 2.0 認証設定
リンクのコピー

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        authentication:
          type: oauth
          #...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        authentication:
          type: oauth
          #...

Copy to Clipboard

Toggle word wrap

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

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

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

# ...
listeners:
  tls:
    authentication:
      type: oauth
  external:
    type: loadbalancer
    tls: true
    authentication:
      type: oauth
    #...

# ...
listeners:
  tls:
    authentication:
      type: oauth
  external:
    type: loadbalancer
    tls: true
    authentication:
      type: oauth
    #...

Copy to Clipboard

Toggle word wrap

tls プロパティーはデフォルトで true に設定されているため、省略することができます。

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

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

3.6.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/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        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
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        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
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

Copy to Clipboard

Toggle word wrap

3.6.2.4. OAuth 2.0 イントロスペクションエンドポイントの設定
リンクのコピー

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

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

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

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        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>
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      tls:
        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>
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

Copy to Clipboard

Toggle word wrap

3.6.3. OAuth 2.0 Kafka クライアントの設定
リンクのコピー

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

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

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

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

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

注記

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

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

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

3.6.4. OAuth 2.0 のクライアント認証フロー
リンクのコピー

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

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

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

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

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

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

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

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

注記

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

3.6.4.1. クライアント認証フローの例
リンクのコピー

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

クライアントではクライアント 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 トークン署名の検証は有効期限の短いトークンにのみ適しています。トークンの有効期限はトークンに書き込まれますが、失効はいつでも発生する可能性があるため、承認サーバーと通信せずに対応することはできません。発行されたトークンはすべて期限切れになるまで有効とみなされます。

3.6.5. OAuth 2.0 認証の設定
リンクのコピー

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

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

3.6.5.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 を使用するように設定します。

3.6.5.2. Kafka ブローカーの OAuth 2.0 サポートの設定
リンクのコピー

この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。

TLS リスナーを設定して、暗号化されたインターフェースで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。

承認サーバーが信頼できる CA によって署名された証明書を使用し、OAuth 2.0 サーバーのホスト名と一致する場合、TLS 接続はデフォルト設定を使用して動作します。その他の場合は、トークンの検証を承認サーバーに委譲するときに 2 つの設定オプションをリスナー設定に使用できます。

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

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

前提条件

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

手順

エディターで、Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新します。
```
oc edit kafka my-cluster
```
```
oc edit kafka my-cluster
```
Copy to Clipboard Toggle word wrap
Kafka ブローカーの listeners 設定を行います。
各タイプのリスナーは独立しているため、同じ設定にする必要はありません。
以下は、外部リスナーに設定された設定オプションの例になります。
例 1: 高速なローカル JWT トークン検証の設定
```
external:
  type: loadbalancer
  authentication:
    type: oauth 
    validIssuerUri: <https://<auth-server-address>/auth/realms/external> 
    jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 
    userNameClaim: preferred_username 
    tlsTrustedCertificates: 
    - secretName: oauth-server-cert
      certificate: ca.crt
    disableTlsHostnameVerification: true 
    jwksExpirySeconds: 360 
    jwksRefreshSeconds: 300 
    enableECDSA: "true" 
```
```
external:
  type: loadbalancer
  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
```
    tlsTrustedCertificates: 
```
5
```
    - secretName: oauth-server-cert
      certificate: ca.crt
    disableTlsHostnameVerification: true 
```
6
```
    jwksExpirySeconds: 360 
```
7
```
    jwksRefreshSeconds: 300 
```
8
```
    enableECDSA: "true" 
```
9
Copy to Clipboard Toggle word wrap
1
oauth に設定されたリスナータイプ。
2
認証に使用されるトークン発行者の URI。
3
ローカルの JWT 検証に使用される JWKS 証明書エンドポイントの URI。
4
トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。userNameClaim の値は、使用される認証フローと承認サーバーによって異なります。
5
(任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
6
(任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
7
JWK 証明書が期限切れになる前に有効とみなされる期間。デフォルトは 360 秒です。デフォルトよりも長い時間を指定する場合は、取り消された証明書へのアクセスが許可されるリスクを考慮してください。
8
JWK 証明書を更新する間隔。この間隔は、有効期間よりも 60 秒以上短くする必要があります。デフォルトは 300 秒です。
9
(任意設定): ECDSA を使用して承認サーバーで JWT トークンを署名する場合は、これを有効にする必要があります。BouncyCastle 暗号ライブラリーを使用して追加の暗号プロバイダーがインストールされます。デフォルトは false です。
例 2: イントロスペクションエンドポイントを使用したトークンの検証の設定
```
external:
  type: loadbalancer
  authentication:
    type: oauth
    validIssuerUri: <https://<auth-server-address>/auth/realms/external>
    introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect> 
    clientId: kafka-broker 
    clientSecret: 
      secretName: my-cluster-oauth
      key: clientSecret
```
```
external:
  type: loadbalancer
  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
```
Copy to Clipboard Toggle word wrap
1
トークンイントロスペクションエンドポイントの URI。
2
クライアントを識別するためのクライアント ID。
3
認証にはクライアントシークレットとクライアント ID が使用されます。
エディターを保存および終了してから、ローリングアップデートが完了するまで待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get po -w
```
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get po -w
```
Copy to Clipboard Toggle word wrap
ローリングアップデートによって、ブローカーが OAuth 2.0 認証を使用するように設定されます。

次のステップ

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

3.6.5.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.3.0.redhat-00001</version>
</dependency>

<dependency>
 <groupId>io.strimzi</groupId>
 <artifactId>kafka-oauth-client</artifactId>
 <version>0.3.0.redhat-00001</version>
</dependency>

Copy to Clipboard

Toggle word wrap

コールバックのシステムプロパティーを設定します。

以下に例を示します。

System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 
System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client-name>"); 
System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client-secret>");

System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”);


System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client-name>");


System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client-secret>");

Copy to Clipboard

Toggle word wrap

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"); 
props.put("sasl.mechanism", "OAUTHBEARER");
props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
props.put("security.protocol", "SASL_SSL");


props.put("sasl.mechanism", "OAUTHBEARER");
props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

Copy to Clipboard

Toggle word wrap

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

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

次のステップ

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

3.6.5.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/v1beta1
kind: Secret
metadata:
 name: my-bridge-oauth
type: Opaque
data:
 clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw

apiVersion: kafka.strimzi.io/v1beta1
kind: Secret
metadata:
 name: my-bridge-oauth
type: Opaque
data:
 clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw

Copy to Clipboard

Toggle word wrap

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/v1beta1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  authentication:
    type: oauth 
    tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 
    clientId: kafka-bridge
    clientSecret:
      secretName: my-bridge-oauth
      key: clientSecret
    tlsTrustedCertificates: 
    - secretName: oauth-server-cert
      certificate: tls.crt
```
```
apiVersion: kafka.strimzi.io/v1beta1
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
```
Copy to Clipboard Toggle word wrap
1
oauth に設定された認証タイプ。
2
認証用のトークンエンドポイントの URI。
3
承認サーバーへの TLS 接続用の信用できる証明書。
OAuth 2.0 認証の適用方法や、承認サーバーのタイプによって、使用できる追加の設定オプションがあります。
```
# ...
spec:
  # ...
  authentication:
    # ...
    disableTlsHostnameVerification: true 
    checkAccessTokenType: false 
    accessTokenIsJwt: false 
```
```
# ...
spec:
  # ...
  authentication:
    # ...
    disableTlsHostnameVerification: true 
```
1
```
    checkAccessTokenType: false 
```
2
```
    accessTokenIsJwt: false 
```
3
Copy to Clipboard Toggle word wrap
1
(任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
2
承認サーバーによって、JWT トークン内部で typ (タイプ) 要求が返されない場合は、checkAccessTokenType: false を適用するとトークンタイプがチェックされず次に進むことができます。デフォルトは true です。
3
不透明なトークンを使用している場合、アクセストークンが JWT トークンとして処理されないように accessTokenIsJwt: false を適用することができます。
Kafka リソースのデプロイメントに変更を適用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get pod -w
```
```
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
oc get pod -w
```
Copy to Clipboard Toggle word wrap
ローリングアップデートでは、OAuth 2.0 認証を使用して Kafka ブローカーと対話するコンポーネントが設定されます。

3.7. OAuth 2.0 トークンベース承認の使用
リンクのコピー

重要

OAuth 2.0 での承認はテクノロジープレビュー機能です。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあります。Red Hat は、本番環境でのテクノロジープレビュー機能の実装は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

この機能について

OAuth 2.0 トークンベースの承認はテクノロジープレビューであるため、Red Hat Single Sign-On 7.3 ではサポートされません。この機能を試す場合は、Keycloak 8.0.2 を承認サーバーとする開発環境での使用はテストされています。

Kafka ブローカーへのアクセスの承認

トークンベースの認証に OAuth 2.0 と Keycloak を使用している場合、Keycloak を使用して承認ルールを設定し、Kafka ブローカーへのクライアントのアクセスを制限することもできます。認証はユーザーのアイデンティティーを確立します。承認は、そのユーザーのアクセスレベルを決定します。

AMQ Streams は、Keycloak Authorization Services による OAuth 2.0 トークンベースの承認をサポートします。これにより、セキュリティーポリシーとパーミッションの一元的な管理が可能になります。

Keycloak で定義されたセキュリティーポリシーおよびパーミッションは、Kafka ブローカーのリソースへのアクセスを付与するために使用されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。

Kafka では、デフォルトですべてのユーザーがブローカーに完全アクセスできます。また、アクセス制御リスト (ACL) を基にして承認を設定するために SimpleACLAuthorizer プラグインが提供されます。ZooKeeper には、 ユーザー名 を基にしてリソースへのアクセスを付与または拒否する ACL ルールが保存されます。ただし、Keycloak を使用した OAuth 2.0 トークンベースの承認では、より柔軟にアクセス制御を Kafka ブローカーに実装できます。さらに、Kafka ブローカーで OAuth 2.0 での承認および ACL が使用されるように設定することができます。

その他のリソース

3.7.1. OAuth 2.0 の承認メカニズム
リンクのコピー

AMQ Streams の OAuth 2.0 の承認では、Keycloak サーバーの Authorization Services REST エンドポイントを使用して、Keycloak を使用するトークンベースの認証が拡張されます。これは、定義されたセキュリティーポリシーを特定のユーザーに適用し、そのユーザーの異なるリソースに付与されたパーミッションの一覧を提供します。ポリシーはロールとグループを使用して、パーミッションをユーザーと照合します。OAuth 2.0 の承認では、Keycloak Authorization Services から受信した、ユーザーに付与された権限のリストを基にして、権限がローカルで強制されます。

3.7.1.1. Kafka ブローカーのカスタムオーソライザー
リンクのコピー

AMQ Streams では、Keycloak オーソライザー (KeycloakRBACAuthorizer) が提供されます。Keycloak によって提供される Authorization Services で Keycloak REST エンドポイントを使用できるようにするには、Kafka ブローカーでカスタムオーソライザーを設定します。

オーソライザーは必要に応じて付与された権限のリストを承認サーバーから取得し、ローカルで Kafka ブローカーに承認を強制するため、クライアントの要求ごとに迅速な承認決定が行われます。

3.7.2. OAuth 2.0 承認サポートの設定
リンクのコピー

この手順では、Keycloak Authorization Services を使用して、OAuth 2.0 の承認を使用するように Kafka ブローカーを設定する方法を説明します。

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

特定のユーザーに必要なアクセス、または制限するアクセスについて検討してください。Keycloak では、Keycloak グループ、ロール、クライアント、および ユーザー の組み合わせを使用して、アクセスを設定できます。

通常、グループは組織の部門または地理的な場所を基にしてユーザーを照合するために使用されます。また、ロールは職務を基にしてユーザーを照合するために使用されます。

Keycloak を使用すると、ユーザーおよびグループを LDAP で保存できますが、クライアントおよびロールは LDAP で保存できません。ユーザーデータへのアクセスとストレージを考慮して、承認ポリシーの設定方法を選択する必要がある場合があります。

注記

スーパーユーザーは、Kafka ブローカーに実装された承認にかかわらず、常に制限なく Kafka ブローカーにアクセスできます。

前提条件

AMQ Streams は、トークンベースの認証に Keycloak と OAuth 2.0 を使用するように設定されている必要があります。承認を設定するときに、同じ Keycloak サーバーエンドポイントを使用する必要があります。
Keycloak ドキュメントの説明にあるように、Keycloak Authorization Services のポリシーおよびパーミッションを管理する方法を理解する必要があります。

手順

Keycloak Admin Console にアクセスするか、Keycloak Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
承認サービスを使用して、クライアントのリソース、承認スコープ、ポリシー、およびパーミッションを定義します。
ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
エディターで Kafka リソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新して、Kafka ブローカーで Keycloak による承認が使用されるように設定します。
```
oc edit kafka my-cluster
```
```
oc edit kafka my-cluster
```
Copy to Clipboard Toggle word wrap

Kafka ブローカーの kafka 設定を指定して、keycloak による承認を使用し、承認サーバーと Red Hat Single Sign-On の Authorization Services にアクセスできるようにします。

以下に例を示します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka
  # ...
  authorization:
    type: keycloak 
    tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token> 
    clientId: kafka 
    delegateToKafkaAcls: false 
    disableTlsHostnameVerification: false 
    superUsers: 
      - CN=fred
      - sam
      - CN=edward
    tlsTrustedCertificates: 
    - secretName: oauth-server-cert
      certificate: ca.crt
  #...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka
  # ...
  authorization:
    type: keycloak


    tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token>


    clientId: kafka


    delegateToKafkaAcls: false


    disableTlsHostnameVerification: false


    superUsers:


      - CN=fred
      - sam
      - CN=edward
    tlsTrustedCertificates:


    - secretName: oauth-server-cert
      certificate: ca.crt
  #...

Copy to Clipboard

Toggle word wrap

1: タイプ keycloak は、Keycloak による承認を有効にします。
2: Keycloak トークンエンドポイントの URI。本番環境では常に HTTP を使用してください。
3: 承認サービスが有効になっている Keycloak の OAuth 2.0 クライアント定義のクライアント ID。通常、kafka が ID として使用されます。
4: (任意設定): Keycloak Authorization Services のポリシーによってアクセスが拒否されている場合は、Kafka SimpleACLAuthorizer に承認を委譲します。デフォルトは false です。
5: (任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。
6: (任意設定): 指定のスーパーユーザー。
7: (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。

エディターを保存して終了し、ローリングアップデートの完了を待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
```
oc logs -f ${POD_NAME} -c kafka
oc get po -w
```
```
oc logs -f ${POD_NAME} -c kafka
oc get po -w
```
Copy to Clipboard Toggle word wrap
ローリングアップデートによって、ブローカーが OAuth 2.0 承認を使用するように設定されます。
クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定したパーミッションを検証し、必要なアクセス権限があり、付与されるべきでないアクセス権限がないことを確認します。

3.8. デプロイメントのカスタマイズ
リンクのコピー

AMQ Streams では、OpenShift の operator によって管理される Deployments、StatefulSets、Pods、および Services などの複数の OpenShift リソースが作成されます。特定の OpenShift リソースの管理を担当する operator のみがそのリソースを変更できます。operator によって管理される OpenShift リソースを手動で変更しようとすると、operator はその変更を元に戻します。

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

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

このような変更は、AMQ Streams カスタムリソースの template プロパティーを使用して追加します。

3.8.1. テンプレートプロパティー
リンクのコピー

template プロパティーを使用すると、リソース作成プロセスの内容を設定できます。以下のリソースおよびプロパティーに追加できます。

Kafka.spec.kafka
Kafka.spec.zookeeper
Kafka.spec.entityOperator
Kafka.spec.kafkaExporter
KafkaConnect.spec
KafkaConnectS2I.spec
KafkaMirrorMakerSpec
KafkaBridge.spec

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

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

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

Copy to Clipboard

Toggle word wrap

3.8.1.1. Kafka クラスターでサポートされるテンプレートプロパティー
リンクのコピー

statefulset: Kafka ブローカーによって使用される StatefulSet を設定します。
pod: StatefulSet によって作成される Kafka ブローカー Pods を設定します。
bootstrapService: OpenShift 内で実行中のクライアントによって使用されるブートストラップサービスを設定し、Kafka ブローカーに接続します。
brokersService: ヘッドレスサービスを設定します。
externalBootstrapService: OpenShift の外部から Kafka ブローカーに接続するクライアントによって使用されるブートストラップサービスを設定します。
perPodService: OpenShift の外部から Kafka ブローカーに接続しているクライアントによって使用される Pod ごとのサービスを設定し、個別のブローカーにアクセスします。
externalBootstrapRoute: OpenShift Routes を使用して OpenShift の外部から Kafka ブローカーに接続するクライアントによって使用されるブートストラップルートを設定します。
perPodRoute: OpenShift の外部から Kafka ブローカーに接続するクライアントによって使用される Pod ごとのルートを設定し、OpenShift Routes を使用して個別のブローカーにアクセスします。
podDisruptionBudget: Kafka ブローカー StatefulSet の Pod の Disruption Budget を設定します。
kafkaContainer: カスタム環境変数を含む、Kafka ブローカーの実行に使用されるコンテナーを設定します。
tlsSidecarContainer: カスタム環境変数を含む、TLS サイドカーコンテナーを設定します。
initContainer: ブローカーの初期化に使用されるコンテナーを設定します。
persistentVolumeClaim: Kafka PersistentVolumeClaims のメタデータを設定します。

その他のリソース

「KafkaClusterTemplate スキーマ参照」

3.8.1.2. ZooKeeper クラスターでサポートされるテンプレートプロパティー
リンクのコピー

statefulset: ZooKeeper の StatefulSet を設定します。
pod: StatefulSet によって作成される ZooKeeper Pods を設定します。
clientsService: ZooKeeper にアクセスするためにクライアントによって使用されるサービスを設定します。
nodesService: ヘッドレスサービスを設定します。
podDisruptionBudget: ZooKeeper StatefulSet の Pod の Disruption Budget を設定します。
zookeeperContainer: カスタム環境変数を含む、ZooKeeper ノードの実行に使用されるコンテナーを設定します。
tlsSidecarContainer: カスタム環境変数を含む、TLS サイドカーコンテナーを設定します。
persistentVolumeClaim: ZooKeeper PersistentVolumeClaims のメタデータを設定します。

その他のリソース

「ZookeeperClusterTemplate スキーマ参照」

3.8.1.3. Entity Operator でサポートされるテンプレートプロパティー
リンクのコピー

deployment: Entity Operator によって使用されるデプロイメントを設定します。
pod: Deployment によって作成された Entity Operator Pod を設定します。
topicOperatorContainer: カスタム環境変数を含む、Topic Operator の実行に使用されるコンテナーを設定します。
userOperatorContainer: カスタム環境変数を含む、User Operator の実行に使用されるコンテナーを設定します。
tlsSidecarContainer: カスタム環境変数を含む、TLS サイドカーコンテナーを設定します。

その他のリソース

「EntityOperatorTemplate スキーマ参照」

3.8.1.4. Kafka Exporter でサポートされるテンプレートプロパティー
リンクのコピー

deployment: Kafka Exporter によって使用されるデプロイメントを設定します。
pod: Deployment によって作成される Kafka Exporter Pod を設定します。
services: Kafka Exporter サービスを設定します。
container: カスタム環境変数を含む、Kafka Exporter の実行に使用されるコンテナーを設定します。

その他のリソース

「KafkaExporterTemplate スキーマ参照」

3.8.1.5. Kafka Connect および Source2Image がサポートされる Kafka Connect でサポートされるテンプレート。
リンクのコピー

deployment: Kafka Connect の Deployment を設定します。
pod: Deployment によって作成される Kafka Connect Pods を設定します。
apiService: Kafka Connect REST API で使用されるサービスを設定します。
podDisruptionBudget: Kafka Connect Deployment の Pod の Disruption Budget を設定します。
connectContainer: カスタム環境変数を含む、Kafka Connect の実行に使用されるコンテナーを設定します。

その他のリソース

「KafkaConnectTemplate スキーマ参照」

3.8.1.6. Kafka MirrorMaker でサポートされるテンプレートプロパティー
リンクのコピー

deployment: Kafka MirrorMaker の Deployment を設定します。
pod: Deployment によって作成される Kafka MirrorMaker Pods を設定します。
podDisruptionBudget: Kafka MirrorMaker Deployment の Pod の Disruption Budget を設定します。
mirrorMakerContainer: カスタム環境変数を含む、Kafka MirrorMaker の実行に使用されるコンテナーを設定します。

その他のリソース

「KafkaMirrorMakerTemplate スキーマ参照」

3.8.2. ラベルおよびアノテーション
リンクのコピー

各リソースに、追加の Labels および Annotations を設定できます。Labels および Annotations は、リソースの識別および整理に使用され、metadata プロパティーで設定されます。

以下に例を示します。

# ...
template:
    statefulset:
        metadata:
            labels:
                label1: value1
                label2: value2
            annotations:
                annotation1: value1
                annotation2: value2
# ...

# ...
template:
    statefulset:
        metadata:
            labels:
                label1: value1
                label2: value2
            annotations:
                annotation1: value1
                annotation2: value2
# ...

Copy to Clipboard

Toggle word wrap

labels および annotations フィールドには、予約された文字列 strimzi.io が含まれないすべてのラベルやアノテーションを含めることができます。strimzi.io が含まれるラベルやアノテーションは、内部で AMQ Streams によって使用され、設定することはできません。

Kafka Connect では、KafkaConnect リソースのアノテーションは KafkaConnector リソースを使用したコネクターの作成および管理を有効にするために使用されます。詳細は、「KafkaConnector リソースの有効化」を参照してください。

注記

metadata プロパティーは、kafkaContainer などのコンテナーテンプレートには適用できません。

3.8.3. Pod のカスタマイズ
リンクのコピー

ラベルやアノテーションの他に、Pod の他のフィールドもカスタマイズできます。これらのフィールドの説明は以下の表を参照してください。これらのフィールドは Pod の作成方法に影響します。

Expand

フィールド	説明
`terminationGracePeriodSeconds`	Pod が正常終了されるはずの期間 (秒単位) を定義します。正常終了の期間後、Pod とそのコンテナーは強制的に終了 (kill) されます。デフォルト値は `30` 秒です。注記: 非常に大型な Kafka クラスターの場合は、正常終了期間を延長し、Kafka ブローカーの終了前に作業を別のブローカーに転送する時間を十分確保する必要があることがあります。
`imagePullSecrets`	プライベートリポジトリーからコンテナーイメージをプルするために使用できる OpenShift シークレットへの参照のリストを定義します。クレデンシャルを使用してシークレットを作成する方法の詳細は「Pull an Image from a Private Registry」を参照してください。注記: Cluster Operator の `STRIMZI_IMAGE_PULL_SECRETS` 環境変数と `imagePullSecrets` オプションが指定されると、`imagePullSecrets` 変数のみが使用されます。`STRIMZI_IMAGE_PULL_SECRETS` 変数は無視されます。
`securityContext`	特定の Pod の一部として実行されているコンテナーの Pod レベルのセキュリティー属性を設定します。SecurityContext の設定に関する詳細は、「Configure a Security Context for a Pod or Container」を参照してください。
`priorityClassName`	指定の Pod に使用される Priority Class (優先順位クラス) の名前を設定します。Priority Class (優先順位クラス) の詳細は、「Pod Priority and Preemption」を参照してください。
`schedulerName`	この `Pod` のディスパッチに使用されるスケジューラーの名前。指定されていない場合、デフォルトのスケジューラーが使用されます。

これらのフィールドは、各タイプのクラスター (Kafka および ZooKeeper、Kafka Connect および S2I サポートのある Kafka Connect、Kafka MirrorMaker) で有効です。

以下は、template プロパティーのカスタマイズされたフィールドの例になります。

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
    imagePullSecrets:
      - name: my-docker-credentials
    securityContext:
      runAsUser: 1000001
      fsGroup: 0
    terminationGracePeriodSeconds: 120
# ...

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
    imagePullSecrets:
      - name: my-docker-credentials
    securityContext:
      runAsUser: 1000001
      fsGroup: 0
    terminationGracePeriodSeconds: 120
# ...

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.8.4. 環境変数でのコンテナーのカスタマイズ
リンクのコピー

関連する template コンテナープロパティーを使用すると、コンテナーのカスタム環境変数を設定できます。以下の表は、各カスタムリソースの AMQ Streams コンテナーと、関連するテンプレート設定プロパティー (spec で定義) を示しています。

Expand

表3.1 コンテナー環境変数プロパティー
AMQ Streams 要素	コンテナー	設定プロパティー
Kafka	Kafka Broker	`kafka.template.kafkaContainer.env`
Kafka	Kafka Broker TLS Sidecar	`kafka.template.tlsSidecarContainer.env`
Kafka	Kafka Initialization	`kafka.template.initContainer.env`
Kafka	ZooKeeper Node	`zookeeper.template.zookeeperContainer.env`
Kafka	ZooKeeper TLS Sidecar	`zookeeper.template.tlsSidecarContainer.env`
Kafka	Topic Operator	`entityOperator.template.topicOperatorContainer.env`
Kafka	User Operator	`entityOperator.template.userOperatorContainer.env`
Kafka	Entity Operator TLS Sidecar	`entityOperator.template.tlsSidecarContainer.env`
KafkaConnect	Connect and ConnectS2I	`template.connectContainer.env`
KafkaMirrorMaker	MirrorMaker	`template.mirrorMakerContainer.env`
KafkaBridge	Bridge	`template.bridgeContainer.env`

環境変数は、env プロパティーで name および value フィールドのあるオブジェクトのリストとして定義されます。以下は、Kafka ブローカーコンテナーに設定された 2 つのカスタム環境変数の例になります。

# ...
kind: Kafka
spec:
    kafka:
        template:
            kafkaContainer:
                env:
                    - name: TEST_ENV_1
                      value: test.env.one
                    - name: TEST_ENV_2
                      value: test.env.two
# ...

# ...
kind: Kafka
spec:
    kafka:
        template:
            kafkaContainer:
                env:
                    - name: TEST_ENV_1
                      value: test.env.one
                    - name: TEST_ENV_2
                      value: test.env.two
# ...

Copy to Clipboard

Toggle word wrap

KAFKA_ で始まる環境変数は AMQ Streams 内部となるため、使用しないようにしてください。AMQ Streams によってすでに使用されているカスタム環境変数を設定すると、その環境変数は無視され、警告がログに記録されます。

その他のリソース

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

3.8.5. 外部サービスのカスタマイズ
リンクのコピー

ロードバランサーまたはノードポートを使用して OpenShift 外部で Kafka を公開する場合、ラベルとアノテーションの他に追加のカスタマイズプロパティーを使用できます。外部サービスのプロパティーの説明は以下の表を参照してください。外部サービスのプロパティーはサービスの作成方法に影響します。

Expand

フィールド説明

フィールド	説明
`externalTrafficPolicy`	サービスによって外部トラフィックがローカルノードのエンドポイントまたはクラスター全体のエンドポイントにルーティングされるかどうかを指定します。`Cluster` を指定すると、別のノードへの 2 回目のホップが発生し、クライアントソースの IP が特定しにくくなる可能性があります。`Local` を指定すると、LoadBalancer および Nodeport タイプのサービスに対して 2 回目のホップが発生しないようにし、クライアントソースの IP を維持します (インフラストラクチャーでサポートされる場合)。指定されていない場合、OpenShift は `Cluster` をデフォルトとして使用します。
`loadBalancerSourceRanges`	クライアントがロードバランサータイプのリスナーに接続できる CIDR 形式による範囲 (例: `10.0.0.0/8`、`130.211.204.1/32`) の一覧。プラットフォームでサポートされる場合、ロードバランサー経由のトラフィックは指定された CIDR 範囲に制限されます。このフィールドは、ロードバランサータイプのサービスのみに適用され、クラウドプロバイダーがこの機能をサポートしない場合は無視されます。詳細は「https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/」を参照してください。

externalTrafficPolicy

サービスによって外部トラフィックがローカルノードのエンドポイントまたはクラスター全体のエンドポイントにルーティングされるかどうかを指定します。Cluster を指定すると、別のノードへの 2 回目のホップが発生し、クライアントソースの IP が特定しにくくなる可能性があります。Local を指定すると、LoadBalancer および Nodeport タイプのサービスに対して 2 回目のホップが発生しないようにし、クライアントソースの IP を維持します (インフラストラクチャーでサポートされる場合)。指定されていない場合、OpenShift は Cluster をデフォルトとして使用します。

loadBalancerSourceRanges

クライアントがロードバランサータイプのリスナーに接続できる CIDR 形式による範囲 (例: 10.0.0.0/8、130.211.204.1/32) の一覧。プラットフォームでサポートされる場合、ロードバランサー経由のトラフィックは指定された CIDR 範囲に制限されます。このフィールドは、ロードバランサータイプのサービスのみに適用され、クラウドプロバイダーがこの機能をサポートしない場合は無視されます。

詳細は「https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/」を参照してください。

これらのプロパティーは、externalBootstrapService および perPodService で使用できます。以下は、template のカスタマイズされたプロパティーの例になります。

# ...
template:
  externalBootstrapService:
    externalTrafficPolicy: Local
    loadBalancerSourceRanges:
      - 10.0.0.0/8
      - 88.208.76.87/32
  perPodService:
    externalTrafficPolicy: Local
    loadBalancerSourceRanges:
      - 10.0.0.0/8
      - 88.208.76.87/32
# ...

# ...
template:
  externalBootstrapService:
    externalTrafficPolicy: Local
    loadBalancerSourceRanges:
      - 10.0.0.0/8
      - 88.208.76.87/32
  perPodService:
    externalTrafficPolicy: Local
    loadBalancerSourceRanges:
      - 10.0.0.0/8
      - 88.208.76.87/32
# ...

Copy to Clipboard

Toggle word wrap

その他のリソース

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

3.8.6. イメージプルポリシーのカスタマイズ
リンクのコピー

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」を参照してください。

3.8.7. Pod の Disruption Budget (停止状態の予算) のカスタマイズ
リンクのコピー

AMQ Streams では、新しい StatefulSet または Deployment ごとに Pod の Disruption Budget が作成されます。デフォルトでは、PodDisruptionBudget.spec リソースの maxUnavailable の値が 1 に設定され、Pod の Disruption Budget で単一の Pod を利用不可能にすることができます。Pod の Disruption Budget のテンプレートで maxUnavailable のデフォルト値を変更すると、許容される利用不可能な Pod の数を変更できます。このテンプレートは、各タイプのクラスター (Kafka および ZooKeeper、Kafka Connect および S2I サポートのある Kafka Connect、および Kafka MirrorMaker) に適用されます。

以下は、template プロパティーのカスタマイズされた podDisruptionBudget フィールドの例になります。

# ...
template:
    podDisruptionBudget:
        metadata:
            labels:
                key1: label1
                key2: label2
            annotations:
                key1: label1
                key2: label2
        maxUnavailable: 1
# ...

# ...
template:
    podDisruptionBudget:
        metadata:
            labels:
                key1: label1
                key2: label2
            annotations:
                key1: label1
                key2: label2
        maxUnavailable: 1
# ...

Copy to Clipboard

Toggle word wrap

その他のリソース

詳細は「PodDisruptionBudgetTemplate スキーマ参照」を参照してください。
Kubernetes ドキュメントの「Disruptions」の章を参照してください。

3.8.8. デプロイメントのカスタマイズ
リンクのコピー

この手順では、Kafka クラスターの Labels をカスタマイズする方法を説明します。

前提条件

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

手順

Kafka、KafkaConnect、KafkaConnectS2I、または KafkaMirrorMaker リソースの template プロパティーを編集します。たとえば、Kafka ブローカー StatefulSet のラベルを変更する場合は、以下を使用します。

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

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

Copy to Clipboard

Toggle word wrap

リソースを作成または更新します。
oc apply を使用します。
```
oc apply -f your-file
```
```
oc apply -f your-file
```
Copy to Clipboard Toggle word wrap
あるいは、oc edit を使用します。
```
oc edit Resource ClusterName
```
```
oc edit Resource ClusterName
```
Copy to Clipboard Toggle word wrap

3.9. 外部ロギング
リンクのコピー

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

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

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

Copy to Clipboard

Toggle word wrap

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

spec:
  # ...
  logging:
    type: external
    name: customConfigMap

spec:
  # ...
  logging:
    type: external
    name: customConfigMap

Copy to Clipboard

Toggle word wrap

外部ロギングでは、ロギングプロパティーは ConfigMap に定義されます。ConfigMap の名前は spec.logging.name プロパティーで参照されます。

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

3.9.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/v1beta1
metadata:
  name: logging-configmap
data:
  log4j.properties:
    kafka.root.logger.level="INFO"
```
```
kind: ConfigMap
apiVersion: kafka.strimzi.io/v1beta1
metadata:
  name: logging-configmap
data:
  log4j.properties:
    kafka.root.logger.level="INFO"
```
Copy to Clipboard Toggle word wrap
プロパティーファイルを使用してコマンドラインから作成します。
```
oc create configmap logging-configmap --from-file=log4j.properties
```
```
oc create configmap logging-configmap --from-file=log4j.properties
```
Copy to Clipboard Toggle word wrap
プロパティーファイルではロギング設定が定義されます。
```
# Define the root logger
kafka.root.logger.level="INFO"
# ...
```
```
# Define the root logger
kafka.root.logger.level="INFO"
# ...
```
Copy to Clipboard Toggle word wrap
logging.name を ConfigMap の名前に設定し、リソースの spec の external ロギングを定義します。
```
spec:
  # ...
  logging:
    type: external
    name: logging-configmap
```
```
spec:
  # ...
  logging:
    type: external
    name: logging-configmap
```
Copy to Clipboard Toggle word wrap
リソースを作成または更新します。
```
oc apply -f kafka.yaml
```
```
oc apply -f kafka.yaml
```
Copy to Clipboard Toggle word wrap

トップに戻る

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

3.1. Kafka クラスターの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.1. Kafka YAML の設定例リンクのコピーリンクがクリップボードにコピーされました!

3.1.2. データストレージに関する留意事項リンクのコピーリンクがクリップボードにコピーされました!

3.1.2.1. ファイルシステムリンクのコピーリンクがクリップボードにコピーされました!

3.1.2.2. Apache Kafka および ZooKeeper ストレージリンクのコピーリンクがクリップボードにコピーされました!

3.1.3. Kafka および ZooKeeper のストレージタイプリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.1. 一時ストレージリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.1.1. ログディレクトリーリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.2. 永続ストレージリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.2.1. ストレージクラスのオーバーライドリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.2.2. Persistent Volume Claim (永続ボリューム要求、PVC) の命名リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.2.3. ログディレクトリーリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.3. 永続ボリュームのサイズ変更リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.4. JBOD ストレージの概要リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.4.1. JBOD の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.4.2. JBOD および 永続ボリューム要求 (PVC)リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.4.3. ログディレクトリーリンクのコピーリンクがクリップボードにコピーされました!

3.1.3.5. JBOD ストレージへのボリュームの追加リンクのコピーリンクがクリップボードにコピーされました!

3.1.3.6. JBOD ストレージからのボリュームの削除リンクのコピーリンクがクリップボードにコピーされました!

3.1.4. Kafka ブローカーレプリカリンクのコピーリンクがクリップボードにコピーされました!

3.1.4.1. ブローカーノード数の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.5. Kafka ブローカーの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.5.1. Kafka ブローカーの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.5.2. Kafka ブローカーの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.6. Kafka ブローカーリスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.1. Kafka リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.2. Kafka リスナーの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3. リスナー認証リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.1. リスナーの認証設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.2. 相互 TLS 認証リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.2.1. クライアントに相互 TLS 認証を使用する場合リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.3. SCRAM-SHA 認証リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.3.1. サポートされる SCRAM クレデンシャルリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.3.3.2. クライアントに SCRAM-SHA 認証を使用する場合リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4. 外部リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.1. 外部リスナーでアドバタイズされたアドレスのカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.2. ルート外部リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.2.1. OpenShift Routes を使用した Kafka の公開リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.2.2. OpenShift ルートを使用した Kafka へのアクセスリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.3. ロードバランサー外部リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.3.1. ロードバランサーを使用した Kafka の公開リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.3.2. 外部ロードバランサーリスナーの DNS 名のカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.3.3. ロードバランサー IP アドレスのカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.3.4. ロードバランサーを使用した Kafka へのアクセスリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.4. ノードポートの外部リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.4.1. ノードポートを使用した Kafka の公開リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.4.2. 外部ノードポートリスナーの DNS 名のカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.4.3. ノードポートを使用した Kafka へのアクセスリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.5. OpenShift Ingress 外部リスナーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.5.1. Kubernetes Ingress を使用した Kafka の公開リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.5.2. Ingress クラスの設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.5.3. 外部 ingress リスナーの DNS 名のカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.4.5.4. ingress を使用した Kafka へのアクセスリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.5. ネットワークポリシーリンクのコピーリンクがクリップボードにコピーされました!

3.1.6.5.1. リスナーのネットワークポリシー設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.6.5.2. networkPolicyPeers を使用した Kafka リスナーへのアクセス制限リンクのコピーリンクがクリップボードにコピーされました!

3.1.7. 認証および承認リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.1. 認証リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.1.1. TLS クライアント認証リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.2. Kafka ブローカーでの認証の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.3. 承認リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.3.1. 簡易承認リンクのコピーリンクがクリップボードにコピーされました!

3.1.7.3.2. スーパーユーザーリンクのコピーリンクがクリップボードにコピーされました!

3.1.7.4. Kafka ブローカーでの承認の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.8. ZooKeeper レプリカリンクのコピーリンクがクリップボードにコピーされました!

3.1.8.1. ZooKeeper ノードの数リンクのコピーリンクがクリップボードにコピーされました!

3.1.8.2. ZooKeeper レプリカの数の変更リンクのコピーリンクがクリップボードにコピーされました!

3.1.9. ZooKeeper の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.9.1. ZooKeeper の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.9.2. ZooKeeper の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.10. ZooKeeper の接続リンクのコピーリンクがクリップボードにコピーされました!

3.1.10.1. ターミナルからの ZooKeeper への接続リンクのコピーリンクがクリップボードにコピーされました!

3.1.11. Entitiy Operatorリンクのコピーリンクがクリップボードにコピーされました!

3.1.11.1. Entity Operator の設定プロパティーリンクのコピーリンクがクリップボードにコピーされました!

3.1.11.2. Topic Operator 設定プロパティーリンクのコピーリンクがクリップボードにコピーされました!

3.1.11.3. User Operator 設定プロパティーリンクのコピーリンクがクリップボードにコピーされました!

3.1.11.4. Operator ロガーリンクのコピーリンクがクリップボードにコピーされました!

3.1.11.5. Entity Operator の設定リンクのコピーリンクがクリップボードにコピーされました!

3.1.12. CPU およびメモリーリソースリンクのコピーリンクがクリップボードにコピーされました!

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

3.1. Kafka クラスターの設定
リンクのコピー

3.1.1. Kafka YAML の設定例
リンクのコピー

3.1.2. データストレージに関する留意事項
リンクのコピー

3.1.2.1. ファイルシステム
リンクのコピー

3.1.2.2. Apache Kafka および ZooKeeper ストレージ
リンクのコピー

3.1.3. Kafka および ZooKeeper のストレージタイプ
リンクのコピー

3.1.3.1. 一時ストレージ
リンクのコピー

3.1.3.1.1. ログディレクトリー
リンクのコピー

3.1.3.2. 永続ストレージ
リンクのコピー

3.1.3.2.1. ストレージクラスのオーバーライド
リンクのコピー

3.1.3.2.2. Persistent Volume Claim (永続ボリューム要求、PVC) の命名
リンクのコピー

3.1.3.2.3. ログディレクトリー
リンクのコピー

3.1.3.3. 永続ボリュームのサイズ変更
リンクのコピー

3.1.3.4. JBOD ストレージの概要
リンクのコピー

3.1.3.4.1. JBOD の設定
リンクのコピー

3.1.3.4.2. JBOD および永続ボリューム要求 (PVC)
リンクのコピー

3.1.3.4.3. ログディレクトリー
リンクのコピー

3.1.3.5. JBOD ストレージへのボリュームの追加
リンクのコピー

3.1.3.6. JBOD ストレージからのボリュームの削除
リンクのコピー

3.1.4. Kafka ブローカーレプリカ
リンクのコピー

3.1.4.1. ブローカーノード数の設定
リンクのコピー

3.1.5. Kafka ブローカーの設定
リンクのコピー

3.1.5.1. Kafka ブローカーの設定
リンクのコピー

3.1.5.2. Kafka ブローカーの設定
リンクのコピー

3.1.6. Kafka ブローカーリスナー
リンクのコピー

3.1.6.1. Kafka リスナー
リンクのコピー

3.1.6.2. Kafka リスナーの設定
リンクのコピー

3.1.6.3. リスナー認証
リンクのコピー

3.1.6.3.1. リスナーの認証設定
リンクのコピー

3.1.6.3.2. 相互 TLS 認証
リンクのコピー

3.1.6.3.2.1. クライアントに相互 TLS 認証を使用する場合
リンクのコピー

3.1.6.3.3. SCRAM-SHA 認証
リンクのコピー

3.1.6.3.3.1. サポートされる SCRAM クレデンシャル
リンクのコピー

3.1.6.3.3.2. クライアントに SCRAM-SHA 認証を使用する場合
リンクのコピー

3.1.6.4. 外部リスナー
リンクのコピー

3.1.6.4.1. 外部リスナーでアドバタイズされたアドレスのカスタマイズ
リンクのコピー

3.1.6.4.2. ルート外部リスナー
リンクのコピー

3.1.6.4.2.1. OpenShift Routes を使用した Kafka の公開
リンクのコピー

3.1.6.4.2.2. OpenShift ルートを使用した Kafka へのアクセス
リンクのコピー

3.1.6.4.3. ロードバランサー外部リスナー
リンクのコピー

3.1.6.4.3.1. ロードバランサーを使用した Kafka の公開
リンクのコピー

3.1.6.4.3.2. 外部ロードバランサーリスナーの DNS 名のカスタマイズ
リンクのコピー

3.1.6.4.3.3. ロードバランサー IP アドレスのカスタマイズ
リンクのコピー

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

3.1.6.4.4. ノードポートの外部リスナー
リンクのコピー

3.1.6.4.4.1. ノードポートを使用した Kafka の公開
リンクのコピー

3.1.6.4.4.2. 外部ノードポートリスナーの DNS 名のカスタマイズ
リンクのコピー

3.1.6.4.4.3. ノードポートを使用した Kafka へのアクセス
リンクのコピー

3.1.6.4.5. OpenShift Ingress 外部リスナー
リンクのコピー

3.1.6.4.5.1. Kubernetes Ingress を使用した Kafka の公開
リンクのコピー

3.1.6.4.5.2. Ingress クラスの設定
リンクのコピー

3.1.6.4.5.3. 外部 ingress リスナーの DNS 名のカスタマイズ
リンクのコピー

3.1.6.4.5.4. ingress を使用した Kafka へのアクセス
リンクのコピー

3.1.6.5. ネットワークポリシー
リンクのコピー

3.1.6.5.1. リスナーのネットワークポリシー設定
リンクのコピー

3.1.6.5.2. networkPolicyPeers を使用した Kafka リスナーへのアクセス制限
リンクのコピー

3.1.7. 認証および承認
リンクのコピー

3.1.7.1. 認証
リンクのコピー

3.1.7.1.1. TLS クライアント認証
リンクのコピー

3.1.7.2. Kafka ブローカーでの認証の設定
リンクのコピー

3.1.7.3. 承認
リンクのコピー

3.1.7.3.1. 簡易承認
リンクのコピー

3.1.7.3.2. スーパーユーザー
リンクのコピー

3.1.7.4. Kafka ブローカーでの承認の設定
リンクのコピー

3.1.8. ZooKeeper レプリカ
リンクのコピー

3.1.8.1. ZooKeeper ノードの数
リンクのコピー

3.1.8.2. ZooKeeper レプリカの数の変更
リンクのコピー

3.1.9. ZooKeeper の設定
リンクのコピー

3.1.9.1. ZooKeeper の設定
リンクのコピー

3.1.9.2. ZooKeeper の設定
リンクのコピー

3.1.10. ZooKeeper の接続
リンクのコピー

3.1.10.1. ターミナルからの ZooKeeper への接続
リンクのコピー

3.1.11. Entitiy Operator
リンクのコピー

3.1.11.1. Entity Operator の設定プロパティー
リンクのコピー

3.1.11.2. Topic Operator 設定プロパティー
リンクのコピー

3.1.11.3. User Operator 設定プロパティー
リンクのコピー

3.1.11.4. Operator ロガー
リンクのコピー

3.1.11.5. Entity Operator の設定
リンクのコピー

3.1.12. CPU およびメモリーリソース
リンクのコピー