10.5. Kafka ストレージの設定

Kafka は、メッセージの保存にファイルシステムを使用します。Streams for Apache Kafka は、Kafka で一般的に使用される XFS および ext4 ファイルシステムと互換性があります。ファイルシステムを選択して設定するときは、デプロイメントの基盤となるアーキテクチャーと要件を考慮してください。

詳細は、Kafka ドキュメントの Filesystem Selection を参照してください。

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

一時ストレージを使用するには、ストレージタイプとして ephemeral を指定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: my-node-pool
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  storage:
    type: ephemeral
  # ...

一時ストレージは、Pod がノードに割り当てられたときに作成される emptyDir ボリュームを使用します。sizeLimit プロパティーを使用して、emptyDir ボリュームのサイズを制限できます。

Kafka ブローカーがログディレクトリー用に使用する一時ボリュームは、/var/lib/kafka/data/kafka-log<pod_id> にマウントされます。

一時ストレージの設定オプションの詳細は、EphemeralStorage スキーマリファレンス を参照してください。

永続ストレージを使用するには、ストレージタイプとして次のいずれかを指定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: my-node-pool
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  storage:
    type: persistent-claim
    size: 500Gi
    deleteClaim: true
  # ...

Streams for Apache Kafka は、永続ボリューム要求 (PVC) を使用して永続ボリューム (PV) 上のストレージを要求します。PVC は、要求されたストレージ基準を満たす PV にバインドします。その際に、基盤となるストレージインフラストラクチャーを認識する必要はありません。

Kafka Pod 用に作成された PVC は、data-<kafka_cluster_name>-<pool_name>-<pod_id> の命名規則に従い、Kafka ログの永続ボリュームは /var/lib/kafka/data/kafka-log<pod_id> にマウントされます。

ストレージ設定で、カスタムストレージクラス (StorageClass) とボリュームセレクターを指定することもできます。

# ...
  storage:
    type: persistent-claim
    size: 500Gi
    class: my-storage-class
    selector:
      hdd-type: ssd
    deleteClaim: true
# ...

ストレージクラスはストレージプロファイルを定義し、そのプロファイルに基づき永続ボリューム (PV) を動的にプロビジョニングします。これは、ストレージクラスが、異なるアベイラビリティーゾーンやデータセンターに制限されている場合などに便利です。ストレージクラスが指定されていない場合は、OpenShift クラスターのデフォルトのストレージクラスが使用されます。セレクターは、ソリッドステートドライブ (SSD) ボリュームなどの特定の機能を提供する永続ボリュームを指定します。

永続ストレージ設定オプションの詳細は、PersistentClaimStorage スキーマリファレンス を参照してください。

永続ボリュームのサイズは、ストレージインフラストラクチャーによってサポートされている限り、size ストレージプロパティーを変更することでデータ損失のリスクを伴うことなく変更できます。Streams for Apache Kafka は、ストレージのサイズを変更する設定の更新に従って、ストレージインフラストラクチャーに変更を指示します。

ストレージ拡張は、persistent-claim ボリュームを使用する Streams for Apache Kafka クラスターでサポートされています。OpenShift では、永続ボリュームのサイズを縮小することはサポートされていません。OpenShift での永続ボリュームのサイズ変更に関する詳細は、Resizing Persistent Volumes using Kubernetes を参照してください。

size プロパティーの値を増やすと、OpenShift は Cluster Operator からの要求に応じて、選択された永続ボリュームの容量を増やします。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。

この例では、ボリュームを 2000Gi に増やしています。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: my-node-pool
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 2000Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 2000Gi
        deleteClaim: false
      - id: 2
        type: persistent-claim
        size: 2000Gi
        deleteClaim: false
  # ...

返される PV の情報で変更を検証します。

oc get pv

NAME               CAPACITY   CLAIM
pvc-0ca459ce-...   2000Gi     my-project/data-my-cluster-my-node-pool-2
pvc-6e1810be-...   2000Gi     my-project/data-my-cluster-my-node-pool-0
pvc-82dc78c9-...   2000Gi     my-project/data-my-cluster-my-node-pool-1

出力には、ブローカー Pod に関連付けられた各 PVC の名前が表示されます。

JBOD ストレージを使用するには、ストレージタイプとして jbod を指定し、JBOD ボリュームの設定を追加します。JBOD ボリュームには永続ボリュームと一時ボリュームがあり、各タイプには設定オプションと制約が適用されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: my-node-pool
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  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
  # ...

JBOD ボリューム用の PVC は、data-<volume_id>-<kafka_cluster_name>-<pool_name>-<pod_id> の命名規則を使用して作成され、ログディレクトリーに使用される JBOD ボリュームは /var/lib/kafka/data-<volume_id>/kafka-log<pod_id> にマウントされます。

JBOD ボリュームの作成後にボリューム ID を変更することはできませんが、ボリュームを追加または削除することはできます。過去に使用されて削除された id の volumes 配列に新しいボリュームを追加する場合は、以前使用した PersistentVolumeClaims が削除されていることを確認してください。

ボリュームを追加または削除するときにパーティションを再度割り当てるには、Cruise Control を使用します。ブローカー内ディスクバランスの詳細は、「リバランスのオプションの調整」 を参照してください。

KRaft モードでは、各ノード (ブローカーとコントローラーを含む) は、Kafka クラスターのメタデータログのコピーをデータボリュームの 1 つに保存します。デフォルトでは、ログは最小 ID を持つボリュームに保存されますが、kraftMetadata プロパティーを使用して別のボリュームを指定することもできます。

コントローラーのみのノードの場合、ストレージはメタデータログ専用になります。ログは常に 1 つのボリュームに保存されるため、複数のボリュームを持つ JBOD ストレージを使用しても、パフォーマンスが向上したり、使用可能なディスク領域が増えたりすることはありません。

対照的に、ブローカーノードや、ブローカーとコントローラーのロールを兼ね備えたノードは、メタデータログとパーティションレプリカデータの両方に同じボリュームを共有できるため、ディスクの使用率が最適化されます。また、JBOD ストレージを使用することもできます。この場合、1 つのボリュームはメタデータログとパーティションレプリカデータ用に共有され、追加のボリュームはパーティションレプリカデータ専用に使用されます。

メタデータログを保存するボリュームを変更すると、クラスターノードのローリングアップデートがトリガーされ、古いログが削除され、指定された場所に新しいログが作成されます。kraftMetadata が指定されていない場合、より小さい ID を持つ新しいボリュームを追加すると、メタデータログの更新と再配置も要求されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: pool-a
  # ...
spec:
  storage:
    type: jbod
    volumes:
    - id: 0
      type: persistent-claim
      size: 100Gi
      deleteClaim: false
    - id: 1
      type: persistent-claim
      size: 100Gi
      kraftMetadata: shared
      deleteClaim: false
  # ...

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

この手順では、3 つのノードを含む pool-a というノードプールのストレージを作成および管理します。これらの手順では、新しいノードプールを追加するためのスケーリング操作が必要です。現時点でスケーリングが可能なのは、専用ブローカーとして実行されるノードを含む、ブローカー専用ノードプールのみです。

使用する永続ストレージのタイプを定義するストレージクラス (volumes.class) を変更する方法を示します。同じ手順を使用して、ストレージサイズ (volumes.size) を変更できます。このアプローチは、ディスクサイズを縮小したい場合に特に便利です。ディスクサイズを増やす場合は、永続ボリュームの動的なサイズ変更 を選択することもできます。

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

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

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

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

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

一時ストレージを使用するには、ストレージタイプとして ephemeral を指定します。

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

Kafka ブローカーがログディレクトリー用に使用する一時ボリュームは、/var/lib/kafka/data/kafka-log<pod_id> にマウントされます。

Kafka リソースの Kafka にも、ノードプールで使用できる同じ永続ストレージ設定オプションを指定できます。詳細は、ノードプールを使用した Kafka ストレージの設定 に関するセクションを参照してください。size プロパティーを調整して 永続ボリュームのサイズを変更する こともできます。

ZooKeeper では JBOD ストレージがサポートされていないため、ストレージタイプは必ず persistent-claim にする必要があります。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: persistent-claim
      size: 500Gi
      deleteClaim: true
  # ...
  zookeeper:
    storage:
      type: persistent-claim
      size: 1000Gi

Kafka リソースにストレージが設定されている場合に Kafka Pod 用に作成された PVC は data-<cluster_name>-kafka-<pod_id> の命名規則を使用し、Kafka ログの永続ボリュームは /var/lib/kafka/data/kafka-log<pod_id> にマウントされます。

ZooKeeper 用に作成された PVC は、data-<cluster_name>-zookeeper-<pod_id> の命名規則に従います。

ZooKeeper は JBOD ストレージをサポートしていませんが、ZooKeeper ベースのクラスター内の Kafka ノードは JBOD ストレージを使用するように設定できます。ノードプールで使用できるものと同じ JBOD 設定オプションを、Kafka リソースの Kafka にも指定できます。詳細は、ノードプールを使用した Kafka ストレージの設定 に関するセクションを参照してください。volumes 配列を調整して、ボリュームを追加または削除する こともできます。

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

以前に Kafka リソースで Kafka および ZooKeeper に使用されていた非推奨の overrides プロパティーは、ボリュームが使用するストレージクラスの変更にノードプールを使用する方法に置き換えられます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  labels:
    app: my-cluster
  name: my-cluster
  namespace: myproject
spec:
  # ...
  kafka:
    replicas: 3
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
        class: my-storage-class
        overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
      # ...
  # ...
  zookeeper:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...

Kafka にストレージクラスのオーバーライドを使用している場合は、代わりにノードプールの使用に移行することが推奨されます。既存の設定を移行するには、次の手順に従います。