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

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

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

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

サポートされるバージョンの詳細は、カスタマーポータルの Red Hat AMQ 7 Component Details Page を参照してください。

Kafka バージョン 2.5.0 では、ZooKeeper バージョン 3.5.8 が必要です。

手作業で ZooKeeper 3.5.8 にアップグレードする必要はありません。Kafka ブローカーがアップグレードされる ときに、Cluster Operator によって ZooKeeper のアップグレードが実行されます。ただし、この手順の実行中に追加のローリング更新が実行されることがあります。

OpenShift 4.x での 非接続インストール のサポートは、テクノロジープレビューから AMQ Streams の一般提供コンポーネントに移行されます。

OpenShift クラスターが制限されたネットワークで非接続クラスター として使用されている場合、AMQ Streams の非接続インストールを実行できます。

非接続インストールでは、必要なイメージを取得し、それらをローカルでコンテナーレジストリーにプッシュします。Operator Lifecycle Manager (OLM) を使用している場合、OperatorHub によって使用されるデフォルトのソースを無効にし、ローカルミラーを作成してローカルソースから AMQ Streams をインストールすることになります。

ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。

MirrorMaker 2.0 のサポートは、テクノロジープレビューから AMQ Streams の一般提供コンポーネントに移行されます。

MirrorMaker 2.0 は Kafka Connect フレームワークをベースとし、コネクターによってクラスター間のデータ転送が管理されます。

MirrorMaker 2.0 は以下を使用します。

MirrorMaker 2.0 では、クラスターでデータをレプリケートする全く新しい方法が導入されました。MirrorMaker 2.0 の使用を選択した場合、現在、レガシーサポートがないため、リソースを手作業で新しい形式に変換する必要があります。

AMQ Streams の MirrorMaker 2.0 との使用 を参照してください。

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

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 からプッシュまたはプルできます。

Service Registry を使用したスキーマの管理 を参照してください。

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

ZooKeeper 3.5.* バージョンへのサポートの移行により、ZooKeeper Pod で TLS サイドカーを使う必要がなくなりました。サイドカーは削除され、TLS のネイティブ ZooKeeper サポートが使用されるようになりました。

新しい設定オプションによって、より多くの承認サーバーとの統合が可能になりました。

OAuth 2.0 認証の適用方法や、承認サーバーのタイプによっては、追加 (任意) の設定を使用できます。

  # ...
  authentication:
    type: oauth
    # ...
    checkIssuer: false 1
    fallbackUserNameClaim: client_id 2
    fallbackUserNamePrefix: client-account- 3
    validTokenType: bearer 4
    userInfoEndpointUri: https://AUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 5

# ...
spec:
  # ...
  authentication:
    # ...
    disableTlsHostnameVerification: true
    checkAccessTokenType: false
    accessTokenIsJwt: false
    scope: any 1

Kafka ブローカーの OAuth 2.0 サポートの設定 および Kafka コンポーネントの OAuth 2.0 の設定 を参照してください。

Prometheus サーバーは、AMQ Streams ディストリビューションの一部としてサポートされません。しかし、メトリクスを公開するために使用される Prometheus エンドポイントと JMX エクスポーターはサポートされます。

Kafka コンポーネントを監視する他に、メトリクス設定を追加して Cluster Operator、Topic Operator、および User Operator を監視できます。

Grafana ダッシュボードのサンプルが提供され、Prometheus によって公開される以下の operator メトリクスを表示できます。

Kafka へのメトリクスの導入 を参照してください。

TLS バージョンの特定の暗号に外部リスナーを実行することができるようになりました。

AMQ Streams で稼働している Kafka コンポーネントでは、許可される 3 つの ssl 設定オプションを使用して、TLS バージョンの固有の暗号スイートで外部リスナーを実行できます。暗号スイートでは、セキュアな接続とデータ転送のためのアルゴリズムが組み合わされます。

以下の例は、Kafka リソースの例を示しています。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  config: 1
    # ...
    ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 2
    ssl.enabled.protocols: "TLSv1.2" 3
    ssl.protocol: "TLSv1.2" 4

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

CORS (Cross-Origin Resource Sharing) より、Kafka Bridge のアクセス制御を有効化および定義できるようになりました。CORS は、複数のオリジンから指定のリソースにブラウザーでアクセスできるようにする HTTP メカニズムです。CORS を設定するには、許可されるリソースオリジンのリストと、それらにアクセスする HTTP メソッドを定義します。リクエストの追加の HTTP ヘッダーには Kafka クラスターへのアクセスが許可されるオリジンが記述 されています。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
    port: 8080
    cors:
      allowedOrigins: "https://strimzi.io" 1
      allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" 2
  # ...

Kafka Bridge HTTP の設定 を参照してください。

Cruise Control を AMQ Streams クラスターにデプロイし、Kafka クラスターの再分散に使用できるようになりました。Cruise Control を使用すると、分散された Kafka クラスターを効率的に実行するための時間および労力を削減できます。

Cruise Control は、Kafka リソースの設定の一部としてデプロイされます。Cruise Control の YAML 設定ファイルのサンプルは、examples/cruise-control/ にあります。

各 Kafka クラスターに Cruise Control のインスタンスをデプロイすると、以下を実行できます。

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

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

ユーザー提供の最適化ゴールの設定に関する既知の問題が存在します。6章既知の問題を参照してください。

トークンベースの認証に OAuth 2.0 を使用している場合、OAuth 2.0 承認ルールを使用して、クライアントの Kafka ブローカーへのアクセスを制限できるようになりました。

AMQ Streams は、Red Hat Single Sign-On の 承認サービス による OAuth 2.0 トークンベースの承認をサポートします。これにより、セキュリティーポリシーとパーミッションの一元的な管理が可能になります。

Red Hat Single Sign-On で定義されたセキュリティーポリシーおよびパーミッションは、Kafka ブローカーのリソースへのアクセスを付与するために使用されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。

OAuth 2.0 トークンベース承認の使用 を参照してください。

AMQ Streams 1.2 リリースでは、v1alpha1 バージョンの以下のリリースは非推奨となり、 v1beta1 に置き換えられました。

次回のリリースでは、v1alpha1 バージョンのこれらのリソースは削除される予定です。リソースのアップグレードに関する情報は AMQ Streams リソースのアップグレード を参照してください。

AMQ Streams 1.5.1 パッチリリースを使用できます。このマイクロリリースは、OpenShift OperatorHub ユーザーインターフェイスから AMQ Streams 1.5.0 をインストールするために使用される Operator メタデータを更新します。AMQ Streams の製品イメージは変更されておらず、バージョン 1.5.0 のままになります。

OpenShift Container Platform 4.5 を使用している場合、Red Hat は AMQ Streams 1.5.1 にアップグレードすることを推奨します。

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