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

Proxmox VM 一重启 Vault 就 sealed，ExternalSecret 跟着失败：postStart 解锁 hook 被 JSON grep 误判、ESO 没有及时重验，恢复脚本自己还有假阴性，最后改成按 exit code 三态判定。

一次看起来像 Cilium Gateway Degraded 和 ArgoCD Sync 异常的故障，最后追到了 CoreDNS stub resolver、ZITADEL backend 缺失和 Vault 密钥问题。记录完整排查链路、修复动作和后续固化方案。

oracle-k3s 从 Flannel 换到 Cilium，翻出 QUIC 超时、Secret 供应链断裂、健康检查和连接串失效、PVC 数据回灌四类问题，哪些复杂度值得保留也因此重新排了序。

homelab K3s 从默认 Flannel 换到 Cilium 之后冒出三个问题：Cloudflared QUIC 握手超时、Pod 访问不到节点物理 IP、ZITADEL 报 Master Key 长度错误，三个成因不同，解法也不同。

disableThinking() 本该只关推理，结果 think 字段泄漏进了 options map，Ollama 返回 HTTP 400。上游修复还没进正式版，我用一个 ClientHttpRequestInterceptor 在请求发出前把它摘掉。

集成测试卡在 make coverage 阶段，第一眼看到的是连接池超时，真正让进程挂住的是 Reactive Redis 下 Lettuce SharedLock 的自旋，两层问题得分开修。

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

A seemingly harmless removal of publishOn(Schedulers.boundedElastic()) led to cascading Redis timeouts in production. This post explains how Spring’s @Cacheable blocks the Netty event loop when used with RedisCacheManager, and why BlockHound failed to catch it.

我在 homelab 的 k8s 集群中使用 helm 部署了 postgresql，但是 prometheus stack 没有采集到 postgresql 的指标数据。怎么排查这个问题呢？