术语表
本术语表旨在成为 Kubernetes 术语的全面、标准化的列表。它包括 Kubernetes 特有的技术术语以及提供有用上下文的更通用术语。
根据标签过滤术语
点击下方 [+] 符号以查看任何特定术语的更详细解释。
在对象持久化之前拦截对 Kubernetes API 服务器请求的一段代码。
[+]准入控制器可在 Kubernetes API 服务器上配置，可以是“验证型”、“变更型”或两者兼具。任何准入控制器都可以拒绝请求。变更型控制器可以修改它们准入的对象；验证型控制器则不能。
聚合层允许你在你的集群中安装额外的 Kubernetes 风格的 API。
[+]当你配置 Kubernetes API 服务器以支持额外的 API后，你可以添加
APIService对象来“声明”Kubernetes API 中的 URL 路径。- 亦称：资源
Kubernetes 类型系统中的一个实体，对应于Kubernetes API上的一个端点。资源通常表示一个对象。有些资源表示对其他对象的操作，例如权限检查。
[+]每个资源代表 Kubernetes API 服务器上的一个 HTTP 端点（URI），定义了该资源上的对象或操作的 schema。
- 亦称：kube-apiserver
API 服务器是 Kubernetes 控制平面的一个组件，它暴露了 Kubernetes API。API 服务器是 Kubernetes 控制平面的前端。
[+]Kubernetes API 服务器的主要实现是 kube-apiserver。kube-apiserver 被设计为横向扩展——即通过部署更多实例来扩展。你可以运行多个 kube-apiserver 实例并在这些实例之间平衡流量。
API 发起的驱逐是你使用Eviction API创建
[+]Eviction对象来触发优雅的 Pod 终止的过程。你可以通过使用 kube-apiserver 的客户端（例如
kubectl drain命令）直接调用 Eviction API 来请求驱逐。当创建一个Eviction对象时，API 服务器会终止 Pod。API 发起的驱逐会遵守你配置的
PodDisruptionBudgets和terminationGracePeriodSeconds。API 发起的驱逐与节点压力驱逐不同。
- 请参阅API 发起的驱逐了解更多信息。
负责应用程序高层设计的人。
[+]架构师确保应用的实现方式能够以可伸缩、可维护的方式与周围组件交互。周围组件包括数据库、日志基础设施以及其他微服务。
编写在 Kubernetes 集群中运行的应用程序的人。
[+]应用开发者专注于应用程序的一部分。他们的关注范围大小可能差异很大。
- 运行各种容器化应用的层。[+]
运行各种容器化应用的层。
可以评审和批准 Kubernetes 代码贡献的人。
[+]代码评审侧重于代码质量和正确性，而审批则侧重于贡献的整体接受度。整体接受度包括向后/向前兼容性、遵守 API 和标志约定、细微的性能和正确性问题、与系统其他部分的交互等。审批者状态仅限于代码库的一部分。审批者以前被称为维护者。
用于验证对 Kubernetes 集群访问的加密安全文件。
[+]证书使 Kubernetes 集群内的应用程序能够安全地访问 Kubernetes API。证书验证客户端是否被允许访问 API。
一组具有可选资源隔离、记账和限制的 Linux 进程。
[+]cgroup 是 Linux 内核的一项特性，用于限制、记账和隔离一组进程的资源使用（CPU、内存、磁盘 I/O、网络）。
设计涉及一个或多个 Kubernetes 集群的基础设施的人。
[+]集群架构师关注分布式系统的最佳实践，例如：高可用性和安全性。
- 基础设施层提供并维护虚拟机、网络、安全组等。[+]
基础设施层提供并维护虚拟机、网络、安全组等。
管理 Kubernetes 集群所涉及的工作：日常运维管理和协调升级。
[+]集群运维工作示例包括：部署新节点以扩缩集群；执行软件升级；实施安全控制；添加或移除存储；配置集群网络；管理集群范围的可观测性；以及响应事件。
配置、控制和监控集群的人。
[+]他们的主要职责是保持集群正常运行，这可能涉及周期性维护活动或升级。
注意
集群运维工程师不同于扩展 Kubernetes API 的Operator 模式。开发代码并将其贡献给 Kubernetes 开源代码库的人。
[+]他们也是积极的社区成员，参与一个或多个特别兴趣小组 (SIG)。
轻量级且可移植的可执行镜像，包含软件及其所有依赖项。
[+]容器将应用程序与底层主机基础设施解耦，以便在不同的云或操作系统环境中更容易部署，也更容易伸缩。在容器内部运行的应用程序称为容器化应用程序。将这些应用程序及其依赖项打包到容器镜像中的过程称为容器化。
赋能 Kubernetes 有效运行容器的基础组件。它负责管理 Kubernetes 环境中容器的执行和生命周期。
[+]Kubernetes 支持诸如 containerd、CRI-O 等容器运行时，以及 Kubernetes CRI（容器运行时接口）的任何其他实现。
kubelet 与容器运行时之间通信的主要协议。
[+]The Kubernetes Container Runtime Interface (CRI) defines the main gRPC protocol for the communication between the node components kubelet and container runtime.
容器存储接口 (CSI) 定义了用于将存储系统暴露给容器的标准接口。
[+]CSI 允许供应商为 Kubernetes 创建自定义存储插件，而无需将它们添加到 Kubernetes 代码库（即树外插件）。要使用存储供应商的 CSI 驱动程序，你必须首先将其部署到集群中。然后你就可以创建一个使用该 CSI 驱动程序的Storage Class。
为帮助 Kubernetes 项目或社区而贡献代码、文档或时间的人。
[+]贡献包括 Pull Request (PR)、Issue、反馈、参与特别兴趣小组 (SIG) 或组织社区活动。
在 Kubernetes 中，控制器是控制循环，负责监视集群状态，然后在需要时进行或请求更改。每个控制器都试图使当前的集群状态更接近期望状态。
[+]控制器通过apiserver（控制平面的一部分）监视集群的共享状态。
一些控制器也运行在控制平面内部，提供作为 Kubernetes 操作核心的控制循环。例如：Deployment 控制器、DaemonSet 控制器、Namespace 控制器和 Persistent Volume 控制器（以及其他）都运行在kube-controller-manager 中。
一个工具，让你可以在 Kubernetes CRI 中使用 OCI 容器运行时。
[+]CRI-O 是容器运行时接口 (CRI) 的一个实现，用于启用兼容 Open Container Initiative (OCI) 运行时规范的容器运行时。
部署 CRI-O 允许 Kubernetes 使用任何 OCI 兼容的运行时作为容器运行时来运行Pod，并从远程注册表拉取 OCI 容器镜像。
自定义代码，用于定义要添加到 Kubernetes API Server 的资源，而无需构建完整的自定义服务器。
[+]如果公开支持的 API 资源无法满足你的需求，Custom Resource Definitions 允许你为你的环境扩展 Kubernetes API。
- 提供 CPU、内存、网络和存储等资源容量的层，以便容器能够运行并连接到网络。[+]
提供 CPU、内存、网络和存储等资源容量的层，以便容器能够运行并连接到网络。
管理复制应用的 API 对象，通常通过运行没有本地状态的 Pod 来实现。
[+]每个副本由一个Pod 表示，并且 Pod 分布在集群的节点之间。对于确实需要本地状态的工作负载，请考虑使用StatefulSet。
中断是导致一个或多个Pod 停止服务的事件。中断会对依赖受影响 Pod 的工作负载资源（例如Deployment）产生影响。
[+]如果你作为集群操作员，销毁属于某个应用的 Pod，Kubernetes 将其称为*自愿中断（voluntary disruption）*。如果一个 Pod 因为节点故障或影响更广泛故障区域的停机而离线，Kubernetes 将其称为*非自愿中断（involuntary disruption）*。
参见中断了解更多信息。
dockershim 是 Kubernetes 1.23 及更早版本中的一个组件。它允许kubelet 与Docker Engine 通信。
[+]从 1.24 版本开始，dockershim 已从 Kubernetes 中移除。有关更多信息，请参见Dockershim FAQ。
可以指：依赖核心 Kubernetes 代码库或分支仓库的 Kubernetes 生态系统中的代码。
[+]- 在**Kubernetes 社区**：讨论中经常使用*下游*来指代依赖核心 Kubernetes 代码库的生态系统、代码或第三方工具。例如，Kubernetes 中的一个新功能可能会被下游应用采用以改进其功能。
- 在 **GitHub** 或 **git** 中：约定俗成的说法是将分支仓库称为*下游*，而源仓库则被视为*上游*。
Kubernetes 用于将 Pod 和容器字段值暴露给容器中运行的代码的机制。
[+]有时容器获取关于自身的信息很有用，而无需修改容器代码使其直接与 Kubernetes 耦合。
Kubernetes downward API 允许容器消费关于自身或其在 Kubernetes 集群中上下文的信息。容器中的应用可以访问这些信息，而无需该应用充当 Kubernetes API 的客户端。
有两种方式将 Pod 和容器字段暴露给运行中的容器
总而言之，这两种暴露 Pod 和容器字段的方式称为 *downward API*。
表示一段时间的字符串值。
[+](Kubernetes) 持续时间的格式基于 Go 编程语言中的
time.Duration类型。在 Kubernetes 中使用持续时间的 API 中，该值表示为一系列非负整数与时间单位后缀的组合。你可以有多个时间量，持续时间是这些时间量的总和。有效的时间单位为“ns”、“µs”（或“us”）、“ms”、“s”、“m”和“h”。
例如：
5s表示五秒的持续时间，1m30s表示一分三十秒的持续时间。允许用户请求自动创建存储卷。
[+]动态制备消除了集群管理员预先制备存储的需要。取而代之的是，它根据用户请求自动制备存储。动态卷制备基于一个 API 对象，即StorageClass，它引用一个负责制备卷的Volume Plugin，并传递参数集合给该 Volume Plugin。
服务的端点是实现该服务的Pod 之一（或外部服务器）。
[+]对于带选择器的 Service，EndpointSlice 控制器将自动创建一个或多个EndpointSlice，其中包含所选端点 Pod 的 IP 地址。
也可以手动创建 EndpointSlice，以指示未指定选择器的服务的端点。
终结器是命名空间的键，告诉 Kubernetes 在完全删除标记为待删除的资源之前要等待特定条件满足。终结器会通知控制器清理被删除对象拥有的资源。
[+]当你告诉 Kubernetes 删除指定了终结器的对象时，Kubernetes API 会通过填充
.metadata.deletionTimestamp字段将该对象标记为待删除，并返回202状态码（HTTP “Accepted”）。在控制平面或其他组件执行终结器定义的操作时，目标对象将保持在终止状态。这些操作完成后，控制器会从目标对象中移除相关的终结器。当metadata.finalizers字段为空时，Kubernetes 认为删除完成并删除该对象。你可以使用终结器来控制资源的垃圾回收。例如，你可以定义一个终结器，在控制器删除目标资源之前清理相关的资源或基础设施。
FlexVolume 是用于创建树外卷插件的已弃用接口。容器存储接口 (CSI) 是一个较新的接口，解决了 FlexVolume 的几个问题。
[+]FlexVolume 使户能够编写自己的驱动程序并在 Kubernetes 中添加对其卷的支持。FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。这需要 root 权限。Storage SIG 建议如果可能的话实现一个CSI 驱动程序，因为它解决了 FlexVolume 的局限性。
用于在 Kubernetes 中建模服务网络的一系列 API 类型。
[+]Gateway API 提供了一系列可扩展的、面向角色的、感知协议的 API 类型，用于在 Kubernetes 中建模服务网络。
- 也被称为: GVR
表示唯一的 Kubernetes API 资源的方式。
[+]组版本资源 (GVR) 指定了与访问 Kubernetes 中特定 ID 对象相关的 API 组、API 版本和资源（即 URI 中对象类型名称）。GVR 使你能够定义和区分不同的 Kubernetes 对象，并指定一种访问对象的方式，这种方式即使在 API 变化时也能保持稳定。
一组预配置的 Kubernetes 资源包，可以使用 Helm 工具进行管理。
[+]Chart 提供了一种可复现的方式来创建和共享 Kubernetes 应用。单个 Chart 可以用于部署简单的东西，比如一个 memcached Pod，也可以用于部署复杂的东西，比如一个完整的 Web 应用栈，包括 HTTP 服务器、数据库、缓存等等。
- 也被称为: HPA
一个 API 资源，根据目标 CPU 利用率或自定义指标目标自动扩缩Pod 副本的数量。
[+]HPA 通常与 ReplicationControllers、Deployments 或 ReplicaSets 一起使用。它不能应用于无法扩缩的对象，例如 DaemonSets。
HostAliases 是要注入到 Pod 的 hosts 文件中的 IP 地址与主机名的映射。
[+]HostAliases 是一个可选的主机名和 IP 地址列表，如果指定，它们将被注入到 Pod 的 hosts 文件中。这仅对非 hostNetwork 的 Pod 有效。
不可变基础设施指一旦部署就无法更改的计算机基础设施（虚拟机、容器、网络设备）。
[+]可以通过覆盖未经授权更改的自动化流程或不允许更改的系统来强制执行不可变性。容器 是不可变基础设施的一个很好的例子，因为对容器的持久性更改只能通过创建新版本的容器或从其镜像重新创建现有容器来实现。
通过防止或识别未经授权的更改，不可变基础设施可以更容易地识别和缓解安全风险。操作这样的系统变得更加简单，因为管理员可以对其进行假设。毕竟，他们知道没有人犯错或进行忘记沟通的更改。不可变基础设施与基础设施即代码（其中创建基础设施所需的所有自动化都存储在版本控制中，例如 Git）相辅相成。这种不可变性和版本控制的结合意味着系统每一次授权更改都有持久的审计日志。
一个 API 对象，用于管理集群中服务的外部访问，通常是 HTTP 访问。
[+]Ingress 可以提供负载均衡、SSL 终止和基于名称的虚拟主机功能。
一个或多个初始化 容器，它们必须先运行完成，然后才能运行任何应用容器。
[+]初始化 (init) 容器与普通应用容器类似，但有一个区别：init 容器必须先运行完成，然后才能启动任何应用容器。Init 容器按顺序运行：每个 init 容器必须先运行完成，下一个 init 容器才能开始。
与 sidecar 容器 不同，init 容器在 Pod 启动后不会保持运行。
有关更多信息，请阅读 init 容器 文档。
一个开放平台（非 Kubernetes 特定），它提供一种统一的方式来集成微服务、管理流量流、实施策略和聚合遥测数据。
[+]添加 Istio 不需要更改应用代码。它是一个服务与网络之间的基础设施层，与服务部署结合使用时，通常称为服务网格。Istio 的控制平面抽象了底层集群管理平台，该平台可能是 Kubernetes、Mesosphere 等。
一种表示要在双方之间传输声明的方式。
[+]JWT 可以进行数字签名和加密。Kubernetes 使用 JWT 作为认证令牌来验证想要在集群中执行操作的实体的身份。
[+]kOps不仅能帮助你创建、销毁、升级和维护生产级别的、高可用的 Kubernetes 集群，还会预置所需的云基础设施。注意
目前官方支持 AWS (Amazon Web Services)，DigitalOcean、GCE 和 OpenStack 提供 beta 支持，Azure 提供 alpha 支持。kOps是一个自动化预置系统- 全自动化安装
- 使用 DNS 标识集群
- 自愈：所有内容都在自动扩缩组 (Auto-Scaling Groups) 中运行
- 支持多种操作系统（Amazon Linux, Debian, Flatcar, RHEL, Rocky 和 Ubuntu）
- 支持高可用性
- 可以直接预置或生成 Terraform 清单
kube-proxy 是一个网络代理，运行在你的集群中的每个 节点 上，实现了 Kubernetes Service 概念的一部分。
[+]kube-proxy 在节点上维护网络规则。这些网络规则允许集群内部或外部的网络会话与你的 Pod 进行网络通信。
如果操作系统有可用的数据包过滤层，kube-proxy 会使用它。否则，kube-proxy 会自行转发流量。
通过 RESTful 接口提供 Kubernetes 功能并存储集群状态的应用程序。
[+]Kubernetes 资源和“意图记录”都存储为 API 对象，并通过对 API 进行 RESTful 调用来修改。API 允许以声明性方式管理配置。用户可以直接与 Kubernetes API 交互，或通过
kubectl等工具交互。核心 Kubernetes API 是灵活的，也可以进行扩展以支持自定义资源。提供约束以限制命名空间中每个 Containers 或 Pods 的资源消耗。
[+]LimitRange 限制按类型创建的对象数量，以及命名空间中单个 Containers 或 Pods 可能请求/消耗的计算资源量。
由第三方提供商维护的软件服务。
[+]托管服务的一些示例包括 AWS EC2、Azure SQL Database 和 GCP Pub/Sub，但它们可以是应用可以使用的任何软件服务。
Kubernetes 社区中的持续活跃 贡献者。
[+]成员可以被分配 Issues 和 PR，并通过 GitHub 团队参与 特别兴趣小组 (SIG)。会自动为成员的 PR 运行预提交测试。成员应保持社区的活跃贡献者身份。
一个在本地运行 Kubernetes 的工具。
[+]Minikube 在你的计算机上的虚拟机内部运行一个一体化或多节点的本地 Kubernetes 集群。你可以使用 Minikube 在学习环境中尝试 Kubernetes。
- 亦称为：MVP
允许
[+]kube-apiserver将资源请求代理到不同对等 API 服务器的功能。当集群有多个运行不同版本 Kubernetes 的 API 服务器时，此功能使资源请求能够由正确的 API 服务器处理。
MVP 默认禁用，可以在 API Server 启动时通过启用名为
UnknownVersionInteroperabilityProxy的 功能门 来激活。 客户端提供的字符串，用于在资源 URL 中引用对象，例如
[+]/api/v1/pods/some-name。在同一时间，给定类型的对象只能有一个特定的名称。但是，如果你删除该对象，则可以创建一个具有相同名称的新对象。
一种规范，定义了 Pod 组之间以及与其它网络端点之间的允许通信方式。
[+]网络策略帮助你以声明性方式配置允许哪些 Pod 互相连接、哪些命名空间允许通信，以及更具体地在哪些端口号上强制执行每条策略。
NetworkPolicy资源使用标签来选择 Pod 并定义规则，这些规则指定允许哪些流量到达选定的 Pod。网络策略由网络提供商提供的受支持的网络插件来实现。请注意，创建网络资源而没有控制器来实现它将无效。Operator 模式 是一种系统设计，它将 控制器 与一个或多个自定义资源关联起来。
[+]你可以在 Kubernetes 自身内置的控制器之外，通过向集群添加控制器来扩展 Kubernetes。
如果一个运行中的应用充当控制器，并具有 API 访问权限来针对控制平面中定义的自定义资源执行任务，这就是 Operator 模式的一个例子。
声明 PersistentVolume 中定义的存储资源，以便可以将其作为卷挂载到 容器 中。
[+]指定存储容量、存储访问方式（只读、读写和/或独占）以及如何回收（保留、回收或删除）。存储本身的细节在 PersistentVolume 对象中描述。
根据项目需求定制 Kubernetes 平台的人员。
[+]例如，平台开发者可以使用自定义资源或通过聚合层扩展 Kubernetes API，为其特定的应用向其 Kubernetes 实例添加功能。一些平台开发者也是贡献者，他们开发扩展并贡献给 Kubernetes 社区。其他人开发闭源的商业或特定站点的扩展。
最小和最简单的 Kubernetes 对象。Pod 代表你的集群中运行的一组 容器。
[+]Pod 通常被设置为运行一个主容器。它也可以运行可选的 sidecar 容器，以添加日志等辅助功能。Pod 通常由 Deployment 管理。
- 也称为： pod template
一个 API 对象，定义了创建 Pod 的模板。PodTemplate API 也嵌入在工作负载管理的 API 定义中，例如 Deployment 或 StatefulSets。
[+] PriorityClass 是一个命名的类别，用于指定属于该类别的 Pod 的调度优先级。
[+]一个 PriorityClass 是一个非命名空间对象，将一个名称映射到一个整数优先级，用于 Pod。名称在
metadata.name字段中指定，优先级值在value字段中指定。优先级范围包括 -2147483648 到 1000000000。值越高表示优先级越高。在计算中，代理（Proxy）是作为远程服务中介的服务器。
[+]客户端与代理交互；代理将客户端的数据复制到实际服务器；实际服务器回复给代理；代理将实际服务器的回复发送给客户端。
kube-proxy 是一个在集群中每个节点上运行的网络代理，实现了 Kubernetes Service 概念的一部分。
你可以将 kube-proxy 作为普通的 userland 代理服务运行。如果你的操作系统支持，你可以改为在混合模式下运行 kube-proxy，使用更少的系统资源实现相同的总体效果。
QoS 类（服务质量类）为 Kubernetes 提供了一种将集群中的 Pod 分类为几个类别的途径，并据此做出调度和驱逐的决策。
[+]Pod 的 QoS 类在其创建时根据其计算资源请求和限制设置确定。QoS 类用于对 Pod 的调度和驱逐做出决策。Kubernetes 可以为 Pod 分配以下 QoS 类之一：
Guaranteed（保证型）、Burstable（突发型）或BestEffort（尽力而为型）。使用 SI 后缀表示小或大数字的整数形式。
[+]Quantity 是使用紧凑的整数表示法和 SI 后缀来表示小或大数字。小数可以使用毫单位表示，而大数字可以使用千、兆或吉单位表示。
例如，数字
1.5表示为1500m，数字1000可以表示为1k，而1000000可以表示为1M。你还可以指定 二进制表示法 后缀；数字 2048 可以写成2Ki。可接受的十进制（10 的幂）单位包括
m(毫),k(千, 特意使用小写),M(兆),G(吉),T(太),P(拍),E(艾)。可接受的二进制（2 的幂）单位包括
Ki(kibi),Mi(mebi),Gi(gibi),Ti(tebi),Pi(pebi),Ei(exbi)。管理授权决策，允许管理员通过 Kubernetes API 动态配置访问策略。
[+]RBAC 使用四种 Kubernetes 对象：
- Role
- 在特定命名空间中定义权限规则。
- ClusterRole
- 在集群范围内定义权限规则。
- 角色绑定
- 将角色中定义的权限授予特定命名空间中的一组用户。
- ClusterRoleBinding
- 将角色中定义的权限授予集群范围内的一组用户。
更多信息，请参阅 RBAC。
ReplicaSet (旨在) 确保在任何时候都有指定数量的副本 Pod 正在运行。
[+]诸如 Deployment 之类的工作负载对象利用 ReplicaSet 来确保根据该 ReplicaSet 的规约，有指定数量的 Pod 在你的集群中运行。
一种工作负载资源，用于管理副本化应用程序，确保指定数量的 Pod 实例正在运行。
[+]控制平面确保定义的 Pod 数量正在运行，即使某些 Pod 失败、你手动删除了 Pod 或错误地启动了过多的 Pod。
注意
ReplicationController 已弃用。请参阅类似的 Deployment。负责评审项目代码质量和正确性的人员。
[+]评审者既了解代码库，也熟悉软件工程原理。评审者身份通常限定在代码库的特定部分。
存储敏感信息，例如密码、OAuth 令牌和 SSH 密钥。
[+]Secret 让你能够更好地控制敏感信息的使用方式，并降低意外暴露的风险。Secret 值默认以 base64 字符串编码并以未加密方式存储，但可以配置为静态加密。
一个 Pod 可以通过多种方式引用 Secret，例如在卷挂载中或作为环境变量。Secret 专为机密数据设计，ConfigMaps 专为非机密数据设计。
一种将请求分配到队列的技术，与对队列数量进行哈希取模相比，它提供了更好的隔离性。
[+]我们通常关注如何将不同的请求流隔离开来，以便高强度流不会挤占低强度流。将请求放入队列的一种简单方法是对请求的一些特征进行哈希，然后对队列数量取模，以获得要使用的队列索引。哈希函数使用与流相关的请求特征作为输入。例如，在互联网中，这通常是源地址和目标地址、协议以及源端口和目标端口的五元组。
这种简单的基于哈希的方案有一个特性：任何高强度流都会挤占所有哈希到同一队列的低强度流。为大量流提供良好的隔离需要大量的队列，这带来了问题。Shuffle-sharding 是一种更灵活的技术，可以更好地隔离低强度流免受高强度流的影响。Shuffle-sharding 的术语使用了发牌的比喻；每个队列都是一张象征性的牌。Shuffle-sharding 技术首先对识别流的请求特征进行哈希，生成一个具有数十位或更多位的哈希值。然后，将该哈希值用作熵源，以“洗牌”并“发一手牌”（队列）。检查所有发出的队列，并将请求放入其中最短的队列。在手牌大小适中的情况下，检查所有发出的牌的成本不高，并且给定的低强度流很有可能避开给定的高强度流的影响。手牌大小较大时，检查发出的队列成本较高，低强度流更难以避开一组高强度流的集体影响。因此，应慎重选择手牌大小。
一个或多个通常在任何应用容器运行之前启动的容器。
[+]Sidecar 容器就像普通的应用容器一样，但有不同的目的：sidecar 为主应用容器提供 Pod 本地服务。与 init 容器 不同，sidecar 容器在 Pod 启动后继续运行。
阅读 Sidecar 容器 获取更多信息。
集体管理大型 Kubernetes 开源项目某个持续活跃部分或方面的社区成员。
[+]SIG 中的成员对推进特定领域有共同兴趣，例如架构、API 机制或文档。SIG 必须遵守 SIG 治理准则，但可以有自己的贡献策略和沟通渠道。
更多信息，请参阅 kubernetes/community 仓库和当前 SIG 和工作组列表。
定义每个对象（如 Pods 或 Services）应如何配置及其期望状态。
[+]几乎每个 Kubernetes 对象都包含两个嵌套的对象字段来管理对象的配置：对象 spec 和对象 status。对于有 spec 的对象，你在创建对象时必须设置它，提供你希望资源具有的特性描述：其期望状态。
不同对象（如 Pods、StatefulSets 和 Services）的 spec 各有不同，详细描述了容器、卷、副本、端口等设置，
以及每个对象类型特有的其他规约。此字段封装了 Kubernetes 应为定义的
对象维护的状态。管理一组 Pod 的部署和扩缩，并保证这些 Pod 的顺序和唯一性。
[+]与 Deployment 一样，StatefulSet 管理基于相同容器规约的 Pod。与 Deployment 不同，StatefulSet 为其每个 Pod 维护一个固定的身份。这些 Pod 由相同的规约创建，但它们不可互换：每个 Pod 都有一个持久的标识符，该标识符在任何重新调度中都会保留。
如果你想使用存储卷为你的工作负载提供持久性，可以将 StatefulSet 作为解决方案的一部分。虽然 StatefulSet 中的单个 Pod 可能发生故障，但持久的 Pod 标识符使得更容易将现有卷与替换任何已失败 Pod 的新 Pod 匹配。
StorageClass 为管理员提供了一种描述不同可用存储类型的方式。
[+]StorageClass 可以映射到服务质量级别、备份策略或集群管理员确定的任意策略。每个 StorageClass 包含字段
provisioner、parameters和reclaimPolicy，这些字段在需要动态配置属于该类的 Persistent Volume 时使用。用户可以使用 StorageClass 对象的名称请求特定类。一个核心对象，由三个必需属性组成：key、value 和 effect。Taint 阻止将 Pod 调度到 节点 或节点组上。
[+]Taint 和 toleration 协同工作，以确保 Pod 不会调度到不合适的节点上。一个或多个 Taint 应用于节点。节点只应调度对配置的 Taint 具有匹配 toleration 的 Pod。
Kubernetes 系统生成的用于唯一标识对象的字符串。
[+]在 Kubernetes 集群的整个生命周期中创建的每个对象都具有唯一的 UID。它旨在区分相似实体的历史出现。
一个动词，用于以流的方式跟踪 Kubernetes 中对象的变化。它用于高效地检测变化。
[+]Watch 是一种动词，用于以流的方式跟踪 Kubernetes 中对象的变更。Watch 允许高效地检测变更；例如，需要知道 ConfigMap 何时更改的控制器可以使用 watch 而不是轮询。
更多信息，请参阅API Concepts 中的高效变更检测。
协助委员会、SIG或跨 SIG 合作开展短期、范围狭窄或独立的项目讨论和/或实施。
[+]工作组是一种组织人们完成特定任务的方式。
更多信息，请参阅 kubernetes/community 仓库和当前SIG 和工作组列表。
工作负载是在 Kubernetes 上运行的应用程序。
[+]代表不同类型或部分工作负载的各种核心对象包括 DaemonSet、Deployment、Job、ReplicaSet 和 StatefulSet 对象。
例如，一个包含 Web 服务器和数据库的工作负载，可能会将数据库运行在StatefulSet中，而将 Web 服务器运行在Deployment中。
反馈
此页面有帮助吗？
感谢您的反馈。如果您有关于如何使用 Kubernetes 的具体、可回答的问题，请在Stack Overflow上提问。如果您想报告问题或提出改进建议，请在GitHub 仓库中创建一个 Issue。