前言

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

helm架构图

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

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

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

总体思路

harbor+helm+drone

  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,也不够友好(当然主要是我不会).

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐