AMQ Streams 2.0 は OpenShift Container Platform 4.6 〜 4.9 でサポートされます。

サポートされるプラットフォームバージョンの詳細については、Red Hat ナレッジベースの記事「Red Hat Streams for Apache Kafka Supported Configurations」を参照してください。

AMQ Streams は Apache Kafka バージョン 3.0.0 に対応するようになりました。

AMQ Streams は Kafka 3.0.0 を使用します。Red Hat によってビルドされた Kafka ディストリビューションのみがサポートされます。

ブローカーおよびクライアントアプリケーションを Kafka 3.0.0 にアップグレードする前に、Cluster Operator を AMQ Streams バージョン 2.0 にアップグレードする必要があります。アップグレードの手順は、「AMQ Streams のアップグレード」を参照してください。

詳細は、Kafka 2.8.0 および Kafka 3.0.0 のリリースノートを参照してください。

サポートされるバージョンの詳細は、Red Hat Streams for Apache Kafka Component Details を参照してください。

Kafka 3.0.0 には ZooKeeper バージョン 3.6.3 が必要です。そのため、AMQ Streams 1.8 から AMQ Streams 2.0 にアップグレードするときに、Cluster Operator は ZooKeeper のアップグレードを実行します。

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

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

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

Deploying and upgrading AMQ Streams を参照してください。

AMQ Streams では、Scala2.12 の代わりに Scala2.13 が使用されるようになりました。

Maven ビルドで Kafka Streams の依存関係を使用している場合は、Scala2.13 および Kafka バージョン 3.0.0 を指定するように更新する必要があります。依存関係が更新されない場合は、ビルドされません。

<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-streams-scala_2.13</artifactId>
    <version>3.0.0</version>
</dependency>

Kafka Streams Scala 依存関係 を参照してください。

AMQ Streams 2.0 は、PowerPC ppc64le アーキテクチャーでの実行が有効になっています。

IBM Power システムのサポートは、OpenShift Container Platform 4.9 の Kafka 3.0.0 で実行されている AMQ Streams に適用されます。AMQ Streams 1.8 以前のバージョンの Kafka バージョンには ppc64 バイナリーが 含まれていません。

AMQ Streams 2.0 では、AMQ Streams Drain Cleaner が導入されました。AMQ Streams Drain Cleaner を Cluster Operator と組み合わせて使用し、ドレイン (解放) されているノードから Kafka ブローカーまたは ZooKeeper Pod を移動します。

Cluster Operator および Kafka クラスターが実行中の OpenShift クラスターに、AMQ Streams Drain Cleaner をデプロイします。AMQ Streams Drain Cleaner をデプロイすることで、Cluster Operator を使用して OpenShift ではなく Kafka Pod を移動できます。

AMQ Streams Drain Cleaner を実行すると、Pod にローリングアップデート Pod アノテーションが付けられます。Cluster Operator はアノテーションに基づいてローリングアップデートを実行します。Cluster Operator は、トピックの複製の数が最低数未満にならないようにします。

Evicting pods with AMQ Streams Drain Cleaner を参照してください。

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

Debezium には、以下を含む複数の用途があります。

Debezium は、以下の共通データベースのコネクター (Kafka Connect をベースとする) を提供します。

AMQ Streams で Debezium をデプロイするための詳細は、「製品ドキュメント」を参照してください。

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

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

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

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

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

AMQ Streams で Service Registry を使用するための詳細は、Service Registry のドキュメントを参照してください。

Kafka 3.0.0 に導入された改良機能の概要はKafka 3.0.0 Release Notesを参照してください。

これで、リスナーの NetworkPolicy リソースの自動作成を無効にし、代わりに独自のカスタムネットワークポリシーを使用できるようになりました。

デフォルトでは、AMQ Streams では、Kafka ブローカーで有効になっているリスナーごとに NetworkPolicy リソースが自動的に作成されます。特定のリスナーの場合、ネットワークポリシーはすべての namespace にまたがるアプリケーションが接続できるようにします。この動作は、networkPolicyPeers を使用して制限できます。

自動作成された NetworkPolicies を無効にするには、Cluster Operator 設定で STRIMZI_NETWORK_POLICY_GENERATION 環境変数を false に設定します。

Cluster Operator configuration および Network policies を参照してください。

User Operator は、ZooKeeper の代わりに Kafka Admin API を使用して SCRAM-SHA-512 ユーザーの認証情報を管理するようになりました。Operator は SCRAM-SHA-512 認証情報管理の Kafka に直接接続します。

この変更は、Kafka の ZooKeeper への依存関係を削除するために Apache Kafka プロジェクトが進めている作業の一部です。

ZooKeeper 関連の一部の設定は非推奨となり、削除されました。

Deprecated features および Using the User Operator を参照してください。

データコネクションに必要なコネクタープラグインでコンテナーイメージを自動的にビルドする build 設定で、Kafka Connect をデプロイできます。コネクタープラグインのアーティファクトを Maven コーディネートとして指定できるようになりました。

AMQ Streams では、以下のタイプのアーティファクトがサポートされます。

Maven コーディネートは、プラグインアーティファクトおよび依存関係を特定し、Maven リポジトリーから検索および取得できるようにします。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: maven 1
          - repository: https://mvnrepository.com 2
          - group: org.apache.camel.kafkaconnector 3
          - artifact: camel-kafka-connector 4
          - version: 0.11.0 5
  #...

Build schema reference を参照してください。

環境変数の設定プロバイダープラグインを使用して、環境変数から設定データを読み込みます。

プロバイダーを使用して、プロデューサーやコンシューマーを含む、すべての Kafka コンポーネントの設定データを読み込むことができます。たとえば、プロバイダーを使用して、Kafka Connect コネクター設定のクレデンシャルを提供します。

環境変数の値は、シークレットまたは設定マップからマッピングできます。環境変数設定プロバイダーを使用して、たとえば、OpenShift シークレットからマップされた環境変数から証明書または JAAS 設定を読み込むことができます。

Loading configuration values from external sources を参照してください。

安全でないサーバーから、コネクタープラグインアーティファクトをダウンロードできるようになりました。これは JAR、TGZ、およびコンテナーイメージにダウンロードされ、追加されたその他のファイルに適用されます。これは、コネクター build 設定の insecure プロパティーを使用して設定できます。ダウンロードするプラグインアーティファクトを指定する場合は、プロパティーを true に設定します。これにより、すべての TLS 検証が無効になります。サーバーが安全ではない場合、アーティファクトは引き続きダウンロードされます。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: tgz
            url: https://my-domain.tld/my-connector-archive.tgz
            sha512sum: 158...jg10
            insecure: true
  #...

Build schema reference を参照してください。

OpenShift 上の Kafka Connect ビルドのベースイメージをプルするために使用される、コンテナーレジストリーシークレットを指定できるようになりました。シークレットは template のカスタマイズとして設定されています。Kafka Connect spec の buildConfig テンプレートを使用して、pullSecret プロパティーを使用したシークレットの指定でができます。シークレットには、ベースイメージをプルするための認証情報が含まれます。

# ...
template:
  buildConfig:
    metadata:
      labels:
        label1: value1
        label2: value2
      annotations:
        annotation1: value1
        annotation2: value2
    pullSecret: "<secret_credentials>"
# ...

/tmp (一時的な emptyDir ボリューム) の合計ローカルストレージサイズを設定できるようになりました。この仕様は、現在 Pod で実行されている単一コンテナーで機能します。デフォルトのストレージサイズは 1Mi です。サイズは template のカスタマイズとして設定されます。リソースの spec で pod テンプレートを使用し、tmpDirSizeLimit プロパティーを使用してボリュームサイズを指定できます。

# ...
template:
  pod:
    tmpDirSizeLimit: "2Mi"
# ...

クラスター管理者は、OpenShift で利用可能なメータリングツールを使用して、クラスターで実行されている内容を分析できます。このツールを使用して、レポートを生成し、インストールされた AMQ Streams コンポーネントを分析できるようになりました。Prometheus をデフォルトのデータソースとして使用すると、Pod、namespace、およびその他ほとんどの Kubernetes リソースのレポートを生成できます。OpenShift の Metering Operator を使用すると、インストールされた AMQ Streams コンポーネントを分析し、Red Hat サブスクリプションに準拠しているかどうかを判断することができます。

AMQ Streams でメータリングを使用するには、まず OpenShift Container Platform に Metering operator をインストールし、設定する必要があります。

Using Metering on AMQ Streams を参照してください。

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 プラグインを使用したブローカーへの制限の設定 を参照してください。

Cruise Control をデプロイし、これを使用して 最適化ゴール (CPU、ディスク、ネットワーク負荷などに定義された制約) を使用し、Kafka をリバランスできます。バランス調整された Kafka クラスターでは、ワークロードがブローカー Pod 全体に均等に分散されます。

Cruise Control は Kafka リソースの一部として設定され、デプロイされます。デフォルトの最適化ゴールを使用するか、要件に合わせて変更できます。Cruise Control の YAML 設定ファイルのサンプルは、examples/cruise-control/ にあります。

Cruise Control がデプロイされると、KafkaRebalance カスタムリソースを作成して以下を行うことができます。

通知、独自ゴールの作成、トピックレプリケーション係数の変更など、その他の Cruise Control の機能は現在サポートされていません。

Cruise Control によるクラスターのリバランス を参照してください。

Java 8 のサポートは Kafka 3.0.0 および AMQ Streams 2.0 で非推奨となりました。Java 8 は、今後、クライアントを含むすべての AMQ Streams コンポーネントではサポートされません。

AMQ Streams は Java 11 をサポートします。新規アプリケーションの開発時に Java 11 を使用します。現在 Java 8 を使用しているアプリケーションを Java 11 に移行する計画です。

スタンドアロンの User Operator 設定から 2 つの環境変数が 削除 されました。

以前のバージョンでは、これらの環境変数は、スタンドアロンの User Operator のみをデプロイするのに使用される install/user-operator/05-Deployment-strimzi-user-operator.yaml で設定されていました。

User Operator の zookeeperSessionTimeoutSeconds プロパティーは不要になり、非推奨 になりました。このプロパティーは Kafka リソースの userOperator プロパティーに設定されました。

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

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

MirrorMaker 1 (AMQ ストリームドキュメントでちょうど MirrorMaker と呼ばれる) を使用している場合は、IdentityReplicationPolicy と KafkaMirrorMaker2 のカスタムリソースを使用します。MirrorMaker 2.0 では、ターゲットクラスターにレプリケートされたトピックの名前が変更されます。IdentityReplicationPolicy 設定は、名前の自動変更を上書きします。これを使用して、MirrorMaker 1 と同じアクティブ/パッシブの一方向レプリケーションを作成します。

Kafka MirrorMaker 2.0 クラスターの設定 を参照してください。

AMQ Streams サンプルファイルで提供される OpenShift テンプレートが削除され、サポート対象外になりました。テンプレート設定ファイルは、OpenShift コンソールから Kafka コンポーネントをデプロイするために提供されていました。たとえば、一時ストレージまたは永続ストレージで Kafka をデプロイするためにテンプレートが含まれていました。テンプレートは、OpenShift 3.11 を使用する場合にいくつかの利点を提供していました。OpenShift 4.x 以降、Cluster Operator を使用して OpenShift コンソールで Kafka コンポーネントをインストールし、管理することがより容易になります。

build 設定が KafkaConnect リソースに導入されたため、AMQ Streams はデータコネクションに必要なコネクタープラグインでコンテナーイメージを自動的にビルドできるようになりました。

そのため、S2I (Source-to-Image) 対応の Kafka Connect のサポートが削除されました。

Kafka Connect S2I インスタンスを Kafka Connect インスタンスに移行できます。

「Kafka Connect S2I の Kafka Connect への移行」を参照してください。

AMQ Streams 2.0.1 パッチリリースが利用できるようになりました。

AMQ Streams の製品イメージがバージョン 2.0.1 にアップグレードされました。

AMQ Streams 2.0.1 で解決された問題の詳細は、AMQ Streams 2. 0.x Resolved Issues を参照してください。

Log4j の脆弱性

AMQ Streams には log4j 1.2.17 が含まれています。このリリースでは、log4j の脆弱性が数多く修正されています。

本リリースで対応する脆弱性の詳細は、以下の CVE の説明を参照してください。

Log4j2 の脆弱性

AMQ Streams には log4j2 2.17.1 が含まれています。本リリースでは、log4j2 の脆弱性が多数修正されています。

本リリースで対応する脆弱性の詳細は、以下の CVE の説明を参照してください。

AMQ Streams には、潜在的に脆弱なバージョンの log4j (log4j-1.2.17.redhat-3) が同梱されています。脆弱性は、デフォルト設定で AMQ Streams によって使用されない SMTP アペンダー機能にあります。

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

AMQ Streams の Cruise Control には、CPU 使用率予測の計算に関連する既知の問題があります。CPU 使用率は、ブローカー Pod の定義容量の割合として計算されます。この問題は、ノードの論理プロセッサーの数が、そのノード上の Kafka ブローカー Pod の CPU 制限と等しくない場合に発生します。この問題は、Pod の負荷が大きい場合に、クラスターのリバランスを阻止することができます。

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

詳細は、OptimizationFailureException due to insufficient CPU capacity を参照してください。