Azure Kubernetes Services (AKS) のストレージとバックアップに関するベスト プラクティス
Azure Kubernetes Service (AKS) でクラスターを作成して管理する際に、多くの場合、アプリケーションにはストレージが必要になります。 アプリケーションに最適なストレージを選択できるように、ポッドのパフォーマンスのニーズとアクセス方法を理解しておく必要があります。 AKS ノードのサイズが、ストレージの選択に影響する可能性があります。 接続されたストレージをバックアップし、その復元プロセスをテストする方法を計画します。
このベスト プラクティスの記事では、クラスター オペレーターを対象としたストレージに関する考慮事項に重点を置いています。 この記事では、次のことについて説明します。
- 利用可能なストレージの種類。
- ストレージ パフォーマンスのために AKS ノードのサイズを適切に設定する方法。
- ボリュームの動的および静的なプロビジョニングの違い。
- データ ボリュームをバックアップしてセキュリティで保護する方法。
適切なストレージの種類を選択する
ベスト プラクティスのガイダンス
適切なストレージを選択するためにアプリケーションのニーズを理解します。 運用環境のワークロードには、高パフォーマンスの SSD を基盤とするストレージを使用します。 複数のコンカレント接続が必要な場合は、ネットワークベースのストレージを計画します。
多くの場合、アプリケーションではさまざまな種類と速度のストレージが必要です。 次の質問をすることで、最適なストレージの種類を決定します。
- ご利用のアプリケーションでは、個々のポッドに接続するストレージが必要ですか?
- ご利用のアプリケーションでは、複数のポッドで共有されるストレージが必要ですか?
- ストレージは、データへの読み取り専用アクセス用ですか?
- ストレージは、大量の構造化データの書き込みに使用されますか?
次の表に、使用可能なストレージの種類とその機能の概要を示します。
| 使用事例 | ボリューム プラグイン | 読み取り/書き込み (1 回のみ) | 読み取り専用 (複数回) | 読み取り/書き込み (複数回) | Windows Server コンテナーのサポート |
|---|---|---|---|---|---|
| 共有構成 | Azure Files | はい | イエス | イエス | はい |
| 構造化されたアプリ データ | Azure ディスク | はい | いいえ | 番号 | はい |
| 非構造化データ、ファイル システム操作 | BlobFuse | はい | イエス | はい | いいえ |
AKS には、Azure ディスクまたは Azure Files でサポートされているボリューム用に、セキュリティで保護された 2 つの主な種類のストレージが用意されています。 どちらも、保存データを暗号化する既定の Azure Storage Service Encryption (SSE) が使用されます。 ディスクは、AKS ノード レベルで Azure Disk Encryption を使用して暗号化することはできません。 Azure Files 共有では、ノードにマウントできる数に関する制限はありません。
Azure Files と Azure ディスクは両方とも、以下の Standard と Premium のパフォーマンス レベルで使用できます。
- Premium ディスク
- 高パフォーマンスのソリッドステート ディスク (SSD) でサポートされます。
- すべての運用環境のワークロードにお勧めします。
- Standard ディスク
- 通常の回転ディスク (HDD) でサポートされます。
- アーカイブ用またはアクセス頻度の低いデータに適しています。
Azure Disk CSI ドライバーの既定のストレージ層は Premium SSD ですが、カスタム StorageClass では Premium SSD、Standard SSD、または Standard HDD を使用できます。
アプリケーション パフォーマンスのニーズとアクセス パターンを理解して、適切なストレージ レベルを選択してください。 マネージド ディスクのサイズとパフォーマンス レベルの詳細については、Azure マネージド ディスクの概要に関するページを参照してください。
アプリケーションのニーズを定義するためにストレージ クラスを作成して使用する
Kubernetes の "ストレージ クラス" を使用して、必要なストレージの種類を定義します。 その後、ストレージ クラスはポッドまたはデプロイの仕様で参照されます。 ストレージ クラスの定義を組み合わせて適切なストレージを作成し、それをポッドに接続します。
詳細については、AKS のストレージ クラスに関するページを参照してください。
ストレージのニーズに合わせてノードのサイズを設定する
ベスト プラクティスのガイダンス
各ノード サイズでは、最大数のディスクがサポートされます。 また、さまざまなノード サイズで、さまざまな量のローカル ストレージやネットワーク帯域幅が提供されます。 最適なサイズのノードをデプロイするために、アプリケーション要求について適切に計画します。
AKS ノードは、さまざまな種類とサイズの Azure VM として実行されます。 各 VM サイズでは以下が提供されます。
- CPU やメモリなど、異なる量のコア リソース。
- 接続できるディスクの最大数。
ストレージのパフォーマンスは、最大のローカルおよび接続されるディスクの IOPS (1 秒あたりの入出力操作) に対する VM サイズによっても異なります。
ご利用のアプリケーションでストレージ ソリューションとして Azure ディスクが必要な場合は、適切なノードの VM サイズを入念に計画します。 ストレージ容量および CPU とメモリの量は、VM サイズの決定時に主要な役割を果たします。
たとえば、Standard_B2ms と Standard_DS2_v2 の両方の VM サイズには、同じような量の CPU とメモリ リソースが含まれますが、これらの潜在的なストレージ パフォーマンスは異なります。
| ノードの種類とサイズ | vCPU | メモリ (GiB) | 最大データ ディスク数 | キャッシュされていないディスクの最大 IOPS | キャッシュされていない場合のスループット (MBps) |
|---|---|---|---|---|---|
| Standard_B2ms | 2 | 8 | 4 | 1,920 | 22.5 |
| Standard_DS2_v2 | 2 | 7 | 8 | 6,400 | 96 |
この例の場合、Standard_DS2_v2 では接続ディスク数が 2 倍、IOPS とディスク スループットの量が 3 から 4 倍提供されます。 コア コンピューティング リソースだけを比較し、コストを比較した場合、Standard_B2ms VM サイズを選択すると考えられますが、その場合、ストレージのパフォーマンスは低く、制限されます。
アプリケーション開発チームと協力し、ストレージ容量とパフォーマンスのニーズを理解してください。 パフォーマンスのニーズを満たすため、あるいはニーズを上回るように、AKS ノードに適した VM サイズを選択します。 定期的にアプリケーションのベースラインを設定し、必要に応じて、VM サイズを調整します。
注意
既定では、マネージド ディスクのディスク サイズとパフォーマンスは、選択された VM SKU と vCPU の数に従って割り当てられます。 既定の OS ディスクのサイズ設定は、エフェメラル OS ディスクがサポートされておらず、既定の OS ディスク サイズが指定されていない場合にのみ、新しいクラスターまたはノード プールで使用されます。 詳細については、「既定の OS ディスクのサイズ設定」を参照してください。
使用可能な VM サイズの詳細については、「Azure の Linux 仮想マシンのサイズ」を参照してください。
ボリュームを動的にプロビジョニングする
ベスト プラクティスのガイダンス
管理オーバーヘッドを削減し、スケーリングを可能にするには、永続ボリュームを静的に作成して割り当てることは避けてください。 動的プロビジョニングを使用します。 ストレージ クラスでは、ポッドが削除された後、不要なストレージ コストを最小限に抑えるために適切な解放ポリシーを定義します。
ポッドにストレージを接続するには、永続ボリュームを使用します。 永続ボリュームは、手動でまたは動的に作成できます。 永続ボリュームを手動で作成する場合は、管理オーバーヘッドが増え、スケーリング機能が制限されます。 代わりに、永続ボリュームを動的にプロビジョニングして、ストレージの管理を簡略化し、必要に応じてアプリケーションを拡張し、スケーリングすることができます。
永続ボリューム要求 (PVC) を使用すれば、必要に応じて、ストレージを動的に作成することができます。 ポッドで要求されたときに、基になる Azure ディスクが生成されます。 ポッド定義で、ボリュームを作成し、指定されたマウント パスに接続するよう要求します。
ボリュームを動的に作成して使用する方法の概念については、「永続ボリューム要求」を参照してください。
これらのボリュームの動作を確認する場合は、Azure ディスクまたは Azure Files で動的に永続ボリュームを作成して使用する方法を参照してください。
ストレージ クラス定義の一部として、適切な reclaimPolicy を設定します。 この reclaimPolicy により、ポッドが削除される場合の、基礎となる Azure Storage リソースの動作が制御されます。 基礎となるストレージ リソースは削除することも、将来ポッドで使用するために保持しておくこともできます。 reclaimPolicy は、retain または delete に設定します。
アプリケーションのニーズを理解し、保持されるストレージの定期チェックを実装して、未使用および課金されるストレージの量を最小限に抑えます。
ストレージ クラス オプションの詳細については、ストレージの解放ポリシーに関するページを参照してください。
データをセキュリティで保護してバックアップする
ベスト プラクティスのガイダンス
Velero や Azure Backup など、ご利用のストレージの種類に適したツールを使って、データをバックアップします。 それらのバックアップの整合性とセキュリティを確認します。
アプリケーションでディスク上またはファイル内に保持されているデータを格納して使用する場合、定期的にそのデータのバックアップまたはスナップショットを作成する必要があります。 Azure ディスクでは、組み込みのスナップショット テクノロジを使用できます。 スナップショット操作を実行する前に、アプリケーションで、ディスクへのフラッシュ書き込みを行う必要が生じる場合があります。 Velero では、追加のクラスター リソースおよび構成と共に永続ボリュームをバックアップできます。 アプリケーションから状態を削除できない場合は、永続ボリュームからデータをバックアップし、復元操作を定期的にテストしてデータの整合性と必要なプロセスを確認します。
データ バックアップのさまざまな方法の制限事項、またスナップショットを作成する前にデータを静止する必要がある場合の制限事項を理解します。 データ バックアップで、クラスター デプロイのアプリケーション環境を必ずしも復元できるとは限りません。 このようなシナリオの詳細については、「Azure Kubernetes Service (AKS) での事業継続とディザスター リカバリーに関するベスト プラクティス」を参照してください。
次のステップ
この記事では、AKS のストレージのベスト プラクティスに重点を置きました。 Kubernetes のストレージの基本の詳細については、AKS におけるアプリケーションのストレージの概念に関するページを参照してください。