Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

8.3. (プレビュー) ノードプールの設定

KafkaNodePool カスタムリソースの spec プロパティーを更新して、ノードプールデプロイメントを設定します。

注記

ノードプール機能はプレビューとして利用できます。ノードプールはデフォルトでは有効になっていないため、使用する前に KafkaNodePools フィーチャーゲートを有効にする 必要があります。

ノードプールは、Kafka クラスター内の Kafka ノードの個別のグループを指します。各プールには独自の固有の設定があり、これにはレプリカの数、ロール、ストレージ割り当ての必須設定が含まれます。

オプションで、次のプロパティーの値を指定することもできます。

  • メモリーと CPU のリクエストと制限を指定する resources
  • Pod およびその他の OpenShift リソースのカスタム設定を指定する template
  • jvmOptions : ヒープサイズ、ランタイム、その他のオプションのカスタム JVM 設定を指定します。

Kafka リソースは、Kafka クラスター内のすべてのノードの設定を表します。KafkaNodePool リソースは、ノードプール内のノードのみの設定を表します。設定プロパティーが KafkaNodePool で指定されていない場合は、Kafka リソースから継承されます。両方のリソースで設定されている場合は、KafkaNodePool リソースで指定された設定が優先されます。たとえば、ノードプールと Kafka 設定の両方に jvmOptions が含まれている場合、ノードプール設定で指定された値が使用されます。-Xmx: 1024m が KafkaNodePool.spec.jvmOptions に設定され、-Xms: 512m が Kafka.spec.kafka.jvmOptions に設定されている場合、ノードはノードプール設定の値を使用します。

Kafka と KafkaNodePool スキーマのプロパティーは組みわせることができません。明確にするために、KafkaNodePool.spec.template に podSet.metadata.labels のみが含まれており、Kafka.spec.kafka.template に podSet.metadata.annotations および pod.metadata.labels が含まれている場合、ノードプール設定内のテンプレート値があるため、Kafka 設定のテンプレート値は無視されます。

ノードプールは、KRaft モード (Kafka Raft メタデータを使用) で動作する Kafka クラスターで使用することも、クラスター管理に ZooKeeper を使用することもできます。KRaft モードを使用している場合は、ノードプール内のすべてのノードがブローカー、コントローラー、またはその両方として動作するようにロールを指定できます。ZooKeeper を使用している場合は、ノードをブローカーのみとして設定する必要があります。

重要

KRaft モードは、Apache Kafka または AMQ Streams での運用の準備ができていません。

ノードプールの設定オプションの詳細は、AMQ Streams カスタムリソースの API リファレンス を参照してください。

注記

ノードプールを有効にする KafkaNodePools フィーチャーゲートはアルファ段階にありますが、KafkaNodePool リソースのレプリカおよびストレージ設定プロパティーも Kafka リソースに存在する必要があります。ノードプールが使用されている場合、Kafka リソースの設定は無視されます。同様に、KRaft モードを使用する場合は、ZooKeeper 設定プロパティーも Kafka リソースに存在する必要があります。これらのプロパティーも無視されます。

ZooKeeper を使用したクラスター内のノードプールの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
1 

  labels:
    strimzi.io/cluster: my-cluster
2 

spec:
  replicas: 3
3 

  roles:
    - broker
4 

  storage:
5 

    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
  resources:
6 

      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
Copy to Clipboard Toggle word wrap

1
ノードプールの一意の名前。
2
ノードプールが属する Kafka クラスター。ノードプールは 1 つのクラスターにのみ属することができます。
3
ノードのレプリカの数。
4
ノードプール内のノードのロール。ZooKeeper で Kafka を使用する場合にのみ broker でありえます。
5
ノードのストレージ仕様。
6
現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。

KRaft モードを使用したクラスター内のノードプールの設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: kraft-dual-role
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
1 

    - controller
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 20Gi
        deleteClaim: false
  resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
Copy to Clipboard Toggle word wrap

1
ノードプール内のノードのロール。この例では、ノードにはコントローラーとブローカーとしての二重のロールがあります。
注記

Kafka リソースの設定は、KRaft モードに適している必要があります。現在、KRaft モードには 多くの制限 があります。

8.3.1. (プレビュー) スケーリング操作のためのノードプールへの ID の割り当て
リンクのコピー

この手順では、ノードプールでスケーリング操作を実行するときに、Cluster Operator による高度なノード ID 処理にアノテーションを使用する方法について説明します。Cluster Operator が順番に次の ID を使用するのではなく、使用するノード ID を指定します。この方法でノード ID を管理すると、より詳細な制御が可能になります。

ID の範囲を追加するには、以下のアノテーションを KafkaNodePool リソースに割り当てます。

  • 新しいブローカーに使用される ID の範囲を追加する strimzi.io/next-node-ids
  • 既存のブローカーを削除するための ID の範囲を追加する strimzi.io/remove-node-ids

個別のノード ID、ID 範囲、または両方の組み合わせを指定できます。たとえば、Kafka ノードプールをスケールアップするために [0, 1, 2, 10-20, 30] の ID の範囲を指定できます。この形式では、個々のノード ID (0、1、2、30) の組み合わせと ID の範囲 (10-20) を指定できます。

一般的なシナリオでは、スケールアップする場合は ID の範囲を指定し、スケールダウンする場合は特定のノードを削除する場合は単一のノード ID を指定します。

この手順では、次のようにスケーリングアノテーションをノードプールに追加します。

  • pool-a にはスケールアップ用の ID 範囲が割り当てられます
  • pool-b には、スケールダウン用の ID 範囲が割り当てられます

スケーリング操作中、ID は次のように使用されます。

  • スケールアップでは、新しいノードの範囲内で使用可能な最小の ID が選択されます。
  • スケールダウンすると、範囲内で使用可能な最大の ID を持つノードが削除されます。

ノードプールに割り当てられたノード ID のシーケンスにギャップがある場合、次に追加されるノードにはギャップを埋める ID が割り当てられます。

アノテーションは、スケーリング操作のたびに更新する必要はありません。未使用の ID は、次のスケーリングイベントでも引き続き有効です。

Cluster Operator を使用すると、ID の範囲を昇順または降順で指定できるため、ノードがスケーリングされる順序で ID を定義できます。たとえば、スケールアップする場合、1000-1999 などの範囲を指定すると、新しいノードには次に低い ID (1000、1001、1002、1003 など) が割り当てられます。逆に、スケールダウンする場合は、1999-1000 のような範囲を指定して、次に高い ID (1003、1002、1001、1000 など) を持つノードが確実に削除されるようにすることができます。

アノテーションを使用して ID 範囲を指定しない場合、Cluster Operator はスケーリング操作中に ID を処理するデフォルトの動作に従います。ノード ID は 0 (ゼロ) から始まり、Kafka クラスター全体で順番に実行されます。次に小さい ID が新しいノードに割り当てられます。ノード ID とのギャップはクラスター全体で埋められます。これは、ノードプール内で順番に実行できない可能性があることを意味します。スケールアップのデフォルトの動作では、クラスター全体で次に小さい使用可能なノード ID を追加します。スケールダウンの場合は、ノードプール内の使用可能なノード ID が最も大きいノードを削除します。デフォルトのアプローチは、割り当てられた ID 範囲の形式が間違っている場合、スケールアップ範囲で ID が不足する場合、またはスケールダウン範囲が使用中のノードに適用されない場合にも適用されます。

前提条件

デフォルトでは、Apache Kafka はノード ID を 0 ~ 999 の範囲の数値に制限します。999 より大きいノード ID 値を使用するには、reserved.broker-max.id 設定プロパティーを Kafka カスタムリソースに追加し、必要な最大ノード ID 値を指定します。

この例では、最大ノード ID は 10000 に設定されます。その後、ノード ID をその値に割り当てることができます。

最大ノード ID 番号の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    config:
      reserved.broker.max.id: 10000
  # ...
Copy to Clipboard Toggle word wrap

手順

  1. 次の例に示すように、スケールアップまたはスケールダウン時に使用する ID でノードプールにアノテーションを付けます。

    スケールアップ用の ID は、ノードプール pool-a に割り当てられます。

    スケールアップ用の ID の割り当て

    oc annotate kafkanodepool pool-a strimzi.io/next-node-ids="[0,1,2,10-20,30]"
    Copy to Clipboard Toggle word wrap

    ノードを pool-a に追加するときに、この範囲内で使用可能な最小の ID が使用されます。

    スケールダウン用の ID はノードプール pool-b に割り当てられます。

    スケールダウン用の ID の割り当て

    oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids="[60-50,9,8,7]"
    Copy to Clipboard Toggle word wrap

    pool-b をスケールダウンすると、この範囲内で使用可能な最大の ID が削除されます。

    注記

    特定のノードを削除する場合は、単一のノード ID をスケールダウンアノテーションに割り当てることができます (oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids="3")。

  2. ノードプールをスケーリングできるようになりました。

    詳細は、以下を参照してください。

    調整時に、アノテーションの形式が間違っている場合は警告が表示されます。

  3. スケーリング操作の実行後に、アノテーションが不要になった場合は削除できます。

    スケールアップ用のアノテーションの削除

    oc annotate kafkanodepool pool-a strimzi.io/next-node-ids-
    Copy to Clipboard Toggle word wrap

    スケールダウン用のアノテーションの削除

    oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids-
    Copy to Clipboard Toggle word wrap

8.3.2. (プレビュー) ノードプールへのノードの追加
リンクのコピー

この手順では、ノードプールをスケールアップして新しいノードを追加する方法について説明します。

この手順では、ノードプール pool-a の 3 つのノードから始めます。

ノードプール内の Kafka ノード

NAME                 READY  STATUS   RESTARTS
my-cluster-pool-a-0  1/1    Running  0
my-cluster-pool-a-1  1/1    Running  0
my-cluster-pool-a-2  1/1    Running  0
Copy to Clipboard Toggle word wrap

ノード ID は、作成時にノードの名前に追加されます。ノード ID が 3 であるノード my-cluster-pool-a-3 を追加します。

注記

このプロセス中に、パーティションのレプリカを保持するノードの ID が変更されます。ノード ID を参照する依存関係を考慮してください。

前提条件

手順

  1. ノードプールに新しいノードを作成します。

    たとえば、ノードプール pool-a には 3 つのレプリカがあります。レプリカの数を増やしてノードを追加します。 

    oc scale kafkanodepool pool-a --replicas=4
    Copy to Clipboard Toggle word wrap

  2. デプロイメントのステータスを確認し、ノードプール内の Pod が作成され、ステータスが READY になるまで待ちます。 

    oc get pods -n <my_cluster_operator_namespace>
    Copy to Clipboard Toggle word wrap

    出力には、ノードプール内の 4 つの Kafka ノードが表示されます

    NAME                 READY  STATUS   RESTARTS
my-cluster-pool-a-0  1/1    Running  0
my-cluster-pool-a-1  1/1    Running  0
my-cluster-pool-a-2  1/1    Running  0
my-cluster-pool-a-3  1/1    Running  0
    Copy to Clipboard Toggle word wrap

  3. ノードプール内のノードの数を増やした後、パーティションを再割り当てします。

    ノードプールをスケールアップした後、Cruise Control の add-brokers モードを使用して、パーティションレプリカを既存のブローカーから新しく追加したブローカーに移動できます。

8.3.3. (プレビュー) ノードプールからのノードの削除
リンクのコピー

この手順では、ノードプールをスケールダウンしてノードを削除する方法について説明します。

この手順では、ノードプール pool-a の 4 つのノードから開始します。

ノードプール内の Kafka ノード

NAME                 READY  STATUS   RESTARTS
my-cluster-pool-a-0  1/1    Running  0
my-cluster-pool-a-1  1/1    Running  0
my-cluster-pool-a-2  1/1    Running  0
my-cluster-pool-a-3  1/1    Running  0
Copy to Clipboard Toggle word wrap

ノード ID は、作成時にノードの名前に追加されます。ノード ID が 3 であるノード my-cluster-pool-a-3 を削除します。

注記

このプロセス中に、パーティションのレプリカを保持するノードの ID が変更されます。ノード ID を参照する依存関係を考慮してください。

前提条件

手順

  1. ノードプール内のノードの数を減らす前に、パーティションを再割り当てします。

    ノードプールをスケールダウンする前に、Cruise Control remove-brokers モードを使用して、削除されるブローカーからパーティションレプリカを移動できます。

  2. 再割り当てプロセスが完了し、削除されるノードにライブパーティションがなくなったら、ノードプール内の Kafka ノードの数を減らします。

    たとえば、ノードプール pool-b には 4 つのレプリカがあります。レプリカの数を減らしてノードを削除します。 

    oc scale kafkanodepool pool-a --replicas=3
    Copy to Clipboard Toggle word wrap

    出力には、ノードプール内の 3 つの Kafka ノードが表示されます

    NAME                       READY  STATUS   RESTARTS
my-cluster-pool-b-kafka-0  1/1    Running  0
my-cluster-pool-b-kafka-1  1/1    Running  0
my-cluster-pool-b-kafka-2  1/1    Running  0
    Copy to Clipboard Toggle word wrap

8.3.4. (プレビュー) ノードプール間でのノードの移動
リンクのコピー

この手順では、ダウンタイムなしでソース Kafka ノードプールとターゲット Kafka ノードプール間でノードを移動する方法について説明します。ターゲットノードプールに新しいノードを作成し、パーティションを再割り当てして、ソースノードプールの古いノードからデータを移動します。新しいノード上のレプリカが同期している場合、古いノードを削除できます。

この手順では、2 つのノードプールから始めます。

  • 3 つのレプリカを持つ pool-a がターゲットノードプールです
  • 4 つのレプリカを持つ pool-b がソースノードプールです

pool-a をスケールアップし、パーティションを再割り当てして pool-b をスケールダウンします。その結果、次のようになります。

  • 4 つのレプリカを持つ pool-a
  • 3 つのレプリカを持つ pool-b
注記

このプロセス中に、パーティションのレプリカを保持するノードの ID が変更されます。ノード ID を参照する依存関係を考慮してください。

前提条件

手順

  1. ターゲットノードプールに新しいノードを作成します。

    たとえば、ノードプール pool-a には 3 つのレプリカがあります。レプリカの数を増やしてノードを追加します。 

    oc scale kafkanodepool pool-a --replicas=4
    Copy to Clipboard Toggle word wrap

  2. デプロイメントのステータスを確認し、ノードプール内の Pod が作成され、ステータスが READY になるまで待ちます。 

    oc get pods -n <my_cluster_operator_namespace>
    Copy to Clipboard Toggle word wrap

    出力には、ターゲットノードプール内の 4 つの Kafka ノードが表示されます

    NAME                 READY  STATUS   RESTARTS
my-cluster-pool-a-0  1/1    Running  0
my-cluster-pool-a-1  1/1    Running  0
my-cluster-pool-a-4  1/1    Running  0
my-cluster-pool-a-5  1/1    Running  0
    Copy to Clipboard Toggle word wrap

    ノード ID は、作成時にノードの名前に追加されます。ノード ID が 5 であるノード my-cluster-pool-a-5 を追加します。

  3. パーティションを古いノードから新しいノードに再割り当てします。

    ソースノードプールをスケールダウンする前に、Cruise Control の remove-broker モードを使用して、削除されるブローカーからパーティションレプリカを移動できます。

  4. 再割り当てプロセスが完了したら、ソースノードプール内の Kafka ノードの数を減らします。

    たとえば、ノードプール pool-b には 4 つのレプリカがあります。レプリカの数を減らしてノードを削除します。 

    oc scale kafkanodepool pool-b --replicas=3
    Copy to Clipboard Toggle word wrap

    プール内で最も数値の大きい ID を持つノードが削除されます。

    出力には、ソースノードプール内の 3 つの Kafka ノードが表示されます

    NAME                       READY  STATUS   RESTARTS
my-cluster-pool-b-kafka-2  1/1    Running  0
my-cluster-pool-b-kafka-3  1/1    Running  0
my-cluster-pool-b-kafka-6  1/1    Running  0
    Copy to Clipboard Toggle word wrap

8.3.5. (プレビュー) ノードプールを使用したストレージの管理
リンクのコピー

AMQ Streams でのストレージ管理は通常は簡単で、設定時にほとんど変更を必要としませんが、お使いのストレージ設定の変更が必要になる場合もあります。ノードプールを使用すると、新しいストレージ要件を指定する個別のノードプールを設定できるため、このプロセスが簡素化されます。

この手順では、3 つのノードを含む pool-a というノードプールのストレージを作成および管理します。使用する永続ストレージのタイプを定義するストレージクラス (volume.class) を変更する方法を示します。同じ手順を使用して、ストレージサイズ (volume.size) を変更できます。

注記

ブロックストレージを使用することを強く推奨します。AMQ Streams は、ブロックストレージでの使用についてのみテストされています。

前提条件

手順

  1. 独自のストレージ設定でノードプールを作成します。

    たとえば、ノードプール pool-a は永続ボリュームが含まれる JBOD ストレージを使用します。 

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 500Gi
        class: gp2-ebs
  # ...
    Copy to Clipboard Toggle word wrap

    pool-a のノードは、Amazon EBS (Elastic Block Store) GP2 ボリュームを使用するように設定されています。

  2. pool-a のノードプール設定を適用します。

  3. デプロイメントのステータスを確認し、pool-a 内の Pod が作成され、ステータスが READY になるまで待ちます。 

    oc get pods -n <my_cluster_operator_namespace>
    Copy to Clipboard Toggle word wrap

    出力には、ノードプール内の 3 つの Kafka ノードが表示されます

    NAME                 READY  STATUS   RESTARTS
my-cluster-pool-a-0  1/1    Running  0
my-cluster-pool-a-1  1/1    Running  0
my-cluster-pool-a-2  1/1    Running  0
    Copy to Clipboard Toggle word wrap

  4. 新しいストレージクラスに移行するには、必要なストレージ設定で新しいノードプールを作成します。 

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-b
  labels:
    strimzi.io/cluster: my-cluster
spec:
  roles:
    - broker
  replicas: 3
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 1Ti
        class: gp3-ebs
  # ...
    Copy to Clipboard Toggle word wrap

    pool-b のノードは、Amazon EBS (Elastic Block Store) GP3 ボリュームを使用するように設定されています。

  5. pool-b のノードプール設定を適用します。
  6. デプロイメントのステータスを確認し、pool-b 内の Pod が作成され、ステータスが READY になるまで待ちます。

  7. パーティションを pool-a から pool-b に再割り当てします。

    新しいストレージ設定に移行する場合、Cruise Control の remove-brokers モードを使用して、削除予定のブローカーからパーティションレプリカを移動できます。

  8. 再割り当てプロセスが完了したら、古いノードプールを削除します。 

    oc delete kafkanodepool pool-a
    Copy to Clipboard Toggle word wrap

8.3.6. (プレビュー) ノードプールを使用したストレージアフィニティーの管理
リンクのコピー

ローカル永続ボリュームなどのストレージリソースが特定のワーカーノードまたはアベイラビリティーゾーンに制限されている状況では、ストレージアフィニティーを設定すると、適切なノードを使用するように Pod をスケジュールする場合に役立ちます。

ノードプールを使用すると、アフィニティーを個別に設定できます。この手順では、zone-1 と zone-2 の 2 つのアベイラビリティゾーンのストレージアフィニティーを作成および管理します。

ノードプールを個別のアベイラビリティーゾーンに設定できますが、同じストレージクラスを使用します。各ゾーンで利用可能なストレージリソースを表す all-zones 永続ストレージクラスを定義します。

また、.spec.template.pod プロパティーを使用してノードアフィニティーを設定し、zone-1 および zone-2 のワーカーノードで Kafka Pod をスケジュールします。

ストレージクラスとアフィニティーは、各アベイラビリティーゾーンのノードを表すノードプールで指定されます。

  • pool-zone-1
  • pool-zone-2

前提条件

手順

  1. 各アベイラビリティーゾーンで使用するストレージクラスを定義します。 

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: all-zones
provisioner: kubernetes.io/my-storage
parameters:
  type: ssd
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

  2. all-zones のストレージクラスと各ゾーンのアフィニティーを指定して、2 つのアベイラビリティーゾーンを表すノードプールを作成します。

    zone-1 のノードプール設定

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-zone-1
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 500Gi
        class: all-zones
  template:
    pod:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                  - zone-1
  # ...
    Copy to Clipboard Toggle word wrap

    zone-2 のノードプール設定

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-zone-2
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 4
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 500Gi
        class: all-zones
  template:
    pod:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                  - zone-2
  # ...
    Copy to Clipboard Toggle word wrap

  3. ノードプール設定を適用します。

  4. デプロイメントのステータスを確認し、ノードプール内の Pod が作成され、ステータスが READY になるまで待ちます。 

    oc get pods -n <my_cluster_operator_namespace>
    Copy to Clipboard Toggle word wrap

    出力には、pool-zone-1 に 3 つの Kafka ノードと、pool-zone-2 に 4 つの Kafka ノードが表示されます。

    NAME                       READY  STATUS   RESTARTS
my-cluster-pool-zone-1-kafka-0  1/1    Running  0
my-cluster-pool-zone-1-kafka-1  1/1    Running  0
my-cluster-pool-zone-1-kafka-2  1/1    Running  0
my-cluster-pool-zone-2-kafka-3  1/1    Running  0
my-cluster-pool-zone-2-kafka-4  1/1    Running  0
my-cluster-pool-zone-2-kafka-5  1/1    Running  0
my-cluster-pool-zone-2-kafka-6  1/1    Running  0
    Copy to Clipboard Toggle word wrap

8.3.7. (プレビュー) Kafka ノードプールを使用するための既存の Kafka クラスターの移行
リンクのコピー

この手順では、既存の Kafka クラスターを移行して Kafka ノードプールを使用する方法について説明します。Kafka クラスターを更新した後、ノードプールを使用して各プール内のノードの設定を管理できます。

注記

ノードプールを有効にする KafkaNodePools フィーチャーゲートはアルファ段階にありますが、KafkaNodePool リソース内のレプリカとストレージ設定も Kafka リソース内に存在する必要があります。ノードプールが使用されている場合、設定は無視されます。

前提条件

手順

  1. 新しい KafkaNodePool リソースを作成します。

    1. リソースに kafka という名前を付けます。
    2. strimzi.io/cluster ラベルが既存の Kafka リソースを指すようにします。
    3. 現在の Kafka クラスターと一致するようにレプリカ数とストレージ設定を設定します。
    4. ロールを Broker に設定します。

    Kafka クラスターの移行で使用されるノードプールの設定例

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: kafka
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    Copy to Clipboard Toggle word wrap

    警告

    クラスターのデータとそのノードおよびリソースの名前を保持しながらクラスターを移行するには、ノードプール名を kafka に指定し、strimzi.io/cluster ラベルでは Kafka リソースの名前を使用する必要があります。それ以外の場合、ノードとリソースは、ノードによって使用される永続ボリュームストレージを含めて、新しい名前で作成されます。そのため、以前のデータが利用できなくなる可能性があります。

  2. KafkaNodePool リソースを適用します。 

    oc apply -f <node_pool_configuration_file>
    Copy to Clipboard Toggle word wrap

    このリソースを適用すると、Kafka がノードプールの使用に切り替わります。

    変更やローリングアップデートはなく、リソースは以前と同じです。

  3. Cluster Operator 設定の STRIMZI_FEATURE_GATES 環境変数を更新して、+KafkaNodePools を含めます。 

    env:
  - name: STRIMZI_FEATURE_GATES
    value: +KafkaNodePools
    Copy to Clipboard Toggle word wrap

    再起動後、Cluster Operator は、Kafka ノードプールが追加されたものの、まだ Cluster Operator と統合されていないことを示す警告をログに記録します。これはプロセスの予期された部分です。

  4. strimzi.io/node-pools:enabled アノテーションを使用して、Kafka リソースで KafkaNodePools フィーチャーゲートを有効にします。

    ZooKeeper を使用したクラスター内のノードプールの設定例

    apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  annotations:
    strimzi.io/node-pools: enabled
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    Copy to Clipboard Toggle word wrap

  5. Kafka リソースを適用します。 

    oc apply -f <kafka_configuration_file>
    Copy to Clipboard Toggle word wrap

    変更やローリング更新はありません。リソースは、以前と同じままです。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat