Veleroを使用して、TKEでクラスターリソースを移行および複製します

概要概要

Velero（以前はHeptio Arkと呼ばれていました）は、安全にバックアップと復元、ディザスタリカバリを実行し、Kubernetesクラスタリソースと永続ボリュームを移行できるオープンソースツールです。Veleroは、次の目的でTKEクラスタまたは自己構築型Kubernetesクラスタにデプロイできます。

クラスターをバックアップし、失われた場合に備えて復元します。
クラスターリソースを他のクラスターに移行します。
本番クラスターを開発クラスターとテストクラスターにコピーします。

Veleroの詳細については、Veleroの公式Webサイトを参照してください。この記事では、Veleroを使用してTKEクラスター間でクラスターリソースをシームレスに移行および複製する手順を紹介します。

移行の原則

移行するクラスターとターゲットクラスターの両方にVeleroインスタンスをインストールし、2つのクラスターのVeleroインスタンスが同じTencent Cloud COSオブジェクトストレージの場所を指すようにします。Veleroを使用して、移行するクラスターでバックアップ操作を実行し、バックアップを生成します。データを取得してTencentCloud COSに保存し、ターゲットクラスターでVeleroを使用してデータ復元操作を実行し、移行を実現します。移行の原則は次のとおりです。

前提条件

Tencentクラウドアカウントを登録しました。
Tencent CloudCOSサービスが開始されました。
移行する必要があるTKEクラスター（以下、クラスターA）、TKEクラスター（以下、クラスターB）の移行ターゲットを作成しました。TKEはクラスターを作成します。「クラスターの作成」を参照してください。
Veleroインスタンス（バージョン1.5以降）をインストールし、COS TencentクラウドVeleroバックエンドストレージと同じバケットを共有するには、クラスターBとクラスターが必要です。インストール手順の構成ストレージとVeleroのインストールを参照してください。

予防

バージョン1.5以降、VeleroはResticを使用して、各ポッドに個別に注釈を付けることなく、すべてのポッドボリュームをバックアップできます。デフォルトでは、この機能により、ユーザーは、次のボリューム条件を除いて、resticを使用してすべてのポッドボリュームをバックアップできます。
- デフォルトのService Account Secretボリュームをマウントする
- マウントhostPathタイプのボリューム
- Kubernetessecretsとconfigmapsボリュームをマウントする
この例では、1.5以上のVeleroが必要であり、永続バックアップボリュームデータへの制限が有効になっています。インストールフェーズのVeleroが開い--use-resticて--default-volumes-to-resticパラメータが設定されていることを確認してください。インストール構成のストレージの手順、およびVeleroのインストールを参照してください。
移行プロセス中は、2つのクラスターのリソースに対してCRUD操作を実行しないでください。これにより、移行プロセス中のデータの違いが回避され、最終的には移行後にデータの一貫性が失われます。
移行されたポッドがリソースの理由でスケジュールできず、保留が発生する状況を回避するために、クラスターBとクラスターAの作業ノードのCPU、メモリ、およびその他の仕様が同じであるか、あまり異ならないようにしてください。

ステップ

クラスタAにバックアップを作成します

バックアップ操作は手動で実行でき、veleroに定期的に提供できます。自動バックアップセットアップ方法を使用velero schedule -hして表示できます。この例では、defaultおよびdefault2名前空間のリソース条件を比較および検証します。次の図は、クラスターAの2つの名前空間のポッドおよびPVCリソースを示しています。

ヒント：バックアップ中にいくつかのカスタムフック操作を実行するように指定できます。たとえば、バックアップする前に、実行中のアプリケーションのメモリ内のデータをディスクに永続化する必要があります。バックアップの詳細については、フックバックアップフックを参照してください。

その中で、クラスター内のminioオブジェクトストレージサービスは永続ボリュームを使用し、次の図に示すように、いくつかの画像データがアップロードされています。

次のコマンドを実行して、クラスターリソース内の他のすべてのリソースにvelero名前空間（veleroインストールのデフォルト名前空間）が含まれていないことをバックアップします。クラスターリソースをバックアップする必要性をカスタマイズする場合は、velero create backup -hスクリーニングパラメーターをサポートするリソースを表示するために使用できます。

velero backup create <BACKUP-NAME> --exclude-namespaces <NAMESPACE>

この例では、「default-all」クラスターバックアップを作成します。バックアッププロセスを次の図に示します。

以下に示すように、バックアップジョブのステータスが「完了」と表示され、バックアップタスクが完了した場合velero backup logs | grep error、バックアップ操作チェックエラーが発生し、出力エラーは発生せず、バックアッププロセスを実行できます。

注：バックアッププロセス中にエラーが発生していないことを確認してください。バックアッププロセス中にエラーが発生した場合は、トラブルシューティングを行い、バックアップを再実行してください。

バックアップが完了したら、バックアップの保存場所を一時的に読み取り専用モードに更新します（これにより、復元プロセス中にVeleroがバックアップの保存場所でバックアップオブジェクトを作成または削除できなくなります）。

kubectl patch backupstoragelocation default --namespace velero \
    --type merge \
    --patch '{"spec":{"accessMode":"ReadOnly"}}'

クラスターBで復元を実行します

復元操作が実行される前は、クラスターBのdefaultおよびdefault2名前空間の下にワークロードリソースはありません。結果は次のとおりです。

クラスターBのVeleroバックアップストレージの場所を読み取り専用モードに一時的に更新します（これは不要です。これにより、復元プロセス中にVeleroがバックアップストレージの場所でバックアップオブジェクトを作成または削除できなくなる可能性があります）。

kubectl patch backupstoragelocation default --namespace velero \
    --type merge \
    --patch '{"spec":{"accessMode":"ReadOnly"}}'

ヒント：復元中またはリソースの復元後に実行するカスタムフック操作を指定することを選択できます。たとえば、データベースアプリケーションコンテナを起動する前に、カスタムデータベース復元操作を実行する必要がある場合があります。フックの復元の詳細については、を参照してくださいフックを復元します。

復元操作の前に、クラスターBのVeleroリソースがクラウドストレージのバックアップファイルと同期されていることを確認してください。デフォルトの同期間隔は1分で、これを使用--backup-sync-periodして同期間隔を構成できます。次のコマンドを使用して、クラスターAのバックアップが同期されているかどうかを確認できます。

velero backup get <BACKUP-NAME>

バックアップを正常に取得して正しいことを確認したら、次のコマンドを実行して、すべてのコンテンツをクラスターBに復元します。

velero restore create --from-backup <BACKUP-NAME>

この例では、次のように復元プロセスを実行します。

復元タスクが完了したら、復元ログを確認します。次のコマンドを使用して、復元にエラーがあるかどうかを確認し、メッセージをスキップできます。

# 查看迁移时是否有错误的还原信息
velero restore logs <BACKUP-NAME> | grep error 

# 查看迁移时跳过的还原操作
velero restore logs <BACKUP-NAME> | grep skip

次の図からわかるように、エラー復元手順はありませんが、クラスターリソースをバックアップするときに、velero名前空間を含まないすべてのクラスターリソースをバックアップしたため、多くの「スキップされた」手順があります。 kube-systemのクラスターリソースなど、同じタイプと名前が存在します。復元プロセス中にリソースの競合が発生した場合、veleroは復元手順をスキップします。したがって、実際には、復元プロセスは正常です。これらの「スキップされた」ログは無視できます。特別な状況がある場合は、ログを分析できます。

移行結果の検証

移行操作後、検証クラスターBのクラスターリソースを確認します。defaultおよびdefault2名前空間のポッドとPVCリソースが、期待どおりに正常に移行されたことがわかります。

次に、Web管理ページからクラスターBのmonioサービスにログインすると、minioサービスのイメージデータが失われていないことがわかります。これは、永続ボリュームデータが期待どおりに正常に移行されたことを示しています。

この時点で、TKEクラスター間のリソースの移行が完了しました。移行操作が完了したら、次のバックアップタスクのために、バックアップの保存場所を読み取り/書き込みモード（クラスターAおよびクラスターB）に復元することを忘れないでください。正常に使用できます：

kubectl patch backupstoragelocation default --namespace velero \
   --type merge \
   --patch '{"spec":{"accessMode":"ReadWrite"}}'

総括する

この記事では主に、Veleroを使用してTKEクラスター間でクラスターリソースを移行する際の原則、注意事項、操作方法を紹介します。サンプルクラスターAのクラスターリソースはクラスターBに正常に移行されます。移行プロセス全体は非常にシンプルで便利です。非常に使いやすいクラスターリソース移行ソリューション。