DoiT Launches PerfectScale™ for Commitments, Bringing Autonomous Rate Optimization to Every Cloud
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Heptio Veleroで実現するGoogle Kubernetes Engineクラスタ移行

By Eran ChetzroniApr 22, 20194 min read

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

1 yyq8hwire9b5wgawnxivhq

Kubernetesのワークロード全体を新しいクラスタへ移行したい場面はたびたび訪れます。テストやメジャーバージョンのアップグレード、災害復旧など、その理由はさまざまです。

先日、あるお客様のGKE(Google Kubernetes Engine)クラスタを、Google CloudのLegacy VPC NetworkからVPC Native Networkへ移行する案件がありました。あいにくGoogle Cloudには、ネットワーク方式を切り替える正式なアップグレード手順は用意されていません。

そこでいろいろと調べてみたところ、組み合わせて使うことで作業を一気に楽にしてくれるツールがいくつか見つかりました。

既存クラスタのクローン作成

Google Kubernetes Engine(GKE)には「新しいクラスタを作成」機能があり、既存クラスタをそのままクローンできます。

1 nkdwsv7pbf4pv6bavvnbw

これにより、以下のクラスタ構成をまとめてコピーできます。

  • ゾーン
  • ノードプールおよび関連するノードプール構成
  • ノードラベルなど、その他の構成設定

もちろん新しいクラスタを作成する前に内容を編集することもできますが、この「クローン」機能を使えば、ノードやラベルが正しく設定された状態をわずか2クリックで再現できます。🚀

ただし、Deployment、Service、Ingress、CustomResourceDefinitionといったKubernetesリソースはコピーされません。これらの移行には別のツールが必要です。

Kubernetesリソースの移行

クローンしたクラスタが手元にできたところで、続いて以下のようなKubernetesリソースをすべて移行する必要がありました。

  • ワークロード
  • サービス
  • Config
  • Secret
  • ストレージ
  • CustomResourceDefinition
  • そのほか、まだまだたくさん…

試しに次のコマンドを実行してみると、

$ kubectl api-resources

テストクラスタには74種類ものKubernetesリソースが存在することが判明しました 😱。なかなか手強いですね。

幸い、Heptio製のVelero(旧Heptio Ark)を見つけました。これを使えば、Kubernetesクラスタのリソースに加えて永続ボリュームのバックアップとリストアもまとめて行えます。

Veleroでできることは次のとおりです。

  • Kubernetesクラスタのバックアップとリストア
  • あるクラスタから別のクラスタへのリソースのコピー
  • 本番環境を複製した開発・テスト環境の構築 🎸

Veleroは新しいクラスタへKubernetesリソースを複製するのにうってつけと思えたので、さっそく試してみることにしました。

Veleroのインストール

Veleroは大きく2つのコンポーネントで構成されています。

  1. velero-cli — ローカルで動作するコマンドラインクライアント
  2. velero deployment — クラスタ上で動作するサーバー

作業に入る前に、Veleroの公式リリースに目を通しておくのがおすすめです。最新の安定版はv0.11.0です。

今回はGKEクラスタにVeleroを導入したため、こちらの手順に沿って進めました。

基本的なインストールの流れは次のとおりです。

  1. velero-cliをインストール
brew install velero

(手動でダウンロードしてもOKです。バイナリ1つだけのシンプルな構成です)

2. Google Cloud Storageバケットを作成

gsutil mb gs://<gke-cluster-migrate-velero-placeholder-name>

3. サービスアカウント / 権限 / ポリシーを作成

こちらの「Create service account」の手順をご覧ください。

4. GKEクラスタに認証情報を追加

こちらの「Credentials and configuration」の手順をご覧ください。

05-backupstoragelocation.yaml内の<YOUR_BUCKET>を忘れずに置き換えてください。

5. velero-serverをデプロイ

  kubectl apply -f config/gcp/05-backupstoragelocation.yaml
  kubectl apply -f config/gcp/06-volumesnapshotlocation.yaml
  kubectl apply -f config/gcp/10-deployment.yaml

いよいよバックアップ!

クラスタ全体のバックアップには、次のコマンドを使いました。

velero backup create <BACKUP-NAME>

velero backup create <BACKUP-NAME>を実行すると、内部では次のような処理が行われます。

  1. VeleroクライアントがKubernetes APIサーバーを呼び出し、Backupオブジェクトを作成します。
  2. BackupControllerが新しいBackupオブジェクトを検知し、検証を行います。
  3. BackupControllerがバックアップ処理を開始し、APIサーバーへの問い合わせを通じて対象リソースのデータを収集します。
  4. BackupControllerがオブジェクトストレージサービス(例:GCSバケット)を呼び出し、バックアップファイルをアップロードします。

いい感じですね!

バックアップの状態は、次のコマンドで確認できます。

velero get backups

移行作業

元のクラスタ(cluster 1)の完全なバックアップが取れたので、次は新しいクラスタ(cluster 2)にVeleroをデプロイします。

ここでは、いくつか注意しておきたいポイントがありました。

  • _cluster 2_では、Veleroのデプロイ用YAMLのサーバーspecに--restore-onlyフラグを追加する必要があります。
  • BackupStorageLocationを_cluster 1_と揃え、新しいVeleroサーバーインスタンスが同じバケットを参照するように設定します。
  • 最後に、_cluster 2_のVeleroリソースがクラウドストレージ上のバックアップファイルと同期していることを確認します。デフォルトの同期間隔は1分なので、確認の前に少し待つようにしてください。
velero backup describe <BACKUP-NAME>

目的のバックアップ(<BACKUP-NAME>)が認識されていることを確認できたら、次のコマンドで一括リストアできます。

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

それでは_cluster 2_側で確認してみましょう。

velero restore get

上のコマンドで得られたリストア名を使って、次のように詳細を確認します。

velero restore describe <RESTORE-NAME-FROM-GET-COMMAND>

以上で完了です!

GKEの「クラスタのクローン」機能とHeptio Veleroを組み合わせることで、クラスタ構成とリソースを含めた移行をスムーズに完了できました。

この2つのツールのおかげで、大幅に時間を節約できただけでなく、Kubernetesリソースの洗い出しからバックアップ、リストアまでの一連の流れがぐっとシンプルになりました。

ほかの記事も読みたい方は、ぜひブログをチェックするか、EranのTwitterをフォローしてみてください。