使用 Kubernetes 构建自动化平台

编者按：本文由 Wercker CTO Andy Smith 分享，他分享了 Kubernetes 如何帮助他们节省时间并加速开发。本文是关于 Kubernetes 1.3 新功能一系列深入文章的第九篇。

我们在 Wercker 运行数百万容器执行用户的 CI/ CD 工作。这些容器的生命周期大多是短暂的，构建、测试和部署完成后，这些容器的生命周期随之结束。

虽然多数容器的生命是短暂的，但我们倾向于持续运行我们的基础设施。通常情况下我们需要跨多节点运行多个容器，所以一个高度可扩展的调度程序就显得非常有必要。我们决定使用 Kubernetes 。

Wercker 是容器中心自动化平台，它帮助开发人员构建、测试并部署应用程序。

我们支持任何数量的 pipelines ，从代码构建、测试微服务间的 API 协议、上传镜像和部署到调度器。

所有这些 pipeline 都运行在 Docker 容器中，而且每个环节都是一个 Docker 容器。

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

概述

我们是一个运行云原生应用的平台，在隔离上做了很多设计决策。在底层，我们使用 CoreOS 和 cloud-init 启动一个异构节点的集群，我把这些节点命名为 Patricians （贵族）、 Peasants （农民）、 Controller （控制器）。

对于 Controller 节点，也许我们应该使用 Constables （警察）这个叫法。

贵族节点占据我们基础设施的一大部分，这些节点有适当的网络接口与后端服务通信，同时还作为各种负载均衡器的 endpoints 。

这些节点上还运行着下面三类服务：

1.日志搜集服务，并发送到日志服务

2.很多用于报告和处理 job 运行结果的服务

3.处理 API 调用的微服务

农民节点用于运行公共服务，包括处理 job 的 Pod ，它用于从 job 队列读取 job ，并声称新的 pod 以处理 job 的执行。

job 本身是开源 CLI 工具的化身，你可以用 Docker 安装并运行在你的笔记本上。

农民节点对基础设施的访问权限十分有限，运行 job 的容器也是高度隔离的。

Controllers 是控制器，对于这类节点的功能，你尽管望文生义就对了。

我们的服务对 Kubernetes API 有重度依赖，每一个 job 启动时，系统都会动态创建 Pod ，这个 Pod 为 job 提供了运行环境。

从队列中获取 job 描述后，我们定义了一个新的 pod ，新的 Pod 包含执行检查代码、缓存管理、执行 job 并上传结果的相关环境。

我们启动 pod ，监控它的进程，并在 job 结束后销毁它。

为了给 HTTP API 提供后端服务，并提供自注册功能，我们使用了 Kubernetes 的 Ingress 功能。

设置 Ingress 并不是很简单，但是通过阅读 nginx 例子，我们最终发现了一个将后端服务连接到前端的好方法。

尽管我们把 pods 和容器当成是短暂的，并期望它能够在故障时快速重启，同时我们也期待使用 Pet Sets 和 Init Containers 优化我们的工作流。

对于 Minikube 得到官方支持，我们也很欣慰，因为它提高了我们的本地测试和开发的效率。

Kubernetes 在管理跨节点的多个容器时，为我们省掉了大量的关键工作。

它提供了一个强大的 API 和工具来查看，包含多内置日志支持、度量、监控和调试。

仅服务发现和网络这两项就为我们节省了很多时间，大大加速了开发进度。

祝 Kubernetes 正式版一周年快乐，也祝愿它越来越好：）。

本文由时速云翻译，如若转载，需注明转载自“时速云”