Kubernetes对象：修订间差异

来自泡泡学习笔记
跳到导航 跳到搜索
无编辑摘要
 
（未显示同一用户的12个中间版本）
第70行： 第70行：
#路径分段名称
#路径分段名称
#:某些资源类型要求名称能被安全地用作路径中的片段。 换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。
#:某些资源类型要求名称能被安全地用作路径中的片段。 换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。
===UID===
Kubernetes 系统生成的字符串，唯一标识对象。
在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID，它旨在区分类似实体的历史事件。
Kubernetes UID 是全局唯一标识符（也叫 UUID）。 UUID 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
===标签和选择算符===
标签（Labels） 是附加到 Kubernetes 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。
标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。
服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。 管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。
"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}
====语法和字符集====
标签是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（/）分隔。 名称段是必需的，必须小于等于 63 个字符，以字母数字字符（[a-z0-9A-Z]）开头和结尾， 带有破折号（-），下划线（_），点（ .）和之间的字母数字。 前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（.）分隔的一系列 DNS 标签，总共不超过 253 个字符， 后跟斜杠（/）。
如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 kube-scheduler、kube-controller-manager、 kube-apiserver、kubectl 或其他第三方自动化工具）必须指定前缀。
kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。
有效标签值：
*必须为 63 个字符或更少（可以为空）
*除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾
*包含破折号（-）、下划线（_）、点（.）和字母或数字
例如，这是一个有 environment: production 和 app: nginx 标签的 Pod 配置文件：
apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
====标签选择算符====
与名称和 UID 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。
通过标签选择算符，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。
API 目前支持两种类型的选择算符：基于等值的和基于集合的。 标签选择算符可以由逗号分隔的多个需求组成。 在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑与（&&）运算符。
空标签选择算符或者未指定的选择算符的语义取决于上下文， 支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。
=====基于等值的需求=====
基于等值或基于不等值的需求允许按标签键和值进行过滤。 匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 可接受的运算符有 =、== 和 != 三种。 前两个表示相等（并且是同义词），而后者表示不相等。例如：
environment = production
tier != frontend
前者选择所有资源，其键名等于 environment，值等于 production。 后者选择所有资源，其键名等于 tier，值不同于 frontend，所有资源都没有带有 tier 键的标签。 可以使用逗号运算符来过滤 production 环境中的非 frontend 层资源：environment=production,tier!=frontend。
基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。 例如，下面的示例 Pod 选择带有标签 "accelerator=nvidia-tesla-p100"。
apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100
=====基于集合的需求=====
基于集合的标签需求允许你通过一组值来过滤键。 支持三种操作符：in、notin 和 exists（只可以用在键标识符上）。例如：
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
第一个示例选择了所有键等于 environment 并且值等于 production 或者 qa 的资源。
第二个示例选择了所有键等于 tier 并且值不等于 frontend 或者 backend 的资源，以及所有没有 tier 键标签的资源。
第三个示例选择了所有包含了有 partition 标签的资源；没有校验它的值。
第四个示例选择了所有没有 partition 标签的资源；没有校验它的值。
类似地，逗号分隔符充当与运算符。因此，使用 partition 键（无论为何值）和 environment 不同于 qa 来过滤资源可以使用 partition, environment notin (qa) 来实现。
基于集合的标签选择算符是相等标签选择算符的一般形式，因为 environment=production 等同于 environment in (production)；!= 和 notin 也是类似的。
基于集合的要求可以与基于相等的要求混合使用。例如：partition in (customerA, customerB),environment!=qa。
===名字空间===
在 Kubernetes 中，名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。
====何时使用多个名字空间====
名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。当需要名字空间提供的功能时，请开始使用它们。
名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。 名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。
名字空间是在多个用户之间划分集群资源的一种方法（通过资源配额）。
不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本： 应该使用标签 来区分同一名字空间中的不同资源。
====初始名字空间====
Kubernetes 启动时会创建四个初始名字空间：
#default
#:Kubernetes 包含这个名字空间，以便于你无需创建新的名字空间即可开始使用新集群。
#kube-node-lease
#:该名字空间包含用于与各个节点关联的 Lease（租约）对象。 节点租约允许 kubelet 发送心跳，由此控制面能够检测到节点故障。
#kube-public
#:所有的客户端（包括未经身份验证的客户端）都可以读取该名字空间。 该名字空间主要预留为集群使用，以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。
#kube-system
#:该名字空间用于 Kubernetes 系统创建的对象。
====使用名字空间====
名字空间的创建和删除在名字空间的管理指南文档描述。
====查看名字空间====
你可以使用以下命令列出集群中现存的名字空间：
kubectl get namespace
NAME              STATUS  AGE
default          Active  1d
kube-node-lease  Active  1d
kube-public      Active  1d
kube-system      Active  1d
====为请求设置名字空间====
要为当前请求设置名字空间，请使用 --namespace 参数。
例如：
kubectl run nginx --image=nginx --namespace=<名字空间名称>
kubectl get pods --namespace=<名字空间名称>
====设置名字空间偏好====
你可以永久保存名字空间，以用于对应上下文中所有后续 kubectl 命令。
kubectl config set-context --current --namespace=<名字空间名称>
# 验证
kubectl config view --minify | grep namespace:
====名字空间和 DNS====
当你创建一个服务时， Kubernetes 会创建一个相应的 DNS 条目。
该条目的形式是 <服务名称>.<名字空间名称>.svc.cluster.local，这意味着如果容器只使用 <服务名称>，它将被解析到本地名字空间的服务。这对于跨多个名字空间（如开发、测试和生产） 使用相同的配置非常有用。如果你希望跨名字空间访问，则需要使用完全限定域名（FQDN）。
因此，所有的名字空间名称都必须是合法的 RFC 1123 DNS 标签。
为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 如果需要，你可以额外部署第三方的安全控制机制， 例如以准入 Webhook 的形式，阻止用户创建与公共 TLD 同名的名字空间。
====并非所有对象都在名字空间中====
大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源， 例如节点和持久化卷不属于任何名字空间。
查看哪些 Kubernetes 资源在名字空间中，哪些不在名字空间中：
# 位于名字空间中的资源
kubectl api-resources --namespaced=true
# 不在名字空间中的资源
kubectl api-resources --namespaced=false
====自动打标签====
Kubernetes 控制面会为所有名字空间设置一个不可变更的 标签 kubernetes.io/metadata.name，只要 NamespaceDefaultLabelName 这一特性门控被启用。 标签的值是名字空间的名称。
===注解===
你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
====为对象附加元数据====
你可以使用标签或注解将元数据附加到 Kubernetes 对象。 标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
注解和标签一样，是键/值对：
"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}
以下是一些例子，用来说明哪些信息可以使用注解来记录：
*由声明性配置所管理的字段。 将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、 自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
*构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
*指向日志记录、监控、分析或审计仓库的指针。
*可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
*用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
*轻量级上线工具的元数据信息：例如，配置或检查点。
*负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
*从用户到最终运行的指令，以修改行为或使用非标准功能。
你可以将这类信息存储在外部数据库或目录中而不使用注解， 但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
====语法和字符集====
注解（Annotations） 存储的形式是键/值对。有效的注解键分为两部分： 可选的前缀和名称，以斜杠（/）分隔。 名称段是必需项，并且必须在 63 个字符以内，以字母数字字符（[a-z0-9A-Z]）开头和结尾， 并允许使用破折号（-），下划线（_），点（.）和字母数字。 前缀是可选的。如果指定，则前缀必须是 DNS 子域：一系列由点（.）分隔的 DNS 标签， 总计不超过 253 个字符，后跟斜杠（/）。 如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解 （例如，kube-scheduler，kube-controller-manager，kube-apiserver，kubectl 或其他第三方组件），必须为终端用户添加注解前缀。
kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。
例如，下面是一个 Pod 的配置文件，其注解中包含 imageregistry: https://hub.docker.com/：
apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
===字段选择器===
“字段选择器（Field selectors）”允许你根据一个或多个资源字段的值 筛选 Kubernetes 资源。 下面是一些使用字段选择器查询的例子：
metadata.name=my-service
metadata.namespace!=default
status.phase=Pending
下面这个 kubectl 命令将筛选出 status.phase 字段值为 Running 的所有 Pod：
kubectl get pods --field-selector status.phase=Running
====支持的字段====
不同的 Kubernetes 资源类型支持不同的字段选择器。 所有资源类型都支持 metadata.name 和 metadata.namespace 字段。 使用不被支持的字段选择器会产生错误。例如：
kubectl get ingress --field-selector foo.bar=baz
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
====支持的操作符====
你可在字段选择器中使用 =、== 和 != （= 和 == 的意义是相同的）操作符。 例如，下面这个 kubectl 命令将筛选所有不属于 default 命名空间的 Kubernetes 服务：
kubectl get services  --all-namespaces --field-selector metadata.namespace!=default
====链式选择器====
同标签和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 kubectl 命令将筛选 status.phase 字段不等于 Running 同时 spec.restartPolicy 字段等于 Always 的所有 Pod：
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
====多种资源类型====
你能够跨多种资源类型来使用字段选择器。 下面这个 kubectl 命令将筛选出所有不在 default 命名空间中的 StatefulSet 和 Service：
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
===Finalizers===
Finalizer 是带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。
当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时， Kubernetes API 通过填充 .metadata.deletionTimestamp 来标记要删除的对象， 并返回 202 状态码(HTTP "已接受") 使其进入只读状态。 此时控制平面或其他组件会采取 Finalizer 所定义的行动， 而目标对象仍然处于终止中（Terminating）的状态。 这些行动完成后，控制器会删除目标对象相关的 Finalizer。 当 metadata.finalizers 字段为空时，Kubernetes 认为删除已完成并删除对象。
你可以使用 Finalizer 控制资源的垃圾收集。 例如，你可以定义一个 Finalizer，在删除目标资源前清理相关资源或基础设施。
你可以通过使用 Finalizers 提醒控制器 在删除目标资源前执行特定的清理任务， 来控制资源的垃圾收集。
Finalizers 通常不指定要执行的代码。 相反，它们通常是特定资源上的键的列表，类似于注解。 Kubernetes 自动指定了一些 Finalizers，但你也可以指定你自己的。
====Finalizers 如何工作====
当你使用清单文件创建资源时，你可以在 metadata.finalizers 字段指定 Finalizers。 当你试图删除该资源时，处理删除请求的 API 服务器会注意到 finalizers 字段中的值， 并进行以下操作：
#修改对象，将你开始执行删除的时间添加到 metadata.deletionTimestamp 字段。
#禁止对象被删除，直到其 metadata.finalizers 字段为空。
#返回 202 状态码（HTTP "Accepted"）。
管理 finalizer 的控制器注意到对象上发生的更新操作，对象的 metadata.deletionTimestamp 被设置，意味着已经请求删除该对象。然后，控制器会试图满足资源的 Finalizers 的条件。 每当一个 Finalizer 的条件被满足时，控制器就会从资源的 finalizers 字段中删除该键。 当 finalizers 字段为空时，deletionTimestamp 字段被设置的对象会被自动删除。 你也可以使用 Finalizers 来阻止删除未被管理的资源。
一个常见的 Finalizer 的例子是 kubernetes.io/pv-protection， 它用来防止意外删除 PersistentVolume 对象。 当一个 PersistentVolume 对象被 Pod 使用时， Kubernetes 会添加 pv-protection Finalizer。 如果你试图删除 PersistentVolume，它将进入 Terminating 状态， 但是控制器因为该 Finalizer 存在而无法删除该资源。 当 Pod 停止使用 PersistentVolume 时， Kubernetes 清除 pv-protection Finalizer，控制器就会删除该卷。
====属主引用、标签和 Finalizers====
与标签类似， 属主引用 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 当一个控制器 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 例如，当 Job 创建一个或多个 Pod 时， Job 控制器会给这些 Pod 应用上标签，并跟踪集群中的具有相同标签的 Pod 的变化。
Job 控制器还为这些 Pod 添加了“属主引用”，指向创建 Pod 的 Job。 如果你在这些 Pod 运行的时候删除了 Job， Kubernetes 会使用属主引用（而不是标签）来确定集群中哪些 Pod 需要清理。
当 Kubernetes 识别到要删除的资源上的属主引用时，它也会处理 Finalizers。
在某些情况下，Finalizers 会阻止依赖对象的删除， 这可能导致目标属主对象被保留的时间比预期的长，而没有被完全删除。 在这些情况下，你应该检查目标属主和附属对象上的 Finalizers 和属主引用，来排查原因。
===属主与附属===
在 Kubernetes 中，一些对象是其他对象的“属主（Owner）”。 例如，ReplicaSet 是一组 Pod 的属主。 具有属主的对象是属主的“附属（Dependent）”。
属主关系不同于一些资源使用的标签和选择算符机制。 例如，有一个创建 EndpointSlice 对象的 Service， 该 Service 使用标签来让控制平面确定，哪些 EndpointSlice 对象属于该 Service。 除开标签，每个代表 Service 所管理的 EndpointSlice 都有一个属主引用。 属主引用避免 Kubernetes 的不同部分干扰到不受它们控制的对象。
====对象规约中的属主引用====
附属对象有一个 metadata.ownerReferences 字段，用于引用其属主对象。 一个有效的属主引用，包含与附属对象同在一个命名空间下的对象名称和一个 UID。 Kubernetes 自动为一些对象的附属资源设置属主引用的值， 这些对象包含 ReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationController 等。 你也可以通过改变这个字段的值，来手动配置这些关系。 然而，通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。
附属对象还有一个 ownerReferences.blockOwnerDeletion 字段，该字段使用布尔值， 用于控制特定的附属对象是否可以阻止垃圾收集删除其属主对象。 如果控制器（例如 Deployment 控制器） 设置了 metadata.ownerReferences 字段的值，Kubernetes 会自动设置 blockOwnerDeletion 的值为 true。 你也可以手动设置 blockOwnerDeletion 字段的值，以控制哪些附属对象会阻止垃圾收集。
Kubernetes 准入控制器根据属主的删除权限控制用户访问，以便为附属资源更改此字段。 这种控制机制可防止未经授权的用户延迟属主对象的删除。
====属主关系与 Finalizer====
当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 Finalizer 规则。 Finalizer 防止意外删除你的集群所依赖的、用于正常运作的资源。 例如，如果你试图删除一个仍被 Pod 使用的 PersistentVolume，该资源不会被立即删除， 因为 PersistentVolume 有 kubernetes.io/pv-protection Finalizer。 相反，它将进入 Terminating 状态，直到 Kubernetes 清除这个 Finalizer， 而这种情况只会发生在 PersistentVolume 不再被挂载到 Pod 上时。
当你使用前台或孤立级联删除时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 foreground Finalizer，这样控制器必须在删除了拥有 ownerReferences.blockOwnerDeletion=true 的附属资源后，才能删除属主对象。 如果你指定了孤立删除策略，Kubernetes 会添加 orphan Finalizer， 这样控制器在删除属主对象后，会忽略附属资源。
===推荐使用的标签===
除了 kubectl 和 dashboard 之外，你还可以使用其他工具来可视化和管理 Kubernetes 对象。 一组通用的标签可以让多个工具之间相互操作，用所有工具都能理解的通用方式描述对象。
除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。
元数据围绕 应用（application） 的概念进行组织。Kubernetes 不是平台即服务（PaaS），没有或强制执行正式的应用程序概念。 相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。
共享标签和注解都使用同一个前缀：app.kubernetes.io。没有前缀的标签是用户私有的。 共享前缀可以确保共享标签不会干扰用户自定义的标签。
====标签====
为了充分利用这些标签，应该在每个资源对象上都使用它们。
{| class="wikitable"
|-
! 键
! 描述
! 示例
! 类型
|-
| app.kubernetes.io/name
| 应用程序的名称
| mysql
| 字符串
|-
| app.kubernetes.io/instance
| 用于唯一确定应用实例的名称
| mysql-abcxzy
| 字符串
|-
| app.kubernetes.io/version
| 应用程序的当前版本
| 5.7.21
| 字符串
|-
| app.kubernetes.io/component
| 架构中的组件
| database
| 字符串
|-
| app.kubernetes.io/part-of
| 此级别的更高级别应用程序的名称
| wordpress
| 字符串
|-
| app.kubernetes.io/managed-by
| 用于管理应用程序的工具
| helm
| 字符串
|}
为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象：
# 这是一段节选
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
====应用和应用实例====
应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。 例如，可以不止一次地为不同的站点安装不同的 WordPress。
应用的名称和实例的名称是分别记录的。例如，WordPress 应用的 app.kubernetes.io/name 为 wordpress，而其实例名称 app.kubernetes.io/instance 为 wordpress-abcxzy。 这使得应用和应用的实例均可被识别，应用的每个实例都必须具有唯一的名称。
=====示例=====
为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。
======一个简单的无状态服务======
考虑使用 Deployment 和 Service 对象部署的简单无状态服务的情况。 以下两个代码段表示如何以最简单的形式使用标签。
下面的 Deployment 用于监督运行应用本身的那些 Pod。
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...
下面的 Service 用于暴露应用。
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...
======带有一个数据库的 Web 应用程序======
考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress）， 其中使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。
以下 Deployment 的开头用于 WordPress：
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...
这个 Service 用于暴露 WordPress：
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...
MySQL 作为一个 StatefulSet 暴露，包含它和它所属的较大应用程序的元数据：
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...
Service 用于将 MySQL 作为 WordPress 的一部分暴露：
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...
使用 MySQL StatefulSet 和 Service，你会注意到有关 MySQL 和 WordPress 的信息，包括更广泛的应用程序。
===服务器端字段验证===
从 Kubernetes v1.25 开始，API 服务器提供了服务器端字段验证， 可以检测对象中未被识别或重复的字段。它在服务器端提供了 kubectl --validate 的所有功能。
kubectl 工具使用 --validate 标志来设置字段验证级别。它接受值 ignore、warn 和 strict，同时还接受值 true（等同于 strict）和 false（等同于 ignore）。kubectl 的默认验证设置为 --validate=true。
* Strict
** 严格的字段验证，验证失败时会报错
* Warn
** 执行字段验证，但错误会以警告形式提供而不是拒绝请求
* Ignore
** 不执行服务器端字段验证
当 kubectl 无法连接到支持字段验证的 API 服务器时，它将回退为使用客户端验证。 Kubernetes 1.27 及更高版本始终提供字段验证；较早的 Kubernetes 版本可能没有此功能。 如果你的集群版本低于 v1.27，可以查阅适用于你的 Kubernetes 版本的文档。

2023年8月22日 (二) 07:45的最新版本

在 Kubernetes 系统中，Kubernetes 对象 是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。 比较特别地是，它们描述了如下信息：

  • 哪些容器化应用正在运行（以及在哪些节点上运行）
  • 可以被应用使用的资源
  • 关于应用运行时表现的策略，比如重启策略、升级策略以及容错策略


Kubernetes 对象是“目标性记录” —— 一旦创建该对象，Kubernetes 系统将不断工作以确保该对象存在。 通过创建对象，你就是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的， 这就是 Kubernetes 集群所谓的 期望状态（Desired State）。


操作 Kubernetes 对象 —— 无论是创建、修改或者删除 —— 需要使用 Kubernetes API。 比如，当使用 kubectl 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API； 也可以在程序中使用客户端库， 来直接调用 Kubernetes API。


对象规约（Spec）与状态（Status）

几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置： 对象 spec（规约） 和 对象 status（状态）。 对于具有 spec 的对象，你必须在创建对象时设置其内容，描述你希望对象所具有的特征： 期望状态（Desired State）。

status 描述了对象的当前状态（Current State），它是由 Kubernetes 系统和组件设置并更新的。 在任何时刻，Kubernetes 控制平面 都一直都在积极地管理着对象的实际状态，以使之达成期望状态。

例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。 当创建 Deployment 时，可能会去设置 Deployment 的 spec，以指定该应用要有 3 个副本运行。 Kubernetes 系统读取 Deployment 的 spec， 并启动我们所期望的应用的 3 个实例 —— 更新状态以与规约相匹配。 如果这些实例中有的失败了（一种状态变更），Kubernetes 系统会通过执行修正操作来响应 spec 和状态间的不一致 —— 意味着它会启动一个新的实例来替换。


描述 Kubernetes 对象

创建 Kubernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态， 以及关于对象的一些基本信息（例如名称）。 当使用 Kubernetes API 创建对象时（直接创建，或经由 kubectl）， API 请求必须在请求本体中包含 JSON 格式的信息。 大多数情况下，你需要提供 .yaml 文件为 kubectl 提供这些信息。 kubectl 在发起 API 请求时，将这些信息转换成 JSON 格式。


必需字段

在想要创建的 Kubernetes 对象所对应的 .yaml 文件中，需要配置的字段如下：

  • apiVersion - 创建该对象所使用的 Kubernetes API 的版本
  • kind - 想要创建的对象的类别
  • metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
  • spec - 你所期望的该对象的状态

对每个 Kubernetes 对象而言，其 spec 之精确格式都是不同的，包含了特定于该对象的嵌套字段。


管理方法

指令式命令

指令式对象配置

声明式对象配置


名称

客户端提供的字符串，引用资源 URL 中的对象，如/api/v1/pods/some name。

某一时刻，只能有一个给定类型的对象具有给定的名称。但是，如果删除该对象，则可以创建同名的新对象。


以下是比较常见的四种资源命名约束。

  1. DNS子域名
    很多资源类型需要可以用作 DNS 子域名的名称。 DNS 子域名的定义可参见 RFC 1123。 这一要求意味着名称必须满足如下规则：
    • 不能超过 253 个字符
    • 只能包含小写字母、数字，以及 '-' 和 '.'
    • 必须以字母数字开头
    • 必须以字母数字结尾
  2. RFC 1123 标签名
    某些资源类型需要其名称遵循 RFC 1123 所定义的 DNS 标签标准。也就是命名必须满足如下规则：
    • 最多 63 个字符
    • 只能包含小写字母、数字，以及 '-'
    • 必须以字母数字开头
    • 必须以字母数字结尾
  3. RFC 1035 标签名
    某些资源类型需要其名称遵循 RFC 1035 所定义的 DNS 标签标准。也就是命名必须满足如下规则：
    • 最多 63 个字符
    • 只能包含小写字母、数字，以及 '-'
    • 必须以字母开头
    • 必须以字母数字结尾
  4. 路径分段名称
    某些资源类型要求名称能被安全地用作路径中的片段。 换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。


UID

Kubernetes 系统生成的字符串，唯一标识对象。

在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID，它旨在区分类似实体的历史事件。

Kubernetes UID 是全局唯一标识符（也叫 UUID）。 UUID 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。


标签和选择算符

标签（Labels） 是附加到 Kubernetes 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。

服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。 管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。 

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}


语法和字符集

标签是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（/）分隔。 名称段是必需的，必须小于等于 63 个字符，以字母数字字符（[a-z0-9A-Z]）开头和结尾， 带有破折号（-），下划线（_），点（ .）和之间的字母数字。 前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（.）分隔的一系列 DNS 标签，总共不超过 253 个字符， 后跟斜杠（/）。

如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 kube-scheduler、kube-controller-manager、 kube-apiserver、kubectl 或其他第三方自动化工具）必须指定前缀。

kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。


有效标签值：

  • 必须为 63 个字符或更少（可以为空）
  • 除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾
  • 包含破折号（-）、下划线（_）、点（.）和字母或数字


例如，这是一个有 environment: production 和 app: nginx 标签的 Pod 配置文件： 

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80


标签选择算符

与名称和 UID 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。

通过标签选择算符，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。

API 目前支持两种类型的选择算符：基于等值的和基于集合的。 标签选择算符可以由逗号分隔的多个需求组成。 在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑与（&&）运算符。

空标签选择算符或者未指定的选择算符的语义取决于上下文， 支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。


基于等值的需求

基于等值或基于不等值的需求允许按标签键和值进行过滤。 匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 可接受的运算符有 =、== 和 != 三种。 前两个表示相等（并且是同义词），而后者表示不相等。例如： 

environment = production
tier != frontend


前者选择所有资源，其键名等于 environment，值等于 production。 后者选择所有资源，其键名等于 tier，值不同于 frontend，所有资源都没有带有 tier 键的标签。 可以使用逗号运算符来过滤 production 环境中的非 frontend 层资源：environment=production,tier!=frontend。

基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。 例如，下面的示例 Pod 选择带有标签 "accelerator=nvidia-tesla-p100"。 

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100
基于集合的需求

基于集合的标签需求允许你通过一组值来过滤键。 支持三种操作符：in、notin 和 exists（只可以用在键标识符上）。例如： 

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition


第一个示例选择了所有键等于 environment 并且值等于 production 或者 qa 的资源。

第二个示例选择了所有键等于 tier 并且值不等于 frontend 或者 backend 的资源，以及所有没有 tier 键标签的资源。

第三个示例选择了所有包含了有 partition 标签的资源；没有校验它的值。

第四个示例选择了所有没有 partition 标签的资源；没有校验它的值。


类似地，逗号分隔符充当与运算符。因此，使用 partition 键（无论为何值）和 environment 不同于 qa 来过滤资源可以使用 partition, environment notin (qa) 来实现。

基于集合的标签选择算符是相等标签选择算符的一般形式，因为 environment=production 等同于 environment in (production)；!= 和 notin 也是类似的。

基于集合的要求可以与基于相等的要求混合使用。例如：partition in (customerA, customerB),environment!=qa。


名字空间

在 Kubernetes 中，名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。


何时使用多个名字空间

名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。当需要名字空间提供的功能时，请开始使用它们。

名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。 名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。

名字空间是在多个用户之间划分集群资源的一种方法（通过资源配额）。

不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本： 应该使用标签 来区分同一名字空间中的不同资源。


初始名字空间

Kubernetes 启动时会创建四个初始名字空间：

  1. default
    Kubernetes 包含这个名字空间，以便于你无需创建新的名字空间即可开始使用新集群。
  2. kube-node-lease
    该名字空间包含用于与各个节点关联的 Lease（租约）对象。 节点租约允许 kubelet 发送心跳，由此控制面能够检测到节点故障。
  3. kube-public
    所有的客户端（包括未经身份验证的客户端）都可以读取该名字空间。 该名字空间主要预留为集群使用，以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。
  4. kube-system
    该名字空间用于 Kubernetes 系统创建的对象。


使用名字空间

名字空间的创建和删除在名字空间的管理指南文档描述。


查看名字空间

你可以使用以下命令列出集群中现存的名字空间： 

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d


为请求设置名字空间

要为当前请求设置名字空间，请使用 --namespace 参数。

例如： 

kubectl run nginx --image=nginx --namespace=<名字空间名称>
kubectl get pods --namespace=<名字空间名称>


设置名字空间偏好

你可以永久保存名字空间，以用于对应上下文中所有后续 kubectl 命令。 

kubectl config set-context --current --namespace=<名字空间名称>
# 验证
kubectl config view --minify | grep namespace:


名字空间和 DNS

当你创建一个服务时， Kubernetes 会创建一个相应的 DNS 条目。

该条目的形式是 <服务名称>.<名字空间名称>.svc.cluster.local，这意味着如果容器只使用 <服务名称>，它将被解析到本地名字空间的服务。这对于跨多个名字空间（如开发、测试和生产） 使用相同的配置非常有用。如果你希望跨名字空间访问，则需要使用完全限定域名（FQDN）。

因此，所有的名字空间名称都必须是合法的 RFC 1123 DNS 标签。

为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 如果需要，你可以额外部署第三方的安全控制机制， 例如以准入 Webhook 的形式，阻止用户创建与公共 TLD 同名的名字空间。


并非所有对象都在名字空间中

大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源， 例如节点和持久化卷不属于任何名字空间。

查看哪些 Kubernetes 资源在名字空间中，哪些不在名字空间中： 

# 位于名字空间中的资源
kubectl api-resources --namespaced=true

# 不在名字空间中的资源
kubectl api-resources --namespaced=false


自动打标签

Kubernetes 控制面会为所有名字空间设置一个不可变更的 标签 kubernetes.io/metadata.name，只要 NamespaceDefaultLabelName 这一特性门控被启用。 标签的值是名字空间的名称。


注解

你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。


为对象附加元数据

你可以使用标签或注解将元数据附加到 Kubernetes 对象。 标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。


注解和标签一样，是键/值对： 

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}


以下是一些例子，用来说明哪些信息可以使用注解来记录：

  • 由声明性配置所管理的字段。 将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、 自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
  • 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
  • 指向日志记录、监控、分析或审计仓库的指针。
  • 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
  • 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
  • 轻量级上线工具的元数据信息：例如，配置或检查点。
  • 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
  • 从用户到最终运行的指令，以修改行为或使用非标准功能。


你可以将这类信息存储在外部数据库或目录中而不使用注解， 但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。


语法和字符集

注解（Annotations） 存储的形式是键/值对。有效的注解键分为两部分： 可选的前缀和名称，以斜杠（/）分隔。 名称段是必需项，并且必须在 63 个字符以内，以字母数字字符（[a-z0-9A-Z]）开头和结尾， 并允许使用破折号（-），下划线（_），点（.）和字母数字。 前缀是可选的。如果指定，则前缀必须是 DNS 子域：一系列由点（.）分隔的 DNS 标签， 总计不超过 253 个字符，后跟斜杠（/）。 如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解 （例如，kube-scheduler，kube-controller-manager，kube-apiserver，kubectl 或其他第三方组件），必须为终端用户添加注解前缀。

kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。


例如，下面是一个 Pod 的配置文件，其注解中包含 imageregistry: https://hub.docker.com/： 

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80


字段选择器

“字段选择器（Field selectors）”允许你根据一个或多个资源字段的值 筛选 Kubernetes 资源。 下面是一些使用字段选择器查询的例子： 

metadata.name=my-service
metadata.namespace!=default
status.phase=Pending


下面这个 kubectl 命令将筛选出 status.phase 字段值为 Running 的所有 Pod： 

kubectl get pods --field-selector status.phase=Running


支持的字段

不同的 Kubernetes 资源类型支持不同的字段选择器。 所有资源类型都支持 metadata.name 和 metadata.namespace 字段。 使用不被支持的字段选择器会产生错误。例如： 

kubectl get ingress --field-selector foo.bar=baz



Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

支持的操作符

你可在字段选择器中使用 =、== 和 != （= 和 == 的意义是相同的）操作符。 例如，下面这个 kubectl 命令将筛选所有不属于 default 命名空间的 Kubernetes 服务： 

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default


链式选择器

同标签和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 kubectl 命令将筛选 status.phase 字段不等于 Running 同时 spec.restartPolicy 字段等于 Always 的所有 Pod： 

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always


多种资源类型

你能够跨多种资源类型来使用字段选择器。 下面这个 kubectl 命令将筛选出所有不在 default 命名空间中的 StatefulSet 和 Service： 

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default


Finalizers

Finalizer 是带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。

当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时， Kubernetes API 通过填充 .metadata.deletionTimestamp 来标记要删除的对象， 并返回 202 状态码(HTTP "已接受") 使其进入只读状态。 此时控制平面或其他组件会采取 Finalizer 所定义的行动， 而目标对象仍然处于终止中（Terminating）的状态。 这些行动完成后，控制器会删除目标对象相关的 Finalizer。 当 metadata.finalizers 字段为空时，Kubernetes 认为删除已完成并删除对象。

你可以使用 Finalizer 控制资源的垃圾收集。 例如，你可以定义一个 Finalizer，在删除目标资源前清理相关资源或基础设施。

你可以通过使用 Finalizers 提醒控制器 在删除目标资源前执行特定的清理任务， 来控制资源的垃圾收集。

Finalizers 通常不指定要执行的代码。 相反，它们通常是特定资源上的键的列表，类似于注解。 Kubernetes 自动指定了一些 Finalizers，但你也可以指定你自己的。


Finalizers 如何工作

当你使用清单文件创建资源时，你可以在 metadata.finalizers 字段指定 Finalizers。 当你试图删除该资源时，处理删除请求的 API 服务器会注意到 finalizers 字段中的值， 并进行以下操作：

  1. 修改对象，将你开始执行删除的时间添加到 metadata.deletionTimestamp 字段。
  2. 禁止对象被删除，直到其 metadata.finalizers 字段为空。
  3. 返回 202 状态码（HTTP "Accepted"）。


管理 finalizer 的控制器注意到对象上发生的更新操作，对象的 metadata.deletionTimestamp 被设置，意味着已经请求删除该对象。然后，控制器会试图满足资源的 Finalizers 的条件。 每当一个 Finalizer 的条件被满足时，控制器就会从资源的 finalizers 字段中删除该键。 当 finalizers 字段为空时，deletionTimestamp 字段被设置的对象会被自动删除。 你也可以使用 Finalizers 来阻止删除未被管理的资源。

一个常见的 Finalizer 的例子是 kubernetes.io/pv-protection， 它用来防止意外删除 PersistentVolume 对象。 当一个 PersistentVolume 对象被 Pod 使用时， Kubernetes 会添加 pv-protection Finalizer。 如果你试图删除 PersistentVolume，它将进入 Terminating 状态， 但是控制器因为该 Finalizer 存在而无法删除该资源。 当 Pod 停止使用 PersistentVolume 时， Kubernetes 清除 pv-protection Finalizer，控制器就会删除该卷。


属主引用、标签和 Finalizers

与标签类似， 属主引用 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 当一个控制器 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 例如，当 Job 创建一个或多个 Pod 时， Job 控制器会给这些 Pod 应用上标签，并跟踪集群中的具有相同标签的 Pod 的变化。

Job 控制器还为这些 Pod 添加了“属主引用”，指向创建 Pod 的 Job。 如果你在这些 Pod 运行的时候删除了 Job， Kubernetes 会使用属主引用（而不是标签）来确定集群中哪些 Pod 需要清理。

当 Kubernetes 识别到要删除的资源上的属主引用时，它也会处理 Finalizers。

在某些情况下，Finalizers 会阻止依赖对象的删除， 这可能导致目标属主对象被保留的时间比预期的长，而没有被完全删除。 在这些情况下，你应该检查目标属主和附属对象上的 Finalizers 和属主引用，来排查原因。


属主与附属

在 Kubernetes 中，一些对象是其他对象的“属主（Owner）”。 例如，ReplicaSet 是一组 Pod 的属主。 具有属主的对象是属主的“附属（Dependent）”。

属主关系不同于一些资源使用的标签和选择算符机制。 例如，有一个创建 EndpointSlice 对象的 Service， 该 Service 使用标签来让控制平面确定，哪些 EndpointSlice 对象属于该 Service。 除开标签，每个代表 Service 所管理的 EndpointSlice 都有一个属主引用。 属主引用避免 Kubernetes 的不同部分干扰到不受它们控制的对象。


对象规约中的属主引用

附属对象有一个 metadata.ownerReferences 字段，用于引用其属主对象。 一个有效的属主引用，包含与附属对象同在一个命名空间下的对象名称和一个 UID。 Kubernetes 自动为一些对象的附属资源设置属主引用的值， 这些对象包含 ReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationController 等。 你也可以通过改变这个字段的值，来手动配置这些关系。 然而，通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。

附属对象还有一个 ownerReferences.blockOwnerDeletion 字段，该字段使用布尔值， 用于控制特定的附属对象是否可以阻止垃圾收集删除其属主对象。 如果控制器（例如 Deployment 控制器） 设置了 metadata.ownerReferences 字段的值，Kubernetes 会自动设置 blockOwnerDeletion 的值为 true。 你也可以手动设置 blockOwnerDeletion 字段的值，以控制哪些附属对象会阻止垃圾收集。

Kubernetes 准入控制器根据属主的删除权限控制用户访问，以便为附属资源更改此字段。 这种控制机制可防止未经授权的用户延迟属主对象的删除。


属主关系与 Finalizer

当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 Finalizer 规则。 Finalizer 防止意外删除你的集群所依赖的、用于正常运作的资源。 例如，如果你试图删除一个仍被 Pod 使用的 PersistentVolume，该资源不会被立即删除， 因为 PersistentVolume 有 kubernetes.io/pv-protection Finalizer。 相反，它将进入 Terminating 状态，直到 Kubernetes 清除这个 Finalizer， 而这种情况只会发生在 PersistentVolume 不再被挂载到 Pod 上时。

当你使用前台或孤立级联删除时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 foreground Finalizer，这样控制器必须在删除了拥有 ownerReferences.blockOwnerDeletion=true 的附属资源后，才能删除属主对象。 如果你指定了孤立删除策略，Kubernetes 会添加 orphan Finalizer， 这样控制器在删除属主对象后，会忽略附属资源。


推荐使用的标签

除了 kubectl 和 dashboard 之外，你还可以使用其他工具来可视化和管理 Kubernetes 对象。 一组通用的标签可以让多个工具之间相互操作，用所有工具都能理解的通用方式描述对象。

除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。

元数据围绕 应用（application） 的概念进行组织。Kubernetes 不是平台即服务（PaaS），没有或强制执行正式的应用程序概念。 相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。

共享标签和注解都使用同一个前缀：app.kubernetes.io。没有前缀的标签是用户私有的。 共享前缀可以确保共享标签不会干扰用户自定义的标签。


标签

为了充分利用这些标签，应该在每个资源对象上都使用它们。

键 描述 示例 类型
app.kubernetes.io/name 应用程序的名称 mysql 字符串
app.kubernetes.io/instance 用于唯一确定应用实例的名称 mysql-abcxzy 字符串
app.kubernetes.io/version 应用程序的当前版本 5.7.21 字符串
app.kubernetes.io/component 架构中的组件 database 字符串
app.kubernetes.io/part-of 此级别的更高级别应用程序的名称 wordpress 字符串
app.kubernetes.io/managed-by 用于管理应用程序的工具 helm 字符串


为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象： 

# 这是一段节选
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm

应用和应用实例

应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。 例如，可以不止一次地为不同的站点安装不同的 WordPress。

应用的名称和实例的名称是分别记录的。例如，WordPress 应用的 app.kubernetes.io/name 为 wordpress，而其实例名称 app.kubernetes.io/instance 为 wordpress-abcxzy。 这使得应用和应用的实例均可被识别，应用的每个实例都必须具有唯一的名称。


示例

为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。


一个简单的无状态服务

考虑使用 Deployment 和 Service 对象部署的简单无状态服务的情况。 以下两个代码段表示如何以最简单的形式使用标签。


下面的 Deployment 用于监督运行应用本身的那些 Pod。 

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

下面的 Service 用于暴露应用。 

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...


带有一个数据库的 Web 应用程序

考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress）， 其中使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。


以下 Deployment 的开头用于 WordPress： 

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...


这个 Service 用于暴露 WordPress： 

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...


MySQL 作为一个 StatefulSet 暴露，包含它和它所属的较大应用程序的元数据： 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...


Service 用于将 MySQL 作为 WordPress 的一部分暴露： 

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...


使用 MySQL StatefulSet 和 Service，你会注意到有关 MySQL 和 WordPress 的信息，包括更广泛的应用程序。


服务器端字段验证

从 Kubernetes v1.25 开始，API 服务器提供了服务器端字段验证， 可以检测对象中未被识别或重复的字段。它在服务器端提供了 kubectl --validate 的所有功能。

kubectl 工具使用 --validate 标志来设置字段验证级别。它接受值 ignore、warn 和 strict，同时还接受值 true（等同于 strict）和 false（等同于 ignore）。kubectl 的默认验证设置为 --validate=true。

  • Strict
    • 严格的字段验证，验证失败时会报错
  • Warn
    • 执行字段验证，但错误会以警告形式提供而不是拒绝请求
  • Ignore
    • 不执行服务器端字段验证

当 kubectl 无法连接到支持字段验证的 API 服务器时，它将回退为使用客户端验证。 Kubernetes 1.27 及更高版本始终提供字段验证；较早的 Kubernetes 版本可能没有此功能。 如果你的集群版本低于 v1.27，可以查阅适用于你的 Kubernetes 版本的文档。

取自“http://bubblestudy.info/wiki/index.php?title=Kubernetes对象&oldid=1947”