Go微服务部署K8s前须改造：实现http.Server.Shutdown()支持优雅退出；健康/就绪探针端点独立且返回200；配置从环境变量读取；日志输出到stdout/stderr。
微服务部署到Kubernetes前必须做哪些Go应用改造
Go微服务本身不依赖Kubernetes，但要真正适配K8s编排，得在代码和构建层面主动配合。否则会遇到就绪探针失败、优雅下线超时、日志无法采集等问题。
-
http.Server必须支持Shutdown()方法，在接收到SIGTERM时完成正在处理的请求再退出 - 健康检查端点（如
/healthz）需独立于主业务路由，避免中间件干扰，且响应必须是纯文本或简单JSON，状态码严格用200表示健康 - 所有配置（数据库地址、超时时间等）不能硬编码，优先从环境变量读取，例如用
os.Getenv("DB_HOST")，而非配置文件嵌套加载 - 日志必须输出到
stdout/stderr，禁用文件写入；推荐用log/slog或zap并设置Output: os.Stdout
如何编写最小可行的Kubernetes Deployment YAML
很多团队一上来就堆叠 initContainers、affinity、topologySpreadConstraints，结果连Pod都起不来。先跑通最简Deployment，再逐步加特性。
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-service
spec:
replicas: 2
selector:
matchLabels:
app: user-service
template:
metadata:
labels:
app: user-service
spec:
containers:
- name: app
image: registry.example.com/user-service:v1.2.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "200m"注意：livenessProbe.initialDelaySeconds 要大于应用冷启动耗时（比如Gin+DB连接池初始化），否则K8s会反复重启；readinessProbe 的 initialDelaySeconds 可设小些，让流量晚点进来但别卡太久。
Service与Ingress如何匹配Go微服务的HTTP路由设计
Kubernetes Service 只做四层转发（IP+端口），而Go微服务内部常有 /api/v1/users 这类路径路由。二者不重叠，但容易误配。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
立即学习“go语言免费学习笔记（深入）”；
-
Service类型选ClusterIP（默认），除非需要外部直接访问；跨服务调用统一走http://user-service:8080/api/...，DNS名即Deployment名 - 若需对外暴露
/api前缀，不要在Go代码里写死router.Group("/api")后再配Ingress去掉前缀——这会让本地调试和K8s环境行为不一致；建议Go保持根路由，由Ingress的path和nginx.ingress.kubernetes.io/rewrite-target处理路径映射 - 多个微服务共用一个Ingress时，确保
host或path不冲突；例如user.example.com和order.example.com分开，比都用*+ 不同path更可靠
为什么Go微服务在K8s里经常出现“CrashLoopBackOff”
这不是Go的问题，而是K8s对进程生命周期的强约束和Go默认行为之间的错位。最常见三个原因：
- 应用启动后立即退出：没启动HTTP服务器，或
http.ListenAndServe()被包裹在 goroutine 里但主goroutine结束，导致进程退出 → 必须用select {}或sync.WaitGroup阻塞主goroutine - 就绪探针返回非200：比如
/readyz检查了Redis连接，但Redis还没就绪，K8s就把Pod从Endpoint摘除，形成死循环 → 就绪检查只应包含本服务可控的依赖（如本地缓存、内存队列），避免级联等待 - 资源限制过紧：Go程序启动时GC堆预分配、TLS握手缓冲区等会瞬时冲高内存；设
limits.memory: "64Mi"很可能OOMKilled → 实测压测峰值后再设limit，request可略低，但limit至少留30%余量
查问题第一反应不是改Go代码，而是先看 kubectl describe pod <name> 里的 Events 和 kubectl logs <pod> --previous，90%的CrashLoopBackOff根源都在这两处。
