Go HTTP服务器必须显式配置ReadTimeout、WriteTimeout和IdleTimeout三类超时，因http.ListenAndServe默认无超时，易致连接堆积、资源耗尽及K8s探针误判重启；示例：ReadTimeout≤5s、WriteTimeout≤30s、IdleTimeout设60–120s。
Go HTTP服务器必须显式设置 http.Server 超时参数
默认的 http.ListenAndServe 不设超时，会导致连接堆积、资源耗尽，尤其在高并发压测或网络抖动时容易触发 Kubernetes 的 LivenessProbe 失败并反复重启 Pod。
正确做法是用完整 http.Server 实例，并显式配置三类超时：
-
ReadTimeout：限制请求头读取时间（建议 ≤ 5s） -
WriteTimeout：限制响应写入时间（建议 ≤ 30s，需匹配业务最长处理路径） -
IdleTimeout：限制 keep-alive 连接空闲时间（建议 60–120s，防连接长期滞留）
示例片段：
server := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second,
WriteTimeout: 30 * time.Second,
IdleTimeout: 90 * time.Second,
}
Deployment 中的 resources 和 livenessProbe 必须匹配 Goroutine 并发模型
Go 高并发依赖大量轻量级 Goroutine，但 Kubernetes 的 livenessProbe 默认使用 HTTP 请求，若探测路径调用阻塞型逻辑（如未加 context 控制的 DB 查询），会卡住整个 probe 线程，导致误杀。
立即学习“go语言免费学习笔记（深入）”；
更关键的是资源限制：内存限制过低会触发 Go runtime 的 GC 频繁回收，CPU 限制过低则调度器无法及时抢占，反而加剧 Goroutine 积压。推荐值：
- 生产环境
requests.cpu≥500m，limits.memory≥512Mi（参考实际 p95 内存占用 ×1.5） -
livenessProbe使用独立健康端点（如/healthz），仅检查进程存活和监听状态，不查 DB 或外部依赖 -
readinessProbe可稍严格（如加 DB 连通性），但超时时间必须 >livenessProbe，且initialDelaySeconds给足启动缓冲（≥ 10s）
镜像构建阶段必须禁用 CGO 并剥离调试信息
CGO 启用时，Go 二进制会动态链接 libc，导致 Alpine 镜像运行时报 no such file or directory；未剥离符号表的二进制体积大、启动慢，影响滚动更新速度和节点磁盘压力。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
多阶段构建中务必加入编译标志：
-
CGO_ENABLED=0：强制静态链接 -
GOOS=linux：确保目标平台一致 -
-ldflags="-s -w"：移除符号表和调试信息
构建命令示例：
go build -a -ldflags="-s -w" -o main ./cmd/api
HorizontalPodAutoscaler 触发指标不能只看 CPU
Go 服务 CPU 使用率可能长期偏低（因 Goroutine 大量休眠），但实际请求积压严重；反过来，短时 GC 尖峰也可能拉高 CPU，引发误扩容。
真正反映服务能力的指标是：
- 自定义 Prometheus 指标：
http_request_duration_seconds_bucket{le="0.3"}（p90 响应时间 ≤ 300ms） - 就绪探针失败率：
kube_pod_status_phase{phase="Running"} == 0关联 readiness probe failure event - 主动暴露
go_goroutines和go_memstats_alloc_bytes，设阈值告警而非直接用于 HPA
HPA 推荐优先基于 custom.metrics.k8s.io 的请求延迟或成功率做伸缩，比 CPU 更贴近业务水位。
最易被忽略的一点：Go 服务在 Kubernetes 中的“高并发”不是靠堆线程数，而是靠减少阻塞、缩短单请求生命周期、以及让 readiness 探针真实反映服务可服务状态——否则再多副本也只会把流量导给不可用实例。
