goctl kube deploy生成可上线YAML需满足三前提：项目结构合规（含etc/与cmd/目录）、etc/下有定义name的服务配置文件、goctl版本≥1.6；生成后须手动修改镜像、探针路径、命名空间及端口等关键字段。
能直接用 goctl kube deploy 生成可上线的 YAML，但必须满足三个硬性前提：项目结构合规、配置文件存在、goctl 版本 ≥ 1.6。
goctl kube deploy 命令生成 YAML 的前提条件
这个命令不是“一键部署”，而是“一键生成符合 go-zero 规范的 YAML”。它不会检查你的代码是否真能跑起来，只校验目录和配置是否存在。
- 项目根目录下必须有
etc/目录，且其中至少一个 YAML 文件（如user-api.yaml）定义了name字段（即服务名） - 必须有
cmd/或internal/等标准目录结构；goctl会按约定扫描api和rpc子目录来推断服务类型 -
goctl版本必须 ≥ 1.6 —— 旧版本不支持HPA、livenessProbe默认路径等关键字段，执行时静默忽略 - 当前 shell 要在项目根目录下运行，否则
goctl找不到etc/，报错cannot find etc directory
生成的 YAML 里哪些字段必须手动改
生成内容很全，但默认值不能直接上生产。镜像名、健康探针路径、命名空间这几项不改，部署后大概率卡在 ContainerCreating 或反复重启。
-
image字段默认是your-repo/{name}:latest—— 必须替换成你 CI 流水线打的带 Git SHA 的 tag，比如harbor.example.com/gozero/user-api:20260920-abc123；否则 K8s 认为镜像没变，跳过拉取 -
livenessProbe和readinessProbe默认都指向/healthz，但 go-zero 项目默认只注册了/healthz（liveness），没注册/readyz（readiness）。如果要用 readiness，得在main.go里显式加engine.GET("/readyz", func...)并做真实依赖检查 -
namespace默认是default，生产环境必须指定实际命名空间，比如prod或staging，否则资源混在一起，权限和网络策略全失效 -
ports.containerPort默认是80，而 go-zero 生成的 HTTP 服务默认监听8888—— 不匹配会导致 Service 流量进不来，Pod 日志里看不到任何请求
Deployment 的 selector 和 template labels 必须完全一致
这是 Kubernetes 的强制校验点，不是建议。哪怕只是大小写或空格差异，kubectl apply 就会失败，提示 invalid label selector 或 field is immutable，后续所有更新都会被阻塞。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
立即学习“go语言免费学习笔记（深入）”；
- 检查生成的 YAML 中
spec.selector.matchLabels和spec.template.metadata.labels两个块的内容是否逐字相同 - 常见错误：
app: user-apivsapp: UserApi，或version: v1vsversion: "v1"（YAML 中字符串加引号不影响值，但某些旧版 kubectl 会误判） - 如果用 CI 自动化生成，建议在
goctl命令后加| sed -i 's/app: \(.*\)/app: \L\1/g'统一小写，避免人工拼写误差
etcd 服务注册必须配 Lease，否则节点宕机后地址残留
go-zero 默认用 etcd 做服务发现，但生成的代码不带租约逻辑。如果不改，进程崩溃后 etcd 里还挂着那个 key，客户端持续发请求到已死 IP，表现为“服务看起来在线，但调用全超时”。
- 注册时必须调用
client.Grant(ctx, 10)创建 10 秒租约，并把租约 ID 传给Put()的WithLease() - 退出前要显式调用
client.Revoke(ctx, leaseID)，或者启动一个 goroutine 监听leaseResp.Done实现自动续租 - 别用轮询心跳模拟保活——etcd Lease 是原子性机制，心跳失败就会立即释放 key，比应用层自己维护可靠得多
- 租约 TTL 设 15 秒比较平衡：太短（如 5 秒）导致频繁 Grant/KeepAlive，压 etcd；太长（如 60 秒）故障发现延迟太高
最常被忽略的是 readiness 探针和 etcd 租约这两处：前者让流量打到还没初始化完的实例上，后者让故障节点长期“假在线”。生成 YAML 只是第一步，这两处不补，上线后问题一定出在最不好排查的地方。
