Kubernetes 在开发方面给我的启示

为什么策略管理是理解 Kubernetes 和 DevOps 管道的关键。

作为一名全栈开发人员，尤其是前端开发人员，DevOps 技术和 DevOps 开发人员的思维方式对我来说一直是个谜。当我工作的公司推出一个新的命令行界面 (CLI) 应用程序 Gatekeeper 时，我便投身于 DevOps 和 Kubernetes 的世界，而我所学到的东西被证明非常有价值。现在，我对 Kubernetes 和 DevOps 管道有了更好的理解，并且我可以更好地解释我们的 CLI 应用程序如何同时支持它们两者。

这是我的故事。

关于我

我叫 Noaa Barki。我担任全栈开发人员已有五年多，目前在一家名为 Datree 的出色公司工作，我们致力于帮助开发人员和 DevOps 工程师防止 Kubernetes (K8s) 错误配置进入生产环境。

理解问题

想象一下：您度过了漫长的一周，现在是星期五，您正在平静地做梦，准备迎接一个长周末。然而，您的周末比预期的来得更早，因为凌晨 3:46 您被手机铃声吵醒，此前您错过了 15 个工作来电。显然，您忘记在其中一个部署中添加内存限制，这导致其中一个容器中出现内存泄漏，从而导致所有 Kubernetes 节点耗尽内存。

这怎么会发生？您的 DevOps 团队花费了大量精力来教育开发人员关于 K8s 以及内存限制的重要性。

为了避免此类事故，您必须为理想的解决方案设定要求，并寻找有助于防止错误配置影响集群的平台和库。实际要求可能因您的基础设施而异，但这里有一个很好的例子

在开发阶段强制执行策略限制： 一种在将资源应用到集群之前强制执行限制的方法
启用限制管理： 在整个组织的专用位置灵活管理限制，使管理员能够完全控制其所有系统
普及最佳实践： 将 DevOps 团队从不断审查、防范和面向未来地应对所有当前和未来用例中可能出现的陷阱的需求中解放出来，这些用例是自助部署的一部分。

作为一名开发人员，工作就是解决现实生活中的问题，但有时上下文会产生很大的影响。您必须首先了解问题是如何发生的，然后才能有效地解决它。

组织为什么要采用 K8s？
DevOps 工程师的角色是什么？
最重要的是，我为谁开发我的应用程序？

谁是 DevOps 工程师？

最初，我对 DevOps 工程师的角色知之甚少，对他们的技术，尤其是 Kubernetes 也几乎一无所知。我阅读、研究并采访了我的 DevOps 朋友，了解他们的工作和职责。我问了诸如此类的问题

您的日常目标是什么？
您的客户是谁？
您的一天是怎样的？

我花了一段时间，但几个月后，我终于找到了答案——或者，说实话，是鼓起勇气去体验 DevOps 的工作。

令人惊讶的是，最有帮助的事情是认识到我们只是用不同的术语思考。 DevOps 工程师必须在他们的头脑中缩小范围。他们从最小的应用程序组件开始，然后像洋葱一样在其之上进行扩展和构建。

另一方面，开发人员可以从相同的应用程序组件开始，但他们习惯于以相反的方向思考：从高层到软件的位和字节。开发人员剥离层——从服务器到服务，再到函数，再到变量，再到它的内存分配——直到我们到达最小的组件。每个人都在管道的相反边缘工作，但我们都在同一个管道上工作。

这让我感到好奇，如果解决方案在管道的某个位置，双方都可以集成的东西会怎么样？

思考解决方案是否应该是管道的一部分，这让我开始思考 DevOps 和开发人员可能还有什么共同点。我思考了作为开发人员的工作流程，并将它们与 DevOps 开发人员的工作流程进行了比较，直到突然，我意识到了

我们都有策略。

为什么您不能总是依赖 OPA

开发人员和工程师都有标准和最佳实践，我们努力维护这些标准和最佳实践，以便对我们的工作更有信心。作为一名开发人员，我使用 SOLID 和整洁代码原则、单元测试和集成测试，并且我尝试学习我使用的每项技术的最佳实践。

一天早上，我问我的 CEO：“作为一名 DevOps 工程师，您的策略是什么？您使用什么来创建和管理您的策略？” 他看着我的眼睛，说了一个词：“OPA。”

什么是 OPA？

OPA 是 Open Policy Agent 的首字母缩写，它就像一个超级引擎。您可以在其中编写所有策略，然后使用每个输入执行它，以检查它是否违反任何策略，如果违反，则以何种方式违反。 OPA 背后的主要思想是将策略决策逻辑与策略执行用法分离的能力。

假设您在多服务架构中工作。您可能需要做出策略决策，例如，当该微服务收到 API 请求（如授权）时。该逻辑基于您组织中的预测规则，因此，在这种情况下，您可以将所有决策逻辑卸载并统一到一个专用服务：OPA。

如何使用 OPA

与 OPA 集成： 如果您的服务是用 Go 编写的，您可以将 OPA 作为包嵌入到您的项目中。否则，您可以将 OPA 部署为主机级守护程序。
编写和存储您的策略： 要在 OPA 中定义您的策略，您需要使用 Rego 编写它们并将它们发送到 OPA。这样，每当您使用 OPA 进行策略执行时，OPA 都会根据这些策略查询输入。
请求策略评估： 当您的应用程序需要做出策略决策时，它将使用 JSON 发送 API 查询请求，其中包含通过 HTTP 发送的所有必需数据。

当 OPA 不够用时

正如您所看到的，OPA 满足了组织范围内策略管理和执行的需求，因为它是一个出色的基于实用程序的工具，并提供了出色的基础设施解决方案。然而，OPA 也需要大量的繁重工作和配置，这对于处于 интенсивного 增长中的公司来说通常太多了。

当涉及到 K8s 中的策略时，OPA 并非为小型团队量身定制，因为 DevOps 工程师可能仍然会花费太多时间来解决紧急情况。使用 OPA 并不总是执行 K8s 策略的最佳方式，但研究它让我了解了 DevOps 世界中策略是什么。

使用 ConfTest——快完成了！

ConfTest 使您能够为任何结构化文件编写测试，并且专门设计用于 CI 或本地测试。您可以将其视为结构化文件的单元测试库。 ConfTest 构建于 OPA 之上。

ConfTest 的主要用途是其 test 命令

$ conftest test deployment.yaml

这接受您要测试的文件的路径，然后评估这些文件上的所有策略。默认情况下，所有策略（单元测试）都应放置在名为 policy 的目录中，但您可以覆盖此设置。由于它构建于 OPA 之上，因此策略也必须以 Rego 编写。

此外，ConfTest 还提供从任何 Open Container Initiative (OCI) 注册表（例如 Dockerhub、Quay.io 等）推送和拉取策略的功能。

ConfTest 的问题

乍一看，ConfTest 似乎是完美的解决方案。您无需部署像 OPA 这样的服务，但从 OCI 注册表拉取和推送的能力意味着您可以在专用空间中统一您的策略，从而获得更多控制权。 ConfTest 的真正威力在于它在 CI 过程中使用时，这使得习惯于测试其代码并持续集成它的开发人员更清楚地了解 K8s 维护。

不幸的是，ConfTest 没有提供足够的策略管理能力。在专用位置统一策略是不够的。如果您想在一个服务上执行一组策略，而在另一个服务上执行另一组策略怎么办？您仍然需要一种在 CI 过程中利用测试的方法，同时还要对策略进行分组。

研究 ConfTest 使我意识到，真正的问题不仅在于强制执行您当前将要推送到集群的内容，还在于您明天可以或可能推送的内容。这就像单元测试；它的存在是为了让您确信当前或未来对代码的任何更改都不会损害现有的生产环境。您需要一个能够为未来和过去强制执行策略的解决方案。

DevOps、Kubernetes 和我

既然我已经排除了其他强制执行策略的方法，那么现在是时候开始下一次冒险并开始研究 Kubernetes 了。

如果您是一名想要和我一起进行 K8s 冒险的开发人员，我有一些技巧想要与您分享。

面向开发人员的 K8s：技巧和指南

了解 CI/CD： 如果您想开始学习 K8s，那么了解 CI/CD 管道中究竟发生了什么、CI 和 CD 之间的区别以及（最后但并非最不重要的）您的公司为何使用它是至关重要的。我从我认为我理解的最小组件（我们的微服务之一）开始，并绘制了一个图表，其中包含连接到它的所有资源和环境。我写下了从我提交代码到它神奇地出现在我的生产环境中的所有过程。
了解您的平台： 使用 Kubernetes 需要大量的配置工作，这些工作可能与 Kubernetes 本身无关。您需要了解您的平台如何工作、您使用和需要的资源以及它们如何从网络角度连接。
理解部署： 部署可能是我在 DevOps 中听到的最常见的表达，但它到底是什么？它是 Kubernetes 资源吗？一个过程？一个工件？在 Kubernetes 中，部署意味着“我的应用程序的状态”。

然而，最让我感兴趣的是我之前提到的 CLI 应用程序 Gatekeeper。了解 OPA Gatekeeper 让我明白了需要获得可见性并遍历所有策略的循环——查看哪些不合规，然后采取行动来解决问题。除了我关于 Gatekeeper 的文章外，我还建议阅读 Gatekeeper 的文档。