DoiT International では、規模の大小を問わず多様なお客様を支援する中で、特に大規模環境で共通して見られる問題に気づくことがあります。今回は、Google の GKE(マネージド Kubernetes)のアップグレードで最近確認された事象について、これからアップグレードを予定している方や同様の問題に直面している方の参考になればと思い、共有します。
症状
すべてのお客様で発生するわけではありませんが、確認されている症状は次のとおりです。
- アップグレード後、kubectl CLI からクラスタを操作できない(API-Server が応答しない)
- アップグレード処理が「ハング」しているように見え、20 分以上経過しても完了しない
- コンソールまたはログに次のようなエラーが表示される:「All cluster resources were brought up, but: component "kube-apiserver" from endpoint "gke-XXXXXXXX-XXXXXXX" is unhealthy.」
リスク診断
全環境で発生するわけではありませんが、共通して見られる条件は以下のとおりです。
- GKE クラスタのバージョンが 1.16 未満
- ゾーンクラスタ(コントロールプレーンが単一ゾーンのマスター構成)
- Istio、Flux、ArgoCD のように API-Server と頻繁にやり取りする「Chatty」な workloads
- 1.12 → 1.13、1.13 → 1.14、1.14 → 1.15、1.15 → 1.16 といったマイナーバージョン間のアップグレード(パッチ更新では通常発生しません)
影響を受ける可能性があるのは?
改めてお伝えしますが、本事象は現時点で一部のお客様でのみ発生しており、その多くはゾーンクラスタを利用し、API-Server に高い負荷をかける workloads を抱えているという特徴があります。その結果、アップグレード時にヘルスチェックの通過に時間がかかりすぎ、「ハング」状態に陥ってしまうのです。本情報が、今後のバージョンアップグレードの計画や、既存の問題のトラブルシューティングのお役に立てば幸いです。
対処方法
Google サポートにヘルスチェックのタイムアウト延長を依頼する
すでに本事象が発生しているものの、ワーカーノードは引き続きトラフィックを処理できている場合(コントロールプレーンへの kubectl アクセスのみができない状態)、Google サポートまたはテクニカルサポートパートナー(できれば DoiT International)にサポートリクエストを起票し、ヘルスチェックのタイムアウトを 3 分に延長してもらうことができます。これにより API-Server の復旧に十分な時間を確保でき、ヘルスチェック失敗の繰り返しを防げます。
ノードプールのサイズと API-Server への負荷を下げる
ワーカーノードのダウンタイムを許容できる場合は、API-Server の負荷を下げるために、「Chatty」な workloads を一時的に停止してスケールダウンするか、ノードプールを 0 までスケールダウンしてアップグレードを完了させた後、改めてスケールアップするという手段もあります。
その他の潜在的な原因
当社のエンジニアの中には、Linux の netfilter/conntrack テーブルに起因する競合状態によってコントロールプレーンへアクセスできなくなった事例に遭遇した者もいます。本問題はすでに修正されていますが、古いバージョンでは影響を受ける可能性がありました。
長期的な解決策
Google のエンジニアは本問題を認識しており、バージョン 1.16 以降(手動アップグレード)向けの修正が来月中にリリースされる予定です。本ブログ執筆時点では、公開のイシュートラッカーのリンクはありません。
クラスタをゾーンからリージョナルへ移行する
残念ながら、ゾーンクラスタをリージョナルクラスタへ簡単にアップグレードする方法は用意されていませんが、当社のクラウドアーキテクトが、人気のオープンソースツール Velero を使った移行アプローチを記事にまとめています。