GKE→EKS のマイグレーションツール 'KMF' の検証 [DeNA インフラ SRE]

はじめに

こんにちは。IT基盤部の林です。

現在IT基盤部では、社内利用が多いクラウドサービスについて、ポータビリティの向上を目指す施策を行っています。具体的には、異なるクラウドベンダ間で同等の機能を持つサービスへ移行する方法を整えることにより、ベンダロックインされない運用を目指しています。

この施策の一環として、いくつかのクラウドサービスを対象に調査を行いました。調査結果は連載形式で順次公開していく予定です。すでに以下の記事を公開していますので、こちらもぜひ御覧ください！

DB のポータビリティ: Percona XtraBackup: 高性能DBバックアップツール [DeNA インフラ SRE]

本記事では、GKE (Kubernetes) のポータビリティ向上を対象とし、GKE (GCP) から EKS (AWS) へのマイグレーションツールである Kubernetes Migration Factory (以下、KMF) を検証した結果を紹介します。
※ 先に結論を書いておきますが、今回の検証では、当初期待していたような使い方はできなかったという結論になります。

ポータビリティ施策の背景

2021年に DeNA のインフラは、オンプレミスからクラウドへ全移行しており、現在はほとんどのサービスがクラウド上で運用されています ( 参考 )。

クラウドサービスには多くの利点がある一方で、サービス終了の可能性がある、利用者側では対応不可能な不具合が発生することがある、急な値上げが行われることがある、など懸念点も存在します。安定した運用のためには、こういった問題が発生した場合に、別のクラウドサービスへ移行する手段を整備しておく必要があります。

しかし、クラウドベンダ間の移行手順はあまりまとまっておらず、そもそも移行が可能かどうか、移行先があるのかどうかも不明でした。そこで、社内利用が多いクラウドサービスを対象に移行手段の調査と検証を行うことにしました。

まず、主に PaaS を対象としてクラウドサービスを洗い出し、その中で利用の多いものを優先的に対応することになりました。その中でも、特に利用の多い以下のマネージドサービスを対象に調査をはじめました。

データストア (RDB、オブジェクトストレージ、分散 DB)
Kubernetes / コンテナ

本記事では Kubernetes を対象とし、その中でも社内利用が多い GKE (Google Kubernetes Engine) からの移行先と移行方法を調査しました。

なお、本記事での移行とは、異なるクラウドベンダ間で Kubernetes のリソースを移すことのみを指しており、ダウンタイムの有無などは考慮していません。

移行先の検討・AWS EKS の利点

移行先については、GCP と同様に社内での利用実績が多い AWS への移行を検討しました。

対象が AWS のため移行先は EKS (Amazon Elastic Kubernetes Service) になりますが、一般に使い勝手が良いとされる GKE に対して、EKS を利用する利点を調査しました。

コスト削減が期待できる
Pod 単位で AWS サービスを利用可能
アドオンの追加が簡単

まず、コストについては、スポットインスタンスの利用により、オンデマンド価格に比べて大幅な削減を見込める場合があります。また、オートスケーラの Karpenter によるコストの最適化も可能です。Karpenter により、負荷に応じた最適なコンピューティングリソースのサイズが選択されることでコスト削減に繋がります ( 採用事例の参考)。同様の機能は GKE にもありますが、スポットインスタンスについては、中断までの猶予が GCP は30秒 ( 参考 )、AWS は2分 ( 参考 ) という差があり、AWS のスポットインスタンスの方が使いやすいという利点があります。

AWS のサービスが利用できるという点は当然ではありますが、特に Kubernetes 以外の部分を AWS を利用して運用している場合は、その他のサービスとの連携のし易さは利点であると考えられます。

アドオンについては、GKE との方向性の違いだと思われますが、EKS では必要なアドオンを選択して適用することが容易なため、特にアドオンを無効化したい場合のカスタマイズ性には優れていると言えます。アドオンの追加も、設定ファイルに1行足すだけというものが多く、手軽に設定可能です。

移行手段・移行先の検討

移行先が EKS なので、AWS 側で公開しているインポート手順を調査しました。

そもそもコンテナ化によりポータビリティは高くなるのが普通ですが、それでも各クラウド独自のサービスを利用している場合などは多いため、移行を補助できるようなツールを検討しました。その中で AWS サービスへの移行にも対応していそうな KMF というマイグレーションツールが見つかったので、実際に移行に使えるかどうかを検証しました。

KMF とは

KMF の主な機能は以下の2つです。簡単な設定ファイルを書いて、KMF を実行するだけで以下を実施できます。

Deployments、DaemonSets などの Kubernetes リソースを GKE から EKS にコピー
リソース内で利用されているコンテナイメージを GCR などから ECR にコピー

現時点の KMF の注意点としては、

対応しているのはリソースの移行のみで、データ移行には対応していない
カスタムリソースには対応していない
現在サポートしているのは GKE → EKS への移行のみ

という点が挙げられます。これらの改善はロードマップには含まれています。

参考:

KMF の検証

調査

まず README に以下の記述があったため、移行元で使用されているサービスと同種の AWS サービスを推奨するような機能があることに期待して検証を始めました。

It is able to provide recommendations to add relevant AWS native services by determining the type of services used in the source and finding a similar type of AWS resources.

しかし、調べたところ、この一文は上記のような意味ではなく、「KMF で GKE のワークロードを EKS に移行して動かすことで、ワークロードについて詳細を理解する一助になる。」という意図であることが分かりました。つまり、KMF の主な機能は pkg.go.dev/k8s.io/api/core/v1 を利用して愚直に Kubernetes のリソースをリストアップし、それらをマイグレーションすることでした。

このように最初期待した機能とは違いましたが、リソースの移行 (コピー) は自動で行うことができるので、今回はこの部分の動作検証を行いました。データ移行やサービス移行には対応していないので、簡単な Nginx のみの検証用クラスタを用意し、KMF を用いて EKS にリソースをコピーできることを確認しました。

検証環境の用意

移行元 GKE クラスタ準備

検証用のクラスタと簡単な設定を用意して適用します。

% gcloud container clusters list
NAME      LOCATION         MASTER_VERSION  MASTER_IP    MACHINE_TYPE  NODE_VERSION    NUM_NODES  STATUS
test-gke  asia-northeast1  1.27.3-gke.100  34.146.0.44  e2-medium     1.27.3-gke.100  3          RUNNING

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <適当なArtifact Registry>/nginx
        ports:
        - containerPort: 80

移行先 EKS クラスタ準備

EKS 側は移行先のクラスタだけ作成します。KMF の機能にクラスタの作成は含まれていません。

% eksctl create cluster --name test-eks --region ap-northeast-1

KMF のインストール

今回は macOS (Ventura 13.6.4) 上で実施したので、以下から kmf_mac をダウンロードしました。

https://github.com/awslabs/aws-kubernetes-migration-factory/releases

KMF の設定

実行の前に設定ファイル (config.ini) を作成する必要があります。今回は検証のため最低限の設定で config.ini を作成しました。

ただ、実用的には RESOURCES や NAMESPACES は、以下のように複数指定することもできます。
RESOURCES=Deployments,Services,DaemonSets,Secrets,HorizontalPodAutoScalers,BatchJobs

また、今回は利用していませんが Helm の利用も可能です。

config.ini の例

[COMMON]
# 今は利用がないので適当な場所を指定
HELM_CHARTS_PATH=./helm
# 移行対象の GKE リソースの種類
RESOURCES=Deployments
# Deploy か Delete を指定
ACTION=Deploy
# 移行対象の名前空間
NAMESPACES=default

# 移行元
[SOURCE]
CLOUD=GKE
KUBE_CONFIG=~/.kube/config
CONTEXT=<GKEのコンテキスト>

# 移行先
[TARGET]
CLOUD=AWS
KUBE_CONFIG=~/.kube/config
CONTEXT=<EKSのコンテキスト>

# コンテナイメージの移行を有効化
[MIGRATE_IMAGES]
USERCONSENT=Yes
REGISTRY=GCP

KMF 実行

移行の実施は、以下のように config.ini があるディレクトリで KMF バイナリを実行するだけです。今回の検証程度の小さなものであれば、実行は数秒で完了します。

% kmf_mac
Deploy
GKE Resources
GKE GetSourceDetails....
Namespace list entered by user
GKE FormatSourceData....start
GKE FormatSourceData....End
EKS Deploying resources....
Creating the namespace:  default
namespaces "default" already exists
=====================================================================
Operating on namespace:  default
=====================================================================
===============
Creating Deployment
Creating Deployment:  nginx-deployment

確認と感想

EKS に Deployment が作成されたことを確認できました。

% kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7c5ddbdf54-nnt8l   1/1     Running   0          69s
nginx-deployment-7c5ddbdf54-q8lpg   1/1     Running   0          69s

% kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           72s

リソースの移行が可能なことは確認できましたが、やはり GCP サービスを利用している場合に、対応する AWS サービスに変換してくれる機能があると、より使い所が増えると思いました。現状の機能では、deployment.yaml を手動で EKS に適用するのと大きな差分がありません。ただ、もしサービスの移行も自動で行ってくれるのであれば、KMF の設定を書くこと自体は簡単なので、簡単な手順で移行を補助してくれる便利なツールになると感じました。