享受helm

Helm是什么?

The package manager for Kubernetes

helm之于k8s就类似于yum之于centos、apt之于ubuntu、brew之于Mac的这种关系,简而言之,helm就是k8s的包管理工具。

为什么会有Helm

我们知道k8s有各种各样的资源,比如Deployment、Pod、Service等等,这些资源最终可以构成了一个应用,比如在k8s里面业务通常需要三个资源 1. Deployment

服务描述,比如:

Pod副本数据、服务镜像,资源限制等等

  1. Service

    将一组同一特性的Pod抽象聚合为一个服务

  2. 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日志平台,可能需要elasticsearchkibanalogstash等组件,这太有意思了,helm能描述一个依赖应用组,可以理解为先安装应用依赖,不存在就创建,依赖存在再部署应用本身,这比健康检查还好的地方在于getOrCreate的能力,

这太有想像力,这意味着,如果应用资源描述得当,比如我有100个应用,存在着层级依赖,最终通过root的应用包的安装即可完成整个应用的安装,so cool!

比如我要在k8s集群里面部署ELK, 本来我需要分别安装elasticsearchkibanalogstash等组件, 然后再配置整合,不过现在一条命令就能搞定

helm install stable/elastic-stack --generate-name

so easy! 以上示例中我使用的是helm的v3版本,只是揭开了helm功能的冰山一角,就使用体验而言,helm是kubectl基本的功能封装加强版本,毕竟kubectl只是脚手架而已,so now, enjoy hlem。

Refer:

相关

comments powered by Disqus