23.5. Kafka のアップグレード
Cluster Operator を 2.6 にアップグレードした後、次にすべての Kafka ブローカーをサポートされる最新バージョンの Kafka にアップグレードします。
Kafka のアップグレードは、Kafka ブローカーのローリング更新によって Cluster Operator によって実行されます。
Cluster Operator は、Kafka クラスターの設定に基づいてローリング更新を開始します。
Kafka.spec.kafka.config に以下が含まれている場合 | Cluster Operator によって開始されるもの |
|---|---|
|
|
単一のローリング更新。更新後、 |
|
| 2 つのローリング更新 |
|
| 2 つのローリング更新 |
Kafka 3.0.0 以降、inter.broker.protocol.version が 3.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 バージョンの違いを示しています。
| 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.config の inter.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 バージョンでサポートされていない設定オプションが含まれてい ない ことを確認してください。
手順
Kafka クラスター設定を更新します。
oc edit kafka <my_cluster>
oc edit kafka <my_cluster>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定されている場合は、
inter.broker.protocol.versionおよびlog.message.format.versionプロパティーが 現在の バージョンに設定されていることを確認してください。たとえば、Kafka バージョン 3.5.0 から 3.6.0 にアップグレードする場合、現在のバージョンは 3.5 です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow log.message.format.versionおよびinter.broker.protocol.versionが設定されていない場合、AMQ Streams では、次のステップの Kafka バージョンの更新後、これらのバージョンを現在のデフォルトに自動的に更新します。注記log.message.format.versionおよびinter.broker.protocol.versionの値は、浮動小数点数として解釈されないように文字列である必要があります。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 にアップグレードする場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告新しい Kafka バージョンの
inter.broker.protocol.versionが変更された場合は、Kafka をダウングレードできません。ブローカー間プロトコルのバージョンは、__consumer_offsetsに書き込まれたメッセージなど、ブローカーによって保存される永続メタデータに使用されるスキーマを判断します。ダウングレードされたクラスターはメッセージを理解しません。Kafka クラスターのイメージが
Kafka.spec.kafka.imageのKafkaカスタムリソースで定義されている場合、imageを更新して、新しい Kafka バージョンでコンテナーイメージを示すようにします。Kafka バージョンおよびイメージマッピング を参照してください。
エディターを保存して終了し、ローリング更新の完了を待ちます。
Pod の状態の遷移を監視して、ローリング更新の進捗を確認します。
oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローリング更新により、各 Pod が新バージョンの Kafka のブローカーバイナリーを使用するようになります。
クライアントのアップグレードに選択したストラテジー に応じて、新バージョンのクライアントバイナリーを使用するようにすべてのクライアントアプリケーションをアップグレードします。
必要に応じて、Kafka Connect および MirrorMaker の
versionプロパティーを新バージョンの Kafka として設定します。-
Kafka Connect では、
KafkaConnect.spec.versionを更新します。 -
MirrorMaker では、
KafkaMirrorMaker.spec.versionを更新します。 MirrorMaker 2 の場合は、
KafkaMirrorMaker2.spec.versionを更新します。注記手動でビルドされたカスタムイメージを使用している場合は、そのイメージを再構築して、最新の AMQ Streams 基本イメージで最新の状態に更新されていることを確認する必要があります。たとえば、Kafka Connect のベースイメージから Docker イメージを作成した 場合は、最新のベースイメージとビルド設定を参照するように Dockerfile を更新します。
-
Kafka Connect では、
- アップグレードされたクライアントアプリケーションが新しい Kafka ブローカーで正しく動作することを確認します。
設定されている場合、新しい
inter.broker.protocol.versionバージョンを使用するように Kafka リソースを更新します。それ以外の場合は、ステップ 9 に進みます。たとえば、Kafka 3.6.0 にアップグレードする場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Cluster Operator によってクラスターが更新されるまで待ちます。
設定されている場合、新しい
log.message.format.versionバージョンを使用するように Kafka リソースを更新します。それ以外の場合は、ステップ 10 に進みます。たとえば、Kafka 3.6.0 にアップグレードする場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Kafka 3.0.0 以降、
inter.broker.protocol.versionが3.0以上に設定されていると、log.message.format.versionオプションは無視されるため、設定する必要はありません。Cluster Operator によってクラスターが更新されるまで待ちます。