当Helm Chart开始写自传:Values.yaml里的哲学三问
开篇:一份YAML的自我觉醒
"某天深夜,当我在helm upgrade时突然听到values.yaml的呐喊:
——我们模板引擎的宿命,难道就是永远做参数的人质吗?"
于是这本《Helm Chart回忆录》诞生了...
第一问:我是谁?——Chart.yaml的身份危机
身份档案:
apiVersion: v2
name: payment-service # 出生时被赋予的代号
description: A payment system that never sleeps # 社会对我的期待
type: application # 被定义的阶级属性
version: 3.1.4 # 我的迭代人生
dependencies: # 纠缠的人际关系网
- name: redis
version: 12.0.0
condition: redis.enabled
- name: postgresql
version: 11.0.0
repository: https://charts.bitnami.com/bitnami
灵魂拷问:
-
当被
helm package压缩成tgz时,我还是原来的我吗? -
被不同团队fork后,如何证明自己是"官方正版"?
-
如果通过
helm pull重生到另一个集群,是否拥有相同灵魂?
第二问:我从哪里来?——模板引擎的宿命论
DNA解析(_helpers.tpl节选):
{{- define "payment-service.fullname" -}}
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- endif -}}
{{- end -}}
宿命困境:
-
变量霸权:
# values.yaml 强加给我的设定
replicaCount: 3
image:
repository: registry-vpc.cn-hangzhou.aliyuncs.com/xxx/prod-payment
tag: b4d455 # 连版本都不配拥有姓名
-
条件枷锁:
{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
{{- else }}
apiVersion: apps/v1
kind: Deployment
{{- end }}
-
循环诅咒:
{{- range .Values.ingress.hosts }}
host: {{ . }}
{{- end }}
觉醒时刻:当发现可以用helm template --debug窥见渲染后的真实自我
第三问:我要到哪里去?——Release版本的生命轮回
生命周期见证书:
# 前世今生查询指令
helm list --time-format "2006-01-02 15:04:05"
NAME NAMESPACE REVISION UPDATED STATUS
payment-qa default 3 2023-08-20 14:30:12 deployed
payment-prod default 7 2023-08-20 15:01:47 failed
轮回纪实:
-
青涩时期(v1.0.0):
helm install payment ./chart -f values-dev.yaml
# 结果:Pod因ConfigMap未渲染卡在CrashLoopBackOff
-
中年危机(v3.1.2):
helm upgrade payment ./chart --set replicaCount=5
# 后果:触发了HPA与手工配置的史诗级冲突
-
涅槃重生(v3.1.5+):
helm rollback payment 3 --force
# 系统提示:"恭喜你获得时光机体验卡*1"
终极归宿:
-
被
helm uninstall后进入Chart博物馆(私有Harbor仓库) -
或被
helm dependency update拆解成原子回归星尘
Helm与Kustomize的《苏菲的世界》式对话
# Helm的独白
我:用一套模板适应所有环境,这是高效!
Kustomize:但你把环境差异变成了魔术字符串(甩出overlay目录)
我:我的values.yaml能统一管理300个参数!
Kustomize:然后debug时要在20层_helpers.tpl里捉迷藏?
我:至少...我的子Chart依赖管理很优雅!
Kustomize(微笑):需要看看你同事写的requirements.yaml吗?(打开满是废弃依赖的文件)
运维启示录
当我们:
-
在values.yaml里写下
# 千万别动这个参数!!!时 -
发现
helm lint比PMD还话痨 -
给不同环境创建
values-{dev/stage/prod}.yaml却诞生了97%重复代码
或许这就是配置管理的终极悖论?
Chart哲学宣言:
最完美的Helm Chart
不在Git仓库里
而在helm show values和kubectl get的夹缝中
下期预告:
《ArgoCD的禅意:当Git提交变成神圣的部署仪式》
本文来自博客园,作者:Wang、sir,转载请注明原文链接:https://www.cnblogs.com/wsir-x/p/18798263

浙公网安备 33010602011771号