【ITニュース解説】Part-88: 🔄 Kubernetes Deployment Updates & Rollout Verification in GCP (Google Kubernetes Engine)

Kubernetesとは、たくさんのアプリケーションを安定して動かすための仕組みを管理してくれる「コンテナオーケストレーションツール」と呼ばれるソフトウェアだ。アプリケーションは「コンテナ」という技術でひとつのパッケージにまとめられ、Kubernetesはそれらのコンテナを、サーバーのどの場所で、いくつ動かすかといったことを自動的に管理してくれる。Google Kubernetes Engine（GKE）は、このKubernetesをGoogle Cloud Platform上で簡単に利用できるサービスであり、自分でサーバーを準備したり、Kubernetesをインストールしたりする手間なく、すぐに使い始められる。

システムエンジニアとしてアプリケーションを開発し、運用していく中で、新しい機能を追加したり、セキュリティ上の問題を修正したりするために、アプリケーションを更新する必要が頻繁に発生する。この時、最も重要なのは、ユーザーがアプリケーションを使っている最中にサービスを停止させないことだ。Kubernetesは「Deployment（デプロイメント）」という機能を使って、アプリケーションを無停止で新しいバージョンに更新できる。この無停止更新の仕組みを「ローリングアップデート」と呼ぶ。

ここでは、GKE上で動いているアプリケーションをKubernetesのDeployment機能を使って更新する方法を、具体的な手順を追いながら解説する。更新方法は主に二つあり、それぞれの方法でアプリケーションのバージョンを順に上げていく様子と、その際にKubernetesの内部で何が起こっているのかを確認する方法について見ていこう。

最初の方法は、kubectl set imageコマンドを使って、アプリケーションが利用するコンテナイメージを直接更新する方法だ。これは、アプリケーションのバージョンアップなど、コンテナイメージだけを変更したい場合に非常に手軽で便利な方法である。

まず、現在稼働しているアプリケーションのDeploymentの名前と、そのDeployment内で使われているコンテナの名前を知る必要がある。kubectl get deployment my-first-deployment -o yamlというコマンドを実行すると、my-first-deploymentという名前のDeploymentの詳細な設定情報（YAML形式）が表示される。この情報の中から、使われているコンテナ名を確認する。例えば、「kubenginx」という名前のコンテナが使われているとしよう。

次に、このコンテナのイメージをバージョン1からバージョン2へ更新する。kubectl set image deployment/my-first-deployment kubenginx=ghcr.io/stacksimplify/kubenginx:2.0.0というコマンドを実行する。このコマンドは、my-first-deploymentというDeploymentのkubenginxという名前のコンテナが使うイメージを、ghcr.io/stacksimplify/kubenginx:2.0.0という新しいバージョンに変更するようKubernetesに指示する。

コマンドを実行すると、Kubernetesはローリングアップデートを開始する。この更新が正しく進んでいるかを確認するには、kubectl rollout status deployment/my-first-deploymentというコマンドを使う。このコマンドは、Deploymentの更新状況をリアルタイムで表示し、更新が完了したかどうかを教えてくれる。

更新中にKubernetesの内部で何が起こっているかを確認することも重要だ。kubectl get deployでDeploymentの概要を、kubectl describe deployment my-first-deploymentで詳細な情報やイベント履歴を確認できる。特に興味深いのは、PodとReplicaSetの状態の変化だ。

kubectl get rsコマンドで「ReplicaSet（レプリカセット）」の状態を確認する。ReplicaSetとは、指定された数のPod（コンテナ化されたアプリケーションの実行単位）が常に稼働していることを保証するKubernetesの機能だ。ローリングアップデートでは、まず新しいバージョンのアプリケーションを動かすための新しいReplicaSetが作成され、それに紐づくPodが起動し始める。そして、新しいPodが正常に動作していることを確認しながら、古いバージョンのアプリケーションを動かしていた古いReplicaSetに紐づくPodが一つずつ停止・削除され、古いReplicaSetの管理するPodの数が徐々にゼロへと減らされていく。最終的には、新しいReplicaSetだけが指定された数のPodを稼働させ、古いReplicaSetは不要になるか、Podの数がゼロになる。

kubectl get poコマンドでPodの状態を確認すると、V1のPodが終了し、V2の新しいPodが立ち上がっていく様子がわかるだろう。これにより、アプリケーションが停止することなく、新しいバージョンに切り替わっていることを確認できる。

更新が完了したら、LoadBalancerの外部IPアドレスを使ってブラウザやcurlでアプリケーションにアクセスし、表示されるバージョンがV2に更新されていることを確認する。kubectl get svcコマンドでLoadBalancerの外部IPアドレスを取得できる。

最後に、将来のトラブルシューティングや監査のために、この更新がなぜ行われたのかという変更理由を記録しておくことが推奨される。kubectl rollout history deployment/my-first-deploymentコマンドでこれまでの更新履歴を確認できるが、初期状態では具体的な理由が記録されていないことが多い。そこで、kubectl annotate deployment/my-first-deployment kubernetes.io/change-cause="Deployment UPDATE - App Version 2.0.0 - SET IMAGE OPTION"というコマンドを使って、この更新は「アプリケーションバージョン2.0.0への更新で、set imageオプションを使った」という情報を追記する。こうすることで、後から履歴を見たときに、誰が何の目的で更新を行ったのかが明確になる。

次に、二つ目の更新方法であるkubectl edit deploymentコマンドを使った更新を見ていこう。この方法は、コンテナイメージの変更だけでなく、アプリケーションの環境変数、リソース要求（CPUやメモリ）、ポート設定など、DeploymentのYAML定義ファイル内のあらゆる設定を変更したい場合に用いられる。

アプリケーションをバージョンV2からV3へ更新するため、kubectl edit deployment/my-first-deploymentというコマンドを実行する。このコマンドを実行すると、ターミナル上でDeploymentの現在の設定情報がYAML形式で表示され、それを直接編集できるエディタが開く。表示されたYAMLファイルの中から、imageの項目を探し、現在のghcr.io/stacksimplify/kubenginx:2.0.0をghcr.io/stacksimplify/kubenginx:3.0.0に書き換える。変更を保存してエディタを閉じると、Kubernetesはただちにその変更を検知し、ローリングアップデートを開始する。

更新後の検証手順は、一つ目の方法とほぼ同じだ。kubectl rollout status deployment/my-first-deploymentで更新状況を確認し、kubectl describe deployment/my-first-deploymentで詳細を見る。PodとReplicaSetの状態を確認するために、kubectl get rsとkubectl get poを実行する。この時、V1、V2、V3の3つのReplicaSetが存在し、V2のReplicaSetが縮小され、V3のReplicaSetが拡大されていく様子が観察できるだろう。

アプリケーションにアクセスし、バージョンがV3に更新されていることを確認する。そして、同様にkubectl annotateコマンドを使って、「アプリケーションバージョン3.0.0への更新で、edit deploymentオプションを使った」という変更原因を履歴に記録しておく。

これらの手順を通じて、GKE上でKubernetesのDeploymentを更新する二つの主要な方法を学んだ。kubectl set imageは迅速なイメージ更新に、kubectl edit deploymentはより広範な設定変更に適している。どちらの方法もKubernetesのローリングアップデート機能により、アプリケーションを停止させることなく、新しいバージョンへの切り替えを実現する。ReplicaSetとPodの動的な変化を観察することで、この無停止更新の仕組みを深く理解できる。さらに、change-causeを記録することで、更新の履歴を明確にし、運用管理の効率と安全性を高めることができる。KubernetesとGCPの組み合わせは、アプリケーションの更新をシームレスかつ無停止で行い、すべての変更が監査可能となる強力なプラットフォームを提供している。