多云环境下基于 Kubernetes 的 DevOps

会员服务 ·

多云环境下基于 Kubernetes 的 DevOps

2019 年 3 月 21 日 DevOps时代

作者简介

邱见
IBM，现任资深架构师

前言

我来自于 IBM，我们的工作是在多云环境下做一些 Kubernetes ，然后在 Kubernetes 之上做 DevOps 一些的东西。今天我的分享主要有以下四个部分：

什么是多云?
多云环境下的 IBM Cloud Private
我们遇到的挑战
IBM Cloud Private DevOps 实践

01 什么是多云？

首先是什么是多云。以前我们经常去谈混合云，混合云其实就是说你有自己的一个私有云，在公有云上有一些服务，在之间做一些 DR 切换，把一些服务托管到公有云上面。

从现在实际情况来看，越来越多的公司使用多个不同的公有云，他们也会有自己的私有云。IBM 做过调查，我们的客户有 80% 的准备使用多个公有云，有 70% 实际上正在使用三个或者三个以上的公有云服务，他们可能来自于 aws、阿里，腾讯各种各样的公有云服务。

为什么使用多云环境呢？有几个很重要的考虑因素，比如说：

把应用部署在最适合的公有云平台上
避免传统应用改造的痛点来适应新的平台
避免被公有云厂商绑定

IBM 自己也使用，可以说是公有云的提供商也是多云的消费者。IBM 有很多的服务也跑在 aws 或者跑在其他云平台上，IBM 自己也在使用多云，也是为了使用更好的这种公有云上的服务。

02 多云环境下的 IBM Cloud Private

在之前很长的时间，多云这件事情在 DevOps 上面很难做，对于公有云以前提供 IAAS 服务，他们的 API 不是统一的，用不同的公有云服务，你要使用不同的 API。但是由于 Container 还有 Kubernetes 的出现，我能有一套统一的 API 去使用公有云。从 Kubernetes 或者从 docker 角度来讲，其实不太关心你后面的是什么，可以是任何的公有云服务，但是你可以从部署在 Kubernetes 的角度来做这个事情。

对于我们团队来说，我们是做多云上面的 Kubernetes 平台，这个平台上面会有一些运维服务，又有一些 IBM 自己的其他应用服务，这些服务包含数据分析、AI、还有一些其他的长期运行的服务。

我们团队主要做运维服务和 Kubernetes 这两层的开发跟运维工作。这个平台会在 IBM 内部运行，也会在其他的公有云平台上运行，也会根据用户使用，决定运行在其他的公有云或者是用户自己的内部环境。

那么在这个平台的开发中，我们使用了挺多的 DevOps 工具，这些工具大多数都是 SAAS ，比如说 Github Enterprise、Artifactory、Slack 这些东西。这些 SAAS 服务之间其实已经做了很多的整合，所以你可以很好地去做一个 CI/CD 的 Pipeline 把他们整合在一起。

03 我们遇到的挑战

我来说说在这个过程当中，遇到什么挑战？最开始开发这个平台，我们主要负责的是以 kubernetes 上面的一些运维服务为主的一些开发。

一开始的时候，我们想法非常简单，我提一个 PR，这个PR去做 unittest ，完了以后提交到 master 上面，之后你就会有一个 latest image ，其他人就可以使用这个镜像去部署这个东西。

这里有三个问题：

组件众多，开发团队众多
多云环境下平台测试异常复杂耗时
对这个平台上来说，既是消费者，又是生产者

第一，组件众多的问题

随着平台的发展，不止是 Kubernetes 本身，还包含上面的一些服务。比如说我们有自己 UI service、监控的 service，有非常多的 service，而每一个 service 都有不同的小组，每个小组之间的开发计划、开发进度又不是完全一致。所以你想说我有一个大的去覆盖所有事情是不太可能的。

我们每一个组件，它其实都是有几部分组成的，我们把它抽象成都是 pod、images、Kubernetes 的 helm chart 。部署的方法就是 helm chart 去部署一堆的镜像。由于开发进度不一样，组件之间有互相的依赖，比如说 api 的依赖，就会导致一个新的镜像构建出来之后，其他的镜像没有办法被使用。

第二，测试复杂耗时的问题

第二个测试复杂耗时的问题。我们这个平台需要在多云环境下进行测试，由于 IBM 自己，不光只要支持 X86，还要支持自己内部的 Power 和 Z 这种架构。实际上这个平台每次需要去做很多的测试，在每一个平台，不同的云环境，不同的 CPU 架构上做测试。

那我们什么时候做这个测试？在之前这种 DevOps Pipeline ，我们提交一个 PR，所有的测试都会做一编，到提交到 master 的时候再做一遍，然后构建出 latest images，这里面会有一个问题，这个时间非常长，很容易出错，出错了以后，直接导致 code 没有办法进行，影响整个开发。

你需要在各种环境里面做测试，就会导致多个团队同时开发，PR 不断 rebase 不断测试。

第三，我们既是消费者，又是生产者的问题

对这个平台来说，使用很多开源软件，实际上我们要在开源软件上做一些修改，对于 Kubernetes 来说，我们自己内部也要做一些改进，加一些业务进去，这部分必须涵盖在 DevOps Pipeline 里。

它又是一个生产者，它生产出这个平台，IBM 其他的数据服务，数据分析要使用这个平台。所以这里就有一个问题，我生产出这个平台以后怎么保证它的版本，因为别人也要不断地去做开发，我们要保证生成出来的平台一定是稳定的平台。

04 IBM Cloud Private DevOps 实践

我们看一下我们后面的一个改进。我们后来发现，其实没有办法完全按照开源的方法去做，因为组件实在是太多了。

最终的决定就是把整个 CI/CD Pipeline 拉长，于是我们就重新做了一个 DevOps 的架构，这个架构首先有 SAAS 的部分，比如说 Github Enterprise、Slack，还有我们使用了 Artifactory，主要去做 images 的存储。

对于 IAAS 层来讲，有不同的 IAAS 平台，有 CI/CD 去拆发一些专门的脚本，他们有自己 IBM Cloud Private system environment 的去做整个系统监控，报告安全的问题，因为我们每一个 docker 镜像构建出来，都要去扫描它的安全问题，他们也会构建一些 Terraform、ansible 的脚本去做这些部署。

每一个自己的 Squad 也要负责一部分，负责自己 images 的构建还要负责自己的 helm chart，这样就把责任分得比较清楚，对于本身的 component 的部署和 images 是由某一个特定的 squad ，就是谁开发谁的负责这部分东西。

对于 CI/CD 的 squad 主要做一些基础环境，比如使用 Terraform 调不同的公有云，把基础环境做起来。

在这之后我们有了一个延长以后的 Pipeline ，这个 Pipeline 分了左右两部分，左边是持续的部分，右边是 scheduled 好的。

左边的部分只需要开发者去关心的，像以前我们有一个 scratch、integration 这两个不同 images 的 repository，一个PR被 build 以后，它首先去做一些 unittest，然后会进到 scratch bulid 里，这个其实可以去定制，别人就可以把 scratch 里的东西拿出来测试。

接下来如果被提交到 master 以后，它会进入到 master build，在这之后就是 CI/CD 团队去做，会产生不同版本的 build 为不同的目的服务。

首先看到是的 scratch build，那么 scratch build 就是说我PR提交了以后我就有一个 scratch build，这些可以用来做一些 unittest。之后如果这个 PR 提交到 master 以后，会产生 integration 的 build，其实它就是一个不同的 image。对于开发者来说，他只对这两个 build 有权限。

在这之后就成了 CI/CD 团队做的事情，他们需要做 daily build，daily build 是说每日从 integration 拿一个 daily 的 image 出来。

我们预期他们是会失败的，当然这里头有很多的原因，比如集成的问题，比如说 API 兼容性的问题。

这个 daily build 会要执行跨平台、跨云、跨操作系统的测试，以前对跨云、跨操作系统的测试，不再放在一个开发者的 PR build 里，而是放在 daily build 里，这个时候把这些事情跟开发者分开来了，相对来说可以更快速的开发，把这些事交给 CI/CD 团队去做，他们会发现其中的一些的 BUG 并且反馈回来，然后再反馈到开发团队。

Development stage、Stable stage 、Release stage 这几个是对于外部来说是比较稳定的一些 build，这些可以被其他人使用。他们也有不同的状态，比如说 Development build 可能它的 api 变化还是相对会大一些，Stable 会保证 api 相互的兼容性，他们 build 的周期也不太一样。

从 Development build 开始可以提供给其他的一些服务去使用，到 Stable build 以后会部署到多云的预生产的环境里面，在这之上让其他的应用去使用。

另外一些问题，生产者和消费者怎么解决？实际我们是很多开源软件的消费者，包括 Kubernetes、docker，还有很多其他的一些开源的组件。另一方面，我们又需要去修改它的一些东西，来保证它可以满足我们的要求。

比如 Kubernetes 这种 build 我们也会跟随一样的流程，也会到 scratch、 integration 再通过做一系列的测试变成一个 stable，也是通过 Pipeline 这种方式去 build 其他的开源组件。

其次是生产者的做法。像我刚才讲的，我们会有三个不同的 build，根据 build 稳定性分成不同的阶段，从 development 到 release。 Content Team 这里指的就是使用它，他们有一些服务要跑在这个平台上面，他们就可以从 Development build 试用它，如果觉得可以就把服务迁移到 Stable build 里。

接下来，一个问题是多云。实际上刚才讲的是 DevOps Pipeline，走到 Stable 的时候，实际上就是多云环境，在这种情况下，我们怎么样去管理多云，如何做一些不同云环境下的应用配置。

比如说我有一个运维服务，它实际上由 helm chart 和 docker images 组成的。你需要部署到多个云环境中，虽然说 Kubernetes 可以很大程度上保证你的东西不管放在哪里都可以部署，但是有一定的区别，需要有一些区别的配置，那么就需要在多云环境的配置管理，需要做一些多云环境上系统的监控、合规等等这些东西。