⚡

HelmChartValidator&AnalysisToolkit helm-validator

这个技能提供了一个全面的Helm图表验证和分析工作流程，结合了Helm原生的lint检查、模板渲染、YAML验证、模式验证、CRD文档查找以及安全最佳实践检查。

Docker/K8s 0 次安装 0 次浏览 更新于 3/4/2026

Helm Chart Validator & Analysis Toolkit

Helm 图表验证与分析工具包

概述

这项技能提供了一个全面的Helm图表验证和分析工作流程，结合了Helm原生的lint检查、模板渲染、YAML验证、模式验证、CRD文档查找以及安全最佳实践检查。

**重要提示：**这是一个只读验证器。它分析图表并提出改进建议，但不修改任何文件。所有建议的更改都会在最终摘要中列出，供用户手动审核和应用，或者通过helm-generator技能自动应用。

何时使用这项技能

在以下情况下调用这项技能：

  • 在打包或部署之前验证Helm图表
  • 调试Helm模板渲染错误
  • 使用不同的值测试图表模板
  • 使用需要文档的自定义资源定义（CRD）
  • 实施或重构Helm模板助手（_helpers.tpl）
  • 执行干运行测试以捕获准入控制器错误
  • 确保图表遵循Helm和Kubernetes的最佳实践
  • 使用Helm函数自动化重复的模板模式
  • 用户要求“验证”、“lint”、“检查”、“测试”或“改进”Helm图表
  • 创建或优化模板函数，如include、tpl、required等

验证和测试工作流程

按照这个顺序验证工作流程。每个阶段捕获不同类型的问题：

第1阶段：工具检查

在开始验证之前，验证所需的工具是否已安装：

bash scripts/setup_tools.sh

所需工具：

  • helm：Kubernetes的Helm包管理器（v3+）
  • yamllint：YAML语法和样式lint
  • kubeconform：支持CRD的Kubernetes模式验证
  • kubectl：集群干运行测试（可选，但推荐）

如果缺少工具，请提供脚本输出中的安装说明，并询问用户是否希望安装它们。

第2阶段：Helm图表结构验证

验证图表是否遵循标准的Helm目录结构：

bash scripts/validate_chart_structure.sh <chart-directory>

预期结构：

mychart/
  Chart.yaml          # 图表元数据（必需）
  values.yaml         # 默认值（必需）
  values.schema.json  # JSON模式用于值验证（可选）
  templates/          # 模板目录（必需）
    _helpers.tpl      # 模板助手（推荐）
    NOTES.txt         # 安装后说明（推荐）
    *.yaml            # Kubernetes清单模板
  charts/             # 图表依赖项（可选）
  crds/               # 自定义资源定义（可选）
  .helmignore         # 打包过程中要忽略的文件（可选）

常见问题：

  • 缺少必需文件（Chart.yaml、values.yaml、templates/）
  • Chart.yaml语法无效或缺少必需字段
  • values.schema.json格式错误
  • 文件权限不正确

第3阶段：Helm Lint

运行Helm内置的linter来捕获图表特定的问题：

helm lint <chart-directory> --strict

可选标志：

  • --values <values-file>：使用特定的值文件进行测试
  • --set key=value：覆盖特定值
  • --debug：显示详细的错误信息

常见问题：

  • Chart.yaml元数据无效
  • 模板语法错误
  • 缺少或未定义的值
  • 已弃用的Kubernetes API版本
  • 图表最佳实践违规

自动修复方法：

  • 对于模板错误，确定有问题的模板文件
  • 向用户显示导致问题的特定行
  • 使用编辑工具提出修复建议
  • 修复后重新运行helm lint

第4阶段：模板渲染

在本地渲染模板以验证它们是否产生有效的YAML：

helm template <release-name> <chart-directory> \
  --values <values-file> \
  --debug \
  --output-dir ./rendered

考虑的选项：

  • --values values.yaml：使用特定的值文件
  • --set key=value：覆盖单个值
  • --show-only templates/deployment.yaml：渲染特定模板
  • --validate：根据Kubernetes OpenAPI模式进行验证
  • --include-crds：在渲染输出中包含CRD
  • --is-upgrade：模拟升级场景
  • --kube-version 1.28.0：针对特定的Kubernetes版本

常见问题：

  • 模板语法错误（Go模板问题）
  • 未定义的变量或值
  • 类型不匹配（字符串与整数）
  • 缺少必需的值
  • 条件或循环中的逻辑错误
  • 嵌套模板中的缩进不正确

对于模板错误：

  • 确定模板文件和行号
  • 检查values.yaml中是否正确定义了值
  • 验证模板函数的使用（quote、required、default、include等）
  • 使用不同的值组合进行测试

第5阶段：YAML语法验证

验证渲染模板的YAML语法和格式：

yamllint -c assets/.yamllint ./rendered/*.yaml

常见问题：

  • 缩进错误（制表符与空格）
  • 尾随空白
  • 行长度违规
  • 语法错误
  • 重复键
  • 文档开始/结束标记

自动修复方法：

  • 对于简单的问题（缩进、尾随空格），使用编辑工具提出修复建议
  • 对于模板生成的问题，修复源模板，而不是渲染输出
  • 在应用修复之前始终向用户显示将更改的内容

第6阶段：CRD检测和文档查找

在模式验证之前，检测图表是否包含或渲染自定义资源定义：

# 检查crds/目录
bash scripts/detect_crd_wrapper.sh <chart-directory>/crds/*.yaml

# 检查渲染模板
bash scripts/detect_crd_wrapper.sh ./rendered/*.yaml

脚本输出包含资源信息的JSON：

[
  {
    "kind": "Certificate",
    "apiVersion": "cert-manager.io/v1",
    "group": "cert-manager.io",
    "version": "v1",
    "isCRD": true,
    "name": "example-cert"
  }
]

对于每个检测到的CRD：

  1. 首先尝试context7 MCP（首选）：

    使用mcp__context7__resolve-library-id与CRD项目名称
示例："cert-manager"用于cert-manager.io CRDs
         "prometheus-operator"用于monitoring.coreos.com CRDs
         "istio"用于networking.istio.io CRDs

然后使用mcp__context7__get-library-docs：
- context7CompatibleLibraryID来自解析步骤
- topic：CRD种类和相关特性（例如，"Certificate spec"）
- tokens：5000（根据需要调整）

  2. 如果context7失败，回退到WebSearch：

    搜索查询模式：
"<kind>" "<group>" kubernetes CRD "<version>" documentation spec

示例：
"Certificate" "cert-manager.io" kubernetes CRD "v1" documentation spec
"Prometheus" "monitoring.coreos.com" kubernetes CRD "v1" documentation spec

  3. 提取关键信息：

    • spec中必需的字段
    • 字段类型和验证规则
    • 文档中的示例
    • 版本特定更改或弃用
    • 常见配置模式

**为什么这很重要：**CRD具有标准Kubernetes验证工具中不可用的自定义模式。了解CRD的spec要求可以防止验证错误，并确保正确的资源配置。

第7阶段：模式验证

验证渲染模板与Kubernetes模式：

kubeconform \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  -summary \
  -verbose \
  ./rendered/*.yaml

考虑的选项：

  • 添加-strict以拒绝未知字段（生产推荐）
  • 添加-ignore-missing-schemas如果使用自定义/内部CRD
  • 添加-kubernetes-version 1.28.0针对特定K8s版本验证
  • 添加-output json用于程序处理

常见问题：

  • 无效的apiVersion或kind
  • 缺少必需字段
  • 错误的字段类型
  • 无效的枚举值
  • 未知字段（使用-strict）

**对于CRDs：**如果kubeconform报告"未找到模式"，这是预期的。使用第6阶段的文档手动验证spec字段。

第8阶段：集群干运行（如果可用）

如果kubectl已配置且集群访问可用，执行服务器端干运行：

# 测试安装
helm install <release-name> <chart-directory> \
  --dry-run \
  --debug \
  --values <values-file>

# 测试升级
helm upgrade <release-name> <chart-directory> \
  --dry-run \
  --debug \
  --values <values-file>

这可以捕获：

  • 准入控制器拒绝
  • 策略违规（PSP、OPA、Kyverno等）
  • 资源配额违规
  • 缺少命名空间
  • 无效的ConfigMap/Secret引用
  • Webhook验证
  • 现有资源冲突

如果干运行不可能：

  • 使用kubectl与渲染模板：kubectl apply --dry-run=server -f ./rendered/
  • 没有集群访问则跳过
  • 在验证报告中记录跳过的集群特定验证

对于现有发布的更新：

helm diff upgrade <release-name> <chart-directory>

这显示了将发生的变化，有助于捕获意外的修改。（需要helm-diff插件）

第9阶段：安全最佳实践检查（强制性）

**重要提示：**这个阶段是强制性的。分析渲染模板是否符合安全最佳实践。

检查渲染的Deployment/Pod模板：

  1. 缺少securityContext - 查找没有安全设置的pod/容器：

    # 检查pod级securityContext是否存在
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000

  2. 缺少容器securityContext - 每个容器应该具有：

    securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  capabilities:
    drop:
      - ALL

  3. 缺少资源限制/请求 - 检查：

    resources:
  limits:
    cpu: "100m"
    memory: "128Mi"
  requests:
    cpu: "100m"
    memory: "128Mi"

  4. 镜像标签问题 - 如果使用:latest或没有标签

  5. 缺少探针 - 检查存活/就绪探针

**如何检查：**读取渲染的部署YAML文件，并使用grep查找这些模式：

# 检查securityContext
grep -l "securityContext" ./rendered/*.yaml

# 检查资源
grep -l "resources:" ./rendered/*.yaml

# 检查最新标签
grep "image:.*:latest" ./rendered/*.yaml

第10阶段：最终报告（强制性）

**重要提示：**这个阶段是强制性的，即使所有验证都通过。你必须完成以下所有操作。

这是一个只读验证器。不要修改任何文件。在摘要中列出所有建议的更改。

第1步：加载参考文件（当存在警告时强制性）

如果发现任何警告、错误或安全问题，你必须阅读：

阅读references/helm_best_practices.md
阅读references/k8s_best_practices.md

使用这些参考为每个发现的问题提供上下文和建议。

第2步：呈现验证摘要

始终呈现一个验证摘要，格式为表格，显示：

  • 执行的每个验证阶段（第1-9阶段）
  • 每个阶段的状态（✅通过，⚠️警告，❌失败）
  • 每个阶段发现的问题数量

示例：

| 阶段 | 状态 | 问题 |
|-------|--------|--------|
| 1. 工具检查 | ✅通过 | 所有工具可用 |
| 2. 结构 | ⚠️警告 | 缺少：.helmignore，NOTES.txt |
| 3. Helm Lint | ✅通过 | 0个错误 |
| 4. 模板渲染 | ✅通过 | 5个模板渲染 |
| 5. YAML语法 | ✅通过 | 没有yamllint错误 |
| 6. CRD检测 | ✅通过 | 1个CRD文档化 |
| 7. 模式验证 | ✅通过 | 所有资源有效 |
| 8. 干运行 | ✅通过 | 没有集群错误 |
| 9. 安全检查 | ⚠️警告 | 缺少securityContext |

第3步：分类所有问题

按严重性分组发现：

❌错误（必须修复）：

  • 模板语法错误
  • 缺少必需字段
  • 模式验证失败
  • 干运行失败

⚠️警告（应该修复）：

  • 已弃用的Kubernetes API
  • 缺少securityContext
  • 缺少资源限制/请求
  • 使用:latest镜像标签
  • 缺少推荐文件（_helpers.tpl，.helmignore，NOTES.txt）

ℹ️信息（建议）：

第4步：列出建议的更改（不要应用）

对于每个问题，提供建议的修复，包括：

  • 文件路径和行号（如果适用）
  • 代码前后对比块
  • 解释为什么推荐这个更改

示例格式：

## 建议更改

### 1. 向Deployment添加securityContext
**文件：**templates/deployment.yaml:25
**严重性：**⚠️警告
**原因：**以root用户运行容器存在安全风险

**当前：**
```yaml
spec:
  containers:
    - name: app
      image: nginx:1.21

建议：

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
    - name: app
      image: nginx:1.21
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

2. 添加.helmignore文件

文件：.helmignore（新文件） 严重性：⚠️警告 **原因：**从图表打包中排除不必要的文件

**建议：**从assets/.helmignore复制


#### 第5步：自动化机会

在摘要中列出所有检测到的自动化机会：
- 如果缺少`_helpers.tpl` → 建议：`bash scripts/generate_helpers.sh <chart>`
- 如果缺少`.helmignore` → 建议：从`assets/.helmignore`复制
- 如果缺少`values.schema.json` → 建议：从`assets/values.schema.json`复制和定制
- 如果缺少`NOTES.txt` → 建议：创建安装后说明模板
- 如果缺少`README.md` → 建议：创建图表文档

#### 第6步：最终摘要

提供一个最终摘要：

验证摘要

图表：<chart-name> 状态：⚠️警告发现（或✅准备部署）

发现的问题：

  • 错误：X
  • 警告：Y
  • 信息：Z

**建议更改：**N个更改建议

下一步：

  1. 查看上述建议更改
  2. 手动应用更改或使用helm-generator技能
  3. 重新运行验证以确认修复

Helm Templating Automation & Best Practices

这部分涵盖了高级Helm模板技术、助手函数和自动化策略。

### 模板助手（_helpers.tpl）

模板助手是在`templates/_helpers.tpl`中定义的可重用函数。它们促进了DRY原则和一致性。

**标准助手模式：**
1. **图表名称助手：**
```yaml
{{/*
扩展图表的名称。
*/}}
{{- define "mychart.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}
  1. 全名助手：
{{/*
创建默认的完全合格的应用名称。
*/}}
{{- define "mychart.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}
  1. 图表引用助手：
{{/*
创建图表名称和版本，如图表标签中使用的。
*/}}
{{- define "mychart.chart" -}}
{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" }}
{{- end }}
  1. 标准标签助手：
{{/*
公共标签
*/}}
{{- define "mychart.labels" -}}
helm.sh/chart: {{ include "mychart.chart" . }}
{{ include "mychart.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}
  1. 选择器标签助手：
{{/*
选择器标签
*/}}
{{- define "mychart.selectorLabels" -}}
app.kubernetes.io/name: {{ include "mychart.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}
  1. 服务账户名称助手：
{{/*
创建要使用的服务账户名称
*/}}
{{- define "mychart.serviceAccountName" -}}
{{- if .Values.serviceAccount.create }}
{{- default (include "mychart.fullname" .) .Values.serviceAccount.name }}
{{- else }}
{{- default "default" .Values.serviceAccount.name }}
{{- end }}
{{- end }}

何时创建助手：

  • 在多个模板中使用的值
  • 重复的复杂逻辑
  • 应该一致的标签集
  • 名称生成模式
  • 条件资源包含

基本模板函数

参考并使用这些Helm模板函数来构建健壮的图表：

  1. required - 强制要求值：
apiVersion: v1
kind: Service
metadata:
  name: {{ required "需要有效的服务名称！" .Values.service.name }}
  1. default - 提供回退值：
replicas: {{ .Values.replicaCount | default 1 }}
  1. quote - 安全引用字符串值：
env:
  - name: DATABASE_HOST
    value: {{ .Values.database.host | quote }}
  1. include - 使用助手与管道：
metadata:
  labels:
    {{- include "mychart.labels" . | nindent 4 }}
  1. tpl - 将字符串作为模板渲染：
{{- tpl .Values.customConfig . }}
  1. toYaml - 将对象转换为YAML：
{{- with .Values.resources }}
resources:
  {{- toYaml . | nindent 2 }}
{{- end }}
  1. fromYaml - 解析YAML字符串：
{{- $config := .Values.configYaml | fromYaml }}
  1. merge - 合并映射：
{{- $merged := merge .Values.override .Values.defaults }}
  1. lookup - 查询集群资源（谨慎使用）：
{{- $secret := lookup "v1" "Secret" .Release.Namespace "my-secret" }}
{{- if $secret }}
  # 存在Secret，使用它
{{- else }}
  # 创建新的Secret
{{- end }}

高级模板模式

  1. 条件资源创建：
{{- if .Values.ingress.enabled -}}
apiVersion: networking.k8s.io/v1
kind: Ingress
# ... ingress定义
{{- end }}
  1. 列表范围：
{{- range .Values.extraEnvVars }}
- name: {{ .name }}
  value: {{ .value | quote }}
{{- end }}
  1. 映射范围：
{{- range $key, $value := .Values.configMap }}
{{ $key }}: {{ $value | quote }}
{{- end }}
  1. 用于作用域的with块：
{{- with .Values.nodeSelector }}
nodeSelector:
  {{- toYaml . | nindent 2 }}
{{- end }}
  1. 带自定义上下文的命名模板：
{{- include "mychart.container" (dict "root" . "container" .Values.mainContainer) }}

值结构最佳实践

尽可能优先选择平面结构：

# 好的 - 平面结构
serverName: nginx
serverPort: 80

# 可接受 - 相关设置的嵌套结构
server:
  name: nginx
  port: 80
  replicas: 3

在values.yaml中始终提供默认值：

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "1.21.0"

service:
  type: ClusterIP
  port: 80

resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

记录所有值：

# replicaCount是部署的pod副本数量
replicaCount: 1

# image配置容器镜像
image:
  # image.repository是容器镜像注册表和名称
  repository: nginx
  # image.tag覆盖镜像标签（默认是图表appVersion）
  tag: "1.21.0"

模板注释和文档

使用Helm模板注释进行文档记录：

{{- /*
mychart.fullname为资源生成全名。
它支持nameOverride和fullnameOverride值。
用法：{{ include "mychart.fullname" . }}
*/ -}}
{{- define "mychart.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

使用YAML注释进行用户面向的注释：

# 警告：更改存储类别不会迁移现有数据
storageClass: "standard"

空白管理

使用-在模板指令中去除空白：

{{- if .Values.enabled }}
  # 去除前导空白
{{- end }}

{{ .Values.name -}}
  # 去除尾随空白

良好格式：

{{- if .Values.enabled }}
  key: value
{{- end }}

不良格式：

{{if .Values.enabled}}
key: value
{{end}}

助手模式参考

在分析图表时，识别助手函数的机会：

  1. 识别重复：

    • 跨资源的相同标签集
    • 重复的名称生成逻辑
    • 常见的条件模式

  2. 推荐常见的助手模式：

    • 图表名称助手（.name）
    • 全名助手（.fullname）
    • 图表版本标签（.chart）
    • 公共标签（.labels）
    • 选择器标签（.selectorLabels）
    • 服务账户名称（.serviceAccountName）

  3. 何时推荐助手：

    • 缺少_helpers.tpl文件
    • 跨模板的重复代码模式
    • 不一致的标签使用
    • 需要截断的长资源名称

最佳实践参考

有关详细的Helm和Kubernetes最佳实践，请加载参考：

阅读references/helm_best_practices.md
阅读references/k8s_best_practices.md

这些参考包括：

  • 图表结构和元数据
  • 模板约定和模式
  • 值文件组织
  • 安全最佳实践
  • 资源限制和请求
  • 常见验证问题及修复方法

**何时加载：**当验证揭示问题需要上下文时，当实施新功能时，或当用户询问最佳实践时。

处理图表依赖项

当图表有依赖项（在Chart.yaml或charts/目录中）：

  1. 更新依赖项：
helm dependency update <chart-directory>
  1. 列出依赖项：
helm dependency list <chart-directory>

  1. 验证依赖项：

    • 检查依赖项版本是否可用
    • 验证依赖项值是否正确作用域
    • 使用依赖资源测试模板

  2. 覆盖依赖项值：

# values.yaml
postgresql:
  enabled: true
  postgresqlPassword: "secret"
  persistence:
    size: 10Gi

错误处理策略

工具不可用

  • 运行scripts/setup_tools.sh检查可用性
  • 提供安装说明
  • 跳过可选阶段，但记录跳过的内容
  • 使用可用工具继续

模板渲染错误

  • 显示特定的模板文件和行号
  • 检查values.yaml中是否定义了值
  • 验证模板函数语法
  • 使用更简单的值组合进行测试
  • 使用--debug标志获取详细错误消息

集群访问问题

  • 回退到客户端验证
  • 使用kubectl与渲染模板
  • 如果没有kubectl配置，则跳过集群验证
  • 在验证报告中记录限制

CRD文档未找到

  • 记录文档查找失败
  • 使用kubeconform CRD模式尝试验证
  • 建议手动CRD检查：
    kubectl get crd <crd-name>.group -o yaml
kubectl explain <kind>

验证阶段失败

  • 即使一个失败，也继续下一个阶段
  • 在呈现给用户之前收集所有错误
  • 优先修复Helm lint错误
  • 然后修复模板错误
  • 最后修复模式/验证错误

macOS扩展属性问题

**症状：**Helm报告"Chart.yaml文件丢失"，即使文件存在且可读。

**原因：**在macOS上，通过Write工具、脚本或某些编辑器以编程方式创建的文件可能具有扩展属性（例如，com.apple.provenance，com.apple.quarantine），这些属性会干扰Helm的文件检测。

诊断：

# 检查扩展属性
xattr /path/to/chart/Chart.yaml

# 如果存在属性，你将看到类似输出：
# com.apple.provenance
# com.apple.quarantine

解决方案：

  1. 移除扩展属性：

    # 从文件中移除所有扩展属性
xattr -c /path/to/chart/Chart.yaml

# 从图表目录递归移除所有扩展属性
xattr -cr /path/to/chart/

  2. 使用shell命令创建文件：

    # 使用cat和heredoc而不是直接文件写入
cat > Chart.yaml << 'EOF'
apiVersion: v2
name: mychart
version: 0.1.0
EOF

  3. 从helm创建的图表复制：

    # 创建一个新的图表并复制结构
helm create temp-chart
cp -r temp-chart/* /path/to/your/chart/
rm -rf temp-chart

**预防：**在macOS上创建新图表文件时，优先使用helm create作为基础，或使用shell heredocs（cat > file << 'EOF'）而不是直接文件创建工具。

沟通指南

在呈现验证结果和修复时：

  1. 清晰简洁地说明发现了什么
  2. 解释为什么问题重要（例如，“这将导致pod创建失败”）
  3. 提供上下文，涉及Helm最佳实践时相关
  4. 将相关问题分组（例如，所有缺少助手的问题一起）
  5. 使用文件：行引用（如果可用）
  6. 显示自动修复的置信度（高置信度=语法，低置信度=逻辑更改）
  7. 在应用修复后始终提供摘要，包括：
    • 变更内容及原因
    • 每个修复的文件和行引用
    • 解决的问题总数
    • 最终验证状态
    • 任何剩余的警告或建议

版本意识

始终考虑Kubernetes和Helm版本兼容性：

  • 检查已弃用的Kubernetes API
  • 确保Helm图表apiVersion是v2（对于Helm 3+）
  • 对于CRDs，确保apiVersion与集群中的匹配
  • 使用kubectl api-versions列出可用的API版本
  • 参考特定版本的文档
  • 如果需要，在Chart.yaml中设置kubeVersion约束

图表测试

进行全面测试，使用Helm测试资源：

  1. 创建测试资源：
# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "mychart.fullname" . }}-test-connection"
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['{{ include "mychart.fullname" . }}:{{ .Values.service.port }}']
  restartPolicy: Never
  1. 运行测试：
helm test <release-name>

自动化机会参考

在第10阶段（最终报告）中，在摘要中列出所有检测到的自动化机会。

不要向用户提问或修改文件。只列出建议。

检测和列出的自动化机会：

缺少项 建议
_helpers.tpl 运行：bash scripts/generate_helpers.sh <chart>
.helmignore 复制自：assets/.helmignore
values.schema.json 复制和定制自：assets/values.schema.json
NOTES.txt 创建安装后说明模板
README.md 创建图表文档
重复模式 提取到助手函数

发现问题时包括的安全建议：

问题 建议
缺少pod securityContext 添加runAsNonRoot: true，runAsUser: 1000，fsGroup: 2000
缺少容器securityContext 添加allowPrivilegeEscalation: false，readOnlyRootFilesystem: true，capabilities.drop: [ALL]
缺少资源限制 添加CPU/内存限制和请求
使用:latest标签 固定到特定镜像版本
缺少探针 添加存活和就绪探针

模板改进建议：

问题 建议
使用template而不是include 替换为include以支持管道
缺少nindent 添加nindent以获得适当的YAML缩进
没有默认值 为可选值添加default函数
缺少required函数 为关键值添加required

资源

scripts/

setup_tools.sh

  • 检查所需的验证工具（helm，yamllint，kubeconform，kubectl）
  • 为缺少的工具提供安装说明
  • 验证已安装工具的版本
  • 使用方法：bash scripts/setup_tools.sh

validate_chart_structure.sh

  • 验证Helm图表目录结构
  • 检查必需文件（Chart.yaml，values.yaml，templates/）
  • 验证文件格式和语法
  • 使用方法：bash scripts/validate_chart_structure.sh <chart-directory>

detect_crd_wrapper.sh

  • 包装脚本，处理Python依赖管理
  • 如果PyYAML不可用，自动创建临时venv
  • 调用detect_crd.py解析YAML文件
  • 使用方法：bash scripts/detect_crd_wrapper.sh <file.yaml>

detect_crd.py

  • 解析YAML文件以识别自定义资源定义
  • 提取kind，apiVersion，group和version信息
  • 输出JSON以供程序处理
  • 需要PyYAML（由包装脚本自动处理）
  • 可以直接调用：python3 scripts/detect_crd.py <file.yaml>

generate_helpers.sh

  • 为图表生成标准Helm助手（_helpers.tpl）
  • 创建fullname，labels和selector助手
  • 使用方法：bash scripts/generate_helpers.sh <chart-directory>

references/

helm_best_practices.md

  • Helm图表最佳实践的综合指南
  • 涵盖模板模式，助手函数，值结构
  • 常见验证问题及如何修复
  • 安全和性能建议
  • 加载时提供Helm特定问题的上下文

k8s_best_practices.md

  • Kubernetes YAML最佳实践的综合指南
  • 涵盖元数据，标签，资源限制，安全上下文
  • 常见验证问题及如何修复
  • 加载时提供Kubernetes特定问题的上下文

template_functions.md

  • Helm模板函数的参考指南
  • 所有内置函数的示例
  • Sprig函数库参考
  • 自定义函数模式
  • 加载时实现复杂模板

assets/

.helmignore

  • 排除打包的标准.helmignore文件
  • 预配置了常见模式

.yamllint

  • 预配置的yamllint规则，适用于Kubernetes YAML
  • 遵循Kubernetes约定（2个空格缩进，行长度等）
  • 可以根据项目定制
  • 使用方法：yamllint -c assets/.yamllint <file.yaml>

values.schema.json

  • 值验证的示例JSON模式
  • 可以复制和定制特定图表
  • 提供类型安全性和验证