你有同感吗？关于开发，Kubernetes教会了我这些

笔者是一名全栈开发人员，DevOps技术和DevOps开发人员的想法对笔者来说一直是个谜。当笔者工作的公司推出了一个名为Gatekeeper的新命令行界面（CLI）应用程序时，笔者跳进了DevOps和Kubernetes的世界。现在，笔者对Kubernetes和DevOps管道有了更好的理解，并且可以更好地解释CLI应用程序如何支持它们。

笔者已经做了五年多的全栈开发，帮助开发人员和DevOps工程师防止Kubernetes（K8s）的错误配置进入生产。

理解问题

想象一下：你度过了漫长的一周，正准备过周末。然而，在凌晨，你在有15个未接来电后醒来，有人一直给你打电话——你忘记在其中一个部署中添加内存限制，这导致了其中一个容器中的内存泄漏，从而导致所有Kubernetes节点的内存不足。

这怎么会发生？DevOps团队投入了大量精力来教育开发人员有关K8s和内存限制的重要性。

为了避免这样的事故，你必须为理想的解决方案设置需求，并搜索有助于防止错误配置影响集群的平台和库。实际需求可能因基础设施而异，但这里有一个很好的示例：

——对开发实施策略限制：在将资源应用到集群之前实施限制的一种方法。

——启用限制管理：在整个组织的专用位置灵活管理限制，使管理员能够完全控制其所有系统。

——关于最佳实践的教育：将DevOps团队从审查、隔离和未来验证所有可能的陷阱的持续需求中解放出来，这些陷阱都是自部署的一部分。

作为一名开发人员，工作就是为了解决现实生活中的问题，但有时环境会起到很大的作用。你必须首先了解问题是如何发生的，然后才能有效地解决它。

为什么组织会采用K8？

DevOps工程师的角色是什么？

最重要的是，为谁开发应用程序？

DevOps工程师做什么？

起初，笔者对DevOps工程师角色知之甚少，对他们的技术几乎一无所知，尤其是Kubernetes。笔者阅读、研究并采访了DevOps朋友，了解他们的工作和责任。笔者问了如下问题：

——你每天的目标是什么？

——谁是你的客户？

——工作日是什么样子？

几个月后，笔者终于找到了答案。

令人惊讶的是，最有帮助的是承认我们只是从不同的角度思考。DevOps工程师必须从最小的应用程序组件开始，然后在上面扩展和构建。

开发人员可以从同一个应用程序组件开始，但他们习惯于朝相反的方向思考：从高层级到软件的位和字节。开发人员将从服务器、服务、函数、变量到内存分配的各个层剥离开来，直到到达最小的组件。这两个角色都在同一个管道的不同边工作。

如果解决方案是在管道的某个地方，双方都哪些东西可以整合呢？

想知道这个解决方案是否应该成为管道的一部分，这让笔者想到了DevOps和开发人员还有哪些共同点。笔者将开发人员的工作流程与DevOps工程师的工作流程进行了比较，意识到：我们都有策略。

为什么不能总是依赖OPA？

开发人员和工程师都有努力维护的标准和最佳实践。作为一名开发人员，笔者使用可靠且干净的代码原则、单元测试和集成测试，并尝试学习使用的每项技术的所有最佳实践。

一天早上，笔者问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的主要用途是其测试命令：

$ conftest test deployment.yaml

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

此外，ConfTest还提供了从任何OCI注册表（如Dockerhub、Quay.io和其他）推送和拉取策略的能力。

ConfTest的问题

乍一看，ConfTest似乎是完美的解决方案。你不需要部署像OPA这样的服务，但从OCI注册中心拉取和推送的能力意味着你可以在专用空间中统一策略，从而获得更多控制。ConfTest的真正威力在于它在CI过程中的使用，对于习惯于测试代码并不断与之集成的开发人员来说，这使K8s维护更加清晰。

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

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

DevOps，Kubernetes

笔者已经排除了执行策略的其他方法，现在是时候开始研究Kubernetes了。

笔者有三个建议想分享。

开发人员的K8s：提示和指南

了解CI/CD：如果你想开始了解K8s，那么必须了解CI/CD管道中到底发生了什么，CI和CD之间的区别，以及为什么你的公司使用它。笔者从一个最小的组件开始（一个微服务），并绘制了一张图表，列出了所有与之相关的资源和环境。笔者写下了从提交代码到它出现在生产环境中的所有事情。

了解你的平台：使用Kubernetes需要大量与Kubernetes本身无关的配置工作。你需要了解平台是如何工作的，使用和需要哪些资源，以及它们是如何从网络的角度连接起来的。

理解部署：部署可能是在DevOps中听到的最常见的表达，但它到底是什么呢？这是Kubernetes的资源吗？是一个过程？一个工件？在Kubernetes中，部署意味着“应用程序的状态”。