Deployment replicas设为大于1即可启动多实例，Kubernetes通过调度器在不同节点创建独立Pod副本，每个Pod运行一个Go进程；需确保Service selector与Pod标签严格匹配、Go监听0.0.0.0而非localhost，并配置resources.requests以保障调度成功。
Deployment replicas 设置为大于 1 的值即可启动多实例
Kubernetes 本身不区分“单实例”或“多实例”，只认 replicas 字段。只要 Deployment 中 replicas: 3，控制器就会确保集群中始终运行 3 个 Pod 副本——每个 Pod 里跑一个 Go 进程。这不是“复制进程”，而是由 Kubernetes 调度器在不同节点（或同一节点，取决于资源和亲和性）上创建独立容器实例。
常见错误是误以为改了代码里的 goroutine 数量就能横向扩容——那只是单 Pod 内的并发，跟实例数无关。
-
replicas建议设为 2 或以上，避免单点故障；设为 1 时任何节点宕机都会导致服务中断 - 若 Pod 频繁重启，
replicas不会自动补偿——需先解决 CrashLoopBackOff 根因（如端口冲突、健康检查失败） - 滚动更新期间，Kubernetes 默认保证至少
minReadySeconds+maxSurge/maxUnavailable约束下的可用副本数，不是简单“删旧建新”
Go 应用必须监听所有网络接口（0.0.0.0），不能只绑 localhost
每个 Pod 有独立 IP 和网络命名空间。如果 Go 代码写成 http.ListenAndServe("localhost:8080", nil)，容器内虽然能通，但 Service 流量无法转发进来——因为 localhost 在 Pod 内只指向自身，外部流量进不来。
正确写法是显式绑定到 ":8080" 或 "0.0.0.0:8080"：
http.ListenAndServe(":8080", nil)否则你会看到 Service 可以访问，但 Endpoint 始终为空，kubectl get endpoints go-app-service 返回 <none>。
- 某些 Go Web 框架（如 Gin）默认行为就是
":8080"，但自定义 server 实例时容易漏掉 - 若使用
net/http.Server，务必检查Addr字段是否为":8080"，而非"127.0.0.1:8080" - 本地调试时用
localhost没问题，但提交前必须改掉
Service 的 selector 必须精确匹配 Pod labels
Service 通过 selector 字段把流量路由到对应 Pod。如果 Deployment 模板里写了 labels: {app: go-app}，但 Service 的 selector 写成 app: my-go-app，那所有 Pod 都不会被纳入 Endpoint。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
典型配置对齐方式：
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-app
spec:
selector:
matchLabels:
app: go-app # ← 这个值要和下面 template.labels 一致
template:
metadata:
labels:
app: go-app # ← 必须完全相同
spec:
containers:
- name: go-app
image: your-registry/go-app:v1.2Service 中：
apiVersion: v1
kind: Service
metadata:
name: go-app-service
spec:
selector:
app: go-app # ← 必须和上面 labels 完全一致- 大小写敏感，
App: go-app和app: go-app是两个不同 label - Deployment 更新后新增的 Pod 如果 label 不匹配，也不会被 Service 收录
- 用
kubectl describe service go-app-service查看 Events 和 Endpoint 地址，是最直接的验证方式
资源限制（resources）没配好会导致多实例调度失败
不设 resources.requests，Kubernetes 调度器无法判断节点是否有足够 CPU / 内存容纳新 Pod，可能把多个实例全塞到一个节点上，也可能因资源不足一直 Pending。
尤其 Go 应用内存占用波动大（GC 周期、连接数上升），只设 limits 不设 requests 会让调度器“瞎猜”，后果是部分 Pod 启动不了，或者被 OOMKilled。
- 最小实践：至少配置
requests.memory和requests.cpu，值参考本地压测结果（如 128Mi + 100m） -
limits.memory建议设为 requests 的 1.5–2 倍，给 GC 和突发流量留余量 - 若用
autoscaling/v2做 HPA，requests是指标计算基准，不设就无法触发扩缩容
多实例真正生效的关键不在“怎么写 Deployment”，而在于确认每个 Pod 真的被 Service 发现、能被流量打中、且不会因资源争抢互相挤占。三者缺一不可——尤其是 selector 匹配和 0.0.0.0 绑定，最容易在线上静默失效。
