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

9.3. ノードプールの設定

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

ノードプールは、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 設定のテンプレート値は無視されます。

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

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

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: kraft-dual-role
1 

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

spec:
  replicas: 3
3 

  roles:
4 

    - controller
    - broker
  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
ノードプール内のノードのロール。この例では、ノードにはコントローラーとブローカーとしての二重のロールがあります。
5
ノードのストレージ仕様。
6
現在 cpu および memory である、サポートされるリソースの予約を要求し、消費可能な最大リソースを指定を制限します。
注記

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

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

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
1 

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

1
ノードプール内のノードのロール。ZooKeeper で Kafka を使用する場合にのみ broker でありえます。

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

9.3.2. ノードプールからノードを移動する場合のラックに与える影響
リンクのコピー

Kafka クラスターでラック認識が有効になっている場合、レプリカを異なるラック、データセンター、またはアベイラビリティーゾーンに分散できます。ノードプールからノードを移動する場合、特にラック認識に関して、クラスタートポロジーへの影響を考慮してください。特定の Pod をノードプールから削除すると (特に順序どおりに削除しない場合)、クラスタートポロジーが壊れたり、ラック間の分散に不均衡が生じたりする可能性があります。不均衡が発生すると、ノード自体の分散とクラスター内のパーティションレプリカの両方に影響を与える可能性があります。ラック間でのノードとパーティションで分散が不均一になると、Kafka クラスターのパフォーマンスと回復力に影響を与える可能性があります。

ラック全体で必要なバランスと復元力を維持するために、ノードの削除を戦略的に計画します。特定の ID を持つノードを慎重に移動するには、strimzi.io/remove-node-ids アノテーションを使用します。パーティションのレプリカをラック全体に分散して、クライアントが最も近隣にあるレプリカから消費できるように、設定が壊れていなことを確認します。

ヒント

RackAwareGoal で Cruise Control と KafkaRebalance リソースを使用して、レプリカが異なるラックに分散していることを確認します。

9.3.3. ノードプールへのノードの追加
リンクのコピー

この手順では、ノードプールをスケールアップして新しいノードを追加する方法について説明します。現在スケールアップが可能なのは、専用ブローカーとして実行されるノードを含む、ブローカー専用ノードプールのみです。

この手順では、ノードプール 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 が作成されて準備完了 (1/1) となるまで待ちます。 

    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 モードを使用して、パーティションレプリカを既存のブローカーから新しく追加したブローカーに移動します。

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: add-brokers
  brokers: [3]
    Copy to Clipboard Toggle word wrap

    パーティションをノード my-cluster-pool-a-3 に再割り当てしています。クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

9.3.4. ノードプールからのノードの削除
リンクのコピー

この手順では、ノードプールをスケールダウンしてノードを削除する方法について説明します。現在スケールダウンが可能なのは、専用ブローカーとして実行されるノードを含む、ブローカー専用ノードプールのみです。

この手順では、ノードプール 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 モードを使用して、削除するブローカーからパーティションレプリカを移動します。

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [3]
    Copy to Clipboard Toggle word wrap

    ノード my-cluster-pool-a-3 からパーティションを再割り当てしています。クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

  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

9.3.5. ノードプール間でのノードの移動
リンクのコピー

この手順では、ダウンタイムなしでソース 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 が作成されて準備完了 (1/1) となるまで待ちます。 

    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-7  1/1    Running  0
my-cluster-pool-b-2  1/1    Running  0
my-cluster-pool-b-3  1/1    Running  0
my-cluster-pool-b-5  1/1    Running  0
my-cluster-pool-b-6  1/1    Running  0
    Copy to Clipboard Toggle word wrap

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

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

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

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [6]
    Copy to Clipboard Toggle word wrap

    ノード my-cluster-pool-b-6 からパーティションを再割り当てしています。クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

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

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

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

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

    出力には、ソースノードプール内の 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-5  1/1    Running  0
    Copy to Clipboard Toggle word wrap

9.3.6. ノードプールのロールの変更
リンクのコピー

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

状況により、ノードプールに割り当てられたロールを変更することが必要な場合があります。たとえば、broker と controller の二重のロールを実行するノードを含むノードプールがあり、それらのロールを 2 つのノードプール間で分割すると決定したとします。この場合、ブローカーとしてのみ機能するノードを含む新しいノードプールを作成し、二重のロールを持つノードから新しいブローカーにパーティションを再割り当てします。その後、古いノードプールのロールを controller 専用ロールに切り替えることができます。

controller 専用ロールを持つノードプールと broker 専用ロールを持つノードプールから、broker と controller の二重のロールを実行するノードを含むノードプールに移動することで、逆の操作を実行することもできます。この場合、broker ロールを既存のコントローラー専用ノードプールに追加し、ブローカー専用ノードから二重のロールを持つノードにパーティションを再割り当てしてから、ブローカー専用ノードプールを削除します。

ノードプール設定で broker ロールを削除する場合は、Kafka がパーティションを自動的に再割り当てしない点に注意してください。broker ロールを削除する前に、controller 専用ロールに変更するノードにパーティションが割り当てられていないことを確認してください。パーティションが割り当てられている場合、変更は妨げられます。broker ロールを削除する前に、ノードにレプリカが残っていないようにしてください。ロールを変更する前にパーティションを再割り当てする最良の方法は、remove-brokers モードで Cruise Control の最適化プロポーザルを適用することです。詳細は、「最適化プロポーザルの生成」 を参照してください。

9.3.7. 個別の broker ロールと controller ロールへの移行
リンクのコピー

この手順では、別のロールを持つノードプールを使用するように移行する方法を説明します。Kafka クラスターが controller ロールと broker ロールを組み合わせたノードプールを使用している場合は、別のロールを持つ 2 つのノードプールを使用するように移行できます。そのためには、クラスターをリバランスして、パーティションレプリカを broker 専用ロールを持つノードプールに移動してから、古いノードプールを controller 専用ロールに切り替えます。

この手順では、controller ロールと broker ロールを持つノードプール pool-a から始めます。

二重のロールを持つノードプール

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - controller
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 20Gi
        deleteClaim: false
  # ...
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

各ノードは、broker と controller を組み合わせたロールを実行します。ブローカーとしてのみ機能する 3 つのノードを含む、pool-b という 2 番目のノードプールを作成します。

注記

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

前提条件

手順

  1. broker ロールを持つノードプールを作成します。

    ノードプール設定の例

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-b
  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

    新しいノードプールにも 3 つのノードがあります。ブローカー専用ノードプールがすでにある場合は、この手順をスキップできます。

  2. 新しい KafkaNodePool リソースを適用してブローカーを作成します。

  3. デプロイメントのステータスを確認し、ノードプール内の Pod が作成されて準備完了 (1/1) となるまで待ちます。 

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

    出力には、2 つのノードプールで実行されている Pod が表示されます

    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-b-3  1/1    Running  0
my-cluster-pool-b-4  1/1    Running  0
my-cluster-pool-b-5  1/1    Running  0
    Copy to Clipboard Toggle word wrap

    ノード ID は、作成時にノードの名前に追加されます。

  4. Cruise Control の remove-brokers モードを使用して、二重のロールを持つノードから新しく追加されたブローカーにパーティションレプリカを再割り当てします。

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [0, 1, 2]
    Copy to Clipboard Toggle word wrap

    クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

    注記

    controller 専用のロールに変更するノードにパーティションが割り当てられている場合、変更は阻止されます。Kafka リソースの status.conditions は、変更を妨げるイベントの詳細を提供します。

  5. 元々ロールを組み合わせて有していたノードプールから broker ロールを削除します。

    二重のロールを持つノードの controller への切り替え

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

  6. 設定変更を適用して、ノードプールを controller 専用ロールに切り替えます。

9.3.8. 二重のロールを持つノードへの移行
リンクのコピー

この手順では、broker 専用ロールと controller 専用ロールを持つ個別のノードプールから、二重のロールを持つノードプールの使用に移行する方法について説明します。Kafka クラスターが専用のコントローラーノードとブローカーノードを持つノードプールを使用している場合は、両方のロールを持つ単一のノードプールを使用するように移行できます。これを行うには、broker ロールをコントローラー専用ノードプールに追加し、クラスターをリバランスしてパーティションレプリカを二重のロールを持つノードプールに移動してから、古いブローカー専用ノードプールを削除します。

この手順では、controller ロールのみを持つ pool-a と、broker ロールのみを持つ pool-b の 2 つのノードプールから始めます。

単一ロールのノードプール

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - controller
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
  # ...
---
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-b
  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 クラスターには 6 つのノードがあります。

ノードプール内の 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-b-3  1/1    Running  0
my-cluster-pool-b-4  1/1    Running  0
my-cluster-pool-b-5  1/1    Running  0
Copy to Clipboard Toggle word wrap

pool-a ノードは controller のロールを実行します。pool-b ノードは broker のロールを実行します。

注記

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

前提条件

手順

  1. ノードプール pool-a を編集し、それに broker ロールを追加します。

    ノードプール設定の例

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

  2. ステータスを確認し、ノードプール内の Pod が再起動して準備完了 (1/1) となるまで待ちます。 

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

    出力には、2 つのノードプールで実行されている Pod が表示されます

    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-b-3  1/1    Running  0
my-cluster-pool-b-4  1/1    Running  0
my-cluster-pool-b-5  1/1    Running  0
    Copy to Clipboard Toggle word wrap

    ノード ID は、作成時にノードの名前に追加されます。

  3. Cruise Control の remove-brokers モードを使用して、ブローカー専用ノードから二重のロールを持つノードにパーティションレプリカを再割り当てします。

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [3, 4, 5]
    Copy to Clipboard Toggle word wrap

    クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

  4. 古いブローカー専用ノードが含まれる pool-b ノードプールを削除します。 

    oc delete kafkanodepool pool-b -n <my_cluster_operator_namespace>
    Copy to Clipboard Toggle word wrap

9.3.9. ノードプールを使用したストレージの管理
リンクのコピー

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

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

注記

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

前提条件

手順

  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 が作成されて準備完了 (1/1) となるまで待ちます。 

    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 が作成されて準備完了となるまで待ちます。

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

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

    Cruise Control を使用したパーティションレプリカの再割り当て

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [0, 1, 2]
    Copy to Clipboard Toggle word wrap

    pool-a からパーティションを再割り当てしています。クラスター内のトピックとパーティションの数によっては、再割り当てに時間がかかる場合があります。

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

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

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

ローカル永続ボリュームなどのストレージリソースが特定のワーカーノードまたはアベイラビリティーゾーンに制限されている状況では、ストレージアフィニティーを設定すると、適切なノードを使用するように 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 が作成されて準備完了 (1/1) となるまで待ちます。 

    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

9.3.11. Kafka ノードプールを使用するための既存の Kafka クラスターの移行
リンクのコピー

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

注記

現在、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. strimzi.io/node-pools: enabled アノテーションを使用して、Kafka リソース内のノードプールのサポートを有効にします。

    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

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

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

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

  5. Kafka カスタムリソースから複製されたプロパティーを削除します。KafkaNodePool リソースが使用されている場合、.spec.kafka.replicas プロパティーや .spec.kafka.storage プロパティーなど、KafkaNodePool リソースにコピーしたプロパティーを削除できます。

移行の取り消し

Kafka カスタムリソースのみを使用して Kafka ノードを管理するように戻すには以下を実行します。

  1. 複数のノードプールがある場合は、ノード ID が 0 から N に、kafka という名前の単一の KafkaNodePool に連結します(N はレプリカの数です)。
  2. Kafka リソースの .spec.kafka 設定が、ストレージ、リソース、レプリカを含む KafkaNodePool 設定と一致していることを確認します。
  3. strimzi.io/node-pools: disabled アノテーションを使用して、Kafka リソース内のノードプールのサポートを無効にします。
  4. kafka という名前の Kafka ノードプールを削除します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat