这篇文章已经超过一年了。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

使用 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 流程中，每当开发人员将代码提交到主分支并且构建通过时，它会自动部署到所有配置的集群。

那么组件是什么？

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 将异步发送所有清单到它们对应的集群。

接下来是什么？

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

我们希望您仔细看看kit，并告诉我们您的想法！查看我们的InVision 工程博客，了解更多关于我们在 InVision 所做的精彩事情的帖子。如果您想研究 kit 或其他类似有趣的的事情，请点击我们的招聘页面。我们很乐意收到您的来信！