23.5. Kafka のアップグレード


Cluster Operator を 2.6 にアップグレードした後、次にすべての Kafka ブローカーをサポートされる最新バージョンの Kafka にアップグレードします。

Kafka のアップグレードは、Kafka ブローカーのローリング更新によって Cluster Operator によって実行されます。

Cluster Operator は、Kafka クラスターの設定に基づいてローリング更新を開始します。

Expand
Kafka.spec.kafka.config に以下が含まれている場合Cluster Operator によって開始されるもの

inter.broker.protocol.versionlog.message.format.version の両方。

単一のローリング更新。更新後、inter.broker.protocol.version を手動で更新し、続いて log.message.format.version を更新する必要があります。それぞれを変更すると、ローリング更新がさらにトリガーされます。

inter.broker.protocol.version または log.message.format.version のいずれか。

2 つのローリング更新

inter.broker.protocol.version または log.message.format.version の設定なし。

2 つのローリング更新

重要

Kafka 3.0.0 以降、inter.broker.protocol.version3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。ブローカーの log.message.format.version プロパティーおよびトピックの message.format.version プロパティーは、非推奨となり、Kafka の今後のリリースで削除されます。

Cluster Operator は、Kafka のアップグレードの一環として、ZooKeeper のローリング更新を開始します。

  • ZooKeeper バージョンが変更されなくても、単一のローリング更新が発生します。
  • 新しいバージョンの Kafka に新しいバージョンの ZooKeeper が必要な場合、追加のローリング更新が発生します。

23.5.1. Kafka バージョン

Kafka のログメッセージ形式バージョンと inter-broker プロトコルバージョンは、それぞれメッセージに追加されるログ形式バージョンとクラスターで使用される Kafka プロトコルのバージョンを指定します。正しいバージョンが使用されるようにするため、アップグレードプロセスでは、既存の Kafka ブローカーの設定変更と、クライアントアプリケーション (コンシューマーおよびプロデューサー) のコード変更が行われます。

以下の表は、Kafka バージョンの違いを示しています。

Expand
表23.1 Kafka バージョンの相違点
AMQ Streams のバージョンKafka バージョンInter-broker プロトコルバージョンログメッセージ形式バージョンZooKeeper バージョン

2.6

3.6.0

3.6

3.6

3.8.3

2.5

3.5.0

3.5

3.5

3.6.4

  • Kafka 3.6.0 は実稼働環境での使用がサポートされています。
  • Kafka 3.5.0 は、AMQ Streams 2.6 にアップグレードする目的でのみサポートされます。

Inter-broker プロトコルバージョン

Kafka では、Inter-broker の通信に使用されるネットワークプロトコルは Inter-broker プロトコル と呼ばれます。Kafka の各バージョンには、互換性のあるバージョンの Inter-broker プロトコルがあります。上記の表が示すように、プロトコルのマイナーバージョンは、通常 Kafka のマイナーバージョンと一致するように番号が増加されます。

Inter-broker プロトコルのバージョンは、Kafka リソースでクラスター全体に設定されます。これを変更するには、Kafka.spec.kafka.configinter.broker.protocol.version プロパティーを編集します。

ログメッセージ形式バージョン

プロデューサーが Kafka ブローカーにメッセージを送信すると、特定の形式を使用してメッセージがエンコードされます。この形式は Kafka のリリース間で変更になる可能性があるため、メッセージにはエンコードに使用されたメッセージ形式のバージョンが指定されます。

特定のメッセージ形式のバージョンを設定するために使用されるプロパティーは以下のとおりです。

  • トピック用の message.format.version プロパティー
  • Kafka ブローカーの log.message.format.version プロパティー

Kafka 3.0.0 以降、メッセージ形式のバージョンの値は inter.broker.protocol.version と一致すると見なされ、設定する必要はありません。値は、使用される Kafka バージョンを反映します。

Kafka 3.0.0 以降にアップグレードする場合は、inter.broker.protocol.version を更新する際にこの設定を削除できます。それ以外の場合は、アップグレード先の Kafka バージョンに基づいてメッセージ形式のバージョンを設定します。

トピックの message.format.version のデフォルト値は、Kafka ブローカーに設定される log.message.format.version によって定義されます。トピックの message.format.version は、トピック設定を編集すると手動で設定できます。

23.5.2. クライアントをアップグレードするストラテジー

Kafka クライアントをアップグレードすると、Kafka の新しいバージョンで導入された機能、修正、改善の恩恵を受けることができます。アップグレードされたクライアントは、他のアップグレードされた Kafka コンポーネントとの互換性を維持します。クライアントのパフォーマンスと安定性も向上する可能性があります。

スムーズな移行を確保するために、Kafka クライアントとブローカーをアップグレードするための最適なアプローチを検討してください。選択するアップグレード戦略は、ブローカーを最初にアップグレードするかクライアントを最初にアップグレードするかによって異なります。Kafka 3.0 以降、ブローカーとクライアントを独立して任意の順序でアップグレードできるようになりました。クライアントまたはブローカーをアップグレードするかどうかは、最初に、アップグレードする必要があるアプリケーションの数や許容できるダウンタイムの量など、いくつかの要因によって決まります。

ブローカーより前にクライアントをアップグレードすると、一部の新機能はブローカーによってまだサポートされていないため、機能しない可能性があります。ただし、ブローカーは、異なるバージョンで実行され、異なるログメッセージバージョンをサポートするプロデューサーとコンシューマーを処理できます。

Kafka 3.0 より古いバージョンの Kafka を使用する場合のクライアントのアップグレード

Kafka 3.0 より前では、log.message.format.version プロパティー (またはトピックレベルの message.format.version プロパティー) を使用して、ブローカーの特定のメッセージ形式を設定していました。これにより、ブローカーは、古いメッセージ形式を使用していた古い Kafka クライアントをサポートできるようになりました。そうしないと、ブローカーは古いクライアントからのメッセージを変換する必要があり、これには大幅なパフォーマンスコストがかかります。

Apache Kafka Java クライアントは、バージョン 0.11 以降、最新のメッセージ形式バージョンをサポートしています。すべてのクライアントが最新のメッセージバージョンを使用している場合は、ブローカーをアップグレードするときに、log.message.format.version または message.format.version のオーバーライドを削除できます。

ただし、古いメッセージ形式バージョンを使用しているクライアントがまだある場合は、まずクライアントをアップグレードすることを推奨します。コンシューマーから始めて、ブローカーのアップグレード時に log.message.format.version または message.format.version のオーバーライドを削除する前に、プロデューサーをアップグレードします。これにより、すべてのクライアントが最新のメッセージ形式バージョンをサポートできるようになり、アップグレードプロセスがスムーズに進むようになります。

次のメトリックを使用して、Kafka クライアントの名前とバージョンを追跡できます。

  • kafka.server:type=socket-server-metrics,clientSoftwareName=<name>,clientSoftwareVersion=<version>,listener=<listener>,networkProcessor=<processor>
ヒント

次の Kafka ブローカーメトリックは、メッセージのダウンコンバージョンのパフォーマンスを監視するのに役立ちます。

  • kafka.network:type=RequestMetrics,name=MessageConversionsTimeMs,request={Produce|Fetch} はメッセージ変換の実行にかかる時間に関するメトリックを提供します。
  • kafka.server:type=BrokerTopicMetrics,name={Produce|Fetch}MessageConversionsPerSec,topic=(-.\w+) は一定期間に変換されたメッセージの数に関するメトリックを提供します。

23.5.3. Kafka バージョンおよびイメージマッピング

Kafka のアップグレード時に、STRIMZI_KAFKA_IMAGES 環境変数と Kafka.spec.kafka.version プロパティーの設定について考慮してください。

  • それぞれの Kafka リソースは Kafka.spec.kafka.version で設定できます。
  • Cluster Operator の STRIMZI_KAFKA_IMAGES 環境変数により、Kafka のバージョンと、指定の Kafka リソースでそのバージョンが要求されるときに使用されるイメージをマッピングできます。

    • Kafka.spec.kafka.image を設定しないと、そのバージョンのデフォルトのイメージが使用されます。
    • Kafka.spec.kafka.image を設定すると、デフォルトのイメージがオーバーライドされます。
警告

Cluster Operator は、Kafka ブローカーの想定されるバージョンが実際にイメージに含まれているかどうかを検証できません。所定のイメージが所定の Kafka バージョンに対応することを必ず確認してください。

23.5.4. Kafka ブローカーおよびクライアントアプリケーションのアップグレード

AMQ Streams Kafka クラスターを、サポートされている最新の Kafka バージョンおよび インターブローカープロトコルバージョン にアップグレードします。

クライアントをアップグレードするストラテジー を選択する必要もあります。Kafka クライアントは、この手順の 6 でアップグレードされます。

前提条件

  • Cluster Operator が稼働しています。
  • AMQ Streams Kafka クラスターをアップグレードする前に、Kafka リソースの Kafka.spec.kafka.config プロパティーに、新しい Kafka バージョンでサポートされていない設定オプションが含まれてい ない ことを確認してください。

手順

  1. Kafka クラスター設定を更新します。

    oc edit kafka <my_cluster>
    Copy to Clipboard Toggle word wrap
  2. 設定されている場合は、inter.broker.protocol.version および log.message.format.version プロパティーが 現在の バージョンに設定されていることを確認してください。

    たとえば、Kafka バージョン 3.5.0 から 3.6.0 にアップグレードする場合、現在のバージョンは 3.5 です。

    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.5.0
        config:
          log.message.format.version: "3.5"
          inter.broker.protocol.version: "3.5"
          # ...
    Copy to Clipboard Toggle word wrap

    log.message.format.version および inter.broker.protocol.version が設定されていない場合、AMQ Streams では、次のステップの Kafka バージョンの更新後、これらのバージョンを現在のデフォルトに自動的に更新します。

    注記

    log.message.format.version および inter.broker.protocol.version の値は、浮動小数点数として解釈されないように文字列である必要があります。

  3. Kafka.spec.kafka.version を変更して、新しい Kafka バージョンを指定します。現在の Kafka バージョンのデフォルトで log.message.format.version および inter.broker.protocol.version のままにします。

    注記

    kafka.version を変更すると、クラスターのすべてのブローカーがアップグレードされ、新しいブローカーバイナリーの使用が開始されます。このプロセスでは、一部のブローカーは古いバイナリーを使用し、他のブローカーはすでに新しいバイナリーにアップグレードされています。inter.broker.protocol.version を現在の設定のままにしておくと、ブローカーはアップグレード中に相互に通信し続けることができます。

    たとえば、Kafka 3.5.0 から 3.6.0 にアップグレードする場合:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.6.0 
    1
    
        config:
          log.message.format.version: "3.5" 
    2
    
          inter.broker.protocol.version: "3.5" 
    3
    
          # ...
    Copy to Clipboard Toggle word wrap
    1
    Kafka のバージョンが新しいバージョンに変更されます。
    2
    メッセージ形式のバージョンは変更されません。
    3
    ブローカー間のプロトコルバージョンは変更されません。
    警告

    新しい Kafka バージョンの inter.broker.protocol.version が変更された場合は、Kafka をダウングレードできません。ブローカー間プロトコルのバージョンは、__consumer_offsets に書き込まれたメッセージなど、ブローカーによって保存される永続メタデータに使用されるスキーマを判断します。ダウングレードされたクラスターはメッセージを理解しません。

  4. Kafka クラスターのイメージが Kafka.spec.kafka.imageKafka カスタムリソースで定義されている場合、image を更新して、新しい Kafka バージョンでコンテナーイメージを示すようにします。

    Kafka バージョンおよびイメージマッピング を参照してください。

  5. エディターを保存して終了し、ローリング更新の完了を待ちます。

    Pod の状態の遷移を監視して、ローリング更新の進捗を確認します。

    oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'
    Copy to Clipboard Toggle word wrap

    ローリング更新により、各 Pod が新バージョンの Kafka のブローカーバイナリーを使用するようになります。

  6. クライアントのアップグレードに選択したストラテジー に応じて、新バージョンのクライアントバイナリーを使用するようにすべてのクライアントアプリケーションをアップグレードします。

    必要に応じて、Kafka Connect および MirrorMaker の version プロパティーを新バージョンの Kafka として設定します。

    1. Kafka Connect では、KafkaConnect.spec.version を更新します。
    2. MirrorMaker では、KafkaMirrorMaker.spec.version を更新します。
    3. MirrorMaker 2 の場合は、KafkaMirrorMaker2.spec.version を更新します。

      注記

      手動でビルドされたカスタムイメージを使用している場合は、そのイメージを再構築して、最新の AMQ Streams 基本イメージで最新の状態に更新されていることを確認する必要があります。たとえば、Kafka Connect のベースイメージから Docker イメージを作成した 場合は、最新のベースイメージとビルド設定を参照するように Dockerfile を更新します。

  7. アップグレードされたクライアントアプリケーションが新しい Kafka ブローカーで正しく動作することを確認します。
  8. 設定されている場合、新しい inter.broker.protocol.version バージョンを使用するように Kafka リソースを更新します。それ以外の場合は、ステップ 9 に進みます。

    たとえば、Kafka 3.6.0 にアップグレードする場合:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.6.0
        config:
          log.message.format.version: "3.5"
          inter.broker.protocol.version: "3.6"
          # ...
    Copy to Clipboard Toggle word wrap
  9. Cluster Operator によってクラスターが更新されるまで待ちます。
  10. 設定されている場合、新しい log.message.format.version バージョンを使用するように Kafka リソースを更新します。それ以外の場合は、ステップ 10 に進みます。

    たとえば、Kafka 3.6.0 にアップグレードする場合:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.6.0
        config:
          log.message.format.version: "3.6"
          inter.broker.protocol.version: "3.6"
          # ...
    Copy to Clipboard Toggle word wrap
    重要

    Kafka 3.0.0 以降、inter.broker.protocol.version3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。

  11. Cluster Operator によってクラスターが更新されるまで待ちます。

    Kafka リソースのステータスからアップグレードが正常に完了したことを確認 できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat