部署工具见解之Kubernetes

【编者的话】本文希望你能更熟悉Kubernetes的概念。

认真的说，你应该在Kubernetes上构建你的系统。

对我来说，对Kubernetes理解的很大转变来自于我开始思考它能提供什么，比如副本控制器、服务、pod等等。当然，你可以写一些yaml 文件来部署一些风格多样的东西。但是，有时候它可以更有用的在更高的层次上沟通事情。

通常情况下，考虑部署一个应用到一个PaaS平台。对Heroku来说，你运行git push；对Google App Engine来说，你运行appcfg.py update。平台会处理创建和配置自己的一系列资源来运行你的应用。你不需要去考虑“我需要一个副本控制器，一个服务，等等”。你只需要简单的一步来部署你的代码。在PaaS中，你不再担忧运行你的应用所需要的资源。

我感觉在Kubernetes 上构建这种类型的工作流是一个连接开发和DevOps 之间差异的临界点。开发者通常过于关注平台怎么处理应用的部署。他们写代码，然后需要一种方式来表示“这些准备部署”。DevOps 应该做这些。

Kubernetes 提供给我们工具来构建PaaS。事实上，这是一个好主意。Deis 现在重新在Kubernetes 上构建了Deis v2。虽然你能明确定义部署你的应用所需要的各种Kubernetes 资源，但是你不需要这样做。事实上，它可能是一种被反对的形式。

Noel：一个最低限度的原生集群的PaaS

我决定去看看在Kubernetes上创建一个工具来提供一个‘最低限度’的PaaS工作流有多困难。一个‘最低限度’的PaaS需要提供：

1. 零配置部署：部署代码唯一需要的只有Dockfile文件。
2. 多个应用／微服务：PaaS 应该能够容纳任意数量的应用／微服务，它们之间能够互相通信。
3. 扩容：集群管理员应该能够简单的手动扩容或缩减应用。
4. 配置管理：提供独立于代码的方式来设置配置值，就像12 factor app 中说的那样。

创建这个工具时，我决定试着在 Dokku 和 Deis 中选择一个。它们都提供了一个伟大的、简单的开发者体验。我决定提供两种应用开发的流程：

1. 本地构建：你能在一个包含Dockfile的目录下运行noel build-and-deploy，来构建部署一个应用。这是和Google App Engine 最相似的工作方式。
2. 远程构建：你能添加一个具体的远程服务区，然后运行git push noel master让远端构建并部署一个应用。

这些当前都对开发者提供了一种比直接跟Kubernetes 集群沟通更简单的工作流程。

Noel 当前发布在GitHub上。这里有一个使用远程构建流程来部署一个简单应用的示例。一旦部署完成，你能看到应用仅需几秒钟的时间来启动并提供服务， 视频

组成

Noel使用以下的几种Kubernetes 资源来将应用部署到集群中：

• 副本控制器：Noel 为部署的应用的每一个版本创建一个唯一的副本控制器。以后，Kubernetes 的部署API 能够用来回滚更新来避免停机。
• 密钥：每一个应用有一个密钥用来存储应用配置。Noel 配置应用的副本控制器来在pod中挂载密钥。
• 服务：每一个应用有一个服务来控制集群内部的流量到自己的pod 里。这允许应用／微服务在集群内部能直接互相通信。

Noel自己在集群中运行两个服务：

1. 远程构建：处理git push请求，并运行noel build-and-deploy来构建和部署应用。
2. 前端Nginx：处理代理的来自app.example.com的外部请求，到适当的应用的服务。

混合模式的集群

Noel，使用Nodel部署的应用，也能够和其他部署在集群中的任何应用一起。这是Kubnertes 中很重要的一个方面。考虑有一个应用由三个微服务组成，并且需要Redis和PostgreSQL。这个微服务是无状态的，能够简单通过比如Noel 或者Deis v2 来部署。Redis和PostgreSQL资源能够直接由集群管理者提供，或者是通过比如 helm这样的东西。你能使用Kubernetes DNS服务和密钥来将它们连接在一起。

长话短说，你不需要和Kubernetes的部署方式耦合在一起。你应该为每个你需要部署的子集选择正确的构建工具。Noel是一个很小的工具，并且被明确验证的它能够去构建你自己的工具去处理基于Kubernetes的工作流。

原文链接：Opinionated Deployment Tools & Kubernetes（翻译：覃璐）