はじめに
Google Kubernetes Engine（以下、GKE）は、Google Cloudが提供するマネージドなKubernetesサービスです。
Kubernetesは、Googleの社内クラスタ管理システムであるBorgを起源として誕生したことでも知られています。GKEを利用することで、Googleのインフラストラクチャ上でコンテナアプリケーションを大規模にデプロイ・運用することが可能です。
もっとも、GKEを使用することで簡単にクラスタが立ち上がる一方で、システムを安定的に稼働させ続けるためには運用保守の観点でいくつか注意すべきポイントがあります。
本記事では、その中でもGKEクラスタのアップグレード戦略にフォーカスし、最低限押さえておきたい知識として、リリースチャンネルとPod Disruption Budget（PDB）について解説します。
自動アップグレードの考え方
GKEクラスタのアップグレードは、基本的にGoogleによって管理されているため、ユーザーはリリースチャンネルやメンテナンスの時間枠などの機能を用いてその実行タイミングを調整する運用になります。
アップグレードに関する内容は、公式ドキュメントの「GKE のクラスタ アップグレードについて」の通りにコントロールプレーンとノードの両方に対して適用されます。
GKE は、コントロールプレーンのアップグレードとノードのアップグレードの両方を含む、以下の種類のクラスタ アップグレードを実施します。
- パッチ バージョン アップグレード: リリース チャンネルに応じて、クラスタを新しいパッチに毎週自動的にアップグレードします。
- マイナー バージョン アップグレード: マイナー アップグレードは年に約 3 回発生します。Extended チャンネル クラスタの場合、マイナー アップグレードは、マイナー バージョンの拡張サポートの終了が近づいたときにのみ行われます。
週次でパッチが適用されるため、アップグレード戦略について何も考えていない場合、意図しないタイミングでのアップグレードによって、システムが一時的に停止するリスクが生じます。従ってGKEクラスタの管理者は適切にアップグレードを管理する責任1が伴います。
安定した運用を実現するための第一歩は、リリースチャンネルを選択して登録することです。
Kubernetesは、頻繁にセキュリティアップデートや新機能をリリースしています。例えば、Stableチャンネルに登録することで、Googleが検証した安定性の高いバージョンのみが適用されるため、本番環境の信頼性が向上します。
Stableチャンネルは新機能の適用が遅れることや重要なセキュリティパッチはどのチャンネルでも緊急に適用される可能性があることは理解しておく必要があります。
Kubernetesのマイナーバージョンに対するGKEのサポートは、Kubernetesオープンソースポリシーに基づいています。マイナーバージョンのライフサイクルについては「GKE のバージョニングとサポート」をご参照ください。
リリースチャンネル
現在利用できるチャンネルは、Rapid、Regular、Stable、Extended、チャンネルなしの5種類があります。
それぞれの違いについては「利用できるチャンネル」より確認できます。
また、StandardクラスタやAutopilotクラスタ、リリース チャンネルに登録されていないクラスタかどうかによってアップグレードの動作が異なるため、ご注意ください。
リリース チャンネルに登録されていないクラスタのアップグレードについては、「リリース チャンネルに登録されているクラスタと登録されていないクラスタの比較」より確認できます。
リリースチャンネルに登録するメリットは、「リリース チャンネルのおおよそのスケジュール」を参考にすることで、リリースに対する計画が立てやすくなります。また、リリースに関する情報は「GKE リリースノート」より確認できます。
リリースチャンネルの登録方法
既存のGKEクラスタをリリースチャンネルに登録する例を以下に記載します。
GKEのクラスタ画面を開き、画面上部に警告のメッセージが表示されている場合は「詳細を表示」を押します。
「リリースチャンネルでのクラスタの登録」の画面が表示されるので「リリースチャンネルに登録」を押します。
「リリースチャンネルの変更」の画面が表示されるのでプルダウンを押します。
リリースチャンネルが表示されるので任意のチャンネルを選択します。
リリースチャンネル選択後「変更を保存」を押します。
リリースチャンネルの変更方法
登録したリリースチャンネルを変更したい場合は、クラスタの詳細画面より「クラスタの基本」セクションの「リリース チャンネル」サブセクションを編集します。
アップグレードに関する情報
アップグレード画面では、アップグレードに関する様々な情報に素早くアクセスできます。
「概要」セクションよりリリースチャネルやバージョンのサポート終了、アップグレード ログなどの情報について確認できます。
また「タイムライン」のセクションではメンテナンスの時間枠を含めたタイムラインの情報が可視化されています。
Pod Disruption Budgets
Pod Disruption Budgets（以下、PDB）が設定されていない場合、ノードのアップグレード時にワークロードが中断される可能性があります。
たとえReplicaSetによってPodを複製していても、ノードアップグレードの際に何らかの障害が発生してPodが正常に起動できなければ、Podが同時に停止するリスクが生じます。
従ってPDBを設定することで、自発的な中断が発生した場合でも、同時に停止するPodの数を制限するため、システムの瞬断を防ぎ可用性の高いアプリケーション運用が可能になります。
PDBはコンソール画面から設定できないため、Kubernetesのリソースオブジェクトとしてマニフェストを作成する必要があります。
PDBの詳細については、Kubernetes公式ドキュメントの「Pod disruption budgets」をご参照ください。
以下は、最低限1つのPodを常に稼働させる例です。selectorで指定するラベルは、対象とするPodのラベルと一致している必要があります。
- pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
namespace: my-app
spec:
minAvailable: 1
selector:
matchLabels:
app: my-app
上記で作成したリソースをGKEクラスタにデプロイする場合は、Cloud Shellを使用して以下のコマンドを実行します。
user@cloudshell:~ (project)$ kubectl apply -f pdb.yaml --namespace my-app
poddisruptionbudget.policy/my-app-pdb created
以下のコマンドを実行すると、リソースの状態について確認できます。
user@cloudshell:~ (project)$ kubectl get PodDisruptionBudget --namespace my-app
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
my-app 1 N/A 1 3m30s
リリースチャンネルやPod Disruption Budgetsを設定後、クラスタの詳細画面の画面上部に表示されている警告のメッセージは、すぐには消えないため、設定変更後に警告メッセージが表示されていても機能的には問題ありません。アプリケーションは計画的な中断から保護されています。
警告メッセージが表示されなくなると、アップグレード画面の「アップグレードに関する推奨事項」にも表示されなくなります。
「中断の許容範囲を設定する」にも注意書きがありますが、PDBによって保護されるのは、自発的な中断（アップグレードなど）のみです。従って偶発的な障害（ハードウェア障害など）から保護することはできません。
PDBが正しく適用されているかについては、ログ エクスプローラを使用してアップグレード時のログを参照することで確認できます。PDBで指定しているPodのデプロイ間隔がPDB設定前より長くなっていたり、PDBのステータスを更新した際の監査ログから対象のPodが保護されていることが分かります。
おわりに
本記事で紹介しているのはGKEのアップグレード戦略の一部にすぎません。
GKEには他にも「ノードのアップグレード戦略」や「ロールアウトの順序付けを使用したクラスタ アップグレードについて」などさまざまな戦略があります。
これらの仕組みを理解した上で「クラスタのアップグレードに関するベスト プラクティス」を実践することが重要です。