通过自定义 Kubernetes 资源验证实现开发人员护栏
通过自定义 Kubernetes 资源验证实现开发人员护栏
翻译自 Developer Guardrails with Custom Kubernetes Resource Validators 。
什么是 Validator，是什么让它们如此强大？
如果你的组织开始采用云原生技术，你可能仍在努力确定如何将 Kubernetes 知识内部化并分发给团队中的其他成员。这并不是对你的团队的抨击——这是一个如此普遍的关注点，以至于云原生计算基金会开发了云原生成熟度模型，帮助组织了解它们有效地应对新工具和不同文化需求的能力。
但需求很明确：为了高效工作并产生高质量的部署，您组织的整个技术团队需要扩展其 Kubernetes 专业知识。
这更具先见之明，因为 DevOps 文化和 GitOps 流程要求更多的工作和认知负荷应该“左移”并更早地纳入软件开发生命周期。现在要求开发人员从他们的第一行代码中纳入安全和 IT 运营最佳实践。他们需要在许多不完全理解的方面负责。
技术组织结构图的另一个分支是平台工程，它承担着防止开发人员部署崩溃、导致级联问题或过度使用昂贵的云资源的新应用程序和资源的任务。毕竟，平台工程师的工作是建立自动化和流程，将基础设施推向梦寐以求的零错误状态。
但是随着新技术的发展和 Kubernetes 知识的发展，平台工程师需要一种基于自动化的可行策略，该策略可以解除对开发人员的阻碍并对其进行培训，同时保持高质量的代码。
文档很棒，但平台工程师不应该花时间以这种方式整理知识——正如我们许多人从自己的经验中了解到的那样，目标受众实际阅读它（更不用说遵守它）的可能性非常低.
平台工程真正应该做的是为组织中的开发人员提供护栏，这些护栏可以作为正在进行的预部署开发人员工作流程的一部分轻松应用、强制执行和自动化。提供这些护栏的一种非常简单的方法是使用易于部署的验证框架为您的 Kubernetes 应用程序配置创建自定义策略。
为什么要验证？
答案很简单：不应允许开发人员提交违反组织政策的代码或配置。
Validator 在提交阶段执行策略，直接在开发人员使用的集成开发环境 (IDE) 中执行，或者作为 CI/CD 管道中的初始检查（或者，理想情况下，在两个阶段）。在您的 CI/CD 管道花费宝贵的时间和云资源部署不可避免会失败的代码之前，简单的错误（例如无效的 YAML 语法）会被 Validator 捕获并拒绝。
通过在提交阶段强制执行标准，您可以在软件开发生命周期的早期构建质量并在此过程中简化您的流程。
您可以通过遵循两个相对简单的规则来建立一种验证文化：
如果您的组织两次犯同样的错误，平台工程师就该将其编入规则，供您的验证者标记和阻止。
您组织的政策应该是独一无二的，并且是根据您的需求、目标和文化定制的，而不是您从 StackOverflow 或 GitHub 复制粘贴的东西。
自定义 Validator 的力量
现在，任何开发人员都可以直接从他们的 IDE 中使用 Validator。最流行的例子之一是直接在 VS Code 中使用 ESLint 来执行各种代码质量标准，就像它们在 TypeScript/JavaScript 项目（如 React 或 Svelte）上那样。
但捆绑到这些工具中的政策——或者开发人员可以从 Airbnb 这样的组织集成的工具——并未涵盖开发人员可能将 Kubernetes 部署带入错误方向的大多数方式。
当您的组织两次犯同样的错误时，它们不会响应制定新政策的需要，而且它们不是为您组织的独特技术栈和文化冲动而设计的。
自定义 validator 通过自动化无缝地解决了这两个问题。您的平台工程师将他们对 Kubernetes 的深入理解和强烈意见编入该组织特定的政策中。平台工程师无需持续手动干预，例如在 PR 后请求更改拉取请求 (PR)，而是被动地防止错误配置。
从开发人员的角度来看，自定义验证器不会对他们的日常工作产生太大影响。当他们开发 Kubernetes 应用程序和资源时，他们的 IDE 会在警告或错误阶段通知他们策略配置错误，这是由平台工程设置的护栏，这会阻止他们从一开始就提交违反组织策略的代码。
您的自定义验证器现在正在被动地提高代码库的质量，而不会为开发人员增加任何额外的认知负担，从而使他们能够快速交付。平台工程师通过自动化实现零错误，开发人员开始通过每一行代码学习 Kubernetes 最佳实践。
超越验证是错误的
大多数组织可能很幸运，每 10 名开发人员就有一名平台工程师，这意味着他们需要专注于自动化和 GitOps，而不是人工干预，以消除自己作为部署到生产环境的瓶颈。
记住任何平台工程团队的主要职责和目标：
- 专注于铺平道路和流程改进，例如选择正确的工具或实施自动化，为他们的“客户”（他们的应用程序开发同行）提供价值。
- 防止开发团队一次又一次地重新发明轮子，仅仅因为他们不得不担心配置和供应基础设施。
- 自动化地搭建开发人员和他们拥有的 Kubernetes 特定最佳实践之间的知识桥梁。
- 创建“胶水”和护栏，帮助开发人员构建和部署高质量的应用程序，而无需了解整个工具链或需要 DevOps 工程师的手动干预。
如果他们能完成其中任何一项，他们就会做扎实的工作，让每个人都能完成任务，保持高效并成功部署到集群。
自定义 validator 不仅可以帮助平台工程师从技术角度实现这些目标。他们还帮助团队接受教育和持续改进的文化。我们想说自定义 validator 的策略不是惩罚，而是帮助开发人员每天学习 Kubernetes 细微差别的资源。
平台工程师通过编写新规则为这种文化做出贡献，其中包括有价值的上下文，可以自动分发他们所知道的内容。在开发人员工作时，他们可以将鼠标悬停在他们的 IDE 中的错误/警告图标上，并阅读有关规则执行的策略以及他们可以采取哪些补救措施的说明。
Monokle 是“口袋平台工程师”
如果你的组织有平台工程师，他们无疑已经听说过或尝试过自定义 validator 。但许多这些工具需要一种独特的领域特定语言，当编写规则过于困难时，它就永远不会发生。平台工程师浪费时间编写文档，或者再次温柔地提醒他们的开发人员同行，如何停止向集群中引入如此多的错误。
如果这是您的组织正在努力解决的问题，或者您清楚地看到弥合平台工程师和开发人员之间差距的价值，您应该将 Monokle 的开源验证框架放在您的雷达上。
Monokle 是一个工具套件，它通过统一开发人员、DevOps 工程师和平台工程师编写、验证和推送 Kubernetes 配置的方式，帮助他们放心地进行部署。
Monokle 最近推出了一个基于 TypeScript 的自定义验证框架，它使添加新规则变得非常简单。可以使用命令行界面、GitHub Action、Monokle Desktop 工具和 Monokle Cloud 应用验证规则。甚至还有一个与 Monokle Cloud 通信的本地开发服务器，以帮助您在将新规则应用到整个组织之前测试它们。
当开发人员在 Monokle 中编写新资源时，Kubernetes 策略和左移革命背后的所有复杂性都被抽象为红灯或绿灯——不再有认知负担。由于 Monokle 的内置上下文信息，开发人员可以开始将每一次错误配置转化为教育机会。
腾讯云开发者
