前言

本小节应该是这个系列剩下的两个小节之一了。剩下一个是之前承诺好的drone-wechart插件。本节主要介绍利用helm部署应用到kubernetes中。
至于helm，详细可以参考FreeWheel Lead Engineer 张夏写的一系列文章。总之，k8s中yaml文件的编写复杂程度直接决定了k8s的使用门槛。利用Kubernetes部署一个应用，需要Kubernetes原生资源文件如deployment、replicationcontroller、service或pod 等。而对于一个复杂的应用，会有很多类似上面的资源描述文件，如果有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，且由于缺少对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，helm主要是能解决这些问题。

而drone中提供了三个kube-helm插件，用来配合drone，实现k8s的cicd。这三个插件大同小异，我集中总结一下：

1. drone-kube
2. drone-kubernetes
3. helm

不过所有的插件都是只能用来更新应用，不能新建。

总体思路

1. 编写自己的.drone.yaml,放置到项目根目录下。主要就是引用各种pipeline插件，例如默认添加的git拉取代码的插件，项目编译环境的插件，此处针对不同语言，可以定制不同的镜像，例如我们之前的项目会把common这种基础库也做到docker镜像里，可以提高构建速度。以及telegram，line，mail等通知插件。
2. 提交代码到github或是gogs等版本控制工具里，触发webhook钩子，通知drone执行整个设计的构建流程。该项目中，需要另外两个插件，一个是docker镜像，用于将编译好的程序做成镜像，并推到自己的docker registry中。所以需要在根目录下，编写自己的DockerFile文件。另外一个是上面提到的helm插件。
3. docker hub由于墙的原因，这边一般是使用harbor，vmware中国团队基于docker registry做出来的私有镜像仓库。
4. helm可以选用k8s官方的公共仓库，一般都会搭建一个自己私仓，结合起来使用。
5. 新的镜像推到harbor之后，helm插件就可以执行部署步骤了。
6. 最后一般都会引用通知插件，将构建结果通知部署人员。

总结

路漫漫其修远兮，其实整个helm插件只是可以满足一般的需求，整个部署过程经常会有一定的部署策略，蓝绿，金丝雀等。这一块需要不同的paas平台，重新实现。另外之前提到的，helm插件只能用来更新，不能新建。所以这一块需要探索的路还很长。
说到部署策略，不得不说Spinnaker，实现的功能很多，但是足够的复杂，目前来看，国内只有小红书用起来了。实现的语言是groovy，也不够友好(当然主要是我不会).