OpenShift 上の Streams for Apache Kafka 2.7 のリリースノート

Streams for Apache Kafka 2.7 は OpenShift Container Platform 4.12 から 4.16 でサポートされています。

詳細は、10章サポートされる構成 を参照してください。

Streams for Apache Kafka は、Apache Kafka バージョン 3.7.0 をサポートおよび使用するようになりました。サポート対象は、Red Hat によってビルドされた Kafka ディストリビューションのみです。

ブローカーとクライアントアプリケーションを Kafka 3.7.0 にアップグレードする前に、Cluster Operator を Streams for Apache Kafka バージョン 2.7 にアップグレードする必要があります。アップグレードの手順については、Streams for Apache Kafka のアップグレード を参照してください。

詳細は、Kafka 3.7.0 リリースノートを参照してください。

Kafka 3.6.x は、Streams for Apache Kafka 2.7 にアップグレードする目的でのみサポートされます。

すべてのカスタムリソースの v1beta2 API バージョンが、Streams for Apache Kafka 1.7 で導入されました。Streams for Apache Kafka 1.8 で、KafkaTopic と KafkaUser を除くすべての Streams for Apache Kafka カスタムリソースから v1alpha1 および v1beta1 API バージョンが削除されました。

カスタムリソースを v1beta2 にアップグレードすると、Kubernetes 1.22 に必要な Kubernetes CRD v1 へ移行する準備ができます。

バージョン 1.7 より前の Streams for Apache Kafka バージョンからアップグレードする場合は、以下を行います。

StableConnectIdentities フィーチャーゲートが GA (一般提供) に移行し、永続的に有効になりました。

この機能は、Deployment リソースを使用する代わりに、StrimziPodSet リソースを使用して Kafka Connect および Kafka MirrorMaker 2 Pod を管理します。これは、コネクタータスクの再バランスの数を最小限に抑えるのに役立ちます。

StableConnectIdentities フィーチャーゲート を参照してください。

この KafkaNodePools フィーチャーゲートはベータレベルの成熟度に達し、デフォルトで有効になりました。このフィーチャーゲートにより、KafkaNodePool カスタムリソースを通じて Apache Kafka ノードのさまざまなプールを設定できるようになります。

ノードプールは、Kafka クラスター内の Kafka ノードの個別のグループを指します。KafkaNodePool カスタムリソースは、ノードプール内のノードのみの設定を表します。各プールには独自の固有の設定があり、これにはレプリカの数、ストレージ設定、割り当てられたロールのリストなどの必須設定が含まれます。ノードプール内のノードにロールを割り当てることができるため、クラスター管理または KRaft モードに ZooKeeper を使用する Kafka クラスターでこの機能を試せます。割り当てることができるのは、controller ロール、broker ロール、または両方のロールです。ZooKeeper ベースの Apache Kafka クラスターで使用する場合、ロールを broker に設定する必要があります。

KafkaNodePools フィーチャーゲートを無効にするには、Cluster Operator 設定の STRIMZI_FEATURE_GATES 環境変数に -KafkaNodePools を指定します。

env:
  - name: STRIMZI_FEATURE_GATES
    value: -KafkaNodePools

ノードプールの設定 を参照してください。

UnidirectionalTopicOperator フィーチャーゲートがベータレベルの成熟度に達し、デフォルトで有効になりました。このフィーチャーゲートにより、一方向トピック管理モードが導入されます。一方向モードでは、KafkaTopic リソースを使用して Kafka トピックを作成します。このトピックは Topic Operator によって管理されます。

UnidirectionalTopicOperator フィーチャーゲートを無効にするには、Cluster Operator 設定の STRIMZI_FEATURE_GATES 環境変数に -UnidirectionalTopicOperator を指定します。

env:
  - name: STRIMZI_FEATURE_GATES
    value: -UnidirectionalTopicOperator

Topic Operator の使用 を参照してください。

Streams for Apache Kafka の KRaft モードは、いくつかの制限がある テクノロジープレビュー ですが、このリリースでは、KRaft をサポートするいくつかの新機能が導入されています。

UseKRaft フィーチャーゲートがベータレベルの成熟度に達し、デフォルトで有効になりました。UseKRaft フィーチャーゲートを有効にすると、Kafka クラスターが ZooKeeper なしで KRaft (Kafka Raft メタデータ) モードでデプロイされます。また、Kafka を KRaft モードで使用するには、Kafka カスタムリソースに strimzi.io/kraft="enabled" アノテーションが必要です。

KRaft モードを使用するには、KafkaNodePool リソースを使用してノードのグループ設定を管理する必要もあります。

UseKRaft フィーチャーゲートを無効にするには、Cluster Operator 設定の STRIMZI_FEATURE_GATES 環境変数の値として -UseKRaft,-KafkaNodePools を指定します。

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UseKRaft,+KafkaNodePools

UseKRaft フィーチャーゲート および フィーチャーゲートリリース を参照してください。

Kafka クラスターでメタデータ管理に ZooKeeper を使用している場合は、KRaft モードでの Kafka の使用に移行できるようになりました。

移行中に次の操作を行います。

KRaft モードへの移行 を参照してください。

Streams for Apache Kafka は、さまざまな KRaft ロールへのノード移行をサポートしています。ノードプールの設定により、次の移行を実行できるようになりました。

ノードプール設定で broker ロールを削除するときにパーティションがまだ割り当てられている場合、変更が防止されます。

二重のロールを持つノードへの移行 および 個別の broker ロールと controller ロールへの移行 を参照してください。

KRaft から KRaft へのアップグレードがサポートされるようになりました。KRaft ベースの Kafka クラスターを、サポートされている新しい Kafka バージョンおよび KRaft メタデータバージョンにアップグレードします。

Kafka バージョンは、以前と同様に指定します。KRaft メタデータバージョンは、Kafka リソースの新しい metadataVersion プロパティーを使用して指定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    replicas: 3
    metadataVersion: 3.7-IV2
    version: 3.7.0
    # ...

metadataVersion が設定されていない場合、Kafka バージョンを更新した後、Streams for Apache Kafka はそれを現在のデフォルトに自動的に更新します。ローリング更新により、各 Pod が新バージョンの Kafka のブローカーバイナリーを使用するようになります。

KRaft ベースの Kafka クラスターとクライアントアプリケーションのアップグレード を参照してください。

階層化ストレージは Kafka の早期アクセス機能であり、Streams for Apache Kafka でも 開発者プレビュー として利用できます。

RHEL 7 はサポート対象外になりました。この決定は、既知の非互換性の問題 が原因で行われました。

Kafka 3.7.0 で導入された機能強化の概要については、Kafka 3.7.0 リリースノートを参照してください。

デフォルトでは、Streams for Apache Kafka は、Kafka クラスターでスケールダウン操作を開始する前に、ブローカー上にパーティションレプリカが存在しないことをチェックします。以前は、ブローカーがまだ使用中であることが判明した場合、スケールダウン操作がブロックされ、調整が失敗していました。現在は、スケールダウンによる変更は元に戻されますが、調整は通常どおり続行できます。

ただし、このブロックメカニズムを回避するほうがよい場合もあります。たとえば、ビジーなクラスターのチェックを無効にすると便利な場合があります。これを行うには、strimzi.io/skip-broker-scaledown-check を true に設定して、Kafka リソースにアノテーションを付けます。

スケールダウン操作でのチェックのスキップ を参照してください。

切断されたコンシューマーのメトリクスの収集を停止できるようになりました。切断されたコンシューマーでのメトリクスの収集を停止するには、Kafka Exporter 設定で showAllOffsets プロパティーを false に設定します。

KafkaExporterSpec スキーマリファレンス を参照してください。

CRD 内のラベルとアノテーションの定義 (template セクションなど) で、整数値が使用できなくなりました。常に文字列値を使用する必要があります。

例として、以下の設定を見てみましょう。

template:
  apiService:
    metadata:
      annotations:
        discovery.myapigateway.io/port: 8080

次のようにする必要があります。

template:
  apiService:
    metadata:
      annotations:
        discovery.myapigateway.io/port: "8080"

これは、無効な値エラーが発生する可能性を回避するためです。

spec.template.apiService.metadata.annotations.discovery.myapigateway.io/port:
Invalid value: "integer": spec.template.apiService.metadata.annotations.discovery.myapigateway.io/port in body must be of type string: "integer"

Streams for Apache Kafka Drain Cleaner が Kubernetes Pod のエビクション要求を処理する方法が変更されました。Drain Cleaner は、デフォルトで Kubernetes のエビクション要求を拒否 (ブロック) して Kubernetes による Pod のエビクトを防ぎ、代わりに Cluster Operator を使用して Pod を移動するようになりました。

以前の方法を引き続き使用することもできます。以前は、Drain Cleaner が Kubernetes のエビクション要求を許可し、同時に Cluster Operator に Pod の移動を指示していました。このレガシーモードを機能させるには、次の手順を実行する必要があります。

Strimzi Drain Cleaner を使用した Pod のエビクト を参照してください。

Kafka Connect で収集されるメトリクスが強化され、次のものが追加されました。

Kafka Connect のサンプル Grafana ダッシュボードファイルが更新され、より多くのコネクター情報とリバランスメトリクスを表示するパネルが追加されました。

MirrorMaker 2 のサンプル Grafana ダッシュボードファイルが、次のように更新されました。

プロデューサー操作を行う場合に、POST リクエストには、生成されるメッセージの 埋め込みデータ形式 を示す Content-Type ヘッダーを指定する必要があります。以前は、レコードとキーの値でサポートされている形式が JSON とバイナリーでした。text 形式も使用できるようになりました。

KRaft モードはテクノロジープレビューとして利用できます。

現在、Streams for Apache Kafka の KRaft モードには次の制限があります。

Streams for Apache Kafka のコンソール (ユーザーインターフェイス) が、テクノロジープレビューとして利用可能になりました。Streams for Apache Kafka Console は、Streams for Apache Kafka デプロイメントとシームレスに統合するように設計されており、Kafka クラスターの監視と管理のための一元化されたハブを提供します。コンソールをデプロイし、Streams for Apache Kafka が管理する Kafka クラスターに接続します。

ブローカー、トピック、コンシューマーグループをカバーする専用ページから、接続された各クラスターの洞察を得ることができます。ブローカー、トピック、または接続されたコンシューマーグループに関する特定の情報を調べる前に、Kafka クラスターのステータスなどの重要な情報を確認できます。

Streams for Apache Kafka Console ガイド を参照してください。

Streams for Apache Kafka Proxy は、Kafka ベースのシステムを強化するために設計された Apache Kafka プロトコル対応プロキシーです。そのフィルターメカニズムにより、アプリケーションや Kafka クラスター自体を変更することなく、Kafka ベースのシステムに追加の動作を導入できます。

テクノロジープレビューの一部として、Streams for Apache Kafka Proxy の Record Encryption フィルターを試すことができます。このフィルターは、業界標準の暗号化技術を使用して Kafka メッセージに暗号化を適用し、Kafka クラスターに保存されているデータの機密性を確保します。

Streams for Apache Kafka Proxy ガイド を参照してください。

Kafka Static Quota プラグインのテクノロジープレビューを使用して、Kafka クラスターのブローカーにスループットおよびストレージの制限を設定します。Kafka リソースを設定して、プラグインを有効にし、制限を設定します。バイトレートのしきい値およびストレージクォータを設定して、ブローカーと対話するクライアントに制限を設けることができます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback
      client.quota.callback.static.produce: 1000000
      client.quota.callback.static.fetch: 1000000
      client.quota.callback.static.storage.soft: 400000000000
      client.quota.callback.static.storage.hard: 500000000000
      client.quota.callback.static.storage.check-interval: 5

Kafka Static Quota プラグインを使用したブローカーへの制限の設定 を参照してください。

Streams for Apache Kafka は、開発者プレビューとして Kafka ブローカーの階層化ストレージをサポートするようになりました。これにより、ローカルストレージだけでなくカスタムリモートストレージソリューションも導入できるようになりました。現在の制限 により、実稼働環境では推奨されません。

リモートストレージ設定は、Kafka リソースの kafka.tieredStorage プロパティーを使用して指定します。カスタムリモートストレージマネージャーを指定して、階層化ストレージを管理します。

kafka:
  tieredStorage:
    type: custom
    remoteStorageManager:
      className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager
      classPath: /opt/kafka/plugins/tiered-storage-s3/*
      config:
        # remote storage manager configuration 1
        storage.bucket.name: my-bucket
  config:
    ...
    rlmm.config.remote.log.metadata.topic.replication.factor: 1 2

階層化ストレージ (早期アクセス) を参照してください。

Kafka では、デフォルトで、サンプルファイルコネクター FileStreamSourceConnector と FileStreamSinkConnector が CLASSPATH と plugin.path に含まれなくなりました。これらのサンプルコネクターを引き続き使用できるように、Streams for Apache Kafka が更新されました。サンプルは、他のコネクターと同様にプラグインパスに追加する必要があります。

Streams for Apache Kafka には、ファイルコネクターを KafkaConnector リソースとしてデプロイするために必要な設定を含むコネクター設定ファイルのサンプルが用意されています。

サンプル KafkaConnector リソースのデプロイ および コネクタープラグインでの Kafka Connect の拡張 を参照してください。

Streams for Apache Kafka カスタムリソース API リファレンス を参照してください。

Java 11 のサポートは、Kafka 3.7.0 および Streams for Apache Kafka 2.7.0 で非推奨になりました。Java 11 は、今後、クライアントを含む Streams for Apache Kafka コンポーネントでサポートされなくなります。

Streams for Apache Kafka は Java 17 をサポートしています。新しいアプリケーションを開発する場合は、Java 17 を使用してください。また、現在 Java 11 を使用しているアプリケーションの Java 17 への移行も計画してください。

双方向の Topic Operator は非推奨となり、2.8 リリースで削除されます。双方向の Topic Operator は KRaft モードではサポートされていません。KRaft モードでサポートされている一方向 Topic Operator は、2.8 リリースで永続的に有効になります。

設定プロバイダーを使用すると、プロデューサーやコンシューマーを含むすべての Kafka コンポーネントの外部ソースから設定データをロードできます。

以前は、コンポーネントの spec 設定で config.providers プロパティーを使用して、secrets.io.strimzi.kafka.EnvVarConfigProvider 環境変数設定プロバイダーを有効にすることができました。ただし、このプロバイダーは現在非推奨となっており、将来削除される予定です。したがって、Kafka 独自の環境変数設定プロバイダー (org.apache.kafka.common.config.provider.EnvVarConfigProvider) を使用して設定プロパティーを環境変数として提供するように実装を更新することが推奨されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...
  config:
    # ...
    config.providers: env
    config.providers.env.class: org.apache.kafka.common.config.provider.EnvVarConfigProvider
  # ...

ID レプリケーションポリシーは、リモートトピックの自動名前変更機能の後継として MirrorMaker 2 で使用される機能です。名前の前にソースクラスターの名前を付ける代わりに、トピックは元の名前を保持します。この設定は、アクティブ/パッシブバックアップおよびデータ移行シナリオに特に役立ちます。

ID レプリケーションポリシーを実装するには、MirrorMaker 2 設定でレプリケーションポリシークラス (replication.policy.class) を指定する必要があります。以前は、Streams for Apache Kafka の mirror-maker-2-extensions コンポーネントに含まれる io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy クラスを指定できました。ただし、このコンポーネントは非推奨となり、今後削除される予定です。したがって、Kafka 独自のレプリケーションポリシークラス (org.apache.kafka.connect.mirror.IdentityReplicationPolicy) を使用するように実装を更新することを推奨します。

Kafka MirrorMaker 2 の設定 を参照してください。

Kafka MirrorMaker は、データセンター内またはデータセンター全体の 2 台以上の Kafka クラスター間でデータをレプリケーションします。Kafka MirrorMaker 1 は Kafka 3.0.0 で非推奨となり、Kafka 4.0.0 で削除される予定です。MirrorMaker 2 が利用可能な唯一のバージョンになります。MirrorMaker 2 は、クラスター間のデータ転送を管理するコネクターである Kafka Connect フレームワークに基づいています。

その結果、Kafka MirrorMaker 1 のデプロイに使用される Streams for Apache Kafka の KafkaMirrorMaker カスタムリソースが非推奨になりました。KafkaMirrorMaker リソースは、Kafka 4.0.0 の導入時に Streams for Apache Kafka から削除されます。

MirrorMaker 1 (Streams for Apache Kafka ドキュメントでは MirrorMaker と表記) を使用している場合は、KafkaMirrorMaker2 カスタムリソースと IdentityReplicationPolicy クラスを使用してください。MirrorMaker 2 は、ターゲットクラスターに複製されたトピックの名前を変更します。IdentityReplicationPolicy 設定は、名前の自動変更をオーバーライドします。これを使用して、MirrorMaker 1 と同じ active/passive の一方向レプリケーションを作成します。

Kafka MirrorMaker 2 の設定 を参照してください。

Kafka Bridge の次の span 属性が非推奨になりました。該当する場合は代替属性を記載しています。

Kafka Bridge は分散トレーシングに OpenTelemetry を使用します。これらの変更は、OpenTelemetry のセマンティック規則の変更に沿ったものです。これらの属性は、Kafka Bridge の今後のリリースで削除される予定です。

OpenShift Container Platform (OCP) バージョン 4.16 に Kafka インスタンスをデプロイすると、Kafka namespace で dockercfg シークレットが継続的に作成されます。

この問題は、サービスアカウントに openshift.io/internal-registry-pull-secret-ref アノテーションが追加されると発生し、Streams for Apache Kafka と OpenShift がアノテーションを繰り返し書き換えるため、調整ループが発生します。時間が経つにつれて、何千もの不要なシークレットが蓄積される可能性があります。

アップグレードがすぐにできない場合は、一時的な回避策として、各サービスアカウントの openshift.io/internal-registry-pull-secret-ref アノテーションを手動で設定し、調整ループを防止します。

template:
  serviceAccount:
    metadata:
      annotations:
        openshift.io/internal-registry-pull-secret-ref: my-cluster-entity-operator-dockercfg-qxwxd

RHEL 7 を Kafka 3.7 と併用する場合、互換性の問題が発生することが確認されています。その結果、RHEL 7 はサポート対象外になりました。この問題は、RHEL 7 上の GCC (GNU Compiler Collection) のバージョンが古く、Kafka 3.7 に必要な RocksDB JNI ライブラリーのバージョン (org.rocksdb:rocksdbjni:7.9.2) と互換性がないために発生します。

RocksDB JNI バージョン 7.9.2 には、RHEL 7 で使用可能なものよりも新しいバージョンの GCC および関連する libstdc++ ライブラリーが必要です。RocksDB に依存する Snappy 圧縮と Kafka Streams は、これらの古いライブラリーが原因で、RHEL 7 では正しく機能しません。

状態がコネクター Operator に渡されないため、MirrorMaker 2 コネクターの自動再起動が機能しません。これは、Streams for Apache Kafka の今後のリリースで修正される予定です。

Streams for Apache Kafka Cluster Operator は、Internet Protocol version 6 (IPv6) クラスターでは起動しません。

Streams for Apache Kafka の Cruise Control には、CPU 使用率の推計に関連する既知の問題があります。CPU 使用率は、ブローカー Pod の定義容量の割合として計算されます。この問題は、CPU コアが異なるノードで Kafka ブローカーを実行する場合に発生します。たとえば、node1 には 2 つの CPU コアがあり、node2 には 4 つの CPU コアが含まれるとします。この場合、Cruise Control はブローカーの CPU 負荷を過大または過少に予測する可能性があります。この問題が原因で、Pod の負荷が大きいときにクラスターのリバランスができない場合があります。

この問題を回避する方法は 2 つあります。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      hard.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      default.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskUsageDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.TopicReplicaDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderReplicaDistributionGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderBytesInDistributionGoal

詳細は、Insufficient CPU capacity を参照してください。

JMX 認証を有効にして FIPS モードで Streams for Apache Kafka を実行すると、クライアントが認証に失敗する可能性があります。この問題を回避するには、FIPS モードでの実行中に JMX 認証を有効にしないでください。私たちはこの問題を調査しており、将来のリリースで解決できるよう取り組んでいます。

以下のプラットフォームは、記載されている OpenShift のバージョンで Kafka とともに実行される Streams for Apache Kafka 2.7 についてテストされています。

OpenShift Local は、Red Hat OpenShift Container Platform (OCP) の限定バージョンです。一部の機能が使用できない可能性があることを理解した上で、開発および評価のみに使用してください。

National Institute of Standards and Technology (NIST) によって承認されている RHEL のバージョンを確認するには、NIST Web サイトの Cryptographic Module Validation Program を参照してください。

Red Hat OpenShift Container Platform は FIPS 用に設計されています。OpenShift Container Platform のコアコンポーネントは、FIPS モードで起動された RHEL または RHEL CoreOS で実行される場合、x86_64、ppc64le (IBM Power)、s390x (IBM Z)、および aarch64 (64 ビット ARM) アーキテクチャー上でのみ、FIPS 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。NIST の検証プログラムの詳細は、Cryptographic Module Validation Program を参照してください。検証のために提出された RHEL 暗号化ライブラリーの各バージョンの NIST における最新ステータスについては、Compliance Activities and Government Standards を参照してください。

OpenShift Container Platform 4.12 は、FIPS 140-2 をサポートする最後のバージョンです。NIST による今後の OpenShift バージョンの検証タイムラインが不確実であることから、Streams for Apache Kafka は、告知があるまで OpenShift 4.12 でサポートされます。

Streams for Apache Kafka では、Red Hat によって構築されたクライアントライブラリーのみがサポートされます。現在、Streams for Apache Kafka は Java クライアントライブラリーのみを提供しています。クライアントは、次のオペレーティングシステムおよびアーキテクチャー上の Streams for Apache Kafka 2.7 での使用がサポートされています。

クライアントは Open JDK 11 および 17 でテストされていますが、Java 11 は Streams for Apache Kafka 2.7.0 で非推奨になりました。IBM JDK はサポートされていますが、リリースごとに定期的にテストされていません。Oracle JDK 11 はサポート対象外です。

Red Hat Universal Base Image (UBI) バージョンのサポートは、同じ RHEL バージョンに対応します。

Streams for Apache Kafka では、Apache Software Foundation から直接リリースされた次のコンポーネントのみがサポートされます。

12章サポート対象となる Red Hat 製品との統合 も併せて参照してください。

Streams for Apache Kafka はブロックストレージでテストされており、Streams for Apache Kafka は、Kafka で一般的に使用される XFS および ext4 ファイルシステムと互換性があります。NFS などのファイルストレージオプションとは互換性がありません。

Streams for Apache Kafka は、Red Hat build of Keycloak の Authorization Services による OAuth 2.0 トークンベースの認可をサポートしています。これにより、セキュリティーポリシーと権限を一元的に管理できます。

Kafka Bridge を OpenShift Container Platform にデプロイした場合は、3scale で使用できます。3scale API Management は、TLS を使用して Kafka Bridge を保護し、認証および認可を提供できます。また、3scale との統合により、メトリック、流量制御、請求などの追加機能も利用できるようになります。

3scale のデプロイについては、3scale API Management と Streams for Apache Kafka Bridge の使用 参照してください。

Red Hat build of Debezium は、分散型の変更データキャプチャープラットフォームです。データベースの行レベルの変更をキャプチャーして、変更イベントレコードを作成し、Kafka トピックにレコードをストリーミングします。Debezium は Apache Kafka 上に構築されています。Red Hat build of Debezium は、Streams for Apache Kafka にデプロイして統合できます。Streams for Apache Kafka のデプロイ後、Kafka Connect で Debezium をコネクター設定としてデプロイします。Debezium は、変更イベントレコードを OpenShift 上の Streams for Apache Kafka に渡します。アプリケーションはこれらの 変更イベントストリーム を読み取りでき、変更イベントが発生した順にアクセスできます。

Streams for Apache Kafka を使用した Debezium のデプロイの詳細は、Red Hat build of Debezium の製品ドキュメントを参照してください。

Red Hat build of Apicurio Registry を、データストリーミングのサービススキーマの集中型ストアとして使用できます。Kafka では、Red Hat build of Apicurio Registry を使用して Apache Avro または JSON スキーマを格納できます。

Apicurio Registry は、REST API および Java REST クライアントを提供し、サーバー側のエンドポイントを介してクライアントアプリケーションからスキーマを登録およびクエリーします。

Apicurio Registry を使用すると、クライアントアプリケーションの設定からスキーマ管理のプロセスが分離されます。クライアントコードに URL を指定して、アプリケーションがレジストリーからスキーマを使用できるようにします。

たとえば、メッセージをシリアライズおよびデシリアライズするスキーマをレジストリーに保存できます。アプリケーションは保存されたスキーマを参照し、それらを使用して送受信するメッセージとスキーマとの互換性を維持します。

Kafka クライアントアプリケーションは、実行時に Apicurio Registry からスキーマをプッシュまたはプルできます。

Streams for Apache Kafka で Red Hat build of Apicurio Registry を使用する方法の詳細は、Red Hat build of Apicurio Registry の製品ドキュメントを参照してください。

Red Hat build of Apache Camel K は、Apache Camel K から構築された軽量の統合フレームワークで、OpenShift 上のクラウドでネイティブに実行されます。Camel K はサーバーレス統合をサポートしているため、基盤となるインフラストラクチャーを管理する必要なく、統合タスクの開発とデプロイメントが可能になります。Camel K を使用すると、イベント駆動型アプリケーションを構築し、Streams for Apache Kafka 環境と統合できます。異なるシステムまたはデータベース間でのリアルタイムのデータ同期が必要な状況では、Camel K を使用してイベントの変更をキャプチャーおよび変換し、それらを Streams for Apache Kafka に送信して他のシステムに配信できます。

Streams for Apache Kafka で Camel K を使用する方法の詳細は、Red Hat build of Apache Camel K の製品ドキュメントを参照してください。

改訂日時: 2024-11-20