Kubernetes のデータ ストレージ パターン

おい、ハブル！

非常に興味深く役立つ別のリリースをリリースしたことをお知らせします。 книга Kubernetes パターンについて。すべては「」から始まりました。パターン「ブレンダン・バーンズ、ところで、私たちはこの分野の仕事をしています」 沸騰する。今日は、Kubernetes のデータ ストレージ パターンの傾向と詳細について簡単に説明した MinIO ブログの記事をぜひ読んでください。

Kubernetes は、従来のアプリケーション開発とデプロイメントのパターンを根本的に変えました。チームは、Kubernetes クラスター内の複数の環境にわたって、数日でアプリケーションを開発、テスト、デプロイできるようになりました。前世代のテクノロジーを使用したこのような作業には、通常、数か月とは言わないまでも、数週間かかりました。

この高速化は、Kubernetes によって提供される抽象化によって可能になります。つまり、Kubernetes 自体が物理マシンまたは仮想マシンの低レベルの詳細と対話し、ユーザーが必要なプロセッサー、必要なメモリ量、およびコンテナーの数を宣言できるためです。インスタンスなどのパラメータ。 Kubernetes をサポートする巨大なコミュニティとその導入が継続的に拡大しているため、Kubernetes はすべてのコンテナ オーケストレーション プラットフォームの中で大差を付けてリーダーとなっています。

Kubernetes の使用が増えるにつれて、そのストレージ パターンに関する混乱も増えています。.

Kubernetes のパイ (つまり、データ ストレージ) の一部を誰もが奪い合っているため、データ ストレージについて話すとなると、信号は多くのノイズにかき消されてしまいます。
Kubernetes は、アプリケーションの開発、展開、管理のための最新のモデルを具体化しています。この最新のモデルは、データ ストレージを計算から切り離します。 Kubernetes のコンテキストでデタッチメントを完全に理解するには、ステートフル アプリケーションとステートレス アプリケーションとは何か、そしてデータ ストレージがそれにどのように適合するかを理解する必要もあります。ここで、S3 で使用される REST API アプローチには、他のソリューションの POSIX/CSI アプローチに比べて明らかな利点があります。

この記事では、Kubernetes のデータ ストレージ パターンについて説明し、特にステートフル アプリケーションとステートレス アプリケーションの間の議論に触れて、両者の違いとそれがなぜ重要であるかをより深く理解します。本文の残りの部分では、コンテナーと Kubernetes を操作するためのベスト プラクティスを考慮して、アプリケーションとそのデータ ストレージ パターンについて説明します。

ステートレスコンテナ

コンテナーは本質的に軽量で一時的なものです。これらは数秒で簡単に停止、削除、または別のノードにデプロイできます。大規模なコンテナ オーケストレーション システムでは、このような操作が常に発生しており、ユーザーはそのような変化にさえ気づきません。ただし、移動は、コンテナーが配置されているノードに依存関係がない場合にのみ可能です。このようなコンテナは機能すると言われています ステートレス.

ステートフルコンテナ

コンテナーがローカルに接続されたデバイス (またはブロック デバイス) にデータを保存している場合、障害が発生した場合、そのコンテナーが存在するデータ ストアをコンテナー自体とともに新しいノードに移動する必要があります。これは重要です。そうしないと、コンテナ内で実行されているアプリケーションがローカル メディアに保存されているデータにアクセスする必要があるため、適切に機能できなくなります。このようなコンテナは機能すると言われています ステートフル.

純粋に技術的な観点から見ると、ステートフル コンテナを他のノードに移動することもできます。これは通常、コンテナを実行しているすべてのノードに接続された分散ファイル システムまたはブロック ネットワーク ストレージを使用して実現されます。このようにして、コンテナは永続的なデータ ストレージのボリュームにアクセスし、情報はネットワーク全体に配置されたディスクに保存されます。このメソッドを「」と呼びます。ステートフルコンテナアプローチ」とありますが、この記事の残りの部分では、統一のためにそう呼ぶことにします。

一般的なステートフル コンテナのアプローチでは、すべてのアプリケーション ポッドが単一の分散ファイル システム (すべてのアプリケーション データが存在する共有ストレージの一種) に接続されます。いくつかのバリエーションが可能ですが、これは高レベルのアプローチです。

次に、クラウド中心の世界においてステートフル コンテナのアプローチがアンチパターンである理由を見てみましょう。

クラウドネイティブなアプリケーション設計

従来、アプリケーションは情報の構造化ストレージとしてデータベースを使用し、すべての非構造化データまたは半構造化データがダンプされるローカル ディスクまたは分散ファイル システムを使用していました。非構造化データの量が増加するにつれて、開発者は、POSIX はおしゃべりが多すぎてオーバーヘッドが大きく、最終的には本当に大規模なスケールに移行するときにアプリケーションのパフォーマンスを妨げることに気づきました。

これは主に、データ ストレージの新しい標準、つまり主に REST API に基づいて動作し、ローカル データ ストレージの煩わしいメンテナンスからアプリケーションを解放するクラウドベースのストレージの出現に貢献しました。この場合、アプリケーションは効果的にステートレス モードになります (状態がリモート ストレージにあるため)。最新のアプリケーションは、この要素を念頭に置いてゼロから構築されています。原則として、何らかの種類のデータ (ログ、メタデータ、BLOB など) を処理する最新のアプリケーションは、状態がそのストレージ専用のソフトウェア システムに転送されるクラウド指向のパラダイムに従って構築されます。

ステートフル コンテナのアプローチにより、このパラダイム全体がまさに出発点に戻ります。

POSIX インターフェイスを使用してデータを保存することにより、アプリケーションはステートフルであるかのように動作します。このため、アプリケーションは、クラウド中心の設計の最も重要な原則、つまり、受信データに応じてアプリケーション ワーカー スレッドのサイズを変更する機能から逸脱します。 input.load、現在のノードに障害が発生するとすぐに新しいノードに移動する、などです。

この状況を詳しく見てみると、データ ストアを選択する際に、POSIX と REST API のジレンマに何度も直面していることがわかります。ただし、Kubernetes 環境の分散型の性質により、POSIX の問題はさらに悪化しています。特に、

• POSIXはおしゃべりです: POSIX セマンティクスでは、各操作が、操作の状態を維持するのに役立つメタデータおよびファイル記述子に関連付けられている必要があります。これにより、実質価値のない多大なコストが発生します。オブジェクト ストレージ API、特に S3 API はこれらの要件を取り除き、アプリケーションを起動して呼び出しを「忘れる」ことができるようにします。ストレージ システムの応答は、アクションが成功したかどうかを示します。失敗した場合、アプリケーションは再試行できます。
• ネットワーク制限注: 分散システムでは、多数のアプリケーションが同じ接続されたメディアにデータを書き込もうとしている可能性があることが暗示されています。したがって、アプリケーションがデータ転送帯域幅 (メディアにデータを送信するため) をめぐって互いに競合するだけでなく、ストレージ システム自体も物理ディスク間でデータを送信することによってこの帯域幅をめぐって競合します。 POSIX の多弁さにより、ネットワーク呼び出しの数は数倍に増加します。一方、S3 API は、クライアントからサーバーに発信されるネットワーク呼び出しとサーバー内で発生するネットワーク呼び出しを明確に区別します。
• セキュリティ: POSIX セキュリティ モデルは、人間が積極的に参加できるように設計されています。管理者は、ユーザーまたはグループごとに特定のアクセス レベルを設定します。このパラダイムは、クラウド中心の世界に適応するのが困難です。最新のアプリケーションは API ベースのセキュリティ モデルに依存しており、アクセス権はポリシー、サービス アカウント、一時的な資格情報などのセットとして定義されます。
• 管理性: ステートフル コンテナには、ある程度の管理オーバーヘッドがあります。データへの並列アクセスの同期、データの一貫性の確保について話していますが、これにはすべて、どのデータ アクセス パターンを使用するかを慎重に検討する必要があります。追加の開発作業は言うまでもなく、追加のソフトウェアをインストール、監視、構成する必要があります。

コンテナデータストレージインターフェース

Container Storage Interface (CSI) は、Kubernetes ボリューム レイヤーの普及に大きく役立ち、部分的にサードパーティのストレージ ベンダーにアウトソーシングしてきましたが、意図せずして、ステートフル コンテナ アプローチが推奨される方法であるという信念にも貢献しました。 Kubernetes にデータを保存します。

CSI は、Kubernetes 上で実行するレガシー アプリケーションに任意のブロックおよびファイル ストレージ システムを提供するための標準として開発されました。そして、この記事で示したように、ステートフル コンテナ アプローチ (および現在の形式の CSI) が意味をなす唯一の状況は、アプリケーション自体がレガシー システムであり、オブジェクト ストレージ API のサポートを追加できない場合です。 。

CSI を現在の形式で使用すると、つまり最新のアプリケーションを操作するときにボリュームをマウントすると、データ ストレージが POSIX スタイルで編成されているシステムで発生するのとほぼ同じ問題が発生することを理解することが重要です。

より良いアプローチ

この場合、ほとんどのアプリケーションは本質的にステートフルまたはステートレスな作業専用に設計されていないことを理解することが重要です。この動作は、システム全体のアーキテクチャと特定の設計上の選択によって異なります。ステートフル アプリケーションについて少しお話しましょう。

原則として、すべてのアプリケーション データは、いくつかの大まかなタイプに分類できます。

• ログデータ
• タイムスタンプデータ
• 取引データ
• メタデータ
• コンテナイメージ
• BLOB (バイナリ ラージ オブジェクト) データ

これらのデータ型はすべて、最新のストレージ プラットフォームで非常によくサポートされており、これらの特定の形式でデータを配信するように調整されたクラウドネイティブ プラットフォームがいくつかあります。たとえば、トランザクション データとメタデータは、CockroachDB、YugaByte などの最新のクラウドネイティブ データベースに存在できます。コンテナー イメージまたは BLOB データは、MinIO に基づいて Docker レジストリに保存できます。タイムスタンプ データは、InfluxDB などの時系列データベースに保存できます。ここでは、各データ型とその用途については詳しく説明しませんが、一般的な考え方は、ローカル ディスクのマウントに依存する永続的なデータ ストレージを避けることです。

さらに、多くの場合、アプリケーションの一時ファイル ストアとして機能する一時キャッシュ レイヤーを提供することが効果的ですが、アプリケーションは信頼できる情報源としてこのレイヤーに依存すべきではありません。

ステートフルなアプリケーションストレージ

ほとんどの場合、アプリケーションをステートレスに保つと便利ですが、データベース、オブジェクト ストア、キー/バリュー ストアなど、データを保存するように設計されたアプリケーションはステートフルである必要があります。これらのアプリケーションが Kubernetes にデプロイされる理由を見てみましょう。 MinIO を例に挙げますが、同様の原則が他の大規模なクラウドネイティブ ストレージ システムにも当てはまります。

クラウドネイティブ アプリケーションは、コンテナーに固有の柔軟性を最大限に活用するように設計されています。これは、展開される環境について何の仮定も行っていないことを意味します。たとえば、MinIO は内部消去コーディング メカニズムを使用して、ディスクの半分に障害が発生した場合でも動作を継続できる十分な復元力をシステムに提供します。 MinIO は、独自のサーバー側ハッシュと暗号化を使用してデータの整合性とセキュリティも管理します。

このようなクラウド中心のアプリケーションの場合、ローカル永続ボリューム (PV) がバックアップ ストレージとして最も便利です。ローカル PV は生データを保存する機能を提供し、これらの PV 上で実行されるアプリケーションはデータを拡張し、増大するデータ需要を管理するための情報を独立して収集します。

このアプローチは、独自のデータ管理層と冗長性をシステムに導入する CSI ベースの PV よりもはるかにシンプルで、拡張性が大幅に優れています。重要なのは、これらの層は通常、ステートフルになるように設計されたアプリケーションと競合するということです。

データを計算から切り離す強力な動き

この記事では、状態を保存せずにアプリケーションが動作するようにどのように再設定されるか、つまり、データの保存がそのデータ上のコンピューティングから切り離されるかについて説明しました。最後に、この傾向の実例をいくつか見てみましょう。

スパークは、著名なデータ分析プラットフォームであり、従来はステートフルであり、HDFS 上にデプロイされてきました。ただし、Spark がクラウド中心の世界に移行するにつれて、プラットフォームは「s3a」を使用してステートレスで使用されることが増えています。 Spark は s3a を使用して他のシステムに状態を​​転送しますが、Spark コンテナー自体は完全にステートレスで動作します。特にビッグデータ分析分野の他の大手企業プレーヤーは、 Vertica, Teradataの, グリーンプラム また、データ ストレージとその計算の分離にも取り組んでいます。

同様のパターンは、Presto、Tensorflow to R、Jupyter など、他の大規模な分析プラットフォームでも見られます。状態をリモートのクラウド ストレージ システムにオフロードすることで、アプリケーションの管理と拡張がはるかに簡単になります。さらに、アプリケーションをさまざまな環境に移植しやすくなります。

出所： habr.com