GKEクラスタ移行のホワイトペーパー

Google Kubernetes Engine(GKE)は、Google Cloud Platform(GCP)上で動作するマネージドKubernetesです。GCPが提供する世界各国リージョンのデータセンターから選択して、kubernetesクラスタを構築できます。

運用後のリージョン間移転は、海外展開のほか、災害対策のシナリオとしても必要となるスキルです。先ほどクロスリージョン移転に成功したノウハウをもとにホワイトペーパー級のドキュメントを提供します。

リージョン移転の構成要素

GKEクラスタを構成する要素には、主に以下のようなものがあります。

Kubernetesクラスタホスト
- kubernetesのマスターと実行ノードです。GKEサービスとして提供される範囲で、GCPのVM上にKuberenetes実行環境セットアップ済のクラスタを利用できます
- サーバー群に相当するクラスタホストについては、GCPクラウドコンソールで複製ツールを利用でき、稼働中のサーバー群と同様の構成を新リージョンに手軽に構築できます
コンテナイメージ
- 主にGKEユーザーがビルド運用しているコンテナイメージです。GKEネイティブなプライベートホストとしてはGoogle Artifact Registry(pkg.dev)を利用できます
- gcr.ioでホストしているイメージはリージョンが変わっても参照可能であるため、移行時の考慮点や移行前後の決定的な違いはとくにありません
コンテナmanifest群
- 各GKEユーザーがコンテナ構成を定義したconfigファイル群です。Deployment, StatefulSet, DaemonSet, Service, ConfigMap, Secret, CronJobなどがあります。
- アプリ層のコンテナは、新リージョンで構築が必要です。移行作業を行うクライアント機器にmanifest群を一式用意しておく必要があります
persistentDisk
- コンテナそのものは揮発性であり、ユーザーデータは典型的にはpersistentDiskに保存します。DBデータやファイル群があります
- persistentDiskはリージョン・ゾーンに帰属しており、GCPのスナップショット→ディスク作成の手順により新リージョンに複製する必要があります
ネットワーク構成
- 典型的にはDNS設定と外部IP設定です。ほかに、独自に設定したファイアーウォールルールなどもネットワーク構成のマイグレーションで対処します
- GCPの負荷分散が提供するIPはグローバルIPであるため、ロードバランサー再作成時に新リージョンにも引き継げます。ほかにリージョンに帰属しているIPもあり、その場合は新リージョンで取得する静的IPをもとにDNS設定の変更が必要です

このように構成要素ごとに対処方法が異なるため、あらかじめ運用中のクラスタの構成要素を特定したうえで、個別に移行手順を明確にしておくことが必要です。

移行ステップの概要

クラスタの複製
- GCPクラウドコンソールから新リージョンに実行環境を作成します。この結果、空のクラスタが追加で立ち上がります
- 単なる複製も可能ですが、新バージョンの採用や構成の変更も可能です
persistentDisk複製
- スナップショットを利用して、新リージョンに同じ状態のpersistentDiskを作成します
- 一貫性のあるデータを取得するため、多くのケースでサービス停止によるWrite中断が必要でしょう
- 別リージョンや別ゾーンであれば同名のディスクを作成できます。ディスク名を同一にするとmanifestを修正せずmountできます
コンテナ構築
- kubectlのコンテキストを新リージョンのクラスタに切り替えたうえで、kubectl create -fによりコンテナ構築します。ディレクトリを指定すると一括作成できます
- persistentDisk名や外部IPなど一部をのぞく、大半のmanifestは変更なくそのまま新リージョンで使用可能です
ネットワーク移行
- 必要に応じて、既存IPを引き継いでGateway/Ingress/LoadBalancerの再作成を行います
- ロードバランサがグローバルオブジェクトの場合、IPは流用可能でしょう。TCPプロキシのケースは GKEのTCPコンテナネイティブ負荷分散で解説しています
- IPが変わるケースでは、DNSなど周辺サービスの接続構成を変更します
旧クラスタ削除
- 新クラスタの接続が確認できれば、GCPコンソールから旧クラスタを一括削除できます

この手順は新旧クラスタが同じ構成を想定したものですが、GKEはネットワーク機能の進化が早いため、移行のタイミングでネットワーク構成を変更することも有効です。

移行にかかるコスト

移行の方法にもよりますが、ダウンタイムを避けるシナリオの場合、新旧２クラスタを重複して動作させる部分のコストが移行コストと言えるでしょう。主に以下のようなものがあります。

一時的に新旧２クラスタ構成となる分のVM料金
一時的に２クラスタ目の利用料。現状、請求アカウントあたり１クラスタはGKE利用費はかかりませんが、２クラスタ目以降は従量課金がかかります。リージョン移行のシナリオでは単一クラスタではおさまらず、一時的に２クラスタ構成となります
データ転送料金。persistentDiskをスナップショット取得する際、asiaマルチリージョンを指定するとasia内では転送料金はかかりませんが、asia, us間の移行などでは転送料金がかかります

いずれも従量課金であるため、手際よく進めて短時間で完了することでコスト抑制を図れます。

ポイント

kubernetesの構成規約に沿って構築しているシステムであれば、ハード層とのアンバンドルが進んでいるため、リージョン間の移転といえども相当簡素な手順で実行できます。

ソフトウェア構成はコンテナイメージにパックされているため考える必要がない
kubernetesのServiceが提供するホスト名を用いた構成をとる限り、リージョンやVMを問わずそのまま動作する
アプリケーションの移行はほぼpersistentDiskの移行に限られる。RDBMSの例では起動時の物理リカバリにより概ねそのまま立ち上がる
ネットワーク構成の注意点は、ロードバランサーの再構成に注意する

予行演習

GKEは任意のリージョンに新クラスタを数分程度で構築でき、従量課金で費用面の失敗リスクも低減できるため、必要に応じて予行演習をしておくことも有効でしょう。
以下のような手順が考えられます。

新クラスタ作成からコンテナ構築まで実行する
既存ネットワークと異なるIPでサービス公開する
- たとえばGateway/Ingress/LoadBalancerをIP指定せず作成すると別IPで作成される
動作確認
- /etc/hostsなどクライアントOSのネットワーク設定を活用できる

この構成はそのまま新クラスタとして切り替えることも可能でしょう。切り替え作業としては、以下のような追加手順があります。