Kratos 服务需暴露0.0.0.0监听地址、提供/healthz健康接口、支持环境变量驱动配置，Helm通过ConfigMap挂载config.yaml、Secret管理敏感信息，并依赖resources、probe、port等字段正确配置以保障正常部署与探活。
Kratos 本身不内置 Helm 支持，但它的标准项目结构和可配置性天然适配 Helm 编排——关键在于把 Kratos 服务当作普通 Go Web/gRPC 服务来打包，而不是试图让 Kratos “理解” Helm。
kratos 服务怎么写才能被 Helm 正确部署
Kratos 服务必须暴露明确的监听地址、健康检查端点，并支持环境变量或配置文件驱动行为。Helm 不关心你用的是 Kratos 还是 Gin，只关心它能否启动、探活、扩缩容。
-
main.go中需显式绑定0.0.0.0:9000（而非127.0.0.1:9000），否则 Pod 内部无法被 Service 访问 - HTTP 服务必须提供
/healthz或类似路径的 GET 接口，供 Helm 的livenessProbe和readinessProbe使用 - gRPC 服务若需被 Istio 等网格识别，应在
values.yaml中显式开启appProtocol: grpc字段（Kubernetes v1.20+） - 所有配置项（如数据库地址、Redis 地址）应通过
config.Load加载，且优先级顺序为：环境变量 >values.yaml注入的 ConfigMap > 默认值
helm chart 模板里哪些字段 Kratos 特别依赖
Kratos 服务对资源限制、启动参数、探针配置敏感，模板中这几处写错会导致 CrashLoopBackOff 或就绪失败。
-
resources建议设下限：requests.cpu: 100m、requests.memory: 128Mi；Kratos 启动时加载 gRPC 反射、中间件等会短暂吃内存，太低容易 OOMKilled -
env中必须传入KRATOS_ENV（如prod），Kratos 的config.New会据此加载对应环境的config.yaml -
readinessProbe.httpGet.path若指向 gRPC 服务，需配合grpc-health-probe工具（不能直接用httpGet）；推荐统一走 HTTP 健康接口，避免额外 initContainer -
service.port和deployment.container.ports.containerPort必须一致，Kratos 默认 gRPC 是9000、HTTP 是8000，改了就得同步更新
values.yaml 怎么组织才方便多环境切换
不要把开发/测试/生产配置全堆在同一个 values.yaml 里。Kratos 项目通常自带 configs/ 目录，Helm 应只负责注入顶层开关，具体配置由 ConfigMap 挂载。
- 在
templates/configmap.yaml中用{{ .Values.config }}渲染整个config.yaml内容，而不是拆成几十个.Values.db.host这类键 -
values.yaml中保留真正需要差异化控制的字段：replicaCount、image.tag、ingress.enabled、autoscaling.enabled - 不同环境用
helm install -f values.prod.yaml覆盖，values.prod.yaml只需重写image.tag和config字段，其余继承默认values.yaml - 敏感字段（如 JWT 密钥、数据库密码）绝不在
values.yaml明文出现，改用Secret挂载 +config.Load的withSource加密源支持
最常被忽略的一点：Kratos 的 transport/http.Server 和 transport/grpc.Server 默认不启用 CORS 和 TLS，如果 Helm 部署后前端调用 403 或连接被重置，不是 Helm 写错了，而是 Kratos 代码里没开 cors.New() 中间件或没配置证书路径——Helm 只管容器调度，不替你写业务逻辑。
