はじめに
Kubernetesを触り始めたばかりで、デプロイや運用は経験したものの、まだ一度もバージョンアップを経験していない方に向けて、「初めてのKubernetesバージョンアップ」という連載をはじめます。バージョンアップにはクラスターのバージョンアップとアプリケーションのバージョンアップの2種類があります。この連載では、ダウンタイムを最小限に抑え、安全にKubernetesの2種類のバージョンアップを行うための手法を解説していきます。
初回となる今回は、デプロイメント戦略の基本と、Kubernetesでの実現方法をアプリケーションのバージョンアップを中心に解説していきます。
デプロイメント戦略の基本
アプリケーションを新しいバージョンに切り替える際、システムの停止時間を最小限にし、リスクをコントロールするために様々なデプロイメント戦略が用いられます。代表的な3つの手法を比較します。
ローリングアップデート
現在稼働している旧バージョンのコンテナを少しずつ停止し、代わりに新バージョンのコンテナを起動していく方法です。
- メリット
- デプロイ中にサービスが停止しません（ダウンタイムがない）。
- デメリット
- 旧バージョンと新バージョンが同時に稼働するため、DBスキーマの変更やAPIの互換性などの違いに注意が必要です。問題があった場合、ロールバックに時間がかかることがあります。Kubernetesの標準的なDeploymentリソースで簡単に実現できます。
Blue/Greenデプロイ
旧バージョン（Blue環境）と全く同じ構成の新バージョン（Green環境）を用意し、両方を並行稼働させます。Green環境のテストが完了したら、外部からのトラフィックを一斉にGreen環境へ切り替える方法です。
- メリット
- 切り替えが一瞬で完了し、ダウンタイムが短いです。問題があった場合、トラフィックをBlue環境に戻すだけで即座にロールバックできるため、非常に安全性が高いです。
- デメリット
- Blue環境とGreen環境の2倍のリソース（コスト）が必要になります。
カナリアリリース
新バージョンを一部のユーザー（カナリアグループ）にだけ公開し、問題がないことを確認しながら徐々に公開範囲を広げていく方法です。
- メリット
- リスクを最小限に抑えつつ、本番環境で新バージョンの影響を検証できます。
- デメリット
- トラフィックを分割する仕組みが必要で、設定が複雑になります。
ユースケース
各デプロイメント戦略がどのような状況に適しているかをまとめます。
|
デプロイメント戦略 |
適している状況 |
|
ローリングアップデート |
軽微なバグ修正、互換性の問題が少ないアップデートで最も一般的 |
|
Blue/Greenデプロイ |
Kubernetesのメジャーバージョンアップなど、切り戻しを迅速に行いたい大規模な変更 |
|
カナリアリリース |
新機能のA/Bテスト、ユーザー影響を慎重に見極めたい場合 |
Kubernetesでの実現方法
Kubernetesにおいて、Blue/Greenデプロイの核となるのは「トラフィックの切り替え」です。Blue環境とGreen環境を並行稼働させた後、どこでトラフィックの流れを変えるかによって、実現方法が異なります。
ServiceのSelector切り替え
最もシンプルな手法です。
- BlueとGreenのアプリケーションをそれぞれ異なるDeploymentでデプロイします。
- 外部からのアクセスを受けるServiceリソースは、selectorフィールドでBlue環境のPodラベルを指定しておきます。
- 切り替え時には、このServiceのselectorをGreen環境のPodラベルに書き換えます。
- これにより、ServiceのIPアドレスやDNS名は変わらず、バックエンドのPodだけが一瞬でGreen環境に切り替わります。
Ingressによるトラフィック制御
複数のアプリケーションや異なるクラスター全体を対象とする場合に使われます。
- IngressやGateway APIを利用し、ホスト名やパスごとにトラフィックをBlue/GreenそれぞれのServiceにルーティングします。
- 切り替え時は、Ingressの設定を書き換え、ルーティング先をBlueからGreenのServiceに変更します。
ロードバランサー（LB）での切り替え
この手法は、KubernetesのクラスターそのものをBlue/Greenで切り替える大規模なバージョンアップに適しています。
Kubernetesクラスターの外にあるロードバランサー（AWS ALB/NLB、GCP Cloud Load Balancingなど）を利用してトラフィックを制御します。
- Blue環境とGreen環境のクラスター全体をLBのターゲットグループとして設定します。
- 切り替え時は、LBの設定を変更し、トラフィックがBlueターゲットグループからGreenターゲットグループに流れるようにします。
まとめ
Blue/Greenデプロイ方式は、新旧環境を並行稼働させ、トラフィックの一斉切り替えにより迅速なロールバックを可能にする、安全性に優れた戦略です。
Kubernetesでは主にアプリケーションのバージョンアップの場合はServiceのselector切り替えやIngressを、クラスターのバージョンアップの場合は外部LBを用いて実現できます。
次回は、Blue/Greenデプロイをより安全に行う上で不可欠な「データの扱い」に焦点を当てます。特にステートフルなアプリケーションをバージョンアップする際のデータ移行の課題について深掘りします。
参考文献
https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/update/update-intro/
