AKS上のアプリケーションのアップグレード / AKSの基礎を理解するシリーズ Part. 12

この記事の内容

YAMLファイルを編集して kubectl apply で変更を反映する基本的なアップグレード手順
ローリングアップデートの仕組みと、kubectl rollout によるロールバックの方法
kubectl patch コマンドを使ったピンポイントな設定変更の方法
Helm を使ったアプリケーション（WordPress + MariaDB）のアップグレード手順
Kubernetes Secret からパスワードを取得してHelmコマンドに渡す方法

YAMLファイルを編集してアップグレードする

アプリケーションのデプロイ

まず、ハンズオン用のディレクトリに移動し、GuestbookアプリケーションをYAMLファイルから展開します。

kubectl apply -f guestbook-all-in-one.yaml

展開後、Serviceの状態を確認します。このタイミングでは、フロントエンドのServiceにExternal IPが割り当てられていないことを確認できます。

kubectl get service

サービスタイプの変更（LoadBalancerへの切り替え）

YAMLファイルを編集して、フロントエンドのServiceタイプを変更します。

code guestbook-all-in-one.yaml

エディタが開いたら102行目付近にあるフロントエンドのServiceの定義を探します。タイプが指定されていないため ClusterIP になっている箇所を探し、以下のようにアンコメントして LoadBalancer を指定します。

type: LoadBalancer

ファイルを保存して閉じた後、再度 kubectl apply を実行します。

kubectl apply -f guestbook-all-in-one.yaml

実行結果に service/frontend configured と表示されれば、フロントエンドのServiceの構成が変更されています。再度 kubectl get service を実行すると、External IPが割り当てられ、タイプが LoadBalancer に変わっていることを確認できます。

ローリングアップデートとロールバック

イメージのバージョンダウングレード

次に、フロントエンドのコンテナイメージのバージョンを変更する操作を試みます。YAMLファイルを再度編集し、127行目付近にあるイメージのタグを変更します。

# 変更前
image: gcr.io/google-samples/gb-frontend:v4

# 変更後
image: gcr.io/google-samples/gb-frontend:v3

保存して、再度適用します。

kubectl apply -f guestbook-all-in-one.yaml

deployment.apps/frontend configured と表示されます。

ローリングアップデートの確認

Podの状態をウォッチしながら変化を確認できます。

kubectl get pods -w

古いPodが終了し、新しいPodが順次作成されていくのが確認できます。これがいわゆる「ローリングアップデート」です。

詳細なイベントは以下のコマンドで確認できます。

kubectl get events | grep ReplicaSet

ローリングアップデートでは、新しいイメージのPodをスケールアップし、起動が確認できたら古いPodをスケールダウンするという操作を順番に繰り返します。これにより、サービスを止めることなくアップグレードが実現されます。

ReplicaSetとロールアウト履歴の確認

kubectl get replicaset

フロントエンドのReplicaSetが2つ存在しており、現在稼働中のものと以前のものがそれぞれ確認できます。

ロールアウトの履歴は以下のコマンドで確認できます。

kubectl rollout history deployment frontend

REVISION 1、REVISION 2 のように、どのタイミングで何が変わったかの履歴が保存されています。

ロールバック（切り戻し）

1つ前の状態に戻すには、以下のコマンドを実行します。

kubectl rollout undo deployment frontend

ロールバック後に再度ReplicaSetを確認すると、以前のReplicaSetが再び3つのPodを保持していることが確認できます。

kubectl get replicaset

kubectl patch を使った設定変更

YAMLファイル全体を適用する以外に、kubectl patch コマンドを使って特定の箇所だけをピンポイントで変更することもできます。

初期状態への戻し方

YAMLファイルを編集してしまった場合は、まずGitで初期状態に戻します。

git reset --hard

その後、アプリケーションをデプロイします。

kubectl create -f guestbook-all-in-one.yaml

ファイルを使ったパッチ適用

パッチの内容をYAMLファイル（例：frontend-image-patch.yaml）に定義しておき、以下のように適用できます。

kubectl patch deployment frontend --patch "$(cat frontend-image-patch.yaml)"

パッチが正常に適用されたかどうかは kubectl describe で確認できます。

kubectl describe deployment frontend

イメージが変更されており、スケールアップ・スケールダウンのイベントも記録されていれば、パッチが正しく適用されています。

インラインでのパッチ適用

ファイルを用意せずに、コマンドラインで直接パッチ内容を記述することもできます。

kubectl patch deployment frontend --patch '
{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "name": "php-redis",
            "image": "gcr.io/google-samples/gb-frontend:v4"
          }
        ]
      }
    }
  }
}'

kubectl describe deployment frontend で確認すると、イメージがv4に戻っていることが確認できます。

Helmを使ったアプリケーションのアップグレード

WordPressのデプロイ

まず、HelmでWordPressをインストールします。

helm install wp bitnami/wordpress

MariaDBのバージョン確認

現在のMariaDBコンテナのイメージバージョンを確認します。

kubectl describe statefulset wp-mariadb | grep Image

例えば mariadb:10.11.4-debian-11-r0 のように表示されます。

新しいタグの確認

Docker Hub（hub.docker.com/r/bitnami/mariadb/tags）でタグの一覧を確認し、アップグレード先のタグを選びます。ここでは 10.11.4-debian-11-r8 を例として使用します。

Kubernetes Secretからパスワードを取得する

Helmでアップグレードする際にはパスワードの指定が必要です。パスワードはKubernetesのSecretに保存されているため、以下の手順で取得します。

まず、MariaDB用のSecretを確認します。

kubectl get secret wp-mariadb -o yaml

Base64エンコードされたパスワードが確認できます。デコードするには以下のコマンドを使います。

echo "<エンコードされたパスワード>" | base64 --decode

同様に、WordPressのパスワードも取得します。

kubectl get secret wp-wordpress -o yaml

こちらのパスワードもBase64デコードして控えておきます。

Helmでアップグレードを実行する

取得した3つのパスワードを使い、Helmのアップグレードコマンドを実行します。

helm upgrade wp bitnami/wordpress \
  --set mariadb.image.tag=10.11.4-debian-11-r8 \
  --set mariadb.auth.password="<MariaDBのパスワード>" \
  --set mariadb.auth.rootPassword="<rootのパスワード>" \
  --set wordpressPassword="<WordPressのパスワード>"

& kubectl get pods -w を末尾に追加すると、Podの状態変化をリアルタイムで確認しながらアップグレードを実行できます。

MariaDBのPodが Terminating → Pending → ContainerCreating → Running と遷移し、新しいイメージで起動されれば成功です。

アップグレード後の確認

kubectl describe statefulset wp-mariadb | grep Image

イメージタグが新しいバージョンに更新されていれば、アップグレードは完了です。

後片付け

helm delete wp
kubectl delete pvc -l app.kubernetes.io/instance=wp
kubectl delete pv --all

まとめ

AKS上のアプリケーションをアップグレードする方法として、主に以下の3つを紹介しました。

YAMLファイルを編集して kubectl apply — 定義ファイルを修正して再適用するシンプルな方法です。ローリングアップデートにより無停止でのバージョン変更が実現できます。また、kubectl rollout undo を使えば簡単にロールバックが可能です。
kubectl patch コマンド — ファイル全体を適用するのではなく、変更したい箇所だけをピンポイントで指定して更新できます。ファイルから読み込む方法と、インラインで記述する方法があります。
Helm を使ったアップグレード — helm upgrade コマンドでコンテナイメージのタグを指定してアップグレードします。パスワードなどの機密情報はKubernetesのSecretから取得し、コマンドに渡す必要があります。

Kubernetesのローリングアップデートの仕組みを理解することで、サービスを継続しながら安全にアプリケーションを更新できるようになります。ロールバック機能と組み合わせることで、問題が発生した際の切り戻しも容易に行えます。