AMQ Streams 1.6 on OpenShift リリースノート

ここでは、AMQ Streams 1.6 および後続のパッチリリースでサポートされる Kafka および ZooKeeper のバージョンについて説明します。

AMQ Streams 1.6.x は、OCP 3.11 で使用する長期サポートリリースであり、OpenShift Container Platform 3.11 がサポートされる限りのみサポートされます。

AMQ LTS バージョンのサポート日付の詳細は、Red Hat ナレッジベースソリューションHow long are AMQ LTS releases supported?を参照してください。

Red Hat によってビルドされた Kafka ディストリビューションのみがサポートされます。以前のバージョンの Kafka は、アップグレードの目的のみで AMQ Streams 1.6.x でサポートされます。

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

AMQ Streams コンテナーイメージは、Java ランタイム環境 (JRE) として Java 11 に移行されます。イメージの JRE バージョンは OpenJDK 8 から OpenJDK 11 に変更されます。

Cluster Operator のロギングは、Cluster Operator がデプロイされる際に自動作成される ConfigMap を使用して設定されるようになりました。ConfigMap は以下の新規 YAML ファイルに記述されます。

install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml

Cluster Operator のロギングを設定するには、以下を実行します。

ログのリロード頻度を変更するには、monitorInterval フィールドに、秒単位で時間を設定します (デフォルトのリロード時間は 30 秒 です)。

「Cluster Operator の設定」を参照してください。

OAuth 2.0 承認のサポートは、テクノロジープレビューから AMQ Streams の一般利用可能なコンポーネントに移行されます。

トークンベースの認証に 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 トークンベース承認の使用」を参照してください。

Open Policy Agent (OPA) は、オープンソースのポリシーエンジンです。OPA と AMQ Streams を統合して、Kafka ブローカーでのクライアント操作を許可するポリシーベースの承認メカニズムとして機能します。

クライアントからリクエストが実行されると、OPA は Kafka アクセスに定義されたポリシーに対してリクエストを評価し、リクエストを許可または拒否します。

Kafka クラスター、コンシューマーグループ、およびトピックのアクセス制御を定義できます。たとえば、プロデューサークライアントから特定のブローカートピックへの書き込みアクセスを許可する承認ポリシーを定義できます。

KafkaAuthorizationOpa スキーマ参照

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

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

以下で紹介されている機能拡張の概要を説明します。

本リリースには、AMQ Streams の Kafka Bridge コンポーネントに対して改良された以下の機能が含まれています。

『Kafka Bridge API reference』を参照してください。

/topics エンドポイントへの POST リクエストでは、リクエストボディーに含まれるメッセージペイロードに任意でヘッダーを指定できます。メッセージヘッダーの値はバイナリー形式である必要があり、Base64 としてエンコードされる必要があります。

curl -X POST \
  http://localhost:8080/topics/my-topic \
  -H 'content-type: application/vnd.kafka.json.v2+json' \
  -d '{
    "records": [
        {
            "key": "my-key",
            "value": "sales-lead-0001"
            "partition": 2
            "headers": [
              {
                "key": "key1",
                "value": "QXBhY2hlIEthZmthIGlzIHRoZSBib21iIQ=="
              }
            ]
        },
    ]
}'

「Kafka Bridge へのリクエスト」を参照してください。

本リリースには、OAuth 2.0 トークンベースの認証および承認に対して改良された以下の機能が含まれています。

セッションの再認証

AMQ Streams の OAuth 2.0 認証は Kafka ブローカーの セッションの再認証 をサポートするようになりました。これは、Kafka クライアントと Kafka ブローカー間の認証された OAuth 2.0 セッションの最大期間を定義します。セッションの再認証は、高速のローカル JWT とイントロスペクションエンドポイントの両方のタイプでサポートされます。

セッションの再認証を設定するには、Kafka ブローカーの OAuth 2.0 設定に新しい maxSecondsWithoutReauthentication オプションを使用します。

特定のリスナーでは、maxSecondsWithoutReauthentication では以下を行うことができます。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    listeners:
      #...
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
          maxSecondsWithoutReauthentication: 3600
          # ...

認証されたセッションは、設定されたmaxSecondsWithoutReauthentication を超えた場合や、アクセストークンの有効期限に達した場合に閉じられます。その後、クライアントは再度承認サーバーにログインし、新しいアクセストークンを取得して、Kafka ブローカーへ再認証する必要があります。これにより、既存の接続上で新しい認証セッションが確立されます。

次に再認証が必要な場合、クライアントによって試行された操作 (再認証以外) によって、ブローカーは接続を終了します。

以下を参照してください。「Kafka ブローカーのセッション再認証」および「Kafka ブローカーの OAuth 2.0 サポートの設定」

JWKS キーの更新間隔

高速のローカル JWT トークン検証を使用するように Kafka ブローカーを設定する場合に、外部リスナー設定に jwksMinRefreshPauseSeconds オプションを設定できるようになりました。これは、承認サーバーによって発行される JSON Web Key Set (JWKS) 公開鍵の更新をブローカーが試行する最小間隔を定義します。

本リリースでは、Kafka ブローカーは不明な署名キーを検出した場合に、通常の更新スケジュールを待たずに JWKS キーの更新を即座に試行します。

    listeners:
      #...
      - name: external2
        port: 9095
        type: loadbalancer
        tls: false
        authentication:
          type: oauth
          validIssuerUri: <https://<auth-server-address>/auth/realms/external>
          jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs>
          userNameClaim: preferred_username
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt
          disableTlsHostnameVerification: true
          jwksExpirySeconds: 360
          jwksRefreshSeconds: 300
          jwksMinRefreshPauseSeconds: 120
          enableECDSA: "true"

JWKS キーの更新スケジュールは、jwksRefreshSeconds オプションに設定されます。不明な署名キーが検出されると、JWKS キーの更新は更新スケジュールとは別にスケジュールされます。最後の更新からの経過時間が jwksMinRefreshPauseSeconds で指定される間隔に達するまで、更新は開始されません。

jwksMinRefreshPauseSeconds のデフォルト値は 1 です。

「Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。

Red Hat Single Sign-On からの付与 (Grants) の更新

Red Hat Single Sign-On により、OAuth 2.0 のトークンベースの承認に新たな設定オプションが追加されました。Kafka ブローカーの設定時に、Red Hat SSO Authorization Service からの付与 (Grants) の更新に関連する以下のオプションを定義できます。

「OAuth 2.0 トークンベース承認の使用」および「OAuth 2.0 承認サポートの設定」を参照してください。

Red Hat Single Sign-On でのパーミッション変更の検出

本リリースでは、keycloak (Red Hat SSO) 承認によってアクティブなセッションのパーミッションの変更が定期的にチェックされるようになりました。ユーザーの変更とパーミッション管理の変更がリアルタイムで検出されるようになりました。

メトリクス設定を Kafka Bridge および Cruise Control に追加できるようになりました。

Kafka Bridge および Cruise Control のサンプルメトリクスファイルは、以下を含む AMQ Streams で提供されます。

メトリクス設定がデプロイされ、Prometheus および Grafana が設定されると、監視に Grafana ダッシュボードのサンプルを使用できます。

metrics
├── grafana-dashboards
│   ├── strimzi-cruise-control.json
│   ├── strimzi-kafka-bridge.json
│   ├── strimzi-kafka-connect.json
│   ├── strimzi-kafka-exporter.json
│   ├── strimzi-kafka-mirror-maker-2.json
│   ├── strimzi-kafka.json
│   ├── strimzi-operators.json
│   └── strimzi-zookeeper.json
├── grafana-install
│   └── grafana.yaml
├── prometheus-additional-properties
│   └── prometheus-additional.yaml
├── prometheus-alertmanager-config
│   └── alert-manager-config.yaml
├── prometheus-install
│    ├── alert-manager.yaml
│    ├── prometheus-rules.yaml
│    ├── prometheus.yaml
│    ├── strimzi-pod-monitor.yaml
├── kafka-bridge-metrics.yaml
├── kafka-connect-metrics.yaml
├── kafka-cruise-control-metrics.yaml
├── kafka-metrics.yaml
└── kafka-mirror-maker-2-metrics.yaml

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

本リリースでは、ほとんどのカスタムリソースのロギングレベル (インラインと外部の両方) を変更しても、Kafka クラスターへのローリングアップデートがトリガーされなくなりました。再起動せずに、ロギングの変更が動的に適用されるようになりました。

この機能改良は、以下のリソースに適用されます。

Mirror Maker や Cruise Control には適用されません。

ConfigMap 経由で外部ロギングを使用する場合、ロギングアペンダーの変更時にローリングアップデートがトリガーされます。以下に例を示します。

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout

『AMQ Streams on OpenShift の使用』の「外部ロギング」および「デプロイメント設定」の章を参照してください。

本リリースでは、Prometheus メトリクスが Pod (Kafka、ZooKeeper、Kafka Connect など) からスクレイピングされる方法が変更になりました。

メトリクスは strimzi-pod-monitor.yaml で定義される PodMonitors によってのみ Pod からスクレイピングされるようになりました。以前のバージョンでは、これは ServiceMonitors および PodMonitors によって実行されていました。ServiceMonitors は本リリースで AMQ Streams から 削除 されました。

「PodMonitors を使用するためのモニタリングスタックのアップグレード」の説明にしたがって、PodMonitors を使用するようにモニタリングスタックをアップグレードする必要があります。

この変更により、以下の要素が Kafka および ZooKeeper に関連するサービスから 削除 されました。

この変更は、以下のサービスに適用されます。

Prometheus アノテーションを追加するには、「OpenShift リソースのカスタマイズ」の説明どおりに、関連する AMQ Streams カスタムリソースで template プロパティーを使用する必要があります。

PodMonitors を使用するためのモニタリングスタックのアップグレード

Kafka クラスターの監視が中断されないようにするには、AMQ Streams 1.6 にアップグレードする 前 に以下の手順を実行します。

AMQ Streams 1.6 へのアップグレードが完了したら、AMQ Streams 1.6 の Grafana ダッシュボードのサンプルをロードできます。

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

本リリースに GenericKafkaListener スキーマが導入されました。

スキーマは、Kafka リソースの Kafka リスナーを設定するもので、非推奨である KafkaListeners スキーマの代わりに使用されます。

GenericKafkaListener スキーマを使用すると、名前とポートが一意であれば、必要なリスナーをいくつでも設定できます。リスナー設定 は配列として定義されますが、非推奨の形式もサポートされます。

GenericKafkaListener スキーマ参照

新しい設定へのリスナーの更新

KafkaListeners スキーマは、plain、tls および external リスナーのサブプロパティーを使用し、それぞれに固定ポートを使用していました。アップグレードプロセスのいずれかの段階で、KafkaListeners スキーマを使用して設定されたリスナーを GenericKafkaListener スキーマの形式に変換する必要があります。

たとえば、現在 Kafka 設定で以下の設定を使用しているとします。

listeners:
  plain:
    # ...
  tls:
    # ...
  external:
    type: loadbalancer
    # ...

以下を使用して、リスナーを新しい形式に変換します。

listeners:
  #...
  - name: plain
    port: 9092
    type: internal
    tls: false 

  - name: tls
    port: 9093
    type: internal
    tls: true
  - name: external
    port: 9094
    type: EXTERNAL-LISTENER-TYPE 

    tls: true

必ず 正確な 名前とポート番号を使用してください。

これまでの形式で使用された追加の configuration または overrides プロパティーは、新しい形式に更新する必要があります。

リスナー 設定 に追加された変更：

すべてのリスナーが、アドバタイズされたホスト名およびポートの設定をサポートするようになりました。

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

listeners:
  external:
    type: loadbalancer
    authentication:
      type: tls
    overrides:
      bootstrap:
        dnsAnnotations:
          #...

これを以下に変更します。

listeners:
    #...
  - name: external
    port: 9094
    type:loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        annotations:
          #...

MirrorMaker 2.0 アーキテクチャーは、リモートトピックの名前を自動変更してソースクラスターを表すことで、双方向レプリケーションをサポートします。元のクラスターの名前の先頭には、トピックの名前が追加されます。

必要に応じて、IdentityReplicationPolicy をソースコネクター設定に追加することで、名前の自動変更をオーバーライドできるようになりました。この設定が適用されると、トピックには元の名前が保持されます。

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  #...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      config:
        replication.factor: 1
        offset-syncs.topic.replication.factor: 1
        sync.topic.acls.enabled: "false"
        replication.policy.separator: ""
        replication.policy.class: "io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy" 

  #...

オーバーライドは、アクティブ/パッシブクラスター設定でバックアップを作成したり、データを別のクラスターに移行する場合などに便利です。いずれの場合でも、リモートトピックの名前を自動的に変更したくないことがあります。

「Kafka MirrorMaker 2.0 の設定」を参照してください。

Kubernetes テンプレートおよび Pod のデプロイメントをカスタマイズする場合に、hostAliases を設定できるようになりました。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
#...
spec:
  # ...
  template:
    pod:
      hostAliases:
      - ip: "192.168.1.86"
        hostnames:
        - "my-host-1"
        - "my-host-2"
      #...

ホストおよび IP の一覧が指定された場合、Pod の /etc/hosts ファイルに注入されます。これは特に、クラスター外部の接続がユーザーによっても要求される場合に Kafka Connect または MirrorMaker で役立ちます。

PodTemplate スキーマ参照

新規 Operator メトリクスは、指定されたリソースの状態に関する情報 (つまり、正常に調整されたかどうか) を提供します。

strimzi_resource_state{kind="Kafka", name="my-cluster", resource-namespace="my-kafka-namespace"}

User Operator によって作成される Secret のテンプレートプロパティーを使用できるようになりました。KafkaUserTemplate を使用すると、ラベルとアノテーションを使用して、KafkaUser リソースに対して Secret が生成される方法を定義するメタデータを設定できます。

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  template:
    secret:
      metadata:
        labels:
          label1: value1
        annotations:
          anno1: value1
  # ...

KafkaUserTemplate スキーマ参照

AMQ Streams コンテナーイメージに以下のツールが追加されました。

Kafka Exporter サービスは AMQ Streams から 削除 されました。Prometheus は PodMonitor 宣言を使用して Kafka Exporter Pod から直接 Kafka Exporter メトリクスをスクレイピングするようになったため、このサービスは不要になりました。

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

--zookeeper オプションは、以下の Kafka 管理ツールで非推奨となりました。

これらのツールを使用する場合は、--bootstrap-server オプションを使用して、接続する Kafka ブローカーを指定する必要があります。以下は例になります。

kubectl exec BROKER-POD -c kafka -it -- \
  /bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

--zookeeper オプションは引き続き動作しますが、今後の Kafka リリースのすべての管理ツールから削除されます。これは、Kafka の ZooKeeper への依存関係を削除するために Apache Kafka プロジェクトが進めている作業の一部です。

Cruise Control は本リリースでもテクノロジープレビューの機能であり、新たな改良 が加えられました。

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

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

Cruise Control がデプロイされると、KafkaRebalance カスタムリソースを使用できます。

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

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

apiVersion: kafka.strimzi.io/v1alpha1
kind: KafkaRebalance
metadata:
  name: my-rebalance
  labels:
    strimzi.io/cluster: amq-streams-cluster
spec:
  goals:
    - CpuCapacityGoal
    - DiskCapacityGoal
  #...

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: amq-streams-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      cpuUtilization: 85
      disk: 100Gi
    # ...

Kafka.KafkaSpec.KafkaClusterSpec リソースの KafkaListeners スキーマは非推奨になりました。

詳細は、改良された機能の「汎用リスナーの設定」を参照してください。

AMQ Streams 1.6.7 パッチリリース（長期サポート）が利用できるようになりました。

AMQ Streams 1.6.7 は、OpenShift Container Platform 3.11 でのみ使用する最新の長期サポートリリースであり、OpenShift Container Platform 3.11 がサポートされる限りのみサポートされます。

AMQ Streams 1.6.7 は OCP 3.11 でのみサポートされます。

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

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

Log4j の脆弱性

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

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

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

Log4j2 の脆弱性

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

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

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

Log4j2 の脆弱性

1.6.5 リリースでは、log4j2 を使用する AMQ Streams コンポーネントのリモートコード実行脆弱性が修正されました。この脆弱性により、システムが承認されていないソースから文字列の値をログに記録した場合に、サーバーでのリモートコード実行が可能になる可能性がありました。これは 2.0 から 2.14.1 までの log4j バージョンに影響を与えます。

詳細は、CVE-2021-44228 を参照してください。

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

AMQ Streams 1.6.2 パッチリリースを使用できます。このリリースには、Kafka Connect に関連する修正が複数含まれています。

AMQ Streams の製品イメージは変更されておらず、バージョンは 1.6 のままになります。

AMQ Streams 1.6.2 で解決された問題の詳細は、「AMQ Streams 1.6.2 Resolved Issues」を参照してください。