非推奨APIを乗り越える:安心して進めるGKEアップグレード

GKEクラスタのアップグレードでは、思わぬ壁にぶつかることがあります。本記事では、一見シンプルなバージョン1.27へのアップグレードが「非推奨APIの呼び出し」によってブロックされた実例を取り上げ、その原因を掘り下げていきます。

GKEが自動アップグレードを一時停止する仕組み

GKEは非推奨機能やAPIの使用を検出すると、クラスタが壊れた状態にアップグレードされるのを防ぐため、自動アップグレードを一時停止します。次のKubernetesマイナーバージョンへのアップグレードは止まりますが、現在のマイナーバージョンに対するパッチアップグレードは引き続き提供されます。

非推奨機能の使用や非推奨APIへの呼び出しが30日間検出されなければ、次のマイナーバージョンがそのクラスタのリリースチャンネルにおけるデフォルトバージョンである場合に限り、クラスタは自動的にアップグレードされます。

一方、GKEがクラスタ上で非推奨機能の使用を検出し続けた場合は、そのバージョンのサポート終了日まで現在のマイナーバージョンに留め置かれます。リリーススケジュールで確認できるこの日付を迎えると、クラスタは次のマイナーバージョンに自動アップグレードされますが、削除された機能が依然として使われていれば、クラスタ環境に支障が出る可能性があります。

今回のケースでは、バージョン1.26からのアップグレードを妨げている原因として、GKEが非推奨APIへの呼び出しを検出していました。しかしクラスタ内をいくら調べても、原因とされる「非推奨APIを使用するhorizontalPodAutoscaler」の痕跡は見当たりません。

調査のステップ

GKE Insights: GKE Insightsでは非推奨API呼び出し(horizontalPodAutoscaler v2beta2)とユーザーエージェント("v2.3.0")を確認できましたが、ユーザーエージェントの情報だけでは手がかりになりませんでした。
非推奨API: 1.27の非推奨APIリストを見ると、HPA v2beta2はKubernetes 1.26以降のクラスタでは利用できないことがわかります。
管理アクティビティ監査ログ: 最初に推奨される調査方法は、以下のログクエリで非推奨APIへの書き込み呼び出しを行っているAPIクライアントを特定することです。このクエリの実行にはroles/logging.viewerロールが必要です。

resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")

データアクセス監査ログ: 次のステップとして、非推奨APIへの読み取り呼び出しを行っているAPIクライアントを特定します。まずKubernetesのデータ読み取りと管理者読み取りを有効化する必要があります。ログを閲覧するにはroles/logging.privateLogViewerロールも必要になる場合があります。

原因の特定

ログが蓄積されるのを待ったところ、原因が見えてきました。古いバージョン(2.3.0)のkube-state-metricsです。Kubernetesオブジェクトのモニタリングサービスであるkube-state-metricsが、非推奨のv2beta2 APIに対して「list」呼び出しを行い、アップグレードのブロックを引き起こしていたのです。クラウド環境の各要素がいかに密接につながっているかを物語る事例といえます。

ソースコードを見れば、呼び出しが発生している箇所を正確に確認できます。

解決策

kube-state-metricsを非推奨APIを使用しないバージョンへアップグレードすることで問題は解消し、GKEのアップグレードもスムーズに進められるようになりました。

まとめ

ログバケットの除外フィルタを確認: 調査をスピードアップするため、データアクセス監査ログがログバケットの除外フィルタで弾かれていないか確認しましょう。
APIの変更情報を常にキャッチアップ: Kubernetes APIの変更を先回りしてウォッチし、アップグレード時の障害を未然に防ぎましょう。
静的バージョンとリリースチャンネルの違いを理解する: アップグレード戦略では、静的バージョン(安定性)とリリースチャンネル(自動的なセキュリティ修正)のトレードオフを踏まえて選択しましょう。
アップグレードを戦略的に管理する: 自動アップグレードとメンテナンス除外を組み合わせてタイミングをコントロールしつつ、重要なセキュリティ修正についてはパッチアップグレードを許可するといった判断も検討しましょう。
ログのコストにも目配りを: データアクセス監査ログを有効化すると追加コストが発生する可能性があります。長期間オンにする前に、本当に必要かを見極めましょう。

これらのポイントを押さえることで、GKEのアップグレードにより自信を持って臨み、クラウド運用への影響を最小限に抑えられます。

DoiT Internationalをまだご存じない方は、ぜひ一度サイトをご覧ください。私たちは、お客様のクラウドエンジニアリングに関する課題に耳を傾ける準備ができています。シニアエンジニアのみで構成されたチームが、高度なクラウドコンサルティング、アーキテクチャ設計、デバッグに関するアドバイスをご提供します。お気軽にお問い合わせください。

本記事が少しでもお役に立てば幸いです。ご質問があれば、下のコメント欄までお気軽にお寄せください。

GKEが自動アップグレードを一時停止する仕組み

GKEアップグレードがブロックされた事例