keptn 是独立部署在 kubernetes 上的事件驱动控制平面，不嵌入 go 微服务代码；go 服务需暴露 /metrics 端点、响应 keptn 事件、兼容 helm 注入约定，并在真实 k8s 环境中验证全流程。
Keptn 不是 Go 微服务的运行时依赖，也不是 SDK 或库，它不嵌入到你的 main.go 里；它是独立部署在 Kubernetes 上的事件驱动控制平面，负责接管交付流程的决策与编排。想让 Go 微服务“用上”Keptn，关键在于：让 Keptn 能触发、观察、验证你的服务，而不是让 Go 代码去调 Keptn 的 API。
Go 微服务必须暴露 SLO 验证所需的指标端点
Keptn 的 SLO 验证能力（比如 keptn configure monitoring 后自动拉取指标）依赖 Prometheus 指标暴露。如果你的 Go 服务没暴露 /metrics，Keptn 就无法评估质量门禁是否通过。
- 用
promhttp.Handler()暴露标准 Prometheus 格式指标，路径必须是/metrics（Keptn 默认扫描该路径） - 至少提供
http_request_duration_seconds_bucket和http_requests_total这类基础指标——Keptn 的dynatrace-sli-service或prometheus-sli-service会基于它们计算错误率、延迟 P95 等 SLO 指标 - 避免在
/metrics中暴露敏感信息（如用户 ID、token），Prometheus 抓取是未认证的 HTTP 请求
Keptn Sequence 必须能触发 Go 服务的部署与验证任务
Keptn 不直接构建或推送镜像，它通过事件（如 sh.keptn.event.deployment.triggered）驱动下游工具链。你的 Go 微服务 CI/CD 流水线要响应这些事件，而不是反过来。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在 GitOps 场景中，Keptn 的
shipyard-controller发出deployment.triggered事件后，应由 Argo CD 或 Helm Operator 去更新 Helm Release 的image.tag字段，触发 K8s Deployment 更新 - 验证阶段（
evaluation.triggered）需确保 Go 服务已就绪：检查readinessProbe是否通过，且/healthz返回 200；Keptn 不会等你手写健康检查逻辑，它只信任 K8s 的探针状态 - 若使用自定义验证（比如调用
evaluator工具），需保证该工具能访问 Go 服务的公开 endpoint（如http://user-svc.staging.svc.cluster.local:8080/healthz），DNS 解析必须在集群内可达
Go 服务的 Helm Chart 必须兼容 Keptn 的命名与注入约定
Keptn 在执行 helm upgrade 时，会向 Chart 注入特定值（如 service.name, namespace, stage）。如果 Chart 的 values.yaml 或模板没预留这些字段，部署会失败或参数错乱。
- Helm Chart 的
templates/deployment.yaml中，容器镜像应写成{{ .Values.image.repository }}:{{ .Values.image.tag }}，而非硬编码my-registry/user-service:v1.2.3 - 必须支持
--set=service.name=user-svc这类动态注入，否则 Keptn 的多环境（staging/prod）无法复用同一 Chart - ConfigMap / Secret 引用需使用
{{ .Values.config.env }}等模板变量，避免把 staging 和 prod 的配置混在一起
本地开发时，Keptn CLI 无法替代真实 K8s 环境验证
keptn send event 命令在本地执行时，只是模拟发事件，不会真正触发部署或验证。很多团队误以为跑通 CLI 就等于 Keptn 集成完成，结果上线后 Sequence 卡在 waiting for deployment。
- 务必在真实 K3s/K3d 集群中验证整个 Sequence：从
keptn trigger delivery开始，观察keptn get events输出的事件流是否完整 - 检查
keptn get service和keptn get project是否返回预期结构——项目名、stage 名、service 名必须与 Helm Chart 中定义的完全一致（大小写、连字符敏感） - Keptn 的
bridgeUI 是唯一能直观看到 Sequence 卡在哪一步的工具；单纯看 Pod 日志或kubectl get po -n keptn无法定位事件丢失或配置不匹配问题
最容易被忽略的是：Keptn 的事件模型要求每个阶段（staging → production）都对应一个独立的 K8s namespace，而 Go 服务的 Helm Chart 必须接受 namespace 作为输入参数——不是靠 helm install -n 硬指定，而是 Chart 内部用 {{ .Release.Namespace }} 动态渲染资源元数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
