クラウド内のコンテナ用の永続ストレージの設定

コンテナの永続ストレージは、クラウドでワークロードを実行するユーザーを含むエンタープライズ ユーザーの間で一般的な要件です。

コンテナ インスタンスは一時的なものです。コンテナが 1 つ破壊されると、何も残りません。その結果、永続性を必要とするワークロード（状態と作業成果物の保存、または共有データベースへのアクセス）は、外部システムと対話する必要があります。

このニーズを満たすために、Docker や Kubernetes などの管理プラットフォームや、AWS、Azure、Google のクラウド コンテナー管理サービスでは、ストレージ ボリューム、ネットワーク ファイル システム、データベースに接続するためのメカニズムが提供されています。

クラウド内のコンテナに永続ストレージを実装する方法は多数あるため、管理者は独自のストレージ ニーズに最適なオプションを選択する必要があります。

CaaS と Kubernetes の背景

Container-as-a-Service (CaaS) サービスは、その利便性、移植性、セキュリティ、スケーラビリティ、パフォーマンス、柔軟性により、セルフホスト型 Kubernetes インストールの代替としてますます人気が高まっています。クラウド サービス プロバイダーのネイティブ サービスを使用できるクラウド ホスト コンテナーの汎用性は、プライベート コンテナー インフラストラクチャよりもオンライン サービスを好む組織にとって大きな魅力となります。

Kubernetes は、クラスター管理プラットフォームとして選ばれるようになりました。これは、Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) などのサービスを通じて利用できます。ただし、クラウド ユーザーには、Amazon Elastic Compute Cloud などの専用コンピューティング インスタンス、または AWS Fargate、Azure Container Instances、GKE Node Auto-provisioning を介したオンデマンド コンテナ インスタンスを使用してクラスター ノードを構成するためのオプションがまだいくつかあります。

管理者がクラスター ノードをどのように展開するかに関係なく、Kubernetes コントロール プレーンは、クラウド ストレージ サービスによって作成されたものも含め、永続ボリュームやファイル共有に接続するいくつかの方法を提供します。

Kubernetes ストレージ オプション

Kubernetes は柔軟性が高く、多数のストレージ プラットフォームをサポートしているため、Kubernetes でストレージを使用するのは混乱を招く可能性があります。実際には、Kubernetes ストレージは概念的に単純であり、ポッド (名前空間、ボリューム、およびその他の設定を共有する 1 つ以上のコンテナー) を外部ボリュームに接続するだけです。ボリュームは次のようになります。

• 論理ディスクとマウント ポイント。
• Amazon Elastic Block Store (EBS) や Azure Disks などのブロック ストレージ サービス。
• NFS、Ceph (CephFS) などを実行するストレージ アレイ、または Amazon Elastic File System (EFS) や Google Cloud Filestore などのクラウド ファイル サービスからのネットワーク ファイル共有。

Kubernetes のドキュメントによると、ボリュームは、ポッド内のコンテナからアクセスできる、データが含まれる可能性のある単なるディレクトリです。管理者が使用する特定のボリューム タイプによって、ディレクトリの名前、それをサポートするメディア、およびその内容が決まります。

複数のストレージ タイプをサポートする柔軟性は、Cloud Foundry、Kubernetes、Mesos、Nomad などのコンテナー オーケストレーターにブロック ストレージとファイル ストレージを公開するための標準である Container Storage Interface (CSI) に由来しています。ポッドは .spec.volumes ファイルの設定を使用してボリュームをマウントしますが、管理者はボリュームをネストすることはできません。ボリュームをマウントしたり、他のボリュームへのシンボリック リンクを持つことはできません。 Kubernetes ドキュメントで指定されているように、サポートされている各ボリューム タイプには異なるキーワードがあります。たとえば、EBS の場合は awsElasticBlockStore、Azure Files の場合は azureFile、SAN iSCSI ボリュームの場合は iscsi などです。

管理者は多くの場合、ポッドのセットの展開とスケーリングを管理するための API である StatefulSets と呼ばれる Kubernetes 機能を備えた永続ボリュームを使用します。一意で永続的な ID、永続的なホスト名、そして秩序立った自動ローリング コード更新を提供します。 Kubernetes のドキュメントによると、StatefulSet 内の個々の Pod は失敗する可能性がありますが、永続的な Pod 識別子は、既存のボリュームを、失敗した Pod を置き換える新しい Pod と一致させるのに役立ちます。

コンテナ内で実行されるアプリケーションは、ほとんどの言語で利用可能な Open Database Connectivity ドライバーを使用して、IP 経由で外部データベースに接続することもできます。管理者が AKS を Azure Database for PostgreSQL に接続すると、Azure などの一部のクラウド サービスでは、ネットワーク パフォーマンスを最大化し、データベースのオーバーヘッドを最小化するための指示が提供されます。

他のクラウド データベース サービスでは、サイドカー プロキシを使用して接続方法をサポートします。たとえば、Google Cloud SQL Proxy は、GKE アプリケーションを Cloud SQL インスタンスにリンクするための安全で信頼性の高い方法です。 Google は、外部データベースのサービス エンドポイントの作成や、マネージド データベース サービスのポート マッピングでの Uniform Resource Identifier の使用など、外部サービスを Kubernetes にマッピングするためのベスト プラクティスを提供しています。

CaaS オファリングでは既存のストレージ インターフェイスが使用され、クラウド ブロックおよびファイル サービス用の CSI ドライバーがあるため、Pod デプロイメントではプライベートの自己管理型ストレージ ボリュームと共有またはクラウド リソースのいずれかを選択できます。

最も一般的な CSI ドライバー オプションには次のものがあります。

• Amazon EKS EBS CSI ドライバー
• Amazon EKS EFS CSI ドライバー
• Azure ディスク CSI ドライバー
• Azure ファイル AKS CSI ドライバー
• GCP GKE 永続ディスク CSI ドライバー
• GCP GKE ファイル ストレージ接続
• GKE 用 GCP Cloud SQL プロキシ

同様に、Kubernetes Pod は NFS CSI ドライバーを使用してプライベート NAS に接続できます。 Dell EMC CSI プラグイン、NetApp Trident、Pure Storage Portworx など、いくつかのエンタープライズ ストレージ プロバイダーが、Kubernetes 向けに設計された CSI およびストレージ ソフトウェアを提供しています。

*元のリンク: https://searchstorage.techtarget.com/tip/Set-up-persistent-storage-for-containers-in-the-cloud