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>
次のステップ
- 詳しくは、一連のバックアップのプランニングをご覧ください。