在 Kubernetes 集群中，用户和 Kubernetes 组件都通过 Kubernetes API 操作对象与集群进行交互，如图所示。
这些对象代表了整个集群的配置。它们包括在集群中运行的应用程序、它们的配置、它们在集群内部或外部暴露的负载均衡器、底层服务器和这些应用程序使用的存储、用户和应用程序的安全权限以及许多其他细节基础设施。
介绍 API
Kubernetes API 是与集群交互的中心点，本书的大部分内容都致力于解释这个 API。最重要的 API 对象将在以下章节中描述，但这里只介绍 API 的基本介绍。
了解 API 的架构风格 Kubernetes API 是一个基于 HTTP 的 RESTful API，其中状态由您使用标准 HTTP 方法（如 POST, GET, PUT/PATCH or DELETE）执行 CRUD 操作（创建、读取、更新、删除）。
正是这些资源（或对象）代表了集群的配置。因此，将应用程序部署到集群中的集群管理员和工程师通过操作这些对象来改变配置。
在 Kubernetes 社区中，术语“资源”和“对象”可以互换使用，但有一些细微的差异需要解释。
了解资源和对象之间的区别
RESTful API 中的基本概念是资源，每个资源都分配有唯一标识它的 URI （统一资源标识符）。例如，在 Kubernetes API 中，应用程序部署由 deployment resources 表示。
集群中所有 deployments 的集合是暴露在 /api/v1/deployments 的 REST 资源。当您使用 GET 方法向此 URI 发送 HTTP 请求时，您会收到一个列出集群中所有部署实例的响应。
每个单独的 deployment 实例也有自己唯一的 URI，通过它可以对其进行操作。因此，单个 deployment 作为另一个 REST 资源对外公开。您可以通过向资源 URI 发送 GET 请求来检索有关 deployment 的信息，并且可以使用 PUT 请求对其进行修改。
因此，一个对象可以通过多个资源公开。如图 4.2 所示，名为 mydeploy 的 Deployment 对象实例在您查询 deployments 资源时作为集合中一个元素返回，而在您查询单个资源 URI 时作为单个对象直接返回。
此外，如果一个对象类型存在多个 API 版本，也可以通过多个资源公开单个对象实例。直到 Kubernetes 版本 1.15，API 公开了两种不同的部署对象表示。除了在 /apis/apps/v1/deployments 中公开的 apps/v1 版本之外，API 中还提供了在 /apis/extensions/v1beta1/deployments 中公开的旧版本 extensions/v1beta1。这两个资源并不代表两组不同的 Deployment 对象，而是以两种不同方式表示的单一集合——对象模式的细微差别。您可以通过第一个 URI 创建一个 Deployment 对象的实例，然后使用第二个 URI 读取它的内容。
在某些情况下，资源不代表任何对象。这方面的一个例子是 Kubernetes API 允许客户端验证主体（人或服务）是否被授权执行 API 操作的方式。这是通过向 /apis/authorization.k8s.io/v1/subjectaccessreviews 资源提交 POST 请求来完成的。响应体内包含是否被授权执行请求正文中指定的操作，这里的关键是 POST 请求不会创建任何对象。
上面描述的示例表明资源与对象不同。如果您熟悉关系数据库系统，则可以将资源和对象类型与视图和表进行比较。资源是您与对象交互的视图。
了解对象的表示方式
当您对资源发出 GET 请求时，Kubernetes API 服务器会以结构化文本形式返回对象。默认数据模型是 JSON，但您也可以告诉服务器返回 YAML。当您使用 POST 或 PUT 请求更新对象时，您还可以使用 JSON 或 YAML 指定新状态。
对象清单中的各个字段取决于对象类型，但一般结构和许多字段由所有 Kubernetes API 对象共享。接下来您将了解它们。
了解对象清单的结构（manifest）
在你面对一个 Kubernetes 对象的完整清单之前，让我先解释一下它的主要部分，因为这将帮助你找到理解数百行配置的方法。
介绍对象的主要部分
大多数 Kubernetes API 对象的清单包含以下四个部分：
Type Metadata包含有关此清单描述的对象类型的信息。它指定对象类型、类型所属的组和 API 版本。Object Metadata包含有关对象实例的基本信息，包括其名称、创建时间、对象所有者和其他标识信息。对象元数据中的字段对于所有对象类型都是相同的。Spec是您指定对象所需状态的部分。它的字段在不同的对象类型之间有所不同。对于 pod，这是指定 pod 的容器、存储卷和其他与其操作相关的信息的部分。Status包含对象的当前实际状态。对于 pod，它会告诉你 pod 的状况、每个容器的状态、它的 IP 地址、它正在运行的节点，以及揭示你的 pod 发生了什么的其他信息。
下图显示了对象清单及其四个部分的可视化表示。
虽然图中显示用户写入对象的 Spec 部分并读取其状态，但 API 服务器总是在您执行 GET 请求时返回整个对象；要更新对象，您还可以在 PUT 请求中发送整个对象。
稍后您将看到一个示例来查看这些部分中存在哪些字段，但让我先解释一下 Spec 和 Status 部分，因为它们代表对象的实体。
理解 spec 和 status 部分
正如您在上图中可能已经注意到的那样，对象的两个最重要的部分是 Spec 和 Status 部分。您可以使用 Spec 指定对象的所需状态，并从 Status 部分读取对象的实际状态。那么，您是编写 Spec 并读取 Status 的人，但是谁或什么读取 Spec 并写入 Status？
Kubernetes 控制平面运行多个控制器（controllers） 的组件，用于管理您创建的对象。每个控制器通常只负责一种对象类型。例如，Deployment controller管理 Deployment objects。
如图所示，控制器的任务是从对象的 Spec 部分读取所需的对象状态，执行实现该状态所需的操作，并通过写入其 Status 部分，实现报告对象的实际状态的目的。
本质上，您通过创建和更新 API 对象来告诉 Kubernetes 它必须做什么。 Kubernetes 控制器使用相同的 API 对象来告诉你他们做了什么以及他们的工作状态。
您将在第 13 章中了解有关各个控制器及其职责的更多信息。现在，请记住控制器与大多数对象类型相关联，并且控制器是读取 Spec 并写入 Status 的东西。
所有 Kubernetes API 对象都包含两个元数据部分，但并非所有对象都有 Spec 和 Status 部分。那些没有的，通常只包含静态数据并且没有相应的控制器，因此没有必要区分对象的期望状态和实际状态。
此类对象的一个示例是 Event 对象，它由各种控制器创建，以提供有关控制器正在管理的对象正在发生的事情的附加信息。
您现在了解了对象的大致轮廓，因此本章的下一部分可以最终探索对象的各个字段。
若有收获，就点个赞吧
0 人点赞
