- 文档
- Kubernetes 博客
- 培训
- 合作伙伴
- 社区
- 案例分析
- 版本列表
- 发布信息
- v1.32
- v1.31
- v1.30
- v1.29
- v1.28
- 中文 (Chinese)
- English
- বাংলা (Bengali)
- Français (French)
- Deutsch (German)
- हिन्दी (Hindi)
- Bahasa Indonesia (Indonesian)
- Italiano (Italian)
- 日本語 (Japanese)
- 한국어 (Korean)
- Polski (Polish)
- Português (Portuguese)
- Русский (Russian)
- Español (Spanish)
- Українська (Ukrainian)
- Tiếng Việt (Vietnamese)
你正在查看的文档所针对的是 Kubernetes 版本: v1.30
Kubernetes v1.30 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。
词汇表
此术语表旨在提供 Kubernetes 术语的完整、标准列表。其中包含特定于 Kubernetes 的技术术语以及能够构造有用的语境的一般性术语。
点击 [+] 下面的指示符号获取特定术语的更为完整的描述。
-
API 服务器亦称作: kube-apiserver
API 服务器是 Kubernetes 控制平面的组件, 该组件负责公开了 Kubernetes API,负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
[+]Kubernetes API 服务器的主要实现是 kube-apiserver。
kube-apiserver
设计上考虑了水平扩缩,也就是说,它可通过部署多个实例来进行扩缩。 你可以运行kube-apiserver
的多个实例,并在这些实例之间平衡流量。 -
CustomResourceDefinition
通过定制化的代码给你的 Kubernetes API 服务器增加资源对象,而无需编译完整的定制 API 服务器。
[+]当 Kubernetes 公开支持的 API 资源不能满足你的需要时, 定制资源对象(Custom Resource Definitions)让你可以在你的环境上扩展 Kubernetes API。
-
Deployment
管理多副本应用的一种 API 对象,通常通过运行没有本地状态的 Pod 来完成工作。
[+]每个副本表现为一个 Pod, Pod 分布在集群中的节点上。 对于确实需要本地状态的工作负载,请考虑使用 StatefulSet。
-
Dockershim
dockershim 是 Kubernetes v1.23 及之前版本中的一个组件。 这个组件使得 kubelet 能够与 Docker Engine 通信。
[+]从 Kubernetes v1.24 开始,dockershim 已从 Kubernetes 中移除。 想了解更多信息,可参考移除 Dockershim 的常见问题。
-
Finalizer
Finalizer 是带有命名空间的键,告诉 Kubernetes 等到特定的条件被满足后, 再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。
[+]当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时, Kubernetes API 通过填充
.metadata.deletionTimestamp
来标记要删除的对象, 并返回202
状态码(HTTP "已接受") 使其进入只读状态。 此时控制平面或其他组件会采取 Finalizer 所定义的行动, 而目标对象仍然处于终止中(Terminating)的状态。 这些行动完成后,控制器会删除目标对象相关的 Finalizer。 当metadata.finalizers
字段为空时,Kubernetes 认为删除已完成并删除对象。你可以使用 Finalizer 控制资源的垃圾收集。 例如,你可以定义一个 Finalizer,在删除目标资源前清理相关资源或基础设施。
-
kube-controller-manager
kube-controller-manager 是控制平面的组件, 负责运行控制器进程。
[+]从逻辑上讲, 每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在同一个进程中运行。
-
kube-proxy
kube-proxy 是集群中每个节点(node)上所运行的网络代理, 实现 Kubernetes 服务(Service) 概念的一部分。
[+]kube-proxy 维护节点上的一些网络规则, 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层,则 kube-proxy 会通过它来实现网络规则。 否则,kube-proxy 仅做流量转发。
-
Kubelet
[+]kubelet
会在集群中每个节点(node)上运行。 它保证容器(containers)都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpec,确保这些 PodSpec 中描述的容器处于运行状态且健康。 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 表示你的集群上一组正在运行的容器(Container)。
[+]通常创建 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 支持新的基于集合的选择器需求(在标签的用户指南中有相关描述),而副本控制器只支持基于等值的选择器需求。
-
Spec
定义 Pod 或 Service 这类每种对象应被如何配置及其预期状态。
[+]几乎每个 Kubernetes 对象都包含两个嵌套的对象字段,用于治理对象本身的配置: 对象规约(spec)和对象状态(status)。 对于具有规约的对象,你必须在创建对象时设置规约,并提供资源所需特征的描述:即其预期状态。
此字段对于 Pod、StatefulSet 和 Service 等不同对象会有所差异, 字段详细说明如容器、卷、副本、端口等设置以及每种对象特有的其他规约。 此字段封装了 Kubernetes 针对所定义的对象应保持何种状态。
-
StatefulSet
StatefulSet 用来管理某 Pod 集合的部署和扩缩, 并为这些 Pod 提供持久存储和持久标识符。
[+]和 Deployment 类似, StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是, StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的, 但是不能相互替换:无论怎么调度,每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储,可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障, 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
-
对象(Object)
Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。
[+]Kubernetes 对象通常是一个“意向表述(Record of Intent)”—一旦你创建了一个对象,Kubernetes 控制平面(Control Plane) 就不断工作, 以确保它所代表的事物确实存在。 创建一个对象相当于告知 Kubernetes 系统:你期望这部分集群负载看起来像什么;这也就是你集群的期望状态。
-
干扰(Disruption)
干扰(Disruption)是指导致一个或者多个 Pod 服务停止的事件。 干扰会影响依赖于受影响的 Pod 的资源,例如 Deployment。
[+]如果你作为一个集群操作人员,销毁了一个从属于某个应用的 Pod, Kubernetes 视之为自愿干扰(Voluntary Disruption)。 如果由于节点故障或者影响更大区域故障的断电导致 Pod 离线, Kubernetes 视之为非愿干扰(Involuntary Disruption)。
更多信息请查阅干扰。
-
工作负载(Workload)
工作负载是在 Kubernetes 上运行的应用程序。
[+]代表不同类型或部分工作负载的各种核心对象包括 DaemonSet、Deployment、Job、ReplicaSet 和 StatefulSet。
例如,具有 Web 服务器和数据库的工作负载可能在一个 StatefulSet 中运行数据库, 而 Web 服务器运行在 Deployment。
-
混排切片(Shuffle Sharding)
混排切片(Shuffle Sharding)是指一种将请求指派给队列的技术,其隔离性好过对队列个数哈希取模的方式。
[+]我们通常会关心不同的请求序列间的相互隔离问题,目的是为了确保密度较高的 请求序列不会湮没密度较低的序列。 将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数, 将结果对队列的个数取模,从而得到要使用的队列的索引。 这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如,在因特网上, 这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的 五元组。
这种简单的基于哈希的模式有一种特性,高密度的请求序列(流)会湮没那些被 哈希到同一队列的其他低密度请求序列(流)。 为大量的序列提供较好的隔离性需要提供大量的队列,因此是有问题的。 混排切片是一种更为灵活的机制,能够更好地将低密度序列与高密度序列隔离。 混排切片的术语采用了对一叠扑克牌进行洗牌的类比,每个队列可类比成一张牌。 混排切片技术首先对请求的特定于所在序列的特征执行哈希计算,生成一个长度 为十几个二进制位或更长的哈希值。 接下来,用该哈希值作为信息熵的来源,对一叠牌来混排,并对整个一手牌(队列)来洗牌。 最后,对所有处理过的队列进行检查,选择长度最短的已检查队列作为请求的目标队列。 在队列数量适中的时候,检查所有已处理的牌的计算量并不大,对于任一给定的 低密度的请求序列而言,有相当的概率能够消除给定高密度序列的湮没效应。 当队列数量较大时,检查所有已处理队列的操作会比较耗时,低密度请求序列 消除一组高密度请求序列的湮没效应的机会也随之降低。因此,选择队列数目 时要颇为谨慎。
-
基于角色的访问控制(RBAC)
管理授权决策,允许管理员通过 Kubernetes API 动态配置访问策略。
[+]RBAC 使用 角色 (包含权限规则)和 角色绑定 (将角色中定义的权限授予一组用户)。
-
控制器(Controller)
在 Kubernetes 中,控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。
[+]控制器(控制平面的一部分) 通过 API 服务器监控你的集群中的公共状态。
其中一些控制器是运行在控制平面内部的,对 Kubernetes 来说,他们提供核心控制操作。 比如:部署控制器(deployment controller)、守护控制器(daemonset controller)、 命名空间控制器(namespace controller)、持久化数据卷控制器(persistent volume controller)(等) 都是运行在 kube-controller-manager 中的。
-
控制组(cgroup;control group)
一组具有可选资源隔离、审计和限制的 Linux 进程。
[+]cgroup 是一个 Linux 内核特性,对一组进程的资源使用(CPU、内存、磁盘 I/O 和网络等)进行限制、审计和隔离。
-
临时容器(Ephemeral Container)
你可以在 Pod 中临时运行的一种 容器(Container) 类型。
[+]如果想要调查运行中有问题的 Pod,可以向该 Pod 添加一个临时容器(Ephemeral Container)并进行诊断。 临时容器没有资源或调度保证,因此不应该使用它们来运行工作负载本身的任何部分。
静态 Pod 不支持临时容器。
-
名称(Name)
客户端提供的字符串,引用资源 URL 中的对象,如
[+]/api/v1/pods/some name
。某一时刻,只能有一个给定类型的对象具有给定的名称。但是,如果删除该对象,则可以创建同名的新对象。
-
清单(Manifest)
JSON 或 YAML 格式的 Kubernetes API 对象规范。
[+]清单指定了在应用该清单时 kubernetes 将维护的对象的期望状态。每个配置文件可包含多个清单。
-
容器(Container)
容器是可移植、可执行的轻量级的镜像,包含其中的软件及其相关依赖。
[+]容器使应用和底层的主机基础设施解耦,降低了应用在不同云环境或者操作系统上的部署难度,便于应用扩展。 在容器内运行的应用称为容器化应用。将这些应用及其依赖项捆绑到容器镜像中的过程称为容器化。
-
容器运行时(Container Runtime)
这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。
[+]Kubernetes 支持许多容器运行环境,例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
-
容器运行时接口(Container Runtime Interface;CRI)
容器运行时接口(Container Runtime Interface;CRI)是一组让容器运行时与节点上 kubelet 集成的 API。
[+]更多信息,请参考容器运行时接口(CRI) API 与规范。
最后修改 May 13, 2024 at 9:52 AM PST: [zh] Sync 4 files in reference/glossary (dcaafc7335)