Kubernetes中readinessProbe必须探测下游依赖而非仅进程存活，否则Pod虽Running却返回500，流量仍被转发；应与服务注册协同，通过initialDelaySeconds和重试机制规避时序问题。
服务注册与发现必须用强一致性存储
etcd 是目前最稳妥的选择，Consul 也可以，但要注意它的默认一致性模式是最终一致——在节点故障或网络分区时，服务列表可能短暂过期。Kubernetes 原生集成 etcd，如果你的微服务跑在 K8s 上，直接复用集群 etcd 就够用，不用额外部署。
- 注册时必须带
Check字段，且HTTP检查路径要真实返回 200，不能只写/health却没实现逻辑 - 避免使用 DNS-based 发现（如 Kubernetes Service DNS），它不感知实例健康状态，故障 Pod 还会被轮询到
- etcd key 路径建议按命名空间组织，例如
/services/user-service/instances/192.168.1.10:8080，方便 ACL 和 watch
Kubernetes 中的 readinessProbe 不能只依赖 HTTP 状态码
很多团队把 readinessProbe 写成简单 GET /health，但这个接口如果只检查自身进程存活，就无法反映下游依赖（比如数据库连不上、Redis 超时）是否就绪。Pod 可能已 Running，却持续返回 500，流量照常打进来。
-
readinessProbe的 handler 必须做依赖探测：连接 DB、ping Redis、校验配置加载结果 - 超时时间（
timeoutSeconds）建议设为 2–3 秒，太长会导致 K8s 等待过久，影响滚动更新速度 - 失败阈值（
failureThreshold）设为 2 或 3，避免因瞬时抖动误判 - 不要和
livenessProbe共用同一个 endpoint——liveness 失败会触发重启，而 readiness 失败只是摘流
持久化存储必须区分工作负载类型
在超融合平台（如 vSAN 或 Nutanix AHV）上，不是所有 PVC 都该用同一个 StorageClass。数据库类服务对 IOPS 敏感，日志或缓存类则更看重吞吐和容量。
- 关键有状态服务（PostgreSQL、etcd）应绑定专用
StorageClass，启用ioPriority或 vSAN 的 “Object Space Reservation” - Go 应用自身的临时文件（如上传缓存、生成报告）用
emptyDir或本地 hostPath，别走网络存储 - PVC 的
accessModes别乱设：ReadWriteOnce是大多数无状态 Go 服务的合理选择；ReadWriteMany仅在极少数共享文件场景才需要，性能损耗大
网络策略要从“默认拒绝”起步
超融合环境里，物理网络隔离弱，虚拟网络又默认互通。不设 NetworkPolicy，一个被攻破的 Pod 就可能横向扫遍整个命名空间。
立即学习“go语言免费学习笔记（深入）”；
- 每个微服务 Deployment 部署时，同步配一条最小权限
NetworkPolicy：只允许 API 网关访问其端口，只允许它访问指定 DB Service - 避免用
podSelector: {}宽泛匹配，明确写matchLabels，比如app: user-service - 如果用了 Istio，
Sidecar默认拦截所有 outbound 流量，记得在DestinationRule里显式放行 etcd 或 Consul 地址，否则服务注册会失败
initialDelaySeconds）和注册逻辑里的重试兜底。 
