享受helm
Helm是什么？
The package manager for Kubernetes
helm之于k8s就类似于yum之于centos、apt之于ubuntu、brew之于Mac的这种关系，简而言之，helm就是k8s的包管理工具。
为什么会有Helm
我们知道k8s有各种各样的资源，比如Deployment、Pod、Service等等，这些资源最终可以构成了一个应用，比如在k8s里面业务通常需要三个资源
-
Deployment
服务描述，比如：
Pod副本数据、服务镜像，资源限制等等
-
Service
将一组同一特性的Pod抽象聚合为一个服务
-
Ingress
将应用从k8s里面暴露出来
...
当然还可能需要定义其它资源比如ConfigMap等，每一种资源的定义都可以用一个YAML文件来描述，所以想要在k8s里面部署一个常规业务，你可能需要根据k8s的描述规则编写以上三种资源（当然也可以合并在一个文件里头）
- deployment.yaml
- service.yaml
- ingress.yaml
然后部署的时候逐一执行
kubectl apply deployment.yaml
...
随着业务的增加这样做的负担比较明显，而且容易出错，资源的编写也没有一定的规范，其实对于一个业务服务来讲，它需要哪些资源从一开始就应该是确定，比如fun-server需要Deployment、Service、Ingress这三种资源，那么这三种资源就描述了fun-server部署到k8s里面的形态，即这三个资源组合定义了k8s中的应用：fun-server。于是Helm应运而生，它定义了一个k8s应用的组成以及简化了应用的编写，并且定义了一套规范。
Helm的应用
我们来尝试一下，用Helm创建一个应用
➜ ~ helm create fun-server
Creating fun-server
看看有哪些文件
.
├── Chart.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
└── values.yaml
哇，这样我就不必从头编写一个k8s应用的资源了，毕竟它很多，很多，这个初始化可省了不少事，我们来看看里面有什么？
一个名词chart是描述k8s应用的资源集合，也被称为helm打包的格式，嗯，一个名词而已，helm与chart通常是一起出现的
Chart.yaml
apiVersion: v2
name: fun-server
description: A Helm chart for Kubernetes
...
很显然，有我们的包的版本号、包名、描述以及其它，重要的是templates文件夹，先来看一下deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "fun-server.fullname" . }}
labels:
{{- include "fun-server.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
...
我们看到在{{与}}是需要模板渲染的，而这些值我猜在values.yaml里面
# Default values for fun-server.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
repository: nginx
pullPolicy: IfNotPresent
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
...
果然如此，聪明如我, charts文件夹是空的，它是用来存在应用依赖的，我们来看一个样例elastic-stack
.
├── Chart.yaml
├── OWNERS
├── README.md
├── charts
│ ├── elasticsearch
│ ├── elasticsearch-curator
│ ├── elasticsearch-exporter
│ ├── filebeat
│ ├── fluent-bit
│ ├── fluentd
│ ├── fluentd-elasticsearch
│ ├── kibana
│ ├── logstash
│ └── nginx-ldapauth-proxy
├── requirements.lock
├── requirements.yaml
├── templates
│ ├── NOTES.txt
│ └── _helpers.tpl
└── values.yaml
比如我需要搭建一个ELK日志平台，可能需要elasticsearch、kibana、logstash等组件，这太有意思了，helm能描述一个依赖应用组，可以理解为先安装应用依赖，不存在就创建，依赖存在再部署应用本身，这比健康检查还好的地方在于getOrCreate的能力，
这太有想像力，这意味着，如果应用资源描述得当，比如我有100个应用，存在着层级依赖，最终通过root的应用包的安装即可完成整个应用的安装，so cool!
比如我要在k8s集群里面部署ELK, 本来我需要分别安装elasticsearch、kibana、logstash等组件, 然后再配置整合，不过现在一条命令就能搞定
helm install stable/elastic-stack --generate-name
so easy!
以上示例中我使用的是helm的v3版本，只是揭开了helm功能的冰山一角，就使用体验而言，helm是kubectl基本的功能封装加强版本，毕竟kubectl只是脚手架而已，so now, enjoy helm。
Refer:
