Veleroを使ったEKS→GKEへの移行の検証 [DeNA インフラ SRE]

はじめに

こんにちは。パブリッククラウドチームの崔です。パブリッククラウドチームでは、クラウドサービスのポータビリティを向上させるための施策に力を入れています。
具体的には、異なるクラウドベンダ間で同等の機能を持つサービスへの移行を容易にすることで、ベンダロックインされない柔軟な運用の確立を目指しています。このアプローチにより、全社のITインフラの効率性と可用性の向上が期待されています。

この施策に関連して、すでに以下の記事を公開していますので、こちらもぜひ御覧ください！

DB のポータビリティ > Percona XtraBackup: 高性能DBバックアップツール [DeNA インフラ SRE]
GKE→EKS のマイグレーションツール > GKE→EKS のマイグレーションツール ‘KMF’ の検証 [DeNA インフラ SRE]
Google Cloud DMSの検証 > Google Cloud DMS 利用時のダウンタイムの検証 [DeNA インフラ SRE]

本記事では Amazon Elastic Kubernetes Service（以下、EKS）から Google Kubernetes Engine（以下、GKE）への移行を対象とし、 Velero を利用した移行の検証結果を紹介します。

背景

GKE、EKS 間の移行の背景は、以下の記事に記載しています。

GKE→EKS のマイグレーションツール > ポータビリティ施策の背景

移行手段・移行先の検討

今回は、Veleroを使用してEKSからGKEに移行する手順を検証しました。

EKSの移行方法については、Googleからも AWS から Google Cloud への移行: Amazon EKS から GKE への移行という公式ガイドが提供されていますが、異なるクラウド間での移行においては、Veleroが提供する高度なバックアップとリストアの機能が有用であると考えたため、今回はVeleroを用いた方法を検証しました。
Veleroはバックアップやリカバリをサポートするツールであり、データ移行を容易にする可能性に期待できました。
また、Veleroに関する情報は、日本のみならず海外でも少なく、公式ドキュメントの内容も限られているため、実際に利用してまとめました。

Veleroとは

Velero は、Kubernetes クラスタのバックアップ、リカバリ、および移行をサポートするツールです。それにより、クラスタ状態や永続ボリュームのスナップショットを容易に取得することができます。

Veleroでできること

クラスタのバックアップ：クラスタの状態や永続ボリュームのデータを定期的にバックアップし、自動化が可能です。
クラスタのリストア: バックアップからクラスタを復元し、特定のネームスペースやリソースだけをリストアすることもできます。
クラスタ間の移行: 異なるKubernetesクラスタ間でのデータ移行が可能です。
災害復旧: 災害時のデータリカバリに対応し、クラスタ全体の復元を迅速に行えます。
スナップショット管理: 永続ボリュームのスナップショットを管理し、クラウドストレージに保存できます。

Veleroでできないこと

リアルタイムデータ同期: Veleroは定期的なバックアップとリカバリをサポートしますが、リアルタイムのデータ同期には対応していません。
マルチクラウド管理: 複数のクラウド環境を一元管理する機能はありません。
カスタムリソースの完全サポート: 一部のカスタムリソースやクラウドプロバイダー固有のリソースについては、完全なサポートが提供されていない場合があります。
セキュリティとコンプライアンスの自動化: セキュリティとコンプライアンスの管理機能は含まれていません。これらは別途対応が必要です。例として、バックアップデータを暗号化するためにKubernetesの秘密管理ツールと組み合わせる、あるいはバックアップやリストアの操作ログを長期間保持する機能がないため、追跡する必要がある場合は別途ログ管理ツールを使用する必要があります。
クラスタの作成:事前にクラスタをセットアップしておく必要があります。Veleroはバックアップから特定のネームスペースやリソースをリストアできますが、クラスタ自体の作成は行いません。

Veleroの検証

今回の検証の目的は、Veleroを使用してEKSからGKEへの移行が実際にどれだけスムーズに行えるかを評価することです。具体的なゴールは以下の通りです。

移行手順の確立：EKSからGKEへの移行手順を詳細に記録し、再現性のあるプロセスを確立する。
課題の特定：移行プロセスで発生する可能性のある問題点や制約を明確にする。
移行の可能性評価：Veleroを使用した移行が可能かどうか、その有効性を評価する。

前提条件

Kubernetesクラスタのセットアップ
- EKSクラスタとGKEクラスタが動作していることを確認。これは、Veleroが既存のクラスタのバックアップとリカバリを行うため、クラスタ自体の作成は対象外となるためです。
kubectlの設定
- 両方のクラスタに対して kubectl がアクセスできることを確認。Veleroはkubectlを通じてクラスタにアクセスし操作を行うため、この設定が必要です。

Veleroのインストール

Veleroのインストール（EKS側）

まず、VeleroをEKSにインストールします。これにより、AWSのS3をバックアップストレージとして設定します。

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket velero-test-bk \
  --backup-location-config region=ap-northeast-1 \
  --snapshot-location-config region=ap-northeast-1 \
  --secret-file ~/.aws/credentials

Veleroのインストール（GKE側）

次に、GKEにも同じ設定でVeleroをインストールします。これにより、EKSでバックアップしたデータをGKEから参照できます。

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket velero-test-bk \
  --backup-location-config region=ap-northeast-1 \
  --snapshot-location-config region=ap-northeast-1 \
  --secret-file ~/.aws/credentials

なぜ同じ内容をインストールするのか

同じ設定を使用してVeleroをインストールする理由は、EKSでバックアップしたデータをGKEから参照するためです。

バックアップデータの共有：EKSで作成したバックアップはAWSのS3に格納されます。GKEからこのS3を参照するためには、同じVeleroをインストールする必要があります。
一貫した設定：EKSとGKE間で一貫した設定を使用することで、両方のクラスタから同じS3にアクセスし、バックアップとリストアの操作をシームレスに行えます。

検証手順

EKSのバックアップ（EKS側）

バックアップを実行した時、そのデータは指定したS3に保存されます。Veleroをインストールする際に指定したS3にバックアップデータが保存されます。

$ velero backup create eks-backup --include-namespaces eks-sampe-app
Backup request "eks-backup" submitted successfully.
Run `velero backup describe eks-backup` or `velero backup logs eks-backup` for more details.

バックアップの確認（EKS側）

ステータスが Completed になるまで待ちます。

$ velero backup get
NAME              STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
eks-backup        Completed   0        0          2024-06-21 07:25:14 +0000 UTC   29d       default            <none>

もし Completed になっていない場合 velero backup describe eks-backup or velero backup logs eks-backupを使って、バックアップ進捗状況やエラーの詳細を確認できることができます。

バックアップのリストア（GKE側）

EKSのバックアップデータを指定したS3から取得し、GKEクラスタにリストアします。

$ velero restore create --from-backup eks-backup

ECR の認証（GKE側）

移行元の EKS では、イメージの保存先として Amazon Elastic Container Registry（以下、ECR）を使用しています。移行先の GKE から ECR に保存されたイメージにアクセスするために以下のコマンドを実行します。イメージの保存先として Docker Hub を使用している場合は、Docker Hub に対してコマンドを実行します。

$ kubectl create secret docker-registry regcred \
  --docker-server=xxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com \
  --docker-username=AWS \
  --docker-password=$(aws ecr get-login-password) \
  --namespace=eks-sample-app

バックアップのリストアのコマンドを実行した後に、すぐにECR認証コマンドを実行します。これにより、GKEがイメージを正しくPullできるようになります。

リストア完了の確認（GKE側）

$ velero restore get
NAME                             BACKUP            STATUS      STARTED                         COMPLETED                       ERRORS   WARNINGS   CREATED                         SELECTOR
eks-backup-20240621073117        eks-backup        Completed   2024-06-21 07:31:18 +0000 UTC   2024-06-21 07:31:31 +0000 UTC   0        2          2024-06-21 07:31:18 +0000 UTC   <none>

$ kubectl get po -A
NAMESPACE         NAME                                                       READY   STATUS      RESTARTS        AGE
eks-sample-app    eks-sample-linux-deployment-69599f5fbc-8k7pc               1/1     Running     0               2m28s

上の手順により、EKS→GKEへのマイグレーションは完了しました。

検証で見つかった問題

問題:IngressのIPが表示されない

Ingressを見ると正常に作成は完了しましたが、Google Cloud Load Balancer（以下、GCLB）のIPが表示されませんでした。これは、EKS側で使用していたApplication Load Balancer（以下、ALB）がGKEには存在せず、リソースが適切に変換されなかったことが原因と考えられます。異なるクラウドプロバイダー間でロードバランシングの実装が異なるため、これが問題となりました。

$ kubectl get ing -n eks-sample-app
NAME                       CLASS   HOSTS   ADDRESS   PORTS   AGE
eks-sample-linux-ingress   alb     *                 80      36m

対処:GKEのIngress再作成

GCLBが正常に作成されない場合は、再作成するか、YAMLファイルを編集すると正常に作成されます。今回は再作成する手順を記載します。

GKE - IngressのYAMLファイルを用意

# gke-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: eks-sample-app
  name: eks-sample-linux-gcp-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  defaultBackend:
    service:
      name: eks-sample-linux-service
      port:
        number: 80

削除前にIngressのYAMLファイルを先に編集

Finalizers の group.ingress.k8s.aws/eks-group の１行を削除します。
※ 上の１行を消さない場合はIngressが正常に削除されません。

$ kubectl edit ingress eks-sample-linux-ingress -n eks-sample-app

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/group.name: eks-group
    alb.ingress.kubernetes.io/load-balancer-name: eks-alb
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=90
    alb.ingress.kubernetes.io/target-type: ip
  creationTimestamp: "2024-06-21T07:31:31Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2024-06-21T08:17:58Z"
  finalizers:
  - group.ingress.k8s.aws/eks-group  ## １行を削除
  generation: 2
  labels:
    velero.io/backup-name: eks-backup
    velero.io/restore-name: eks-backup-20240621073117

Ingressを削除

$ kubectl delete ingress eks-sample-linux-ingress -n eks-sample-app
ingress.networking.k8s.io "eks-sample-linux-ingress" deleted

Ingressを再作成

$ kubectl apply -f gke-ingress.yaml
ingress.networking.k8s.io/eks-sample-linux-gcp-ingress created

$ kubectl get ingress -n eks-sample-app
NAME                           CLASS    HOSTS   ADDRESS        PORTS   AGE
eks-sample-linux-gcp-ingress   <none>   *       ***.***.***.***   80      2m

IngressのIPでWEBにアクセス

web app

まとめ

Veleroを利用したEKSからGKEへの移行を検証しました。Veleroにより、Ingress以外のDeploymentとServiceリソースは簡単に移行できました。今後Ingressにも対応された場合、非常に優れたマイグレーションツールになると思います。
VeleroはKubernetesのバックアップツールとして非常に優れていると感じました。クラウド間でのデータ移行が必要な場合にも、Veleroは信頼性の高い選択肢と言えるでしょう。ただし、移行先の環境に依存する部分もあるため、個別の環境での適用検証は欠かせません。Veleroを利用する際には、事前に慎重な検証を行い、問題点を洗い出して対応することが重要です。