这篇文章已发表一年多。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已过时或不准确。

使用 kit 部署到多个 Kubernetes 集群

作者：Chesley Brown (InVision) |

我们在 InVision 的 Docker 之旅可能听起来很熟悉。我们首先在开发环境中开始使用 Docker，努力在那里实现一致性。我们将传统的单体应用程序打包到 Docker 镜像中，并简化了 Dockerfile 以最小化大小并提高效率。事情看起来不错。我们在过程中学到了很多吗？当然。但最终，我们整个工程团队都在本地使用 Docker 进行开发环境。任务完成了！嗯，不完全是。开发是一回事，但迁移到生产环境则是另一回事了。

Kubernetes 来了

在去年 12 月评估编排器和调度器时，Kubernetes 进入了我们的视野。AWS ECS 仍然很新，Docker 刚刚发布了 1.9 版本（网络 overlay 版本）。我们花了一个月的时间评估了我们的选择，最终范围缩小到原生的 Docker 工具（Machine、Swarm、Compose）、ECS 和 Kubernetes。毫无疑问，Kubernetes 显然是我们最终的选择，我们在新年伊始就全力以赴利用 Kubernetes 进入生产环境。但没过多久，我们就遇到了一个小小的难题...

自动化部署的一个小问题

在InVision，我们面临一个独特的挑战。我们不仅仅有一个运行 Kubernetes 的生产环境，而是有好几个，所有都需要通过 CI/CD 流程进行自动化更新。尽管在这些环境中运行的代码相似，但配置却不同。我们需要让整个过程顺利、自动化地进行，因为我们无法承受在部署流程中增加阻碍或给我们的工程团队带来负担。

拥有几个几乎重复的集群很容易变成 Kubernetes manifest 的噩梦。反模式比比皆是，因为我们复制粘贴 95% 的 manifest 来创建一个新集群。可伸缩？不。头痛？是的。保持这些 manifest 最新且准确将是一项艰巨（且容易出错）的任务。我们需要一些更容易的东西，一些允许重用、维护成本低并且可以集成到我们的 CI/CD 系统中的东西。

所以在寻找能够满足我们需求的项目或工具之后，我们一无所获。在 InVision，我们乐于创建工具来帮助我们解决问题，考虑到我们可能不是唯一面临这种情况的团队，我们决定卷起袖子，自己创造一些东西。结果就是我们的开源工具 kit！（Kubernetes + git 的简称）

你好 kit！

kit 是一套组件，当集成到您的 CI/CD 系统和源代码控制中时，它允许您持续地向所需的任意数量的集群部署更新（或全新的服务！），所有这些都利用了 webhook，并且无需托管外部服务。

使用 kit 的模板格式，您可以一次性定义您的服务文件，并在多个集群中重用它们。它的工作原理是在您通常的 Kubernetes manifest 文件之上进行构建，允许一次定义它们，然后通过仅定义特定集群所需的唯一配置，在多个集群中重用它们。这使您可以轻松地构建应用程序的编排，并将其部署到所需的任意数量的集群。它还允许您对应用程序的不同变体进行分组，这样您可以拥有运行应用程序“开发”版本的集群，而其他集群则运行“生产”版本等等。

开发者像往常一样简单地将代码提交到他们的分支，然后 kit 会部署到所有运行该服务的集群。kit 随后直接将给定服务使用的镜像和标签更新到包含所有 kit manifest 模板的仓库。这意味着您集群的任何和所有更改，无论是环境变量、配置还是镜像更新，都会在源代码控制历史记录下进行跟踪，从而为您拥有的每个集群提供审计追踪。

我们将所有这些都开源了，因此您可以查看 kit 仓库！

kit 适合我们吗？

如果您正在多个集群（或命名空间）中运行 Kubernetes，并且所有都需要持续部署，那肯定适合！因为使用 kit 不需要托管任何外部服务器，您的团队可以利用您可能已经拥有的 GitHub webhook 和 CI/CD 系统来开始使用。然后，您可以创建一个仓库来托管您的 Kubernetes manifest 文件，其中说明了哪些服务部署到哪些集群。由于 kit 的模板引擎，这些文件的复杂性得到了极大的简化。kit-image-deployer 组件集成到 CI/CD 流程中，无论何时开发者提交代码到 master 且构建通过，它都会自动部署到所有配置的集群。

那么组件有哪些？

kit 由多个相互依赖的组件组成。一般流程是开发者提交代码到他们的仓库，构建镜像，然后 kit-image-deployer 将新镜像和标签提交到您的 manifest 仓库。之后 kit-deploymentizer 运行，解析所有 manifest 模板以生成原始的 Kubernetes manifest 文件。最后 kit-deployer 运行，接收所有生成的 manifest 文件并将它们部署到所有相应的集群。以下是组件和流程的摘要

kit-image-deployer
一个服务，可用于在 Git 仓库中更新指定的 yaml 文件，替换为新的 Docker 镜像路径。它可以与 kit-deploymentizer 和 kit-deployer 协同工作，以在多个集群中自动更新服务使用的镜像。

kit-deploymentizer
该服务智能地构建部署文件，以允许重用环境变量和其他形式的配置。它还支持为多个集群汇总这些部署。最终，它会生成一个集群列表以及每个集群对应的部署文件列表。最好与 kit-deployer 和 kit-image-deployer 协同使用，以实现持续部署工作流。

kit-deployer
使用此服务将文件部署到多个 Kubernetes 集群。只需将您的 manifest 文件组织到与您的集群名称（在 kubeconfig 文件中定义的名称）匹配的目录中。然后提供一个包含 kubeconfig 文件的目录，kit-deployer 将异步地将所有 manifest 发送到相应的集群。

接下来是什么？

在不久的将来，我们希望让部署更加智能，以便处理诸如更新 mongo 副本集之类的任务。我们还想增加智能监控，以进一步提升 Kubernetes 的自愈特性。我们也在努力增加额外的集成（例如 Slack）和通知方法。最重要的是，我们正在努力将更多控制权转移给每个服务的个体开发者，方法是允许 kit manifest 模板存在于每个单独的服务仓库中，而不是单一的主 manifest 仓库中。这将使他们能够完全自主地管理他们的服务，从开发直到在所有集群中的生产部署。

我们希望您能仔细看看kit并告诉我们您的想法！请访问我们的InVision 工程博客，了解我们在 InVision 所做的更多有趣的事情。如果您想参与 kit 或其他类似有趣项目的工作，请点击进入我们的招聘页面。我们很乐意收到您的来信！