ステータス：整理 (2026-10-16). 前の5篇で確認した事実のみでまとめています。各篇の根拠と限界はその篇にあります。
目次
1. 目に見えないラベルとデフォルト
5つの障害のうち4つは、誰も意図的に設定していない値から始まりました。
| 障害 | 静かに動作を変えたもの | 誰が決めたのか |
|---|---|---|
| 公式接続 | コントロールプレーンの exclude-from-external-load-balancers ラベル |
kubeadm がインストールの際に自動で |
| GPU | 自動更新は有効、自動再起動は無効 | Ubuntu unattended-upgrades のデフォルト |
| DNS | 最初につくったポリシーの matchPattern: "*"、そして * がドットを超えないというルール |
最初の設計 / Cilium のパターンルール |
| 一括ゲート | \b がカンマの後ろで一致するというルール |
正規表現エンジン |
共通点は 画面に表れないということです。ノード一覧のデフォルト出力にはラベルが見えず、更新ログには「再起動しない」と記載されず、ポリシーは見た目だけもっともらしく、正規表現は短いです。そのため何かを選ぶとき（広告ノード、パターン、正規表現）はその対象の ラベルとデフォルトルールをまず広げて見る習慣が必要です。 kubectl get nodes --show-labels、設定ファイルのコメントアウトされたデフォルト値、製品ドキュメントの「ワイルドカード」の節、正規表現の境界ルールがその「広げて見る」ことに該当します。
2. 「緑のシグナル」と実際の状態
各障害には「問題ない」と伝えるシグナルがありました。そしてそのシグナルは嘘をついていませんでした。 見ている範囲が狭かっただけです。
- クラスター内からゲートウェイへ送ったリクエストは本当に成功していました。ルーターと広告ノードの間を見ていなかっただけです。
- ノードは本当に Ready であり、自動更新は本当に成功していました。メモリ上のカーネルモジュールを見ていなかっただけです。
unchangedは本当に「変更するものがない」でした。読み込んだファイルが古かっただけです。- 機密情報ゲートは本当に通過しました。値があったフォルダを見ていなかっただけです。
- 犯人探しは本当に犯人を知りませんでした。失敗文言の
.jsパスを見ていなかっただけです。
同じ週にデプロイツールのドキュメントでも似たようなものを見ました。ArgoCDのドキュメントでは CronJob のジョブが実行されている間、ステータスが「Progressing」と記載されていましたが、組み込みチェックはその間「Healthy」を出します。ドキュメントと実際が異なっているという不具合チケットを起票し、2026-10-15 に完了としてクローズされました — argoproj/argo-cd#30209。緑のシグナルが何を見て点灯しているのか分からなければ、緑のシグナルは何も教えてくれません。
そこで、このようにすることにしました。 確認は成果物の側で行う。 デプロイされたかどうかはパイプラインの緑のシグナルではなく運用の生み出すファイルで、ポリシーが変わったかどうかは apply の出力ではなくクラスターから再度読み込んだ値で、サイトが開くかどうかは内部からではなく外部から確認します。
3. 人が担う役割と自動化の境界
今週仕事が止まった箇所のほとんどは境界でした。
| 仕事 | なぜ人が担うべき役割なのか | 境界で止まったこと |
|---|---|---|
| GPUノードの再起動 | 同一ノードの他のサービスが切断される。時刻と影響を人が決める | 3日間誰も気づかなかった |
| ハンズオンDNSポリシーの適用 | クラスターの変更。ハンズオンが壊れる可能性がある | 1ヶ月間リポジトリにのみ存在していた |
| 資格情報のローテーション | 値を使用するすべての連携を同時に変更する必要がある | ローテーション前までは履歴内の値が生きている |
| 一括ゲートの失敗判断 | 「犯人不明」は機械が結論を出せない | 機械が26回再実行した |
自動化が人の役割を代行してはなりませんが、 人が担うべき役割を人へ正確に引き継ぐことは自動化の仕事です。今回効果があった引き継ぎはこのような形でした — 原因の1行、そのまま貼り付けるコマンド、影響を受けるもののリスト、そして「やったかどうか」を確認する読み取りコマンド。逆に効果がなかったのはリポジトリに入れて終わりだった変更でした — DNSポリシーはクラスターに適用する人も、適用されたかを確認するコマンドも決まっていないまま1ヶ月を過ごしました。引き継いだ仕事には 確認コマンドと期限が添付されていなければならず、確認されていない引き継ぎは「適用待ち」として目に見える形に残さなければなりません。
4. 直したことをテストで固定する
直したものが再び壊れないようにする方法はテストです。しかし今週は テストも間違えることがあることを示してくれました。
- 資格情報ゲートは追加する前に修正前のツリーで 13箇所が赤くなることをまず確認しました。この順序が正しいです。
- DNSポリシーのテストはポリシー文字列の 形だけを見ていました。そのため意図とは異なる動作をするパターン(
*.cluster.local)が通過しました。テストは「この名前は通過、あの名前は拒否」といった 意味を断言しなければなりません。 - 商標チェックは守るためのテストでしたが、数字の中の
729を商標と誤認しました。守るためのテストにも「これに引っかかってはならない」という例が必要です。
まとめると、テストを追加するたびに3つの事を確認します。①直す前に赤いか、②直した後に緑か、③引っかかってはならない例で緑になっていないか。
5. 次の障害の前に使うチェックリスト
- 対象を選ぶ前にラベル・デフォルト・ワイルドカードルールを広げて確認したか
- 「できる」を成果物の側（外部、クラスターから再度読み込んだ値、運用の生み出すファイル）で確認したか
- 適用コマンドが読み込むファイルはリモートの main のものか、
kubectl diffが空ではないか - 自動更新が有効なノードで、再起動が必要なパッケージがこっそり入り込んでいないか
- リポジトリに入り込んだ機密情報がある場合、ローテーションしたか（ファイルから削除しただけでは不十分）
- 人に引き継いだ仕事にコマンド・影響・確認コマンド・期限が紐づいているか
- 新しいテストが直す前に赤く、引っかかってはならない例で緑になっていないか
- 同じ失敗が2回起きたら立ち止まり、人に見えるようになっているか
Titiの一言。 5回転倒してみて、転んだ場所がどれも似ていました。見えないデフォルト、狭く見る緑のシグナル、誰も引き取らなかったタスク、そして見た目だけを見るテスト。次からはチェックリストをまず広げてから始めましょう！
参考
すべての資料は 2026-10-16 に閲覧しました。
- 今週送ったドキュメントのPR・イシュー： https://github.com/metallb/metallb/pull/3156, https://github.com/NVIDIA/cloud-native-docs/pull/524, https://github.com/argoproj/argo-cd/issues/30209
- 各障害の根拠はこのシリーズの1〜5篇の「参考」にあります。