HARUMI
Notes

2026-07-21

アップグレードは完了していたが、ノードはまだ仕事を受け付けていなかった

全ノードが新バージョンを報告していたのでアップグレードは完了に見えた——しかし control plane は cordon されたままで、4 つのレプリカに行き先がなかった。

背景

3 ノード全てで kubeadm による 1.32.13 → 1.33.13 のアップグレードが実施済みでした。バイナリは入れ替わり、全ノードが新バージョンを報告していました——通常はここでアップグレード完了と判断する状態です。

経路

症状
完了したはずのアップグレード後、4 つのレプリカが Pending のまま
仮説
Pod 自体が壊れていると仮定
計測
スケジューラーの数字を読む: 0/3 nodes available、ノード一覧は SchedulingDisabled
判断
uncordon し、最後の uncordon を明示的な手順に格上げ

対応

control plane を uncordon し、バージョン確認をアップグレードの完了条件として扱うのをやめました。残りのスケジューリング余地は偶然ではありません——worker はワークロードの affinity に適合せず、3 台目は専用の taint を持っていたため、cordon された control plane が唯一の候補で 0/3 という結果でした。同時に半数の namespace で発生していた CrashLoopBackOff / ImagePullBackOff の波は意図的に放置しました——ノードアップグレード後の sandbox とレジストリの再起動ウィンドウであり、数分で自然に解消しました。

運用スキルの更新

スキルharumi-infra-managerコミットinfra@0e92e82

運用スキルに、最後の uncordon をアップグレード手順の完了として推定せず明示的に確認することを必須として追加し、アップグレード直後の Pod 不安定期間は介入不要の想定挙動として記録した。