结论是：Go镜像必须用多阶段构建，第一阶段编译（golang:1.22-alpine），第二阶段运行（scratch或alpine），禁用CGO、静态编译、非root用户、监听0.0.0.0:8080，并严格配置imagePullSecrets、探针和资源限制，否则Kubernetes将报ImagePullBackOff或CrashLoopBackOff。
直接说结论：不是“打包再部署”，而是“构建镜像 → 推送到仓库 → 用 Deployment 拉取并运行”。中间漏掉任一环，ImagePullBackOff 或 CrashLoopBackOff 就会立刻出现。
怎么写 Dockerfile 才能生成安全、轻量、可部署的 Go 镜像
Go 编译产物是静态二进制，但很多人仍用 golang:alpine 直接跑，结果镜像里塞了 Go 工具链、apk 包管理器、甚至 shell——既不安全，又容易被误操作拉垮。
- 必须用多阶段构建：第一阶段用
golang:1.22-alpine编译，第二阶段切到scratch（或alpine:latest，仅当依赖 cgo 时） - 编译时加
CGO_ENABLED=0 GOOS=linux，否则二进制会动态链接 libc，scratch镜像直接报no such file or directory - 别写
go run main.go—— 那会把整个 Go 环境打进镜像；要go build -o main . - 运行时用非 root 用户：
USER 65532:65532（避免容器逃逸后提权） - 监听地址必须是
0.0.0.0:8080，不是127.0.0.1:8080；否则 Kubernetes Service 流量进不来
示例关键片段：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main . <p>FROM scratch COPY --from=builder /app/main /main EXPOSE 8080 USER 65532:65532 CMD ["/main"]
怎么推送到 Harbor 并让 Kubernetes 正确拉取
很多失败根本不是 YAML 写错了，而是 docker login 这一步没通。Kubernetes 不会帮你试连 Harbor，它只静默失败。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先在任意 K8s 节点执行：
docker login https://192.168.10.229（注意必须带https://，Harbor 默认强制 TLS） - 如果报
connection refused：检查 Harbor 服务是否运行、443 端口是否暴露、Ingress 是否配置正确 - 如果报
unauthorized：确认账号有目标项目的 “Pull” 权限（比如项目dtb里给admin开了读权限） - 成功后检查
~/.docker/config.json里是否有对应auths条目，且auth字段是 base64 编码的username:password - 创建 Secret 时必须指定类型：
--type=kubernetes.io/dockerconfigjson；漏掉这个，Pod 事件里只会显示Failed to pull image，不提示认证问题 - Secret 必须和 Pod 在同一 Namespace 下，除非你把它绑定到 ServiceAccount
推荐创建方式（避免密码泄露）：
cat ~/.docker/config.json | kubectl create secret generic harbor-cred \ --from-file=.dockerconfigjson=/dev/stdin \ --type=kubernetes.io/dockerconfigjson \ --namespace=default
Deployment YAML 里哪些字段不能少、不能错
Kubernetes 不认“Go 应用”这个词，它只认 YAML 里写的字段。少一个、错一个，Deployment 就卡住不动。
-
spec.selector.matchLabels和spec.template.metadata.labels必须完全一致，否则控制器找不到 Pod -
spec.template.spec.containers[].image地址要完整，比如192.168.10.229/dtb/go-app:1.0，不能漏端口或项目名 -
imagePullSecrets必须显式声明，且名字和上一步创建的 Secret 一致：- name: harbor-cred -
livenessProbe和readinessProbe的httpGet.path要和 Go 代码里暴露的健康端点一致（如/healthz），port必须等于containerPort -
resources.requests和limits必填，否则调度器无法分配节点；尤其在资源紧张集群里，缺这个 Pod 会一直 Pending
最小可用片段示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-app
spec:
replicas: 2
selector:
matchLabels:
app: go-app
template:
metadata:
labels:
app: go-app
spec:
containers:
- name: app
image: 192.168.10.229/dtb/go-app:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
readinessProbe:
httpGet:
path: /readyz
port: 8080
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
imagePullSecrets:
- name: harbor-cred为什么 Pod 一直 ContainerCreating 或 CrashLoopBackOff
这两个状态背后，90% 是基础链路断了，而不是代码逻辑问题。
-
ContainerCreating：大概率是imagePullSecrets名字写错、Secret 不在同 namespace、或 Harbor 凭据失效；用kubectl describe pod <name>看 Events 最靠前那条 -
CrashLoopBackOff：先看日志：kubectl logs <pod-name> --previous；常见原因是 Go 服务监听了127.0.0.1:8080、健康端点没注册、或启动时 panic（比如 DB 连接字符串为空） - 探针失败却不报错？检查
containerPort和probe.port是否一致；Kubernetes 不会自动映射端口，它严格按数字匹配 - 用
scratch镜像时出错？大概率忘了CGO_ENABLED=0，导致二进制依赖动态库；改用alpine并apk add ca-certificates临时验证
最易被忽略的一点：Go 服务启动日志里没打 server started on :8080 类似语句。没有这行，你根本分不清是镜像没跑起来，还是跑起来了但探针还没就绪。
