如何基于 Kubernetes 构建完整的 DevOps 流水线
ztsinghua 2019-01-19
- 什么是 Kubernetes？为什么 Kubernetes 比较适合用来构建 DevOps 的流水线？
- 如何基于 Kubernetes 来构建 DevOps 流水线？
- 如何在 Azure 上面利用 AKS 去构建 DevOps 流水线？
- 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 去管理生命周期。这样容器最终在运行状态时，总是有一个控制器来管理，就不会出现一个容器在一直在运行，却不知道是谁在管理的问题。
