バックアッププランで Permissive モードを有効にする

Autopilot Standard

このページでは、バックアッププランで制約なしモードを有効にする方法について説明します。

バックアップの実行中に、復元が失敗する可能性のある条件が Backup for GKE によって検出されると、バックアップ自体が失敗します。失敗の理由は、バックアップの state_reason フィールドに示されます。Google Cloud コンソールでは、このフィールドは「ステータスの理由」と表示されます。

制約なしモードを有効にすると、[ステータスの理由] フィールドに問題の説明が表示されますが、バックアップは失敗しません。この設定は、問題を認識しており、復元時に回避策を採用する準備ができている場合に有効にしてください。

次の例は、バックアップの [ステータスの理由] フィールドに表示され、制約なしモードの有効化を推奨するエラーメッセージの例です。 If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

制約なしモードを有効にします。

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

次のように置き換えます。

BACKUP_PLAN: 更新するバックアッププランの名前。
PROJECT_ID: Google Cloud プロジェクトの ID。
LOCATION: リソースのコンピューティングリージョン（us-central1 など）。リソースのロケーションについてをご覧ください。

オプションの完全なリストについては、gcloud beta container backup-restore backup-plans update のドキュメントをご覧ください。

コンソール

Google Cloud コンソールで制約なしモードを有効にするには、次の操作を行います。

Google Cloud コンソールで、Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
ナビゲーションメニューで [Backup for GKE] をクリックします。
[バックアッププラン] タブをクリックします。
クラスタを開き、プラン名をクリックします。
[詳細] タブをクリックして、プランの詳細を編集します。
[編集] をクリックして、[バックアップモード] のセクションを編集します。
[制約なしモード] チェックボックスをオンにして、[変更を保存] をクリックします。

Terraform

既存の google_gke_backup_backup_plan リソースを更新します。

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

次のように置き換えます。

NAME: 更新する google_gke_backup_backup_plan の名前

詳細については、gke_backup_backup_plan をご覧ください。

バックアップエラーのトラブルシューティング

次の表に、バックアップの [ステータスの理由] フィールドに表示されるさまざまなバックアップエラーメッセージの説明と推奨される対応を示します。

バックアップエラーメッセージ	メッセージの説明と失敗の理由	推奨される対応
`CustomResourceDefinitions "..." have invalid schemas`	説明: クラスタ内のカスタムリソース定義（CRD）は、元々 `apiextensions.k8s.io/v1beta1` として適用されたため、`apiextensions.k8s.io/v1` で必要な構造スキーマがありません。理由: Backup for GKE は構造スキーマを自動的に定義できません。`apiextensions.k8s.io/v1beta1` を使用できない Kubernetes v1.22 以降のクラスタで CRD を復元すると、復元が失敗します。この問題は、CRD で定義されたカスタムリソースを復元するときに発生します。	次のオプションを使用することをおすすめします。 CRD を管理する場合は、Kubernetes のドキュメントの手順に沿って、CRD の構造スキーマを指定します。 GKE マネージド CRD の場合、CRD によって提供される既存のリソースがなければ `kubectl delete crd` を呼び出すことができます。CRD によって提供されている既存のリソースがある場合は、復元動作を理解したうえで、制約なしモードを有効にできます。一般的な CRD に関する推奨事項については、ドキュメントをご覧ください。サードパーティの CRD の場合は、関連ドキュメントを参照して `apiextensions.k8s.io/v1` に移行します。制約なしモードが有効になっている場合、構造スキーマのない CRD は Kubernetes v1.22 以降のクラスタでバックアップされません。このようなバックアップを正常に復元するには、CRD によって提供されるリソースを復元から除外するか、復元を開始する前にターゲットクラスタに CRD を作成する必要があります。
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	説明: ソースクラスタで、PVC が Persistent Disk ボリュームではない PV にバインドされています。理由: Backup for GKE は、Persistent Disk ボリュームデータのバックアップのみをサポートしています。「新しいボリュームをプロビジョニングし、バックアップからボリュームデータを復元する」ポリシーで復元される Persistent Disk 以外の PVC には、ボリュームデータが復元されません。ただし、「データを含む既存のボリュームを再利用する」ポリシーを使用すると、PVC を元のボリュームハンドルに再接続できます。これは、NFS などの外部サーバーがバッキングするボリュームタイプに有効です。	ソースクラスタの Persistent Disk 以外のボリュームで使用可能な復元オプションを理解して、制約なしモードを有効にします。Filestore ボリュームのバックアップについては、Backup for GKE を使用して Filestore ボリュームを処理するをご覧ください。制約なしモードが有効になっている場合、PVC 構成はバックアップされますが、ボリュームデータはバックアップされません。
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	説明: クラスタ内の PVC が PV にバインドされていません。理由: Backup for GKE は PVC をバックアップできますが、バックアップするボリュームデータがありません。この状況は、構成ミスや、リクエストされたストレージと使用可能なストレージの不一致を示している可能性があります。	未使用の PVC が許容範囲内の状態であることを確認します。その場合は、制約なしモードを有効にします。バックアップ動作への影響に注意してください。制約なしモードが有効になっている場合、PVC 構成はバックアップされますが、バックアップするボリュームデータがありません。
`Failed to query API resources ...`	説明: クラスタ内の API サービスの構成が正しくありません。これにより、API パスへのリクエストで「Failed to query API resources」というエラーが返されます。基盤となるサービスが存在しないか、準備ができていない可能性があります。理由: 使用できない API によって提供されるリソースを Backup for GKE でバックアップすることはできません。	API サービスの `spec.service` で基盤となるサービスを確認し、準備ができていることを確認します。制約なしモードが有効になっている場合、読み込みに失敗した API グループのリソースはバックアップされません。
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	説明: Kubernetes v1.23 以前では、サービスアカウントは Secret でバックアップされたトークンを自動的に生成します。ただし、後続のバージョンでは、Kubernetes からこの自動生成トークン機能が削除されました。クラスタ内の Pod が、Secret ボリュームをコンテナのファイルシステムにマウントしている可能性があります。理由: Backup for GKE が、自動生成された Secret と Secret ボリュームをマウントする Pod とともにサービスアカウントの復元を試みると、復元は成功したように見えます。しかし、Kubernetes は Secret を削除するため、Pod はコンテナの作成で停止し、起動に失敗します。	Pod で `spec.serviceAccountName` フィールドを定義します。このアクションにより、トークンがコンテナ内の `/var/run/secrets/kubernetes.io/serviceaccount` に自動的にマウントされます。詳細については、Pod のサービスアカウントを構成するのドキュメントをご覧ください。制約なしモードを有効にすると、Secret はバックアップされますが、Kubernetes v1.24 以降のクラスタの Pod にはマウントできません。

問題のある一般的な CRD と推奨される対応

バックアップの問題が発生する一般的な CRD と、問題に対処するために推奨される対応策を次に示します。

capacityrequests.internal.autoscaling.k8s.io: この CRD は v1.21 クラスタで一時的に使用されました。kubectl delete crd capacityrequests.internal.autoscaling.k8s.io を実行して CRD を削除します。
scalingpolicies.scalingpolicy.kope.io: この CRD は fluentd リソースの制御に使用されていましたが、GKE は fluentbit の使用に移行しました。kubectl delete crd scalingpolicies.scalingpolicy.kope.io を実行して CRD を削除します。
memberships.hub.gke.io: メンバーシップリソースがない場合は、kubectl delete crd memberships.hub.gke.io を実行して CRD を削除します。メンバーシップリソースがある場合は、制約なしモードを有効にします。
applications.app.k8s.io: 復元の動作を理解したうえで制約なしモードを有効にします。

バックアップエラーメッセージ	メッセージの説明と失敗の理由	推奨される対応
`CustomResourceDefinitions "..." have invalid schemas`	説明: クラスタ内のカスタムリソース定義（CRD）は、元々 `apiextensions.k8s.io/v1beta1` として適用されたため、`apiextensions.k8s.io/v1` で必要な構造スキーマがありません。理由: Backup for GKE は構造スキーマを自動的に定義できません。`apiextensions.k8s.io/v1beta1` を使用できない Kubernetes v1.22 以降のクラスタで CRD を復元すると、復元が失敗します。この問題は、CRD で定義されたカスタムリソースを復元するときに発生します。	次のオプションを使用することをおすすめします。 CRD を管理する場合は、Kubernetes のドキュメントの手順に沿って、CRD の構造スキーマを指定します。 GKE マネージド CRD の場合、CRD によって提供される既存のリソースがなければ `kubectl delete crd` を呼び出すことができます。CRD によって提供されている既存のリソースがある場合は、復元動作を理解したうえで、制約なしモードを有効にできます。一般的な CRD に関する推奨事項については、ドキュメントをご覧ください。サードパーティの CRD の場合は、関連ドキュメントを参照して `apiextensions.k8s.io/v1` に移行します。制約なしモードが有効になっている場合、構造スキーマのない CRD は Kubernetes v1.22 以降のクラスタでバックアップされません。このようなバックアップを正常に復元するには、CRD によって提供されるリソースを復元から除外するか、復元を開始する前にターゲットクラスタに CRD を作成する必要があります。
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	説明: ソースクラスタで、PVC が Persistent Disk ボリュームではない PV にバインドされています。理由: Backup for GKE は、Persistent Disk ボリュームデータのバックアップのみをサポートしています。「新しいボリュームをプロビジョニングし、バックアップからボリュームデータを復元する」ポリシーで復元される Persistent Disk 以外の PVC には、ボリュームデータが復元されません。ただし、「データを含む既存のボリュームを再利用する」ポリシーを使用すると、PVC を元のボリュームハンドルに再接続できます。これは、NFS などの外部サーバーがバッキングするボリュームタイプに有効です。	ソースクラスタの Persistent Disk 以外のボリュームで使用可能な復元オプションを理解して、制約なしモードを有効にします。Filestore ボリュームのバックアップについては、Backup for GKE を使用して Filestore ボリュームを処理するをご覧ください。制約なしモードが有効になっている場合、PVC 構成はバックアップされますが、ボリュームデータはバックアップされません。
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	説明: クラスタ内の PVC が PV にバインドされていません。理由: Backup for GKE は PVC をバックアップできますが、バックアップするボリュームデータがありません。この状況は、構成ミスや、リクエストされたストレージと使用可能なストレージの不一致を示している可能性があります。	未使用の PVC が許容範囲内の状態であることを確認します。その場合は、制約なしモードを有効にします。バックアップ動作への影響に注意してください。制約なしモードが有効になっている場合、PVC 構成はバックアップされますが、バックアップするボリュームデータがありません。
`Failed to query API resources ...`	説明: クラスタ内の API サービスの構成が正しくありません。これにより、API パスへのリクエストで「Failed to query API resources」というエラーが返されます。基盤となるサービスが存在しないか、準備ができていない可能性があります。理由: 使用できない API によって提供されるリソースを Backup for GKE でバックアップすることはできません。	API サービスの `spec.service` で基盤となるサービスを確認し、準備ができていることを確認します。制約なしモードが有効になっている場合、読み込みに失敗した API グループのリソースはバックアップされません。
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	説明: Kubernetes v1.23 以前では、サービスアカウントは Secret でバックアップされたトークンを自動的に生成します。ただし、後続のバージョンでは、Kubernetes からこの自動生成トークン機能が削除されました。クラスタ内の Pod が、Secret ボリュームをコンテナのファイルシステムにマウントしている可能性があります。理由: Backup for GKE が、自動生成された Secret と Secret ボリュームをマウントする Pod とともにサービスアカウントの復元を試みると、復元は成功したように見えます。しかし、Kubernetes は Secret を削除するため、Pod はコンテナの作成で停止し、起動に失敗します。	Pod で `spec.serviceAccountName` フィールドを定義します。このアクションにより、トークンがコンテナ内の `/var/run/secrets/kubernetes.io/serviceaccount` に自動的にマウントされます。詳細については、Pod のサービスアカウントを構成するのドキュメントをご覧ください。制約なしモードを有効にすると、Secret はバックアップされますが、Kubernetes v1.24 以降のクラスタの Pod にはマウントできません。