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

在Wercker，我们运行着数百万个容器，这些容器执行着我们用户的CI/CD任务。绝大多数容器是短暂的，只持续到构建、测试和部署运行完成，其余的也是短暂的——我们不都是这样吗——但往往持续时间稍长，运行我们的基础设施。由于我们在许多节点上运行着许多容器，我们需要一个高度可伸缩的调度器，以简化我们的工作，因此决定实施Kubernetes。

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

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

概述

因为我们是一个运行多服务云原生代码的平台，所以我们围绕隔离做了许多设计决策。在底层，我们使用CoreOS和cloud-init来引导一个由异构节点组成的集群，我将这些节点命名为“贵族”（Patricians）、“农民”（Peasants），以及没有酷炫名称只被称为“控制器”（Controllers）的控制器节点。也许我们应该改名为“治安官”（Constables）。

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

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

控制器就是控制器，我相信我们的控制器看起来和您的控制器一模一样。

动态 Pod

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

Ingresses

为了为 HTTP API 调用提供后端并允许处理程序的自注册，我们利用了 Kubernetes 中的 Ingress 系统。设置起来并不算最清晰明了，但阅读了足够多的 nginx 示例 后，我们最终达到了一个很好的状态，可以轻松地将服务连接到前端。

1.3 版本即将推出的功能

虽然我们通常将所有 Pod 和容器视为短暂的，并期望在故障时快速重启，但我们期待 Pet Sets 和 Init Containers 能够优化我们的一些流程。我们也很高兴看到 Minikube 的官方支持，因为它改进了我们的本地测试和开发。

结论

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

为 Kubernetes 干杯，继续保持良好的工作！:)

• ←上一篇
• 下一篇→