本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

使用 kit 部署到多个 Kubernetes 集群

作者：Chesley Brown (InVision) |

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

Kubernetes 的出现

去年 12 月，在我们评估编排器和调度器时，Kubernetes 进入了我们的生活。AWS ECS 仍是新事物，Docker 刚刚发布了 1.9 版本（网络覆盖发布）。我们花了一个月的时间评估我们的选择，将其范围缩小到原生的 Docker 工具（Machine、Swarm、Compose）、ECS 和 Kubernetes。毋庸置疑，Kubernetes 显然是我们的赢家，我们从新的一年开始便全力以赴地利用 Kubernetes 来实现生产。但很快我们就遇到了一个小麻烦……

自动部署的陷阱

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

拥有几个近乎重复的集群很容易演变成 Kubernetes 清单的噩梦。反模式比比皆是，我们复制粘贴 95% 的清单来获取一个新集群。可伸缩吗？不。令人头疼吗？是的。让这些清单保持最新和准确将是一项艰巨（且容易出错）的任务。我们需要更简单的方法，一种允许重用、降低维护成本并且可以融入我们 CI/CD 系统的工具。

因此，在寻找能够满足我们需求的项目或工具后，我们一无所获。在 InVision，我们喜欢创建工具来帮助我们解决问题，考虑到我们可能不是唯一处于这种情况的团队，我们决定卷起袖子，创建了自己的工具。结果就是我们的开源工具 kit！（Kubernetes + git 的缩写）

你好，kit！

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

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

开发人员只需像往常一样将代码提交到他们的分支，kit 就会部署到所有运行该服务的集群。然后，Kit 直接管理更新给定服务所使用的镜像和标签到包含所有 kit 清单模板的存储库中。这意味着您集群中的所有更改，无论是环境变量、配置还是镜像更新，都将在源代码控制历史中进行跟踪，为您拥有的每个集群提供审计跟踪。

我们已将所有这些开源，您可以查看 kit 存储库！

kit 适合我们吗？

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

那么组件有哪些？

Kit 由几个相互构建的组件组成。一般的流程是开发人员将代码提交到其存储库，构建镜像，然后 kit-image-deployer 将新镜像和标签提交到您的清单存储库。从那里，kit-deploymentizer 运行，解析您的所有清单模板以生成原始 Kubernetes 清单文件。最后，kit-deployer 运行，获取所有已构建的清单文件并将其部署到所有相应的集群。以下是组件和流程的摘要

kit-image-deployer
一种服务，可用于使用新的 Docker 镜像路径更新 Git 存储库中给定的 YAML 文件。这可以与 kit-deploymentizer 和 kit-deployer 协同使用，以自动更新跨多个集群的服务所使用的镜像。

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

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

接下来是什么？

在不久的将来，我们希望使部署更加智能化，以处理更新 MongoDB 副本集之类的任务。我们还希望添加智能监控，以进一步改进 Kubernetes 的自我修复特性。我们还在努力添加额外的集成（例如 Slack）和通知方法。最重要的是，我们正在努力将更多控制权转移给各个服务的开发人员，方法是允许 kit 清单模板存在于每个单独的服务存储库中，而不是单个主清单存储库中。这将使他们能够完全从开发到生产，跨所有集群管理他们的服务。

我们希望您能仔细查看kit，并告诉我们您的想法！查看我们的InVision Engineering博客，了解更多关于我们在 InVision 所做的精彩事情的帖子。如果您想参与 kit 或其他类似有趣的项目，请点击访问我们的招聘页面。我们期待您的来信！