词汇表
此术语表旨在提供 Kubernetes 术语的完整、标准列表。其中包含特定于 Kubernetes 的技术术语以及能够构造有用的语境的一般性术语。
根据标签过滤术语
点击 [+] 下面的指示符号获取特定术语的更为完整的描述。
API 发起的驱逐是一个先调用 Eviction API 创建
[+]Eviction
对象,再由该对象体面地中止 Pod 的过程。你可以通过 kube-apiserver 的客户端,比如
kubectl drain
这样的命令,直接调用 Eviction API 发起驱逐。 当Eviction
对象创建出来之后,该对象将驱动 API 服务器终止选定的 Pod。API 发起的驱逐取决于你配置的
PodDisruptionBudgets
和terminationGracePeriodSeconds
。API 发起的驱逐不同于节点压力引发的驱逐。
- 有关详细信息,请参阅 API 发起的驱逐。
- 亦称作: kube-apiserver
API 服务器是 Kubernetes 控制平面的组件, 该组件负责公开了 Kubernetes API,负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
[+]Kubernetes API 服务器的主要实现是 kube-apiserver。
kube-apiserver
设计上考虑了水平扩缩,也就是说,它可通过部署多个实例来进行扩缩。 你可以运行kube-apiserver
的多个实例,并在这些实例之间平衡流量。 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象,而无需编译完整的定制 API 服务器。
[+]当 Kubernetes 公开支持的 API 资源不能满足你的需要时, 定制资源对象(Custom Resource Definitions)让你可以在你的环境上扩展 Kubernetes API。
管理多副本应用的一种 API 对象,通常通过运行没有本地状态的 Pod 来完成工作。
[+]每个副本表现为一个 Pod, Pod 分布在集群中的节点上。 对于确实需要本地状态的工作负载,请考虑使用 StatefulSet。
dockershim 是 Kubernetes v1.23 及之前版本中的一个组件。 这个组件使得 kubelet 能够与 Docker Engine 通信。
[+]从 Kubernetes v1.24 开始,dockershim 已从 Kubernetes 中移除。 想了解更多信息,可参考移除 Dockershim 的常见问题。
Kubernetes 将 Pod 和容器字段值暴露给容器中运行的代码的机制。
[+]在不需要修改容器代码的前提下让容器拥有关于自身的信息是很有用的。修改代码可能使容器直接耦合到 Kubernetes。
Kubernetes Downward API 允许容器使用它们自己或它们在 Kubernetes 集群中所处环境的信息。 容器中的应用程序可以访问该信息,而不需要以 Kubernetes API 客户端的形式执行操作。
有两种方法可以将 Pod 和容器字段暴露给正在运行的容器:
- 使用环境变量
- 使用
downwardAPI
卷
这两种暴露 Pod 和容器字段的方式统称为 Downward API。
表示时间量的字符串值。
[+](Kubernetes 中)持续时间的格式基于 Go 编程语言中的
time.Duration
类型。在使用持续时间的 Kubernetes API 中,该值表示为一系列非负整数与时间单位后缀的组合。 你可以设置多个时间量,并且持续时间是这些时间量的总和。 有效的时间单位为 "ns"、"µs"(或 "us")、"ms"、"s"、"m" 和 "h"。
例如:
5s
代表时长为五秒,1m30s
代表时长为一分三十秒。一种将网络端点与 Kubernetes 资源组合在一起的方法。
[+]一种将网络端点组合在一起的可扩缩、可扩展方式。 它们将被 kube-proxy 用于在 每个 节点 上建立网络路由。
Finalizer 是带有命名空间的键,告诉 Kubernetes 等到特定的条件被满足后, 再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。
[+]当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时, Kubernetes API 通过填充
.metadata.deletionTimestamp
来标记要删除的对象, 并返回202
状态码(HTTP "已接受") 使其进入只读状态。 此时控制平面或其他组件会采取 Finalizer 所定义的行动, 而目标对象仍然处于终止中(Terminating)的状态。 这些行动完成后,控制器会删除目标对象相关的 Finalizer。 当metadata.finalizers
字段为空时,Kubernetes 认为删除已完成并删除对象。你可以使用 Finalizer 控制资源的垃圾收集。 例如,你可以定义一个 Finalizer,在删除目标资源前清理相关资源或基础设施。
FlexVolume 是一个已弃用的接口,用于创建树外卷插件。 容器存储接口(CSI) 是一个更新的接口,它解决了 FlexVolume 的一些问题。
[+]FlexVolume 允许用户编写自己的驱动程序,并在 Kubernetes 中加入对用户自己的数据卷的支持。 FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 这需要 root 权限。如果可能的话,SIG Storage 建议实现 CSI 驱动程序, 因为它解决了 FlexVolume 的限制。
在 Kubernetes 中服务网络建模所用的一系列 API 类别。
[+]Gateway API 为在 Kubernetes 中服务网络建模提供了一系列可扩展、面向角色、协议感知的 API 类别。
Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包,可以使用 Helm 工具对其进行管理。
[+]Chart 提供了一种可重现的用来创建和共享 Kubernetes 应用的方法。 单个 Chart 可用来部署简单的系统(例如:memcached Pod), 也可以用来部署复杂的系统(例如:HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈)。
主机别名 (HostAliases) 是一组 IP 地址和主机名的映射,用于注入到 Pod 内的 hosts 文件。
[+]HostAliases 是一个包含主机名和 IP 地址的可选列表,配置后将被注入到 Pod 内的 hosts 文件中。 该选项仅适用于没有配置 hostNetwork 的 Pod。
Ingress 是对集群中服务的外部访问进行管理的 API 对象,典型的访问方式是 HTTP。
[+]Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。
Istio 是一个(非 Kubernetes 特有的)开放平台,提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。
[+]添加 Istio 时不需要修改应用代码。它是基础设施的一层,介于服务和网络之间。 当它和服务的 Deployment 相结合时,就构成了通常所谓的服务网格(Service Mesh)。 Istio 的控制面抽象掉了底层的集群管理平台,这一集群管理平台可以是 Kubernetes、Mesosphere 等。
JWT 是用来表示在两方之间所转移的权限声明的一种方式。
[+]JWT 可以用数字方式签名和加密。 Kubernetes 将 JWT 用作身份验证令牌,以验证想要在集群中执行一些操作的实体的身份。
[+]kOps
不仅会帮助你创建、销毁、升级和维护生产级、高可用性的 Kubernetes 集群, 还会提供必要的云基础设施。说明:
目前正式支持 AWS(Amazon Web Services),DigitalOcean、GCE 和 OpenStack 处于 beta 支持阶段,Azure 处于 alpha 阶段。
kOps
是一个自动化的制备系统:- 全自动安装流程
- 使用 DNS 识别集群
- 自我修复:一切都在自动扩缩组中运行
- 支持多种操作系统(Amazon Linux、Debian、Flatcar、RHEL、Rocky 和 Ubuntu)
- 支持高可用
- 可以直接提供或者生成 terraform 清单
kube-controller-manager 是控制平面的组件, 负责运行控制器进程。
[+]从逻辑上讲, 每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在同一个进程中运行。
kube-proxy 是集群中每个节点(node)上所运行的网络代理, 实现 Kubernetes 服务(Service) 概念的一部分。
[+]kube-proxy 维护节点上的一些网络规则, 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层,则 kube-proxy 会通过它来实现网络规则。 否则,kube-proxy 仅做流量转发。
[+]kubelet
会在集群中每个节点(node)上运行。 它保证容器(containers)都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpec,确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。
[+]Kubernetes 资源和"意向记录"都是作为 API 对象储存的,并可以通过调用 RESTful 风格的 API 进行修改。 API 允许以声明方式管理配置。 用户可以直接和 Kubernetes API 交互,也可以通过
kubectl
这样的工具进行交互。 核心的 Kubernetes API 是很灵活的,可以扩展以支持定制资源。提供约束来限制命名空间中每个 容器(Containers) 或 Pod 的资源消耗。
[+]LimitRange 按照类型来限制命名空间中对象能够创建的数量,以及单个 容器(Containers) 或 Pod 可以请求/使用的计算资源量。
Minikube 是用来在本地运行 Kubernetes 的一种工具。
[+]Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube 在学习环境中尝试 Kubernetes。
operator 模式 是一种系统设计, 将 控制器(Controller) 关联到一个或多个自定义资源。
[+]除了使用作为 Kubernetes 自身一部分的内置控制器之外,你还可以通过 将控制器添加到集群中来扩展 Kubernetes。
如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控 那些在控制平面中定义的自定义资源,这就是一个 operator 模式的示例。
Pod 是 Kubernetes 的原子对象。 Pod 表示你的集群上一组正在运行的容器(Container)。
[+]通常创建 Pod 是为了运行单个主容器。 Pod 还可以运行可选的边车(sidecar)容器,以添加诸如日志记录之类的补充特性。 通常用 Deployment 来管理 Pod。
- 亦称作: PDB
Pod 干扰预算(Pod Disruption Budget,PDB) 使应用所有者能够为多实例应用创建一个对象,来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。
[+]PDB 无法防止非主动的中断,但是会计入预算(budget)。
- 亦称作: HPA
Pod 水平自动扩缩器(Horizontal Pod Autoscaler)是一种 API 资源,它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。
[+]HPA 通常用于 ReplicationController 、Deployment 或者 ReplicaSet 上。 HPA 不能用于不支持扩缩的对象,例如 DaemonSets。
- 亦称作: pod template
An API object that defines a template for creating Pods. The PodTemplate API is also embedded in API definitions for workload management, such as Deployment or StatefulSets.
[+]Pod templates allow you to define common metadata (such as labels, or a template for the name of a new Pod) as well as to specify a pod's desired state. Workload management controllers use Pod templates (embedded into another object, such as a Deployment or StatefulSet) to define and manage one or more Pods. When there can be multiple Pods based on the same template, these are called replicas. Although you can create a PodTemplate object directly, you rarely need to do so.
PriorityClass 是针对应分配给此类别 Pod 的调度优先级而命名的一种类别。
[+]PriorityClass 是用于 Pod 的一个非命名空间对象,负责将某个名称映射到一个整数优先级。 此名称在
metadata.name
字段中指定,优先级值在value
字段中指定。 优先级范围从 -2147483648 到 1000000000(包含边界值)。 值越大,优先级越高。QoS Class(Quality of Service Class)为 Kubernetes 提供了一种将集群中的 Pod 分为几个类并做出有关调度和驱逐决策的方法。
[+]Pod 的 QoS 类是基于 Pod 在创建时配置的计算资源请求和限制。QoS 类用于制定有关 Pod 调度和逐出的决策。 Kubernetes 可以为 Pod 分配以下 QoS 类:
Guaranteed
,Burstable
或者BestEffort
。ReplicaSet 是下一代副本控制器。
[+]ReplicaSet 就像 ReplicationController 那样,确保一次运行指定数量的 Pod 副本。ReplicaSet 支持新的基于集合的选择器需求(在标签的用户指南中有相关描述),而副本控制器只支持基于等值的选择器需求。
Secret 用于存储敏感信息,如密码、OAuth 令牌和 SSH 密钥。
[+]Secret 允许用户对如何使用敏感信息进行更多的控制,并减少信息意外暴露的风险。 默认情况下,Secret 值被编码为 base64 字符串并以非加密的形式存储,但可以配置为 静态加密(Encrypt at rest)。
Pod 可以通过多种方式引用 Secret, 例如在卷挂载中引用或作为环境变量引用。Secret 设计用于机密数据,而 ConfigMap 设计用于非机密数据。
定义 Pod 或 Service 这类每种对象应被如何配置及其预期状态。
[+]几乎每个 Kubernetes 对象都包含两个嵌套的对象字段,用于治理对象本身的配置: 对象规约(spec)和对象状态(status)。 对于具有规约的对象,你必须在创建对象时设置规约,并提供资源所需特征的描述:即其预期状态。
此字段对于 Pod、StatefulSet 和 Service 等不同对象会有所差异, 字段详细说明如容器、卷、副本、端口等设置以及每种对象特有的其他规约。 此字段封装了 Kubernetes 针对所定义的对象应保持何种状态。
StatefulSet 用来管理某 Pod 集合的部署和扩缩, 并为这些 Pod 提供持久存储和持久标识符。
[+]和 Deployment 类似, StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是, StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的, 但是不能相互替换:无论怎么调度,每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储,可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障, 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
Kubernetes 系统生成的字符串,唯一标识对象。
[+]在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID,它旨在区分类似实体的历史事件。
不可变基础设施指的是一旦部署就不能变更的计算机基础设施(虚拟机、容器和网络设施)。
[+]不可变性可以通过某个自动化进程或某种系统来强制执行,前者会覆盖未经授权的变更,而后者从源头上就不允许进行变更。 容器是不可变基础设施的一个很好的例子, 这是因为对容器的持久变更只能通过创建新版本的容器或从其镜像重新创建现有容器来进行。
通过防止或识别未经授权的变更,不可变基础设施可以更容易地识别和缓解安全风险。 操作此类系统变得更加简单明了,因为管理员可以对其作一些假设。 毕竟,他们可以确认没有人犯错,也没人做了变更而又忘记沟通。 不可变基础设施与基础设施即代码关系紧密,后者将所有创建基础设施所需的自动化都存储在版本控制中(如 Git)。 不可变性和版本控制的结合意味着对系统的每个经过授权的变更都会对应一个持久的审计日志记录。
K8s 社区中持续活跃的贡献者(contributor)。
[+]可以将问题单(issue)和 PR 指派给成员(Member),成员(Member)也可以通过 GitHub 小组加入 特别兴趣小组 (SIGs)。针对成员(Member)所提交的 PR,系统自动运行提交前测试。成员(Member)应该是持续活跃的社区贡献者。
申领持久卷(PersistentVolume) 中定义的存储资源,以便可以将其挂载为容器(container)中的卷。
[+]指定存储的数量,如何访问存储(只读、读写或独占)以及如何回收存储(保留、回收或删除)。 存储本身的详细信息在 PersistentVolume 对象中。
在计算机领域,代理指的是充当远程服务中介的服务器。
[+]客户端与代理进行交互;代理将客户端的数据复制到实际服务器;实际服务器回复代理;代理将实际服务器的回复发送给客户端。
kube-proxy 是集群中每个节点上运行的网络代理,实现了部分 Kubernetes 服务(Service) 概念。
你可以将 kube-proxy 作为普通的用户态代理服务运行。 如果你的操作系统支持,则可以在混合模式下运行 kube-proxy;该模式使用较少的系统资源即可达到相同的总体效果。
为 Kubernetes 开源代码库开发并贡献代码的人。
[+]他们也是加入一个或多个特别兴趣小组 (Special Interest Groups;SIGs)的活跃成员。
允许用户请求自动创建存储卷。
[+]动态制备让集群管理员无需再预先制备存储。这种机制转为通过用户请求自动地制备存储。 动态卷制备是基于 API 对象 StorageClass 的, StorageClass 可以引用卷插件(Volume Plugin) 提供的卷, 也可以引用传递给卷插件的参数集。
端点负责记录与服务的选择器相匹配的 Pod 的 IP 地址。
[+]端点可以手动配置到服务(Service)上,而不必指定选择器标识。
EndpointSlice 提供了一种可伸缩、可扩展的替代方案。
Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。
[+]Kubernetes 对象通常是一个“意向表述(Record of Intent)”—一旦你创建了一个对象,Kubernetes 控制平面(Control Plane) 就不断工作, 以确保它所代表的事物确实存在。 创建一个对象相当于告知 Kubernetes 系统:你期望这部分集群负载看起来像什么;这也就是你集群的期望状态。
服务目录是一种过去曾经存在的扩展 API,它能让 Kubernetes 集群中运行的应用易于使用外部托管的软件服务,例如云供应商提供的数据仓库服务。
[+]服务目录可以检索、供应并绑定外部托管服务(Managed Services), 而无需知道那些服务具体是怎样创建和托管的。
一种管理多副本应用的工作负载资源,能够确保特定个数的 Pod 实例处于运行状态。
[+]控制平面确保即使某些 Pod 失效、被你手动删除或错误地启动了过多 Pod 时, 指定数量的 Pod 仍处于运行状态。
说明:
ReplicationController 已被弃用。请参见执行类似功能的 Deployment。
干扰(Disruption)是指导致一个或者多个 Pod 服务停止的事件。 干扰会影响依赖于受影响的 Pod 的资源,例如 Deployment。
[+]如果你作为一个集群操作人员,销毁了一个从属于某个应用的 Pod, Kubernetes 视之为自愿干扰(Voluntary Disruption)。 如果由于节点故障或者影响更大区域故障的断电导致 Pod 离线, Kubernetes 视之为非愿干扰(Involuntary Disruption)。
更多信息请查阅干扰。
工作负载是在 Kubernetes 上运行的应用程序。
[+]代表不同类型或部分工作负载的各种核心对象包括 DaemonSet、Deployment、Job、ReplicaSet 和 StatefulSet。
例如,具有 Web 服务器和数据库的工作负载可能在一个 StatefulSet 中运行数据库, 而 Web 服务器运行在 Deployment。
工作组是为了方便讨论和(或)推进执行一些短周期、窄范围、或者从委员会和 SIG 分离出来的项目、以及跨 SIG 的活动。
[+]工作组可以将人们组织起来,一起完成一项分散的任务。
更多信息请参考 kubernetes/community 代码库和当前的 SIGs 和工作组 列表。
通过贡献代码、文档或者投入时间等方式来帮助 Kubernetes 项目或社区的人。
[+]贡献形式包括提交拉取请求(PR)、问题报告(Issue)、反馈、 参与特别兴趣小组(SIG)或者组织社区活动等等。
混排切片(Shuffle Sharding)是指一种将请求指派给队列的技术,其隔离性好过对队列个数哈希取模的方式。
[+]我们通常会关心不同的请求序列间的相互隔离问题,目的是为了确保密度较高的 请求序列不会湮没密度较低的序列。 将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数, 将结果对队列的个数取模,从而得到要使用的队列的索引。 这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如,在因特网上, 这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的 五元组。
这种简单的基于哈希的模式有一种特性,高密度的请求序列(流)会湮没那些被 哈希到同一队列的其他低密度请求序列(流)。 为大量的序列提供较好的隔离性需要提供大量的队列,因此是有问题的。 混排切片是一种更为灵活的机制,能够更好地将低密度序列与高密度序列隔离。 混排切片的术语采用了对一叠扑克牌进行洗牌的类比,每个队列可类比成一张牌。 混排切片技术首先对请求的特定于所在序列的特征执行哈希计算,生成一个长度 为十几个二进制位或更长的哈希值。 接下来,用该哈希值作为信息熵的来源,对一叠牌来混排,并对整个一手牌(队列)来洗牌。 最后,对所有处理过的队列进行检查,选择长度最短的已检查队列作为请求的目标队列。 在队列数量适中的时候,检查所有已处理的牌的计算量并不大,对于任一给定的 低密度的请求序列而言,有相当的概率能够消除给定高密度序列的湮没效应。 当队列数量较大时,检查所有已处理队列的操作会比较耗时,低密度请求序列 消除一组高密度请求序列的湮没效应的机会也随之降低。因此,选择队列数目 时要颇为谨慎。
管理授权决策,允许管理员通过 Kubernetes API 动态配置访问策略。
[+]RBAC 使用 角色 (包含权限规则)和 角色绑定 (将角色中定义的权限授予一组用户)。
Kubernetes 管理相关工作包括:日常管理操作和协调升级。
[+]集群操作(Cluster Operations)工作的示例包括: 部署新节点来扩容集群、执行软件升级、实施安全控制、 添加或删除存储、配置集群网络、管理集群范围的可观测性和响应集群事件。
配置、控制、监控集群的人。
[+]他们的主要责任是保持集群正常运行,可能需要进行周期性的维护和升级活动。
说明:
注意: 集群操作者不同于操作者模式(Operator Pattern),操作者模式是用来扩展 Kubernetes API 的。
- 基础设施层提供并维护虚拟机、网络、安全组及其他资源。 [+]
基础设施层提供并维护虚拟机、网络、安全组及其他资源。
设计涉及一个或多个 Kubernetes 集群的基础设施的人。
[+]集群架构师(Cluster Architect)关心分布式系统的最佳实践,例如:高可用性和安全性。
用于以流的形式跟踪 Kubernetes 中对象更改的动词。 它用于高效检测更改。
[+]用于以流的形式跟踪 Kubernetes 中对象变化的动词。 监视可以有效地检测变化;例如,需要知道 ConfigMap 何时发生变化的控制器可以使用监视而不是轮询。 请参阅有效检测 API 概念的变化了解更多信息。
聚合层允许你在自己的集群上安装额外的 Kubernetes 风格的 API。
[+]当你配置了 Kubernetes API 服务器来支持额外的 API, 你就可以在 Kubernetes API 中增加
APIService
对象来"申领(Claim)"一个 URL 路径。在 Kubernetes 中,控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。
[+]控制器(控制平面的一部分) 通过 API 服务器监控你的集群中的公共状态。
其中一些控制器是运行在控制平面内部的,对 Kubernetes 来说,他们提供核心控制操作。 比如:部署控制器(deployment controller)、守护控制器(daemonset controller)、 命名空间控制器(namespace controller)、持久化数据卷控制器(persistent volume controller)(等) 都是运行在 kube-controller-manager 中的。
一组具有可选资源隔离、审计和限制的 Linux 进程。
[+]cgroup 是一个 Linux 内核特性,对一组进程的资源使用(CPU、内存、磁盘 I/O 和网络等)进行限制、审计和隔离。
使用全数字来表示较小数值或使用 SI 后缀表示较大数值的表示法。
[+]量纲是使用紧凑的全数字表示法来表示小数值或带有国际计量单位制(SI) 的大数值的表示法。 小数用 milli 单位表示,而大数用 kilo、mega 或 giga 单位表示。
例如,数字
1.5
表示为1500m
, 而数字1000
表示为1k
,1000000
表示为1M
。 你还可以指定二进制表示法后缀;数字 2048 可以写成2Ki
。公认的十进制(10 的幂数)单位是
m
(milli)、k
(kilo,有意小写)、M
(mega)、G
(giga)、T
(terra)、P
(peta)、E
(exa)。公认的二进制(2 的幂数)单位是
Ki
(kibi)、Mi
(mebi)、Gi
(gibi)、Ti
(tebi)、Pi
(pebi)、Ei
(exbi)。你可以在 Pod 中临时运行的一种 容器(Container) 类型。
[+]如果想要调查运行中有问题的 Pod,可以向该 Pod 添加一个临时容器(Ephemeral Container)并进行诊断。 临时容器没有资源或调度保证,因此不应该使用它们来运行工作负载本身的任何部分。
静态 Pod 不支持临时容器。
客户端提供的字符串,引用资源 URL 中的对象,如
[+]/api/v1/pods/some name
。某一时刻,只能有一个给定类型的对象具有给定的名称。但是,如果删除该对象,则可以创建同名的新对象。
能够审核并批准 Kubernetes 代码贡献的人。
[+]代码审核的重点是代码质量和正确性,而批准的重点是对贡献的整体接受。 整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。 批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。
定制 Kubernetes 平台以满足自己的项目需求的人。
[+]平台开发人员可以使用定制资源 或使用汇聚层扩展 Kubernetes API 来为其 Kubernetes 实例增加功能,特别是为其应用程序添加功能。 一些平台开发人员也是 kubernetes 贡献者, 他们会开发贡献给 Kubernetes 社区的扩展。 另一些平台开发人员则开发封闭源代码的商业扩展或用于特定网站的扩展。
评审者是负责评审项目的某部分代码以便提高代码质量和正确性的人。
[+]评审者既要了解代码库又要了解软件工程规范。评审者状态是基于代码库的组成部分来设定的。
日志是 集群(cluster) 或应用程序记录的事件列表。
[+]应用程序和系统日志可以帮助你了解集群内部发生的情况。日志对于调试问题和监视集群活动非常有用。
容器是可移植、可执行的轻量级的镜像,包含其中的软件及其相关依赖。
[+]容器使应用和底层的主机基础设施解耦,降低了应用在不同云环境或者操作系统上的部署难度,便于应用扩展。 在容器内运行的应用称为容器化应用。将这些应用及其依赖项捆绑到容器镜像中的过程称为容器化。
容器存储接口(Container Storage Interface;CSI)定义存储系统暴露给容器的标准接口。
[+]CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件, 而无需将这些插件的代码添加到 Kubernetes 代码仓库(外部插件)。 要使用某个存储提供商的 CSI 驱动,你首先要 将它部署到你的集群上。 然后你才能创建使用该 CSI 驱动的 Storage Class 。
这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。
[+]Kubernetes 支持许多容器运行环境,例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
容器运行时接口(Container Runtime Interface;CRI)是一组让容器运行时与节点上 kubelet 集成的 API。
[+]更多信息,请参考容器运行时接口(CRI) API 与规范。
- 提供诸如 CPU、内存、网络和存储的能力,以便容器可以运行并连接到网络。 [+]
提供诸如 CPU、内存、网络和存储的能力,以便容器可以运行并连接到网络。
共同管理大范畴 Kubernetes 开源项目中某组件或方面的一组社区成员。
[+]SIG 中的成员对推进某个领域(如体系结构、API 机制构件或者文档)具有相同的兴趣。 SIGs 必须遵从 governance guidelines 的规定, 不过可以有自己的贡献策略以及通信渠道(方式)。
更多的详细信息可参阅 kubernetes/community 仓库以及 SIGs 和工作组(Working Groups)的最新列表。
由第三方供应商负责维护的一种软件产品。
[+]托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等, 不过它们也可以是可以被某应用使用的任何软件交付件。
网络策略是一种规范,规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。
[+]网络策略帮助你声明式地配置允许哪些 Pod 之间、哪些命名空间之间允许进行通信, 并具体配置了哪些端口号来执行各个策略。
NetworkPolicy
资源使用标签来选择 Pod, 并定义了所选 Pod 可以接受什么样的流量。网络策略由网络提供商提供的并被 Kubernetes 支持的网络插件实现。 请注意,当没有控制器实现网络资源时,创建网络资源将不会生效。可以指:Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。
[+]- 在 Kubernetes 社区中:下游(downstream) 在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如,Kubernetes 的一个新特性可以被下游(downstream) 应用采用,以提升它们的功能性。
- 在 GitHub 或 git 中:约定用下游(downstream) 表示分支代码库,源代码库被认为是上游(upstream)。
选择算符允许用户通过标签(labels)对一组资源对象进行筛选过滤。
[+]在查询资源列表时,选择算符可以通过标签对资源进行过滤筛选。
- 各种容器化应用运行所在的层。 [+]
各种容器化应用运行所在的层。
应用架构师是负责应用高级设计的人。
[+]应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。 周边组件包括数据库、日志基础设施和其他微服务。
编写可以在 Kubernetes 集群上运行的应用的人。
[+]应用开发者专注于应用的某一部分。他们工作范围的大小有明显的差异。
- 亦称作: 云服务提供商(Cloud Service Provider)
一个提供云计算平台的商业机构或其他组织。
[+]云提供商(Cloud provider),有时也称作云服务提供商(CSPs)提供云计算平台或服务。
很多云提供商提供托管的基础设施(也称作基础设施即服务或 IaaS)。 针对托管的基础设施,云提供商负责服务器、存储和网络,而用户(你) 负责管理其上运行的各层软件,例如运行一个 Kubernetes 集群。
你也会看到 Kubernetes 被作为托管服务提供;有时也称作平台即服务或 PaaS。 针对托管的 Kubernetes,你的云提供商负责 Kubernetes 的控制平面以及 节点 及他们所依赖的基础设施: 网络、存储以及其他一些诸如负载均衡器之类的元素。
证书是个安全加密文件(cryptographically secure file),用来确认对 Kubernetes 集群访问的合法性。
[+]证书(Certificate)可以让 Kubernetes 集群中运行的应用程序安全的访问 Kubernetes API。 证书可以确认客户端是否被允许访问 API。
在对象持久化之前拦截 Kubernetes API 服务器请求的一段代码。
[+]准入控制器可针对 Kubernetes API 服务器进行配置,可以执行“验证(validating)”、“变更(mutating)”或两者都执行。 任何准入控制器都可以拒绝访问请求。 变更控制器可以修改其允许的对象,验证控制器则不可以。
- 亦称作: GVR
表示唯一的 Kubernetes API 资源的方法。
[+]组版本资源(Group Version Resource, GVR)指定了与访问 Kubernetes 中对象的特定 id 相关联的 API 组、API 版本和资源(URI 中显示的对象类别的名称)。GVR 允许你定义和区分不同的 Kubernetes 对象, 并指定了一种访问对象的方式,即使在 API 发生变化时这也是一种稳定的访问方式。
反馈
此页是否对你有帮助?
感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案,可以访问 Stack Overflow. 如果需要,请在 GitHub 仓库 上登记新的问题 报告问题 或者 提出改进建议.