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

在 Wercker，我们运行数百万个容器来执行用户的 CI/CD 作业。其中绝大多数是临时的，只持续到构建、测试和部署完成，其余的也是临时的——我们不都是吗？——但往往持续的时间更长，并运行我们的基础设施。由于我们在许多节点上运行许多容器，我们需要一个高度可扩展的调度器，以使我们的生活更轻松，因此，我们决定实施 Kubernetes。

Wercker 是一个以容器为中心的自动化平台，可帮助开发人员构建、测试和部署他们的应用程序。我们支持任意数量的管道，从构建代码、测试微服务之间的 API 契约，到将容器推送到注册表，以及部署到调度器。所有这些管道作业都在 Docker 容器内运行，并且每个工件都可以是一个 Docker 容器。

当然，我们使用 Wercker 来构建 Wercker，并将其自身部署到 Kubernetes 上！

概述

因为我们是一个用于运行多服务云原生代码的平台，所以我们在隔离方面做出了许多设计决策。在基础级别上，我们使用 CoreOS 和 cloud-init 来引导异构节点集群，我将这些节点命名为贵族、平民，以及没有酷名称的控制器节点，它们只是被称为控制器。也许我们应该改成警员。

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

另一方面，平民节点是运行公共作业的地方。公共作业包括从作业队列读取的 worker Pod，并动态生成新的 runner Pod 来处理作业的执行。作业本身是我们开源 CLI 工具的化身，您可以在安装了 Docker 的笔记本电脑上运行相同的工具。这些节点对其他基础设施的访问权限非常有限，并且作业本身运行的容器也进一步隔离。

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

动态 Pod

我们对 Kubernetes API 的最大用途绝对是我们的动态 Pod 创建系统，它用作我们实际作业执行的运行时环境。在从队列中提取作业描述后，我们定义一个新的 Pod，其中包含用于检出代码、管理缓存、执行作业和上传工件的所有相关环境。我们启动 Pod，监视其进度，并在作业完成后销毁它。

Ingress

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

1.3 中的即将推出的功能

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

结论

Kubernetes 节省了我们在许多节点上管理许多容器的艰巨任务。它提供了强大的 API 和工具来内省这些容器，并且它包括对日志记录、指标、监控和调试的许多内置支持。仅服务发现和网络就为我们节省了大量时间，并极大地加快了开发速度。

为 Kubernetes 干杯，继续努力 :)

• ←上一篇
下一篇→