Intermittent 413s caused by h2c upgrade + JDK HttpClient + Tomcat maxSavePostSize: root cause, troubleshooting playbook, and a deterministic kind reproduction.

基于 Kubernetes 1.35 官方文档和实操验证，梳理 VPA 的 InPlaceOrRecreate 模式、原地调容的工作链路，以及落地时最容易踩的坑。

我顺着一个 Pod DNS 排查短视频，把 K8s Service 网络链路重新整理了一遍：DNS 解析、ClusterIP 到 Pod IP 的 DNAT、EndpointSlice、负载均衡，以及 1.36 时代 iptables/IPVS/nftables/eBPF 的取舍。

以 diegolnasc/kubernetes-best-practices 仓库为蓝本过一遍 K8s 生产实践，顺手补上 Gateway API、ValidatingAdmissionPolicy、原生 Sidecar 这些仓库还没覆盖的新特性。

结合一份 2026 年调查和我自己的阅读笔记，整理 K8s 容器化 Java 应用里三个常见 JVM 配置决策：JDK_JAVA_OPTIONS、MaxRAMPercentage，以及 GC 选择。

把 mirrord OSS 接入 VS Code 时撞上一个 WebSocket 403，最后追到 K8s impersonation 的两条 authorization 链路，记录了排查、原理和最小修复。

不用 Spring Cloud Config Server 也能把 feature flag 做出来：Gateway、微服务和 React 三个角色共用同一个 flagd，热加载方案选型和 OFREP 跨栈一致性都在 kind 环境里验证过。

给 mirrord OSS 做一套按 namespace 授权的开发者接入 demo：kubeconfig 走 Kubernetes CSR API 签发，ClusterRole 集中审查能力，授权和撤销都落在 RoleBinding 这一层。

开关语义和供应商解耦之后，剩下的问题是 flag 从哪儿读、改完怎么不重启就生效。shop 项目这一版把这两件事分别交给 Spring Config 和 Configuration Watcher。

Java 25 跑在 Kubernetes 上，默认堆只用了 25%，CPU 节流的影响也比预期大，这几组实验数据和值得优先验证的配置项放在一起。