Kubernetes 上の Kafka は優れていますか?

こんにちは、ハブル！

かつて、私たちはこのトピックをロシア市場に初めて紹介しました。 カフカ そして続けます フォローする その発展のために。 特に、Kafka と Kubernetes。 観察可能（そして非常に注意深い） 記事 このトピックは、Gwen Shapira の執筆のもと、昨年 XNUMX 月に Confluent ブログで公開されました。 今日は、ヨハン・ガイガーによる XNUMX 月の最近の記事に注目していただきたいと思います。この記事は、タイトルに疑問符がないわけではありませんが、興味深いリンクを本文に添えて、より実質的な方法でこのトピックを考察しています。 できれば「カオスモンキー」の意訳をお許しください！

導入

Kubernetes はステートレスなワークロードを処理するように設計されています。 通常、このようなワークロードはマイクロサービス アーキテクチャの形式で提示され、軽量で水平方向に拡張性が高く、12 要素アプリケーションの原則に従い、サーキット ブレーカーやカオス モンキーと連携できます。

一方、Kafka は基本的に分散データベースとして機能します。 したがって、動作するときに状態を処理する必要があり、マイクロサービスよりもはるかに重いです。 Kubernetes はステートフル ロードをサポートしていますが、Kelsey Hightower が XNUMX つのツイートで指摘しているように、ステートフル ロードは注意して扱う必要があります。

Kubernetes をステートフル ワークロードに組み込むと、RDS に匹敵するフルマネージド データベースになると考える人もいます。 これは間違っています。 おそらく、十分に努力してコンポーネントを追加し、SRE エンジニアのチームを引き付ければ、Kubernetes 上に RDS を構築できるでしょう。

私は常に、Kubernetes でステートフル ワークロードを実行するときは細心の注意を払うことをお勧めします。 「Kubernetes でステートフル ワークロードを実行できますか?」と尋ねるほとんどの人は、Kubernetes について十分な経験がなく、多くの場合、質問しているワークロードについても十分な経験がありません。

では、Kubernetes 上で Kafka を実行する必要があるでしょうか? 逆質問: Kafka は Kubernetes なしでより適切に動作しますか? そのため、この記事では、Kafka と Kubernetes がどのように相互補完するのか、また、これらを組み合わせることでどのような落とし穴が生じる可能性があるのか​​を強調したいと思います。

完成時期

基本的なこと、つまりランタイム環境自体について話しましょう

プロセス

Kafka ブローカーは CPU に優しいです。 TLS ではオーバーヘッドが発生する可能性があります。 ただし、Kafka クライアントは暗号化を使用すると CPU の使用量が増える可能性がありますが、これはブローカーには影響しません。

メモリ

Kafka ブローカーはメモリを消費します。 JVM ヒープ サイズは通常 4 ～ 5 GB に制限されていますが、Kafka はページ キャッシュを非常に頻繁に使用するため、大量のシステム メモリも必要になります。 Kubernetes では、コンテナーのリソースとリクエストの制限をそれに応じて設定します。

データストア

コンテナ内のデータ ストレージは一時的なものであり、再起動するとデータが失われます。 Kafka データの場合はボリュームを使用できます emptyDirと同様の効果が得られます。完了後にブローカーのデータは失われます。 メッセージは引き続き他のブローカーにレプリカとして保存できます。 したがって、再起動後、障害が発生したブローカーはまずすべてのデータをレプリケートする必要があり、このプロセスには時間がかかることがあります。

このため、長期データ ストレージを使用する必要があります。 XFS ファイル システム、より正確には ext4 を使用した非ローカルの長期ストレージにします。 NFS は使用しないでください。 私はあなたに警告しました。 NFS バージョン v3 または v4 は機能しません。 つまり、NFS の「愚かな名前変更」問題によりデータ ディレクトリを削除できない場合、Kafka ブローカーはクラッシュします。 まだあなたを納得させていない場合は、慎重に この記事を読む。 Kubernetes が再起動または再配置後に新しいノードをより柔軟に選択できるように、データ ストアは非ローカルである必要があります。

Сеть

ほとんどの分散システムと同様に、Kafka のパフォーマンスは、ネットワーク遅延を最小限に抑え、帯域幅を最大限に保つことに大きく依存します。 可用性が低下するため、同じノード上ですべてのブローカーをホストしようとしないでください。 Kubernetes ノードに障害が発生すると、Kafka クラスター全体に障害が発生します。 また、Kafka クラスターをデータセンター全体に分散させないでください。 Kubernetes クラスターについても同様です。 この場合の適切な妥協策は、別のアベイラビリティ ゾーンを選択することです。

設定

定期マニフェスト

Kubernetes Web サイトには、 とても良いガイド マニフェストを使用して ZooKeeper を構成する方法について説明します。 ZooKeeper は Kafka の一部であるため、ここから Kubernetes のどの概念が適用されるかを理解するのに適しています。 これを理解すると、同じ概念を Kafka クラスターで使用できるようになります。

• 下に: ポッドは、Kubernetes でデプロイ可能な最小単位です。 ポッドにはワークロードが含まれており、ポッド自体はクラスター内のプロセスに対応します。 ポッドには XNUMX つ以上のコンテナが含まれます。 アンサンブル内の各 ZooKeeper サーバーと Kafka クラスター内の各ブローカーは、別のポッドで実行されます。
• ステートフルセット: StatefulSet は、複数のステートフル ワークロードを処理する Kubernetes オブジェクトであり、そのようなワークロードには調整が必要です。 StatefulSet は、ポッドの順序とその一意性に関する保証を提供します。
• ヘッドレスサービス: サービスを使用すると、論理名を使用してクライアントからポッドを切り離すことができます。 この場合、Kubernetes は負荷分散を担当します。 ただし、ZooKeeper や Kafka などのステートフル ワークロードを操作する場合、クライアントは特定のインスタンスと通信する必要があります。 ここでヘッドレス サービスが役に立ちます。この場合、クライアントには論理名が残りますが、ポッドに直接接続する必要はありません。
• 長期保管量: これらのボリュームは、前述の非ローカル ブロック永続ストレージを構成するために必要です。

На ヨリアン Kubernetes で Kafka を使い始めるのに役立つマニフェストの包括的なセットを提供します。

ヘルムチャート

Helm は Kubernetes のパッケージ マネージャーであり、yum、apt、Homebrew、Chocolatey などの OS パッケージ マネージャーと比較できます。 これにより、Helm チャートに記述された事前定義されたソフトウェア パッケージを簡単にインストールできます。 適切に選択された Helm チャートにより、Kubernetes で Kafka を使用するためにすべてのパラメーターを適切に構成する方法という難しいタスクが簡単になります。 Kafka の図はいくつかあります。公式のものは次の場所にあります。 保育器の状態でからのものがあります。 ジャンクショ​​ン、もう一つ - から Bitnami.

演算子

Helm には特定の欠点があるため、別のツールである Kubernetes オペレーターがかなりの人気を集めています。 オペレーターは、Kubernetes 用のソフトウェアをパッケージ化するだけでなく、そのようなソフトウェアのデプロイと管理も可能にします。

Всписке 素晴らしいオペレーター Kafka の XNUMX つの演算子について説明します。 それらの中の一つ - ストリムジ。 Strimzi を使用すると、Kafka クラスターを数分で簡単に起動して実行できます。 実質的に構成は必要ありません。さらに、オペレーター自体が、クラスター内のポイントツーポイント TLS 暗号化などのいくつかの優れた機能を提供します。 Confluent は次のサービスも提供します 自身のオペレーター.

Производительность

Kafka インスタンスのベンチマークを行ってパフォーマンスをテストすることが重要です。 このようなテストは、問題が発生する前に潜在的なボトルネックを見つけるのに役立ちます。 幸いなことに、Kafka はすでに XNUMX つのパフォーマンス テスト ツールを提供しています。 kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh。 積極的に活用してください。 参考までに、に記載されている結果を参照してください。 この郵便受け ジェイ・クレップス、または焦点を当てる このレビュー ステファン・マーレクのAmazon MSK。

オペレーション

監視

システムの透明性は非常に重要です。そうでないと、システム内で何が起こっているのか理解できなくなります。 現在、クラウド ネイティブ スタイルでメトリクスベースの監視を提供する堅牢なツールキットが存在します。 この目的でよく使用される XNUMX つのツールは、Prometheus と Grafana です。 Prometheus は、JMX エクスポーターを使用して、すべての Java プロセス (Kafka、Zookeeper、Kafka Connect) から最も簡単な方法でメトリクスを収集できます。 cAdvisor メトリクスを追加すると、Kubernetes でリソースがどのように使用されるかをより完全に理解できます。

Strimzi には、Kafka 用の Grafana ダッシュボードの非常に便利な例があります。 たとえば、複製が不十分なセクターやオフラインのセクターに関する主要なメトリクスを視覚化します。 そこではすべてが非常に明確です。 これらのメトリクスは、リソース使用率とパフォーマンス情報、および安定性指標によって補完されます。 したがって、基本的な Kafka クラスター監視を無料で利用できます。

出所： streamzi.io/docs/master/#kafka_dashboard

これらすべてを、クライアント監視 (コンシューマとプロデューサーに関するメトリクス) およびレイテンシ監視 (これについては、 バロー) およびエンドツーエンドの監視 - この用途向け カフカモニター.

ロギング

ロギングも重要なタスクです。 Kafka インストール内のすべてのコンテナがログに記録されていることを確認してください stdout и stderrまた、Kubernetes クラスターがすべてのログを中央のログ インフラストラクチャに集約していることを確認します。 Elasticsearch.

機能テスト

Kubernetes は、liveness プローブと readiness プローブを使用して、ポッドが正常に実行されているかどうかを確認します。 活性チェックが失敗した場合、Kubernetes はそのコンテナを停止し、再起動ポリシーが適切に設定されていれば自動的に再起動します。 準備状況チェックが失敗した場合、Kubernetes はポッドをリクエストの処理から隔離します。 したがって、このような場合、手動による介入はまったく必要なくなり、これは大きな利点となります。

アップデートのロールアウト

StatefulSet は自動更新をサポートしています。RollingUpdate 戦略を選択すると、Kafka の下のそれぞれが順番に更新されます。 このようにして、ダウンタイムをゼロに減らすことができます。

スケーリング

Kafka クラスターのスケーリングは簡単な作業ではありません。 ただし、Kubernetes を使用すると、ポッドを特定の数のレプリカに拡張することが非常に簡単になります。つまり、必要な数の Kafka ブローカーを宣言的に定義できることになります。 この場合、最も難しいのは、スケールアップ後またはスケールダウン前にセクターを再割り当てすることです。 繰り返しになりますが、Kubernetes がこのタスクを支援します。

行政

トピックの作成やセクターの再割り当てなど、Kafka クラスターの管理に関連するタスクは、ポッドでコマンド ライン インターフェイスを開いて既存のシェル スクリプトを使用して実行できます。 ただし、この解決策はあまり美しくありません。 Strimzi は、別の演算子を使用したトピックの管理をサポートしています。 ここには改善の余地があります。

バックアップとリカバリ

現在、Kafka の可用性は Kubernetes の可用性にも依存します。 Kubernetes クラスターが失敗すると、最悪の場合、Kafka クラスターも失敗します。 マーフィーの法則によれば、これは必ず起こり、データは失われます。 この種のリスクを軽減するには、適切なバックアップの概念を用意してください。 MirrorMaker を使用することもできますが、別のオプションとして、このために S3 を使用することもできます。これについては、この記事で説明しています。 役職 ザランドから。

まとめ

中小規模の Kafka クラスターを操作する場合、柔軟性が向上し、オペレーターのエクスペリエンスが簡素化されるため、Kubernetes を使用する価値は間違いなくあります。 機能以外の遅延やスループットの要件が非常に大きい場合は、他の展開オプションを検討した方がよい場合があります。

出所： habr.com