golang微服务本身不提供集群能力，所谓“集群部署”是工程层面的组合策略，必须依赖kubernetes等容器编排系统，并满足健康检查、服务发现、副本调度和配置隔离等硬性契约。
Golang 微服务本身不提供集群能力，所谓“集群部署”是工程组合动作，不是写几行 go run 就能成的事。真正落地的集群，必须依赖容器编排系统（主要是 Kubernetes），并满足健康检查、服务发现、副本调度、配置隔离等硬性契约。
为什么直接起多个进程不算集群
常见错误现象：本地用 nohup ./app & 启 3 个实例，以为这就是高可用——结果一个节点宕机，整个服务就挂了；或者没做健康探针，Kubernetes 把流量发给已卡死但进程还在的 Pod。
- 缺少自动剔除机制：没有
livenessProbe和readinessProbe，K8s 不知道哪个实例还能收请求 - 无服务发现：实例 IP 变动后，调用方无法动态更新地址，硬编码或 DNS 缓存会导致 5xx
- 无状态协同缺失：比如分布式锁、会话共享、配置热更新，全靠自己手撸，极易出错
- 资源争抢未约束：没设
resources.requests/limits，多个 Pod 在同一节点上互相挤占 CPU 内存
Kubernetes Deployment 必须配的四项
Deployment 是 Golang 微服务在 K8s 里真正跑起来的最小可靠单元。只写 replicas: 3 远不够，以下四点漏一不可：
-
livenessProbe和readinessProbe必须指向真实 HTTP 接口（如/health），且initialDelaySeconds要大于服务冷启动时间（Golang 二进制通常 1–2 秒，别设成 5） -
podAntiAffinity规则必须启用，否则 K8s 可能把 3 个 Pod 全调度到同一台 Node 上，单机故障即全挂 -
resources.requests要填准：Golang 服务常驻内存一般 20–50MB，CPU request 设100m足够，过大会导致调度失败 -
terminationGracePeriodSeconds: 30必须显式设，配合 Golang 的优雅关闭逻辑（监听SIGTERM，处理完当前请求再退出）
Redis Cluster 连接不能用 redis.NewClient()
很多团队上线后突然大量报 redis: MOVED 12345 10.0.1.5:6379 或直接 connection refused，根本原因是误用单节点客户端连集群。
-
redis.NewClient()是单节点模式，完全不识别 Redis Cluster 的 slot 分片规则，也不处理MOVED/ASK重定向 - 必须改用
redis.NewClusterClient()，Addrs至少填一个在线节点（如[]string{"redis-cluster:6379"}），它会自动执行CLUSTER SLOTS拉取拓扑 - 别在
NewClusterClient()里传空Addrs或只传已下线节点，首次建连失败会导致整个服务启动卡住 - 连接池参数（
PoolSize、MinIdleConns）要按实际 QPS 调整，Golang 微服务常见值是PoolSize: 20，不是越大越好
多集群管理时 rest.Config 必须隔离
当你用 Golang 写控制器同步东西南北四个集群，却只加载一次 kubeconfig，所有操作都会打到同一个集群——因为 rest.Config 复用等于 token、CA、Host 全复用。
- 每个集群必须独立调用
clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")，不能共用返回的*rest.Config - 手动构造
rest.Config时，TLSClientConfig.CAData是 base64 编码后的字节，别忘了base64.StdEncoding.DecodeString() - 每个
rest.Config必须单独设QPS和Burst（建议QPS: 3,Burst: 6），避免打爆边缘集群 API Server -
http.Transport也得隔离：至少设不同MaxIdleConnsPerHost，否则 TLS 连接复用混乱，偶发超时或证书错乱
最易被忽略的其实是健康接口的响应速度——/health 必须在 1 秒内返回 200，里面不能查 DB、不能调下游、不能读大文件。K8s 的 probe 默认 timeout 是 1 秒，超时即判定为失败，反复重启。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
