Sublime Text不运行Helm，所谓“Helm插件”仅提供YAML语法高亮、缩进对齐和文件跳转，无法校验Chart合法性、渲染模板或连接Kubernetes集群，真正验证依赖helm template --debug命令。
Sublime Text 本身不运行 Helm，插件只是辅助写 YAML
Sublime Text 没有内置 Kubernetes 或 Helm 运行时能力，所谓“Helm 插件”（如 Helm Syntax 或 YAML Navigation）只做三件事：高亮 values.yaml 里的变量语法（{{ .Values.replicaCount }}）、缩进对齐模板块、跳转到 templates/ 下对应文件。它不会校验 Chart.yaml 字段合法性，也不会渲染模板或连接集群。
常见错误现象：
- 复制粘贴了
helm create myapp生成的模板，但没改serviceName和matchLabels，导致 StatefulSet 启动失败（Pod 卡在Pending） - 在
values.yaml里写了ingress.enabled: true，但templates/ingress.yaml文件缺失或条件判断写成{{ if .Values.ingress.enable }}（少了个d），结果 Ingress 资源根本没生成
实操建议：
- 安装
YAMLLintSublime 插件，并配置.yamllint规则，强制检查缩进、空格、键名拼写 - 用
Ctrl+Shift+P→YAML: Validate（需提前装好yaml-language-server）快速发现语法错误 - 别依赖插件自动补全
.Release.Name这类内置对象——Sublime 不知道 Helm 版本差异，Helm 3 已移除.Release.Service，但旧插件提示仍存在
StatefulSet 的 serviceName 必须与 spec.serviceName 严格一致
这是 Sublime 编辑时最容易漏检的硬约束。Kubernetes 要求 StatefulSet 的 spec.serviceName 字段必须指向一个已存在的 Service 对象，且该 Service 的 metadata.name 必须完全匹配——大小写、连字符、长度都不能差。
使用场景：
- 部署 Kafka、ZooKeeper、Elasticsearch 等有状态中间件时，Pod 域名格式为
<pod-name>.<serviceName>.<namespace>.svc.cluster.local - 若
serviceName: kafka-headless，但实际 Service 文件命名为kafka-service.yaml，Pod 就无法解析域名，InitContainer 卡住
实操建议：
- 在 Sublime 中用
Find All in Project搜索serviceName:，确认所有地方（StatefulSet、Service、Headless Service）拼写统一 - 避免在
values.yaml中动态生成serviceName，例如serviceName: "{{ .Release.Name }}-headless"—— 这会让人工校验失效，且 Helm lint 不报错 - 给 Service 加上
clusterIP: None标识其为 Headless Service，否则 StatefulSet 启动时会报service not found
helm template --debug 是唯一能验证模板逻辑的手段
Sublime 插件再智能，也无法替代 helm template。它才是真正把 values.yaml、_helpers.tpl、条件块和循环展开成最终 YAML 的执行器。你看到的编辑器里“看起来对”的结构，可能在渲染时因作用域或空值处理崩掉。
参数差异：
-
helm template myapp ./mychart --debug：直接输出渲染后全部 YAML，含注释说明每段来自哪个模板文件 -
helm template myapp ./mychart --dry-run --debug：模拟提交给 API Server，但不真正创建资源（仍需 kubeconfig 可达） -
helm template myapp ./mychart -f values-prod.yaml --debug：指定非默认 values 文件，验证环境差异化配置
容易踩的坑：
- 在 Sublime 里写了
{{- include "myapp.fullname" . | quote }}，但_helpers.tpl中fullname定义漏了.Release.Name，helm template会报error calling include: template "myapp.fullname" not defined - 用
{{ .Values.ingress.hosts | toJson }}输出 JSON 字符串，但实际需要的是数组结构，helm template渲染出的 YAML 会多一层引号，导致 Ingress 控制器无法识别
revisionHistoryLimit 影响 StatefulSet 滚动更新的安全边界
这个字段不在 Sublime 插件的高亮范围内，但直接决定回滚是否可行。它控制 StatefulSet 保留多少个旧版本的 ReplicaSet（即历史 revision）。设为 0 表示不保留任何历史版本，一旦升级失败就只能手动修复；设为 10 会占用更多 etcd 存储，但支持最多回退 10 次。
性能与兼容性影响：
- Kubernetes 1.22+ 默认值为
10，但旧集群（如 1.16）可能默认为0，需显式声明 - StatefulSet 的
revisionHistoryLimit和 Deployment 的同名字段行为不同：Deployment 删除旧 ReplicaSet 后释放 Pod，而 StatefulSet 保留旧 Pod（带 PVC 绑定），仅清理控制器元数据
实操建议：
- 在
templates/statefulset.yaml中固定写死revisionHistoryLimit: 5，不要从values.yaml动态注入——避免因 values 错误导致无限保留历史版本 - 配合
helm upgrade --history-max 5控制 Release 版本数量，两者协同防止集群元数据膨胀 - 升级前用
kubectl get statefulset myapp -o yaml | grep revisionHistoryLimit确认当前值，比依赖 Sublime 里写的“预期值”更可靠
Sublime Text 的价值在于写得快、看得清，但它不参与 Helm 的任何执行环节。真正决定部署成败的，永远是 helm template 渲染出的 YAML 是否合法，以及 kubectl apply 提交后集群的实际响应。别让编辑器里的绿色高亮，掩盖了 serviceName 拼错一个字母带来的连锁故障。
