本指南将详细概述 Kubernetes 对象、分析其结构并提供有用的对象管理技巧。它还将列出并描述最常用的对象。
Kubernetes 对象是 Kubernetes 集群中充当意图记录的实体。管理员创建对象来展示集群的所需状态，Kubernetes 使用它们来自动维护状态。常见的K8S对象包括Pods，Services，Volumes，Namespaces，Deployments，ReplicationControllers，ReplicaSets，DaemonSets， StatefulSets，ConfigMaps, Jobs...
理解 Kubernetes 对象的另一种方法是将它们视为类实例。每个创建的对象都引用一个预定义的类，该类告诉API 服务器如何处理系统资源并与特定组件进行通信。
要查看 Kubernetes 集群中可用对象的完整列表，请键入以下kubectl 命令：
kubectl api-resources
以下部分通过描述最重要的 Kubernetes 对象来解释对象概念。
Pods
Kubernetes Pod是 Kubernetes 中最小的部署单元。它们驻留在集群节点上并拥有自己的 IP 地址，使它们能够与集群的其余部分进行通信。单个 Pod 可以托管一个或多个容器，提供存储和网络资源。
Kubernetes Pod 的关键特征之一是它们是短暂的。实际上，Pod 可能会发生故障，但不会影响系统的功能。Kubernetes 会自动用新的 pod 副本替换每个失败的 pod，并保持集群运行。
除了作为容器包装器之外，Pod 还存储指导 Kubernetes 如何运行容器的配置信息。
Services
服务提供了一种公开在 Pod 中运行的应用程序的方法。它们的目的是代表一组执行相同功能的 Pod，并设置访问这些 Pod 的策略。
尽管 Pod 故障是集群中的预期事件，但 Kubernetes 会使用具有不同 IP 地址的副本替换发生故障的 Pod。这会导致相互依赖的 Pod 之间的通信出现问题。
Kubernetes使用**kube-proxy**在每个集群节点上运行的进程，将服务的虚拟 IP 地址映射到 Pod IP 地址。此过程使内部网络变得更容易，而且还可以通过负载平衡等技术将部署暴露给外部网络。
Volumes
卷是旨在为 Pod 提供存储的对象。Kubernetes 中有两种基本类型的卷：
- 临时卷仅在它们所绑定的 Pod 的生命周期内持续存在。
- 持久卷，当 pod 崩溃时不会被破坏。持久卷是通过发出称为 (PVC) 的请求来创建的**
PersistentVolumeClaim**。Kubernetes 使用 PVC 来配置卷，然后充当 Pod 和物理存储之间的链接。
Namespace
命名空间对象的目的是充当集群中资源的分隔符。单个集群可以包含多个命名空间，允许管理员更好地组织集群并简化资源分配。
新集群带有多个为系统目的创建的命名空间和**default**为用户创建的命名空间。管理员可以创建任意数量的附加命名空间 - 例如，一个用于开发，一个用于测试。
Deployments
部署是控制器对象，提供有关 Kubernetes 应如何管理托管容器化应用程序的Pod 的说明。使用部署，管理员可以：
- 扩展 Pod 副本的数量。
- 推出更新的代码。
- 执行回滚到较旧的代码版本。
创建后，部署控制器将监视 Pod 和节点的运行状况。如果发生故障，它会销毁失败的 Pod 并创建新的 Pod。它还可以绕过故障节点，使应用程序即使在发生硬件错误时也能保持功能。
ReplicationControllers
ReplicationController 确保集群上始终运行正确数量的 Pod 副本。创建 ReplicationController 时，管理员指定所需的 Pod 数量。然后，控制器维护它们的数量，创建额外的 Pod，并在必要时终止额外的 Pod。
ReplicationController 支持基于相等的选择器，允许按标签键和值进行过滤。**.spec.selector**控制器将管理标签与配置文件字段中提供的标签匹配的所有 Pod 。
例如，以下声明告诉 Kubernetes 运行五个**nginx**pod：
spec:
replicas: 5
selector:
app: nginx
由于手动创建的 pod 在失败时不会自动替换，因此在 Kubernetes 中建议使用复制，即使所需的 pod 数量为 1 时也是如此。
注意：虽然 ReplicationController 并未被弃用，但它们不再是设置复制的推荐方法。Kubernetes 文档建议在部署中使用 ReplicaSet。
ReplicaSets
ReplicaSet 的用途与 ReplicationController 相同，即在集群上维护相同数量的 pod 副本。然而，这两个对象之间的区别在于它们支持的选择器类型。虽然 ReplicationController 只接受基于相等的选择器，但 ReplicaSet 还支持基于集合的选择器。
基于集合的选择器允许使用一组值来过滤键。这些语句接受三个运算符：in、notin和exists。例如，以下**selector部分指示 ReplicaSet 运行属于production和qa**环境的 Nginx pod：
selector:
matchLabels:
app: nginx
matchExpressions:
- {key: environment, operator: In, values: [production, qa]}
DaemonSets
DaemonSet是控制器对象，其目的是确保特定 Pod 在集群中的特定（或所有）节点上运行。Kubernetes 调度程序会忽略 DaemonSet 创建的 Pod，因此只要节点存在，这些 Pod 就会持续存在。该对象对于设置需要在每个节点上运行的守护进程特别有用，例如用于集群存储、日志收集和节点监视的守护进程。
默认情况下，DaemonSet 在集群中的每个节点上创建一个 pod。如果对象需要针对特定节点，则通过**nodeSelector**配置文件中的字段执行它们的选择。
StatefulSets
虽然部署和复制控制器可以处理无状态应用程序，但有状态应用程序需要一个称为 StatefulSet 的工作负载对象。StatefulSet 为每个 pod 提供了唯一的标识，该标识在 pod 重新启动后仍然存在。
从 StatefulSet 中受益的应用程序需要：
- 每个 Pod 都有唯一的持久存储- 与 Deployment 一起使用的 PersistentVolumeClaims 为 Pod 副本提供共享存储。StatefulSet 使用 VolumeClaimTemplates 代替，它为每个副本分配一个唯一的 PVC。
- 唯一网络 ID - 无头服务控制 Pod 网络身份。
- 有序部署、扩展和滚动更新。
MySQL和PostgreSQL等数据库是使用 StatefulSet 部署的应用程序的示例。
ConfigMap
ConfigMap是 Kubernetes 对象，用于以键值对形式存储容器配置数据。通过将配置数据与容器映像的其余部分分离，ConfigMap 可以创建更轻、更便携的映像。它们还允许开发人员根据应用程序是否处于开发、测试或生产阶段，使用具有不同配置的相同代码。
通过将 ConfigMap 安装为 pod 内的卷，可以将 pod 配置为使用 ConfigMap 数据：
volumes:
- name: config
configMap
name: config-example
items:
- key: key1
path: config.example
或者，可以使用环境变量从配置中提取特定值：
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: config-example
key: key1
Jobs
Jobs是执行有限任务的工作负载控制器对象。虽然其他控制器对象的任务是永久维护所需的状态和 pod 数量，但作业旨在完成任务并终止关联的 pod。此属性使它们对于维护、监视、批处理任务和工作队列管理非常有用。
作业实例同时或连续运行。计划作业是一个名为CronJob 的单独控制器对象。
Object Spec and Status
object**spec和 objectstatus**是 Kubernetes 用于控制对象的对象配置中的两个嵌套字段。
- 该**
spec**字段用于声明对象所需的状态，即资源的特征。用户在创建对象时提供此字段。 - 该**
status**字段提供有关当前对象状态的信息。该字段由 Kubernetes 在对象的生命周期内提供。
Kubernetes 控制平面监视集群中每个对象的状态，并尝试将当前状态与所需状态相匹配。
例如，考虑以下部署 YAML：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-test
labels:
app: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.23.1
ports:
- containerPort: 80
该**spec字段指出 nginx 部署所需的副本数量为 5。部署成功创建后，Kubernetes 会监控其状态并status**相应更新该字段。如果一个副本发生故障，状态字段只会报告四个正在运行的副本，这会触发 Kubernetes 启动另一个 pod。
对象必填字段
当用户想要创建 Kubernetes 对象时，必须在 YAML 文件中提供以下字段：
apiVersion- 指定用于创建对象的 Kubernetes API 的版本。kind- 提供对象类型，例如 Deployment、ReplicaSet 或 Service。metadata- 列出对象标识符，例如其名称、UID、标签和命名空间。spec- 指明对象的所需状态，例如副本数量和容器映像。
对象名称和 ID
每个 Kubernetes 对象都有一个名称和一个 UID。它们用于识别整个集群中的对象。
对象名称是用户定义的并且对于对象类型是唯一的。这意味着，例如，在单个命名空间内只能有一个命名的 pod test-app，但允许存在同名的部署。
系统分配对象 UID，对于跨类型和命名空间的每个对象实例来说，这些 UID 都是唯一的。这意味着即使同一对象的历史版本也具有不同的 UID。
使用 Kubernetes 对象
Kubernetes 对象使用各种 GUI 仪表板或使用 kubectl CLI 工具进行管理。借助 kubectl，用户可以通过三种不同的管理技术来管理对象：
- 命令式命令是可以一步更改集群的单个操作词。然而，如果用户应用许多这样的命令，那么跟踪集群中的更改就会变得更加困难。
- 命令式配置指定命令（例如**
create**）、选项以及包含对象配置的 YAML 或 JSON 文件。这种方法允许将配置存储在源代码控制系统（例如Git）中，以便于访问，但学习曲线更陡峭并且更耗时。 - 声明式配置将定义必要操作的任务转移给 kubectl，同时只要求用户提供配置文件。当用户应用配置文件时，kubectl 对对象执行必要的操作。
注意：始终使用单一技术来管理单个 Kubernetes 对象。混合技术可能会产生不良后果。
创建对象
您可以使用上面列出的任何管理技术来创建 Kubernetes。
例如，以下命令式命令创建 Nginx 部署：
kubectl create deployment nginx --image nginx
可以使用命令式对象配置创建相同的部署：
kubectl create -f nginx.yaml
第三种选择涉及使用声明性方法：
kubectl apply -f nginx.yaml
编辑对象
Kubectl 具有多个用于编辑现有对象的子命令。以下是最常用的命令：
scale- 更新控制器的副本计数以执行水平扩展。annotate- 编辑对象的注释。label- 编辑对象标签。set- 更新对象方面。
上述命令允许用户更新对象，而无需知道需要更改的特定字段。以下命令集需要更好地理解对象模式：
edit- 在文本编辑器中打开并编辑对象的配置。patch- 使用补丁字符串修改特定对象字段。
删除对象
使用该**kubectl delete**命令从集群中删除对象。要对此命令采用命令式方法，请将对象作为命令参数传递。例如：
kubectl delete deployment/nginx
您还可以通过使用命令式对象配置并提供配置文件来删除对象：
kubectl delete -f nginx.yaml
结论
本指南向您介绍了 Kubernetes 对象的概念。它展示了最常用的对象，并提供了对其形式和功能的深入了解。最后，列出并解释了一些基本的管理技术。
