带自定义Kubernetes资源验证器的开发人员护栏

如果你的组织开始采用云原生技术，那么可能仍在研究如何将Kubernetes知识内部化并分发给团队的其他成员。这是一个非常普遍的问题。

需求是明确的：为了高效工作并产生高质量的部署，整个技术团队需要扩展Kubernetes知识。

DevOps文化和GitOps流程要求更多的工作和认知负载应该“向左转移”，并更早地纳入软件开发生命周期。开发人员现在被要求从第一行代码开始就纳入安全和IT运维最佳实践。他们越来越卷入一个不完全理解的系统的多个方面。

技术组织结构图的另一个分支是平台工程，它的任务是防止开发人员错误部署新的应用程序和资源，导致崩溃、级联问题或过度使用昂贵的云资源。毕竟，平台工程师的工作是建立自动化和流程，将基础设施推向令人垂涎的零错误状态。

随着新技术和Kubernetes知识的发展，平台工程师需要一种基于自动化的可行策略，在维护高质量代码的同时，解除开发人员的限制并让他们学习。

文档是很好的，但平台工程师不应该把时间花在这个上，而且目标受众阅读（更不用说遵守）的可能性很低。

平台工程真正应该做的是为开发人员提供护栏，这些护栏可以作为正在进行的部署前开发人员工作流的一部分，轻松应用、实施和自动化。提供这些护栏的一个简单方法是，为Kubernetes应用程序配置用易于部署的验证框架创建自定义策略。

为什么要验证？

答案很简单：不应允许开发人员提交违反组织政策的代码或配置。

验证器在提交阶段执行策略，可以直接在开发人员使用的集成开发环境（IDE）中执行，也可以作为CI/CD管道中的初始检查（或者理想情况下，在两个阶段都有）。在CI/CD管道花费宝贵的时间和云资源部署必定会失败的代码之前，简单的错误（如无效的YAML语法），被验证器捕获并拒绝。

通过在提交阶段实施标准，你可以在软件开发生命周期的早期保证质量，并在此过程中简化流程。

你可以通过以下两个相对简单的规则来建立验证文化：

——如果组织犯了两次相同的错误，那么平台工程师应该将其编码为规则，以便验证器进行标记和阻止。

——组织的策略应该是独特的，并根据需求、目标和文化进行定制，而不是从StackOverflow或GitHub复制粘贴。

自定义验证器的功能

现在，任何开发人员都可以直接从IDE使用验证器。最流行的例子之一是在VS Code中直接使用ESLint来强制执行各种代码质量标准。

但绑定到这些工具中的策略，或者开发人员可以从Airbnb这样的大型组织中集成的策略，并没有涵盖开发人员错误部署Kubernetes的大部分方式。

当组织两次犯同样的错误时，它们不能满足制定新策略的需要，而且它们不是为组织的独特技术堆栈和文化冲动而设计的。

自定义验证器通过自动化无缝地解决了这两个问题。平台工程师将他们对Kubernetes的知识和观念编入特定于组织的策略中。平台工程师被动地防止错误配置，而不是不断的手动干预，比如在PR后请求更改拉取请求（PR）。

从开发人员的角度来看，自定义验证器对日常生活没有太大的改变。当他们开发Kubernetes应用程序和资源时，他们的IDE会在警告或错误阶段通知策略错误，这是平台工程设置的护栏，从一开始就阻止他们提交违反组织策略的代码。

自定义验证器被动地提高了代码库的质量，而不需要为开发人员增加任何额外的认知负载，这使他们能够快速完成工作。平台工程师自动化了实现零错误的方法，开发人员开始用每一行新代码学习Kubernetes的最佳实践。

超越验证

大多数组织可能很幸运，每10名开发人员就有一名平台工程师，这意味着他们需要专注于自动化和GitOps（而不是人工干预），以消除部署到生产中的瓶颈。

记住平台工程团队的主要职责和目标：

——专注于为应用程序开发人员提供有价值的铺设道路和流程改进，如选择正确的工具或实施自动化。

——防止开发团队一次又一次地重新发明轮子，减少对配置和供应基础设施的担心。

——自动化弥合开发人员和他们丰富的Kubernetes特定最佳实践之间知识差距的方式。

——创建“胶水”和护栏，帮助开发人员构建和部署高质量的应用程序，而无需了解整个工具链，也无需DevOps工程师的手动干预。

如果能够完成其中任何一项任务，那么他们正在确保每个人都能完成任务、高效工作并成功部署到集群中。

自定义验证器不仅仅从技术角度帮助平台工程师实现这些目标。它们还帮助团队接受教育和持续改进的文化。自定义验证器的策略不是惩罚，而是帮助开发人员每天学习Kubernetes细微差别的资源。

平台工程师通过编写新的规则为这种文化做出贡献，其中包括有价值的上下文，可以自动分配他们所知道的内容。当开发人员工作时，他们可以将鼠标悬停在IDE中的错误/警告图标上，阅读规则实施的策略以及可以采取的补救措施的说明。

Monkle是“袖珍平台工程师”

如果你的组织中有平台工程师，他们无疑听说过或已经尝试过自定义验证器。但这些工具中的许多都需要一种独特的领域特定语言，当编写规则太困难时，它很难被采用。平台工程师浪费时间编写文档，或者重复提醒开发人员如何停止在集群中引入如此多的错误。

如果这是组织难以解决的问题，或者你清楚地看到了弥合平台工程师和开发人员之间差距的价值，那么你应该考虑Monkle的开源验证框架。

Monkle是一套工具，通过统一编写、验证Kubernetes配置并将其推向生产的方式，帮助开发人员、DevOps工程师和平台工程师自信地进行部署。

Monkle最近引入了一种基于TypeScript的自定义验证框架，这使得添加新规则变得非常简单。验证规则可以使用命令行界面、GitHub Action、Monkle Desktop工具和Monkle Cloud应用。甚至还有一个与Monkle Cloud通信的本地开发服务器，可以帮助你在将新规则应用于整个组织之前测试它们。

当开发人员在Monkle中编写新资源时，Kubernetes策略和左移背后的所有复杂性都被抽象为红灯或绿灯——没有更多的认知负载。由于Monkle内置的上下文信息，开发人员可以开始将每一个错误配置转化为学习机会。