概要
Kubernetes apiserver の admission 処理において、存在するはずの Namespace が「namespace not found」と誤判定されてリクエストが拒否され得る問題を抑止する修正（LWKD: Week Ending Nov 30, 2025 の項目）。対象は主に ValidatingAdmissionPolicy / MutatingAdmissionPolicy を使って namespaced リソースを扱うケース。
変更内容（何が変わったか）
- ValidatingAdmissionPolicy / MutatingAdmissionPolicy の Namespace 参照が、キャッシュ（lister）が
NotFoundを返した場合に「ライブ取得（ストレージ直）」へフォールバックするように調整された（他の admission 実装と挙動を揃える意図）。 - 具体的には、Namespace 取得インターフェイスが
context.Contextを受け取る形に変更され、Namespace 取得側でNamespaceLister.Get()がNotFoundのときにClient.CoreV1().Namespaces().Get(ctx, ...)を追加で試すようになった。 - Mutating 側では、Namespace 取得で返ってきたエラーが
StatusErrorの場合に、それをそのまま返すような扱いも入っている（不必要なNotFoundへのラップを避ける意図）。
背景（なぜこの変更が必要か）
- apiserver は性能のために informer/lister のキャッシュを使うが、Namespace を作った直後などに watch/informer が未追従だと、キャッシュ上は
NotFoundになり得る。 - この
NotFoundを「本当に Namespace が無い」と扱うと、Policy が有効な環境で namespaced オブジェクト作成が 404 相当で拒否される（例: 新規 Namespace 作成直後に Deployment/StatefulSet を作ると失敗し得る、という報告）。 - 既存の admission 実装（例: webhook admission 側など）は、キャッシュ
NotFound時にライブ取得へフォールバックすることで、この種の一時的不整合を吸収しており、Policy 系も同様にすべきという整理。
影響（運用者/利用者/開発者への影響、注意点、移行）
- 運用者/利用者:
- ValidatingAdmissionPolicy / MutatingAdmissionPolicy を使っている環境で、新規 Namespace 作成直後のリソース作成が「namespace not found」で弾かれるタイプの一時的失敗が減る。
- PR のリリースノートでは「Kubernetes 1.30+ のデフォルト構成で、VAP/MAP が新規 Namespace 内の namespaced オブジェクトをインターセプトする場合に起こり得る」と説明されている。
- 開発者:
- Namespace 取得 API が
GetNamespace(ctx, name)形式になり、インターフェイス上の期待（空 name の扱い等）も更新されているため、周辺実装（テスト含む）の追従が必要。
- Namespace 取得 API が
用語メモ（用語の軽い説明）
- Admission: apiserver がリクエストを 受理/拒否/変更するための仕組み（認可の前後などで実行されるプラグイン群）。
- ValidatingAdmissionPolicy / MutatingAdmissionPolicy: ポリシー定義に基づき、リクエストを 検証（拒否）／**変更（mutate）**できる admission 機能。
- Informer/Lister（キャッシュ）: apiserver/コントローラが watch 経由で保持する ローカルキャッシュ参照。更新遅延があり得る。
- NotFound: オブジェクトが見つからないことを示すエラー（キャッシュ遅延でも一時的に起こり得る）。
- ライブ取得（direct to storage）: キャッシュではなく **実ストレージ（API 経由）**で存在確認する取得。