使用 Kubernetes 在 Wercker 引导自动化平台

在 Wercker，我们运行数百万个容器来执行我们用户的 CI/CD 任务。其中绝大多数是短暂的，只持续构建、测试和部署运行所需的时间，其余的也是短暂的（我们所有人不都如此吗？），但往往持续时间稍长，并运行我们的基础设施。由于我们在许多节点上运行大量容器，我们需要一个高度可伸缩的调度器来让我们的工作更轻松，因此我们决定实现 Kubernetes。

Wercker 是一个以容器为中心的自动化平台，帮助开发者构建、测试和部署他们的应用。我们支持各种管道，从构建代码、测试微服务间的 API 合约，到将容器推送到注册中心，以及部署到调度器。所有这些管道任务都在 Docker 容器中运行，每个产物都可以是一个 Docker 容器。

当然，我们也使用 Wercker 来构建 Wercker，并将它部署到 Kubernetes 上！

概述

因为我们是一个运行多服务云原生代码的平台，所以围绕隔离性做出了许多设计决策。在基础层面，我们使用 CoreOS 和 cloud-init 引导一个由异构节点组成的集群，我将其命名为 Patricians（贵族）、Peasants（平民），以及没有炫酷名称仅称为 Controllers（控制器）的控制节点。也许我们应该改用 Constables（警员）。

Patrician 节点是我们大部分基础设施运行的地方。这些节点具有适当的网络接口，可以与我们的后端服务通信，并可以由各种负载均衡器进行路由。这里聚合日志并发送到日志服务，运行我们众多用于报告和处理任务运行结果的微服务，以及处理 API 调用的众多微服务。

在光谱的另一端是 Peasant 节点，公共任务在此运行。公共任务由从任务队列读取的工作 Pod 组成，并动态生成新的 runner Pod 来处理任务的执行。任务本身是我们开源 CLI 工具的一个实例，与你在安装 Docker 的笔记本电脑上运行的工具相同。这些节点对基础设施其余部分的访问非常有限，并且任务本身运行的容器进一步隔离。

控制器就是控制器，我敢说我们的看起来和你的一模一样。

动态 Pod

我们对 Kubernetes API 最重要的使用绝对是我们创建动态 Pod 的系统，它们作为实际任务执行的运行时环境。从队列中拉取任务描述后，我们定义一个新的 Pod，其中包含检查代码、管理缓存、执行任务和上传产物所需的所有相关环境。我们启动 Pod，监控其进度，并在任务完成后将其销毁。

Ingress

为了提供 HTTP API 调用的后端并允许处理程序自我注册，我们使用了 Kubernetes 的 Ingress 系统。设置它并非最清晰的事情，但仔细阅读足够的 nginx 示例最终使我们找到了一个很好的方式，可以轻松地将服务连接到前端。

1.3 版本即将推出的功能

虽然我们通常将所有的 Pod 和容器视为短暂的，并期望在失败时快速重启，但我们期待 Pet Sets 和 Init Containers 作为优化我们部分流程的方式。我们也对 Minikube 的官方支持感到高兴，因为它改进了我们的本地测试和开发。 

结论

Kubernetes 使我们免去了在众多节点上管理海量容器这一复杂任务。它提供了强大的 API 和工具来检查这些容器，并内置了对日志记录、指标、监控和调试的大量支持。仅仅服务发现和网络功能就为我们节省了大量时间，极大地加快了开发速度。

为 Kubernetes 干杯，继续努力 :)

• ←上一页
• 下一页→