7.3. Kafka クラスターの設定


Kafka クラスターは、1 つまたは複数のブローカーで設定されます。プロデューサーおよびコンシューマーがブローカー内のトピックにアクセスできるようにするには、Kafka 設定でクラスターへのデータの保存方法、およびデータへのアクセス方法を定義する必要があります。ラック全体で複数のブローカーノードを使用して Kafka クラスターを実行するように設定できます。

7.3.1. Storage

Streams for Apache Kafka は、Kafka および ZooKeeper データを管理するための以下のストレージ設定オプションをサポートします。

一時データストレージ (開発用のみで推奨されます)
一時ストレージは、インスタンスの有効期間についてのデータを格納します。インスタンスを再起動すると、データは失われます。
永続ストレージ
永続ストレージは、インスタンスのライフサイクルとは関係なく長期のデータストレージに関連付けられます。
JBOD (Just a Bunch of Disks、Kafka のみに適しています)
JBOD では、複数のディスクを使用して各ブローカーにコミットログを保存できます。

これらのオプションに加えて、階層ストレージを使用するように Streams for Apache Kafka を設定できます。階層化ストレージは、Kafka の 早期アクセス 機能であり、特性がっ子となるストレージタイプを並行して使用することで、データ管理の柔軟性を高めます。基本的なストレージオプションの 1 つは階層化ストレージと一緒に設定する必要がありますが、ブロックストレージとオブジェクトストレージなどの組み合わせが可能になり、パフォーマンスとスケーラビリティーが向上します。

ストレージタイプは、storage または tieredStorage 設定プロパティーを使用してカスタムリソースで指定されます。

  • storage 設定タイプ:

    • type: ephemeral
    • 永続ボリューム要求 (PVC) を使用する 永続ストレージ用の type: persistent-claim
    • JBOD ストレージ用の type: jbod
  • tieredStorage 設定タイプ:

    • カスタムの階層化ストレージの type: custom

ディスクに保存される Kafka および ZooKeeper データの場合、ストレージのファイルシステム形式は XFS または EXT4 である必要があります。既存の Kafka クラスターが使用するディスク容量は、増やすことができます (インフラストラクチャーでサポートされる場合)。

7.3.2. リスナー

リスナーは、クライアントが Kafka クラスターに接続する方法を設定します。

Kafka クラスター内の各リスナーに一意の名前とポートを指定することで、複数のリスナーを設定できます。

以下のタイプのリスナーがサポートされます。

  • OpenShift 内でのアクセスに使用する 内部リスナー
  • OpenShift 外からアクセスするときに使用する 外部リスナー

リスナーの TLS 暗号化を有効にし、認証 を設定できます。

内部リスナーは、internal 型を指定して Kafka を公開します。

  • 同じ OpenShift クラスター内で接続する internal
  • ブローカーごとの ClusterIP サービスを使用して Kafka を公開する cluster-ip

外部リスナーは、外部用 type を指定して Kafka を公開します。

  • OpenShift ルートおよびデフォルトの HAProxy ルーターを使用する route
  • ロードバランサーサービスを使用する loadbalancer
  • OpenShift ノードのポートを使用する nodeport
  • OpenShift Ingress および Ingress NGINX Controller for Kubernetes を使用する ingress
注記

cluster-ip タイプを使用すると、独自のアクセスメカニズムを追加できます。たとえば、カスタム Ingress コントローラーまたは OpenShift Gateway API でリスナーを使用できます。

トークンベースの認証に OAuth 2.0 を使用している場合は、リスナーが認可サーバーを使用するように設定できます。

7.3.3. ラックアウェアネス

ラックは、データセンター、データセンター内のラック、または可用性ゾーンを表します。Kafka ブローカー Pod とトピックレプリカをラック全体に分散するようにラック認識を設定します。rack プロパティーを使用してラック認識を有効にし、topologyKey を指定します。topologyKey は、ラックを識別する OpenShift ワーカーノードに割り当てられたラベルの名前です。Streams for Apache Kafka は、各 Kafka ブローカーにラック ID を割り当てます。Kafka ブローカーは ID を使用して、パーティションのレプリカをラック全体に分散させます。ラック認識で使用する RackAwareReplicaSelector セレクタープラグインを指定することもできます。プラグインはブローカーとコンシューマーのラック ID を照合するため、メッセージは最も近いレプリカから消費されます。プラグインを使用するには、コンシューマーもラック認識を有効にする必要があります。Kafka Connect、MirrorMaker 2、および Kafka Bridge でラック認識を有効にすることができます。

7.3.4. Kafka 設定の YAML 例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external1
        port: 9094
        type: route
        tls: true
        authentication:
          type: tls
    # ...
    storage:
      type: persistent-claim
      size: 10000Gi
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    config:
      replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
    # ...
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る