kubernetes-文档

https://kubernetes.io/zh/docs/home/

了解 Kubernetes

Kubernetes 是什么？

此页面是 Kubernetes 的概述。

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上，结合了社区中最好的想法和实践。

时光回溯

让我们回顾一下为什么 Kubernetes 如此有用。

部署演进

传统部署时代：

早期，各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且维护许多物理服务器的成本很高。

虚拟化部署时代：

作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序而可以实现更好的可伸缩性，降低硬件成本等等。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处：

敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的容器镜像构建和部署。
关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
资源隔离：可预测的应用程序性能。
资源利用：高效率和高密度。

为什么需要 Kubernetes，它能做什么?

容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？

这就是 Kubernetes 来解决这些问题的方法！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes 为你提供：

服务发现和负载均衡

Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

存储编排

Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

自动部署和回滚

你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。

自动完成装箱计算

Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

自我修复

Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

密钥与配置管理

Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

Kubernetes 不是什么

Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。 Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。

Kubernetes：

不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
不部署源代码，也不构建你的应用程序。持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如，开放服务代理）来访问。

不要求日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。
不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、系统更健壮、更为弹性和可扩展。

Kubernetes 组件

当你部署完 Kubernetes, 即拥有了一个完整的集群。

一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。

工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。

本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。

Kubernetes 的组件

Kubernetes 集群的组件

控制平面组件（Control Plane Components）

控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。

控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅使用 kubeadm 构建高可用性集群中关于跨多机器控制平面设置的示例。

kube-apiserver

API 服务器是 Kubernetes 控制面的组件，该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

etcd

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。

要了解 etcd 更深层次的信息，请参考 etcd 文档。

kube-scheduler

控制平面组件，负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

kube-controller-manager

运行控制器进程的控制平面组件。

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

这些控制器包括:

节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

cloud-controller-manager

云控制器管理器是指嵌入特定云的控制逻辑的控制平面组件。云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制回路。如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，所部署的环境中不需要云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

Node 组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet

一个在集群中每个节点（node）上运行的代理。它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kube-proxy

kube-proxy 是集群中每个节点上运行的网络代理，实现 Kubernetes 服务（Service）概念的一部分。

kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。

容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件。

Kubernetes 支持容器运行时，例如 Docker、 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

下面描述众多插件中的几种。有关可用插件的完整列表，请参见插件（Addons）。

DNS

尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS，因为很多示例都需要 DNS 服务。

集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web 界面（仪表盘）

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。

容器资源监控

容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。

集群层面日志

集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

Kubernetes API

Kubernetes 控制面的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。

大部分操作都可以通过 kubectl 命令行接口或类似 kubeadm 这类命令行工具来执行，这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。

如果你正在编写程序来访问 Kubernetes API，可以考虑使用客户端库之一。

OpenAPI 规范

完整的 API 细节是用 OpenAPI 来表述的。

OpenAPI V2

Kubernetes API 服务器通过 /openapi/v2 端点提供聚合的 OpenAPI v2 规范。你可以按照下表所给的请求头部，指定响应的格式：

OpenAPI v2 查询请求的合法头部值
头部	可选值	说明
`Accept-Encoding`	`gzip`	不指定此头部也是可以的
`Accept`	`application/com.github.proto-openapi.spec.v2@v1.0+protobuf`	主要用于集群内部
	`application/json`	默认值
	`*`	提供`application/json`

Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。关于此格式的详细信息，可参考 Kubernetes Protobuf 序列化设计提案。每种模式对应的接口描述语言（IDL）位于定义 API 对象的 Go 包中。

OpenAPI V3

FEATURE STATE: Kubernetes v1.23 [alpha]

Kubernetes v1.23 提供将其 API 以 OpenAPI v3 形式发布的初始支持；这一功能特性处于 Alpha 状态，默认被禁用。你可以通过为 kube-apiserver 组件启用 OpenAPIV3 特性门控来启用此 Alpha 特性。

特性被启用时，Kubernetes API 服务器会在端点 /openapi/v3/apis/<group>/<version> 提供按 Kubernetes 组版本聚合的 OpenAPI v3 规范。请参阅下表了解可接受的请求头部。

头部	可选值	说明
`Accept-Encoding`	`gzip`	不提供此头部也是可接受的
`Accept`	`application/com.github.proto-openapi.spec.v3@v1.0+protobuf`	主要用于集群内部使用
	`application/json`	默认
	`*`	以 `application/json` 形式返回

发现端点 /openapi/v3 被提供用来查看可用的所有组、版本列表。此列表仅返回 JSON。

API 变更

任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 Kubernetes 项目的目标是不要引发现有客户端的兼容性问题，并在一定的时期内维持这种兼容性，以便其他项目有机会作出适应性变更。

一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。删除资源或者字段则要遵从 API 废弃策略。

Kubernetes 对维护达到正式发布（GA）阶段的官方 API 的兼容性有着很强的承诺，通常这一 API 版本为 v1。此外，Kubernetes 在可能的时候还会保持 Beta API 版本的兼容性：如果你采用了 Beta API，你可以继续在集群上使用该 API，即使该功能特性已进入稳定期也是如此。

Note:

尽管 Kubernetes 也努力为 Alpha API 版本维护兼容性，在有些场合兼容性是无法做到的。如果你使用了任何 Alpha API 版本，需要在升级集群时查看 Kubernetes 发布说明，以防 API 的确发生变更。

使用 Kubernetes 对象

本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 .yaml 格式的文件中表示。

理解 Kubernetes 对象

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

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

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

操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 Kubernetes API。比如，当使用 kubectl 命令行接口时，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 规约，并启动我们所期望的应用的 3 个实例 —— 更新状态以与规约相匹配。如果这些实例中有的失败了（一种状态变更），Kubernetes 系统通过执行修正操作来响应规约和状态间的不一致 —— 在这里意味着它会启动一个新的实例来替换。

关于对象 spec、status 和 metadata 的更多信息，可参阅 Kubernetes API 约定。

描述 Kubernetes 对象

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

这里有一个 .yaml 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约：

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

使用类似于上面的 .yaml 文件来创建 Deployment的一种方式是使用 kubectl 命令行接口（CLI）中的 kubectl apply 命令，将 .yaml 文件作为参数。下面是一个示例：

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

输出类似如下这样：

deployment.apps/nginx-deployment created

必需字段

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

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

对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。 Kubernetes API 参考能够帮助我们找到任何我们想创建的对象的规约格式。

例如，参阅 Pod API 参考文档中 spec 字段。对于每个 Pod，其 .spec 字段设置了 Pod 及其期望状态（例如 Pod 中每个容器的容器镜像名称）。另一个对象规约的例子是 StatefulSet API 中的 spec 字段。对于 StatefulSet 而言，其 .spec 字段设置了 StatefulSet 及其期望状态。在 StatefulSet 的 .spec 内，有一个为 Pod 对象提供的模板。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。不同类型的对象可以由不同的 .status 信息。API 参考页面给出了 .status 字段的详细结构，以及针对不同类型 API 对象的具体内容。

Kubernetes 对象管理

kubectl 命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。本文档概述了不同的方法。阅读 Kubectl book 来了解 kubectl 管理对象的详细信息。

管理技巧

Warning:

应该只使用一种技术来管理 Kubernetes 对象。混合和匹配技术作用在同一对象上将导致未定义行为。

管理技术	作用于	建议的环境	支持的写者	学习难度
指令式命令	活跃对象	开发项目	1+	最低
指令式对象配置	单个文件	生产项目	1	中等
声明式对象配置	文件目录	生产项目	1+	最高

指令式命令

使用指令式命令时，用户可以在集群中的活动对象上进行操作。用户将操作传给 kubectl 命令作为参数或标志。

这是开始或者在集群中运行一次性任务的推荐方法。因为这个技术直接在活跃对象上操作，所以它不提供以前配置的历史记录。

例子

通过创建 Deployment 对象来运行 nginx 容器的实例：

kubectl create deployment nginx --image nginx

权衡

与对象配置相比的优点：

命令简单，易学且易于记忆。
命令仅需一步即可对集群进行更改。

与对象配置相比的缺点：

命令不与变更审查流程集成。
命令不提供与更改关联的审核跟踪。
除了实时内容外，命令不提供记录源。
命令不提供用于创建新对象的模板。

指令式对象配置

在指令式对象配置中，kubectl 命令指定操作（创建，替换等），可选标志和至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。

有关对象定义的详细信息，请查看 API 参考。

Warning:

replace 指令式命令将现有规范替换为新提供的规范，并放弃对配置文件中缺少的对象的所有更改。此方法不应与对象规约被独立于配置文件进行更新的资源类型一起使用。比如类型为 LoadBalancer 的服务，它的 externalIPs 字段就是独立于集群配置进行更新。

例子

创建配置文件中定义的对象：

kubectl create -f nginx.yaml

删除两个配置文件中定义的对象：

kubectl delete -f nginx.yaml -f redis.yaml

通过覆盖活动配置来更新配置文件中定义的对象：

kubectl replace -f nginx.yaml

权衡

与指令式命令相比的优点：

对象配置可以存储在源控制系统中，比如 Git。
对象配置可以与流程集成，例如在推送和审计之前检查更新。
对象配置提供了用于创建新对象的模板。

与指令式命令相比的缺点：

对象配置需要对对象架构有基本的了解。
对象配置需要额外的步骤来编写 YAML 文件。

与声明式对象配置相比的优点：

指令式对象配置行为更加简单易懂。
从 Kubernetes 1.5 版本开始，指令对象配置更加成熟。

与声明式对象配置相比的缺点：

指令式对象配置更适合文件，而非目录。
对活动对象的更新必须反映在配置文件中，否则会在下一次替换时丢失。

声明式对象配置

使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户未定义要对该文件执行的操作。 kubectl 会自动检测每个文件的创建、更新和删除操作。这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。

Note:

声明式对象配置保留其他编写者所做的修改，即使这些更改并未合并到对象配置文件中。可以通过使用 patch API 操作仅写入观察到的差异，而不是使用 replace API 操作来替换整个对象配置来实现。

例子

处理 configs 目录中的所有对象配置文件，创建并更新活跃对象。可以首先使用 diff 子命令查看将要进行的更改，然后在进行应用：

kubectl diff -f configs/
kubectl apply -f configs/

递归处理目录：

kubectl diff -R -f configs/
kubectl apply -R -f configs/

权衡

与指令式对象配置相比的优点：

对活动对象所做的更改即使未合并到配置文件中，也会被保留下来。
声明性对象配置更好地支持对目录进行操作并自动检测每个文件的操作类型（创建，修补，删除）。

与指令式对象配置相比的缺点：

声明式对象配置难于调试并且出现异常时结果难以理解。
使用 diff 产生的部分更新会创建复杂的合并和补丁操作。

对象名称和 IDs

集群中的每一个对象都有一个名称来标识在同类资源中的唯一性。

每个 Kubernetes 对象也有一个UID 来标识在整个集群中的唯一性。

比如，在同一个名字空间中有一个名为 myapp-1234 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 myapp-1234.

对于用户提供的非唯一性的属性，Kubernetes 提供了标签（Labels）和注解（Annotation）机制。

名称

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

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

Note:

当对象所代表的是一个物理实体（例如代表一台物理主机的 Node）时，如果在 Node 对象未被删除并重建的条件下，重新创建了同名的物理主机，则 Kubernetes 会将新的主机看作是老的主机，这可能会带来某种不一致性。

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

DNS 子域名

很多资源类型需要可以用作 DNS 子域名的名称。 DNS 子域名的定义可参见 RFC 1123。这一要求意味着名称必须满足如下规则：

不能超过253个字符
只能包含小写字母、数字，以及'-' 和 '.'
须以字母数字开头
须以字母数字结尾

RFC 1123 标签名

某些资源类型需要其名称遵循 RFC 1123 所定义的 DNS 标签标准。也就是命名必须满足如下规则：

最多 63 个字符
只能包含小写字母、数字，以及 '-'
须以字母数字开头
须以字母数字结尾

RFC 1035 标签名

某些资源类型需要其名称遵循 RFC 1035 所定义的 DNS 标签标准。也就是命名必须满足如下规则：

最多 63 个字符
只能包含小写字母、数字，以及 '-'
须以字母开头
须以字母数字结尾

路径分段名称

某些资源类型要求名称能被安全地用作路径中的片段。换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。

下面是一个名为nginx-demo的 Pod 的配置清单：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Note: 某些资源类型可能具有额外的命名约束。

UIDs

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

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

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

标签和选择算符

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

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

标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。应使用注解记录非识别信息。

动机

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

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

示例标签：

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

有一些常用标签的例子; 你可以任意制定自己的约定。请记住，标签的 Key 对于给定对象必须是唯一的。

语法和字符集

标签是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（/）分隔。名称段是必需的，必须小于等于 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]）开头和结尾
包含破折号（-）、下划线（_）、点（.）和字母或数字。

标签选择算符

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

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

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

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

Note: 对于某些 API 类别（例如 ReplicaSet）而言，两个实例的标签选择算符不得在命名空间内重叠，否则它们的控制器将互相冲突，无法确定应该存在的副本个数。

Caution: 对于基于等值的和基于集合的条件而言，不存在逻辑或（||）操作符。你要确保你的过滤语句按合适的方式组织。

基于等值的需求

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

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: "k8s.gcr.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。

API

LIST 和 WATCH 过滤

LIST 和 WATCH 操作可以使用查询参数指定标签选择算符过滤一组对象。两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中）

基于等值 的需求: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
基于集合 的需求: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。例如，使用 kubectl 定位 apiserver，可以使用 基于等值 的标签选择算符可以这么写：

kubectl get pods -l environment=production,tier=frontend

或者使用 基于集合的 需求：

kubectl get pods -l 'environment in (production),tier in (frontend)'

正如刚才提到的，基于集合 的需求更具有表达力。例如，它们可以实现值的或操作：

kubectl get pods -l 'environment in (production, qa)'

或者通过 exists 运算符限制不匹配：

kubectl get pods -l 'environment,environment notin (frontend)'

在 API 对象中设置引用

一些 Kubernetes 对象，例如 services 和 replicationcontrollers ，也使用了标签选择算符去指定了其他资源的集合，例如 pods。

Service 和 ReplicationController

一个 Service 指向的一组 Pods 是由标签选择算符定义的。同样，一个 ReplicationController 应该管理的 pods 的数量也是由标签选择算符定义的。

两个对象的标签选择算符都是在 json 或者 yaml 文件中使用映射定义的，并且只支持 基于等值 需求的选择算符：

"selector": {
    "component" : "redis",
}

或者

selector:
    component: redis

这个选择算符(分别在 json 或者 yaml 格式中) 等价于 component=redis 或 component in (redis) 。

支持基于集合需求的资源

比较新的资源，例如 Job、 Deployment、 Replica Set 和 DaemonSet ，也支持 基于集合的 需求。

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels 是由 {key,value} 对组成的映射。 matchLabels 映射中的单个 {key,value } 等同于 matchExpressions 的元素，其 key 字段为 "key"，operator 为 "In"，而 values 数组仅包含 "value"。 matchExpressions 是 Pod 选择算符需求的列表。有效的运算符包括 In、NotIn、Exists 和 DoesNotExist。在 In 和 NotIn 的情况下，设置的值必须是非空的。来自 matchLabels 和 matchExpressions 的所有要求都按逻辑与的关系组合到一起 -- 它们必须都满足才能匹配。

选择节点集

通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。有关更多信息，请参阅选择节点文档。

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 和属主引用，来排查原因。

Note:

在对象卡在删除状态的情况下，要避免手动移除 Finalizers，以允许继续删除操作。 Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它们会导致集群出现问题。只有了解 finalizer 的用途时才能这样做，并且应该通过一些其他方式来完成（例如，手动清除其余的依赖对象）。

字段选择器

“字段选择器（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

Note:

字段选择器本质上是资源过滤器（Filters）。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。这使得以下的两个 kubectl 查询是等价的：

kubectl get pods
kubectl get pods --field-selector ""

支持的字段

不同的 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

属主与附属

在 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 字段的值，以控制哪些附属对象会阻止垃圾收集。

Note:

根据设计，kubernetes 不允许跨名字空间指定属主。名字空间范围的附属可以指定集群范围的或者名字空间范围的属主。名字空间范围的属主必须和该附属处于相同的名字空间。如果名字空间范围的属主和附属不在相同的名字空间，那么该属主引用就会被认为是缺失的，并且当附属的所有属主引用都被确认不再存在之后，该附属就会被删除。

集群范围的附属只能指定集群范围的属主。在 v1.20+ 版本，如果一个集群范围的附属指定了一个名字空间范围类型的属主，那么该附属就会被认为是拥有一个不可解析的属主引用，并且它不能够被垃圾回收。

在 v1.20+ 版本，如果垃圾收集器检测到无效的跨名字空间的属主引用，或者一个集群范围的附属指定了一个名字空间范围类型的属主，那么它就会报告一个警告事件。该事件的原因是 OwnerRefInvalidNamespace， involvedObject 属性中包含无效的附属。你可以运行 kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace 来获取该类型的事件。

属主关系与 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，这样控制器在删除属主对象后，会忽略附属资源。

键	描述	示例	类型
`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`	字符串
`app.kubernetes.io/created-by`	创建该资源的控制器或者用户	`controller-manager`	字符串

hanease

kubernetes-文档

了解 Kubernetes

Kubernetes 是什么？

时光回溯

为什么需要 Kubernetes，它能做什么?

Kubernetes 不是什么

Kubernetes 组件

控制平面组件（Control Plane Components）

kube-apiserver

etcd

kube-scheduler

kube-controller-manager

cloud-controller-manager

Node 组件

kubelet

kube-proxy

容器运行时（Container Runtime）

插件（Addons）

DNS

Web 界面（仪表盘）

容器资源监控

集群层面日志

Kubernetes API

OpenAPI 规范

OpenAPI V2

OpenAPI V3

API 变更

使用 Kubernetes 对象

理解 Kubernetes 对象

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

描述 Kubernetes 对象

必需字段

Kubernetes 对象管理

管理技巧

指令式命令

例子

权衡

指令式对象配置

例子

权衡

声明式对象配置

例子

权衡

对象名称和 IDs

名称

DNS 子域名

RFC 1123 标签名

RFC 1035 标签名

路径分段名称

UIDs

标签和选择算符

动机

语法和字符集

标签选择算符

基于等值的 需求

基于集合 的需求

API

LIST 和 WATCH 过滤

在 API 对象中设置引用

Service 和 ReplicationController

支持基于集合需求的资源

选择节点集

Finalizers

Finalizers 如何工作

属主引用、标签和 Finalizers

字段选择器

支持的字段

支持的操作符

链式选择器

多种资源类型

属主与附属

对象规约中的属主引用

属主关系与 Finalizer

推荐使用的标签

标签

应用和应用实例

示例

一个简单的无状态服务

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

基于等值的需求

基于集合的需求