词汇表
This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to Kubernetes, as well as more general terms that provide useful context.
Filter terms according to their tags
Click on the [+] indicators below to get a longer explanation for any particular term.
-
CustomResourceDefinition
通过定制化的代码给您的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。
[+]当 Kubernetes 公开支持的 API 资源不能满足您的需要时，定制资源对象（Custom Resource Definitions）让您可以在您的环境上扩展 Kubernetes API。
-
Dockershim
The dockershim is a component of Kubernetes version 1.23 and earlier. It allows the kubelet to communicate with Docker Engine.
[+]Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see Dockershim FAQ.
-
Finalizer
Finalizer 是带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。
[+]当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时， Kubernetes API 通过填充
.metadata.deletionTimestamp来标记要删除的对象， 并返回202状态码 (HTTP "已接受") 使其进入只读状态。 此时控制平面或其他组件会采取 Finalizer 所定义的行动， 而目标对象仍然处于终止中（Terminating）的状态。 这些行动完成后，控制器会删除目标对象相关的 Finalizer。 当metadata.finalizers字段为空时，Kubernetes 认为删除已完成。你可以使用 Finalizer 控制资源的垃圾收集。 例如，你可以定义一个 Finalizer，在删除目标资源前清理相关资源或基础设施。
-
kube-apiserver
API 服务器是 Kubernetes 控制面的组件， 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。
[+]Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
-
kube-proxy
kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
[+]kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。
-
Kubelet
一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。
[+]kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
-
Kubernetes API
Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。
[+]Kubernetes 资源和"意向记录"都是作为 API 对象储存的，并可以通过调用 RESTful 风格的 API 进行修改。 API 允许以声明方式管理配置。 用户可以直接和 Kubernetes API 交互，也可以通过
kubectl这样的工具进行交互。 核心的 Kubernetes API 是很灵活的，可以扩展以支持定制资源。 -
LimitRange
提供约束来限制命名空间中每个 容器（Containers） 或 Pod 的资源消耗。
[+]LimitRange 按照类型来限制命名空间中对象能够创建的数量，以及单个 容器（Containers） 或 Pod 可以请求/使用的计算资源量。
-
Minikube
Minikube 是用来在本地运行 Kubernetes 的一种工具。
[+]Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube 在学习环境中尝试 Kubernetes.
-
Pod
Pod 是 Kubernetes 的原子对象。Pod 表示您的集群上一组正在运行的容器（containers）。
[+]通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的边车（sidecar）容器，以添加诸如日志记录之类的补充特性。通常用 Deployment 来管理 Pod。
-
QoS 类（QoS Class）
QoS Class（Quality of Service Class）为 Kubernetes 提供了一种将集群中的 Pod 分为几个类型并做出有关调度和驱逐决策的方法。
[+]Pod 的 QoS 类是基于 Pod 在创建时配置的计算资源请求和限制。QoS 类用于制定有关 Pod 调度和逐出的决策。 Kubernetes 可以为 Pod 分配以下 QoS 类：
Guaranteed，Burstable或者BestEffort。 -
ReplicaSet
ReplicaSet 是下一代副本控制器。
[+]ReplicaSet 就像 ReplicationController 那样，确保一次运行指定数量的 Pod 副本。ReplicaSet 支持新的基于集合的选择器需求（在标签的用户指南中有相关描述），而副本控制器只支持基于等值的选择器需求。
-
StatefulSet
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。
[+]和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
-
临时容器（Ephemeral Container）
您可以在 Pod 中临时运行的一种 容器（Container） 类型。
[+]如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器并进行诊断。 临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。
-
卷（Volume）A directory containing data, accessible to the containers in a pod. aka: tags: - core-object - fundamental --- -- containers in a Pod. -- 包含可被 Pod 中容器访问的数据的目录。 每个 Kubernetes 卷在所处的 Pod 存在期间保持存在状态。 因此，卷的生命期会超出 Pod 中运行的容器， 并且保证容器重启之后仍保留数据。 更多信息可参考storage [+]
-
名称（Name）
客户端提供的字符串，引用资源 url 中的对象，如
[+]/api/v1/pods/some name。某一时刻，只能有一个给定类型的对象具有给定的名称。但是，如果删除该对象，则可以创建同名的新对象。
-
基于角色的访问控制（RBAC）
管理授权决策，允许管理员通过 Kubernetes API 动态配置访问策略。
[+]RBAC 使用 角色 (包含权限规则)和 角色绑定 (将角色中定义的权限授予一组用户)。
-
容器运行时（Container Runtime）
容器运行环境是负责运行容器的软件。
[+]Kubernetes 支持容器运行时，例如 Docker、 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
-
容器（Container）
容器是可移植、可执行的轻量级的镜像，包含其中的软件及其相关依赖。
[+]容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。
-
对象（Object）
Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。
[+]Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes 控制平面（Control Plane） 不断工作，以确保它代表的项目确实存在。 创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。
-
工作负载（Workload）
工作负载是在 Kubernetes 上运行的应用程序。
[+]代表不同类型或部分工作负载的各种核心对象包括 DaemonSet， Deployment， Job， ReplicaSet， and StatefulSet。
例如，具有 Web 服务器和数据库的工作负载可能在一个 StatefulSet 中运行数据库， 而 Web 服务器运行在 Deployment。
-
干扰（Disruption）
干扰是指导致一个或者多个 Pod 服务停止的事件。 干扰会影响工作负载资源，比如 Deployment 这种依赖于受影响 Pod 的资源。
[+]如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 自愿干扰（Voluntary Disruption）。如果由于节点故障 或者影响更大区域故障的断电导致 Pod 离线，kubernetes 视之为 非愿干扰（Involuntary Disruption）。
更多信息请查阅Disruptions
-
应用（Applications）The layer where various containerized applications run. aka: tags: - fundamental --- -- 各种容器化应用运行所在的层。 [+]
各种容器化应用运行所在的层。
-
控制器（Controller）
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。
[+]控制器（控制平面的一部分） 通过 apiserver 监控你的集群中的公共状态。
其中一些控制器是运行在控制平面内部的，对 Kubernetes 来说，他们提供核心控制操作。 比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、 命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume controller）（等）都是运行在 kube-controller-manager 中的。
-
控制组（cgroup）
一组具有可选资源隔离、审计和限制的 Linux 进程。
[+]Cgroup 是一个 Linux 内核特性，对一组进程的资源使用（CPU、内存、磁盘 I/O 和网络等）进行限制、审计和隔离。
-
混排切片（Shuffle Sharding）
混排切片（Shuffle Sharding）是指一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。
[+]我们通常会关心不同的请求序列间的相互隔离问题，目的是为了确保密度较高的 请求序列不会湮没密度较低的序列。 将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数， 将结果对队列的个数取模，从而得到要使用的队列的索引。 这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如，在因特网上， 这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的 五元组。
这种简单的基于哈希的模式有一种特性，高密度的请求序列（流）会湮没那些被 哈希到同一队列的其他低密度请求序列（流）。 为大量的序列提供较好的隔离性需要提供大量的队列，因此是有问题的。 混排切片是一种更为灵活的机制，能够更好地将低密度序列与高密度序列隔离。 混排切片的术语采用了对一叠扑克牌进行洗牌的类比，每个队列可类比成一张牌。 混排切片技术首先对请求的特定于所在序列的特征执行哈希计算，生成一个长度 为十几个二进制位或更长的哈希值。 接下来，用该哈希值作为信息熵的来源，对一叠牌来混排，并对整个一手牌（队列）来洗牌。 最后，对所有处理过的队列进行检查，选择长度最短的已检查队列作为请求的目标队列。 在队列数量适中的时候，检查所有已处理的牌的计算量并不大，对于任一给定的 低密度的请求序列而言，有相当的概率能够消除给定高密度序列的湮没效应。 当队列数量较大时，检查所有已处理队列的操作会比较耗时，低密度请求序列 消除一组高密度请求序列的湮没效应的机会也随之降低。因此，选择队列数目 时要颇为谨慎。
-
清单（Manifest）
JSON 或 YAML 格式的 Kubernetes API 对象规范。
[+]清单指定了在应用该清单时 kubernetes 将维护的对象的期望状态。每个配置文件可包含多个清单。
-
集群（Cluster）
集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。
[+]工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。