コンテナクラウドドッキングと永続ストレージの使用

コンテナはインターネット アプリケーションのアジャイル開発と迅速な配信を実現するため、従来の金融 IT に技術革新の課題をもたらしました。データの爆発的な増加、アプリケーションの複雑性の増大、ビジネス製品の急速な更新、アプリケーション システム ソフトウェアの急速な反復などの一連の課題に対応するため、金融業界のデジタル変革の波の中で、コンテナ テクノロジの人気が高まっています。

この記事では主に、コンテナ クラウドでのストレージの使用に関する提案を提供します。 Kubernetes は多くの種類のボリュームをサポートしており、Pod は同時に任意の数のボリューム タイプを使用できます。一時ボリューム タイプのライフサイクルは Pod と同じですが、永続ボリュームは Pod よりも長く存続できます。 Kubernetes は、ポッドが存在しなくなったときに一時ボリュームも破棄します。ただし、Kubernetes は永続ボリュームを破棄しません。特定のポッド内のどのタイプのボリュームでも、コンテナの再起動時にデータが失われることはありません。ボリュームはイメージ内の指定されたパスにマウントされます。コンテナがストレージに接続されると、接続と管理にはストレージ CSI プラグインが使用されます。

コンテナクラウドにおけるストレージの分類

Kubernetes が使用できるストレージは、次のカテゴリに分類できます。

1) 一時保管

共通の一時ストレージは主に emptyDir ボリュームです。 Pod がノードにディスパッチされると、emptyDir ボリュームが作成され、Pod がノード上で実行されている間はボリュームが存在します。何らかの理由で Pod がノードから削除されると、emptyDir ボリューム内のデータも完全に削除されます。通常、emptyDir ストレージは一時的なストレージ スペースとして使用されます。 emptyDirの一般的な用途には次のようなものがあります:(1) ディスクベースのマージソートなどのキャッシュスペース。 （２）時間のかかる計算タスクにチェックポイントを設け、クラッシュ前の状態からタスクを簡単に再開できるようにする。 （３）Webサーバーコンテナがデータを提供する際にコンテンツマネージャコンテナが取得したファイルを保存する。

2) 半永続ストレージ

半永続ストレージは主に HostPath です。 HostPath ボリュームを使用する場合は、その範囲を可能な限り必要なファイルまたはディレクトリに制限し、読み取り専用としてマウントする必要があります。 HostPath の一般的な用途としては、(1) Docker の内部メカニズムにアクセスする必要があるコンテナを実行することが挙げられます。 hostPath を使用して /var/lib/docker パスをマウントできます。 （2）コンテナ内でcAdvisorを実行する場合は、hostPathとして/sysをマウントします。 （3）Podを実行する前に特定のhostPathが存在する必要があるかどうか、それを作成する必要があるかどうか、そしてどのように存在するかをPodが指定できるようにします。

3) 永続ストレージ

永続ストレージのために、Kubernetes では StorageClass、Volume、PVC、PV の概念が導入されています。 Kubernetes でサポートされている永続ストレージには、主流のブロック ストレージ、オブジェクト ストレージ、ネットワーク ファイル ストレージなどが含まれます。Kubernetes では、PersistentVolume と PersistentVolumeClaim という 2 つの新しい API リソースが導入されています。永続ボリューム (PV) は、管理者が事前に準備することも、ストレージ クラスを使用して動的に準備することもできる、クラスター内のストレージの一部です。永続ボリュームは、ノードがクラスター リソースであるのと同様に、クラスター リソースです。

4) 特別な保管

特殊なストレージクラスには主にsecret、configMapなどが含まれます。(1)シークレットボリュームは、パスワードなどの機密情報をポッドに渡すために使用されます。シークレット ボリュームは tmpfs (RAM ベースのファイルシステム) を使用して保存されるため、不揮発性 (永続的) ストレージに書き込まれることはありません。 （2）ConfigMapは、Podに設定データを注入する方法を提供します。これは、キーと値の形式で呼び出されるストレージボリューム内の設定ファイルなど、非機密データをキーと値のペアに保存するために使用されます。

コンテナクラウドでのストレージの使用

Kubernetes では、PV ボリュームはクラスター内のリソースです。 PVC クレームはこれらのリソースに対する要求であり、リソースに対するクレーム チェックを実行するためにも使用されます。 PV コイルと PVC の使用プロセスは一般的に次のようになります。

1) 準備: PV コイルを準備する方法には、静的準備と動的準備の 2 つがあります。 （１）静的準備 クラスタ管理者は複数のPVボリュームを作成します。これらのボリューム オブジェクトには実際のストレージの詳細が含まれており、クラスター ユーザーが利用できます。 （２）動的準備動的ボリューム プロビジョニングは StorageClass に基づいています。PVC アプリケーションはストレージ クラスを要求する必要があり、クラスター管理者は動的ボリューム プロビジョニングを実行するためにクラスを作成して構成しておく必要があります。 PVC アプリケーションで指定されたストレージ クラスが "" (空) の場合、動的に準備されたボリュームの使用を禁止するのと同じです。

2) バインディング: ユーザーは、特定のストレージ容量と特定のアクセス モード要件を持つ PersistentVolumeClaim オブジェクトを作成します。動的プロビジョニングのシナリオでは、この PVC オブジェクトはすでに作成されている可能性があります。 PV と PVC 間のバインディング関係が確立されると、PersistentVolumeClaim バインディングは排他的になり、PVC クレームと PV ボリューム間のバインディングは 1 対 1 のマッピングになります。

一致する PV ボリュームが見つからない場合、PVC クレームは無期限にバインドされないままになります。一致する PV ボリュームが利用可能になると、PVC クレームがバインドされます。たとえば、クラスターに 10 Gi PV ボリュームが多数ある場合でも、20 Gi ストレージを要求する PVC と一致することはできません。新しい 20 Gi PV ボリュームがクラスターに追加されると、PVC をバインドできます。

3) 使用法: Pod は PVC をストレージ ボリュームとして使用します。クラスターは PVC クレームをチェックし、バインドされたボリュームを見つけて、ポッドのボリュームをマウントします。複数のアクセス モードをサポートするボリュームの場合、ユーザーはポッド内のボリュームを要求するときに、必要なアクセス モードを指定する必要があります。

4) 使用中のストレージ オブジェクトの保護: 使用中のストレージ オブジェクト保護機能の目的は、ポッドによってまだ使用されている PersistentVolumeClaim (PVC) オブジェクトとそれにバインドされた PersistentVolume (PV) オブジェクトがシステム内で削除されないようにすることです。削除されると、データが失われる可能性があります。

5) 再利用: ユーザーがストレージ ボリュームを使用しなくなった場合は、API から PVC オブジェクトを削除して、リソースを再利用できるようになります。 PersistentVolume オブジェクトの再要求ポリシーは、ボリュームが要求から解放されたときにボリュームに対して何を行うかをクラスターに指示します。現在、データ ボリュームは保持、リサイクル、または削除できます。

• 保持: 再利用ポリシー保持により、ユーザーはリソースを手動で再利用できます。 PersistentVolumeClaim オブジェクトが削除されても、PersistentVolume は引き続き存在し、対応するデータ ボリュームは「解放済み」とみなされます。
• 削除: 削除リサイクルポリシーをサポートするボリュームプラグインの場合、削除アクションにより、Kubernetes から PersistentVolume オブジェクトが削除され、関連するストレージアセットも外部インフラストラクチャ (AWS EBS、CEPH など) から削除されます。
• リサイクル: リサイクル戦略 Recycle は、Kubernetes の新しいバージョンでは非推奨になりました。代わりに、動的な準備が推奨されます。

コンテナクラウドストレージの実装

現在、当行は開発、テスト、本番環境に複数のコンテナ クラウド クラスター プラットフォームを導入しており、重要なアプリケーション システムのサービスをホストして実行しています。この段階では、ステートレス アプリケーションのコンテナ化に主な焦点が当てられています。データベースやミドルウェアなどの一部のステートフル コンポーネントは、まだ仮想マシンで実行されており、将来的に徐々に移行される予定です。オンライン コンテナ クラウド プラットフォームに含まれる永続ストレージは、主に次の部分に分かれています。

1) コンテナイメージデータの保存。イントラネット環境で、独自のプライベート イメージ リポジトリを構築します。関連する構成を行った後、コンテナ クラウド プラットフォームはプライベート イメージ リポジトリからイメージをプルできます。ポッドが配置されているサーバーがクラッシュまたは障害を起こした場合、ポッドを新しいノードで起動する必要があります。このとき、プライベートイメージライブラリからイメージを取得する必要があります。本番環境のポッド数が一定規模に達すると、複数のイメージを並列にプルすることで発生する IO ストームを考慮する必要があります。したがって、コンテナ イメージ データのストレージには、一定の同時実行能力を持ち、永続ストレージの一定のスケーラビリティを備えた分散ブロック ストレージを使用することをお勧めします。もちろん、既存の集中型ブロックストレージを再利用して投資を節約することもできます。同時に、この部分のストレージのバックアップやプライベートイメージリポジトリの冗長ストレージも考慮する必要があります。

2) ポッド/コンテナのデータストレージ。コンテナ クラウド クラスターの Etcd のデータは、ログの形式で常にメモリとハードディスクに記録されます。 etcd はディスクの遅延に非常に敏感です。低レイテンシと高パフォーマンスの書き込みを保証するために、Etcd を物理マシン/仮想マシン (クラスターの規模によって異なります) にデプロイし、基盤となるストレージに SSD ディスクを構成することをお勧めします。ほとんどのアプリケーション ポッド/コンテナーでは、ストレージ パフォーマンスに対する要件は高くなく、主にコンピューティング リソースを消費します。したがって、ノード上で実行されている Pod/コンテナのイメージは、サーバーのローカル ディスクに保存することをお勧めします。

3) アプリケーション間の共有データストレージ。 NFS は、ステートフル アプリケーションまたはステートレス アプリケーション間でデータを共有する必要がある場合に主流となるファイル共有サーバーです。 NFS データ ボリュームは NFS マウントのサポートを提供し、NFS 共有パスを Pod に自動的にマウントできます。各アプリケーション ポッドでファイル共有が必要な場合、業務システムのファイル共有要件を満たすために、NAS アクティブ アクティブ ストレージが提供する NFS ファイル システムを使用することをお勧めします。

4) ログデータの保存。ログ データを収集するための一般的なソリューションはいくつかあります。 （1）ログ収集コンポーネントをアプリのイメージに統合します。利点は、アプリ アプリケーションの YAML ファイルに特別な構成が必要ないことです。 1 つのイメージで問題は解決しますが、強い結合も発生し、将来コンポーネントまたはアプリケーションを個別にアップグレードできなくなります。 （２）アプリコンテナとログ収集コンポーネントコンテナを同じポッドで実行すると、上記のソリューションに比べて結合度は低くなりますが、ポッドのYAMLファイルを個別に記述して構成する必要があり、面倒になります。 （３）ポッドログをホストノードに直接ハングアップする。各ノードでポッドを開始するか、バイナリ プロセスを使用してログを収集します。利点は、ログ収集がアプリケーション ポッドから完全に分離されているため、管理が容易になることです。ログ出力仕様を設定し、ログディレクトリと出力方法を統一するだけです。この方法はログ保存のパフォーマンスが高くなります。ログデータの保存には、pod log output を使用してストレージをローカルサーバーにマウントし、Filebeat + Logstash + ElasticSearch + Kibana (ELK) または Fluentd + Filebeat + Elasticsearch + Kibana (EFK) を介して統合されたログ収集、分類、分析、クエリ、表示プラットフォームを構築することをお勧めします。

例えば、コンテナクラウドプラットフォーム全体の永続ストレージを選択する過程では、統合ログストレージプラットフォームとして、分散ブロックストレージ（Ceph、Longhornなど）にログデータを保存することも検討しました。ただし、既存のELKログ収集・表示プラットフォームを引き続き利用することと、コンテナの初期規模が小さいことから、分散ブロックストレージは暫定的に第2フェーズの計画・構築として挙げられています。最初のフェーズでは、主にステートレス アプリケーションのコンテナ化を完了します。第 2 フェーズでは、ステートフル アプリケーション (Redis、ZK、低負荷の MySQL など) のコンテナ化に重点を置きます。 StatefulSet としてデプロイすることをお勧めします。ノードが再起動して他のマシンに移動すると、マウントされた PVC (PersistentVolumeClaim) を通じて元の完全なデータを取得できます。ただし、分散ストレージによって読み取りと書き込みの遅延が発生するため、ビジネス開発の IO 要件を満たすには、さまざまなコンテナ化されたアプリケーションの感度に応じて異なるパフォーマンスの分散ストレージを構成する必要があります。

要約すると、特定の種類のストレージを使用するコンテナ クラウド永続ストレージのベスト プラクティスに対する完璧なソリューションは存在しません。代わりに、ビジネスの種類、システムの重要度、クラスターのサイズ、スケーラビリティなどの複数の側面を総合的に考慮し、銀行の長期計画と組み合わせて、テクノロジー戦略に適合し、ビジネス開発に役立つストレージ アーキテクチャを設計する必要があります。