Kubernetesストレージ101: データ駆動型のパワーを解き放つKubernetesストレージの概念の簡単な紹介

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 は多くのプラグインをプリインストールしており、ユーザーはビジネス ニーズに応じて選択することができます。

 kubectl explain pod.spec.volumes

このコマンドは、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 つのタイプがあります。

1. 非永続ボリューム（一時ストレージとも呼ばれる）
2. 永続ボリューム

非永続ボリュームと永続ボリューム

これら 2 つの巻の主な違いを紹介する前に、類似点を述べる必要があると思います。

1. 使用方法

• まず、.spec.volumes[]で使用するボリュームタイプを定義します。
• 次に、コンテナの指定された場所にマウントします。.spec.containers[].volumeMounts[]

2. ホストディレクトリ

ボリューム タイプに関係なく、Kubelet は現在の HOST にスケジュールされている Pod のボリューム ディレクトリを次の形式で作成します。

 /var/lib/kubelet/pods/<Pod-UID>/volumes/kubernetes.io~<Volume-Type>/<Volume-Name>

＃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 を介して別のコンテナーのログ ファイルを読み取る、別の一般的な例を見てみましょう。

 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: lqshow/busybox-curl:1.28 args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-sidecar image: lqshow/busybox-curl:1.28 args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} EOF

ご覧のとおり、Pod 内の count コンテナのログは stdout として出力されません。次のコマンドを使用した場合、ログを取得できません。

 kubectl logs -f counter -c count

ただし、サイドカー コンテナーを使用してログ ファイルを読み取り、stdout として再度出力することができます。

もちろん、このログ処理方法は、ホスト マシン上に 2 つの同一ログが形成されることになり、実際にはまったく不要であるため、決して最善ではありません。しかし、emptyDir の適用可能なシナリオを理解しやすくするために、ここで例を挙げるのが適切だと思います。

 kubectl logs -f counter -c count-log-sidecar

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 はポッドとして考えることができます。

1. ポッドはノードリソースを消費し、PVCはPVリソースを消費します。
2. ポッドは特定のレベルのリソース (CPU やメモリなど) を要求でき、PVC は特定のボリューム サイズとアクセス モードを要求できます。
3. PVCはアプリケーションとその背後にある特定のストレージを切り離します。

2. 次元と懸念を分ける

アプリケーション開発者

まず、アプリケーション開発者は PVC リソースのみを扱うということを明確にしておく必要があります。アプリケーションに必要なストレージ容量を知っているのは開発者だけだからです。

Kubernetes では、PVC は永続ストレージの抽象インターフェースとして見ることができます。特定の永続ストアの要件とプロパティについて説明しますが、実際のストレージ実装については責任を負いません。 PV は特定のストレージの実装を担当し、PVC にバインドされます。

NFS や Ceph など、ストレージの背後にある特定の実装方法について心配する必要はなく、必要なストレージ サイズとアクセス モードというニーズを明確にするだけで済みます。これは私たちが気にかける必要のあることではありません。

この分離設計により、基盤となるストレージ テクノロジの選択と実装を気にすることなくアプリケーション開発に集中でき、効率性と柔軟性が向上します。

運用・保守担当者

クラスターの運用および保守担当者だけがクラスターにどのようなストレージが提供されているかを知っているため、PV リソースは通常、運用および保守担当者によって作成されます。これは簡単に理解できるはずです。

プロビジョニング

一般的に、クラスター内で PV を提供する方法は 2 つあります。これら 2 つの方法の長所と短所を見てみましょう。

1. 静的プロビジョニング

静的プロビジョニング

使用プロセス

1. まず、クラスター管理者は、基盤となるネットワーク ストレージ リソースに基づいて静的永続ボリュームを作成します。
2. 次に、ユーザーは最初のステップで特定の永続ボリュームに適用する PVC 宣言を作成します。
3. 最後に、Podを作成し、同時にこのPVCを使用します。

考える

このアプローチの利点は非常に明白です。クラスター内のすべてのストレージ リソースが運用と保守の管理下にあると言えます。

しかし、静的 PV を提供するプロセスでは、運用および保守担当者が PV リソースを作成する必要があり、これによってもいくつかの問題が発生します。

1. これは小規模なクラスターでは問題ありませんが、大規模な本番環境では、ユーザー アプリケーションのインスタンスが制御不能になり、予測できない数万の PV が必要になる場合があります。この手作業による反復的な作業は非効率的であるだけでなく、管理者にとっても面倒です。
2. さらに、この方法ではストレージの使用効率が悪くなる可能性があります。

• 設定が不十分でプログラムの実行が制限されている
• 過剰に構成され、ストレージの無駄が生じる

では、これをどのように自動化するのでしょうか?これは、動的なストレージ構成プロセスを導入するストレージ クラスの概念に依存しています。

2. 動的プロビジョニング

動的プロビジョニング

使用プロセス

上記のフローチャートから、プロセス全体に管理者の介入が欠けていることが明らかです。

1. ユーザーが PVC を作成すると、対応するプロビジョニングによって PV が自動的に作成され、1 対 1 でバインドされます。どのように対応すればいいですか？ storageClassName で検索するだけです。
2. Pod を作成し、PVC を使用するプロセスはどちらでも同じです。

考える

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 ワークロードであり、複数のレプリカの概念も備えています。

 apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: ... replicas: 3 template: ... volumeClaimTemplates: # 定义创建与该StatefulSet 相关的PVC 的模板- metadata: name: www spec: accessModes: ["ReadWriteOnce"] storageClassName: "my-storage-class" resources: requests: storage: 1Gi

違いは、次の図に示すように、volumeClaimTemplatesを定義して、レプリカごとに新しいPVCを自動的に作成できることです。

ステートフルセット

もちろん、実際のシナリオは、特に分散アプリケーションの場合は、より複雑になることがよくあります。たとえば、マスターとスレーブの関係では、StatefulSet によって提供される Pod の識別や順序などの機能を考慮する必要があります。

PVC を作成する最後の方法である、汎用一時ボリュームを見てみましょう。

Generic Ephemeral Volume 内のデータは、コンテナのライフサイクル中にのみ保持されることに注意してください。 Pod が削除または再起動されると、同時に生成された PVC も削除されます。したがって、Generic Ephemeral Volume は、キャッシュ ファイルや一時構成ファイルなど、コンテナーのライフサイクル中に一時的なデータを保持する必要があるシナリオに適しています。

 kind: Pod apiVersion: v1 metadata: name: my-app spec: containers: - name: my-frontend volumeMounts: - mountPath: "/scratch" name: scratch-volume ... volumes: - name: scratch-volume ephemeral: volumeClaimTemplate: metadata: labels: type: my-frontend-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "scratch-storage-class" resources: requests: storage: 1Gi

デフォルトのストレージクラス

管理者は、クラスター内のストレージ クラスにデフォルト ストレージ クラスとして注釈を付けることができます。これは、ストレージ クラスが明示的に指定されていない場合に使用されるデフォルト ストレージ クラスを指定するために使用される、事前定義された特別なストレージ クラスです。

 kubectl patch storageclass <STORAGE-CLASS-NAME> -p \ '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

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

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