Kubernetes 资源模型 (KRM) 以及如何使用 YAML？

引言

Kubernetes 的联合创始人之一 Brian Grant 强调了 Kubernetes 提供的巨大简洁性，这部分归功于 Kubernetes 资源模型 (KRM)。该资源模型描述了一种创建配置文件的机制，格式清晰易懂，允许使用代码指定期望的系统状态。通用声明式元数据的概念是 KRM 的关键组成部分。因此，KRM 通常以 YAML 的形式表示，确立了 Kubernetes 中的一切都可以归结为 YAML 的核心概念。

一个类似的基本原则是“一切皆代码”（Everything-as-Code，EaC）范式的基石，有时也称为“万物皆代码”。EaC 的指导理念认为，IT 基础设施的每个方面，从配置到安全系统，都可以通过代码精心配置。这种天然的声明式方法允许将重点从执行单个操作转移到描述最终目标和状态。值得注意的是，YAML 在这个环境中仍然具有相关性，它作为创建健康平衡的关键工具，用于协同处理这两种技术。

Kubernetes 与 YAML

与 21 世纪面向云原生应用的 Linux 内核版本相比，Kubernetes 在我们管理和交互现代 IT 系统的方式上代表了一个重大的转变。这种比较强调了 Kubernetes 和 Linux 之间的相似之处，即它们都具备访问和修改系统信息的能力，尽管是通过不同的机制。

Linux 中的 /proc 目录提供了对内核和大量系统数据的访问。检查这些虚拟文件流允许用户调查和检索有关系统的信息。同样，在 Kubernetes 中，API 是访问系统内部运作的门户。此 API 会公开有关整个 Kubernetes 集群的信息，并允许用户查询和控制 Kubernetes 资源。

至关重要的是，Linux 和 Kubernetes 都通过易于访问的格式提供了这种可访问性。在 Linux 中是虚拟文件流，在 Kubernetes 中是 YAML 文件。YAML 文件提供了一种结构化且人类可读的方法来定义配置和期望状态。这种方法简化了系统管理、配置和监控任务。

以下是 YAML 文件成为设置 Kubernetes 和类似系统的事实标准解决方案的一些有力理由：

人性化： YAML 文件对人类来说易于访问和友好，使其成为配置的绝佳选择。

多功能性和表现力： YAML 的多功能性使其能够表达广泛的配置和数据结构，从而支持广泛的应用场景。

易于设置和操作： 设置和操作简单，最大限度地减少了 Kubernetes 及相关系统新手用户的学习曲线。

跨语言兼容性： YAML 可以轻松地从一种编程语言翻译到另一种编程语言，促进了互操作性。

一致的数据模型： YAML 文件遵循一致的数据模型，简化了通用工具和解析器的构建。

单次处理： YAML 文件可以单次处理，使其对人类和机器都高效。

使用简单： 它们通过减少在命令行键入复杂命令的需要，使与系统的通信更加容易。

版本控制： YAML 文件可以添加到源代码控制系统，以实现版本控制和更改跟踪。

适应性： YAML 能够描述复杂数据结构的能力使其适合构建比命令行所能实现的更复杂的设置。

DevSecOps 和协作性： 使用 YAML 来确保实现类型和一致性的统一，对于几个引人注目的原因至关重要，尤其是在 DevSecOps 和现代 IT 运营的协作性方面。

清晰度和可读性： 由于 YAML 是结构化的，配置是清晰且易于阅读的。当每个人都遵循相同的类型和结构时，所有团队成员都更容易理解和使用配置，无论其部门或职能如何。这种清晰度提高了理解和沟通。

最后，Kubernetes 和 YAML 之间的密切互动强调了这种结构化配置语言在当前 IT 运营中的重要性。由于其人性化和一致的特性，YAML 促进了复杂系统的管理和设置，使其成为云原生计算时代开发人员和运维团队的必备工具。

如何链接资源？

在 Kubernetes 中链接资源对于创建应用程序或基础设施不同组件之间的交互和依赖关系至关重要。Kubernetes 有多种连接资源的方法，了解这些方法对于有效管理大型系统至关重要。以下是 Kubernetes 中链接资源的三个重点方法：

ownerReference (UID)： OwnerReference 允许一个资源与另一个资源创建层级关系。它表示一个资源是另一个资源的“所有者”或“父级”。

用例：这通常用于一个资源在逻辑上拥有或控制另一个资源时。例如，Deployment 是 ReplicaSet 的“父级”，ReplicaSet 是其维护的 pod 的“父级”。

垃圾回收： Kubernetes 使用垃圾回收机制来处理由 ownerReferences 链接的资源。

当“父”资源被删除时，垃圾回收器将删除所有链接的“子”资源。

标签和选择器： 标签和选择器提供了一种灵活的方法，根据键值对链接资源。

标签被分配给资源，例如 pod 或服务，以根据指定的特征对其进行分类和分组。然后，其他资源可以使用选择器来识别和引用具有特定标签的资源。例如，Service 可以使用选择器将流量路由到具有特定标签的 pod。

标签和选择器通过允许您根据应用程序的需求构建自定义分组，实现了定义资源之间关联的灵活性。

Targetref： Targetref 方法的目的是指定被链接资源的 API 版本、名称和资源类型。

用例：这种策略在资源之间建立清晰直接的链接。当根据 API 版本和名称显式链接资源时，它特别有用。这种方法在创建资源之间的精确链接方面最有效。

清晰度： TargetRef 提供了对 Kubernetes 资源之间所有关系的清晰了解，使得复杂的系统更容易管理和维护。

链接资源的最佳方法取决于您应用程序的特定需求以及您必须建立的关联。owner reference 类对于建立层级关系很重要，而标签和选择器则在分类和排列资源方面提供了更大的自由度。

在 Kubernetes 中，创建资源对于描述应用程序或基础设施的不同组件如何交互至关重要。了解这些策略并为您的用例选择最佳策略将帮助您成功构建和管理 Kubernetes 资源，同时维护一个结构良好且一致的系统。

YAML 在 Kubernetes 中的使用

在 Kubernetes 中，首选的配置文件语言是 YAML（YAML Ain't Markup Language）。它用于定义和配置各种 Kubernetes 资源和应用程序。YAML 因其简洁易读的风格而成为在 Kubernetes 集群中定义和维护资源的理想选择。在 Kubernetes 中，YAML 的使用方式如下：

资源定义：在 Kubernetes 中，YAML 主要用于定义资源的期望状态。每个资源都有自己的 YAML 配置文件，例如 pod、service、deployment、config map 和 secret。

Yml

此示例中的 YAML 文件定义了一个名为“my-pod”的 pod，其中包含一个运行最新版 Nginx 镜像的容器。

标签和元数据

元数据，如名称、标签和注解，是资源定义的关键组成部分。注解用于保存非标识信息，而标签是键值对，提供有关资源的更多信息。

YML

此示例中的 pod 具有标签（“app: my-app”）和一个带有描述的注解。

配置

YAML 文件用于提供资源配置。可以包含容器镜像、环境变量、卷挂载、资源限制和其他自定义设置。

YML

YAML 文件定义了一个带有 Nginx 容器和卷挂载的 pod。

服务和网络

YAML 文件用于定义 Kubernetes 服务和网络配置，例如服务类型（ClusterIP、NodePort、LoadBalancer）、端口和选择器。

YML

此 YAML 文件定义了一个服务，该服务将流量路由到带有“app: my-app”标签的 pod。

部署和控制器

YAML 文件用于定义更高级别的控制器，如 Deployments、StatefulSets 和 DaemonSets。这些控制器管理 pod 的生命周期和伸缩。

YML

此 YAML 文件定义了一个 Deployment，该 Deployment 确保运行 Nginx 的 pod 有三个副本。

配置文件

Kubernetes 还使用 YAML 配置文件来设置集群范围的配置，包括身份验证、授权和网络策略。

yaml

此 YAML 文件定义了一个 ConfigMap，其中包含可用于配置设置的键值对。

Helm Charts

Helm 是 Kubernetes 的一个包管理器，它使用 YAML 文件来定义 Helm Charts，后者封装了 Kubernetes 应用程序。Helm Charts 包括模板、值文件和元数据，所有这些都以 YAML 定义。

yaml

这是一个 Kubernetes 服务的 Helm Chart 模板示例。

YAML 是定义和配置 Kubernetes 资源的標準语言。它用于定义资源规范，包括元数据、配置、服务、控制器等。Kubernetes 会解析这些 YAML 文件，以创建、更新或删除资源，使其符合 YAML 配置中指定的期望状态。理解如何编写和管理 YAML 文件是有效使用 Kubernetes 的基础。

现实生活中的例子

想象一下您办公室里普通的一天，不同的团队协同工作，以确保您公司的应用程序和系统顺利运行。您有开发团队、运维团队和安全团队，每个团队都有自己独特的职责。

有一天，出现了一个让开发和运维团队头疼的问题。他们花了几个小时挠头，试图找出为什么一个应用程序在一种环境中完美运行，而在另一种环境中却糟糕地失败，尽管一切似乎都一样。

当他们遇到障碍时，沮丧感油然而生。他们决定联系安全团队，希望他们能提供一些见解。毕竟，他们听说他们正在使用的第三方解决方案可能是罪魁祸首。

令所有人惊讶的是，安全团队深入调查，发现第三方解决方案在容器中运行的应用程序进程中引入了一些隐藏的元素。这些隐藏的元素阻止了开发和运维团队认为正常的行为。

现在，这是引起沮丧的地方。安全团队访问了其他人无法访问的特定接口和信息。是他们的专业知识和独特的访问权限才揭示了问题。

但是这种情况提出了一个重要问题：对于任何与基础设施相关的问题，您是否总是需要求助于安全部门？难道不是每个相关人员，无论是开发、运维还是安全，都能看到并理解基础设施中发生的事情会更好吗？

想象一个工作场所，所有团队都能平等地访问相同的信息和工具。当出现问题时，团队无缝协作，快速识别和解决问题。这是一个每个人都对系统安全、可靠性和性能分担责任的地方。

在这样的环境中，问题得到更快解决，每个人都感到有能力贡献自己的专业知识，安全不再是障碍，而是流程的有机组成部分。这种协作方法带来了更顺畅的运营，并确保您的系统安全并符合行业法规。

最终，这是关于创建一个每个人都拥有成功所需的工具和知识，并且透明度和团队合作是解决挑战的关键的工作场所。

结论

在敏捷性、协作性和安全性至关重要的 DevSecOps 时代，强制要求使用 YAML 文件实现相同的类型和结构，可以确保所有参与基础设施管理的人都能高效地协同工作。它改善了沟通，最大限度地减少了错误，并培养了对基础设施健康和安全共同承担责任的文化。因此，它使个人团队受益，也使组织 IT 运营的整体成功和稳健性受益。