Kubernetes移行のベストプラクティス: アプリケーション復旧のためのリソースバックアップの柔軟な管理

Last updated at 2025-02-20Posted at 2025-02-20

本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

Kubernetesクラスターのバックアップとリカバリ: ACK Backup Centerの活用

著者

Yashi Su (Sisi)

はじめに

急速に変化するクラウドネイティブ分野において、Kubernetesクラスターの運用（O&M）は多くの課題に直面しており、その中でも特に災害復旧とビジネス移行が重要です。効率的で信頼性の高いリソースのバックアップおよび復元メカニズムは、緊急時のクラスターバックアップや災害復旧、プライマリおよびセカンダリサービスの同期、IDCからクラウドへの移行、ハイブリッドクラウドシナリオでのクラウド移行などに不可欠です。これらのシナリオでは、共通の課題として、クロスクラスターでのビジネス復旧時に環境の違いが伴い、手動でのリソース調整が必要になる点が挙げられます。これにより、運用の複雑さが大幅に増し、復旧時間目標（RTO）が延びる可能性があり、サービスの継続性に影響を及ぼします。この課題に対処するため、ACK Backup Centerはさまざまなリソース調整戦略をサポートしています。これにより、データ復元中にターゲットクラスター環境に自動的に適応し、シームレスなビジネス再開を実現します。この革新的なソリューションは、災害復旧や移行プロセスにおける煩雑な操作を大幅に簡素化し、運用の敷居を下げ、ビジネス復旧速度を加速させます。また、高可用性と柔軟性を追求するKubernetesクラスター管理に強力な支援を提供します。

ACK Backup Centerの概要

Kubernetesクラスター上で動作するビジネス向けに、ACKはコンテナ化されたビジネスの災害復旧および移行のための一括ソリューションであるBackup Centerを提供します。

Backup Centerの詳細はこちら: https://www.alibabacloud.com/help/en/ack/ack-managed-and-ack-dedicated/user-guide/backup-center-overview

クラスター運用エンジニアは以下の操作を実行できます：バックアップ、リソース調整戦略の設定（オプション）、および復元。

バックアップ

クラスター運用エンジニアは、バックアップクラスターのコンソールで定期的なバックアップスケジュールを作成するか、または単一のアプリケーションバックアップをワンクリックで実行できます。ETCDバックアップと比較して、バックアップセンターは名前空間、ラベル、リソースタイプなどの次元に基づいてバックアップ対象のアプリケーションを選択することをサポートしています。ステートフルアプリケーションの場合、ビジネスによってマウントされたストレージボリュームデータも同時にバックアップされます。堅牢なGitOpsプロセスを持つ企業は、バックアップセンターのデータ保護機能を利用して、ストレージボリュームデータのみを選択してバックアップすることが可能です。バックアップが完了し、関連付けられたバックアップボールトのOSSバケットにアップロードされると、バックアップセンターはクラウドに保存されているバックアップに対して一切の変更を行いません。

リソース調整戦略の設定と復元

バックアップセンターは、以下の方法でクラスターの修正をサポートします：

デフォルトの修正: 構成は不要で、これらは復元中にコンポーネントによってデフォルトで実行されます。例としては、リソース削除UIDなどの一時情報の一般的な修正、ストレージボリューム復元時のFlexVolumeからCSIへの変更、APIバージョンの自動アップグレード、およびクロスクラウドシナリオにおけるいくつかの既知の互換性修正があります。
一般的な修正: これらは、復元タスクのフィールドを構成することで簡単に実装できます。例としては、名前空間、ストレージクラス、イメージレジストリアドレスのマッピング、およびネットワークプラグインとの互換性を確保するためのsvcおよびingのアノテーション書き換えがあります。
汎用的な修正: より柔軟な修正ニーズには、Veleroのリソース修飾機能に依存する必要があります。具体的には、特定のフィールド変更を実現するためにConfigMapを記述し、JSONパッチ操作（追加、削除、置換）をサポートします。

デフォルトの修正は、リソースの正常な展開を確保するために必要なリソースおよびフィールドにのみ適用されます。ほとんどのインプレース災害復旧シナリオでは、追加のリソース調整戦略は必要ありません。一般的な修正および汎用的な修正は、どちらも運用エンジニア向けのオプション構成であり、以下を目的として使用されます：

新しいクラスターやクラウドリソース環境との互換性を確保するためのサービス再開。これは、ハイブリッドクラウドなど異なる場所間の災害復旧シナリオで重要です。たとえば、イメージがクラウドにアップロードされた後のアドレス変更や、各クラウドプロバイダー間での基盤となるクラウドリソースの違いによる問題に対処します。
必要に応じてビジネス運用ロジックをカスタマイズします。安定性の要件により、ビジネス移行には構成ファイルの修正、レプリカ数の変更、強制的なポート変更、負荷分散の再利用、および負荷分散再利用中の強制的なリスニング施行などが含まれることがあります。

一般的なリソース修正は、復元ステップでの構成項目を修正するだけで実装できますが、より柔軟で汎用的な修正には、このステップで事前にConfigMapを作成して記述する必要があります。リソース調整戦略を設定した後、運用エンジニアはクラスターのコンソールでバックアップレコード（クラスターリソースおよびストレージボリュームデータを含む）を復元できます。

クラスターリソース調整のベストプラクティス

次に、この記事では、自社構築のKubernetesクラスターからACKクラスターへのステートフルアプリケーションの移行に関するベストプラクティスをシミュレーションします。この例では、構成を通じて名前空間とイメージレジストリアドレスを修正して復元する方法、およびリソース修飾子を使用してnodeAffinityを削除する方法を示します。

ステートフルアプリケーションのデプロイ例

自社構築クラスターはElastic Compute Service（ECS）インスタンスで構成されており、オープンソース版のContain Storage Interface（CSI）ストレージプラグインがインストールされています。自社構築クラスターをACK Oneの登録済みクラスターに接続し、バックアップセンターコンポーネント（migrate-controller）をインストールします。

登録済みクラスターの概要はこちら: https://www.alibabacloud.com/help/en/ack/overview-9

作成されたステートフルアプリケーションは、OpenAnolisコミュニティが提供する公開NGINXイメージを使用し、is_idcというマークが付いたノードにスケジュールされます。yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
namespace: default
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
serviceName: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: is_idc
operator: Exists
containers:
- image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
name: web
protocol: TCP
terminationMessagePath: /dev/termination-log
ネームスペース:

default
ラベルセレクター:
matchLabels:
app: nginx
パッチ:
operation: remove
path: /spec/affinity
kind: ConfigMap
metadata:
name: <backupName>-resource-modifier
namespace: csdr
ステートフルアプリケーションの調整された状態を復元する
ACKクラスターに切り替え、バックアップセンターのコンポーネントmigrate-controllerをインストールし、同じバックアップボールトに関連付けます。その後、バックアップが新しいクラスターに同期されるのを待ちます。前述のカスタム調整戦略に加えて、復旧タスクではnamespaceMappingおよびimageRegistryMappingフィールドを通じてネームスペースとイメージレジストリのマッピングも設定します。以前に作成した調整戦略に加え、復元中にバックアップ内のデフォルトネームスペースにあるリソース（ストレージボリュームデータを含む）はdefault1ネームスペースに復元され、OpenAnolisコミュニティのイメージレジストリアドレスはACRイメージアドレスに変更されます（イメージは事前に同期しておく必要があります）。 apiVersion: csdr.alibabacloud.com/v1beta1
kind: ApplicationRestore
metadata:
name: <restoreName>
namespace: csdr
spec:
backupName: <backupName>
namespaceMapping:
default: default1
imageRegistryMapping:
anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis: registry.cn-beijing.aliyuncs.com/<acrRegistry>
resourceModifier:
kind: ConfigMap
name: <backupName>-resource-modifier

復元タスクのステータスがCompletedに変わるまで待ちます。復元が要求通りに修正されたことを確認します。
テンプレートを見ると、コンテナイメージのイメージレジストリアドレスとそれらが存在するネームスペースが変更されていることがわかります。さらに、ノードアフィニティの設定も削除されています。残りの新しいフィールドはKubernetesコントローラーによって自動的に埋められます。 apiVersion: apps/v1
kind: StatefulSet
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
# 省略
generation: 1
labels:
app: nginx
velero.io/backup-name: <backupName>
velero.io/restore-name: <restoreName>
name: web
namespace: default1
resourceVersion: 119622
uid: d23878ea-0b9f-40ba-b61b-1ff6bb77eb43
spec:
persistentVolumeClaimRetentionPolicy:
whenDeleted: Retain
whenScaled: Retain
podManagementPolicy: OrderedReady
replicas: 2
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
serviceName: nginx
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
affinity: {}
containers:
- image: registry.cn-beijing.aliyuncs.com/<acrRegistry>/nginx:1.14.1-8.6
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
name: web
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /usr/share/nginx/html/
name: www
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
updateStrategy:
rollingUpdate:
partition: 0
type: RollingUpdate
volumeClaimTemplates:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
  creationTimestamp: null
  labels:
  app: nginx
  name: www
  spec:
  accessModes:
  - ReadWriteOnce
    resources:
    requests:
    storage: 20Gi
    storageClassName: alicloud-disk-topology-alltype
    volumeMode: Filesystem
    status:
    phase: Pending
    status:
    availableReplicas: 0
    collisionCount: 0
    currentRevision: web-7b454646b4
    observedGeneration: 1
    replicas: 2
    updateRevision: web-7b454646b4
    ステートフルアプリケーションは、ラベルのないACKクラスターのノード上で正常に起動され、スナップショットから新しいディスクが復元され、マウントされています。