3. Helm 核心概念：Chart、Release、Repository、Values 与 Templates

Helm 是 Kubernetes 生态中最流行的包管理工具，其核心设计围绕五个关键概念展开。理解这些概念是掌握 Helm 网络拓扑资源配额配置策略的基础。本章将逐一剖析 Chart、Release、Repository、Values 与 Templates 的定义、作用及相互关系。

3.1 概念总览与关系矩阵

五个核心概念构成了 Helm 的工作闭环：Chart 是打包好的应用模板；Values 提供可配置参数；Templates 将 Chart 与 Values 渲染为 Kubernetes 资源清单；Release 是 Chart 在集群中的一次部署实例；Repository 是 Chart 的存储与分发仓库。

3.2 Chart：应用打包标准

Chart 是 Helm 的核心打包单元，本质是一个遵循特定目录结构的文件集合。一个标准的 Chart 目录结构如下：

mychart/
├── Chart.yaml          # Chart 元数据（名称、版本、描述）
├── values.yaml         # 默认配置值
├── values.schema.json  # （可选）Values 的 JSON Schema 校验
├── charts/             # （可选）子 Chart 依赖
├── templates/          # Kubernetes 资源模板目录
│   ├── NOTES.txt       # 部署后提示信息
│   ├── _helpers.tpl    # 模板辅助函数
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── networkpolicy.yaml
│   └── resourcequota.yaml
└── .helmignore         # 打包时忽略的文件模式

3.3 Release：部署实例管理

Release 是 Chart 在 Kubernetes 集群中的一次具体部署实例。每次执行 helm install 都会创建一个新的 Release，而 helm upgrade 则更新已有 Release。

3.4 Repository：Chart 分发中心

Repository 是 Helm Chart 的存储和分发仓库，类似于 Docker 的镜像仓库。用户可以通过 helm repo add 添加远端仓库，通过 helm search 查找 Chart。

# 添加官方稳定仓库
helm repo add stable https://charts.helm.sh/stable

# 添加网络拓扑策略专用仓库
helm repo add netpolicy-repo https://my-company.com/charts

# 搜索网络策略相关 Chart
helm search repo network-policy

# 更新仓库索引
helm repo update

3.5 Values：配置参数注入

Values 是 Helm 实现参数化配置的核心机制。用户通过 values.yaml 文件或 --set 命令行参数，将自定义配置注入到 Templates 中。

以下是一个网络拓扑资源配额场景的 Values 示例：

# values.yaml
namespace: production
networkPolicy:
  enabled: true
  ingressRules:
    - from:
        - namespaceSelector:
            matchLabels:
              tier: frontend
      ports:
        - port: 80
          protocol: TCP
resourceQuota:
  enabled: true
  limits:
    cpu: "4"
    memory: "8Gi"
    pods: "10"
    services: "5"
  requests:
    cpu: "2"
    memory: "4Gi"

3.6 Templates：资源渲染引擎

Templates 使用 Go 模板语法，将 Values 中的参数动态填充到 Kubernetes 资源清单中。Helm 内置了丰富的模板函数（如 quote、default、include）和流水线操作。

以下是一个 networkpolicy.yaml 模板示例：

{{- if .Values.networkPolicy.enabled }}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: {{ .Release.Name }}-network-policy
  namespace: {{ .Values.namespace | default .Release.Namespace }}
spec:
  podSelector:
    matchLabels:
      app: {{ .Release.Name }}
  policyTypes:
    - Ingress
  ingress:
    {{- range .Values.networkPolicy.ingressRules }}
    - from:
        {{- range .from }}
        - namespaceSelector:
            matchLabels:
              {{- range $key, $value := .namespaceSelector.matchLabels }}
              {{ $key }}: {{ $value | quote }}
              {{- end }}
          {{- if .podSelector }}
          podSelector:
            matchLabels:
              {{- range $key, $value := .podSelector.matchLabels }}
              {{ $key }}: {{ $value | quote }}
              {{- end }}
          {{- end }}
        {{- end }}
      ports:
        {{- range .ports }}
        - port: {{ .port }}
          protocol: {{ .protocol | default "TCP" }}
        {{- end }}
    {{- end }}
{{- end }}

# 预览渲染结果
helm template my-release ./mychart -f values.yaml

3.7 概念协同：从 Chart 到 Release 的完整流程

下图展示了五个核心概念如何协同工作，完成一次网络拓扑资源配额策略的部署：

3.8 最佳实践与常见误区

• Chart 版本管理： 始终在 Chart.yaml 中维护 version 和 appVersion 字段，确保网络策略变更可追溯。
• Values 分层设计： 将网络策略规则、资源配额数值、命名空间名称等参数分离到不同的 Values 层级，便于维护和复用。
• 模板函数复用： 在 _helpers.tpl 中定义通用的标签生成函数，避免在每个模板中重复编写相同的逻辑。
• 避免硬编码： 所有 Kubernetes 资源名称、标签、命名空间都应通过 .Release.Name 或 .Values 动态生成，禁止在模板中写死。
• Schema 校验： 使用 values.schema.json 对 Values 进行类型和范围校验，防止误传非法配额数值导致集群不稳定。