10 应用管理:初识 Helm 整体概览 上节,我们已经学习了如何通过编写配置文件的方式部署项目。而在实际生产环境中,项目所包含组件可能不止 3 个,并且可能项目数会很多,如果每个项目的发布,更新等都通过手动去编写配置文件的方式,实在不利于管理。
并且,当线上出现个别组件升级回滚之类的操作,如果组件之间有相关版本依赖等情况,那事情会变得复杂的多。我们需要有更简单的机制来辅助我们完成这些事情。
Helm 介绍 Helm 是构建于 K8S 之上的包管理器,可与我们平时接触到的 Yum
,APT
,Homebrew
或者 Pip
等包管理器相类比。
使用 Helm 可简化包分发,安装,版本管理等操作流程。同时它也是 CNCF 孵化项目。
Helm 安装 Helm 是 C/S 架构,主要分为客户端 helm
和服务端 Tiller
。安装时可直接在 Helm 仓库的 Release 页面 下载所需二进制文件或者源码包。
由于当前项目的二进制文件存储已切换为 GCS,我已经为国内用户准备了最新版本的二进制包,可通过以下链接进行下载。
1 链接: https://pan.baidu.com/s/1n1zj3rlv2NyfiA6kRGrHfg 提取码: 5huw
下载后对文件进行解压,我这里以 Linux amd64 为例。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ➜ /tmp tar -zxvf helm-v2.11.0-linux-amd64.tar.gz linux-amd64/ linux-amd64/tiller linux-amd64/README.md linux-amd64/helm linux-amd64/LICENSE ➜ /tmp tree linux-amd64 linux-amd64 ├── helm ├── LICENSE ├── README.md └── tiller 0 directories, 4 files
解压完成后,可看到其中包含 helm
和 tiller
二进制文件。
客户端 helm helm
是个二进制文件,直接将它移动至 /usr/bin
目录下即可。
1 ➜ /tmp sudo mv linux-amd64/helm /usr/bin/helm
这时候便可直接通过 helm
命令使用了。比如,我们验证当前使用的版本。
1 2 3 4 5 ➜ /tmp helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"} Error: Get http://localhost:8080/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: dial tcp 127.0.0.1:8080: connect: connection refused
可以看到上面有明显的报错,并且很像 kubectl
未正确配置时的错误。这是因为 helm
默认会去读取 $HOME/.kube/config
的配置文件,用于正确的连接至目标集群。
当我们正确的配置好 $HOME/.kube/config
文件时,再次执行:
1 2 3 4 5 ➜ /tmp helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"} Error: could not find tiller
这次报错是因为找不到服务端 Tiller
,接下来我们部署服务端。
服务端 Tiller 以下讨论中,前提都是 $HOME/.kube/config
已正确配置,并且 kebectl
有操作集群的权限。
本地安装 刚才我们解压的文件中,还有一个二进制文件 tiller
。我们可以直接执行它,用于在本地启动服务。
1 2 3 4 5 6 7 8 9 10 11 ➜ /tmp ./linux-amd64/tiller [main] 2018/11/18 23:47:10 Starting Tiller v2.11.0 (tls=false) [main] 2018/11/18 23:47:10 GRPC listening on :44134 [main] 2018/11/18 23:47:10 Probes listening on :44135 [main] 2018/11/18 23:47:10 Storage driver is ConfigMap [main] 2018/11/18 23:47:10 Max history per release is 0
直接执行时,默认会监听 44134
和 44135
端口,44134
端口用于和 helm
进行通信,而 44135
主要是用于做探活的,在部署至 K8S 时使用。
当我们使用客户端连接时,只需设置 HELM_HOST
环境变量即可。
1 2 3 4 5 6 7 ➜ ~ export HELM_HOST=localhost:44134 ➜ ~ helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
注意 一定要正确配置 $HOME/.kube/config
文件,否则会影响正常功能使用。
默认安装 官方提供了一种一键式安装的方式。那便是 helm init
执行这条命令后,会同时在 K8S 中部署服务端 Tiller 和初始化 helm 的默认目录 $HELM_HOME
默认值为 $HOME/.helm
。
这种方式下会默认使用官方镜像 gcr.io/kubernetes-helm/tiller
网络原因可能会导致安装失败。所以我已将官方镜像进行同步。可使用以下方式进行使用:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 ➜ ~ helm init --tiller-image taobeier/tiller:v2.11.0 Creating /root/.helm Creating /root/.helm/repository Creating /root/.helm/repository/cache Creating /root/.helm/repository/local Creating /root/.helm/plugins Creating /root/.helm/starters Creating /root/.helm/cache/archive Creating /root/.helm/repository/repositories.yaml Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com Adding local repo with URL: http://127.0.0.1:8879/charts $HELM_HOME has been configured at /root/.helm. Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. To prevent this, run `helm init` with the --tiller-tls-verify flag. For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation Happy Helming! ➜ ~ helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
可以看到 $HELM_HOME
目录已经初始化完成,客户端与服务端已可以正常通信。查看下当前 K8S 集群中的情况:
1 2 3 4 5 ➜ ~ kubectl -n kube-system get deploy tiller-deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE tiller-deploy 1 1 1 1 6m
可以看到已正常部署。
手动安装 通过上面的描述,可能你已经发现,安装服务端,其实也就是一次普通的部署,我们可以通过以下方式来自行通过 kubectl
完成部署。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 ➜ ~ helm init --dry-run --debug # 篇幅原因,以下内容进行了省略 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: creationTimestamp: null labels: app: helm name: tiller name: tiller-deploy namespace: kube-system spec: replicas: 1 strategy: {} ... status: {} --- apiVersion: v1 kind: Service metadata: creationTimestamp: null labels: app: helm name: tiller name: tiller-deploy namespace: kube-system spec: ports: - name: tiller port: 44134 targetPort: tiller selector: app: helm name: tiller type: ClusterIP status: loadBalancer: {}
将输出内容保存至文件中,自行修改后,通过 kubectl
进行部署即可。建议在修改过程中,尽量不要去更改标签及选择器。
RBAC 使用 上面的内容中,均未提及到权限控制相关的内容,但是在生产环境中使用,我们一般都是会进行权限控制的。
在第 8 节中,我们已经详细的解释了认证授权相关的内容。所以下面的内容不做太多详细解释。
这里我们创建一个 ServiceAccount
命名为 tiller
,为了简单,我们直接将它与 cluster-admin
进行绑定。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system
将此内容保存为 tiller-rbac.yaml
,开始进行部署操作。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 ➜ ~ kubectl apply -f tiller-rbac.yaml serviceaccount/tiller created clusterrolebinding.rbac.authorization.k8s.io/tiller created ➜ ~ helm init --service-account tiller Creating /root/.helm Creating /root/.helm/repository Creating /root/.helm/repository/cache Creating /root/.helm/repository/local Creating /root/.helm/plugins Creating /root/.helm/starters Creating /root/.helm/cache/archive Creating /root/.helm/repository/repositories.yaml Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com Adding local repo with URL: http://127.0.0.1:8879/charts $HELM_HOME has been configured at /root/.helm. Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. To prevent this, run `helm init` with the --tiller-tls-verify flag. For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation Happy Helming! ➜ ~ helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
以此方式完成部署。
Helm 概念 Chart chart
就是 Helm 所管理的包,类似于 Yum
所管理的 rpm
包或是 Homebrew
管理的 Formulae
。它包含着一个应用要部署至 K8S 上所必须的所有资源。
Release Release
就是 chart
在 K8S 上部署后的实例。chart
的每次部署都将产生一次 Release
。这和上面类比的包管理器就有所不同了,多数的系统级包管理器所安装的包只会在系统中存在一份。我们可以以 Pip
在虚拟环境下的包安装,或者 Npm
的 local install 来进行类比。
Repository Repository
就是字面意思,存储 chart
的仓库。还记得我们上面执行 helm init
时的输出吗?默认情况下,初始化 Helm 的时候,会添加两个仓库,一个是 stable
仓库 kubernetes-charts.storage.googleapis.com 另一个则是 local
仓库,地址是 http://127.0.0.1:8879/charts 。
Config 前面提到了 chart
是应用程序所必须的资源,当然我们实际部署的时候,可能就需要有些自定义的配置了。Config
便是用于完成此项功能的,在部署时候,会将 config
与 chart
进行合并,共同构成我们将部署的应用。
Helm 的工作原理 helm
通过 gRPC
将 chart
发送至 Tiller
,Tiller
则通过内置的 kubernetes
客户端库与 K8S 的 API server 进行交流,将 chart
进行部署,并生成 Release
用于管理。
前面只说到了 helm
与 Tiller
交互的协议,但尚未说其数据链路。
我们来看看 Tiller
的部署情况。主要看 Service
:
1 2 3 4 5 6 7 ➜ ~ kubectl -n kube-system get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 1h tiller-deploy ClusterIP 10.107.204.164 <none> 44134/TCP 33m
Tiller
默认采用 ClusterIP
类型的 Service
进行部署。而我们知道的 ClusterIP
类型的 Service
是仅限集群内访问的。
在这里所依赖的技术,便是在第 5 节,我们提到的 socat
。helm
通过 socat
的端口转发(或者说 K8S 的代理),进而实现了本地与 Tiller
的通信。
当然,以上内容均以当前最新版本 2.11.0
为例。当下一个大版本 Helm v3 出现时, Tiller
将不复存在,通信机制和工作原理也将发生变化。
总结 通过本节,我们已经学习到了 Helm 的基础知识和工作原理,了解到了 Helm 的用途以及如何在本地和 K8S 中部署它。需要注意的是 $HOME/.kube/config
需要提前配置好,以及 socat
工具需要提前安装,可参考第 5 节的内容。
接下来,我们将上节中的示例项目使用 Helm 部署至 K8S 集群中。