Kubernetes クラスターへのデータの保存

Kubernetes クラスター上で実行されるアプリケーションのデータ ストレージを構成するには、いくつかの方法があります。 それらの中には、すでに時代遅れになっているものもあれば、ごく最近に登場したものもあります。 この記事では、最新のオプションであるコンテナ ストレージ インターフェイスを介した接続を含む、ストレージ システムを接続するための XNUMX つのオプションの概念について説明します。

方法 1: ポッド マニフェストで PV を指定する

Kubernetes クラスター内のポッドを記述する一般的なマニフェストは次のとおりです。

どのボリュームがどこに接続されているかを説明するマニフェストの部分が色で強調表示されます。

セクション内の ボリュームマウント マウント ポイント (mountPath)、つまり永続ボリュームがコンテナ内のどのディレクトリにマウントされるか、およびボリュームの名前を示します。

セクション内の x ポッドで使用されているすべてのボリュームをリストします。 各ボリュームの名前、タイプ (この場合: awsElasticBlockStore)、および接続パラメーターを指定します。 マニフェストにどのパラメータがリストされるかは、ボリュームのタイプによって異なります。

同じボリュームを複数のポッド コンテナに同時にマウントできます。 このようにして、異なるアプリケーション プロセスが同じデータにアクセスできます。

この接続方法は、Kubernetes がまだ初期段階にあった当初に発明されましたが、現在ではこの方法は時代遅れです。

それを使用する場合、いくつかの問題があります。

1. すべてのボリュームは手動で作成する必要があり、Kubernetes では何も作成できません。
2. 各ボリュームのアクセス パラメータは一意であり、ボリュームを使用するすべてのポッドのマニフェストで指定する必要があります。
3. ストレージ システムを変更するには（AWS から Google Cloud への移行など）、すべてのマニフェストでマウントされたボリュームの設定とタイプを変更する必要があります。

これはすべて非常に不便であるため、実際には、このメソッドは一部の特殊なタイプのボリューム (configMap、secret、emptyDir、hostPath) のみを接続するために使用されます。

• configMap と Secret は、コンテナー内の Kubernetes マニフェストからのファイルを含むボリュームを作成できるようにするサービス ボリュームです。

• emptyDir は一時ボリュームであり、ポッドの存続期間中のみ作成されます。 テストや一時データの保存に便利です。 ポッドが削除されると、emptyDir ボリュームも削除され、すべてのデータが失われます。

• hostPath - アプリケーションを含むコンテナー内でアプリケーションが実行されているサーバーのローカル ディスク上の任意のディレクトリ (/etc/kubernetes など) をマウントできます。 これは安全ではない機能であるため、通常、セキュリティ ポリシーではこのタイプのボリュームの使用を禁止しています。 そうしないと、攻撃者のアプリケーションがコンテナ内に HTC Kubernetes ディレクトリをマウントし、すべてのクラスター証明書を盗むことができます。 通常、hostPath ボリュームは、kube-system 名前空間で実行されるシステム アプリケーションによってのみ使用が許可されます。

Kubernetes がすぐに使用できるストレージ システム ドキュメントに記載されています。

方法 2. SC/PVC/PV ハースへの接続

代替の接続方法は、Storage クラス、Persistent VolumeClaim、Persistent Volume の概念です。

ストレージクラス 接続パラメータをデータ ストレージ システムに保存します。

PersistentVolumeClaim アプリケーションに必要な要件について説明します。
持続ボリューム アクセスパラメータとボリュームステータスを保存します。

アイデアの本質: ポッド マニフェストでは、PersistentVolumeClaim タイプのボリュームを示し、claimName パラメーターでこのエンティティの名前を示します。

PersistentVolumeClaim マニフェストには、アプリケーションが必要とするデータ量の要件が記述されています。 含む：

• ディスクサイズ。
• アクセス方法: ReadWriteOnce または ReadWriteMany;
• ストレージ クラスへのリンク - ボリュームを作成するデータ ストレージ システム。

ストレージ クラス マニフェストには、ストレージ システムへの接続のタイプとパラメータが格納されます。 キューブレットは、ノードにボリュームをマウントするためにそれらを必要とします。

PersistentVolume マニフェストは、特定のボリュームのストレージ クラスとアクセス パラメーター (ボリューム ID、パスなど) を示します。

PVC を作成するとき、Kubernetes はボリュームのサイズと必要なストレージ クラスを確認し、空きの Persistent Volume を選択します。

このような PV が利用できない場合、Kubernetes は特別なプログラムであるプロビジョナー (その名前はストレージ クラスに示されています) を起動できます。 このプログラムはストレージ システムに接続し、必要なサイズのボリュームを作成し、識別子を受信して​​、Persistent VolumeClaim に関連付けられた Kubernetes クラスター内に PersistentVolume マニフェストを作成します。

この多数の抽象化により、アプリケーションがどのストレージ システムで動作しているかに関する情報を、アプリケーション マニフェスト レベルから管理レベルまで削除できます。

データ ストレージ システムに接続するためのすべてのパラメータは、クラスタ管理者が担当するストレージ クラスにあります。 AWS から Google Cloud に移行するときに必要なのは、アプリケーション マニフェストでストレージ クラスの名前を PVC に変更することだけです。 データ ストレージ用の永続ボリュームは、Provisioner プログラムを使用してクラスター内に自動的に作成されます。

方法 3: コンテナ ストレージ インターフェイス

さまざまなストレージ システムと対話するすべてのコードは、Kubernetes コアの一部です。 バグ修正または新機能のリリースは新しいリリースに関連付けられているため、サポートされているすべてのバージョンの Kubernetes に対してコードを変更する必要があります。 これらすべてを保守したり、新しい機能を追加したりするのは困難です。

この問題を解決するために、Cloud Foundry、Kubernetes、Mesos、および Docker の開発者は、コンテナ ストレージ インターフェイス (CSI) を作成しました。これは、コンテナ管理システムと特定のシステムで動作する特別なドライバー (CSI ドライバー) の相互作用を記述するシンプルな統合インターフェイスです。ストレージシステム。 ストレージ システムと対話するためのすべてのコードは、Kubernetes コアから別のシステムに移動されました。

コンテナストレージインターフェースのドキュメント.

通常、CSI ドライバーは、ノード プラグインとコントローラー プラグインの XNUMX つのコンポーネントで構成されます。

ノード プラグインは各ノード上で実行され、ボリュームのマウントとボリューム上での操作の実行を担当します。 コントローラー プラグインはストレージ システムと対話し、ボリュームの作成または削除、アクセス権の割り当てなどを行います。

現時点では、古いドライバーは Kubernetes カーネルに残っていますが、使用は推奨されなくなり、使用するシステム専用の CSI ドライバーをインストールすることをお勧めします。

この革新性は、Storage クラスを使用してデータ ストレージを設定することにすでに慣れている人を怖がらせるかもしれませんが、実際には、恐ろしいことは何も起こっていません。 プログラマにとっては、実際には何も変わりません。これまでは、Storage クラスという名前でのみ作業しており、今後もそうするでしょう。 管理者向けに、helm chart のインストールが追加され、設定の構造が変更されました。 以前に設定を Storage クラスに直接入力していた場合は、まず Helm チャートで設定し、次に Storage クラスで設定する必要があります。 調べてみると何も悪いことは起きていませんでした。

CSI ドライバーを使用した Ceph ストレージ システムの接続に切り替えることで得られる利点を例として見てみましょう。

Ceph を使用する場合、CSI プラグインは、ストレージ システムを操作するための組み込みドライバーよりも多くのオプションを提供します。

1. 動的ディスクの作成。 通常、RBD ディスクは RWO モードでのみ使用されますが、CSI for Ceph では RWX モードでの使用が可能です。 異なるノード上の複数のポッドは、同じ RDB ディスクをノードにマウントし、それらを並行して操作できます。 公平を期すために、すべてがそれほど明るいわけではありません。このディスクはブロック デバイスとしてのみ接続できます。つまり、マルチ アクセス モードで動作するようにアプリケーションを調整する必要があります。
2. スナップショットを作成しています。 Kubernetes クラスターでは、スナップショットを作成する要件を含むマニフェストを作成できます。 CSI プラグインはそれを認識し、ディスクからスナップショットを取得します。 これに基づいて、PersistentVolume のバックアップまたはコピーを作成できます。
3. ディスクサイズの増加 Kubernetes クラスター内のストレージと Persistent Volume 上で。
4. 割り当て。 Kubernetes に組み込まれている CephFS ドライバーはクォータをサポートしていませんが、最新の Ceph Nautilus を備えた新しい CSI プラグインを使用すると、CephFS パーティションでクォータを有効にすることができます。
5. メトリクス。 CSI プラグインは、どのボリュームが接続されているか、どのような通信が行われているかなどに関するさまざまなメトリクスを Prometheus に提供できます。
6. トポロジーを認識します。 クラスターが地理的に分散される方法をマニフェストで指定し、アムステルダムにあるストレージ システムをロンドンで実行されているポッドに接続することを回避できます。

CSI 経由で Ceph を Kubernetes クラスターに接続する方法については、を参照してください。 スラーム夜間学校の講義の実践部分で。 購読することもできます Ceph ビデオコース、15月XNUMX日に発売されます。

記事の著者: Sergey Bondarev、Southbridge の現役アーキテクト、認定 Kubernetes 管理者、kubespray 開発者の XNUMX 人。

宣伝のためではなく、利益のための小さな Post Scriptum...

PS Sergey Bondarev が XNUMX つの集中コースを指導: 更新 Kubernetes ベース 28月30日～XNUMX日および前倒し Kubernetes メガ 14月16日～XNUMX日。

出所： habr.com