2018-05-02-helm2 install

1. Helm用途

Helm把Kubernetes资源(比如deployments、services或 ingress等) 打包到一个chart中,而chart被保存到chart仓库。通过chart仓库可用来存储和分享chart。Helm使发布可配置,支持发布应用配置的版本管理,简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。

做为Kubernetes的一个包管理工具,用来管理charts——预先配置好的安装包资源,有点类似于Ubuntu的APT和CentOS中的yum。Helm具有如下功能:

  • 创建新的chart

  • chart打包成tgz格式

  • 上传chart到chart仓库或从仓库中下载chart

  • 在Kubernetes集群中安装或卸载chart

  • 管理用Helm安装的chart的发布周期

Helm有三个重要概念:

  • chart:包含了创建Kubernetes的一个应用实例的必要信息

  • config:包含了应用发布配置信息

  • release:是一个chart及其配置的一个运行实例

2. Helm组件

Helm基本架构如下: 架构图

Helm有以下两个组成部分:

Helm Client是用户命令行工具,其主要负责如下:

  • 本地chart开发

  • 仓库管理

  • 与Tiller sever交互

  • 发送预安装的chart

  • 查询release信息

  • 要求升级或卸载已存在的release

Tiller Server是一个部署在Kubernetes集群内部的server,其与Helm client、Kubernetes API server进行交互。

Tiller server主要负责如下:

  • 监听来自Helm client的请求

  • 通过chart及其配置构建一次发布

  • 安装chart到Kubernetes集群,并跟踪随后的发布

  • 通过与Kubernetes交互升级或卸载chart

简单的说,client管理charts,而server管理发布release。

3. 安装Helm

3.1 前提要求

  • Kubernetes1.5以上版本

  • 集群可访问到的镜像仓库

  • 执行helm命令的主机可以访问到kubernetes集群

3.2 安装步骤

首先需要安装helm客户端

方法1:需要能连外网

方法2: 我把helm 包和镜像上传到了网盘

然后安装helm服务端tiller

创建tiller的serviceaccount和clusterrolebinding

tiller的服务端是一个deployment,在kube-system namespace下,会去连接kube-api创建应用和删除,所以需要给他权限

安装server端,如果能连外网,直接helm init,会自动拉取镜像。不能的话,指定镜像,镜像文件在上面的网盘里

为应用程序设置serviceAccount:

3.3 检验版本

完成后查看pod状态和helm版本,容器中的为helm server端, 虚拟机的/usr/local/bin/helm为client

4. helm 使用

常用命令

查看源

查看chart

下载chart

部署应用 wordpress, 通过ali源文件

访问wordpress,使用node节点ip + nodeport, 192.168.1.181:30655

访问wordpress

删除应用

5. 建立自己的chart

创建一个自己的chart,看下文档结构,学习下如何使用

5.1 模板 template

template下包含应用所有的yaml文件模板,这个和openshift的template 有点类似,感觉openshift的使用更简便一些。 应用资源的类型不仅限于deployment 和service这些,k8s支持的都可以。

这是该应用的Deployment的yaml配置文件,其中的双大括号包扩起来的部分是Go template, template "misa86.name" 这类是在 _helpers.tpl 文件中定义的,如果不定义,将来文件名会是随意字符加chart名字。

其中的Values是在values.yaml文件中定义的,应用主要的参数在这边:

比如在Deployment.yaml中定义的容器镜像image: ":"其中的:

以上两个变量值是在create chart的时候自动生成的默认值。

将默认的镜像地址和tag改成自己的地址 registry.cn-hangzhou.aliyuncs.com/misa/nginx:1.13

5.2 检查配置和模板是否有效

当使用kubernetes部署应用的时候实际上将templates渲染成最终的kubernetes能够识别的yaml格式。

使用helm install --dry-run --debug 命令来验证chart配置。该输出中包含了模板的变量配置与最终渲染的yaml文件。 deployment service的名字前半截由两个随机的单词组成,随机数加chart名。 这名字也可以改成value方式,自己定义 如果配置等有问题此处会报错

5.3 部署到kubernetes

在misa86目录下执行下面的命令将应用部署到kubernetes集群上。

现在nginx已经部署到kubernetes集群上,本地执行提示中的命令在本地主机上访问到nginx实例。

5.4 查看部署的relaese

5.5 打包分享

我们可以修改Chart.yaml中的helm chart配置信息,然后使用下列命令将chart打包成一个压缩文件。

5.6 依赖

我们可以在charts 的目录 requirement.yaml 中定义应用所依赖的chart,例如定义对mariadb的依赖:

这功能还没屡明白

使用helm lint .命令可以检查依赖和模板配置是否正确。

5.7 http提供chart

我们在前面安装chart可以通过HTTP server的方式提供,如果不带 address 参数,那只能本机访问

把已安装的chart做server

指定目录做server

任意节点访问 192.168.1.181:80 可以看到安装的chart或者指定的chart库,点击链接即可以下载chart的压缩包。

chart-http

6. 注意事项

下面列举一些常见问题,和在解决这些问题时候的注意事项。

6.1 服务依赖管理

所有使用helm部署的应用中如果没有特别指定chart的名字都会生成一个随机的Release name,例如romping-frog、sexy-newton等,跟启动docker容器时候容器名字的命名规则相同,而真正的资源对象的名字是在YAML文件中定义的名字,我们成为App name,两者连接起来才是资源对象的实际名字:Release name-App name。

而使用helm chart部署的包含依赖关系的应用,都会使用同一套Release name,在配置YAML文件的时候一定要注意在做服务发现时需要配置的服务地址,如果使用环境变量的话,需要像下面这样配置。

6.2 解决本地chart依赖

在本地当前chart配置的目录下启动helm server,我们不指定任何参数,直接使用默认端口启动。

6.3 设置helm命令自动补全

为了方便helm命令的使用,helm提供了自动补全功能,如果使用zsh请执行:

参考文档

https://jimmysong.io/kubernetes-handbook/practice/helm.html http://dockone.io/article/2701

Last updated