跳转到内容

Helm 面试题

30 道题
分类
Kubernetes
题目数
30 道
已阅读 0 / 30 题
1 Helm 的核心组件和架构是怎样的?

答案:

Helm 采用客户端-库架构,核心组件包括 Helm CLI、Helm SDK、Chart 和 Repository。

  • Helm CLI:用户操作的命令行工具,负责 Chart 的安装、升级、回滚和卸载
  • Helm SDK:Go 语言库,封装了 Chart 解析、模板渲染、Kubernetes 资源交互等核心逻辑
  • Chart:打包的 Kubernetes 资源模板集合,包含 Chart.yaml、values.yaml、templates/ 等目录
  • Repository:Chart 的存储和分发仓库(如 ArtifactHUB、OCI Registry)
  • Release:在 Kubernetes 集群中运行的一个 Chart 实例,具有唯一的名称和版本号

工作流程:

helm install my-release bitnami/nginx
  → Helm CLI 读取 Chart
  → 合并 values.yaml 和用户自定义值
  → 渲染 Go Template
  → 将生成的 YAML 提交到 Kubernetes API
  → 创建 Release(存储在 Secret 中)

Helm v3 与 v2 的核心变化:

  • Tiller 移除:v3 移除服务器端组件 Tiller,直接通过 kubeconfig 与 K8s API 交互,消除安全风险
  • Release 存储:v2(Tiller 时代)用 ConfigMap 存于 kube-system 命名空间;v3 移除 Tiller 改用 Secrettype: helm.sh/release.v1,存于 Release 所在命名空间),支持加密
  • JSON Schema:支持 values.schema.json 校验用户输入
  • OCI 支持:直接使用容器镜像仓库存储 Chart
2 Helm Chart 的目录结构是怎样的?每个文件有什么用?

答案:

标准的 Helm Chart 目录结构如下:

graph TD
    A["mychart/"] --> B["Chart.yaml
Chart 元数据"] A --> C["values.yaml
默认配置值"] A --> D["values.schema.json
JSON Schema 校验(可选)"] A --> E["charts/
子 Chart 依赖"] A --> F["templates/
Go Template 模板文件"] F --> F1["_helpers.tpl
可复用的模板辅助函数"] F --> F2["deployment.yaml
Deployment 资源模板"] F --> F3["service.yaml
Service 资源模板"] F --> F4["ingress.yaml
Ingress 资源模板"] F --> F5["hpa.yaml
HPA 资源模板"] F --> F6["NOTES.txt
安装后的提示信息"] A --> G["crds/
CRD 定义"] A --> H["README.md
使用文档"] A --> I[".helmignore
打包时忽略的文件列表"]

各文件的作用:

  • Chart.yamlapiVersion, name, version, appVersion, description, dependencies,定义 Chart 身份和依赖关系
  • values.yaml:模板渲染的输入变量,支持层次化结构,用户可通过 -f--set 覆盖
  • values.schema.json:对 values 进行类型、范围、必填校验,无效配置直接报错
  • templates/_helpers.tpl:定义可复用的模板片段,通过 {{ include "mychart.name" . }} 引用
  • NOTES.txt:安装成功后打印的指引信息(如访问地址、默认密码获取命令)
3 Helm 模板语法核心概念有哪些?

答案:

Helm 模板基于 Go text/template 扩展,核心概念包括内置对象、函数和流程控制。

内置对象:

对象含义示例
.Valuesvalues.yaml 和用户传入值的合并{{ .Values.replicaCount }}
.ReleaseRelease 元数据{{ .Release.Name }}, {{ .Release.Namespace }}
.ChartChart.yaml 信息{{ .Chart.Name }}, {{ .Chart.Version }}
.FilesChart 内文件访问{{ .Files.Get "config.yaml" }}
.CapabilitiesK8s 集群能力{{ .Capabilities.APIVersions.Has "apps/v1" }}
.Template当前模板信息{{ .Template.Name }}

流程控制:

# if-else
{{ if .Values.persistence.enabled }}
persistence:
  enabled: true
  size: {{ .Values.persistence.size }}
{{ end }}

# range 循环
{{ range .Values.ports }}
- name: {{ .name }}
  containerPort: {{ .containerPort }}
{{ end }}

# with 作用域
{{ with .Values.securityContext }}
securityContext:
  runAsUser: {{ .runAsUser }}
  fsGroup: {{ .fsGroup }}
{{ end }}

函数与管道:

# 默认值
replicas: {{ .Values.replicaCount | default 1 }}

# 大小写转换
name: {{ .Values.appName | upper }}
env: {{ .Values.env | lower }}

# 缩进对齐
{{ .Files.Get "config.yaml" | indent 4 }}

# include 引用
{{ include "mychart.labels" . | nindent 4 }}

# quote 和 squote
name: {{ .Values.name | quote }}

# tpl(字符串模板渲染)
{{ tpl .Values.templateString . }}
4 Helm 如何管理依赖(Dependency)?

答案:

Helm 通过 Chart.yaml 的 dependencies 字段声明子 Chart 依赖。

声明依赖:

# Chart.yaml
dependencies:
- name: postgresql
  version: "12.x"
  repository: "https://charts.bitnami.com/bitnami"
  condition: postgresql.enabled  # 条件启用
  tags:
  - database
- name: redis
  version: "17.x"
  repository: "https://charts.bitnami.com/bitnami"
  condition: redis.enabled
  tags:
  - cache
- name: local-chart
  version: "0.1.0"
  repository: "file://../local-chart"  # 本地路径

依赖管理命令:

# 下载依赖到 charts/ 目录
helm dependency update

# 构建依赖(更新 Chart.lock)
helm dependency build

# 列出依赖
helm dependency list

父子 Chart 的值传递:

# 父 Chart values.yaml
postgresql:
  enabled: true
  auth:
    database: myapp
    username: myapp
redis:
  enabled: false
5 Helm 如何处理 CRD(Custom Resource Definition)?

答案:

Helm v3 对 CRD 有专门的处理机制,在 crds/ 目录中的 CRD 会在模板渲染前安装。

CRD 目录规则:

graph TD
    A["mychart/"] --> B["crds/"]
    B --> B1["crd-prometheus.yaml"]
    B --> B2["crd-servicemonitor.yaml"]
    A --> C["templates/"]
    C --> C1["prometheus.yaml
引用 CRD 的资源"]

CRD 行为:

操作CRD 处理
helm install先安装 crds/ 下的 CRD,再渲染 templates/
helm upgrade不更新 crds/ 下的 CRD(K8s 限制 CRD 更新)
helm uninstall不删除 CRD(防止删除其他释放的 CRD 实例)
helm template不处理 crds/(仅本地渲染)

注意事项:

  • CRD 安装后不可修改 spec 字段
  • CRD 升级需要手动 kubectl apply 或 Helm post-upgrade hook
  • CRD 删除会导致所有该类型的 CR 实例丢失
6 Helm Hooks 机制是什么?有什么用途?

答案:

Helm Hooks 是在 Release 生命周期的特定节点执行的特殊模板资源,用于执行初始化、备份、验证等任务。

Hook 类型:

Hook执行时机适用场景
pre-install模板渲染后、资源创建前创建数据库、生成密钥
post-install所有资源创建后初始化数据、通知
pre-upgrade升级模板渲染后、资源更新前备份数据库、预检查
post-upgrade升级完成数据迁移、通知
pre-delete删除前释放外部资源
post-delete删除后清理、通知
pre-rollback回滚前备份当前状态
post-rollback回滚后验证恢复
testhelm test 执行运行集成测试

Hook 示例:

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-db-migrate
  annotations:
    "helm.sh/hook": post-upgrade
    "helm.sh/hook-weight": "5"           # 执行顺序(数值越小越先)
    "helm.sh/hook-delete-policy": hook-succeeded  # 成功后删除
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: myapp/migrate:latest
        command: ["/bin/migrate.sh"]
      restartPolicy: Never
7 Helm 的 values 覆盖优先级是怎样的?

答案:

Helm 的 value 来源有明确优先级,高优先级会覆盖低优先级。

优先级(从低到高):

  1. Chart 自带的 values.yaml(最低优先级)
  2. 子 Chart 自带的 values.yaml(当 Chart 有 dependencies 时)
  3. 父 Chart 的 values.yaml 中的 ${子Chart名}.${key} 路径
  4. helm install -f myvalues.yaml-f myvalues.json 传入的文件
  5. --set key=value 设置的单个值
  6. --set-json key=jsonValue 设置的 JSON 值
  7. --set-string key=stringValue 强制字符串类型(最高优先级)

覆盖示例:

# 优先级从高到低(后传入的 -f 优先级更高,按顺序合并)
helm install myapp ./mychart \
  --set image.tag=prod-latest \              # 最高
  -f custom-values.yaml \                    # 次高(最后 -f 优先)
  -f prod-values.yaml                        # 第三

合并规则:

  • YAML 合并采用深度合并(deep merge),非简单替换
  • 列表默认替换而非追加;Helm 3.7+ --set 支持精确合并:key[index]=valuekey{name}=value
  • --set 支持逗号分隔和 JSON 路径:--set a.b.c=value
8 Helm 如何处理升级和回滚?

答案:

Helm v3 使用三路策略合并补丁(3-way strategic merge patch)进行升级和回滚;v3.2+ 默认改用 Server-Side Apply (SSA),v3.4+ 提供 --server-side 选项显式启用。

**升级流程:``` helm upgrade myapp ./mychart -f new-values.yaml → 读取当前 Release 的 Manifest(上次安装的 YAML) → 用新 values 重新渲染模板 → 新 Manifest → 三路合并(旧 Manifest + 新 Manifest + 当前集群状态) → 计算 Patch → 应用到 K8s API


**三路合并优势:** 手动修改过的 K8s 资源不会被直接覆盖,Helm 会识别集群状态差异并尝试智能合并。

**回滚:**

查看 Release 历史

helm history myapp

REVISION STATUS CHART APP VERSION DESCRIPTION

1 deployed mychart-1.0.0 1.0 Install complete

2 deployed mychart-1.1.0 1.1 Upgrade complete

3 failed mychart-1.2.0 1.2 Upgrade failed

回滚到版本 2

helm rollback myapp 2

指定回滚参数

helm rollback myapp 2 –wait –timeout 5m


**回滚行为:**

- 回滚 = 使用旧 Revision 的 values 重新渲染并应用
- 回滚本身会创建新 Revision
- 回滚不影响 Secret 中存储的历史
9 Helm 如何处理大规模部署(--wait / --timeout)?

答案:

Helm 提供安装后的资源就绪等待机制。

helm install myapp ./mychart \
  --wait \                    # 等待所有 Pod 进入 Ready
  --timeout 10m \             # 超时时间
  --atomic \                  # 失败时自动回滚
  --create-namespace          # 自动创建命名空间

等待资源类型:

  • Deployment / StatefulSet:等待可用副本数达到期望
  • Job:等待 Pod 执行完成
  • Service:等待 Endpoint 分配
  • PVC:等待 PV 绑定
  • Pod:等待 Ready 状态
10 Helm 如何处理多环境(dev/staging/prod)配置?

答案:

Helm 通过分层 values 文件实现多环境配置管理。

values 分层文件:

graph TD
    A["config/"] --> B["values.yaml<br/>公共基础配置"]
    A --> C["values-dev.yaml<br/>开发环境覆盖"]
    A --> D["values-staging.yaml<br/>预发布覆盖"]
    A --> E["values-prod.yaml<br/>生产覆盖"]
```text

**安装命令:**

开发

helm install myapp ./mychart -f config/values.yaml -f config/values-dev.yaml

生产

helm upgrade myapp ./mychart
-f config/values.yaml
-f config/values-prod.yaml
–set image.tag=v1.2.3


**values.yaml(基础):**

replicaCount: 1 resources: requests: cpu: 100m memory: 128Mi ingress: enabled: false


**values-prod.yaml(覆盖):**

replicaCount: 5 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2 memory: 2Gi ingress: enabled: true hosts:

  • app.prod.example.com
11 Helm 的 OCI 注册表支持是什么?

答案:

Helm v3.8+ 支持将 Chart 直接存储在 OCI(Open Container Initiative)兼容的容器镜像仓库中(v3.8 实验性,v3.13.0 (2024) 正式 GA)。

OCI 操作:

# 登录 OCI 注册表
helm registry login registry.example.com

# 推送 Chart 到 OCI
helm package mychart
helm push mychart-1.0.0.tgz oci://registry.example.com/helm-charts

# 从 OCI 安装
helm install myapp oci://registry.example.com/helm-charts/mychart --version 1.0.0

# 从 OCI 拉取
helm pull oci://registry.example.com/helm-charts/mychart --version 1.0.0

优势:

  • 统一用容器镜像仓库,无需独立 Chart 仓库
  • 支持镜像仓库的访问控制(RBAC、签名)
  • 支持镜像仓库的复制同步
12 Helm 的验证和测试机制是什么?

答案:

Helm 提供内置的 Chart 验证和测试功能。

Chart Lint:

# 语法检查
helm lint ./mychart

# 带严格模式
helm lint ./mychart --strict

# 检查结果:YAML 格式、模板渲染、values 完整性
```text

**JSON Schema 校验:**

{ “$schema”: “https://json-schema.org/draft-07/schema", “type”: “object”, “required”: [“image”, “replicaCount”], “properties”: { “image”: { “type”: “object”, “required”: [“repository”, “tag”], “properties”: { “repository”: { “type”: “string” }, “tag”: { “type”: “string”, “pattern”: “^v?[0-9]+\.[0-9]+” } } }, “replicaCount”: { “type”: “integer”, “minimum”: 1, “maximum”: 100 } } }


**Test(helm test):**

apiVersion: v1 kind: Pod metadata: name: “{{ .Release.Name }}-connection-test” annotations: “helm.sh/hook”: test spec: containers:

  • name: test image: curlimages/curl command:
    • curl
    • http://{{ .Release.Name }}-svc:80 restartPolicy: Never

helm test myapp

13 Helm 如何处理 Chart 的签名和验证?

答案:

Helm 支持 Chart 的 GPG 签名和 OCI Registry + cosign 签名两种机制,确保 Chart 来源可信和完整性。

注意: Helm 支持两套并行的签名方案——传统 HTTP 仓库的 GPG 签名helm package --sign + helm verify --keyring)与 OCI + cosign(云原生 Sigstore 方案)。两者均为官方支持,无"已不推荐"说法;新项目 OCI + cosign 趋势更明显。

签名流程:

# 生成 GPG 密钥
gpg --full-generate-key

# 签名 Chart
helm package --sign --key 'my-key' --keyring ~/.gnupg/secring.gpg ./mychart
# 生成 mychart-1.0.0.tgz + mychart-1.0.0.tgz.prov

# 验证签名
helm verify mychart-1.0.0.tgz
```text

**验证配置:**

安装时验证

helm install myapp ./mychart-1.0.0.tgz –verify

配置信任密钥

helm repo add myrepo https://charts.example.com
–ca-file ca.crt
–cert-file client.crt
–key-file client.key

14 Helm Subchart 和 Global Values 的作用?

答案:

Subchart 是 Chart 的嵌套依赖,Global Values 允许父子 Chart 共享值。

Subchart 特点:

  • Subchart 被视为独立 Chart,有自己的 values.yaml 和 templates/
  • 父 Chart 的模板不能直接访问子 Chart 的值
  • 子 Chart 的 values 通过父 Chart 的 ${子Chart名}.${key} 路径覆盖

Global Values:

# 父 Chart values.yaml
global:
  imageRegistry: "registry.internal.company.com"
  env: production

subchart1:
  enabled: true
# 子 Chart 模板引用全局值
image: "{{ .Values.global.imageRegistry }}/myapp:{{ .Values.image.tag }}"

Global Values 传递规则:

  • Global 值自动从父 Chart 传递到所有子 Chart
  • 子 Chart 可以覆盖自己的非 global 值
  • Global 值是跨 Chart 共享的首选方式
15 Helm 的 PostRenderer 机制是什么?

答案:

PostRenderer 是 Helm 在模板渲染后执行的命令管道,允许在提交到 K8s 前进行 YAML 后处理。

# 使用 kustomize 作为 PostRenderer
helm install myapp ./mychart \
  --post-renderer ./kustomize-wrapper.sh
```text

**典型用途:**

#!/bin/bash

kustomize-wrapper.sh

cat <&0 > /tmp/rendered.yaml kubectl kustomize /tmp/rendered


- 注入 Sidecar(如 Istio)
- 添加通用 Label/Annotation
- 密钥加密(SealedSecrets)
- 资源转换(Helm → Kustomize 混合使用)
16 Helm 的 Library Chart 是什么?用于什么场景?

答案:

Library Chart 是只包含模板辅助函数(_helpers.tpl)的 Chart,不安装任何资源。

Library Chart 定义:

# common/Chart.yaml
apiVersion: v2
name: common
type: library        # 标记为 Library Chart
version: 1.0.0
# common/templates/_helpers.tpl
{{- define "common.name" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" }}
{{- end }}

{{- define "common.labels" -}}
app.kubernetes.io/name: {{ include "common.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

{{- define "common.probe" -}}
initialDelaySeconds: {{ .delay | default 5 }}
periodSeconds: {{ .period | default 10 }}
{{- end }}
```text

**使用 Library Chart:**

mychart/Chart.yaml

dependencies:

  • name: common version: 1.0.0 repository: file://../common

mychart/templates/deployment.yaml

{{ include “common.labels” . }} livenessProbe: {{ include “common.probe” . | nindent 2 }}

17 Helm 如何管理大规模的 Release 文件?

答案:

Helm v3 将 Release 信息存储在 Kubernetes Secret 中,每次更新都会创建新的 Secret。

# 查看 Release Secret(Secret type 字段为 helm.sh/release.v1)
kubectl get secret -n mynamespace -l owner=helm

# 查看 Secret 中的 Release 数据(Secret 名称格式:sh.helm.release.v1.<release>.v<revision>)
kubectl get secret sh.helm.release.v1.myapp.v1 -o jsonpath='{.data.release}' | base64 -d | base64 -d | gunzip
```text

**Release 存储优化:**

限制历史版本数量

helm upgrade myapp ./mychart –history-max 5

手动清理历史

helm history myapp –max 10 helm delete myapp –keep-history # 保留 Release 记录

18 Helm 如何与 ArgoCD 集成?

答案:

ArgoCD 原生支持 Helm Chart 作为应用来源。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  source:
    repoURL: https://git.example.com/helm-charts
    path: mychart
    targetRevision: HEAD
    helm:
      valueFiles:
      - values.yaml
      - values-prod.yaml
      parameters:
      - name: image.tag
        value: v1.2.3
      releaseName: myapp
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
19 Helm Secrets 如何处理敏感信息?

答案:

Helm 本身不加密 values,需要结合外部工具处理敏感信息。

方案 1:Helm Secrets + SOPS

# secrets.yaml(加密文件)
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  password: ENC[AES256_GCM,data:encrypted-base64]
```bash

helm secrets install myapp ./mychart -f secrets.yaml


**方案 2:External Secrets Operator**

Chart 中引用 ExternalSecret

apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: myapp-secret spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: myapp-secret data:

  • secretKey: password remoteRef: key: /myapp/password

**方案 3:Sealed Secrets**

加密 Secret

kubeseal –format yaml < secret.yaml > sealed-secret.yaml

Chart 中包含 SealedSecret,Helm 安装后由 sealed-secrets controller 解密

20 Helm 的 Hooks 权重和删除策略如何配置?

答案:

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-upgrade-job
  annotations:
    "helm.sh/hook": pre-upgrade
    "helm.sh/hook-weight": "-5"  # 负数权重 = 更早执行
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: job
        image: busybox
        command: ["sh", "-c", "echo pre-upgrade check"]

删除策略说明:

策略行为
hook-succeededHook 执行成功后被删除
hook-failedHook 执行失败后被删除
before-hook-creation新 Hook 创建前删除旧的
默认保留 Hook 资源
21 Helm 如何限制 Chart 的最低 K8s 版本?

答案:

# Chart.yaml
apiVersion: v2
name: mychart
version: 1.0.0
kubeVersion: ">= 1.21.0-0"  # 最低 K8s 版本

版本约束语法(Go 语义版本,Masterminds/semver):

  • >= 1.21:版本大于等于 1.21
  • >= 1.21 < 1.25:版本范围
  • ~1.22>=1.22.0 <1.23.0(锁次版本,1.22.x 系列)
  • ^1.22>=1.22.0 <2.0.0(跨次版本与主版本,Go 语义)
22 Helm 的 Capabilities 对象如何使用?

答案:

Capabilities 对象用于根据集群能力条件渲染模板。

# 根据 K8s 版本选择 API 版本
{{- if .Capabilities.APIVersions.Has "apps/v1" }}
apiVersion: apps/v1
{{- else }}
apiVersion: extensions/v1beta1
{{- end }}

# 检查特定 CRD 是否存在
{{- if .Capabilities.APIVersions.Has "monitoring.coreos.com/v1" }}
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
{{- end }}

# 根据 K8s 版本选择特性
{{- if semverCompare ">=1.21-0" .Capabilities.KubeVersion.Version }}
topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
{{- end }}
23 Helm 如何自定义安装后的提示信息(NOTES.txt)?

答案:

# templates/NOTES.txt
Thank you for installing {{ .Chart.Name }}.

Your application is running at:
  http://{{ .Values.ingress.host }}

Get the admin password:
  kubectl get secret {{ .Release.Name }}-admin -o jsonpath="{.data.password}" | base64 --decode

To test the connection:
  helm test {{ .Release.Name }}
24 Helm 的 lookup 函数是什么?

答案:

lookup 函数在模板渲染时查询集群中的已有资源。

# 查询已有 ConfigMap
{{- $cm := lookup "v1" "ConfigMap" .Release.Namespace "myconfig" }}
{{- if $cm }}
configData: {{ $cm.data }}
{{- else }}
configData: {}
{{- end }}

# 查询 Secret 是否存在(避免覆盖已有密钥)
{{- $existingSecret := lookup "v1" "Secret" .Release.Namespace (printf "%s-db" .Release.Name) }}
{{- if not $existingSecret }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-db
data:
  password: {{ randAlphaNum 16 | b64enc }}
{{- end }}
25 Helm 的 fail 函数是什么?

答案:

fail 函数用于模板渲染时主动终止并输出错误信息。

{{- if and (.Values.ingress.enabled) (not .Values.ingress.host) }}
{{- fail "ingress.host is required when ingress is enabled" }}
{{- end }}

{{- if and (.Values.persistence.enabled) (not .Values.storageClass) }}
{{- fail "storageClass is required for persistent storage" }}
{{- end }}

# 版本兼容性检查
{{- if not (semverCompare ">=1.21-0" .Capabilities.KubeVersion.Version) }}
{{- fail "Kubernetes version must be >= 1.21" }}
{{- end }}
26 Helm 如何实现条件安装(Conditional Installation)?

答案:

# values.yaml
ingress:
  enabled: false
monitoring:
  enabled: true
serviceMonitor:
  enabled: "{{ .Values.monitoring.enabled }}"
# templates/ingress.yaml
{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
...
{{- end }}
# templates/servicemonitor.yaml
{{- if .Values.serviceMonitor.enabled }}
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
...
{{- end }}
27 Helm 的 template 命令和 install --dry-run 的区别?

答案:

维度helm templatehelm install --dry-run
访问 K8s API不访问访问(lookup 可用)
验证 Release 名称不验证验证是否已存在
输出控制台 YAML控制台 YAML
使用场景CI/CD 管道渲染开发调试
Capabilities固定默认值真实集群信息
28 Helm 如何处理复杂的多 Chart 部署?

答案:

方案 1:Helm Dependency(父子 Chart) 方案 2:Helmfile(多 Chart 编排) 方案 3:ArgoCD ApplicationSet(GitOps 方式)

Helmfile 示例:

# helmfile.yaml
repositories:
- name: bitnami
  url: https://charts.bitnami.com/bitnami

releases:
- name: postgresql
  namespace: database
  chart: bitnami/postgresql
  version: 12.x
  values:
  - values/postgresql.yaml

- name: myapp
  namespace: myapp
  chart: ./charts/myapp
  values:
  - values/myapp.yaml
  needs:
  - database/postgresql
```text

部署所有 Release

helmfile apply

查看差异

helmfile diff

29 Helm 的 --generate-name 和 --name-template 的作用?

答案:

# 自动生成 Release 名称
helm install --generate-name ./mychart
# Release: mychart-1712345678

# 使用模板生成名称
helm install --name-template "myapp-{{ .Chart.Version }}" ./mychart
# Release: myapp-1.0.0
```yaml
30 Helm Chart 生产环境最佳实践?

答案:

Chart 开发规范:

  • 所有可配置项暴露在 values.yaml 中,并有默认值
  • 提供 values.schema.json 校验用户输入
  • 使用 Library Chart 提取通用模板逻辑
  • 模板中不使用硬编码值(IP、端口等)
  • 使用 include 而非 template(支持作用域传递)

安全实践:

  • 不将敏感信息(密码、Token)硬编码在 values.yaml
  • 使用 Helm Secrets 或 External Secrets Operator 管理密钥
  • 启用 Chart 签名和验证
  • 设置 --history-max 限制 Release 数量

CI/CD 集成:

  • CI 中运行 helm linthelm template 验证
  • 使用 --dry-run 验证集群兼容性
  • 生产环境使用 --atomic 确保失败自动回滚
  • 使用 Helmfile 或 ArgoCD 管理多 Chart 部署

版本管理:

  • Chart version 遵循 SemVer(语义化版本)
  • appVersion 与应用版本保持一致
  • 重大变更时增加 Chart 主版本号
  • 使用 README.md 记录变更日志