go服务需通过downward api或节点标签获取az信息，最可靠方式是用node_name查api server获取topology.kubernetes.io/zone标签；跨az调度应配置topologyspreadconstraints并设maxskew:1和whenunsatisfiable:donotschedule；客户端需控制连接生命周期、启用幂等重试；健康探针应只检查本体状态，避免跨az依赖导致误杀。
Go 服务如何感知自己运行在哪个可用区
Kubernetes 不会自动把 AZ（Availability Zone）信息注入 Go 进程，得靠自己从 Downward API 或节点标签里拿。最可靠的方式是读取 os.Getenv("NODE_NAME")，再用 client-go 调 /api/v1/nodes/{name} 拿 topology.kubernetes.io/zone 标签。
常见错误是直接解析 /proc/mounts 或查云厂商元数据接口——前者在容器里不可靠，后者要额外权限且跨云不一致。
- 必须给 Pod 绑定
ServiceAccount，并授予nodes/get权限 - 别用硬编码的 APIServer 地址，走
https://kubernetes.default.svc+ 自动挂载的 token - 缓存节点信息，避免每次请求都查 API；AZ 一般不会变，按小时级刷新足够
K8s 中设置 topologySpreadConstraints 强制跨 AZ 分散 Pod
这是目前最主流、原生支持的跨 AZ 调度方式，比 nodeAffinity + labelSelector 更可控。关键不是“调度到某 AZ”，而是“尽量让副本均匀落在不同 AZ”。
容易踩的坑是只写 topologyKey: topology.kubernetes.io/zone 却漏掉 whenUnsatisfiable: DoNotSchedule —— 默认值是 ScheduleAnyway，等于没约束。
立即学习“go语言免费学习笔记（深入）”；
- 必须配合
maxSkew: 1和topologyKey: topology.kubernetes.io/zone - 如果集群只有 2 个 AZ，但 Deployment 副本数设为 5，
maxSkew: 1会导致调度失败（无法满足“最多差 1 个”） - StatefulSet 场景下，建议加
podTopologySpreadConstraint同时配podAntiAffinity双保险
Go 客户端连接其他 AZ 的服务时如何避免单点故障
跨 AZ 调用本身不丢包，但延迟高、网络抖动多。Go 默认的 http.Client 会复用连接，一旦某个 AZ 的 endpoint 失效，连接池里的旧连接可能持续超时。
核心是控制连接生命周期和失败转移逻辑，而不是依赖 DNS 轮询或 Service ClusterIP 的透明转发。
- 设置
http.Transport.MaxIdleConnsPerHost = 100，但更关键的是IdleConnTimeout: 30 * time.Second，强制淘汰老连接 - 对跨 AZ 请求启用重试：用
retryablehttp库或自己封装，仅重试幂等方法（GET/HEAD），且限制总耗时 ≤ 2× 单次 timeout - 不要把所有 AZ 的 endpoint 写死在配置里；通过 Kubernetes Endpoints 或自定义 CRD 动态发现，配合 informer 监听变更
健康检查探针怎么写才不误杀跨 AZ 的 Pod
Liveness 探针如果调用同集群内另一个 AZ 的依赖服务，失败就重启 Pod，反而放大故障面。真正的健康检查应该只反映本 Pod 自身状态，而非远端依赖。
很多人把 readiness 探针写成 “能连上数据库就 ready”，结果数据库跨 AZ 网络抖动，整组 Pod 集体 not ready，流量全切走，形成雪崩。
- Liveness 探针只检查本地进程是否存活（如
/healthz返回 200，不连外部服务） - Readiness 探针可检查本地依赖（如本地 cache 是否 warm、gRPC server 是否监听），但避免跨 AZ HTTP 调用
- 对真正需要验证的跨 AZ 依赖，改用单独的指标（如 Prometheus 抓取
up{job="cross-az-db"}）做告警，而非探针驱逐
跨 AZ 的高可用不是靠“调度平均”或“连得上”实现的，而是靠每个环节明确区分“自身健康”和“依赖可用”——这点在 Go 里特别容易被忽略，因为 net/http 的默认行为太“顺滑”了。
