系列介绍：初探云原生应用管理系列是介绍如何用云原生技术来构建、测试、部署、和管理应用的内容专辑。做这个系列的初衷是为了推广云原生应用管理的最佳实践，以及传播开源标准和知识。通过这个系列，希望帮助大家学到 Kubernetes、Helm、Gitops、Kustomize 等新知识。

这是大厂程序员小张普普通通的一个早晨，大家好像在讨论着什么：

“什么？听说隔壁公司在用 K8s 发布应用了？”

“据说在用 Helm！”

像往常，小张根本不关心这些无聊的讨论。他稳稳的坐在办公桌前，打开公司内部自研的、魔改 Gitlab  打造的项目管理系统，点击了好几个 Button 之后，开始一天辛勤的劳作。

但这一次不知道为何，小张的内心居然有点慌：
“Helm？啥是 Helm ?”

—— 分割线 ——

Helm:  K8s 应用部署与打包工具

如果一个用户想要部署起来一个 K8s 应用，最快捷的方法是什么呢？

我们知道，Kubernetes (简称 k8s) 是一个能够部署和管理容器的平台。然而，在 k8s 里还没有抽象到“应用”这一层概念。一个应用往往由多个 k8s 资源 (Deployment、Service、ConfigMap）组成。所以，我们需要一个工具在 k8s 之上来部署和管理一个应用所包含的资源（K8s API Resource），这就是 Helm 所做的事情。

除此以外，Helm 定义了一套 Chart 格式来描述一个应用。怎么理解 Chart 呢？打个比方，一个安卓程序打包成 APK 格式，就可以安装到任意一台运行安卓系统的手机上。如果我们把 k8s 比做安卓系统，K8s 应用比做安卓程序，那么 Chart 就可以比做 APK。这也意味着，K8s 应用只要打包成 Chart，就可以通过 Helm 部署到任意一个 k8s 集群上。

通常来说，我们可以直接使用别人已经做好的 Helm Chart，就跟使用 Docker 镜像一样。所以，Helm 社区已经维护了一个官方 Helm Hub，这个 Hub 里包含的应用非常丰富，是目前云原生开发者搜索和下载应用的主要站点。

AppHub:  Helm Hub 的中国小站

不过，遗憾的是，在国内使用 Helm Hub，对于绝大多数开发者来说都是很痛苦的一件事情。

原因很简单，随便打开一个 Charts 文件，你就会看到这个文件里充斥着大量的不可访问的镜像 URL：

或者是依赖根本访问不到的 Charts  库：

咱们软件工程师的时间这么宝贵（少），根本不想花时间解决这些无聊的网络问题上（大雾）！

可是，看着国外的程序员们通过一条 helm install 命令就把应用部署起来，咱们怎么感觉还是有点酸呢 ……

所以在正式开始探索云原生应用管理之前，我们首先要为你介绍一个叫做“开放云原生应用中心”(Cloud Native App Hub，简称 AppHub) 的服务，它的主页是：https://developer.aliyun.com/hub。

AppHub 是一个托管在国内公有云上、全公益性的 Helm Hub“中国站”，它的后端由阿里云容器平台团队的三位工程师利用 20% 时间开发完成。

而这个站点的一个重要职责，就是把所有 Helm 官方 Hub 托管的应用自动同步到国内；同时，自动将 Charts 文件中的 gcr.io 等所有有网络访问问题的 URL 替换成为稳定的国内镜像 URL。

这样，国内的开发者也可以自由的使用 helm install 来安装应用了！

接下来，我们就进入喜闻乐见的实践环节！

实例：用最快的速度部署 Guestbook

首先，当然是安装 Helm。

在这里我们强烈推荐你使用 Helm v3 版本。

Helm v3 跟 Helm v2 的区别就像 Python 2 和 3 那么大，而且还比 Helm v2 要好用的多（比如：不需要安装服务端组件 Tiller）。我们下周的《为什么你必须尽快转向 Helm v3》文章，会为你解释这个事情。

而为了方便国内开发者使用，我们已经自动同步了 Helm  v3 二进制文件的下载链接到国内（一定要试，真的是秒下）：

• MacOS amd64 tar.gz
• MacOS amd64 zip
• Linux 386
• Linux amd64
• Linux arm64
• Windows amd64

下载到 Helm 二进制文件直接解压到 $PATH 下就可以使用了。

接下来，我们使用 Helm 快速部署一个 guestbook 应用。这里假设你有一个阿里云 Kubernetes 服务在运行了（如果没有的话也没关系，下面还有自建 K8s 集群的例子）。

第一步是添加 apphub 作为你的 Helm Hub Repo：

$ helm repo add apphub https://apphub.aliyuncs.com

可以直接在命令行搜索 guestbook：

$ helm search guestbook
NAME                       CHART VERSION   APP VERSION DESCRIPTION
apphub/guestbook           0.2.0           1.0.0       A Helm chart to deploy Guestbook three tier web...

然后，只需一行命令即可:

$ helm install guestbook apphub/guestbook

访问 Guestbook 服务

部署完成后，运行以下命令来查询并等待 pods 启动完毕 (Running):

$ kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
guestbook-d85895895-5mdx6   1/1     Running   0          5m59s
guestbook-d85895895-zh4l4   1/1     Running   0          5m59s
redis-master-7b5cc58fc8-2wjmn          1/1     Running   0          5m59s
redis-slave-859585ff7f-4v9hj           1/1     Running   0          5m59s
redis-slave-859585ff7f-fppqn           1/1     Running   0          5m59s

查询服务地址:

$kubectl get service -l app.kubernetes.io/name=guestbook
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
guestbook   LoadBalancer   172.21.1.213   47.95.136.189   3000:32244/TCP   11m

通过 External IP 即可访问 guestbook 服务:

使用 Minikube 或者自建 K8s 集群？

实际上，K8s 本身是不区分云上服务还是自建集群的。只不过在没有云提供的负载均衡服务的话，Service 的访问方式会稍微麻烦一些，比如使用 NodePort：

$ helm install guestbook apphub/guestbook --set service.type=NodePort

这条命令执行完之后，应用会自动提示你接下来的访问方式。而通过 –set 这种方式设置应用参数到底是怎么回事，我们后面的文章会细聊。

如果是 Minikube 的话，还需要把这个 NodePort Service 从 Minikube 里映射出来才能访问：

$ minikube service guestbook

试用“一键安装”(体验功能)

除了正常的部署方法，AppHub 上也可以通过网页 UI 来体验一键部署 Chart 到任何云的 k8s 上。

举个例子，只需打开 guestbook 应用详情页面，点击“一键安装”:

然后在”安装参数“弹窗里填写相应的服务器 URL 和 base64 编码的证书数据后，点击“确认”，AppHub 就会尝试安装 guestbook chart 到对应 k8s 集群上，成功后会弹窗通知。

不过，这个功能目前只是“体验”，因为你现在还没办法在 AppHub 上直接修改应用的配置参数。在线进行“应用定制”的功能就在 AppHub 的 Roadmap 里，预计下个月会上线。

不过，说起 Roadmap 的话：

AppHub 6 个月内的 Roadmap，都在 Github 上开源！

是的，你可以通过 Github 来随时对这个 Helm Hub 中国小站点提出你的改进思路。比如：如何更好的做“应用定制”？如何对接和托管你自己的 Charts Repo？等等。

我们的口号是：每一位中国开发者，都是我们的 PM！（认真脸）

远不止 Helm！

可以看到，通过 Helm 快速部署起来 K8s 应用的过程，使用门槛和心智负担都是非常低的。而相比于传统的应用构建、编排和发布的流程，Helm + K8s 的自动化组合正在迅速成为云时代提升开发者效率的不二法宝。

而这里介绍到的所有同步自官方 Hub Repo 的应用 Charts，全都托管在这个 Github 上: cloudnativeapp/charts。大家有对 AppHub 相关的任何吐槽，都欢迎来这个 Repo 提 issue；也欢迎来通过提交 pull requests 把你的 Charts 和 Repo 加入到 AppHub 上。

不过，如果深入使用过 Helm 一段时间后，你可能会有些其他的感受：

比如：“Helm 里的 Release 的概念到底是啥意思？Helm 的 Rollback 又是咋回事儿，跟 K8s 是啥关系？”

“Helm 对 K8s 应用管理的流程，好像不是那么的 Native 啊，总感觉哪里不对啊。”

在后面的几篇文章中，我们会和大家一起深入的分析 Helm 这套体系的优点和缺点，梳理在 K8s 架构中使用 Helm 的最佳实践，分享和讲解 Kustomize 流程和 GitOps 架构，以及更多的云原生应用管理的实例。

敬请期待吧！

作者简介: 邓洪超，阿里云工程师，前 CoreOS 软件工程师、Kubernetes Operator 机制的初始作者之一、Operator 第二人（因为第一人是李响），对 K8s 应用管理体系有较多的研究和经验。