Google CloudがGKEの障害調査を紹介、3層のバグが判明し最終修正はLinuxカーネルへのパッチ

GKEのKubernetes API接続失敗の概要

podsがKubernetes APIサーバーへ断続的に接続できない症状は、見慣れたタイムアウトでした。ただし、原因は1つではなく、スタックの異なる3層で別々のバグが同時に同じ症状を起こしていました。^[1]

図1　Kubernetes API接続の障害の概要

障害の収束までに、約800人の開発者が数週間にわたって本番環境へデプロイできませんでした。europe-westにまたがるGKEクラスタも、停止状態に陥っています。

調査には、GKEやPrivate Service Connect、ネットワーク、hostnet、カーネルの技術者とLinuxのupstreamコミュニティが加わりました。Private Service Connectは、GKEのコントロールプレーンをプライベートに公開するGoogle Cloudの仕組みです。

複数のnamespacesのpodsのログ例

最初のエラーはeurope-westのUAT（user acceptance testing）クラスタの1つで出て、数日後に同じリージョンの2つ目のクラスタでも出ました。当初のエラーは断続的で、完全な停止ではなくログ上の急増でした。^[1]

図2　接続タイムアウトのログの内容

利用企業は自社のコードを疑い、最近デプロイしたkopfのカスタムoperatorを最初に調べました。しかし、ログ上のエラーはデプロイの8日前に始まっており、完全に停止してもタイムアウトは続きました。

複数のnamespacesのpodsに出たアプリケーションログのうち、タイムアウトを示す例は次の通りです。

TimeoutError: Connect call failed ('1.2.3.4', 443)
dial tcp 1.2.3.4:443: i/o timeout

# 1.2.3.4 is the cluster's internal VIP for the kube-apiserver,
# routed through Private Service Connect

公式資料からの抜粋：When the Kubernetes API went silent: A three-layer networking mystery（Part one: The alarm bell that wouldn't stop）。対象版・範囲：事例のログ。

上記のコードでは、1.2.3.4がクラスタの内部VIPで、kube-apiserver用の接続先です。このVIPへの通信は、Private Service Connectを経由します。

自社のログで同じ形のエラーを調べる場合は、接続先がkube-apiserver用の内部VIPかを確かめる方法が考えられます。エラーが複数のnamespacesのpodsに及ぶかどうかも、確かめる項目の1つです。

接続タイムアウトの事例で除外された原因候補

GKEの障害調査の出発点は、何が変わったかの確認でした。利用企業の時系列から複数の候補を挙げ、その候補を順に確かめています。^[1]

Day 1からDay 22の経過

最初のI/O timeoutは、Day 1にeurope-west3のUATクラスタの1つで出ました。Day 1の時点では断続的で、見過ごしやすいエラーでした。

図3　障害の発生からパケット取得までの経過

Day 10に頻度が大きく増え、エラーは継続的になりました。Day 15には複数のクラスタで影響が確認され、P0のバグが起票されています。

Day 15の時点で約800人の開発者が止まり、本番リリースは凍結されました。Day 20に明白な候補を除外し、Day 22にコントロールプレーンノードのNICとkube-apiコンテナの内部で同時にパケットを取得しています。

原因候補ごとの除外の根拠

この事例の調査では、開始時期の照合や対象の停止と削除、使用量の確認、VMサイズの拡大を試しています。KCPは、Kubernetes control planeの略です。

図4　原因候補の確かめ方

原因候補ごとの除外の根拠は、以下の通りです。

kopfのカスタムoperatorでは、エラーがデプロイの約1週間前から出ていて、停止後も続きました。そのため、このoperatorはすぐに原因候補から除外されました。

DaemonSetsなどの影響範囲

タイムアウトは5つのクラスタで確認され、DaemonSetsやDeployments、system podsに同じように影響しました。開発者のラップトップやGitHub Actions runnersなどの外部クライアントでも、同じ症状が出ています。

図5　タイムアウトを確認した範囲

Google Cloudは、この事例の特異な点を影響範囲の広さと見ています。壊れたワークロードの問題ではなく、Kubernetes APIサーバーまでの経路に問題があると判断しました。

事例の利用企業が運用していたGKE環境の構成

事例の環境は、Google Cloudのeurope-westリージョンで動く大規模なマルチクラスタのGKEです。クラスタはPrivate Service Connectを使い、システムレベルのワークロードを多く動かしていました。^[1]

図6　事例の利用企業のGKE環境の構成

今回の発表はサポート事例の解説で、新機能の提供地域や料金は含まれていません。自社のGKE環境と比べる場合は、事例の構成を発生条件そのものと区別する必要があります。

最終修正は、設定変更やfeature flagではなく、Linuxカーネルへのパッチでした。修正を含むLinuxカーネルの版やGKEの版は、今回の発表に含まれていません。

図7　本記事で扱う範囲

本記事で詳しく扱う調査の経過は、明白な原因候補を除外し、パケットの調査へ進む段階までです。結末は最終修正の形だけを示し、3つの根本原因それぞれの内容は扱っていません。

GKEのpodsのAPIサーバータイムアウト継続時

GKEのpodsからKubernetes APIサーバーへの接続でタイムアウトが続く場合は、最近の変更を確かめたうえで、影響範囲まで広げて調べる方法が考えられます。この事例では、直近のoperatorを止めてもエラーが続きました。^[1]

GKEのpodsからKubernetes APIサーバーへの接続でタイムアウトが続く場合に、確認できる範囲で行う編集部案は、順に以下の通りです。

GKEのpodsからKubernetes APIサーバーへの接続でタイムアウトが続く場合に、確認できる範囲で確かめる項目です。

アプリケーション層の手掛かりが尽きた場合は、パケット単位の確認を次の選択肢に入れる方法が考えられます。この事例では、明白な候補を除外した後にパケットの調査へ進んでいます。

事例のタイムアウトは、3つのバグが同時に起こしていました。同じタイムアウトの症状を調べる場合も、原因が1つとは限らない前提を置くのが妥当でしょう。