kubevela 是运行在 kubernetes 上的独立控制平面，非 go sdk，不通过 import 引入；go 微服务只需容器化合规、暴露端口、提供健康探针，并通过 yaml 声明交付，无需修改代码逻辑。
KubeVela 不是 SDK，也不是 Go 语言库，它不通过 import 引入到 Golang 微服务代码里。你无法、也不该在 Go 应用二进制中“引入”KubeVela。它的角色是平台层的交付控制器，不是应用层的依赖。
真正要做的，是让 Golang 微服务「适配」KubeVela 的交付模型，而不是把它“集成”进 Go 代码。
为什么不能 go get kubevela？
KubeVela 是一个运行在 Kubernetes 集群上的独立控制平面（Controller + API Server + Web UI），基于 CRD 扩展 Kubernetes。它没有 Go 客户端 SDK 提供给业务微服务调用；它的交互入口是 YAML 声明（Application 资源）和 CLI（vela 命令）。你的 Go 服务只需按标准容器化方式构建、打镜像、暴露端口、支持健康探针——这些就足够了。
如何让 Go 微服务被 KubeVela 正确交付？
关键不在 Go 代码改什么，而在交付声明怎么写。你需要提供一份符合 KubeVela 模型的 Application YAML，并确保 Go 服务满足基础运行契约：
- 镜像必须可拉取（私有 Registry 需配置
imagePullSecrets） -
Deployment中的spec.selector.matchLabels必须与template.metadata.labels严格一致，否则KubeVela渲染出的资源会报field is immutable - Go 服务需监听指定端口（如
8080），并在livenessProbe和readinessProbe路径返回200（例如/healthz） - 若要用
ingressTrait 暴露服务，Go 服务必须绑定0.0.0.0:8080，不能只绑127.0.0.1 - 若启用
rolloutTrait 做灰度，Go 服务需支持按 header 或 query 参数路由（KubeVela 不修改代码，只靠 Istio/Flagger 等底层能力实现）
常见错误：把 KubeVela 当成 client-go 用
有人试图在 Go 微服务里用 client-go 主动调用 KubeVela 的 API，这是典型误用。KubeVela 的 Application 是声明式资源，由平台工程师或 CI 流水线提交到集群，不是由业务 Pod 反向触发的。以下行为都属于踩坑：
- 在 Go 代码里执行
vela up -f app.yaml—— 这会破坏 GitOps 流程，且权限难以管控 - 用
rest.InClusterConfig()初始化 client-go 去 watchcore.oam.dev/v1alpha1 Application—— 业务 Pod 不该感知交付层抽象 - 在 main 函数里读取
KUBEVELA_ENV环境变量做差异化启动 —— KubeVela 不注入这类变量，它只管理 Pod 生命周期，不参与应用逻辑
真正需要你在 Go 侧做的三件事
不是写代码，而是准备交付上下文：
-
提供标准化镜像：Dockerfile 使用多阶段构建，最终镜像基于
gcr.io/distroless/static或alpine，以非 root 用户运行，暴露明确端口 -
定义清晰的健康端点：比如
GET /healthz返回 JSON{"status":"ok"}，并确保 probe 配置与之匹配（initialDelaySeconds: 10要留足启动时间） -
输出结构化日志：用
log/slog输出 JSON 格式日志（如slog.With("service", "user-api").Info("started")），便于 KubeVela 集成的 Loki 或 Prometheus 统一采集
KubeVela 负责“怎么把它跑好”。混淆这两层，就会陷入配置漂移、权限混乱、可观测性割裂的泥潭。最易被忽略的是——KubeVela 的 Workflow 步骤可以调用 Helm、Kustomize、甚至 Bash 脚本，但它从不侵入你的 Go 二进制。你写的每一行 Go 代码，都应该假设自己运行在裸 Kubernetes 上，而 KubeVela 只是帮你少写几份 YAML。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
