广告

Kubernetes清单的生命周期往往被忽视

  • 浏览(109)
  • 评论(0)
  • 译者:k8s

Kubernetes完全改变了应用程序的交付和运行方式。今天,我们以无法想象的方式更快地构建、不断发布代码并管理巨大的工作负载。但是,随着越来越多的组织采用并接受这种新的工作方式,高度复杂的云计算原生环境正在快速发展,很难跟上。

Kubernetes是帮助提高应用程序部署速度和可靠性的关键转变之一。然而,很少有人关注Kubernetes清单。

这些YAML文件描述了你要创建的对象的资源(从服务到部署和pod等),以及它们应该如何在集群中运行。即使如此,事情也不简单。

不断增长的云原生生态系统意味着需要管理的工具越来越多,清单越来越大,同时出现了大量不同语法的代码,这对工程师个人来说越来越具有挑战性。更不用说跨微服务架构部署的固有挑战了,在这种情况下,孤立的团队可能不知道服务的上下游变化。

Kubernetes清单管理

图片

让我们更仔细地看看上面概述的Kubernetes清单生命周期。

创建——清单的创建和编辑阶段包括几个任务:

验证清单:YAML语法和目标K8s模式、合规性和策略政策(公司、OPA、安全等)、约定(命名、元数据等)、参考资源的完整性、Helm和Kustomize等工具的模板验证。

版本控制:版本控制相关工作流;分支、评审等。

预览/验证/修复:如果你使用的是Kustomize或Helm之类的工具,则可能需要预览和验证这些工具生成的清单,并可能需要调试和修复相应模板中的任何错误。

应用程序——与将清单部署到目标集群相关的任务。

如果使用Kustomize/Helm/etc,则生成要部署的清单。

针对目标集群验证有关对象引用的清单。

将清单与集群中的任何现有版本进行比较,以评估更改的影响。

应用回滚:手动或可能使用基于CI/CD/GitOps的自动化方法

修改——一旦部署,通常需要:

如果事情没有按预期工作,则调试清单。

修改集群中的清单以解决即时问题。

退役(删除)清单,以便在不再需要时删除清单及其相应的对象。

今天执行上述所有任务的生态系统分为两个主要部分——用于编写和编辑清单的工具/集成开发环境(IDE)和用于监控集群中运行的清单的集群检查工具。在这两方面,最流行和最常用的工具是用于编写的Visual Studio Code和用于监控的Lens。

Visual Studio Code是由微软开发的流水线代码编辑器,它专注于软件开发,可能支持调试和版本控制等操作。它旨在为开发人员提供快速代码构建调试周期所需的工具。它是在MIT许可下作为许可自由软件发布的。

Intellij IDEA是另一种流行的开源IDE,旨在通过智能编码辅助和人体工程学设计最大限度地提高开发人员的工作效率。有一个企业版可用,它不在Apache 2.0许可的范围内。

Lens为Kubernetes中运行的一切提供全面的态势感知。它旨在通过用户界面降低参与Kubernetes集群运营的人员的进入门槛。它也可以通过MIT许可获得。

现有Kubernetes清单工具的挑战

Visual Studio Code或其他通用IDE之类的工具与Lens之类的集群仪表盘之间存在根本性的差距,前者对YAML语法没有很强的概念,更不用说对象、集群或其他Kubernetes构造,你可以在其中创建和编辑清单,后者可以检查从清单创建并在集群中运行的对象。

虽然VS Code和Intellij使您能够轻松编写清单,但它们在自动查找值错误或语法错误方面的能力有限。最重要的是,这些监控工具都不能让您看到资源之间的关系和依赖关系。

目前大多数针对生命周期特定部分的工具(如上所述)都是通过扩展/插件实现的。不幸的是,需要许多不同的插件来覆盖所有与清单相关的任务,而这些插件并不是从头开始构建的,目的是为Kubernetes清单生命周期中的不同任务提供一致和连贯的支持,也不是为这些目的提供一个集成且平滑的UI。

对我们来说,这是一个需要解决的重要挑战——我们希望使清单的创建、应用和修改更直接、更高效,以节省工程师宝贵的时间和精力,缓解他们的压力。

Monokle优势

图片

当我们仔细观察这一情况时,我们意识到没有任何工具可以在其整个生命周期中专门且一致地针对清单相关的工作流,这使得初学者和专家在日常清单和Kubernetes相关任务中尽可能多地提高工作效率具有挑战性。

现在,你可能需要在不同的工具集(如IDE、CLI语法或安全验证器等)之间切换,以全面完善与清单相关的工作流。

Monokle致力于改进典型的Kubernetes工作流,这些工作流会让人头疼,尤其是对于那些第一步进入Kubernetes的人来说,但超级用户也可以从中受益。

Monokle功能:

立即识别并修复YAML语法错误。

Kubernetes资源及其关系的快速概述。

调试并验证Kustomize和Helm的输出。

查找并修复配置错误。区分本地和远程资源,并进行部署。

易于使用的编辑器和模板可确保最佳实践和一致性。

验证工具的集成:例如,Open Policy Agent,它专注于合规性。

弥合Kubernetes清单鸿沟

我们希望帮助工程师在编码时快速获得所有清单及其包含资源的高级视图,就像部署后场景中的Lens一样。

但与VS Code和IntelliJ IDEA一样,我们也希望让工程师能够轻松编辑资源,快速发现问题,而不必学习YAML语法,不必根据你的集群区分资源,不必预览和调试使用Kustomize或Helm生成的资源等。

这就是为什么我们要开发Monokle,使其正好位于编辑和可视化空间之间。它与IDE和集群仪表板一起工作,帮助工程师高效地处理清单相关的工作流。它旨在显著简化工作流,使工程师能够在单个工具中可视化地管理整个Kubernetes清单生命周期。

如果你刚刚开始Kubernetes之旅:对于喜欢在命令行或IDE中工作的工程师,我们认为你仍然应该使用首选方法来编写清单。Monokle只是在顶部添加了一个支持层,帮助突出显示对象的YAML语法错误和依赖关系问题。

下一步:对于那些拥有喜欢的集群仪表板的人来说,Monokle可以补充现有的生态系统,进一步确定资源之间的关系,这样你就不必在代码中搜索关系。此外,关系会实时更新,任何断开的链接都会以警告突出显示。

Kubernetes生态系统的一部分:作为一个云原生项目,Monokle支持Kustomize和Helm等Kubernetes工具,允许工程师共享资源和模板,并定义公共值以跨多个资源共享。

它还使工程师能够查看Kustomize文件或Helm图表,而无需将它们部署到正在运行的集群中——这对于测试来说是一个巨大的进步,因为目前在不读取大型Kubernetes YAML文件的情况下调试Kustomize非常困难。谁真的想整天读YAML?

原文链接:

https://thenewstack.io/the-kubernetes-manifest-life-cycle-too-often-overlooked/




  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头