Kubernetes 1.37 在 2026-08-26 发布，67 项 enhancement 里真正影响升级的不多：四条 ACTION REQUIRED、一批默认值翻开的 Beta gate、三条带版本期限的弃用。

hostname 已经写在 Ingress 或 HTTPRoute 里，再去 DNS 那边手建一条记录，等于给集群状态留了一份要同步维护的副本。交给 external-dns 的代价是自己定三件事：读哪种资源、target 指向哪里、哪些记录归这个实例。

容器内存告警冲到 99.45% 却没触发 OOM，峰值里约 87% 是页缓存；同一个容器热缓存下重启只剩 23.70%，最后把告警的分子换成 RSS。

夜间备份那段时间内存接近 limit，按每次运行重新对齐数据后才发现根因：书库 pod 重建时 kubelet 对 local PV 做 fsGroup 权限处理，restic 因此重读整库。

两个 K3s 集群的子域名 DNS 从 Terraform 手改交给 external-dns 之后，加一个子域名只剩一步，真正的难点是把既有记录零停机迁过去，得先预埋 ownership TXT。

mirrord 的开发者授权从脚本式操作改成 GitOps：每人一份 RoleBinding 与 ClusterRoleBinding 写进 Git，由 Argo CD 带 prune 同步；证书签发后无法吊销，能回收的只有授权。

Java 25 加 Spring Boot 3.5 的微服务上 Kubernetes，我给自己定了一份运行时基线，覆盖镜像、探针、优雅停机、滚动与回滚、可观测性，每块都同时写现状和差距。

OpenFeature 加 flagd 的全链路场景下，一个前后端共享语义的新 flag 要灰度，先升级后端还是先升级前端？两条路径的风险对比下来，先让 backend 兼容、再升级 frontend 通常少踩一些坑。

对比 ArgoCD 两种应用组织方式，App-of-Apps 和 ApplicationSet，在三个真实项目里的实践。按场景（单人多集群异构、团队多环境同构、混合需求）给出取舍建议和决策框架。

压测时副本数在 3 和 5 之间反复抖动，查到是 ArgoCD selfHeal 在和 HPA 抢 spec.replicas。记录这次排查的证据链、修复方式，以及引出的几个扩缩容问题。