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

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"

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"

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

手順

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

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

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

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

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

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

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

    oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids="[60-50,9,8,7]"

    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-

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

    oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids-

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

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

注記

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

前提条件

手順

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

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

    oc scale kafkanodepool pool-a --replicas=4

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

    oc get pods -n <my_cluster_operator_namespace>

    出力には、ノードプール内の 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

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

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

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

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: add-brokers
  brokers: [3]

    パーティションをノード 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

ノード 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]

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

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

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

    oc scale kafkanodepool pool-a --replicas=3

    出力には、ノードプール内の 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

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

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

    oc get pods -n <my_cluster_operator_namespace>

    出力には、ソースノードプールとターゲットノードプール内の 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

    ノード 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]

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

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

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

    oc scale kafkanodepool pool-b --replicas=3

    プール内で最も数値の大きい 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

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

ノードプールには 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

各ノードは、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
  # ...

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

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

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

    oc get pods -n <my_cluster_operator_namespace>

    出力には、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

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

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

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

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [0, 1, 2]

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

    注記

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

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

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

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

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

    oc get pods -n <my_cluster_operator_namespace>

    出力には、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

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

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

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

    apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  # ...
spec:
  mode: remove-brokers
  brokers: [3, 4, 5]

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

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

    oc delete kafkanodepool pool-b -n <my_cluster_operator_namespace>

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

    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>

    出力には、ノードプール内の 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

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

    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]

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

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

    oc delete kafkanodepool pool-a

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

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

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

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

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

    oc get pods -n <my_cluster_operator_namespace>

    出力には、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

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

    警告

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

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

    oc apply -f <node_pool_configuration_file>

    このリソースを適用すると、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:
    # ...

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

    oc apply -f <kafka_configuration_file>

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

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

© 2024 Red Hat, Inc.