Kubernetes は、クラウドネイティブ分散オペレーティングシステムの事実上の標準になったと言えます。その最大の利点はスケーラビリティにあります。コンピューティング、ストレージ、ネットワークなど、ユーザーのニーズに応じて柔軟に拡張できます。 チーム内で Kubernetes ストレージのトピックを共有しました。内容は比較的基本的なもので、全員の思考を刺激することを目的としていました。今日はこれらの共有を原稿の形でまとめたいと思います。読み返してみたら、たくさんのことを学べたと感じました。他の友達にも役立つと嬉しいです。 この記事は長いため、Kubernetes ストレージの基本的な概念と用語から始めます。 Kubernetes ストレージが重要な理由は何ですか?開発エンジニアにとって、コンテナは誰にとっても馴染み深いものであるはずです。 コンテナ 本質的にステートレスであり、コンテンツは極めて短い時間だけ存在します。コンテナを閉じると、元の状態に戻ります。つまり、コンテナがアクティブな間にアプリケーションによって生成されたデータは失われます。 ストレージはアプリケーションを支える基礎と言えます。データが消えてしまうとアプリケーションは正常に動作しなくなるため、この状況はアプリケーションにとって絶対に受け入れられません。 アプリケーションが徐々にクラウド ネイティブに移行するにつれて、Kubernetes プラットフォーム上でアプリケーションが遭遇するストレージの問題を見てみましょう。 1. アプリケーションの構成各アプリケーションには独自の構成があり、柔軟性を保つために構成をコードから切り離すのが一般的です。アプリケーション コードはミラーリングされていますが、Kubernetes では構成はどのように処理されるのでしょうか? 2. コンテナ間のデータ通信Pod は Kubernetes における最小のデプロイメント ユニットです。 Pod 内の複数のコンテナ間でデータを共有するにはどうすればよいでしょうか?あるいは、マイクロサービス アーキテクチャでは異なるノード上の Pod データはどのように通信するのでしょうか? 3. コンテナ内のデータの永続性ポッドは非常に壊れやすいです。 Pod がクラッシュして再スケジュールされた場合、アプリケーションによって古い Pod に書き込まれたデータを取得できますか? 4. サードパーティのストレージサービスを統合するたとえば、独自のストレージ サービスがある場合、または顧客が国内のストレージ システムの使用を要求している場合、それらを Kubernetes ストレージ システムに統合する方法はありますか? 解決上記の問題を解決するために、Kubernetes はボリュームという抽象概念を導入しました。ユーザーはリソースと宣言型 API を通じて意図を記述するだけで、Kubernetes はユーザーのニーズに基づいて特定の操作を完了します。 Volume という言葉はもともとオペレーティング システムの用語に由来しており、Docker にも同様の概念があります。 Kubernetes の世界では、ボリュームは、ポッドとコンテナ間でデータを共有および永続化するためのプラグ可能な抽象化レイヤーを指します。 この記事では、Kubernetes におけるボリュームの概念とアプリケーションについて説明します。 Kubernetes ストレージ システムストレージ技術には多くの種類があることはご存じのとおりです。できるだけ多くのストレージ テクノロジとの互換性を確保するために、Kubernetes は多くのプラグインをプリインストールしており、ユーザーはビジネス ニーズに応じて選択することができます。 このコマンドは、Kubernetes Pod 内のボリューム定義の詳細な説明(フィールドや使用法を含む)を返します。これにより、ユーザーは Pod 内でボリュームを定義する方法を理解することができます。 上記のコマンドを使用すると、Kubernetes がデフォルトで少なくとも 20 種類のストレージ ボリュームをサポートしており、さまざまなストレージ要件を満たすことができることがわかります。この機能により、Kubernetes はストレージに関して非常に柔軟になり、さまざまなアプリケーションのストレージ要件に適応できるようになります。 次の表では、ストレージ プラグインを 2 つのカテゴリに分類しています。この表には最も一般的に使用されるボリュームタイプのみがリストされていますが、他のタイプについては公式ドキュメント「永続ボリュームの種類」[1]に記載されています。 In-Tree Volume[2]の実装に興味がある方は、ソースコードを閲覧することができます。 写真 では、In-Tree と Out-Of-Tree の違いは何でしょうか?まずは文字どおりの意味から両者の違いを大まかに理解し、後ほどそれらの違いについて詳しく紹介します。 In-Tree は、実装コードを Kubernetes コード リポジトリに配置することとして理解できます。一方、Out-Of-Tree は、コード実装が Kubernetes 自体から分離され、Kubernetes コード リポジトリの外部に保存されることを意味します。 まとめ一見すると、Kubernetes はサポートするストレージ ボリュームの種類が多すぎるため、それらに慣れていないユーザーは圧倒されるかもしれません。ただし、要約すると、主に 2 つのタイプがあります。
非永続ボリュームと永続ボリュームこれら 2 つの巻の主な違いを紹介する前に、類似点を述べる必要があると思います。 1. 使用方法
2. ホストディレクトリ ボリューム タイプに関係なく、Kubelet は現在の HOST にスケジュールされている Pod のボリューム ディレクトリを次の形式で作成します。 #1。非永続ボリューム
音量 上記のアーキテクチャ図からわかるように、ボリュームは Pod に囲まれているため、そのライフサイクルはそれをマウントする Pod と一致します。何らかの理由でポッドが破棄されると、ボリュームも削除されますが、少なくともそのライフサイクルは、ポッド内で実行されているコンテナの存続時間よりも長くなります。 考える以下はKubernetes公式ドキュメントにおけるPodライフサイクルの説明です。 ポッドは、その存続期間中に 1 回だけスケジュールされます。ポッドがノードにスケジュール(割り当て)されると、ポッドは停止または終了されるまでそのノード上で実行されます。 restartPolicy != Never で設定された Pod の場合、例外が発生して Pod が再起動しても、Pod 自体は再スケジュールされません。したがって、ポッドの UID は変更されておらず、削除もされていないため、これらのボリュームのデータはそのまま残ります。 ⚠️ また、ここで説明しておく必要があるのは、再起動後、ポッドの背後にあるコンテナは完全に新しくなりますが、現在のホストには古いコンテナがまだ存在しているということです。終了状態にあります。私の言っている意味は皆さんも理解していただけると思います。つまり、古いコンテナがアクティブな場合でも、コンテナの読み取り/書き込みレイヤーを介して、通常のディレクトリにユーザーが書き込んだデータを取得できる可能性があります。 Kubelet GC 回復メカニズムによってクリーンアップされない限り。 2. 永続ボリューム
永続ボリューム 明らかに、上記のアーキテクチャから、永続ボリュームは Pod とは独立して存在するため、そのライフサイクルは Pod とは無関係であることがわかります。 ConfigMap/Secret & EmtpyDir & HostPath以下は、Kubernetes プラットフォームで一般的に使用されるストレージ ボリュームの簡単なレビューです。まず、ユーザーの観点からこれらのストレージ ボリュームがどのように使用されるかを見てみましょう。 これまでの記事でこれら 3 つのタイプについて説明しましたが、ストレージの概念については特に強調していませんでした。これらをまとめると、適用可能なシナリオをより深く理解できると思います。 ConfigMap/Secret 適用可能なシナリオConfigMap と Secret は、通常、アプリケーション構成を保存するために使用され、Kubernetes プラットフォームが構成とコードを分離するための一般的な手段である 2 つのリソースです。 ベストプラクティス写真 1つのコードベース、複数のデプロイメント ストレージボリュームとして使用できます。以下は一般的な使用法です。画像をクリックすると詳細内容に直接ジャンプします。 ConfigMapの一般的な使用法 EmtpyDir 適用可能なシナリオEmtpyDir は非常によく使われるボリュームと言えます。名前が示すように、最初に作成されたときは空のディレクトリであり、通常は Pod 内の複数のコンテナ間でデータを共有するために使用されます。非永続ボリュームに属します。 Pod が削除されると、EmtpyDir に生成されたデータもクリアされます。 ベストプラクティス次のようなアーキテクチャを例に挙げてみましょう。ここでは、Init Container がデータ準備コンテナーとして使用され、コンテンツの書き込みを担当します。アプリケーション コンテナーはメイン アプリケーションのコンテナーであり、データの読み取りを担当します。 この例は、Kubernetes コンテナ オーケストレーションの魅力を示すだけでなく、リッチ コンテナのソリューションでもあります。詳細を表示するには画像をクリックしてください。シナリオ03 EmtpyDirボリュームを使用してコンテナ間でデータを通信する サイドカー コンテナーが EmtpyDir を介して別のコンテナーのログ ファイルを読み取る、別の一般的な例を見てみましょう。 ご覧のとおり、Pod 内の count コンテナのログは stdout として出力されません。次のコマンドを使用した場合、ログを取得できません。 ただし、サイドカー コンテナーを使用してログ ファイルを読み取り、stdout として再度出力することができます。 もちろん、このログ処理方法は、ホスト マシン上に 2 つの同一ログが形成されることになり、実際にはまったく不要であるため、決して最善ではありません。しかし、emptyDir の適用可能なシナリオを理解しやすくするために、ここで例を挙げるのが適切だと思います。 HostPath 適用可能なシナリオHostPath は、ホスト ノードのファイル システム上のファイルまたはディレクトリを Pod に直接マウントします。また、ボリューム データはホスト ノードのファイル システムに保存されることにも注意してください。このタイプのボリュームは、ボリューム内のコンテンツが特定のノードにのみ保持されるため、ほとんどのアプリケーションには適していません。ポッドが再割り当てされ、別のノードにスケジュールされると、元のデータは引き継がれません。 したがって、非常に特殊なニーズがあり、何をしているのかを理解している場合を除き、一般的には hostpath を使用することはお勧めしません。それは意味がありますか? ベストプラクティスHostPath は通常、DaemonSet と組み合わせて使用されます。前述のログ収集を例に挙げてみましょう。各ノードでロギング エージェント (Fluentd) が実行され、ホスト上のコンテナ ログ ディレクトリがマウントされ、現在のホスト ログが収集されます。 今回ご紹介するもう 1 つのトピックは、各種ストレージ プラグインのエージェント コンポーネント (CSI) です。このコンポーネントも各ノードで実行して、リモート ストレージ ディレクトリをこのノードにマウントし、コンテナのボリューム ディレクトリを操作する必要があります。 もちろん、他にも多くの用途があります。これらは自分で発見していただければわかると思いますので、詳しくは紹介しません。 考えるHostPath + NodeAffinity は疑似永続性を実現でき、PV 機能を備えているように見えますが、ホスト マシンのディスクがいっぱいになりやすく、最終的に現在のノードが NotReady 状態になるため、この方法を使用することはお勧めしません。 さらに、クラスターのセキュリティ上の理由から、通常は HostPath のマウントを制限します。結局のところ、HostPath Volume には多くのセキュリティ リスクがあります。制限されていない場合、ユーザーはノードに対して何でも実行できます。 PV、PVC、ストレージクラスPV と PVC は、Kubernetes ストレージ システムにおいて非常に重要な 2 つのリソースです。これらは主に責任の分離と分離を実現するために導入されます。 言い換えれば、アプリケーション開発者はストレージ設備の詳細を気にする必要はなく、アプリケーションのストレージ リソースの需要にのみ焦点を当てる必要があります。 実は、もう一つ理由があります。開発者としては、クラスターで使用できるボリューム タイプがわかりません。また、ストレージ関連の構成は実に複雑です。ストレージに関わる知識分野は非常に専門的です。諺にあるように、専門家に専門的な仕事を任せると、仕事の効率がより良くなります。 まず、これら 2 つのリソースの公式の解釈を見てみましょう。 用語集1. 永続ボリューム(PV)クラスター レベルのリソースは、クラスター管理者または外部プロビジョニング コンポーネントによって作成されます。 永続的なストレージ データ ボリュームを記述します。 2. 永続ボリュームクレーム (PVC)名前空間レベルのリソースは、開発者または StatefulSet コントローラー (VolumeClaimTemplate に基づく) によって作成されます。汎用エフェメラル ボリュームは、ライフサイクルがポッドのライフサイクルと一致する一時ストレージ ボリュームも作成します。 これは、ボリュームの容量やアクセス モードなど、永続ストレージに対するポッドの要件のプロパティを記述し、基盤となるストレージ リソースの抽象的な表現を提供します。 PVC を使用すると、クラスター間で Pod を移行できます。 3. ストレージクラスクラスター管理者によって作成されるクラスター レベルのリソースは、PV を動的にプロビジョニングおよび構成する機能を定義します。ストレージ クラスは、PV を動的に割り当てるメカニズムを提供し、PVC 要求に基づいて PV を自動的に作成し、動的なストレージのプロビジョニングと管理を実装します。 StorageClass のパラメータ フィールドについては言及する価値があります。ストレージクラスに関連するパラメータを指定するために使用されるオプションのフィールドですが、CSI ドライバーを開発するときに非常に役立ちます。詳細については、「シークレットと資格情報[3]」を参照してください。これらのパラメータの正確な意味は、使用されるストレージ プラグインとストレージ ベンダーによって異なります。 出典: docker.com どのように理解しますか?Kubernetes に触れたばかりの人にとっては、用語の定義だけでは理解しにくいかもしれません。 私も最初は、これらのリソースが何なのか、どのように使用すればいいのか、どのようなシナリオに適しているのかがわからず混乱しました。 それは問題ではありません。次に、これらのリソースをさまざまな角度から解釈し、全員が概念を確立できるようにしたいと考えています。最後に具体的な使い方を紹介します。 #1。リソースの次元から
PV リソースの .Spec には、ストレージ デバイスに関する詳細情報が格納されます。 PVC はポッドとして考えることができます。
2. 次元と懸念を分けるアプリケーション開発者まず、アプリケーション開発者は PVC リソースのみを扱うということを明確にしておく必要があります。アプリケーションに必要なストレージ容量を知っているのは開発者だけだからです。 Kubernetes では、PVC は永続ストレージの抽象インターフェースとして見ることができます。特定の永続ストアの要件とプロパティについて説明しますが、実際のストレージ実装については責任を負いません。 PV は特定のストレージの実装を担当し、PVC にバインドされます。 NFS や Ceph など、ストレージの背後にある特定の実装方法について心配する必要はなく、必要なストレージ サイズとアクセス モードというニーズを明確にするだけで済みます。これは私たちが気にかける必要のあることではありません。 この分離設計により、基盤となるストレージ テクノロジの選択と実装を気にすることなくアプリケーション開発に集中でき、効率性と柔軟性が向上します。 運用・保守担当者クラスターの運用および保守担当者だけがクラスターにどのようなストレージが提供されているかを知っているため、PV リソースは通常、運用および保守担当者によって作成されます。これは簡単に理解できるはずです。 プロビジョニング一般的に、クラスター内で PV を提供する方法は 2 つあります。これら 2 つの方法の長所と短所を見てみましょう。 1. 静的プロビジョニング静的プロビジョニング 使用プロセス
考えるこのアプローチの利点は非常に明白です。クラスター内のすべてのストレージ リソースが運用と保守の管理下にあると言えます。 しかし、静的 PV を提供するプロセスでは、運用および保守担当者が PV リソースを作成する必要があり、これによってもいくつかの問題が発生します。
では、これをどのように自動化するのでしょうか?これは、動的なストレージ構成プロセスを導入するストレージ クラスの概念に依存しています。 2. 動的プロビジョニング動的プロビジョニング 使用プロセス上記のフローチャートから、プロセス全体に管理者の介入が欠けていることが明らかです。
考えるPVを自動作成します。このモードでは、デプロイメントの動作方法が完全に変わります。 実は、運用・保守担当者の解放だけではなく、DevOps の推進にも大きな助けとなります。 PVとPVCの結合条件✔️ StorageClass: PV と PVC は同じ StorageClass に属している必要があります。 ✔️ アクセス モード: PV と PVC のアクセス モードは互換性がある必要があります。アクセス モードは、ポッドがストレージ ボリュームにアクセスする方法を定義します。 ✔️ 容量: PVC の要求された容量は PV の容量を超えることはできません。 PVC は特定のサイズのストレージ ボリュームを要求できますが、PV には PVC の要求を満たすのに十分な容量が必要です。 ✔️ セレクター: PV は 1 つ以上のラベル セレクターを定義でき、PVC はラベル セレクターを通じて一致する PV を選択できます。 PVC のセレクターは、バインドする PV のラベル セレクターと一致する必要があります。 これらのバインド条件が満たされると、Kubernetes は PVC を対応する PV に自動的にバインドし、永続ストレージの割り当てと使用を有効にします。 考えるKubernetes では、PV と PVC の間には 1 対 1 の関係があります。 1 つの PV は 1 つの PVC にのみバインドできます。ただし、複数の Pod が同じ PVC を共有できるため、その PVC によって提供される永続ストレージを使用できます。実際、Pod はノードによって追い出されるなど、さまざまな理由でシャットダウンされ、サービスを提供できなくなる可能性があるため、本番環境では直接使用しません。 一般的には、Pod の複数のレプリカを管理できる Deployment を使用します。次のシナリオでは、同じ PVC をマウントする 3 つの Pod レプリカがあります。 PVC に読み取り専用権限のみがある場合は、問題はありません。 展開 ただし、PVC に読み取りおよび書き込み権限があり、3 つの Pod レプリカによって共有されている場合、データの不整合の問題が発生する可能性があります。たとえば、競合状態が発生する可能性があります。2 つ以上の Pod が同時に同じファイルに書き込むと、データの上書きやデータの不整合が発生する可能性があります。 それで、この問題を解決する方法はあるのでしょうか?これは StatefulSet ワークロードであり、複数のレプリカの概念も備えています。 違いは、次の図に示すように、volumeClaimTemplatesを定義して、レプリカごとに新しいPVCを自動的に作成できることです。 ステートフルセット もちろん、実際のシナリオは、特に分散アプリケーションの場合は、より複雑になることがよくあります。たとえば、マスターとスレーブの関係では、StatefulSet によって提供される Pod の識別や順序などの機能を考慮する必要があります。 PVC を作成する最後の方法である、汎用一時ボリュームを見てみましょう。 Generic Ephemeral Volume 内のデータは、コンテナのライフサイクル中にのみ保持されることに注意してください。 Pod が削除または再起動されると、同時に生成された PVC も削除されます。したがって、Generic Ephemeral Volume は、キャッシュ ファイルや一時構成ファイルなど、コンテナーのライフサイクル中に一時的なデータを保持する必要があるシナリオに適しています。 デフォルトのストレージクラス管理者は、クラスター内のストレージ クラスにデフォルト ストレージ クラスとして注釈を付けることができます。これは、ストレージ クラスが明示的に指定されていない場合に使用されるデフォルト ストレージ クラスを指定するために使用される、事前定義された特別なストレージ クラスです。 コンテナストレージインターフェースKubernetes プラットフォーム自体はさまざまなストレージ プラグインをサポートしていますが、ユーザーのニーズが高まっているため、これらのプラグインではすべての要件を満たすことができないことがよくあります。例えば、顧客から当社の PaaS プラットフォームを国内のストレージと統合することを求められた場合、どのように対応すればよいでしょうか? さらに、これらのストレージ プラグインは基本的にツリー内にあります。プラグインにパッチを適用する必要がある場合、現在のモードではテストとメンテナンスに不便が生じます。 ここで、基本的にはプロトコル標準のセットを定義するだけのコンテナ ストレージ インターフェイス (CSI) について説明しておく必要があります。サードパーティのストレージ プラグインがこれらの統合インターフェースを実装している限り、ユーザーが Kubernetes のコア コードに触れることなく Kubernetes に接続できます。 適応作業は、コンテナ オーケストレーション システム (Kubernetes など) とストレージ プロバイダー (SP) によって行われます。 CO は gRPC を介して CSI プラグインと通信します。 写真 CSI は実際には非常に複雑で、非常に多くのコンポーネントが関係します。 CSI の動作原理とそれが直面する課題を紹介する記事を後ほど書く予定です。 最後にこれらの基本的な概念を理解することで、アプリケーションの永続ストレージのニーズを満たすように Kubernetes でストレージ リソースを正しく構成および管理できるようになります。 参考文献 [1]永続ボリュームの種類: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes [2]ツリー内ボリューム: https://github.com/kubernetes/kubernetes/tree/master/pkg/volume [3]シークレットと認証情報: https://kubernetes-csi.github.io/docs/secrets-and-credentials.html |
<<: MinIO と Grafana Mimir を使用してインジケーターの永続ストレージを実装する
>>: Kubernetes コンテナ ランタイム インターフェース CRI
ニュース追跡最終レポートインデックス日付: 2012年7月3日版:A20「深センニュース」タイトル:...
justhost.asia は現在、米国中部のダラス データ センターの VPS を 50% 割引で...
ウェブマスターとして、最も気にするのは記事の包含とキーワードのランキングです。しかし、記事が包含され...
業界関係者は、美団がパブリッククラウド戦略とビジネスを放棄し、社内サービス(つまり社内使用)に切り替...
中国の旧正月まであと1ヶ月ちょっとです。ここ数日、専門家は皆、Googleは長い間PRを更新しないだ...
優れたウェブサイトを運営するウェブマスターは、自分のウェブサイト構築を評価する際に、多くの認識を持っ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますウェブサイ...
タイトルはユーザーにとって最も重要なメタデータであり、これはまさに Google Play ディレク...
「企業は急速な発展の過程で、徐々に洗練された管理を強化し、効率を高め、コストを削減すると同時に、顧客...
主要なフォーラム、特にウェブマスター フォーラムをすべて調べた結果、Guardian は非常に一般的...
[[425938]] Velero (https://velero.io) は、Kubernetes...
今日、モノのインターネットの応用はますます広範囲に広がっていますが、それには企業の視点が必要です。こ...
数日前、私のWeChatパブリックアカウントのフォロワーが、最近の面接について不満を述べるメッセージ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っています対外貿易ウ...
クラウド管理プラットフォームを評価する際、IT 意思決定者は、プラットフォームが便利な主要機能を備え...