Azure Backup を使用して、Azure Kubernetes Service (AKS) を保護できます。 この記事では、利用可能なリージョン、サポートされるシナリオ、および制限事項について説明します。
サポートされているリージョン
- AKS 用 Azure Backup では、次の Azure リージョンのコンテナー層と運用 (スナップショット) 層の両方にバックアップ データを格納できます。
オーストラリア中部、オーストラリア中部 2、オーストラリア東部、オーストラリア南東部、ブラジル南部、ブラジル南東部、カナダ中部、カナダ東部、インド中部、米国中部、東アジア、米国東部 2、フランス中部、フランス南部、ドイツ北部、ドイツ西部、イタリア北部、東日本、西日本、九尾インド西部、韓国中部、韓国南部、米国中北部、北ヨーロッパ、ノルウェー東部、 ノルウェー西部、南アフリカ北部、南アフリカ西部、米国中南部、南インド、東南アジア、スウェーデン中部、スイス北部、スイス西部、アラブ首長国連邦北部、英国南部、英国西部、米国中西部、西ヨーロッパ、米国西部、米国西部 2、米国西部 3
- 次のリージョンでは、運用 (スナップショット) レベルのみがサポートされています。
中国東部 2、中国東部 3、中国北部 2、中国北部 3、US GOV アリゾナ、US GOV テキサス、US GOV バージニア、イスラエル中部、ポーランド中部、スペイン中部
注
オンデマンドで復元できる geo 冗長バックアップが必要な場合は、バックアップをコンテナー層に格納し、バックアップ コンテナーでリージョン間復元を有効にします。 これにより、ペアになっている Azure リージョンでもバックアップを使用できるため、プライマリ リージョンが使用できない場合でも復元を実行できます。 Azure のペアになっているリージョンの一覧を参照してください。
サポートされているシナリオ
Azure Backup for AKS では、サポートされている Kubernetes バージョンを実行しているクラスターのみがサポートされます。 サポートされている Kubernetes バージョンの一覧を次に示します。 クラスターがサポートされていないバージョンの場合、バックアップ操作は引き続き実行される可能性がありますが、バックアップまたは復元中のエラーについては説明しません。 完全なサポートと信頼性を確保するには、サポートされているバージョンにアップグレードし、バックアップを検証し、問題が解決しない場合はサポートにお問い合わせください。
AKS 用 Azure Backup では、CSI ドライバーベースの永続ボリューム (Azure ディスク) のみがサポートされます。 ツリー内ボリューム プラグインはサポートされていません。 クラスターで CSI ドライバーとスナップショットが有効になっていることを確認します。 無効な場合は、これらの設定を有効にします。 また、ワークロードでツリー内ボリュームを使用する場合は、 それらを CSI ベースのボリュームに移行してバックアップのサポートを有効にします。
現在、AKS 用 Azure Backup では、CSI ドライバーを使用してプロビジョニングされた Azure ディスク ベースの永続ボリュームのみがサポートされています。 サポートされているディスク SKU には、Standard HDD、Standard SSD、Premium SSD が含まれます。
動的にプロビジョニングされたボリュームと静的にプロビジョニングされたボリュームの両方がサポートされています。ただし、静的ボリュームの場合、 ストレージ クラス は YAML 仕様で明示的に定義する必要があります。そうしないと、バックアップ中にボリュームがスキップされます。
AKS 用 Azure Backup では、 システム割り当て マネージド ID またはユーザー割り当 てマネージド ID を使用するクラスターがサポートされています。 サービス プリンシパルで構成されたクラスターはサポートされていません。 バックアップを有効にするには、システム割り当てマネージド ID またはユーザー割り当てマネージド ID を使用するようにクラスターを更新します。
Azure Backup for AKS では、運用層とコンテナー層の両方のバックアップが提供されます。 運用層のバックアップは、サポートされている永続ボリュームの種類のスナップショットと、バックアップ拡張機能のインストール時に指定された BLOB コンテナーに格納されたメタデータで構成されます。 一方、コンテナー層のバックアップは、テナントの外部と安全にオフサイトで保存されます。 バックアップ ポリシーを使用して、運用層とコンテナー層の両方のバックアップを有効にするか、運用層のみを使用することを選択できます。
運用レベルのバックアップの一部として作成された永続ボリューム スナップショットは、本質的にクラッシュ整合性があります。 Azure Backup for AKS では現在、ボリューム間で一貫性のあるスナップショットを実現するために、すべての PV のスナップショットをまったく同じミリ秒で取得することはサポートされていません。
Azure Backup for AKS でサポートされる最小バックアップ頻度は 4 時間ごとであり、6、8、12、24 時間間隔の追加オプションがあります。 バックアップは、スケジュールされた開始時刻から 2 時間以内に完了する必要があります。 これらの頻度は、運用層のバックアップに適用され、1 日に複数のバックアップが可能になります。 ただし、24 時間の間に成功した最初のバックアップのみが、コンテナー層に転送される資格があります。 運用レベルでバックアップが作成されると、コンテナー層に移動するまでに最大 4 時間かかることがあります。
バックアップ コンテナーと AKS クラスターは、同じリージョンに配置する必要があります。 ただし、これらは、同じテナント内にある限り、異なるサブスクリプションに存在できます。
Azure Backup for AKS では、運用層とコンテナー層の両方のバックアップを使用して、同じまたは別の AKS クラスターにバックアップを復元できます。 ターゲット AKS クラスターは、同じサブスクリプションまたはサブスクリプション間の復元と呼ばれる別 のサブスクリプションに存在できます。
運用層から復元する場合、ターゲット AKS クラスターはバックアップと同じリージョンに存在する必要があります。 ただし、バックアップが Geo 冗長ストレージ設定 でコンテナー層に格納され、Backup Vault で リージョン間復元 が有効になっている場合は、Azure ペアリージョン内の別のリージョンに復元できます。
Azure CLI を使用して AKS の Azure Backup を有効にするには、バージョン 2.41.0 以降を使用していることを確認します。 az upgrade コマンドを実行して、CLI をアップグレードできます。
Terraform を使用して AKS の Azure Backup を有効にするには、バージョン 3.99.0 以降を使用します。
Azure Backup for AKS では、バックアップ拡張機能をインストールする必要があります。 この拡張機能にはストレージ アカウントが必要であり、インストール時に入力として、その中に空の BLOB コンテナーが必要です。 バックアップ関連以外のファイルで BLOB コンテナーを使用しないでください。
バックアップ拡張機能のインストール時に指定するストレージ アカウントは、AKS クラスターと同じリージョンに存在する必要があります。 汎用 v2 ストレージ アカウントのみがサポートされています。Premium ストレージ アカウントはサポートされていません。
AKS クラスターがプライベート仮想ネットワーク内にデプロイされている場合は、バックアップ操作を有効にするようにプライベート エンドポイントを構成する必要があります。
バックアップ拡張機能は、x86 ベースのプロセッサを使用し、オペレーティング システムとして Ubuntu または Azure Linux を実行するノード プールにのみインストールできます。
期限切れの復旧ポイントの削除を含め、バックアップ操作または復元操作を実行する前に、AKS クラスターとバックアップ拡張機能ポッドの両方が実行中で正常な状態である必要があります。
Azure Backup for AKS では、Azure Monitor を介してアラートを提供します。これにより、クラシック アラート、組み込みの Azure Monitor アラート、バックアップエラー通知用のカスタム ログ アラートなど、さまざまな Azure サービス間でアラート管理の一貫したエクスペリエンスを実現できます。 サポートされているバックアップ アラート は、ここで入手できます
Azure Backup for AKS では、さまざまなバックアップ関連レポートがサポートされています。 現在、バックアップ データは、レポート フィルターでワークロードの種類として [すべて] を選択することによってのみ表示できます。 サポートされているバックアップ レポート については、こちらをご覧ください
Azure Backup for AKS では、Vault 層に格納されているバックアップの 拡張論理的な削除 がサポートされており、偶発的または悪意のある削除に対する保護が提供されます。 運用層に格納されているバックアップの場合、基になるスナップショットは論理的な削除によって保護されず、完全に削除できます。
Azure Backup for AKS では 、マルチユーザー承認 (MUA) がサポートされているため、バックアップが構成されているバックアップ コンテナーに対する重要な操作に保護レイヤーを追加できます。
Azure Backup for AKS では 不変コンテナーがサポートされています。これは、復旧ポイントが失われる可能性のある操作を防ぐことでバックアップ データを保護するのに役立ちます。 ただし、バックアップ用の WORM (Write Once、Read Many) ストレージは現在サポートされていません。
Azure Backup for AKS では 、Customer-Managed キー (CMK) 暗号化がサポートされていますが、コンテナー層に格納されているバックアップにのみ適用されます。
バックアップと復元の各操作を正常に実行するには、バックアップ コンテナーのマネージド ID によるロールの割り当てが必要です。 必要なアクセス許可がない場合は、ロールを割り当てた直後のバックアップの構成または復元操作中に、アクセス許可の問題が発生することがあります。これは、ロールの割り当てが有効になるまで数分かかるためです。 ロールの定義についてご確認ください。
サポートされていないシナリオと制限事項
AKS 用 Azure Backup では、Premium SSD v2 と Ultra Disks の Azure ディスク SKU はサポートされていません。
AKS Backup では、Azure ファイル共有、Azure Blob Storage、Azure Container Storage ベースの永続ボリュームはサポートされていません。 これらの種類の永続ボリュームを AKS クラスターで使用している場合は、専用の Azure Backup ソリューションを使用して個別にバックアップできます。 詳細については、「Azure ファイル共有のバックアップについて」と「Azure BLOB バックアップの概要」を参照してください。
サポートされていない永続ボリュームの種類は、AKS クラスターのバックアップ プロセス中に自動的にスキップされます。
バックアップ拡張機能は、Windows ベースのノード プールまたは ARM64 ベースのノード プールにはインストールできません。 このようなノードを使用する AKS クラスターでは、バックアップ拡張機能のインストールをサポートするために、個別の Linux ベースのノード プール (できれば x86 ベースのプロセッサを搭載したシステム ノード プール) をプロビジョニングする必要があります。
AKS 用 Azure Backup は、現在、Network Isolated AKS クラスターではサポートされていません。
AKS バックアップ拡張機能を Velero または Velero ベースのバックアップ ソリューションと共にインストールしないでください。これにより、バックアップ操作と復元操作中に競合が発生する可能性があるためです。 さらに、サポートされているシナリオで明示的に要求されない限り、Kubernetes リソースでプレフィックス
velero.io
を含むラベルや注釈が使用されていないことを確認します。 このようなメタデータが存在すると、予期しない動作が発生する可能性があります。AKS クラスターのバックアップセットアップ中にバックアップ インスタンスに割り当てられたバックアップ構成またはスナップショット リソース グループの変更はサポートされていません。
次の名前空間は Backup Configuration からスキップされ、バックアップ用に構成することはできません:
kube-system
、kube-node-lease
、kube-public
。Azure Backup は AKS ノードを自動的にスケールアウトせず、データと関連リソースのみを復元します。 自動スケールは、クラスター オートスケーラーなどの機能を使用して、AKS 自体によって管理されます。 ターゲット クラスターで自動スケールが有効になっている場合は、リソースのスケーリングを自動的に処理する必要があります。 復元する前に、復元の失敗やパフォーマンスの問題を回避するために、ターゲット クラスターに十分なリソースがあることを確認してください。
AKS バックアップの制限は次のとおりです。
設定 制限 Backup コンテナーあたりのバックアップ ポリシーの数 5,000 Backup コンテナーあたりのバックアップ インスタンスの数 5,000 1 日に許可されるバックアップ インスタンスあたりのオンデマンド バックアップの数 10 バックアップ インスタンスあたりの名前空間の数 800(八百) 1 日のバックアップ インスタンスあたりの許可される復元の数 10
コンテナー化されたバックアップとリージョン間の復元に固有の制限事項
現在、サイズが < = 1 TB の永続ボリュームを持つ Azure ディスクは、コンテナー層に移動する資格があります。サイズが大きいディスクは、コンテナー層に移動されたバックアップ データではスキップされます。
現在、 < = 100 個のディスクが永続ボリュームとして接続されているバックアップ インスタンスがサポートされています。 ディスクの数が上限を超える場合、バックアップ操作と復元操作が失敗する可能性があります。
すべてのネットワークからパブリック アクセスが有効になっている Azure ディスクのみが、コンテナー層に移動できます。パブリック アクセスとは別にネットワーク アクセスを持つディスクがある場合、階層化操作は失敗します。
ディザスター リカバリー 機能は、Azure のペアになっているリージョン間でのみ使用できます (リージョン間復元が有効になっている Geo 冗長バックアップ コンテナーでバックアップが構成されている場合)。 バックアップ データは、Azure のペアになっているリージョンでのみ使用できます。 たとえば、リージョン間の復元が有効になっている Geo 冗長バックアップ コンテナーにバックアップされている AKS クラスターが米国東部にある場合、バックアップ データは復元のために米国西部でも使用できます。
コンテナー層では、スケジュールされた復旧ポイントが 1 日に 1 つだけ作成され、プライマリ リージョンで 24 時間の目標復旧ポイント (RPO) が提供されます。 セカンダリ リージョンでは、この復旧ポイントのレプリケーションに最大 12 時間かかる場合があります。その結果、最大 36 時間の有効な RPO が生成されます。
バックアップが運用レベルで作成され、コンテナー層の対象になると、階層化プロセスが開始されるまでに最大 4 時間かかる場合があります。
運用レベルからコンテナー層にバックアップを移動する場合、排除ロジックでは、階層化操作とデータ整合性を成功させるために不可欠なスナップショットが保持されます。 具体的には、ソース ストア (運用レベル) の最新の復旧ポイント (RP) の階層化中に、次の両方のスナップショットが必要です。
- 運用レベル (ソース ストア) の最新の RP。
- コンテナー層 (ターゲット ストア) の以前の強化 RP。
その結果、Operational レベルの 2 つの復旧ポイントは意図的に保持され、排除されません。
- Operational レベルの最新の RP。
- 最新のコンテナー層 RP にリンクされている Operational レベルの RP。
この動作により、偶発的なデータ損失を防ぎ、一貫性のあるバックアップが保証されます。 その結果、これらの階層化の依存関係により、一部の運用バックアップが構成された毎日の保持ポリシーよりも長く保持されていることに気付く場合があります。
運用レベルからコンテナー層にバックアップを移動する場合、バックアップ拡張機能に提供されるストレージ アカウントでは、パブリック ネットワーク アクセスが有効になっている必要があります。 ストレージ アカウントがファイアウォールの内側にある場合、またはプライベート アクセスが有効になっている場合は、シームレスなデータ転送を許可するために、バックアップ コンテナーがストレージ アカウントのネットワーク設定に信頼済みサービスとして追加されていることを確認します。
コンテナー層からの復元中、ストレージ アカウントとリソース グループを含むステージング場所のハイドレートされたリソースは、復元後に消去されません。 手動で削除する必要があります。
復元中、バックアップ サービスがデータにアクセスして転送できるようにするには、ステージング ストレージ アカウントでパブリック ネットワーク アクセスが有効になっている必要があります。 パブリック アクセスがないと、接続の制限により復元操作が失敗する可能性があります。
復元中に、ターゲット AKS クラスターがプライベート仮想ネットワーク内にデプロイされている場合は、クラスターとステージング ストレージ アカウントの間でプライベート エンドポイントを有効にして、セキュリティで保護された正常なデータ転送を確保する必要があります。
ターゲットの AKS クラスターのバージョンがバックアップ時に使用されたバージョンと異なる場合、新しいクラスター バージョンでの非推奨のリソースなどのさまざまなシナリオで、復元操作が失敗したり、警告が表示されて完了したりすることがあります。 コンテナー層から復元する場合は、ステージング場所のハイドレートされたリソースを使用して、アプリケーション リソースをターゲット クラスターに復元できます。
現在、Terraform デプロイでは、コンテナー層ベースのバックアップはサポートされていません。
次のステップ
- Azure Kubernetes Service クラスターのバックアップについて。
- Azure portal、Azure CLI、Azure PowerShell、Azure Resource Manager、Bicep、Terraform を使用して Azure Kubernetes Service クラスターをバックアップします。
- Azure portal、Azure CLI、AzurePowerShell を使用して Azure Kubernetes Service クラスターを復元します。
- Azure Backup を使用して Azure Kubernetes Service バックアップを管理します。