AMQ Streams 2.1 on OpenShift のリリースノート

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

サポートされているプラットフォームバージョンの詳細については、AMQ Streams Supported Configurations を参照してください。

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

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

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

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

サポート対象バージョンの詳細については、AMQ Streams Component Details を参照してください。

Kafka 3.1.0 には、Kafka 3.0.0 と同じバージョンの ZooKeeper バージョン 3.6.3 が必要です。そのため、AMQ Streams 2.0 から AMQ Streams 2.1 にアップグレードするときに、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 2.1 は IBM Z および LinuxONE s390x アーキテクチャーで稼働するように有効になっています。

IBM Z および LinuxONE のサポートは、OpenShift Container Platform 4.10 の Kafka 3.1.0 で実行されている AMQ Streams に適用されます。AMQ Streams 2.0 以前のバージョンの Kafka バージョンには s390x バイナリーが含まれていません。

AMQ Streams 2.1 は、BM Power ppc64le アーキテクチャーで実行できます。

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

Cluster Operator は、ユーザーが提供したカスタム CA 証明書を検出できるようになりました。カスタム証明書を更新すると、Cluster Operator は、Zoo Keeper、Kafka、およびその他のコンポーネントのローリング更新を実行して、新しい CA 証明書を信頼します。

独自の証明書を使用している場合、Cluster Operator は自動的に更新されません。代わりに、既存の Secret を編集して、新しい CA 証明書を追加し、証明書生成アノテーション値を更新する必要があります。アノテーションは、Cluster Operator が更新プロセスで最新の証明書を使用するように、より高い増分値に設定されます。

apiVersion: v1
kind: Secret
data:
  ca.crt: GCa6LS3RTHeKFiFDGBOUDYFAZ0F... 
metadata:
  annotations:
    strimzi.io/ca-cert-generation: "1" 
  labels:
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
  name: my-cluster-cluster-ca-cert
  #...
type: Opaque

apiVersion: v1
kind: Secret
data:
  ca.crt: GCa6LS3RTHeKFiFDGBOUDYFAZ0F... 

metadata:
  annotations:
    strimzi.io/ca-cert-generation: "1" 

  labels:
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
  name: my-cluster-cluster-ca-cert
  #...
type: Opaque

独自の CA 証明書の更新 を参照してください。

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 documentation を参照してください。

Kafka 3.1.0 に導入された機能拡張の概要は、Kafka 3.1.0 Release Notes を参照してください。

現在、FIPS 準拠の設定ではありませんが、FIPS 対応のクラスターで AMQ ストリームを実行できるようになりました。

AMQ Streams コンテナーイメージで使用される OpenJDK は、FIPS 対応クラスターで自動的に FIPS モードに切り替わります。これにより、AMQ Streams がクラスターで実行されなくなります。

FIPS 対応クラスターで AMQ Streams を実行するには、Cluster Operator のデプロイメント設定で FIPS_MODE 環境変数を無効に設定し、OpenJDK FIPS モードを無効にします。AMQ Streams のデプロイは FIPS に準拠していませんが、AMQ Streams Operator とそのすべてのオペランドは、FIPS 対応の Kubernetes クラスターで実行できます。

apiVersion: apps/v1
kind: Deployment
spec:
  # ...
  template:
    spec:
      serviceAccountName: strimzi-cluster-operator
      containers:
        # ...
        env:
        # ...
        - name: "FIPS_MODE"
          value: "disabled" 
  # ...

apiVersion: apps/v1
kind: Deployment
spec:
  # ...
  template:
    spec:
      serviceAccountName: strimzi-cluster-operator
      containers:
        # ...
        env:
        # ...
        - name: "FIPS_MODE"
          value: "disabled" 

  # ...

Cluster Operator での FIPS モードの設定 を参照してください。

Kafka デプロイメントで、同じブローカーにディスクが複数割り当てられた JBOD ストレージを使用している場合には、Cruise Control はディスク間でパーティションを分散できます。

rebalanceDisk 設定オプションを使用します。ブローカー内のディスク分散を実行するには、KafkaRebalance.spec で rebalanceDisk を true に設定します。

リバランスパフォーマンスチューニング を参照してください。

フィーチャーゲートの ControlPlaneListener および ServiceAccountPatching は beta 成熟段階に移行します。つまり、どちらもデフォルトで有効になっています。

成熟段階が beta レベルのフィーチャーゲートは十分にテストされており、それらの機能は変更されない可能性が高くなります。

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

新しいリスナー設定プロパティーを使用すると、loadBalancer タイプのリスナーのブートストラップサービスを作成するかどうかを制御できます。<cluster_name>-kafka-external-bootstrap ブートストラップサービスは、Kafka クラスターに対してデフォルトで作成されます。リスナー設定で createBootstrapService プロパティーを false に設定することにより、ロードバランサーのサービスを作成しないことを選択できます。

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      createBootstrapService: false
      # ...
# ...

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      createBootstrapService: false
      # ...
# ...

GenericKafkaListenerConfiguration スキーマプロパティー を参照してください。

新しい OAuth 設定プロパティーが OAuth 認証設定に導入されました。

タイムアウトとグループ情報の抽出に関連するプロパティー。

デフォルトは両方とも 60 秒です。

#...
- name: external
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    # ...
    connectTimeoutSeconds: 60
    readTimeoutSeconds: 60
    groupsClaim: "$.groups"
    groupsClaimDelimiter: ","

#...
- name: external
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    # ...
    connectTimeoutSeconds: 60
    readTimeoutSeconds: 60
    groupsClaim: "$.groups"
    groupsClaimDelimiter: ","

KafkaListenerAuthenticationOAuth スキーマリファレンス および KafkaClientAuthenticationOAuth スキーマプロパティー を参照してください。

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

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 への移行も計画してください。

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

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

ID レプリケーションポリシーは MirrorMaker 2.0 で使用され、リモートトピックの自動名前変更をオーバーライドします。その名前の前にソースクラスターの名前を追加する代わりに、トピックが元の名前を保持します。このオプションの設定は、active/passive バックアップおよびデータ移行に役立ちます。

現在、AMQ Streams Identity Replication Policy class (io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy) は非推奨であり、将来削除される予定です。Kafka 独自の ID レプリケーションポリシー (class org.apache.kafka.connect.mirror.IdentityReplicationPolicy) に更新できます。

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

ListenerStatus の type プロパティーは非推奨になり、将来削除される予定です。ListenerStatus は、内部および外部リスナーのアドレスを指定するために使用されます。type を使用する代わりに、アドレスが name で指定されるようになりました。

ListenerStatus スキーマ参照 を参照してください。

disk および cpuUtilization 容量の設定プロパティーは非推奨になり、無視され、将来削除される予定です。プロパティーは、リソースベースの最適化ゴールの破損を判断するための最適化プロポーザルの容量制限の設定に使用されました。ディスクと CPU の容量制限は、AMQ Streams によって自動的に生成されるようになりました。

Cruise Control configuration を参照してください。

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

AMQ Streams の Cruise Control には、CPU 使用率予測の計算に関連する既知の問題があります。CPU 使用率は、ブローカー Pod の定義容量の割合として計算されます。この問題は、CPU コアが異なるノードで Kafka ブローカーを実行する場合に発生します。たとえば、node1 には 2 つの CPU コアがあり、node2 には 4 つの CPU コアが含まれるとします。この場合、Cruise Control はブローカーの 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

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 を参照してください。