Google Kubernetes Engine クラスタで Backup for GKE エージェントを有効にすると、Backup for GKE によって CustomResourceDefinition が提供されます。これにより、新しい種類の Kubernetes リソース ProtectedApplication が導入されます。
ProtectedApplication の作成では、次の 3 つの操作を行います。
アプリケーションの一部としてバックアップと復元を行うリソースセットを選択する。
リソースのサブセットに詳細なオーケストレーション ルールを定義する。
ProtectedApplicationを検証して、バックアップの準備ができているかどうかを確認する。
ProtectedApplication リソースを使用すると、バックアップと復元のロジックをアプリケーション レベルでカスタマイズする際に、次の機能を使用できます。
より詳細なバックアップと復元。
ProtectedApplicationsを使用しない場合は、バックアップのスコープをNamespaceレベルで定義する必要があります（allNamespaces または selectedNamespaces を選択）。名前空間付きリソースの復元にも同様のロジックが適用されます。ProtectedApplicationリソースを作成すると、Namespace内のリソースのサブセットに名前を指定できます。その後、バックアップ スコープで selectedApplications をリストして、サブセットのバックアップと復元を行うこともできます（復元の場合も同様です）。バックアップまたは復元のプロセスの詳細なオーケストレーション
バックアップ時に選択したボリュームをスキップします。
アプリケーション トポロジをバックアップと復元に組み込みます（たとえば、複製されたデータベースの 1 つのインスタンスのみをバックアップし、それを使用して複数のインスタンスを復元します）。
ボリュームのスナップショットの前後にユーザー定義のフックを実行します。たとえば、スナップショットを作成する前にワークロードをフラッシュして停止させ、完了後に停止を解除します。
他の Kubernetes リソースと同様に、kubectl を使用して ProtectedApplication を作成します。これらはすべて任意です。ProtectedApplication リソースが存在しない場合、Backup for GKE は、バックアップ スコープ内のすべてのボリュームに対してボリューム バックアップを作成します。その結果、ボリュームのバックアップがクラッシュ整合性を持ちます。特定の時点でディスクにフラッシュされたすべての書き込みがキャプチャされます（つまり、部分的な書き込みはありません）。ただし、一部のアプリケーションでは、ディスクにフラッシュされていないデータをメモリに保持することがあるため、アプリケーションがクラッシュ整合性のあるバックアップから正常に復元できるかどうかは、アプリケーション ロジックによって異なります。
リソースの選択
ProtectedApplication リソースを作成する最初のステップは、アプリケーションの一部として含める同じ Namespace 内のリソースを特定することです。これは、BackupPlan 構成で selectedApplications スコープ オプションを指定した場合にバックアップまたは復元されるリソースのセットです。
リソースは、ラベルセレクタを使用して識別されます。そのためには、すべてのリソースに（各リソースの metadata.label フィールドを使用して）同じラベルを付ける必要があります。これは、コントローラによって自動的に作成されるリソースにも該当します。自動的に作成されたこれらのリソースには、対応するテンプレートによってラベルが設定されます。すでに使用しているラベルを再利用して、生成された Pods と PersistentVolumeClaims を親リソースに関連付けるのが一般的です。
使用上の考慮事項は次のとおりです。
- 子リソースを作成するリソースを保護する場合は、親リソース（
StatefulSet、Deployment、DaemonSetなど）と子リソース（Pod、PersistentVolumeClaimなど）の両方に、ProtectedApplicationのSelectorフィールドで使用されるラベルが必要です。 ProtectedApplicationで参照される一部のリソースがオペレーターによって自動的に作成される場合は、ProtectedApplicationセレクタにオペレーターのカスタム リソースを含める必要があります。これにより、オペレーターがリソースの作成を試みるのと同時にバックアップから復元された場合に発生する、復元時間の競合状態を回避できます。
次の例では、Deployment に加えて、他のリソースにも app: nginx ラベルを適用しています。
apiVersion: v1 kind: ConfigMap metadata: name: nginx-vars namespace: webserver labels: app: nginx data: ... --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nginx-logs namespace: webserver labels: app: nginx spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Mi storageClassName: standard-rwo --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: webserver labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: volumes: - name: nginx-logs persistentVolumeClaim: claimName: nginx-logs containers: ... 選択したラベルをすべてのターゲット リソース（追加リソースの生成元となるテンプレートを含む）に適用すると、ProtectedApplication からそれらのリソースを参照できます。次に例を示します。
kind: ProtectedApplication apiVersion: gkebackup.gke.io/v1 metadata: name: nginx namespace: webserver spec: resourceSelection: type: Selector selector: matchLabels: app: nginx ... オーケストレーション ルールを定義する
ProtectedApplication 内のすべてのリソースを特定したら、それらのリソースのサブセットに詳細なオーケストレーション ルールを定義できます。これらのルールは、Deployment と StatefulSet の 2 種類のリソースにのみ適用されます。これらは ProtectedApplication の components セクションで参照されています。
コンポーネントの概要
コンポーネントの構成では、次のことを行います。
このコンポーネントのバックアップと復元に関する基本的な戦略を選択します。次の 3 つの戦略があります。
BackupAllRestoreAll- コンポーネントのすべてのインスタンスに関連付けられたボリュームをバックアップし、すべてをバックアップから復元するBackupOneRestoreAll- コンポーネントの 1 つのインスタンスのボリュームをバックアップし、そのバックアップを使用してすべてのインスタンスを復元するDumpAndLoad- バックアップ時にアプリケーションから単一ボリュームにデータをエクスポートし、復元時にそのデータをアプリケーションにインポートする
バックアップ時に実行する実行フックを定義します（戦略によっては復元時にも実行します）。フックは、特定のコンテナで実行されるコマンドです。
実行フック
フックは、バックアップまたは復元プロセスの特定のフェーズで Backup for GKE がコンテナ内で実行するシェルコマンドです。
フックには次の 4 種類があります。
pre hooks- このコマンドは、ボリュームがバックアップされる直前に実行されます。ディスクに新しい書き込みが発生しないよう、通常はメモリ内のデータをディスクにフラッシュしてから、アプリケーションを停止します。このフックは、BackupAllRestoreAll戦略とBackupOneRestoreAll戦略で使用されます。post hooks- このコマンドは、ボリューム バックアップ プロセスの SNAPSHOTTING ステップの直後（UPLOADING ステップの前）のボリューム バックアップ プロセスで実行されます。通常、SNAPSHOTTING ステップにかかる時間は数秒です。通常、アプリケーションは停止解除状態になります（つまり、通常の処理とディスクの書き込みを続行します）。このフックは、BackupAllRestoreAll、BackupOneRestoreAll、DumpAndLoadの各戦略で使用されます。dump hooks- このコマンドは、DumpAndLoad戦略でボリュームがバックアップされる前に実行されます。通常、アプリケーションから指定のバックアップ ボリュームにデータをエクスポートします。load hooks- このコマンドは、DumpAndLoad戦略でバックアップ ボリュームが復元された後に実行されます。通常は、バックアップ ボリュームからアプリケーションにデータをインポートします。
タイプごとに複数のフックを指定することができ、Backup for GKE は定義された順序でこれらのフックを実行します。
フックは、ProtectedApplication 仕様のコンポーネント セクションの一部として定義します。フックの定義で使用できるフィールドは次のとおりです。
name- フックに割り当てた名前。container- （省略可）コマンドを実行するコンテナの名前。コンテナを指定しない場合、Backup for GKE はターゲットPodに定義された最初のコンテナでフックを実行します。command- コンテナに送信される実際のコマンド。単語の配列として構成されます。配列の最初の単語はコマンドのパスで、以降はコマンドに渡される引数です。timeoutSeconds- （省略可）フックの実行を中止するまでの時間。指定しない場合、デフォルトで 30 秒に設定されます。onError- （省略可）フックが失敗したときの動作。IgnoreまたはFail（デフォルト）に設定できます。Failに設定した場合、フックが失敗すると、ボリュームのバックアップも失敗します。Ignoreに設定すると、このフックの失敗は無視されます。
フックが期待どおりに動作することを確認するには、ProtectedApplication フックをアプリケーションに適用する前に、kubectl exec を使用してコマンドをテストする必要があります。
kubectl exec POD_NAME -- COMMAND 次のように置き換えます。
POD_NAME:ProtectedApplicationリソースを含む Pod の名前。COMMAND: コンテナで実行するコマンドを含む配列。
バックアップするボリュームのサブセットの選択
アプリケーションによっては、復元に関係のないボリュームに書き込みを行う場合があります（たとえば、特定のログやスクラッチ ボリュームなど）。これらのボリュームのバックアップを抑制するには、ボリューム セレクタを使用します。
この機能を使用するには、まずバックアップするボリュームの PersistentVolumeClaim リソースに共通のラベルを適用する必要があります。また、バックアップしないボリュームの PersistentVolumeClaim リソースには、このラベルを付けない必要があります。その後、次のようにコンポーネント定義に volumeSelector 句を含めます。
spec: ... components: ... strategy: ... volumeSelector: matchLabels: label_name: label_value コンポーネントに volumeSelector を指定すると、PersistentVolumeClaim リソースに特定のラベルが付いているボリュームのみがバックアップおよび復元されます。復元時に、他のボリュームはボリューム バックアップから復元されるのではなく、空のものとしてプロビジョニングされます。
戦略: BackupAllRestoreAll
最もシンプルな戦略で、バックアップ時にはコンポーネントのすべてのボリュームがバックアップされ、復元時にはそのすべてがボリュームのバックアップから復元されます。これは、アプリケーションで Pods 間のレプリケーションがない場合に最適です。
この戦略は、次のパラメータをサポートしています。
backupPreHooks- （省略可）ボリュームがバックアップされる直前に実行されるフックの順序付きリスト。これらのコマンドは、コンポーネント内のすべてのPodsで実行されます。backupPostHooks- （省略可）ボリュームのバックアップが UPLOADING フェーズに達した後に実行されるフックの順序付きリスト。これらのコマンドは、コンポーネント内のすべてのPodsで実行されます。volumeSelector- （省略可）バックアップするボリュームのサブセットを照合するロジック。
この例では、ログボリュームをバックアップする前にファイル システムを停止し、バックアップの後に停止する ProtectedApplication リソースを作成します。
kind: ProtectedApplication apiVersion: gkebackup.gke.io/v1 metadata: name: nginx namespace: sales spec: resourceSelection: type: Selector selector: matchLabels: app: nginx components: - name: nginx-app resourceKind: Deployment resourceNames: ["nginx-deployment"] strategy: type: BackupAllRestoreAll backupAllRestoreAll: backupPreHooks: - name: freeze container: nginx command: - bash - "-c" - | # Add application logic to flush data to disk before snapshot # and freeze the application from further changes. echo "Freezing the application" # Return 0 on successful freeze of application, and non-zero # for errors exit 0 backupPostHooks: - name: unfreeze container: nginx command: - bash - "-c" - | # Add application logic to unfreeze the application. echo "Unfreezing the application" # Return 0 on successful freeze of application, and non-zero # for errors exit 0 戦略: BackupOneAndRestoreAll
この戦略では、選択した Pod のコピーを 1 つバックアップします。この単一コピーは、復元中にすべての Pod を復元するソースです。この方法は、ストレージ費用を削減しバックアップ時間を短縮するのに役立ちます。この戦略は、1 つのプライマリ PersistentVolumeClaim と複数のセカンダリ PersistentVolumeClaims でコンポーネントがデプロイされている場合に、高可用性構成で機能します。
この戦略は、次のパラメータをサポートしています。
backupTargetName- （必須）データのバックアップに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。高可用性構成の場合は、これをアプリケーション レプリカのいずれかに設定することをおすすめします。backupPreHooks- （省略可）ボリュームがバックアップされる直前に実行されるフックの順序付きリスト。これらのコマンドは、選択したバックアップPodでのみ実行されます。backupPostHooks- （省略可）ボリュームのバックアップが UPLOADING フェーズに達した後に実行されるフックの順序付きリスト。これらのコマンドは、選択したバックアップPodでのみ実行されます。volumeSelector- （省略可）バックアップするボリュームのサブセットを照合するロジック。
コンポーネントが複数の Deployment または StatefulSet で構成されている場合は、すべてのリソースが同じ PersistentVolume 構造になっている必要があります。つまり、次のルールに従う必要があります。
- すべての Deployment または StatefulSet で使用される
PersistentVolumeClaimsの数は同じである必要があります。 - 同じインデックス内の
PersistentVolumeClaimsの目的は同じである必要があります。StatefulSet で、インデックスはvolumeClaimTemplateで定義されます。Deployment で、インデックスはVolumesで定義され、非永続ボリュームはスキップされます。 - アプリケーション コンポーネントが Deployment で構成されている場合、各 Deployment には 1 つのレプリカが必要です。
これらの考慮事項を前提に、バックアップには複数のボリューム セットを選択できますが、各ボリューム セットから選択されるボリュームは 1 つだけです。
この例は、1 つのプライマリ StatefulSet とセカンダリ StatefulSet のアーキテクチャを想定し、セカンダリ StatefulSet に 1 つの Pod のボリュームのバックアップがあり、その後、他のすべてのボリュームに復元されることを示しています。
kind: ProtectedApplication apiVersion: gkebackup.gke.io/v1 metadata: name: mariadb namespace: mariadb spec: resourceSelection: type: Selector selector: matchLabels: app: mariadb components: - name: mariadb resourceKind: StatefulSet resourceNames: ["mariadb-primary", "mariadb-secondary"] strategy: type: BackupOneRestoreAll backupOneRestoreAll: backupTargetName: mariadb-secondary backupPreHooks: - name: quiesce container: mariadb command: [...] backupPostHooks: - name: unquiesce container: mariadb command: [...] 戦略: DumpAndLoad
この戦略では、バックアップと復元のプロセスに専用のボリュームが使用されます。ダンプデータを格納するコンポーネントには、専用の PersistentVolumeClaim が接続されている必要があります。
この戦略は、次のパラメータをサポートしています。
dumpTarget- （必須）データのバックアップに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。高可用性構成の場合は、これをアプリケーション レプリカのいずれかに設定することをおすすめします。loadTarget- （必須）データの読み込みに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。読み込みターゲットは、ダンプ ターゲットと同じにする必要はありません。dumpHooks- （必須）専用のバックアップ ボリュームを設定するために実行されるフックの順序付きリスト。これらのコマンドは、選択したダンプPodに対してのみ実行されます。backupPostHooks- （省略可）ボリュームのバックアップが UPLOADING フェーズに達した後に実行されるフックの順序付きリスト。これらのコマンドは、選択したダンプPodでのみ実行されます。loadHooks- （必須）アプリケーションの起動後に復元されたボリュームからデータを読み込むために実行されるフックの順序付きリスト。これらのコマンドは、選択した読み込みPodでのみ実行されます。volumeSelector- （必須）1 つのボリューム（ダンプ ボリューム）をバックアップおよび復元に一致させるためのロジック。一致させるボリュームは 1 つだけですが、この構成は、他の戦略で使用されるバックアップするボリュームのサブセットと同じ方法で行います。
アプリケーションが Deployment で構成されている場合、各 Deployment には 1 つのレプリカが必要です。
この例では、プライマリ StatefulSet とセカンダリ StatefulSet の両方に専用の PersistentVolumeClaims を持つ 1 つのプライマリ StatefulSet とセカンダリ StatefulSet のアーキテクチャを想定し、DumpAndLoad の戦略を示しています。
kind: ProtectedApplication apiVersion: gkebackup.gke.io/v1 metadata: name: mariadb namespace: mariadb spec: resourceSelection: type: Selector selector: matchLabels: app: mariadb components: - name: mariadb-dump resourceKind: StatefulSet resourceNames: ["mariadb-primary", "mariadb-secondary"] strategy: type: DumpAndLoad dumpAndLoad: loadTarget: mariadb-primary dumpTarget: mariadb-secondary dumpHooks: - name: db_dump container: mariadb command: - bash - "-c" - | mysqldump -u root --all-databases > /backup/mysql_backup.dump loadHooks: - name: db_load container: mariadb command: - bash - "-c" - | mysql -u root < /backup/mysql_backup.sql volumeSelector: matchLabels: gkebackup.gke.io/backup: dedicated-volume ProtectedApplication がバックアップの準備ができているかどうかを確認する
次のコマンドを実行して、ProtectedApplication がバックアップの準備ができているかどうかを確認できます。
kubectl describe protectedapplication APPLICATION_NAME APPLICATION_NAME は、アプリケーションの名前に置き換えます。
準備ができると、次の例のように、アプリケーションの説明には Ready to backup ステータスが true として表示されます。
% kubectl describe protectedapplication nginx Name: nginx Namespace: default API Version: gkebackup.gke.io/v1 Kind: ProtectedApplication Metadata: UID: 90c04a86-9dcd-48f2-abbf-5d84f979b2c2 Spec: Components: Name: nginx Resource Kind: Deployment Resource Names: nginx Strategy: Backup All Restore All: Backup Pre Hooks: Command: /sbin/fsfreeze -f /var/log/nginx Container: nginx Name: freeze Backup Post Hooks: Command: /sbin/fsfreeze -u /var/log/nginx Container: nginx Name: unfreeze Type: BackupAllRestoreAll Resource Selection: Selector: Match Labels: app: nginx Type: Selector Status: Ready To Backup: true Events: <none> 次のステップ
- 詳しくは、一連のバックアップのプランニングをご覧ください。