享受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: