使用 Kubernetes 构建自动化平台

[Tenxcloud10]

编者按：本文由 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 是控制器，对于这类节点的功能，你尽管望文生义就对了。

动态 Pods

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

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

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

Ingresses

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

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

1.3 即将发布的功能

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

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

结论

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

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

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

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

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

原文链接： http://blog.kubernetes.io/2016/07/automation-platform-at-wercker-with-kubernetes.html