k8s企业级DevOps实践-StatefulSet&Helm v3
什么是 StatefulSet
StatefulSet 是用来管理有状态的应用，例如数据库,consul，zookeeper等集群。
- 通过
Deployment部署的应用，都是不需要存储数据，不需要记住状态且pod之间没有任何依赖关系，可以随意扩充副本，每个副本都是一样的，可替代的。 - 而像数据库、Redis、kafka、consul这类有状态的，则不能随意扩充副本。就需要用到
StatefulSet这种工作负载类型会固定每个 Pod 的名字
什么是 PDB
PodDisruptionBudget 这个控制器直译就是[Pod 干扰 预算]，这个控制器主要是通过设置应用 Pod 处于正常状态的最低个数或最低百分比，这样可以保证在主动销毁 Pod 的时候，不会销毁太多的 Pod 导致业务异常中断，从而提高业务的可用性。
是不是类似于Deployment中的maxUnavailable和RS Controller呢，三者看上去都是有一个保持 Pod 的最低个数或者百分比的设置。其实后两个并不能给你保证集群中始终有几个副本的，他们只是让实际副本数跟你的期望副本数尽快的一致，但这个过程中的副本数量并不关心。所以这个时候就要考虑使用 PDB 了，对那些Voluntary Disruption（自愿中断）做好Budgets（预算）。
Involuntary AND Voluntary
对 Voluntary Disruption 的情况，我们可以使用PDB做预算。哪些情况是 Involuntary Disruption，哪些又是 Voluntary Disruption 呢？
Involuntary Disruption：
- 服务器硬件故障或者内核崩溃导致节点宕了；
- 如果节点是 KVM，Xen 虚拟机，虚拟机被删了或者 KVM，Xen 崩了；
- 集群网络脑裂；
- 某个节点因为不合理的超配导致出现计算资源不足时，触发了 kubelet eviction； 这些都是 Kubernetes 不可控的情况，这些情况下不适用于PDB。
Voluntary Disruption：
- 删除 Deployment，RC，StatefulSet控制器
- 更新了 Pod 模版，触发 Pod 滚动更新
- 批量删除Pod
- 清空节点
- 下线一个节点
PDB 关键参数与注意事项
.spec.minAvailable表示发生自愿中断的过程中，要保证至少可用的Pods数或者比例.spec.maxUnavailable表示发生自愿中断的过程中，要保证最大不可用的Pods数或者比例 上面配置只能用来对应 Deployment，RS，RC，StatefulSet的Pods，推荐优先使用.spec.maxUnavailable。
注意：
- 同一个 PDB Object 中不能同时定义
.spec.minAvailable和.spec.maxUnavailable。 - 前面提到，应用滚动更新时Pod的delete和unavailable虽然也属于自愿中断，但是实际上滚动更新有自己的策略控制（marSurge 和 maxUnavailable），因此PDB不会干预这个过程。
- PDB 只能保证自愿中断时的副本数，比如 eviction pod过程中刚好满足
.spec.minAvailable或.spec.maxUnavailable，这时某个本来正常的Pod突然因为Node Down(非自愿中断)挂了，那么这个时候实际Pods数就比PDB中要求的少了，因此PDB不是万能的！ - 使用上，如果设置
.spec.minAvailable为 100% 或者.spec.maxUnavailable为 0%，意味着会完全阻止 eviction pods 的过程（ Deployment和StatefulSet的滚动更新除外 ）。
PDB for Zookeeper
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
namespace: baseservice
spec:
selector:
matchLabels:
app: zk
maxUnavailable: 1
# pod 干扰预算定义的示例，它们与带有 app: zk 标签的 pod 相匹配
# 上面的PDB选择的是一个规格为 3 的 StatefulSet，因为zk三节点集群中。最少需要保证两个节点可用zk集群才可用Service和DNS的关系
在kubernetes中,所有的Service和Pod都会被分配一条对应的DNS A记录( 通过域名解析到IP地址的记录 )
ClusterIP Service的DNS分配方式
ClusterIP模式的NormalService 来说,它的 A 记录的格式是: myservicename.mynamespace.svc.cluster.local 当你访问这条 A 记录的时候,它解析到的就是该Service的VIP地址
Headliness Service的DNS分配方式
ClusterIP=None的 HeadlessService 来说,它的 A 记录的格式也是: myservicename.mynamespace.svc.cluster.local 当你访问这条A记录的时候,它返回的是所有被代理的Pod的IP地址的集合.当然,如果你的客户端没办法解析这个集合的话,它可能会只会拿到第一个Pod的IP地址
ClusterIP Service被代理Pod的分配方式 对于ClusterIP模式的Service来说,它代理的Pod被自动分配的A记录的格式是: PodIP.mynamespace.pod.cluster.local这条记录指向Pod的IP地址
Headliness Service被代理Pod的分配方式
- 对Headless Service 来说,它代理的Pod被自动分配的A记录的格式是:
mypodname.myservicename.mynamespace.svc.cluster.local这条记录也指向Pod的IP地址 - 如果Pod本身声明了hostname和subdomain字段,那么这时候Pod的A记录就会变成:
podhostname.mysubdomain.mynamespace.svc.cluster.local
什么是 HeadLess
Normal和Headless对比
写法方面： 
工作方式对比
NormalService
工作方式是通过一个Cluster-ip 10.0.0.112:80 来反向代理 endpoints 列表中的 pod 地址
10.244.4.10:80 10.244.6.160:80 10.244.8.32:80
此时要访问apiA这个接口只需要访问到这个Cluster-ip，就可以实现对后端POD的负载均衡
HeadlessService
工作方式是并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了 selector。 如下图： 
此时要访问zookeeper这个集群，需要按照 <pod-name>.<service-name>.<namespace-name>..svc.cluster.local就可以访问到zk集群中指定pod，相当于给pod分配了一个可解析身份，非常适合用作StatefulSet类型工作负载中pod之间进行内部通信。
HeadLess的作用
简而言之Headless Service就是没头的Service。有啥用呢？很简单，有时候client想自己来决定使用哪个Real Server时可以通过查询DNS来获取Real Server的信息。Headless Service的对应的每一个Endpoints，即每一个Pod，都会有对应的DNS域名；这样Pod之间就可以互相访问。
Zookeeper容器化部署
编排PV持久化存储
参考文档:https://kubernetes.io/zh/docs/tutorials/stateful-application/zookeeper/
apiVersion: v1
kind: PersistentVolume
metadata:
name: k8s-pv-zk1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce #允许一个节点挂载
mountOptions:
- vers=3
- nolock,tcp,noresvport
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /zk/zk1
server: 71cc1489fb-kmn77.ap-southeast-1.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: k8s-pv-zk2
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce #允许一个节点挂载
mountOptions:
- vers=3
- nolock,tcp,noresvport
persistentVolumeReclaimPolicy: Retain #不清理, 保留 Volume（需要手动清理）
storageClassName: nfs
nfs:
path: /zk/zk2
server: 71cc1489fb-kmn77.ap-southeast-1.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: k8s-pv-zk3
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce #允许一个节点挂载
mountOptions:
- vers=3
- nolock,tcp,noresvport
persistentVolumeReclaimPolicy: Retain #不清理, 保留 Volume（需要手动清理）
storageClassName: nfs
nfs:
path: /zk/zk3
server: 71cc1489fb-kmn77.ap-southeast-1.nas.aliyuncs.com应用：
[root@node002 Statefulset]# kubectl apply -f zk-pv.yaml
[root@node002 Statefulset]# kubectl get pv | grep Available
k8s-pv-zk1 5Gi RWO Retain Available nfs 23s
k8s-pv-zk2 5Gi RWO Retain Available nfs 23s
k8s-pv-zk3 5Gi RWO Retain Available nfs 23s部署Service & PDB
apiVersion: v1
kind: Service
metadata:
name: zk-headless
namespace: baseservice
labels:
app: zk
spec:
ports:
- port: 2888
name: server
- port: 3888
name: leader-election
clusterIP: None #headless模式，用于zk p2p内部选举
selector:
app: zk
---
apiVersion: v1
kind: Service
metadata:
name: zk-service
namespace: baseservice
labels:
app: zk
spec:
ports:
- port: 2181
name: client
selector:
app: zk
---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
namespace: baseservice
spec:
selector:
matchLabels:
app: zk
maxUnavailable: 1 #自发干扰时最多允许一个节点宕机应用：
[root@node002 Statefulset]# kubectl apply -f svc.yaml
[root@node002 Statefulset]# kubectl get svc -n baseservice | grep zk
zk-headless ClusterIP None <none> 2888/TCP,3888/TCP 41s
zk-service ClusterIP 10.0.0.140 <none> 2181/TCP 41s
[root@node002 Statefulset]# kubectl get pdb -n baseservice
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
zk-pdb N/A 1 0 64s部署StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: zk
namespace: baseservice
spec:
selector:
matchLabels:
app: zk
serviceName: zk-headless #必须关联到一个无头服务商
replicas: 3
updateStrategy:
type: RollingUpdate #更新策略: 滚动更新
podManagementPolicy: OrderedReady #串行启动pod即一个一个启动
template:
metadata:
labels:
app: zk
spec:
containers:
- name: kubernetes-zookeeper
imagePullPolicy: IfNotPresent #拉取策略
image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
resources: #资源限制
requests:
memory: "500Mi"
cpu: "0.5"
ports:
- containerPort: 2181
name: client
- containerPort: 2888
name: server
- containerPort: 3888
name: leader-election
command:
- sh
- -c
- "start-zookeeper \
--servers=3 \
--data_dir=/var/lib/zookeeper/data \
--data_log_dir=/var/lib/zookeeper/data/log \
--conf_dir=/opt/zookeeper/conf \
--client_port=2181 \
--election_port=3888 \
--server_port=2888 \
--tick_time=2000 \
--init_limit=10 \
--sync_limit=5 \
--heap=512M \
--max_client_cnxns=60 \
--snap_retain_count=3 \
--purge_interval=12 \
--max_session_timeout=40000 \
--min_session_timeout=4000 \
--log_level=INFO"
readinessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 10
timeoutSeconds: 5
livenessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 10
timeoutSeconds: 5
volumeMounts:
- name: datadir
mountPath: /var/lib/zookeeper
volumeClaimTemplates:
- metadata:
name: datadir
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs" #一定要写，如果pv中存在
resources:
requests:
storage: 5Gi应用：
[root@node002 Statefulset]# kubectl apply -f zk.yaml
[root@node002 Statefulset]# kubectl -n baseservice get pod | grep zk
zk-0 1/1 Running 0 7m30s
zk-1 1/1 Running 0 6m29s
zk-2 1/1 Running 0 3m54s
[root@node002 Statefulset]# kubectl -n baseservice get pv | grep zk
k8s-pv-zk1 5Gi RWO Retain Bound baseservice/datadir-zk-0 nfs 7m19s
k8s-pv-zk2 5Gi RWO Retain Bound baseservice/datadir-zk-1 nfs 7m19s
k8s-pv-zk3 5Gi RWO Retain Bound baseservice/datadir-zk-2 nfs 7m19s
[root@node002 Statefulset]# kubectl -n baseservice get pvc | grep zk
datadir-zk-0 Bound k8s-pv-zk1 5Gi RWO nfs 7m54s
datadir-zk-1 Bound k8s-pv-zk2 5Gi RWO nfs 6m53s
datadir-zk-2 Bound k8s-pv-zk3 5Gi RWO nfs 6m35s
#查看配置
[root@node002 Statefulset]# kubectl exec -n baseservice zk-0 -- cat /opt/zookeeper/conf/zoo.cfg
#This file was autogenerated DO NOT EDIT
clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/data/log
tickTime=2000
initLimit=10
syncLimit=5
maxClientCnxns=60
minSessionTimeout=4000
maxSessionTimeout=40000
autopurge.snapRetainCount=3
autopurge.purgeInteval=12
server.1=zk-0.zk-headless.baseservice.svc.cluster.local:2888:3888
server.2=zk-1.zk-headless.baseservice.svc.cluster.local:2888:3888
server.3=zk-2.zk-headless.baseservice.svc.cluster.local:2888:3888
#集群状态
[root@node002 Statefulset]# kubectl exec -n baseservice zk-0 zkServer.sh status
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
ZooKeeper JMX enabled by default
Using config: /usr/bin/../etc/zookeeper/zoo.cfg
Mode: follower
[root@node002 Statefulset]# kubectl exec -n baseservice zk-1 zkServer.sh status
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
ZooKeeper JMX enabled by default
Using config: /usr/bin/../etc/zookeeper/zoo.cfg
Mode: leader
[root@node002 Statefulset]# kubectl exec -n baseservice zk-2 zkServer.sh status
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
ZooKeeper JMX enabled by default
Using config: /usr/bin/../etc/zookeeper/zoo.cfg
Mode: follower
StatefulSet总结
上面使用Statefulset控制器搭建了Zookeeper分布式集群，了解到Statefulset具备以下特点：
- 稳定且唯一的网络标识符
- 稳定且持久的存储
- 有序，平滑的部署和扩展
- 有序，平滑的删除和终止
- 有序的滚动更新 且了解到Statefulset包含三个组件：
headless service、StatefulSet，volumeClaimTemplate headless service：确保解析名称直达后端podvolumeClaimTemplate：卷申请模板，每创建一个pod时，自动申请一个pvc，从而请求绑定pvStatefulSet：有状态服务的控制器
什么是Helm
Helm 是一个 Kubernetes 的包管理工具，类似 Linux 的包管理器，如RedHat系的yum、Debian的apt，可以很方便的将之前打包好的 yaml 文件部署到 Kubernetes 上。Helm主要解决以下问题：
- 把yaml作为一个整体管理。
- 实现yaml的高效复用。
- 实现应用级别的版本管理。
当前 Helm 已经升级到V3版本，相比于V2版本主要变化如下：
- 最明显的变化是删除了 Tiller 。
- Release 名称可以在不同命名空间重用。
- 支持将 Chart 推送至 Docker 镜像仓库中。
- 使用 JSONSchema 验证 chart values。
Helm是官方提供类似于YUM的包管理，是部署环境的流程封装，Helm有三个重要的概念：chart、release和Repository
chart是创建一个应用的信息集合，包括各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等。可以将chart想象成apt、yum中的软件安装包。release是chart的运行实例，代表一个正在运行的应用。当chart被安装到Kubernetes集群，就生成一个release。chart能多次安装到同一个集群，每次安装都是一个release[根据chart赋值不同，完全可以部署出多个release出来]。Repository用于发布和存储 Chart 的存储库。
Helm V2 与 Helm V3 的架构图对比： 
在V2版本的架构中，Tiller在Kubernetes集群中，Helm Client发请求给Tiller需要经过RBAC认证。而在V3版本是Helm通过kubeconfig连接kube-apiserver，避免了使用者去配置RBAC权限。
Helm发布与传统发布对比： 
Helm是 Kubernetes 的包管理器，它将应用程序的所有资源和部署信息(*.yaml)组合到单个部署包中。从而实现应用快速安装到Kubernetes集群中。（通过Yaml的配置模板，将需要修改的内容变为属性值）
安装Helm v3
安装Helm V3版本非常简单，只需要下载Helm的二进制文件，并复制到 Kubernetes 主节点的 /usr/bin 目录即可。
Helm下载地址: https://get.helm.sh/helm-v3.4.2-linux-amd64.tar.gz
[root@node001 ~]# wget https://get.helm.sh/helm-v3.4.2-linux-amd64.tar.gz
--2022-02-09 16:16:34-- https://get.helm.sh/helm-v3.4.2-linux-amd64.tar.gz
Resolving get.helm.sh (get.helm.sh)... 152.199.39.108, 2606:2800:247:1cb7:261b:1f9c:2074:3c
Connecting to get.helm.sh (get.helm.sh)|152.199.39.108|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13317454 (13M) [application/x-tar]
Saving to: ‘helm-v3.4.2-linux-amd64.tar.gz’
100%[===============================================================================================================>] 13,317,454 --.-K/s in 0.08s
2022-02-09 16:16:35 (151 MB/s) - ‘helm-v3.4.2-linux-amd64.tar.gz’ saved [13317454/13317454]
[root@node001 ~]# tar -xf helm-v3.4.2-linux-amd64.tar.gz
[root@node001 ~]# cp linux-amd64/helm /usr/local/bin/
[root@node001 ~]# helm version
version.BuildInfo{Version:"v3.4.2", GitCommit:"23dd3af5e19a02d4f4baa5b2f242645a1a3af629", GitTreeState:"clean", GoVersion:"go1.14.13"}
## Helm命令补全
[root@node001 ~]# yum install -y bash-completion
Loaded plugins: fastestmirror, langpacks, update-motd
Loading mirror speeds from cached hostfile
base | 3.1 kB 00:00:00
docker-ce-stable | 3.5 kB 00:00:00
epel | 4.7 kB 00:00:00
extras | 2.5 kB 00:00:00
plus | 2.9 kB 00:00:00
updates | 2.9 kB 00:00:00
updates/2.1903/x86_64/primary_db | 10 MB 00:00:00
Package 1:bash-completion-2.1-8.1.al7.noarch already installed and latest version
Nothing to do
[root@node001 ~]# source /usr/share/bash-completion/bash_completion
[root@node001 ~]# source <(helm completion bash)
[root@node001 ~]# echo "source <(helm completion bash)" >> ~/.bashrc
[root@node001 ~]# helm ver<tab>Helm常用命令
| 命令 | 描述 |
|---|---|
| create | 创建一个chart并指定名字 |
| dependency | 管理chart依赖 |
| get | 下载一个release。可用子命令：all、hooks、manifest、notes、values |
| history | 获取release历史 |
| install | 安装一个chart |
| list | 列出release |
| package | 将chart目录打包到chart存档文件中 |
| pull | 从远程仓库中下载chart并解压到本地 # helm pull stable/mysql --untar |
| repo | 添加，列出，移除，更新和索引chart仓库。可用子命令：add、index、list、remove、update |
| rollback | 从之前版本回滚 |
| search | 根据关键字搜索chart。可用子命令：hub、repo |
| show | 查看chart详细信息。可用子命令：all、chart、readme、values |
| status | 显示已命名版本的状态 |
| template | 本地呈现模板 |
| uninstall | 卸载一个release |
| upgrade | 更新一个release |
| version | 查看helm客户端版本 |
Helm-Chart模板
Helm最核心的就是模板，即模板化的K8S manifests文件。
它本质上就是一个Go的template模板。Helm在Go template模板的基础上，还会增加很多东西。如一些自定义的元数据信息、扩展的库以及一些类似于编程形式的工作流，例如条件语句、管道等等。这些东西都会使得我们的模板变得更加丰富。
模板
有了模板，我们怎么把我们自定义的配置融入进去呢？用的就是这个values文件。这两部分内容其实就是chart的核心功能。
[root@node001 helm]# helm create nginx
Creating nginx
[root@node001 helm]# tree nginx/
nginx/
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yamlChart.yaml用于描述这个 Chart的基本信息，包括名字、描述信息以及版本等。values.yaml用于存储 templates 目录中模板文件中用到变量的值。Templates目录里面存放所有yaml模板文件。charts目录里存放这个chart依赖的所有子chart。NOTES.txt用于介绍Chart帮助信息， helm install 部署后展示给用户。例如：如何使用这个 Chart、列出缺省的设置等。_helpers.tpl放置模板助手的地方，可以在整个 chart 中重复使用
接下来尝试部署nginx应用，熟悉模板使用，先把templates 目录下面所有文件全部删除掉，这里我们自己来创建模板文件：
# kubectl create deployment --image=nginx web --dry-run -o yaml > templates/deployment.yaml
# kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > templates/service.yaml
[root@node001 helm]# rm -rf mychart/templates/*
[root@node001 helm]# cd nginx/templates
[root@node001 templates]# ls
deployment.yaml service.yaml
[root@node001 templates]# cat *
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- image: nginx
name: nginx
apiVersion: v1
kind: Service
metadata:
labels:
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web实际上，这已经是一个可安装的Chart包了，通过 helm install命令来进行安装：
# helm install web nginx
NAME: web
LAST DEPLOYED: Fri Feb 11 15:35:54 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None这样部署，其实与直接apply没什么两样。
然后使用如下命令可以看到实际的模板被渲染过后的资源文件：
# helm get manifest web可以看到，这与刚开始写的内容是一样的，包括名字、镜像等，我们希望能在一个地方统一定义这些会经常变换的字段，这就需要用到Chart的模板了。
# vi templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
name: {{ .Chart.Name }}
app: {{ .Release.Name }}
name: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.label }}
template:
metadata:
labels:
app: {{ .Values.label }}
spec:
containers:
- image: {{ .Values.image }}:{{ .Values.imageTag }}
name: {{ .Release.Name }}
# vi templates/service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
name: {{ .Chart.Name }}
app: {{ .Release.Name }}
name: {{ .Release.Name }}
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: {{ .Values.label }}
# vi values.yaml
replicas: 2
image: nginx
imageTag: 1.17
label: nginx
#尝试渲染
[root@node001 nginx]# helm install web --dry-run ./
NAME: web
LAST DEPLOYED: Fri Feb 11 16:04:18 2022
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
HOOKS:
MANIFEST:
---
# Source: nginx/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
name: nginx
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
---
# Source: nginx/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
name: nginx
app: web
name: web
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.17
name: web
这个deployment就是一个Go template的模板，这里定义的Release模板对象属于Helm内置的一种对象，是从values文件中读取出来的。这样一来，我们可以将需要变化的地方都定义变量。
调试
Helm也提供了--dry-run --debug调试参数，帮助你验证模板正确性。在执行helm install时候带上这两个参数就可以把对应的values值和渲染的资源清单打印出来，而不会真正的去部署一个release。
比如我们来调试上面创建的 chart 包：
# helm install web2 --dry-run /root/mychart内置对象
刚刚我们使用 {{.Release.Name}}将 release 的名称插入到模板中。这里的 Release 就是 Helm 的内置对象，下面是一些常用的内置对象：
| Release.Name | release 名称 |
|---|---|
| Release.Name | release 名称 |
| Release.Namespace | release 命名空间 |
| Release.Service | release 服务的名称 |
| Release.Revision | release 修订版本号，从1开始累加 |
参考文档: https://helm.sh/zh/docs/chart_template_guide/builtin_objects/
Values
Values对象是为Chart模板提供值，这个对象的值有4个来源：
- chart 包中的
values.yaml文件 - 父 chart 包的
values.yaml文件 - 通过
helm install或者helm upgrade的-f或者--values参数传入的自定义的 yaml 文件 - 通过
--set参数传入的值
chart 的 values.yaml 提供的值可以被用户提供的 values 文件覆盖，而该文件同样可以被 --set提供的参数所覆盖。
上面的例子中我们重新编辑了 values.yaml 文件，将默认的值全部清空，然后分别添加副本数、镜像名称、镜像版本、标签等
# vi values.yaml
replicas: 2
image: nginx
imageTag: 1.17
label: nginx且values文件也可以包含结构化内容，例如：
# cat values.yaml
...
label:
project: ms
app: nginx
...
# cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
project: {{ .Values.label.project }}
app: {{ .Values.label.app }}
template:
metadata:
labels:
project: {{ .Values.label.project }}
app: {{ .Values.label.app }}
spec:
containers:
- image: {{ .Values.image }}:{{ .Values.imageTag }}
name: nginx参考文档: https://helm.sh/zh/docs/chart_template_guide/values_files/
管道与函数
前面讲的模块，其实就是将值传给模板引擎进行渲染，模板引擎还支持对拿到数据进行二次处理。 例如从.Values中读取的值变成字符串，可以使用quote函数实现：
# vi templates/deployment.yaml
app: {{ quote .Values.label.app }}
# helm install --dry-run web ../mychart/
project: ms
app: "nginx"quote .Values.label.app 将后面的值作为参数传递给quote函数。
模板函数调用语法为：functionName arg1 arg2…
另外还会经常使用一个default函数，该函数允许在模板中指定默认值，以防止该值被忽略掉。 例如忘记定义，执行helm install 会因为缺少字段无法创建资源，这时就可以定义一个默认值。
# cat values.yaml
replicas: 2
# cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
- name: {{ .Values.name | default "nginx" }}其他函数： 指定长度缩进：{{ .Values.resources | indent 12 }} 转大写：{{ upper .Values.resources }} 首字母大写：{{ title .Values.resources }}
参考文档:
- https://helm.sh/zh/docs/chart_template_guide/functions_and_pipelines/
- https://helm.sh/zh/docs/chart_template_guide/function_list/
流程控制
if/else
流程控制是为模板提供了一种能力，满足更复杂的数据逻辑处理。 Helm模板语言提供以下流程控制语句：
- if/else 条件块
- with 指定范围
- range 循环块
- if
if/else块是用于在模板中有条件地包含文本块的方法，条件块的基本结构如下：
{{ if PIPELINE }}
# Do something
{{ else if OTHER PIPELINE }}
# Do something else
{{ else }}
# Default case
{{ end }}示例：
# cat values.yaml
devops: k8
# cat templates/deployment.yaml
...
template:
metadata:
labels:
app: nginx
{{ if eq .Values.devops "k8s" }}
devops: 123
{{ else }}
devops: 456
{{ end }}在上面条件语句使用了eq运算符判断是否相等，除此之外，还支持ne、 lt、 gt、 and、 or等运算符。
通过模板引擎来渲染一下，会得到如下结果：
# helm install --dry-run web ../mychart/
...
labels:
app: nginx
devops: 456上面渲染出来会有多余的空行，这是因为当模板引擎运行时，会将控制指令删除，所有之前占的位置也就空白了，需要使用{{- if …}} 的方式消除此空行：
# cat templates/deploymemt.yaml
...
env:
{{- if eq .Values.env.hello "world" }}
- name: hello
value: 123
{{- end }}现在是不是没有多余的空格了，如果使用-}}需谨慎，比如上面模板文件中：
# cat templates/deploymemt.yaml
...
env:
{{- if eq .Values.env.hello "world" -}}
- hello: true
{{- end }}这会渲染成：
env:- hello: true因为-}}它删除了双方的换行符。
条件判断就是判断条件是否为真，如果值为以下几种情况则为false：
- 一个布尔类型的
假 - 一个数字
零 - 一个
空的字符串 - 一个
nil（空或null） - 一个空的集合（
map、slice、tuple、dict、array）
例如，判断一个空的数组
# cat values.yaml
resources: {}
# limits:
# cpu: 100m
# memory: 128Mi
# requests:
# cpu: 100m
# memory: 128Mi
# cat templates/deploymemt.yaml
...
spec:
containers:
- image: nginx:1.16
name: nginx
{{- if .Values.resources }}
resources:
{{ toYaml .Values.resources | indent 10 }}
{{- end }}例如，判断一个布尔值
# cat values.yaml
service:
type: ClusterIP
port: 80
ingress:
enabled: true
host: example.ctnrs.com
# cat templates/ingress.yaml
{{- if .Values.ingress.enabled -}}
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: {{ .Release.Name }}-ingress
spec:
rules:
- host: {{ .Values.ingress.host }}
http:
paths:
- path: /
backend:
serviceName: {{ .Release.Name }}
servicePort: {{ .Values.service.port }}
{{ end }}with
with: 控制变量作用域。 还记得之前我们的 {{.Release.xxx}}或者 {{.Values.xxx}}吗？其中的 .就是表示对当前范围的引用， .Values就是告诉模板在当前范围中查找 Values对象的值。而 with语句就可以来控制变量的作用域范围，其语法和一个简单的 if语句比较类似：
{{ with PIPELINE }}
# restricted scope
{{ end }}with语句可以允许将当前范围 .设置为特定的对象，比如我们前面一直使用的 .Values.label，我们可以使用 with来将 .范围指向 .Values.label:
# cat values.yaml
...
replicas: 3
label:
project: ms
app: nginx
# cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
{{- with .Values.nodeSelector }}
nodeSelector:
team: {{ .team }}
gpu: {{ .gpu }}
{{- end }}
containers:
- image: nginx:1.16
name: nginx优化后：
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}上面增加了一个{{- with .Values.label }} xxx {{- end }}的一个块，这样的话就可以在当前的块里面直接引用 .team和 .gpu了。
with是一个循环构造。使用.Values.nodeSelector中的值：将其转换为Yaml。toYaml之后的点是循环中.Values.nodeSelector的当前值
range
在Helm模板语言中，使用 range关键字来进行循环操作, values.yaml文件中添加上一个变量列表:
# cat values.yaml
test:
- 1
- 2
- 3循环打印该列表:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}
data:
test: |
{{- range .Values.test }}
{{ . }}
{{- end }}
# helm install web --dry-run .
...
# Source: nginx/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: web
data:
test: |
1
2
3
...参考文档: https://helm.sh/zh/docs/chart_template_guide/control_structures/
变量
变量，在模板中，使用变量的场合不多，但我们将看到如何使用它来简化代码，并更好地利用with和range。 问题1：获取列表键值
# cat ../values.yaml
env:
NAME: "gateway"
JAVA_OPTS: "-Xmx1G"
# cat deployment.yaml
...
env:
{{- range $k, $v := .Values.env }}
- name: {{ $k }}
value: {{ $v | quote }}
{{- end }}渲染结果如下:
env:
- name: JAVA_OPTS
value: "-Xmx1G"
- name: NAME
value: "gateway"上面在 range循环中使用 $key和 $value两个变量来接收后面列表循环的键和值。
问题2：with中不能使用内置对象 with语句块内不能再 .Release.Name对象，否则报错。我们可以将该对象赋值给一个变量可以来解决这个问题:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
spec:
replicas: {{ .Values.replicas }}
template:
metadata:
labels:
project: {{ .Values.label.project }}
app: {{ quote .Values.label.app }}
{{- with .Values.label }}
project: {{ .project }}
app: {{ .app }}
release: {{ .Release.Name }}
{{- end }}上面会出错
{{- $releaseName := .Release.Name -}}
{{- with .Values.label }}
project: {{ .project }}
app: {{ .app }}
release: {{ $releaseName }}
# 或者可以使用$符号,引入全局命名空间
release: {{ $.Release.Name }}
{{- end }}可以看到在 with语句上面增加了一句 {{-$releaseName:=.Release.Name-}}，其中 $releaseName就是后面的对象的一个引用变量，它的形式就是 $name，赋值操作使用 :=，这样 with语句块内部的 $releaseName变量仍然指向的是 .Release.Name
参考文档: https://helm.sh/zh/docs/chart_template_guide/variables/
命名模板
命名模板: 使用define定义，template引入，在templates目录中默认下划线_开头的文件为公共模板_helpers.tpl
# cat _helpers.tpl
{{- define "demo.fullname" -}}
{{- .Chart.Name -}}-{{ .Release.Name }}
{{- end -}}
# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ template "demo.fullname" . }}
...template指令是将一个模板包含在另一个模板中的方法。但是，template函数不能用于Go模板管道。为了解决该问题，增加include功能。
# cat _helpers.tpl
{{- define "demo.labels" -}}
app: {{ template "demo.fullname" . }}
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
release: "{{ .Release.Name }}"
{{- end -}}
# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "demo.fullname" . }}
labels:
{{- include "demo.labels" . | nindent 4 }}
...上面包含一个名为 demo.labels 的模板，然后将值 . 传递给模板，最后将该模板的输出传递给 nindent 函数。
参考文档: https://helm.sh/zh/docs/chart_template_guide/named_templates/
如何开发自己的Chart
- 先创建模板
helm create demo - 修改
Chart.yaml，Values.yaml，添加常用的变量 - 在templates目录下创建部署镜像所需要的yaml文件，并变量引用yaml里经常变动的字段