タイトル：バグハント：GKEにおけるWireGuardクラッシュとMTU不一致

Lovableのインフラチームは、Google Kubernetes Engine（GKE）上のクラスタ全体のネットワーク問題をデバッグし、断続的な接続障害を引き起こしていることを突き止めました。AIエージェントを使ってClickhouseのログをスキャンしたところ、anetdポッド（GoogleのCilium実装）が6日間でポッドあたり約120回クラッシュしていることが判明しました——ほぼ1時間に1回のペースです。クラッシュダンプから、WireGuard自体ではなく、GoogleのWireGuard統合コードにおける同時マップアクセスのパニックが明らかになりました。

最初の修正：透過的暗号化の無効化

Googleサポートは、WireGuardのバグを回避するためにノード間暗号化を無効にすることを推奨しました。チームはこの変更を適用し、すべてのanetdポッドを再起動しました。クラッシュは約4時間停止しました——その後、ユーザーはValkey（インメモリデータストア）へのランダムな接続障害に気づき始めました。

2つ目のバグ：MTUの不一致

エンジニアのErikはtcpdumpとWiresharkを使用してパケットをキャプチャしました。証拠は決定的でした：「Destination unreachable (Fragmentation needed)」。原因は次の通りです：

• WireGuard有効時、クラスタのMTUは1420バイトに設定されていました（WireGuardの80バイトカプセル化オーバーヘッドを考慮）。
• WireGuardを無効にした後、設定は標準の1500バイトに戻るはずでしたが、一部のノードが再起動されておらず、古い1420バイトのMTUが使われ続けていました。
• MTUが一致しないノードをまたがるValkey接続が断続的に失敗しました。

解決策

修正方法：すべてのノードのローリング再起動により、クラスタ全体で一貫したMTU設定を確保しました。これにより断片化エラーが解消され、安定性が回復しました。

重要な教訓

• 最初のバグはGoogleのanetdにおけるWireGuard統合にありました——マップアクセスの同時実行バグです。GKEの実装に固有の問題です。
• 暗号化を無効にすることでパニックは回避できましたが、MTU不一致が発生し、全ノードのロールアウトが必要になりました。
• AIエージェントは、数百万行のログからanetdのクラッシュパターンを迅速に浮き彫りにするのに役立ちました。