与云无关的用于 Kubernetes 的自动化 CI/CD

首发于 Jenkins 中文社区

在本文中，我想讨论一种在云环境中为 Kubernetes 工做负载实现自动化端到端 CI/CD 的方法。 这里可能有其它解决方案，而像 AWS、Microsoft Azure 和 GCP 这样的云提供商也提供了本身的一套框架，以实现与 Kubernetes 相同的目标。

它的部署模型的核心是 Rancher，Rancher 负责为托管在不一样云环境和裸机环境中的多个 Kubernetes 集群提供集中管理与运营的能力。 根据应用程序和业务须要，这里提到的工具能够替换为本身选择的工具。

在详细介绍以前，这里有张部署模型的快照：

持续集成组件

咱们使用 JIRA、BitBucket、Bamboo 和 Nexus 做为自动化持续集成组件。 需求和用户故事来自 JIRA ； 开发人员将他们的代码放进 BitBucket ； 代码被代码评审工具和静态分析工具构建与集成，Bamboo 生成的 Docker 镜像被推送到 Nexus。 这些镜像会通过特定的容器安全检查。

当你有许多微服务/应用程序须要构建时，那么处理 Kubernetes 集群工做负载的部署、升级和回滚可能会复杂。 版本控制是咱们须要考虑的另外一个挑战。 Helm 有助于克服这些大多数挑战，并使部署变得简单。

若是你想知道你是否须要有一个 chart 将全部 deployments 包含在其中， 或者容许每一个应用程序和微服务都有一个单独的 chart ， 那么咱们但愿将这些 charts 放到特定的应用程序或微服务的仓库中， 这样咱们就不须要有单独的仓库来维护 Helm 制品。 这就省去了为实际的代码和 Helm 模板维护两个独立仓库的工做。 开发人员能够对任何应用程序代码更改所需的模板更改有更多的控制权。

Nexus 做为 Docker 镜像和 Helm chart（使用的是 Helm Nexus 插件）的仓库。 每次成功构建应用程序后，镜像和 chart 都是可用的并被推送到 Nexus 。

持续部署组件

为了实现与云无关的准备，咱们选择了 Terraform ，由于它易于学习并易于部署。 咱们发现对于准备后的配置管理/维护活动， Terraform 并非很是有用，因此咱们还放置了一些 Ansible 脚本。 咱们也曾考虑 Ansible 用于准备，可是使用 Terraform 可让咱们更好地控制启动实例， 这些实例能够做为 Rancher Server/节点，而且能够被自动的添加到自动伸缩组中。 咱们使用启动脚本功能实现了这一点。

咱们认为能够将为 AWS 编写的大多数 Terraform 脚本重用到 Azure 中，但事实并不是如此。 咱们必须作出至关大的改变。

咱们部署了一个运行在三个不一样实例上的高可用的 Rancher Server ，前面有一个 NGINX Server 来为这三个实例作负载均衡。 部署是使用 Terraform 和启动脚本完成的。 脚本使用 RKE ( Rancher Kubenetes 引擎)和 Rancher API 调用来启动集群(高可用的 Rancher Server )。

Rancher 提供了各类选项来在不一样的云提供商上添加 Kubernetes 集群。 您能够从选项中进行选择，使用托管的 Kubernetes 提供商，或者使用基础设施提供商的节点或自定义节点。 在这个场景中，咱们选择使用 AWS 和 Azure 上的自定义节点，而不是托管的 Kubernetes 提供商。 这帮助咱们向自动伸缩组添加一组工做节点，并使用集群自动伸缩器进行节点伸缩。

全部这些都是经过启动脚本和 Rancher API 调用自动完成的，所以任何经过 ASG (和自动伸缩器)添加的新节点都会自动注册为一个 Rancher/Kubernetes 节点。 经过启动脚本自动执行的一些活动包括:

• 安装和配置所需的 Docker 版本
• 在全部实例上安装和配置 Zabbix 代理(稍后将在监控中使用)
• 安装所需的 GlusterFS 客户端组件
• 安装所需的 kubectl 客户端
• 后端数据库集群所需的任何其余自定义配置
• 自动挂载额外的 EBS 卷和 GlusterFS 卷
• 为 Rancher 代理/Kubernetes 节点运行 Docker 容器并附加特定的角色( etcd/controlplane/worker )
• 检查以确保 Rancher 代理可用、启动和运行。

GlusterFS 被考虑能够处理 EBS 和 Azure 中不可用的 ReadWriteMany 磁盘卷类型。 这对于咱们部署的许多应用程序都是必需的。

一个 ELK stack ( ElasticSearch、Logstash 和 Kibana )使用 Helm charts 部署在 Kubernetes 上， 并被配置为经过 logstash 推送容器日志、审计和其余自定义日志。

HAProxy 和 NGINX 被用于两个不一样的目的。 NGINX 是在 Rancher Server HA 设置期间所提供的默认 ingress controller 。 这用于三个 Rancher Server 的负载均衡。 咱们在 Kubernetes 集群上部署了一个 HAProxy Ingress Controller， 这样咱们就能够经过这些特定的节点(其 IPs 映射到特定的 FQDNs)暴露应用程序的 end points 。 HAProxy ingress controller 被部署为 daemonset ，所以对于任何额外的负载，节点的数量会基于自动伸缩组和自动伸缩器自动增长。

持续监控组件

咱们部署了 Prometheus、Grafana 和 Alertmanager 套件，用于容量规划以及监控 Rancher/Kubernetes 集群的状态。 这再次经过 Rancher Helm Chart Provisioner 部署。 咱们也能够经过常规的/稳定的 Helm charts 来部署它。 它确实有助于咱们监控和收集开发环境中诸如 CPU、内存利用率和 IO 操做之类的指标，并据此为 staging 环境和生产环境进行容量规划。

咱们还在集群上部署了 Zabbix Server，它用于为部署的全部节点监控各类操做系统级别的和应用程序特定的指标和警告。 这包括任何后端数据库集群节点、Kubernetes 节点、Rancher servers、文件服务器或经过 Terraform 提供的任何其余服务器。 Zabbix Server 被配置为节点/代理自动注册，以便经过自动缩放组或自动缩放器添加到集群中的任何新节点均可用于监控。

结论

这是咱们为 Kubernetes 工做负载构建完整的 CI/CD 工具链所遵循的方法之一。 这个模型帮助咱们自动化全部的三个环境的准备。 经过 Rancher ，咱们可以提供一个开发环境，每一个开发人员均可以使用这个项目概念。 每一个开发人员都有一个节点和一个项目，它由 RBAC 控制，这样他们就能够部署和测试他们本身的更改。 没有人能够看到项目/节点的详细信息，也不会妨碍其余开发人员部署的 Kubernetes 工做负载。 因为节点自动注册到 Rancher Server，系统从新启动不会影响节点的可用性。 即便在最坏的状况下，若是节点丢失，也很容易在几分钟内打开一个新节点。 应用程序可使用 Helm charts 进行部署，也可使用 Rancher 提供的内置的 Helm charts 进行部署。

这些是咱们部署的来管理整个环境的一些高级组件。 咱们考虑的其余方面是高可用性集群环境，用于 Rancher servers、Kubernetes 集群、Gluster 文件服务器集群或任何其余后端集群。 在提出此方法时，须要考虑生产级环境所需的更改和更新。 还考虑了其余方面，例如对集群实例的安全访问、升级、备份和恢复，以及根据行业标准提出的分层体系结构建议。

但愿本文为您提供一些参考，当您计划为多个云提供商提供生产级环境准备时，能够考虑这些参考。

译者：王冬辉