如何基于Kubernetes构建完整的DevOps流水线

作者 倪朋飞

前言

关于DevOps是一个很大的话题，它可能既涉及到公司的技术文化构建，也包括开发者技术能力的支持，这次技术干货分享主要是侧重于技术方面，就是如何用Kubernetes来服务好DevOps的流水线。本文从4个方面介绍：

1．什么是Kubernetes？为什么Kubernetes比较适合用来构建DevOps的流水线？

2．如何基于Kubernetes来构建DevOps流水线？

3．如何在Azure上面利用AKS去构建DevOps流水线？

4．DevOps中常见的一些挑战。

1．什么是Kubernetes？为什么Kubernetes比较适合用来构建DevOps的流水线？

Kubernetes是目前最为广泛且流行的容器编排调度系统，它也是现在用来构建云原生应用编排的最佳平台。目前所有云原生应用基本上都会基于Kubernetes API去构建。

Kubernetes给开发者带来了很多实用的特性，比如一致性、可扩展性、自我修复的功能。一致性是指在Kubernetes上构建的应用可以无缝的迁移到任何环境里，不论公有云、私有云还是跨云。可扩展性是指把Kubernetes的插件机制运用到任何环境里，通过Kubernetes这些插件都可以实现自定义化。Kubernetes的自我修复功能，包括健康检查、故障的自动恢复、自动扩展等机制，这些对于系统运行至关重要。

Kubernetes的架构比较简单，分为Master和Node两部分。

· Master主要负责集群的状态维护，也给集群提供一个对外访问的入口；

· Node负责运行容器，为容器提供一些必要的环境，比如存储、网络等。

Kubernetes在Master上必备的组件只有四个，在Node上必备的组件，除了Kubelet、Kube-proxy，还有Docker等。而其他所有的一切都是通过扩展的方式部署到集群里，比如在部署一个集群时，DNS是一个必需的功能，但这个功能是以一个容器的方式部署到集群里。

由于Kubernetes架构非常简单。因此它有一些特别的好处，就是可以运用到DevOps流水线里面来。以持续集成为例，在版本升级测试新的特性时，在Kubernetes之前可能要通过IPM包管理这些软件，当升级IPM包时，有可能产生冲突。而在Kubernetes中，通过把IPM包放到每一个容器里，避免软件包的冲突问题。如果把每个应用程序所依赖的东西都放到了容器里面，应用程序在不同环境里就可以很容易保持一致。

在DevOps里监控系统很关键，而在Kubernetes中，通过一个Pod的方式运行容器，应用程序可以部署在Pod的一个容器里，其他的容器可以用在监控里。

在DevOps中经常需要频繁地发布、变更系统，发现问题时需要回滚，而在频繁的发布和回滚时，需要有一个系统去管理这些发布的历史生命周期，在发现问题时才可以回滚回来。对于系统来说，要求它发布的过程中不能影响应用程序对外正常访问。在Kubernetes中已经有了原生的机制，比如用Service和Deployment来完成这个功能，Service可以提供一个对外访问的入口，自动做好负载均衡；Deployment负责管理好这些副本。如果需要升级，通过滚动升级的方式去部署。

2．基于Kubernetes的DevOps

DevOps是把人员流程、产品进行结合，给用户提供持续价格的一个过程，这个过程既涉及到人员、过程，也涉及到产品。DevOps最终目的是给客户提供持续交付的价值，流程包括：产品的规划跟踪、软件开发、构建测试、产品部署、运维、监控和优化，并通过一个流水线的方式串联起来。因此通常把DevOps这些流程合并起来称为一个DevOps的流水线。这个流水线的核心目标，就是持续给用户交付有价值的产品。

Kubernetes如何服务好DevOps流水线？Kubernetes的好处就是可以把不同的产品、工具串联起来。以CI/CD里最常用的Jenkins为例：现在有一个Jenkins-x项目，实现了与Kubernetes的集成，利用Kubernetes的CI/CD实现了自定义的兑现，有了这些资源兑现，就可以通过Kubernetes的API来定义CI/CD的过程。

另外如果使用Kubernetes构建整个流水线，在监控的时候就可以同样选择Kubernetes生态之中的项目，比如可以直接从Prometheus里获得很多指标，去构建想要的监控告警，以及后续的对整个产品的优化依据。基于这些工具，就可以构建一个DevOps的流水线。

一个比较典型的DevOps的流水线过程是：项目开始开发时，用VS Code开发代码，然后把代码推送到GitLab里存储，通过GitLab的hook使Jenkins执行一些CI的过程，比如做一些单元测试，构建Docker image，再把这个Docker image调用helm部署到开发环境或测试环境中。在测试环境里通过Jenkins触发一个集成测试的功能，完成后就可以把它部署到生产环境里，通过Kubernetes addon的方式，把Prometheus、Grafana等监控组件部署到集群里，就实现了一整套从CI到CD的监控过程。

3．基于AKS的Devops

AKS是Azure提供的一个托管的Kubernetes服务，因为很多人在接触Kubernetes时发现它最大的痛点是Kubernetes的安装部署和维护太麻烦。Kubernetes发布特别快，在升级的过程中很容易出现各种问题，而AKS的出现可以解决这些问题。

需要注意的是，AKS只是提供了一个托管的Kubernetes服务，也就是它只提供了一个K8s的集群，而为了运行这个集群，还需要其他东西，比如要考虑Docker image要存在哪里的问题。ACI提供了跨地域自动复制的功能，因此Docker image只要存到ACI里，就可以在不同的Image里使用。

另外在DevOps的流水线里执行任务时，这些任务都类似Kubernetes的一个Job，比如在持续集成里做一个单元测试，这个单元测试可能运行很短时间就结束了，但如果用AKS，或者通过其他产品的Kubernetes集群来管理这套DevOps流程，要优先保证最大的Job数量时，它才能够正常的运行。但是这会造成一定的资源浪费。

ACI是一种无服务器化的容器解决方案，用户无需管理底层服务器，只需要调用它的API把一个容器运行起来即可。另外如果运行的程序还有一些数据要存储，如果要访问数据库，就需要用cosmosDB等服务，而它们已经跟AKS、Kubernetes有了很好的集成，这些服务可以很方便地在Azure上使用。

如何构建一套比较完善的DevOps流水线呢？

首先要创建项目，选择最合适的产品来管理进度，用Azure DevOps把产品后面的代码开发、单元测试和集成测试、持续部署等串联起来。Azure DevOps提供了Backlog等工具来管理应用程序。

开发项目时，需要一套Git存储仓库，Azure DevOps也提供了这个功能。而项目开发完成之后，需要的本地测试可以使用Draft，它的好处就是可以把进项打包，再通过Helm部署到开发环境里，并且可以自动设置好应用程序的远程调试。也就是让应用程序以容器的方式运行在一个Kubernetes的环境中，但是可以通过VS Code在线调试程序。

如果应用程序在本地测试通过了，就需要推送到代码仓库里持续集成，然后需要部署到测试环境里做相应的测试，最终再把它部署到生产环境里。当这一切做完了以后，应用程序就已经在线上跑了，但这个时候DevOps流程并没有结束，因为还需要运维和监控这个应用程序。这个时候就可以Azure monitor监控这个程序的状态。

4．DevOps的挑战

DevOps的挑战，首先就是自动化的测试不足。DevOps流水线由于测试的投入不足，新发布的功能没有测试到，这个时候发布到生产环境就容易出现各种各样的问题。比如应用程序部署之后，可用性降低了，资源使用率突然升的很高等。对于这个问题实际上可以通过一定的组织文化建设去解决。一个比较简便的方式就是对这些过程提供适当的测试覆盖率的要求。例如一个新的产品发布时，要求测试覆盖率不能降低了，但是测试覆盖率是比较难以控制的，可能要从组织文化上来解决。

第二个问题就是DevOps的工具链缺少链接，没有链接就没有办法做到高度的自动化。比较推荐的做法是选用Kubernetes生态中的这些工具链，利用Kubernetes API把应用程序更好地串联起来，形成完整的DevOps的流水线。

第三个问题就是很难量化成果，以及很难协调团队之间的合作。比如用户抱怨网站访问速度慢了，由于当下并不知道慢的问题在哪里，所以要到各个产品里去检查。如果没有一套完善的监控系统，就很难定位这个产品到底是该由谁去负责。针对这个问题可以使用Kubernetes，在不改变应用程序的情况下，跟踪整个应用程序的调用链，比如可以使用ServiceMesh监控这些应用程序，这样可以减少发现问题之后没法具体定位产品的瓶颈。

最后一个问题就是在DevOps之中，虽然使用了Kubernetes的生态链工具，如果没有遵循一些Kubernetes/DevOps的最佳实践，会导致在实际操作中出现预想不到的问题。比如一个最简单的问题，在升级的过程中可以用Kubernetes的Deployment来做滚动更新。按照正常的预期，在滚动更新的过程中，原来的副本还在正常运行着，新副本也是逐步去创建着，Service负载均衡也是正常运行的。但问题是，Service每次升级时总会时不时的断一下，其可能用性在每次部署时，总会降低那么一点。产生这个问题就是因为没有遵循Kubernetes最基本的最佳实践，没有给应用程序部署健康检查。对于最佳实践的问题，实际上需要整个团队，不只是DevOps流水线的构建团队，还需要应用程序的团队共同把这些最佳实践运用到流水线和应用程序的管理中。比如会出现Job的失败率非常高的问题，这时不仅要对应用程序进行资源的限制，另外对DevOps流水线里面的这些Job也要进行一定的资源控制，不要把资源全部耗光。

经验之谈

在Kubernetes中，不建议大家直接去管理一个Pod，你之前创建了一个Pod，而没有使用控制器去管理它。在Kubernetes中，建议每一个Pod都有一个控制器来管理，比如你可以用Deployment来管理，或者使用副本控制器来管理。所有这些控制器都是用来保证Pod在预期的状态。也可以使用自己的控制器去管理这些Pod，通过开发一个API去管理生命周期。这样容器最终在运行状态时，总是有一个控制器来管理，就不会出现一个容器在一直在运行，却不知道是谁在管理的问题。

作者简介

倪朋飞，就职于微软Azure，主要关注Kubernetes与微服务，同时也是Kubernetes开源社区SIG Azure Tech Lead。作为Kubernetes项目维护者，同时负责维护开源书籍《Kubernetes指南》。