本稿はJCB Advent Calendar 2024の12月3日の記事です。
PFチームの平松です。
去年の記事では、Google Kubernetes Engine (以下GKE) のアップグレード運用効率化について記載しました。
今回は、前回の記事で記載したGKEクラスタのアップグレード戦略からの変更点について、その背景と詳細について記します。
前提条件
GKEのアップグレード運用を行うにあたり、前提となる当初設定は以下の通りでした。 本条件を念頭に置いてアップグレード戦略の更新に至るまでを記載します。
- GKEのマイナーアップグレードは任意のタイミングで実施
- アップグレード戦略として、チャンネルなし (静的リリース) を採用
- 運用上、Stage適用〜本番適用までにテストのため2週間以上の期間が必要
- Stageと本番は同一パッチバージョンでのリリースを想定
- コントロールプレーンのパッチバージョンの自動アップグレードは許容
以前のGKEアップグレード戦略 : 静的リリースの問題点
これまでGKEクラスタのアップグレードタイミングを完全に制御することを目的として、チャンネルなし(静的リリース)を選択してきました。
静的リリースでは、Googleが提供する自動アップグレード機能を無効化し、任意のタイミングでアップグレード作業を実施することが可能であり、我々のようにマイナーアップグレードのタイミングを完全に制御したいプロジェクトでは有効な戦略でした。
ただし、静的リリースを利用することは以前から公式には非推奨と明記されており、利用し続けることにはリスクが伴っていました。
この状態で2024年も引き続きKubernetesのリリースに合わせて約4ヶ月ごとにアップグレード運用を続けていたところ、9月に意図しないタイミングでコントロールプレーンの自動アップグレードが作動し、マイナーアップグレードが実施されてしまいました。
本件について確認したところ、以下の状況が原因であることが分かってきました。
- 静的チャンネルの自動アップグレードタイミングは公式ドキュメントに記載の通りStableチャンネルのKubernetesマイナーバージョンの自動アップグレード日と同じであり、かつ
- 2024年8月ごろから、Stableチャンネルの自動アップグレードスケジュールが狭まっている (以下の2024年11月時点の各チャンネルの自動アップグレード日目安のスクリーンショット及び表参照)
minor version | Regular Availableから Stable Auto Upgradeまで | Stable Availableから Stable Auto Upgradeまで |
---|---|---|
1.26 | 293日 | 223日 |
1.27 | 318日 | 298日 |
1.28 | 236日 | 200日 |
1.29 | 197日 | 59日 |
1.30 | 56日 | 42日 |
上記の通り、1.29 ~ 1.30間GKEの自動アップグレード期間が短く、公式記載の期日を超えたことで自動アップグレードがいつ実行されてもおかしくない状態となっていることがわかりました。
対策として自動アップグレードのメンテナンス除外ポリシーを適用する方法を検討しましたが、静的リリースでは30日以上連続で設定することができない(30日ごとに48時間の除外NG期間が必ず挿入される)という制約があるのでこの方法は利用できません。
また、自動アップグレード期間に注目して「最大4ヶ月間、それまでに自動アップグレード期間が迫ればそちらを優先してアップグレードを実施する」運用を定めれば良いという考え方もできますが、アップグレードにはGKEの上で稼働している全てのサービスにも影響し、かつ全チームの工数を必要とするため、現状の4ヶ月の頻度を上げていくことはあまり現実的ではありません。
このように突き詰めていくと、従来通りの静的リリースでの運用は困難という結論に至りました。
リリースチャンネルへの登録
この課題を解決するために、我々はGKEクラスタのアップグレード戦略を見直し、リリースチャンネルへの登録を決定しました。
リリースチャンネルのうちStableチャンネルとRegularチャンネルでは、そのままでは自動アップグレードが定期的に実施されます。
しかしメンテナンス時間枠と除外を設定することで、マイナーバージョンのアップグレードタイミングを標準サポート期間まで制御することが可能です。
ただし、リリースチャンネルに登録した場合、アップグレード可能なバージョンは以下のコマンドで確認できるいずれかのリリースチャンネル上に含まれるvalidVersionsに限られる模様です。
% gcloud container get-server-config --flatten="channels" --format="yaml(channels.channel, channels.validVersions)" --location asia-northeast1 Fetching server config for asia-northeast1 --- channels: channel: EXTENDED validVersions: - 1.31.1-gke.2105000 - 1.31.1-gke.2008000 - 1.31.1-gke.1846000 - 1.30.5-gke.1699000 - 1.30.5-gke.1443001 - 1.29.10-gke.1054000 - 1.29.9-gke.1541000 - 1.29.9-gke.1496000 (中略) --- channels: channel: RAPID validVersions: - 1.31.2-gke.1518000 - 1.31.2-gke.1384000 - 1.31.2-gke.1354000 - 1.31.1-gke.2105000 - 1.30.6-gke.1125000 - 1.30.6-gke.1059000 - 1.30.5-gke.1713000 - 1.30.5-gke.1699000 - 1.29.10-gke.1227000 - 1.29.10-gke.1155000 - 1.29.10-gke.1071000 - 1.29.10-gke.1054000 (中略) --- channels: channel: REGULAR validVersions: - 1.31.1-gke.2105000 - 1.31.1-gke.2008000 - 1.31.1-gke.1846000 - 1.30.5-gke.1699000 - 1.30.5-gke.1443001 - 1.29.10-gke.1054000 - 1.29.9-gke.1541000 - 1.29.9-gke.1496000 (中略) --- channels: channel: STABLE validVersions: - 1.30.5-gke.1443001 - 1.30.5-gke.1014003 - 1.29.9-gke.1496000 - 1.29.9-gke.1177000 (中略)
静的リリースの場合は、以下の通りコントロールプレーンはvalidMasterVersionsに記載のバージョン、ノードプールはvalidNodeVersionsに記載のバージョンが選択可能です。
% gcloud container get-server-config --format="yaml(validMasterVersions)" --location asia-northeast1 Fetching server config for asia-northeast1 validMasterVersions: - 1.31.2-gke.1518000 - 1.31.2-gke.1384000 - 1.31.2-gke.1354000 - 1.31.1-gke.2105000 - 1.31.1-gke.2008000 - 1.31.1-gke.1846000 - 1.30.6-gke.1125000 - 1.30.6-gke.1059000 - 1.30.5-gke.1713000 - 1.30.5-gke.1699000 - 1.30.5-gke.1443001 - 1.30.5-gke.1355000 - 1.30.5-gke.1014003 - 1.30.5-gke.1014001 - 1.29.10-gke.1227000 - 1.29.10-gke.1155000 - 1.29.10-gke.1071000 - 1.29.10-gke.1054000 - 1.29.9-gke.1541000 - 1.29.9-gke.1496000 - 1.29.9-gke.1177000 (中略)
% gcloud container get-server-config --format="yaml(validNodeVersions)" --location asia-northeast1 Fetching server config for asia-northeast1 validNodeVersions: - 1.31.2-gke.1518000 - 1.31.2-gke.1384000 - 1.31.2-gke.1354000 - 1.31.2-gke.1115000 - 1.31.1-gke.2105000 - 1.31.1-gke.2008000 - 1.31.1-gke.1846000 - 1.31.1-gke.1678000 - 1.31.1-gke.1146000 - 1.30.6-gke.1125000 - 1.30.6-gke.1059000 - 1.30.5-gke.1713000 - 1.30.5-gke.1699000 - 1.30.5-gke.1628000 - 1.30.5-gke.1443001 - 1.30.5-gke.1355000 - 1.30.5-gke.1145000 - 1.30.5-gke.1014003 - 1.30.5-gke.1014001 - 1.30.5-gke.1014000 - 1.30.4-gke.1476000 - 1.30.4-gke.1348001 - 1.30.4-gke.1348000 - 1.30.4-gke.1282000 - 1.30.4-gke.1213000 - 1.30.4-gke.1129000 - 1.30.3-gke.1969002 - 1.30.3-gke.1969001 - 1.30.3-gke.1639000 - 1.30.3-gke.1451000 - 1.30.3-gke.1225000 - 1.30.2-gke.1587003 - 1.30.1-gke.1329003 - 1.29.10-gke.1227000 - 1.29.10-gke.1155000 - 1.29.10-gke.1071000 - 1.29.10-gke.1054000 - 1.29.10-gke.1043000 - 1.29.9-gke.1541000 - 1.29.9-gke.1496000 - 1.29.9-gke.1341000 - 1.29.9-gke.1177000 - 1.29.8-gke.1278000 - 1.29.8-gke.1211000 - 1.29.8-gke.1157000 - 1.29.8-gke.1096000 - 1.29.8-gke.1057000 - 1.29.8-gke.1031000 - 1.29.7-gke.1274000 - 1.29.7-gke.1174000 - 1.29.7-gke.1104000 - 1.29.7-gke.1008000 - 1.29.6-gke.1326000 - 1.29.6-gke.1254000 - 1.29.6-gke.1137000 - 1.29.6-gke.1038001 - 1.29.6-gke.1038000 - 1.29.5-gke.1192000 - 1.29.5-gke.1121000 - 1.29.5-gke.1091002 - 1.29.5-gke.1091001 - 1.29.5-gke.1091000 - 1.29.5-gke.1060001 - 1.29.5-gke.1060000 - 1.29.5-gke.1010000 - 1.29.4-gke.1670000 - 1.29.4-gke.1542000 - 1.29.4-gke.1447001 - 1.29.4-gke.1447000 - 1.29.4-gke.1165000 - 1.29.4-gke.1043004 - 1.29.4-gke.1043002 - 1.29.4-gke.1043001 - 1.29.4-gke.1043000 - 1.29.3-gke.1282005 - 1.29.3-gke.1282001 - 1.29.3-gke.1282000 - 1.29.3-gke.1093006 - 1.29.3-gke.1093000 - 1.29.2-gke.1521000 - 1.29.2-gke.1217000 - 1.29.2-gke.1060000 - 1.29.1-gke.1589020 - 1.29.1-gke.1589018 - 1.29.1-gke.1589017 - 1.29.1-gke.1589000 - 1.29.1-gke.1575000 - 1.29.1-gke.1425000 - 1.29.1-gke.1016000 - 1.29.0-gke.1381000 (中略)
リリースチャンネル登録と静的チャンネルを比較すると、適用可能なバージョンに若干の差異があります。
例えば、リリースチャンネル(Extended/Rapid/Regular/Stable)のvalidVersionに記載の無いバージョン(上記の例だと1.30.5-gke.1355000 等)が、静的リリースのvalidMasterVersionには存在します。
このように静的リリースの方が選択できるパッチバージョンの種類が多く、過去に遡って設定することが可能です。
また、基本的にGKEはほぼ毎週パッチリリースが入り、最短で1週間程度でその時選択可能であったバージョンが選択不可になります。 すると前提であるStage適用〜本番適用までにテストのため2週間以上の期間が必要であるため、実際にStageをアップグレードした2~3週間後にいざ本番をアップグレードしようとした際に、Stageで選択したパッチバージョンはすでに選択不可となってしまいます。 従って、リリースチャンネルに登録した場合はStageと本番は同一パッチバージョンでのリリースを行うという前提条件の達成は困難となります。
まとめると、リリースチャンネルに登録する場合と静的リリースは以下の通り整理できます。
種別 | メンテナンス時間枠 | Stage/本番バージョンの一致可否 |
---|---|---|
各リリースチャンネル | 標準アップグレード期間まで | 不可 |
静的リリース | 最大30日間まで | 可 |
以上からリリースチャンネルに登録・静的リリースの継続双方とも、全ての前提条件をクリアすることは事実上不可という結果となりました。 しかし、最終的な判断としてはStage/本番間のパッチバージョンの差異については許容し、自動でのマイナーアップグレードを避けることを優先する方針としました。 その判断根拠は以下となります。
- コントロールプレーンのパッチバージョンに関しては自動アップグレードは許容するのでいずれバージョン差異はなくなる可能性がある
- いずれのバージョンもGoogleの公式サポートバージョンであるため、問題発生可能性は限りなく低い
また、登録するチャンネルとしては、安定性を重視かつアップグレードサイクルもこれまで通り4ヶ月サイクルを採用する方針であることから、Stableチャンネルを選定しました。
チャンネル | 説明 |
---|---|
Rapid | Kubernetesの最新リリースをいち早く取り込む場合に利用する。 ただし安定版ではないため、GKEのSLAは適用されない。 |
Regular | 安定版として扱われるため、新機能の利用と可用性のバランスを保ちたい場合に有効。 |
Stable | 新規性よりも安定に重きを置いたバージョン。 |
Extended (New) | 標準サポート期間終了後も延長サポート有効。ただし別途料金が必要。 |
まとめ
Stableチャンネルへの登録及びメンテナンス時間の設定を実施することより、マイナーバージョンの自動アップグレードについては抑止することができました。
今後もGKEアップグレード運用に関して最新のトレンドやベストプラクティスを取り入れながら、より安定した運用を目指していきます。
終わりに
JCBでは我々と一緒に働きたいという人材を募集しています。 詳しい募集要項等については採用ページをご覧下さい。
本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、製品名は各社及び商標権者の登録商標あるいは商標です。
また、記事の内容は、公開時点の情報に基づいています。最新の情報については、Google Cloud の公式ドキュメントをご確認ください。