最小可用Go应用需Deployment（replicas≥2、containerPort与targetPort一致、resources.requests）+Service（selector匹配、PORT环境变量可配置）+NetworkPolicy（ingress/egress双白名单、精确podSelector、依赖拓扑驱动规则）。
直接部署 Go 应用到 Kubernetes 并配网络策略，关键不是“能不能”，而是“不配就暴露”——默认所有 Pod 之间可互通，NetworkPolicy 一没加，横向扫描、误调用、服务越权都可能发生。
怎么写一个最小可用的 Go Deployment + Service
Deployment 负责跑起来，Service 负责让其他服务能访问它。别跳过 selector 和 targetPort 的匹配，这是最常见的 503 错误源头。
-
replicas建议从 2 起步，单副本下readinessProbe失败会导致整个服务不可用，没冗余容错 -
containerPort是容器内监听端口（比如 Go 里http.ListenAndServe(":8080")），targetPort必须和它一致，否则 Service 转发失败 - 环境变量如
PORT要在 Go 代码里主动读取，不能只写死:8080；否则换端口时要改代码+重建镜像 - 务必加
resources.requests，否则 Kubernetes 调度器可能把多个高内存应用塞进同一节点，触发 OOMKilled
为什么 NetworkPolicy 一加就断连
因为 NetworkPolicy 默认是“拒绝所有”，你写的每一条规则都是白名单，漏一条，连不上就是正常行为。最常踩的坑是：只写了入向（ingress），忘了出向（egress）也需要放行 DNS 和健康检查探针目标。
- Pod 要解析域名（比如连数据库、调第三方 API），必须允许 egress 到
53/udp和53/tcp - 如果用了
livenessProbe或readinessProbe指向集群内其他服务（比如 /health 检查依赖 Redis），得在ingress里放开对应 Service 的 ClusterIP 网段或标签选择器 - 不要用
podSelector: {}开放全部 Pod，应精确到matchLabels: {app: go-app}，否则后续加新服务容易被误放行 - Kubernetes 1.24+ 默认不启用
NetworkPolicy插件，确认你的 CNI（如 Calico、Cilium）已安装且配置正确，kubectl get networkpolicy有返回不代表生效
Go 应用自身要配合网络策略做什么
网络策略管的是 Pod 间流量，但 Go 代码得配合才能让策略真正起效。比如探针路径返回 200 不代表服务就绪——如果它没等 DB 连上就返回 OK，NetworkPolicy 放行后流量进来，立马 500。
-
/ready探针必须检查所有强依赖（DB、Redis、下游关键 API），而不仅是进程存活；否则NetworkPolicy放行后，请求打进来却卡死在依赖上 -
/healthz可以轻量，只检查自身 goroutine 和内存是否异常，但别让它依赖外部服务，否则探针超时会反复重启 Pod - Go 启动时若监听
0.0.0.0:8080是必须的，监听127.0.0.1会导致 Service 无法转发，和 NetworkPolicy 无关，但常被一起排查 - 日志里别打明文密钥或 token，NetworkPolicy 防不住应用层泄露；Secret 挂载后，Go 代码要用
os.ReadFile("/secret/token")而非硬编码
NetworkPolicy 的复杂点不在语法，而在依赖拓扑——你得画出 Go 服务实际要连哪些外部系统、被哪些服务调用，再逐条转成规则。少写一条，要么服务不可用，要么策略形同虚设。
