デフォルトでは、Container Service for Kubernetes (ACK) のバックアップセンター機能は、クラスターリソースをバックアップする際に、すべての実行時構成をバックアップします。ただし、アプリケーションの復元プロセス中に、O&M エンジニアは特定のパラメーターと構成を変更する必要がある場合があります。たとえば、ハイブリッドクラウドシナリオでは、異なるクラスターが異なるイメージリポジトリからイメージをプルする必要があります。この場合、image のアドレスを変更する必要があります。このトピックでは、StatefulSet をバックアップし、アプリケーションの復元中にリソース構成を変更する方法について説明します。
アプリケーションの復元中にリソース構成を変更する方法
デフォルトの変更
バックアップセンターコンポーネントがアプリケーションを復元すると、リソース構成が自動的に変更されます。通常、コンポーネントは次のリソース構成を変更します。
コンポーネントは、リソースの UID などの、一時的な情報を変更します。
コンポーネントは、ボリュームプラグインを FlexVolume から Container Storage Interface (CSI) に変更します。
コンポーネントは API を更新します。
復元がクラウド間で実行される場合、コンポーネントは関連設定を変更して互換性を確保します。
一般的な変更
復元タスクのパラメーターを手動で変更して、特定のリソース構成を変更できます。通常、次のリソース構成を変更できます。
リソースが属する名前空間を変更できます。
アプリケーションで使用される StorageClass とイメージアドレスを変更できます。
サービスと Ingress のアノテーションを上書きして、ネットワークプラグインとの互換性を有効にできます。
汎用修飾子
Velero が提供するリソース修飾子を使用して、必要に応じてリソース構成を変更できます。これを行うには、変更するパラメーターを指定する ConfigMap を作成する必要があります。これにより、JSON パッチを使用して add、delete、および replace 操作を実行できます。
デフォルトでは、ボリュームが復元されると、CSI プラグインは同じ StorageClass の新しいボリュームを動的にプロビジョニングします。この場合、リソース修飾子を使用してボリューム構成を変更することはできません。ボリューム構成を変更するには、ボリュームで使用される StorageClass を変換する必要があります。
リソース修飾子を使用するには、ロールベースアクセス制御 (RBAC) 管理者権限を取得する必要があります。リソース修飾子を使用して、リソースグループまたはセキュリティに依存するパラメーターを変更することはできません。 RBAC 管理者権限の付与方法の詳細については、「RBAC を使用してクラスター内のリソースに対する操作権限を管理する」をご参照ください。
前提条件
migrate-controller 1.8.1 以降がバックアップクラスターと復元クラスターの両方にインストールされていること。詳細については、「migrate-controller をインストールして権限を付与する」をご参照ください。
バックアップクラスターにバックアップボールトが作成されていること。詳細については、「バックアップボールトを作成する」をご参照ください。次の表に、バックアップボールトの基本情報を示します。
説明バックアップクラスター、復元クラスター、およびバックアップボールトが異なるリージョンにある場合、バックアップクラスターと復元クラスターの両方でパブリックネットワークアクセスを有効にする必要があります。
バックアップボールト名
OSS バケット名
OSS バケットサブディレクトリ
OSS バケットリージョン
表示範囲
vault
cnfs-oss-test
subpath
cn-beijing
<クエリに影響なし>
Velero リソース修飾子を使用する場合は、クラスターで Kubernetes 1.20 以降が実行されており、CSI プラグインが使用されていることを確認してください。
例
このセクションでは、NGINX アプリケーションをバックアップおよび復元する方法について説明します。アプリケーションがバックアップされると、アプリケーションを復元し、新しいアプリケーションが属する名前空間とイメージリポジトリアドレスを変更するための復元タスクが作成されます。また、リソース修飾子を使用して、アプリケーションで使用されるボリュームのマウントパスを変更し、ノードアフィニティルールを削除する方法についても説明します。
NGINX アプリケーションは、バックアップクラスターのデフォルトの名前空間にデプロイされた StatefulSet として実行され、OpenAnolis コミュニティのイメージを使用します。イメージアドレスは anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis です。 volumeClaimTemplates パラメーターがアプリケーション構成に追加され、alicloud-disk-topology-alltype StorageClass を使用する永続ボリューム要求 (PVC) がマウントされます。これにより、ディスクボリュームがアプリケーションに自動的にプロビジョニングされます。
次の YAML テンプレートは例です。
次のコマンドを実行して、アプリケーションが想定どおりに実行されているかどうか、およびボリュームがアプリケーションにマウントされているかどうかを確認します。
kubectl get pod && kubectl get pvc予期される出力:
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 39s
web-1 1/1 Running 0 30s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
www-web-0 Bound d-2zefofsg0uzoiaxxxxxx 20Gi RWO alicloud-disk-topology-alltype <unset> 3m18s
www-web-1 Bound d-2zedgdlghw2oudxxxxxx 20Gi RWO alicloud-disk-topology-alltype <unset> 30s手順 1:バックアップクラスターでアプリケーションをバックアップする
ACK コンソールまたは kubectl を使用してバックアップタスクを作成できます。
kubectl
バックアップクラスターに applicationbackup.yaml という名前のファイルを作成し、次のコンテンツをファイルに追加します。
apiVersion: csdr.alibabacloud.com/v1beta1 kind: ApplicationBackup metadata: # バックアップボールトがクラスターで使用されている場合、csdr.alibabacloud.com/backuplocations アノテーションは省略できます。 annotations: csdr.alibabacloud.com/backuplocations: '{"name":"<backuplocationName>","region":"<bucketRegion>","bucket":"<bucketName>","prefix":"<path>","provider":"alibabacloud"}' name: <backupName> namespace: csdr spec: backupType: AppAndPvBackup includedNamespaces: - default pvBackup: defaultPvBackup: true storageLocation: <backuplocationName> ttl: 720h0m0sバックアップクラスターで次のコマンドを実行して、applicationbackup オブジェクトをデプロイし、バックアップタスクを作成します。
kubectl apply -f applicationbackup.yaml次のコマンドを実行して、バックアップタスクが Completed 状態であるかどうかを確認します。
kubectl -ncsdr get applicationbackup <インスタントバックアップタスク名> --watch予期される出力:
NAME PHASE AGE <backupName> Completed 18s
ACK コンソール
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
システムは、バックアップサービスコンポーネントがインストールされているかどうかを自動的にチェックします。インストールされていない場合は、ページの指示に従ってバックアップサービスコンポーネントをインストールします。登録済みクラスターまたは ACK 専用クラスターを使用する場合は、権限も構成する必要があります。詳細については、「migrate-controller をインストールして権限を付与する」をご参照ください。
[アプリケーションバックアップ] ページで、[インスタントバックアップ] をクリックします。 [インスタントバックアップ] パネルで、パラメーターを構成し、[OK] をクリックします。詳細パラメーターの詳細については、「バックアッププランを作成するか、即座にバックアップする」をご参照ください。
パラメーター
説明
例
[名前]
インスタントバックアップタスクの名前。このパラメーターは必須です。
backup
バックアップボールト
使用するバックアップボールトを選択します。このパラメーターは必須です。
cnfs-oss-test
[バックアップタイプ]
[アプリケーションバックアップ]:クラスターリソースとアプリケーションで使用されるボリュームを含め、クラスターで実行されているアプリケーションをバックアップします。
[データ保護]:ボリュームデータをバックアップします。リソースには、永続ボリューム要求 (PVC) と永続ボリューム (PV) のみが含まれます。
詳細については、「アプリケーションバックアップとデータ保護のシナリオとは何ですか?」をご参照ください。
アプリケーションバックアップ
[バックアップ名前空間]
1 つ以上の名前空間を選択できます。このパラメーターは必須です。
説明kube-system、kube-publish、kube-node-lease、および csdr 名前空間はクラスターに依存しています。バックアップと復元機能は、これらの名前空間には適していません。したがって、これらの名前空間のアプリケーションをバックアップすることはできません。
default
[バックアップボリューム]
アプリケーションで使用されるボリュームのデータをバックアップするかどうかを指定します。
[マウントされたボリューム]:現在のデータは ECS スナップショットまたは Cloud Backup にバックアップされます。データを復元すると、システムは ECS スナップショットまたは Cloud Backup からバックアップデータを取得し、新しいディスクまたはその他の基盤となるストレージメディアにデータを復元します。
ディスクボリューム:デフォルトでは、システムは ECS スナップショットを使用してデータをバックアップおよび復元します。
その他のタイプのボリューム:システムは Cloud Backup を使用してデータをバックアップおよび復元します。
[無効]:システムは、ボリュームの基盤となるストレージメディアのデータをバックアップしません。データを復元すると、システムは YAML ファイルのみを復元します。ボリューム関連のリソースをバックアップおよび復元したくない場合は、除外リソースに PV と PVC を指定できます。
マウントされたボリューム
[バックアップレコード] タブの [アプリケーションバックアップ] ページで、バックアップレコードの [ステータス] 列に [完了] と表示されている場合、バックアップが作成されます。
(オプション)ステップ 2:OSS コンソールでリソースバックアップの JSON ファイルを表示する
JSON ファイルには、バックアップされるすべてのリソースに関する情報(リソースの名前、種類、サイズ、作成日など)が含まれています。 JSON ファイルを表示して、リストアするリソースがファイルに含まれているかどうかを確認できます。前提条件 で作成したバックアップボールトでバックアップタスクによって生成された JSON ファイルを表示する方法は次のとおりです。
OSS コンソールにログインします。
左側のナビゲーションウィンドウで、バケット をクリックします。[バケット] ページで、cnfs-oss-test バケットをクリックします。
左側のナビゲーションウィンドウで、[オブジェクト管理] > [オブジェクト] を選択します。
/subpath/backups/Instant backup task name>/パスで、<Instant backup task name>.tar.gzパッケージを見つけてダウンロードします。次に、パッケージを解凍してファイル内の情報を表示します。
ステップ 3: リストア クラスターでカスタム リソース変更ポリシーを構成する
カスタム リソース変更ポリシーには、conditions と patches の 2 つのパラメーターがあります。conditions パラメーターは、変更対象のリソースを選択するために使用されるルールを指定します。patches パラメーターは、変更するフィールドとフィールドの変更方法を指定します。次の ConfigMap は例です。ConfigMap は、条件を満たす StatefulSet とポッドのノード アフィニティ ルールを削除し、ボリューム マウント パスを /data に変更します。
次の表は、conditions パラメーターのフィールドについて説明しています。
フィールド | 説明 | 必須 | 例 |
| リソースが属する Kubernetes リソース グループ。カスタム リソースがサポートされています。
| はい |
|
| 変更対象のリソースが属する名前空間。 パラメーターを空のままにすると、すべての名前空間のリソースが変更されます。 名前空間マッピング機能を使用する場合、元の名前空間が優先されます。 | いいえ |
|
| 変更する Kubernetes リソース。 変更は、セレクターによって選択されたリソースにのみ適用されます。 | いいえ | |
| リソースを選択するために使用する正規表現。 変更は、正規表現に一致するリソースにのみ適用されます。 | いいえ |
|
次の表は、patches パラメーターのフィールドについて説明しています。
フィールド | 説明 | 必須 | 例 |
operation | 実行する操作。例: | はい |
|
path | 変更するフィールドのパス。 | はい |
|
value | 追加する新しい値、または元の値を置き換えるために使用する新しい値。このパラメーターは、 | いいえ |
|
(Optional) Step 4: バックアップボールトを初期化する
次の backuplocation.yaml の例を使用して、リストア クラスター内のバックアップボールトを初期化します。既に初期化されている場合は、この手順をスキップします。
apiVersion: csdr.alibabacloud.com/v1beta1
kind: BackupLocation
metadata:
name: <backup-vault-name>
namespace: csdr
spec:
backupSyncPeriod: 0s
# バックアップボールトの初期設定と一致する必要があります。コンソールから初期化することもできます。
config:
network: internal
region: <oss-bucket-region>
objectStorage:
bucket: <oss-bucket-name>
prefix: <oss-bucket-subpath>
provider: alibabacloudステップ 5: リストア クラスターで変更されたアプリケーションをリストアする
変更されたアプリケーションをデプロイするために、リストア クラスターにリストア タスクを作成します。リストア タスクは、前のステップで設定した カスタム リソース変更ポリシー を参照します。リストア タスクは、namespaceMapping パラメーターと imageRegistryMapping パラメーターを使用して、Map 形式の名前空間マッピングとイメージ リポジトリ マッピングを有効にします。
applicationrestore.yaml という名前のファイルを作成し、次のコード ブロックをファイルにコピーします。
このファイルは、
default1名前空間のリソース(ボリュームを含む)を default1 名前空間にリストアするリストア タスクを作成するために使用されます。リストア タスクは、OpenAnolis コミュニティによって提供されるアプリケーションで使用されるイメージ アドレスを、Container Registry によって提供されるイメージ アドレスに変更します。イメージ アドレスを変更する前に、イメージが同期されていることを確認してください。apiVersion: csdr.alibabacloud.com/v1beta1 kind: ApplicationRestore metadata: name: <restoreName> namespace: csdr spec: backupName: <backupName> namespaceMapping: default: default1 # バックアップ ファイルがリストアされる default1 名前空間。 imageRegistryMapping: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis: registry.cn-beijing.aliyuncs.com/<acrRegistry> # イメージ アドレスを変更する前に、イメージが元のイメージ リポジトリから新しいイメージ リポジトリに同期されていることを確認してください。 resourceModifier: kind: ConfigMap name: <backupName>-resource-modifierリストア クラスターで次のコマンドを実行して、applicationrestore オブジェクトをデプロイし、リストア タスクを作成します。
kubectl apply -f applicationrestore.yamlリストア タスクをクエリするには、次のコマンドを実行します。
説明ACK コンソールでリストア タスクを表示することもできます。詳細については、「ステップ 3: アプリケーションとボリュームのリストア」をご参照ください。
kubectl -n csdr get applicationrestore <restoreName> --watch期待される出力:
NAME PHASE AGE <restoreName> Completed 18h
ステップ 6: アプリケーションがリストアされているかどうかを確認する
リストアされた StatefulSet をクエリするには、次のコマンドを実行します。
kubectl -n default1 get sts web -oyaml予想される出力:
出力は、イメージアドレス、ボリュームマウントパス、および名前空間が変更されていることを示しています。さらに、ノードアフィニティルールは削除されています。
YAML ファイルの一部の新しいパラメーターは、Kubernetes によって自動的に追加されます。