次の方法で共有

Azure Kubernetes Service バックアップとは?

Azure Kubernetes Service (AKS) バックアップは、AKS クラスターで実行されるコンテナー化されたアプリケーションとデータのバックアップと復元に使用できる、シンプルなクラウドネイティブ プロセスです。 コンテナー ストレージ インターフェイス (CSI) ドライバー ベースの Azure Disk Storage の Kubernetes 永続ボリュームに格納されているクラスターの状態とアプリケーション データのスケジュールされたバックアップを構成できます。

このソリューションでは、細かい制御が提供されます。 バックアップは、BLOB コンテナーとディスク スナップショットとしてローカルに格納することで、特定の名前空間またはクラスター全体をバックアップまたは復元できます。 AKS バックアップは、運用回復、開発者またはテスト環境の複製、クラスターのアップグレード シナリオなど、エンドツーエンドのシナリオに使用できます。

AKS バックアップは、Azure の Backup センターと統合され、大規模なバックアップの管理、監視、運用、分析に役立つ単一のビューを提供します。 バックアップは、AKS インスタンスのサービス メニューの [設定] の下の Azure portal でも使用できます。

AKS バックアップのしくみ

AKS バックアップを使用して、AKS クラスターにデプロイされている AKS ワークロードと永続ボリュームをバックアップできます。 このソリューションでは、Backup 拡張機能を AKS クラスター内にインストールする必要があります。 バックアップ コンテナーは拡張機能と通信して、バックアップと復元の操作を完了します。 バックアップ拡張機能の使用は必須です。 クラスターのバックアップと復元を有効にするには、拡張機能を AKS クラスター内にインストールする必要があります。 AKS バックアップを構成するときは、ストレージ アカウントとバックアップが保存されている BLOB コンテナーの値を追加します。

Backup 拡張機能と共に、AKS クラスターの管理対象リソース グループにユーザー ID ("拡張機能 ID" と呼ばれます) が作成されます。 拡張機能 ID には、バックアップが BLOB コンテナーに格納されているストレージ アカウントに対するストレージ アカウント共同作成者ロールが割り当てられます。

パブリック、プライベート、および承認された IP ベースのクラスターをサポートするには、AKS バックアップでは、AKS クラスターとバックアップ コンテナーの間で信頼されたアクセス機能を有効にする必要があります。 信頼されたアクセスにより、バックアップ 操作用に特定のアクセス許可が割り当てられるため、Backup コンテナーは AKS クラスターにアクセスできます。 AKS の信頼されたアクセスの詳細については、「信頼されたアクセスを使用して Azure リソースから AKS クラスターにアクセスできるようにする」を参照してください。

AKS バックアップを使用すると、運用層とコンテナー層の両方にバックアップを格納できます。 運用層はローカル データストア (バックアップはスナップショットとしてテナント内に存在) です。 AKS バックアップを使用して、1 日に 1 つの復旧ポイントを移動し、コンテナー層に BLOB (テナントの外部) として格納できるようになりました。 コンテナー層に格納されているバックアップを使用して、セカンダリ リージョン (Azure とペアのリージョン) のデータを復元することもできます。

バックアップ拡張機能をインストールし、信頼できるアクセスを有効にした後、バックアップ ポリシーに従ってクラスターのスケジュールされたバックアップを構成できます。 また、バックアップを元のクラスターまたは同じサブスクリプションとリージョン内の別のクラスターに復元することもできます。 特定の操作を設定するときに、バックアップと復元の構成として特定の名前空間またはクラスター全体を選択できます。

AKS バックアップを使用すると、クラスターにデプロイされている AKS データ ソースのバックアップ操作が可能になります。 また、クラスターの永続ボリュームに格納されているデータのバックアップ操作も有効になります。 その後、バックアップが BLOB コンテナーに格納されます。 ディスク ベースの永続ボリュームは、スナップショット リソース グループのディスク スナップショットとしてバックアップされます。 BLOB 内のスナップショットとクラスターの状態を組み合わせることで、テナントに保存される、運用層と呼ばれる復旧ポイントを生成できます。 また、運用層のバックアップ（日、週、月、年単位でその日の最初に成功したバックアップ）をBLOBに変換し、1日に1回、テナント外の保管庫に移動することもできます。

注

現在、Azure Backup では、CSI ドライバー ベースの Azure Disk Storage の永続ボリュームのみがサポートされています。 バックアップ中、ソリューションは Azure Files 共有や BLOB などの他の永続ボリュームの種類をスキップします。 また、コンテナー層に対して定義された保持ルールを設定した場合、永続ボリュームが 1 TB 以下の場合にのみ、バックアップをコンテナーに移動できます。

バックアップの構成

AKS クラスターのバックアップを構成するには、まず Backup ボールトを作成します。 保管庫は、さまざまなデータ ソース間で構成されたバックアップの統合ビューを提供します。 AKS バックアップでは、運用層とコンテナー層の両方のバックアップがサポートされます。

バックアップ コンテナーのストレージ冗長設定 (ローカル冗長ストレージまたは geo 冗長ストレージ) は、コンテナー層に格納されているバックアップにのみ適用されます。 ディザスター リカバリーにバックアップを使用する場合は、リージョン間の復元を有効にしてストレージの冗長性を GRS に設定します。

注

Backup コンテナーと、バックアップまたは復元する AKS クラスターは、同じリージョンとサブスクリプションに存在する必要があります。

AKS バックアップでは、スケジュールされたバックアップ ジョブが自動的にトリガーされます。 ジョブは、クラスター リソースを BLOB コンテナーにコピーし、バックアップ頻度に従ってディスク ベースの永続ボリュームの増分スナップショットを作成します。 バックアップは、バックアップ ポリシーで定義されている保持期間に従って、運用層とコンテナー層に保持されます。 バックアップは、期間が経過すると削除されます。

AKS バックアップを使用すると、バックアップ インスタンスごとに異なるバックアップ構成を使用して、1 つの AKS クラスターに対して複数のバックアップ インスタンスを作成できます。 ただし、AKS クラスターの各バックアップ インスタンスは、次の 2 つの方法のいずれかで作成することをお勧めします。

  • 別のバックアップ コンテナー内
  • 同じバックアップ コンテナー内で別のバックアップ ポリシーを使用する

バックアップの管理

AKS クラスターのバックアップ構成が完了すると、Backup ボールトにバックアップ インスタンスが作成されます。 クラスターのバックアップ インスタンスは、Azure portal の AKS インスタンスの [Backup] セクションで確認できます。 ユーザーは、対応するバックアップ インスタンスを使用して、復元の開始、監視、保護の停止など、インスタンスに対して任意のバックアップ関連の操作を実行できます。

また、AKS バックアップは Backup センターと直接統合され、すべての AKS クラスターとその他のバックアップでサポートされているワークロードの保護を一元的に管理するのに役立ちます。 バックアップ センターでは、ジョブの監視やバックアップと復元の状態など、すべてのバックアップ要件を 1 つのビューで確認できます。 Backup センターを使用すると、コンプライアンスとガバナンスを確保し、バックアップの使用状況を分析し、データをバックアップおよび復元する重要な操作を行います。

AKS バックアップは、マネージド ID を使用して他の Azure リソースにアクセスします。 AKS クラスターのバックアップを構成し、以前のバックアップから復元するには、バックアップ コンテナーのマネージド ID に AKS クラスターに対する一連のアクセス許可が必要です。 また、スナップショットが作成および管理されるスナップショット リソース グループに対する一連のアクセス許可も必要です。 現在、AKS クラスターには、スナップショット リソース グループに対する一連のアクセス許可が必要です。

また、Backup 拡張機能ではユーザー ID を作成し、バックアップが BLOB に保存されているストレージ アカウントにアクセスするための一連のアクセス許可を割り当てます。 Azure ロールベースのアクセス制御を使用して、マネージド ID にアクセス許可を付与できます。 マネージド ID は、Azure リソースでのみ使用できる、特殊な種類のサービス プリンシパルです。 マネージド IDの詳細を確認してください。

バックアップから復元する

回復ポイントが存在する任意の時点からデータを復元できます。 バックアップ インスタンスが保護された状態になると、復旧ポイントが作成されます。 バックアップ ポリシーでデータが保持されるまで、データの復元に使用できます。

Azure Backup には、バックアップされたすべての項目を復元するオプションや、名前空間やその他のフィルター オプションを使用してバックアップから特定の項目を選択するための詳細な制御を使用するオプションが用意されています。 また、元の AKS クラスター (バックアップされたクラスター) または代替 AKS クラスターで復元を行うこともできます。 運用層とコンテナー層に格納されているバックアップは、同じサブスクリプションまたは別のサブスクリプション内のクラスターに復元できます。 コンテナー層に格納されているバックアップのみを使用して、別のリージョン (Azure とペアのリージョン) のクラスターへの復元を行うことができます。

コンテナー層に格納されているバックアップを復元するには、バックアップ データがハイドレートされるステージング場所を指定する必要があります。 このステージング場所には、復元するターゲット クラスターと同じリージョンとサブスクリプション内のリソース グループとストレージ アカウントが含まれます。 復元時に、ハイドレーションの一部として特定のリソース (BLOB コンテナー、ディスク、ディスク スナップショット) が作成されます。 復元操作が完了するとクリアされます。

Azure Backup for AKS では現在、リソースの競合が発生するシナリオに対して、次の 2 つのオプションがサポートされています。 リソースの競合は、バックアップされたリソースがターゲット AKS クラスター内のリソースと同じ名前である場合に発生します。 復元構成を定義するときに、これらのオプションのいずれかを選択できます。

  • スキップ: 既定では、このオプションが選択されます。 たとえば、 pvc-azuredisk という名前の永続ボリューム要求 (PVC) をバックアップし、同じ名前の PVC を持つターゲット クラスターで復元する場合、バックアップ拡張機能はバックアップされた PVC の復元をスキップします。 このようなシナリオでは、クラスターからリソースを削除することをお勧めします。 次に、バックアップされた項目がクラスターでのみ使用でき、スキップされないように、復元操作を実行します。

  • パッチ: このオプションを使用すると、ターゲット クラスター内のリソース上のバックアップ リソースの変更可能な変数にパッチを適用できます。 ターゲット クラスター内のレプリカの数を更新したい場合は、操作としてパッチ適用を選択できます。

注

AKS バックアップでは、ターゲット クラスター内のリソースが既に存在する場合、リソースは削除および再作成されません。 元の場所にある永続ボリュームの復元を試みる場合は、既存の永続ボリュームを削除してから、復元操作を実行します。

バックアップと復元用のカスタム フックの使用

カスタム フックを使用して、コンテナー化されたワークロードとしてデプロイされたデータベースに使用されるボリュームのアプリケーション整合性スナップショットを取得できます。

カスタム フックとは

AKS バックアップを使用すると、バックアップと復元操作の一部としてカスタム フックを実行できます。 フックは、バックアップ操作中または復元後にコンテナーの下のポッドで実行する 1 つ以上のコマンドを実行するように構成されます。

これらのフックをカスタム リソースとして定義し、バックアップまたは復元したい AKS クラスターにデプロイします。 必要な名前空間の AKS クラスターにカスタム リソースがデプロイされている場合は、バックアップと復元を構成するためのフローの入力として詳細を指定します。 Backup 拡張機能は、YAML ファイルで定義されているフックを実行します。

注

フックは、"シェル" でコンテナーに対して実行されるのではありません。

AKS の Backup には、次の 2 種類のフックがあります。

  • バックアップ フック
  • 復元フック

バックアップ フック

バックアップ フックを使用する場合は、カスタム アクション処理 (PreHooks) の前にフックを実行するようにコマンドを構成できます。 また、すべてのカスタム アクションが完了し、カスタム アクションで指定された追加項目がバックアップされた後にフックを実行することもできます (PostHooks)。

たとえば、バックアップ フックを使用してデプロイするカスタム リソースの YAML テンプレートを次に示します。

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
  # BackupHook CR Name and Namespace
  name: bkphookname0
  namespace: default
spec:
  # BackupHook is a list of hooks to execute before and after backing up a resource.
  backupHook:
    # BackupHook Name. This is the name of the hook that will be executed during backup.
    # compulsory
  - name: hook1
    # Namespaces where this hook will be executed.
    includedNamespaces: 
    - hrweb
    excludedNamespaces:
    labelSelector:
    # PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
    preHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute.
          command:
            - /bin/uname
            - -a
          # OnError specifies how Velero should behave if it encounters an error executing this hook  
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          timeout: 10s
      - exec:
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: webcontainer
          onError: Continue
    # PostHooks is a list of BackupResourceHooks to execute after backing up an item.
    postHooks:
      - exec:
          container: webcontainer
          command:
            - /bin/uname
            - -a
          onError: Continue
          timeout: 10s

復元フック

復元フック スクリプトでは、復元された AKS ポッドのコンテナーでカスタム コマンドまたはスクリプトを実行するように記述します。

復元フックを使用してデプロイされるカスタム リソースの YAML テンプレートを次に示します。

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
  name: restorehookname0
  namespace: default
spec:
  # RestoreHook is a list of hooks to execute after restoring a resource.
  restoreHook:
    # Name is the name of this hook.
  - name: myhook-1  
    # Restored Namespaces where this hook will be executed.
    includedNamespaces: 
    excludedNamespaces:
    labelSelector:
    # PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
    postHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute from within a container after a pod has been restored.
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          # OnError specifies how Velero should behave if it encounters an error executing this hook
          # default value is Continue
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          execTimeout: 30s
          # WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
          waitTimeout: 5m

AKS バックアップ中にフックを使用する方法については、こちらを参照してください。

復元中、バックアップ拡張機能はコンテナーが起動するまで待機し、復元フックで定義された exec コマンドを実行します。

バックアップされたのと同じ名前空間への復元を実行している場合、復元フックは実行されません。 新しく生成されたコンテナーだけを検索対象とします。 この結果は、スキップ ポリシーとパッチ ポリシーのどちらを使用するかに関係なく発生します。

AKS クラスターへのバックアップの復元中にリソースを変更する

リソース変更機能を使用すると、AKS クラスターにデプロイconfigmap パッチを指定することで、復元中にバックアップされた Kubernetes リソースを変更できます。

復元中にリソース修飾子の configmap を作成して適用する

リソースの変更を作成して適用するには、次の手順に従います。

  1. リソース修飾子 configmapを作成します。

    YAML ファイルで定義されたリソース修飾子から、あなたの好みの名前空間にconfigmapを1つ作成する必要があります。

    コマンドを作成する例:

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: "^mysql.*$"
    namespaces:
    - bar
    - foo
    labelSelector:
        matchLabels:
          foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"
  - operation: remove
    path: "/metadata/labels/test"
    • 前の configmap は、名前が と namespaces で始まる foo bar と mysql 内のすべての永続ボリューム コピーに match label foo: bar パッチを適用します。 JSON パッチは、 storageClassName を premium に置き換え、永続ボリューム のコピーから test ラベルを削除します。
    • ここで、 namespace はバックアップされたリソースの元の名前空間であり、リソースが復元される新しい名前空間ではありません。
    • 特定のリソースに対して複数の JSON パッチを指定できます。 パッチは、 configmapで指定された順序に従って適用されます。 次のパッチは順番に適用されます。 同じパスに複数のパッチが指定されている場合、最後のパッチは前のパッチをオーバーライドします。
    • resourceModifierRulesで複数のconfigmapを指定できます。 ルールは、 configmapで指定された順序に従って適用されます。

  2. 復元構成でリソース修飾子参照を作成する

    復元操作を実行するときは、復元構成の一部として展開する ConfigMap name と namespace を指定します。 これらの詳細は、リソース修飾子ルールで指定する必要があります。

    リソースの詳細を指定する場所を示すスクリーンショット。

リソース修飾子でサポートされる操作

  • 追加

    Add 操作を使用して、リソース JSON に新しいブロックを追加できます。 次の例では、この操作によって、デプロイを使用して新しいコンテナーの詳細が仕様に追加されます。

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
    # Dealing with complex values by escaping the yaml
  - operation: add
    path: "/spec/template/spec/containers/0"
    value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"

  • 削除

    Remove 操作を使用して、リソース JSON からキーを削除できます。 次の例では、操作によって、キーとして test ラベルが削除されます。

    version: v1
resourceModifierRules:
- conditions:
      groupResource: persistentvolumeclaims
      resourceNameRegex: "^mysql.*$"
      namespaces:
      - bar
      - foo
      labelSelector:
        matchLabels:
            foo: bar
  patches:
  - operation: remove
    path: "/metadata/labels/test"

  • 取り替える

    置換操作を使用することで、指定したパスの値を別の値に置き換えることができます。 次の例では、PVC の storageClassName を premiumに置き換えます。

    version: v1
resourceModifierRules:
- conditions:
     groupResource: persistentvolumeclaims
     resourceNameRegex: "^mysql.*$"
     namespaces:
     - bar
     - foo
     labelSelector:
        matchLabels:
           foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"

  • コピー

    コピー操作を使用することで、定義されたリソースからのあるパスから別のパスへと値をコピーできます。

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
  - operation: copy
    from: "/spec/template/spec/containers/0"
    path: "/spec/template/spec/containers/1"

  • テスト

    テスト操作を使用して、リソースに特定の値が存在するかどうかを確認できます。 値が存在する場合は、パッチが適用されます。 値が存在しない場合、パッチは適用されません。 以下の例では、この操作によって PVC の premium が StorageClassName であるかどうかが確認され、そうであれば standard に置き換えられます。

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: ".*"
    namespaces:
    - bar
    - foo
  patches:
  - operation: test
    path: "/spec/storageClassName"
    value: "premium"
  - operation: replace
    path: "/spec/storageClassName"
    value: "standard"

  • JSON パッチ

    このconfigmapは、既定で名前空間内のすべてのデプロイに JSON パッチを適用し、nginxで始まる名前でnginxdepします。 JSON パッチは、このようなすべてのデプロイに対してレプリカ数を 12 するように更新します。

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"

  • JSON マージパッチ

    このconfigmapは、既定およびnginxの名前空間内の、nginxdepで始まる名前を持つすべてのデプロイに JSON マージ パッチを適用します。 JSON マージ パッチは、app値でnginx1ラベルを追加または更新します。

    version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

  • 戦略的マージパッチ

    この configmap では、名前空間の既定のすべてのポッドに戦略的マージ パッチが適用され、名前は nginx で始まります。 戦略的マージ パッチは、コンテナー nginx のイメージを mcr.microsoft.com/cbl-mariner/base/nginx:1.22に更新します。

    version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
    resourceNameRegex: "^nginx.*$"
    namespaces:
    - default
  strategicPatches:
  - patchData: |
      {
        "spec": {
          "containers": [
            {
              "name": "nginx",
              "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22"
            }
          ]
        }
      }

AKS バックアップはどのバックアップ ストレージ層をサポートしますか?

AKS 用 Azure Backup は、バックアップ データストアとして 2 つのストレージ層をサポートします。

  • 運用レベル: AKS クラスターにインストールされているバックアップ拡張機能は、まず CSI ドライバーを介してボリューム スナップショットを取得することでバックアップを取得します。 次に、ユーザーのテナントの BLOB コンテナーにクラスターの状態が保存されます。 このレベルでは、2 つのバックアップの間の最小期間が 4 時間の低い目標復旧ポイント (RPO) がサポートされます。 さらに、Azure ディスク ベースのボリュームの場合、運用レベルでは迅速な復元がサポートされます。

  • コンテナー層: バックアップ データをスナップショットよりも低コストで長期間保存するために、AKS バックアップではコンテナー標準データストアがサポートされています。 バックアップ ポリシーで設定された保持ルールに従って、最初に成功したバックアップ (日、週、月、または年) がテナントの外部の BLOB コンテナーに移動されます。 このデータストアはより長い保持期間を実現するだけでなく、ランサムウェアの防止にも役立ちます。 また、バックアップ コンテナーで geo 冗長性 と リージョン間の復元 を有効にすることで、コンテナーに格納されているバックアップを別のリージョン (Azure ペア リージョン) に移動して復旧することもできます。

    注

    保持ルールを定義することで、Backup Policy を使用して、コンテナー標準データストアにバックアップ データを保存できます。 スケジュールされた復旧ポイントは、1 日に 1 つだけコンテナー層に移動されます。 ただし、選択したルールに従って、任意の数のオンデマンド バックアップをコンテナーに移動できます。

価格の詳細

次の料金が発生します。

  • 保護されたインスタンスの料金: Azure Backup for AKS では、名前空間ごとに 1 か月あたりの "保護されたインスタンスの料金" が請求されます。 AKS クラスターのバックアップを構成すると、保護されたインスタンスが作成されます。 各インスタンスには、バックアップ構成で定義されているとおりにバックアップされる特定の数の名前空間があります。 AKS バックアップの価格の詳細については、「 Azure Backup の価格 」を参照し、ワークロードとして Azure Kubernetes Service を選択します。

  • スナップショット料金: Azure Backup for AKS は、Azure サブスクリプションのリソース グループに格納されているスナップショットを取得することで、ディスク ベースの永続ボリュームを保護します。 これらのスナップショットには、スナップショット ストレージの料金が発生します。 スナップショットはバックアップ コンテナーにコピーされないため、バックアップ ストレージのコストは適用されません。 スナップショットの価格の詳細については、「 Managed Disks の価格」を参照してください。

  • バックアップ ストレージ料金: AKS 用 Azure Backup では、コンテナー層へのバックアップの格納もサポートされています。 バックアップ ポリシーでコンテナー標準の保持ルールを定義し、1 日に 1 つの復元ポイントをコンテナーに移動する資格を持つコンテナー層にバックアップを格納できます。 コンテナー層に格納されている復元ポイントには、バックアップ コンテナーに格納されている合計データ (ギガバイト単位) と冗長性の種類に応じて、個別の料金 (バックアップ ストレージ料金と呼ばれます) が課金されます。

関連コンテンツ