使用自定义控制器解决Kubernetes配置问题

作者: Joel Speed

Joel是Pusher的云基础架构工程师，致力于构建其内部Kubernetes平台，有四年多的DevOps工作经验。 最近一直专注于扩展Kubernetes的能力，构建鉴权和自定义资源控制器以改善平台上的开发人员体验的项目。Joel热衷于自动扩展，部署流水线，身份验证和授权。 他还为Pusher工程团队建立并维护了一个ChatOps机器人Marvin。

【编者的话】我们都知道，Kubernetes中的应用配置存储在ConfigMaps和Secrets中，但是它们都没有版本化，也没有控制循环。然而如果做了多次变更，由于没有版本控制，不知道到底发生了什么，也无法回滚，这将是一件多么可怕的事情。本文作者就此问题提出了一个解决方案——Wave，相信也可以解决你遇到的同样的困境。

两年前， Pusher 开始构建一个基于Kubernetes的内部平台。当我们从单一产品转变为多产品的公司时，我们希望帮助产品团队花更少的时间处理共享问题（例如基础设施），能够更加专注于实现产品的业务逻辑。

在这段时间里，我们的平台团队已经解决了许多Kubernetes没有解决的问题。直到最近，我们还没有解决配置问题。遗憾的是，与大多数资源不同，普通的Kubernetes集群对配置(存储在ConfigMaps和Secrets中)的更改不会触发对集群中正在运行的应用程序状态的更改。

我们平台上运行的许多应用程序，包括自研和第三方的，都不能动态地重新加载其配置。当配置更新时，虽然可以更新挂载到容器中的文件（如果它们来自ConfigMap），但应用程序不会监视更改，只会在重新启动进程时加载新配置，或者更通常的情况是，新的Pod已创建并且现有Pod已终止。

由于Kubernetes通常会为你协调所需的状态，因此典型的用户可能会认为更新ConfigMap或Secret会使应用程序加载新的配置。然而情况并非如此，用户很容易更新ConfigMap或Secret，而不替换挂载配置的Pods，从而导致应用程序正在使用的配置与更新后的所需配置不同。

我们的配置困境

通常在Kubernetes中，当你更新所需状态时，会有一些控制循环监视全局的状态，并调整状态以使其与你所需的更改保持一致。 在部署中更新Pod的模板时，部署控制器将使用新的Pod替换所有现有的Pod，以匹配更新的规范。

Kubernetes中的配置存储在ConfigMaps和Secrets中，它们通过文件或环境变量挂载到Pod中，以允许容器进程读取数据。但是，这种方法存在一个问题。 ConfigMaps和Secrets都没有版本化，也没有控制循环。更新ConfigMap将更新Pod中挂载的文件，而更新Secrets不会触发群集内的任何更改。

Pusher平台上的产品依赖于一个称为Bridge的关键组件。Bridge是我们入口层的一部分，将流量路由到后端服务，并在此过程中处理大量Pusher协议逻辑。遗憾的是，Bridge不能动态地重新加载其配置。

该组件对于运行在平台上的所有产品（Chatkit、Beams、TextSync）的运行都是必不可少的，当它宕机时，其他一切都会随之而去。

在过去的两年里，我们在平台上没有发生太多的事故(诚然，我们只有GA几个月)，但是当我们遇到停机时，事后分析几乎总是得出相同的结论。在Bridge中运行的配置不是它所挂载的ConfigMap中的配置。

由于对Kubernetes集群进行更改，大多数事件都是由一个基础架构团队触发的。 我们以不可变的方式运行所有机器，因此，当我们想要进行更改时，我们会替换集群中的每个节点，反过来又替换每个Pod。新的Pods将从该点存在的配置开始运行。

我们发现，尽管我们已经采用了相应的程序，但在更新配置时，我们组件的Pod并不总是被替换，在某些情况下，只有在应用了破坏的配置后两周才更换Pod。 如果你曾经遇到过同样的情况，你就会明白，如果不知道发生了什么更改，并且由于没有版本控制，无法回滚，这是一件多么可怕的事情。

我们是如何解决问题的

我们目前正在使用我们的GitOps项目 Faros 自动化我们的部署流水线。我们的平台服务团队拥有许多服务，无法动态重新加载配置并引发对项目的担忧。为了能够在git merge上同步配置更新，他们需要保证实际部署配置更新，并且在配置中断的情况下，会有人通知git还原他们刚刚部署的更改。

这就是我们的新项目 Wave ，一个使用 Kubebuilder 构建的自定义控制器的用武之地。Wave的作用是确保在更新ConfigMap或Secrets时，任何部署安装该ConfigMap或Secret都会替换它的所有Pod。Wave有效地推动了Kubernetes内置 Deployment 控制器并使其执行滚动更新，删除运行旧配置的Pod并使用更新的配置创建新Pod。

Wave的工作原理

与其他Kubernetes控制器一样，Wave订阅Kubernetes API for Deployment对象中的事件。 这意味着，只要对部署执行操作（创建/读取/更新/删除），Wave就可以处理部署并查看是否需要更改。

Wave所做的第一件事就是检查部署中是否存在 Annotation （wave.pusher.com/update-on-config-change:true）。 如果Annotation不存在，Wave将忽略该部署。 这使得Wave成为一个选择加入控制器并从Wave中受益，用户必须手动分配他们的部署由Wave管理。 因此，可以安全地部署到现有的Kubernetes集群，而无需担心它会突然开始干扰不需要其更新触发功能的已部署工作负载。

其次，Wave解析部署并查找对挂载到部署创建的Pod中的ConfigMaps和Secrets的引用。 然后它获取每个挂载的ConfigMaps和Secrets，并使用可重现的算法，创建当前配置的哈希值。 哈希表示所有已挂载的ConfigMaps和Secrets的配置，只有在添加新的挂载，删除或修改挂载中的数据中的字段时才会更改。

然后将此哈希作为Annotation放置在部署中的 Pod模板 上。 这是我们利用内置Kubernetes Deployment控制器的地方。通过修改Pod模板的元数据，Deployment控制器将其计为更新并开始处理Deployments更新策略。

总之，每当更新配置时，Wave计算的哈希将更改，Wave将更新部署的Pod模板上的哈希，然后部署控制器将读取更新策略并通过创建新的ReplicaSet开始新配置的部署。

由于Wave还订阅了ConfigMaps和Secrets的事件，因此它可以使用 Owner References 来跟踪哪些部署正在挂载哪些ConfigMaps和Secrets，并且每当其中一个更新发生时，就会协调父部署更新其哈希值。但是，我们不使用 Owner References 的垃圾收集部分。一旦部署标记为删除，Wave将删除所有所有者引用，否则部署的ConfigMaps和Secrets也将被删除。

下一步的计划

Wave工作尚未完成！目前它仅支持部署，将来我们计划为Wave添加一项功能，以触发Daemonsets和Statefulsets的更新。

我们已将Wave部署到我们的系统中，并在我们的团队内和整个组织中实现了大量部署。 自从开始使用它以来，我们一直在更快地捕获破坏的配置（没有更多的生产事件）并且能够减少大量的手动部署过程（部署配置，慢慢重启pod）。

该项目已经解决了我们最长期存在的问题之一。我们现在部署时更有信心，并且知道所需配置的更新实际上将在应用后立即运行。

原文链接： Solving Kubernetes Configuration Woes with a Custom Controller

译者：Mr.lzc，软件工程师、DevOpsDays深圳核心组织者，目前供职于华为，从事云存储工作，以Cloud Native方式构建云文件系统服务，专注于K8s、容器及微服务领域。