节点
在 OpenShift Container Platform 中配置和管理节点
摘要
第 1 章 节点概述 复制链接链接已复制到粘贴板!
1.1. 关于节点 复制链接链接已复制到粘贴板!
节点是 Kubernetes 集群中的虚拟机或裸机。Worker 节点托管您的应用程序容器,分组为 pod。control plane 节点运行控制 Kubernetes 集群所需的服务。在 OpenShift Container Platform 中,control plane 节点不仅仅包含用于管理 OpenShift Container Platform 集群的 Kubernetes 服务。
在集群中运行稳定和健康的节点是基本运行托管应用程序的基本操作。在 OpenShift Container Platform 中,您可以通过代表节点的 Node 对象访问、管理和监控节点。使用 OpenShift CLI(oc)或 Web 控制台,您可以在节点上执行以下操作。
节点的以下组件负责维护运行 pod 并提供 Kubernetes 运行时环境。
- 容器运行时
- 容器运行时负责运行容器。Kubernetes 提供多个运行时,如 containerd、cri-o、rktlet 和 Docker。
- Kubelet
- kubelet 在节点上运行并读取容器清单。它确保定义的容器已启动且正在运行。kubelet 进程维护工作和节点服务器的状态。kubelet 管理网络流量和端口转发。kubelet 管理仅由 Kubernetes 创建的容器。
- Kube-proxy
- kube-proxy 在集群的每个节点上运行,并维护 Kubernetes 资源之间的网络流量。Kube-proxy 可确保网络环境被隔离并可访问。
- DNS
- 集群 DNS 是一个 DNS 服务器,它为 Kubernetes 服务提供 DNS 记录。由 Kubernetes 启动的容器会在其 DNS 搜索中自动包含此 DNS 服务器。
读取操作
通过读操作,管理员可以或开发人员获取 OpenShift Container Platform 集群中节点的信息。
- 列出集群中的所有节点。
- 获取节点的相关信息,如内存和 CPU 使用量、健康、状态和年龄。
- 列出节点上运行的 pod。
管理操作
作为管理员,您可以通过几个任务轻松地在 OpenShift Container Platform 集群中管理节点:
-
添加或更新节点标签。标签是应用于
Node对象的键值对。您可以使用标签来控制 pod 的调度。 -
使用自定义资源定义(CRD)或
kubeletConfig对象更改节点配置。 -
配置节点以允许或禁止调度 pod。具有
Ready状态的健康 worker 节点默认允许 pod 放置,而 control plane 节点没有;您可以通过将 worker 节点配置为不可调度,并将 control plane 节点配置为可以调度。 -
使用
system-reserved设置为节点分配资源。您可以允许 OpenShift Container Platform 自动决定节点的最佳system-reservedCPU 和内存资源,也可以手动决定并为节点设置最佳资源。 - 根据节点上的处理器内核数、硬限制或两者,配置可在节点上运行的 pod 数量。
- 使用 pod 反关联性来安全地重新引导节点。
- 通过使用计算机器集缩减集群,从集群中删除节点。要从裸机集群中删除节点,您必须首先排空节点上的所有 pod,然后手动删除该节点。
增强操作
OpenShift Container Platform 不仅支持访问和管理节点;作为管理员,您可以在节点上执行以下任务,使集群更高效、应用程序友好,并为开发人员提供更好的环境。
- 使用 Node Tuning Operator,为需要一定等级内核调整的高性能应用程序管理节点级别的性能优化。
- 使用守护进程集在节点上自动运行后台任务。您可以创建并使用守护进程集来创建共享存储,在每个节点上运行日志记录 pod,或者在所有节点上部署监控代理。
- 在节点上启用 TLS 安全配置集,以保护 kubelet 和 Kubernetes API 服务器之间的通信。
- 使用守护进程集在节点上自动运行后台任务。您可以创建并使用守护进程集来创建共享存储,在每个节点上运行日志记录 pod,或者在所有节点上部署监控代理。
- 使用垃圾回收释放节点资源。您可以通过删除终止的容器以及任何正在运行的 pod 不引用的镜像来确保节点高效运行。
- 在一组节点中添加内核参数。
- 将 OpenShift Container Platform 集群配置为在网络边缘(远程 worker 节点)具有 worker 节点。如需有关在 OpenShift Container Platform 集群中具有远程 worker 节点的挑战,以及一些在远程 worker 节点上管理 pod 的建议方法,请参阅在网络边缘使用远程 worker 节点。
1.2. 关于 pod 复制链接链接已复制到粘贴板!
pod 是节点上共同部署的一个或多个容器。作为集群管理员,您可以定义 pod,为它分配在准备好调度和管理的健康节点上运行。只要容器正在运行,pod 就会运行。在 Pod 被定义并运行后,您无法更改它。使用 pod 时,您可以执行的一些操作包括:
读取操作
作为管理员,您可以通过以下任务来获取项目中的 pod 信息:
- 列出与项目关联的 pod,包括副本数、重启、当前状态和年龄等信息。
- 查看 pod 用量统计,如 CPU、内存和存储消耗。
管理操作
以下任务列表概述了管理员如何在 OpenShift Container Platform 集群中管理 pod。
使用 OpenShift Container Platform 中可用的高级调度功能控制 pod 调度:
- 配置 descheduler 以根据特定策略驱除 pod,以便调度程序将 pod 重新调度到更合适的节点。
- 配置 pod 如何使用 pod 控制器重启后的行为,然后重新启动策略。
- 限制 pod 上的出口和入口流量。
- 从具有 pod 模板的任何对象中添加和移除卷。卷是 pod 中所有容器使用的已挂载文件系统。容器存储是临时的;您可以使用卷来持久保留容器数据。
增强操作
您可以使用 OpenShift Container Platform 中提供的各种工具和功能,更轻松地使用 pod。以下操作涉及使用这些工具和功能来更好地管理 pod。
| 操作 | 用户 | 更多信息 |
|---|---|---|
| 创建并使用 pod 横向自动扩展。 | 开发者 | 您可以使用 pod 横向自动扩展来指定您要运行的 pod 的最小和最大数量,以及 pod 的目标 CPU 使用率或内存使用率。通过使用 pod 横向自动扩展,您可以自动扩展 pod。 |
| 管理员和开发人员 | 作为管理员,通过监控资源和资源要求,使用垂直 pod 自动扩展来更好地利用集群资源。 作为开发人员,使用垂直 pod 自动扩展来确保 pod 在高负载时可以继续工作,方法是将 pod 调度到具有每个 pod 充足资源的节点。 | |
| 使用设备插件提供对外部资源的访问。 | Administrator | 设备插件是在节点(kubelet 的外部)上运行的 gRPC 服务,用于管理特定的硬件资源。您可以部署设插件,以提供一致且可移植的解决方案,以便在集群中使用硬件设备。 |
|
使用 | Administrator |
有些应用程序需要敏感信息,如密码和用户名。您可以使用 |
1.3. 关于容器 复制链接链接已复制到粘贴板!
容器是 OpenShift Container Platform 应用程序的基本单元,它由应用程序代码与其依赖项、库和二进制文件一起打包。容器提供不同环境间的一致性和多个部署目标:物理服务器、虚拟机 (VM) 和私有或公有云。
Linux 容器技术是一种轻量型机制,用于隔离运行中的进程,仅限制对指定的资源的访问。作为管理员,您可以在 Linux 容器上执行各种任务,例如:
OpenShift Container Platform 提供针对 Init 容器的专用容器。init 容器在应用程序容器之前运行,可以包含应用程序镜像中不存在的工具或设置脚本。您可以在部署 pod 的其余部分之前,使用 Init 容器执行任务。
除了在节点、Pod 和容器上执行特定任务外,您还可使用整个 OpenShift Container Platform 集群来使集群高效和应用程序 pod 具有高可用性。
1.4. 关于节点上的自动扩展 pod 复制链接链接已复制到粘贴板!
OpenShift Container Platform 提供了三种工具,可用于自动扩展节点上的 pod 数量以及分配给 pod 的资源。
- Pod 横向自动扩展
Horizontal Pod Autoscaler (HPA) 可以根据从属于该复制控制器或部署配置的 pod 收集的指标自动增加或减少复制控制器或部署配置的规模。
如需更多信息,请参阅使用 pod 横向自动扩展自动扩展 pod。
- 自定义 Metrics Autoscaler
自定义 Metrics Autoscaler 可以根据不基于 CPU 或内存的自定义指标自动增加或减少部署、有状态集、自定义资源或作业的 pod 数量。
如需更多信息,请参阅自定义 Metrics Autoscaler Operator 概述。
- Vertical Pod Autoscaler
Vertical Pod Autoscaler (VPA) 可以自动查看 pod 中容器的运行状况和当前的 CPU 和内存资源,并根据它所了解的用量值更新资源限值和请求。
如需更多信息,请参阅使用垂直 pod 自动扩展自动调整 pod 资源级别。
1.5. OpenShift Container Platform 节点的常用术语表 复制链接链接已复制到粘贴板!
该术语表定义了在节点内容中使用的常用术语。
- Container
- 它是一个轻量级且可执行的镜像,它包括了软件及其所有依赖项。容器虚拟化操作系统,因此您可以在任意位置运行容器,包括数据中心到公共或私有云,甚至在开发人员笔记本电脑中运行。
- 守护进程集
- 确保 pod 副本在 OpenShift Container Platform 集群的合格节点上运行。
- egress
- 通过来自 pod 的网络出站流量进行外部数据共享的过程。
- 垃圾回收
- 清理集群资源的过程,如终止的容器和未被任何正在运行的 Pod 引用的镜像。
- 横向 Pod 自动扩展 (HPA)
- 作为 Kubernetes API 资源和控制器实现。您可以使用 HPA 指定您要运行的 pod 的最小和最大数量。您还可以指定 pod 应该针对的 CPU 或内存使用率。当超过给定 CPU 或内存阈值时,HPA 会扩展或缩放 pod。
- 入口
- 到一个 pod 的传入流量。
- 作业
- 要完成的进程。作业创建一个或多个 pod 对象,并确保指定的 pod 成功完成。
- 标签
- 您可以使用标签(即键值对)来组织并选择对象子集,如 pod。
- 节点
- OpenShift Container Platform 集群中的 worker 机器。节点可以是虚拟机 (VM) 或物理机器。
- Node Tuning Operator
- 您可以使用 Node Tuning Operator,使用 TuneD 守护进程来管理节点级别的性能优化。它保证了自定义性能优化设置以可被守护进程支持的格式传递到在集群中运行的所有容器化的 TuneD 守护进程中。相应的守护进程会在集群的所有节点上运行,每个节点上运行一个。
- 自助服务修复 Operator
- Operator 在集群节点上运行,并检测和重启不健康的节点。
- Pod
- 一个或多个带有共享资源(如卷和 IP 地址)的容器,在 OpenShift Container Platform 集群中运行。pod 是定义、部署和管理的最小计算单元。
- 容限(toleration)
- 表示 pod 允许(但不需要)调度到具有匹配污点的节点组。您可以使用容限来启用调度程序来调度具有匹配污点的 pod。
- 污点(taint)
- 一个核心对象,由一个键、值和效果组成。污点和容限可以一起工作,以确保 pod 不会调度到不相关的节点上。
第 2 章 使用 pod 复制链接链接已复制到粘贴板!
2.1. 使用 pod 复制链接链接已复制到粘贴板!
pod 是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。
2.1.1. 了解 pod 复制链接链接已复制到粘贴板!
对容器而言,Pod 大致相当于一个机器实例(物理或虚拟)。每个 pod 分配有自己的内部 IP 地址,因此拥有完整的端口空间,并且 pod 内的容器可以共享其本地存储和网络。
Pod 有生命周期,它们经过定义后,被分配到某一节点上运行,然后持续运行,直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码,Pod 可在退出后删除,或被保留下来以启用对容器日志的访问。
OpenShift Container Platform 将 pod 基本上视为不可变;在运行期间无法更改 pod 定义。OpenShift Container Platform 通过终止现有的 pod,再利用修改后的配置和/或基础镜像重新创建 pod,从而实现更改。Pod 也被视为是可抛弃的,不会在重新创建时保持原来的状态。因此,pod 通常应通过更高级别的控制器来管理,而不直接由用户管理。
如需了解每个 OpenShift Container Platform 节点主机的最大 pod 数,请参阅“集群限制”。
不受复制控制器管理的裸机 pod 不能在节点中断时重新调度。
2.1.2. pod 配置示例 复制链接链接已复制到粘贴板!
OpenShift Container Platform 使用 Kubernetes 的 pod 概念,它是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。
以下是 pod 的示例定义。它展示了 pod 的许多特性,其中大多数已在其他主题中阐述,因此这里仅简略提及:
Pod 对象定义(YAML)
- 1
- pod 可以被“标上”一个或多个标签,然后使用这些标签在一个操作中选择和管理多组 pod。标签以键/值格式保存在
metadata散列中。 - 2
- pod 重启策略,可能的值有
Always、OnFailure和Never。默认值为Always。 - 3
- OpenShift Container Platform 为容器定义了一个安全上下文,指定是否允许其作为特权容器来运行,或者以所选用户身份运行,等等。默认上下文的限制性比较强,但管理员可以根据需要进行修改。
- 4
containers指定包括一个或多个容器定义的数组。- 5
- 容器指定在容器中挂载外部存储卷的位置。
- 6
- 指定要为 pod 提供的卷。卷挂载在指定路径上。不要挂载到容器 root、
/或主机和容器中相同的任何路径。如果容器有足够权限,可能会损坏您的主机系统(如主机的/dev/pts文件)。使用/host挂载主机是安全的。 - 7
- pod 中的每个容器使用自己的容器镜像进行实例化。
- 8
- pod 定义了可供其容器使用的存储卷。
如果将具有高文件数的持久性卷附加到 pod,则这些 pod 可能会失败,或者可能需要很长时间才能启动。如需更多信息,请参阅在 OpenShift 中使用具有高文件计数的持久性卷时,为什么 pod 无法启动或占用大量时间来实现"Ready"状态?
此 pod 定义不包括 OpenShift Container Platform 在 pod 创建并开始其生命周期后自动填充的属性。Kubernetes pod 文档详细介绍了 pod 的功能和用途。
2.2. 查看 pod 复制链接链接已复制到粘贴板!
作为管理员,您可以查看集群中的 pod,并确定这些 pod 和整个集群的健康状态。
2.2.1. 关于 pod 复制链接链接已复制到粘贴板!
OpenShift Container Platform 使用 Kubernetes 的 pod 概念,它是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。对容器而言,Pod 大致相当于机器实例(物理或虚拟)。
您可以查看与特定项目关联的 pod 列表,或者查看 pod 的使用情况统计。
2.2.2. 查看项目中的 pod 复制链接链接已复制到粘贴板!
您可以查看与当前项目关联的 pod 列表,包括副本数、当前状态、重启次数和 pod 的年龄。
流程
查看项目中的 pod:
切换到对应项目:
oc project <project-name>
$ oc project <project-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加
-o wide标记来查看 pod IP 地址和 pod 所在的节点。oc get pods -o wide
$ oc get pods -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.3. 查看 pod 用量统计 复制链接链接已复制到粘贴板!
您可以显示 pod 的用量统计,这些统计信息为容器提供了运行时环境。这些用量统计包括 CPU、内存和存储的消耗。
先决条件
-
您必须有
cluster-reader权限才能查看用量统计。 - 必须安装 Metrics 才能查看用量统计。
流程
查看用量统计:
运行以下命令:
oc adm top pods
$ oc adm top podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc adm top pods -n openshift-console
$ oc adm top pods -n openshift-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15Mi
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15MiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,以查看带有标签的 pod 用量统计:
oc adm top pod --selector=''
$ oc adm top pod --selector=''Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您必须选择过滤所基于的选择器(标签查询)。支持
=、==和!=。例如:
oc adm top pod --selector='name=my-pod'
$ oc adm top pod --selector='name=my-pod'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.4. 查看资源日志 复制链接链接已复制到粘贴板!
您可以在 OpenShift CLI (oc) 和 Web 控制台中查看各种资源的日志。日志从日志的尾部或末尾读取。
先决条件
-
访问 OpenShift CLI(
oc)。
流程 (UI)
在 OpenShift Container Platform 控制台中,导航到 Workloads → Pods,或通过您要调查的资源导航到 pod。
注意有些资源(如构建)没有直接查询的 pod。在这种情况下,您可以在资源的 Details 页面中找到 Logs 链接。
- 从下拉菜单中选择一个项目。
- 点您要调查的 pod 的名称。
- 点 Logs。
流程 (CLI)
查看特定 pod 的日志:
oc logs -f <pod_name> -c <container_name>
$ oc logs -f <pod_name> -c <container_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
-f- 可选:指定输出是否遵循要写到日志中的内容。
<pod_name>- 指定 pod 的名称。
<container_name>- 可选:指定容器的名称。当 pod 具有多个容器时,您必须指定容器名称。
例如:
oc logs ruby-58cd97df55-mww7r
$ oc logs ruby-58cd97df55-mww7rCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ruby-57f7f4855b-znl92 -c ruby
$ oc logs -f ruby-57f7f4855b-znl92 -c rubyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出的日志文件内容。
查看特定资源的日志:
oc logs <object_type>/<resource_name>
$ oc logs <object_type>/<resource_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定资源类型和名称。
例如:
oc logs deployment/ruby
$ oc logs deployment/rubyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出的日志文件内容。
2.3. 为 pod 配置 OpenShift Container Platform 集群 复制链接链接已复制到粘贴板!
作为管理员,您可以为 pod 创建和维护高效的集群。
通过确保集群高效运行,您可以使用一些工具为开发人员提供更好的环境,例如,pod 退出时的行为,确保始终有所需数量的 pod 在运行,何时重启设计为只运行一次的 pod,限制 pod 可以使用的带宽,以及如何在中断时让 pod 保持运行。
2.3.1. 配置 pod 重启后的行为 复制链接链接已复制到粘贴板!
pod 重启策略决定了 OpenShift Container Platform 在该 pod 中的容器退出时作出何种响应。该策略适用于 pod 中的所有容器。
可能的值有:
-
Always- 在 pod 被重启之前,按规定的延时值(10s,20s,40s)不断尝试重启 pod 中成功退出的容器(最长为 5 分钟)。默认值为Always。 -
OnFailure- 按规定的延时值(10s,20s,40s)不断尝试重启 pod 中失败的容器,上限为 5 分钟。 -
Never- 不尝试重启 pod 中已退出或失败的容器。Pod 立即失败并退出。
在 pod 绑定到某个节点后,该 pod 永远不会绑定到另一个节点。这意味着,需要一个控制器才能使 pod 在节点失败后存活:
| 状况 | 控制器类型 | 重启策略 |
|---|---|---|
| 应该终止的 Pod(例如,批量计算) | 作业 |
|
| 不应该终止的 Pod(例如,Web 服务器) | 复制控制器 |
|
| 每台机器必须运行一个的 Pod | 守护进程集 | 任意 |
如果 pod 上的容器失败且重启策略设为 OnFailure,则 pod 会保留在该节点上并重新启动容器。如果您不希望容器重新启动,请使用 Never 重启策略。
如果整个 pod 失败,OpenShift Container Platform 会启动一个新 pod。开发人员必须解决应用程序可能会在新 pod 中重启的情况。特别是,应用程序必须处理由以往运行产生的临时文件、锁定、不完整输出等结果。
Kubernetes 架构需要来自云提供商的可靠端点。当云提供商停机时,kubelet 会防止 OpenShift Container Platform 重启。
如果底层云提供商端点不可靠,请不要使用云提供商集成来安装集群。应像在非云环境中一样安装集群。不建议在已安装的集群中打开或关闭云提供商集成。
如需详细了解 OpenShift Container Platform 如何使用与失败容器相关的重启策略,请参阅 Kubernetes 文档中的示例状态。
2.3.2. 限制可供 pod 使用的带宽 复制链接链接已复制到粘贴板!
您可以对 pod 应用服务质量流量控制,有效限制其可用带宽。出口流量(从 pod 传出)按照策略来处理,仅在超出配置的速率时丢弃数据包。入口流量(传入 pod 中)通过控制已排队数据包进行处理,以便有效地处理数据。您对 pod 应用的限制不会影响其他 pod 的带宽。
流程
限制 pod 的带宽:
编写对象定义 JSON 文件,并使用
kubernetes.io/ingress-bandwidth和kubernetes.io/egress-bandwidth注解指定数据流量速度。例如,将 pod 出口和入口带宽限制为 10M/s:受限
Pod对象定义Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用对象定义创建 pod:
oc create -f <file_or_dir_path>
$ oc create -f <file_or_dir_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.3. 了解如何使用 pod 中断预算来指定必须在线的 pod 数量 复制链接链接已复制到粘贴板!
pod 中断预算允许在操作过程中指定 pod 的安全限制,如排空节点以进行维护。
PodDisruptionBudget 是一个 API 对象,用于指定在某一时间必须保持在线的副本的最小数量或百分比。在项目中进行这些设置对节点维护(比如缩减集群或升级集群)有益,而且仅在自愿驱除(而非节点失败)时遵从这些设置。
PodDisruptionBudget 对象的配置由以下关键部分组成:
- 标签选择器,即一组 pod 的标签查询。
可用性级别,用来指定必须同时可用的最少 pod 的数量:
-
minAvailable是必须始终可用的 pod 的数量,即使在中断期间也是如此。 -
maxUnavailable是中断期间可以无法使用的 pod 的数量。
-
Available 指的是具有 Ready=True 的 pod 数量。ready=True 指的是能够服务请求的 pod,并应添加到所有匹配服务的负载平衡池中。
允许 maxUnavailable 为 0% 或 0,minAvailable 为 100% 或等于副本数,但这样设置可能会阻止节点排空操作。
对于 OpenShift Container Platform 中的所有机器配置池,maxUnavailable 的默认设置是 1。建议您不要更改这个值,且一次只更新一个 control plane 节点。对于 control plane 池,请不要将这个值改为 3。
您可以使用以下命令来检查所有项目的 pod 中断预算:
oc get poddisruptionbudget --all-namespaces
$ oc get poddisruptionbudget --all-namespaces
以下示例包含特定于 AWS 上的 OpenShift Container Platform 的一些值。
输出示例
如果系统中至少有 minAvailable 个 pod 正在运行,则 PodDisruptionBudget 被视为是健康的。超过这一限制的每个 pod 都可被驱除。
根据您的 pod 优先级与抢占设置,可能会无视 pod 中断预算要求而移除较低优先级 pod。
2.3.3.1. 使用 pod 中断预算指定必须在线的 pod 数量 复制链接链接已复制到粘贴板!
您可以使用 PodDisruptionBudget 对象来指定某一时间必须保持在线的副本的最小数量或百分比。
流程
配置 pod 中断预算:
使用类似以下示例的对象定义来创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 或者:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将对象添加到项目中:
oc create -f </path/to/file> -n <project_name>
$ oc create -f </path/to/file> -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.3.2. 为不健康的 pod 指定驱除策略 复制链接链接已复制到粘贴板!
当您使用 pod 中断预算 (PDB) 来指定必须同时有多少 pod 可用时,您还可以定义驱除不健康 pod 的条件。
您可以选择以下策略之一:
- IfHealthyBudget
- 只有在保护的应用程序没有被中断时,运行的还没有处于健康状态的 pod 才能被驱除。
- AlwaysAllow
无论是否满足 pod 中断预算中的条件,运行的还没有处于健康状态的 pod 都可以被驱除。此策略可帮助驱除出现故障的应用程序,如 pod 处于
CrashLoopBackOff状态或无法报告Ready状态的应用程序。注意建议您在
PodDisruptionBudget对象中将unhealthyPodEvictionPolicy字段设置为AlwaysAllow,以便在节点排空期间支持收集错误的应用程序。默认行为是等待应用程序 pod 处于健康状态,然后才能排空操作。
流程
创建定义
PodDisruptionBudget对象的 YAML 文件,并指定不健康的 pod 驱除策略:pod-disruption-budget.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 选择
IfHealthyBudget或AlwaysAllow作为不健康 pod 的驱除策略。当unhealthyPodEvictionPolicy字段为空时,默认为IfHealthyBudget。
运行以下命令来创建
PodDisruptionBudget对象:oc create -f pod-disruption-budget.yaml
$ oc create -f pod-disruption-budget.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在,设置了 AlwaysAllow 不健康 pod 驱除策略的 PDB,您可以排空节点并驱除受此 PDB 保护的应用程序的 pod。
2.3.4. 使用关键 pod 防止删除 pod 复制链接链接已复制到粘贴板!
有不少核心组件对于集群完全正常工作而言至关重要,但它们在常规集群节点而非主节点上运行。如果一个关键附加组件被驱除,集群可能会停止正常工作。
标记为关键 (critical) 的 Pod 不允许被驱除。
流程
使 pod 成为关键 pod:
创建
Podspec 或编辑现有的 pod,使其包含system-cluster-critical优先级类:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 绝不可从节点驱除的 pod 的默认优先级类。
此外,对于对集群而言很重要但可在必要时移除的 pod,可以指定
system-node-critical。创建 pod:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.5. 当使用带有大量文件的持久性卷时,可以减少 pod 超时的情况 复制链接链接已复制到粘贴板!
如果存储卷包含多个文件(~1,000,000 或更多),您可能会遇到 pod 超时的问题。
这是因为当挂载卷时,OpenShift Container Platform 会递归更改每个卷内容的所有权和权限,以匹配 pod 的 securityContext 中指定的 fsGroup。对于大型卷,检查和更改所有权和权限可能会非常耗时,从而导致 pod 启动非常慢。
您可以通过应用以下临时解决方案之一来缩短这个延迟:
- 使用安全性上下文约束 (SCC) 跳过卷的 SELinux 重新标记。
-
使用 SCC 中的
fsGroupChangePolicy字段来控制 OpenShift Container Platform 检查和管理卷的所有权和权限的方式。 - 使用 Cluster Resource Override Operator 自动应用 SCC 来跳过 SELinux 重新标记。
- 使用运行时类跳过卷的 SELinux 重新标记。
如需更多信息,请参阅在 OpenShift 中使用具有高文件计数的持久性卷时,为什么 pod 无法启动或占用大量时间来实现"Ready"状态?
2.4. 使用 pod 横向自动扩展自动扩展 pod 复制链接链接已复制到粘贴板!
作为开发人员,您可以使用 pod 横向自动扩展 (HPA) 来指定 OpenShift Container Platform 如何根据从属于某复制控制器或部署配置的 pod 收集的指标来自动增加或缩小该复制控制器或部署配置的规模。您可以为部署、部署配置、副本集、复制控制器或有状态集创建 HPA。
有关根据自定义指标缩放 pod 的信息,请参阅基于自定义指标自动扩展 pod。
除非需要特定功能或由其他对象提供的行为,否则建议使用 Deployment 对象或 ReplicaSet 对象。如需有关这些对象的更多信息,请参阅了解部署。
2.4.1. 了解 pod 横向自动扩展 复制链接链接已复制到粘贴板!
您可以创建一个 pod 横向自动扩展来指定您要运行的 pod 的最小和最大数量,以及 pod 的目标 CPU 使用率或内存使用率。
在创建了 pod 横向自动扩展后,OpenShift Container Platform 会开始查询 pod 上的 CPU 和/或内存资源指标。当这些指标可用时,pod 横向自动扩展会计算当前指标使用率与所需指标使用率的比率,并相应地扩展或缩减。查询和缩放是定期进行的,但可能需要一到两分钟时间才会有可用指标。
对于复制控制器,这种缩放直接与复制控制器的副本对应。对于部署配置,缩放直接与部署配置的副本计数对应。注意,自动缩放仅应用到 Complete 阶段的最新部署。
OpenShift Container Platform 会自动考虑资源情况,并防止在资源激增期间进行不必要的自动缩放,比如在启动过程中。处于 unready 状态的 pod 在扩展时具有 0 CPU 用量,自动扩展在缩减时会忽略这些 pod。没有已知指标的 Pod 在扩展时具有 0% CPU 用量,在缩减时具有 100% CPU 用量。这在 HPA 决策过程中提供更高的稳定性。要使用这个功能,您必须配置就绪度检查来确定新 pod 是否准备就绪。
要使用 pod 横向自动扩展,您的集群管理员必须已经正确配置了集群指标。
2.4.1.1. 支持的指标 复制链接链接已复制到粘贴板!
pod 横向自动扩展支持以下指标:
| 指标 | 描述 | API 版本 |
|---|---|---|
| CPU 使用率 | 已用的 CPU 内核数。可以用来计算 pod 的已请求 CPU 百分比。 |
|
| 内存使用率 | 已用内存量。可以用来计算 pod 的已请求内存百分比。 |
|
对于基于内存的自动缩放,内存用量必须与副本数呈正比增大和减小。平均而言:
- 增加副本数一定会导致每个 pod 的内存(工作集)用量总体降低。
- 减少副本数一定会导致每个 pod 的内存用量总体增高。
使用 OpenShift Container Platform Web 控制台检查应用程序的内存行为,并确保应用程序在使用基于内存的自动缩放前满足这些要求。
以下示例显示了 image-registry Deployment 对象的自动扩展。初始部署需要 3 个 pod。HPA 对象将最小值增加到 5。如果 pod 的 CPU 用量达到 75%,pod 会增加到 7:
oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75
$ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75
输出示例
horizontalpodautoscaler.autoscaling/image-registry autoscaled
horizontalpodautoscaler.autoscaling/image-registry autoscaled
image-registry Deployment 对象的 HPA 示例,其中 minReplicas 被设置为 3
查看部署的新状态:
oc get deployment image-registry
$ oc get deployment image-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 部署中现在有 5 个 pod:
输出示例
NAME REVISION DESIRED CURRENT TRIGGERED BY image-registry 1 5 5 config
NAME REVISION DESIRED CURRENT TRIGGERED BY image-registry 1 5 5 configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.2. HPA 的工作原理? 复制链接链接已复制到粘贴板!
pod 横向自动扩展(HPA)扩展了 pod 自动扩展的概念。HPA 允许您创建和管理一组负载均衡的节点。当给定的 CPU 或内存阈值被超过时,HPA 会自动增加或减少 pod 数量。
图 2.1. HPA 的高级别工作流
HPA 是 Kubernetes 自动扩展 API 组中的 API 资源。自动扩展器充当控制循环,在同步周期内默认为 15 秒。在此期间,控制器管理器会根据 HPA 的 YAML 文件中定义的 CPU、内存使用率或两者查询 CPU、内存使用或两者。控制器管理器为 HPA 为目标的每个 pod 来获取来自每个 pod 资源指标(如 CPU 或内存)的资源指标的利用率指标。
如果设置了使用值目标,控制器会将利用率值视为各个 pod 中容器对等资源请求的百分比。然后,控制器需要所有目标 pod 的平均利用率,并生成一个用于缩放所需副本数的比率。HPA 配置为从 metrics.k8s.io 获取指标(由 metrics 服务器提供)。由于指标评估的动态性质,副本的数量在扩展一组副本期间会波动。
要实现 HPA,所有目标 pod 都必须在其容器上设置了一个资源请求。
2.4.3. 关于请求和限制 复制链接链接已复制到粘贴板!
调度程序使用您为 pod 中容器指定的资源请求,来确定要将 pod 放置到哪个节点。kubelet 强制执行您为容器指定的资源限值,以确保容器不允许使用超过指定的限制。kubelet 还保留针对该容器使用的系统资源的请求数量。
如何使用资源指标?
在 pod 规格中,您必须指定资源请求,如 CPU 和内存。HPA 使用此规范来确定资源利用率,然后扩展目标或缩减。
例如,HPA 对象使用以下指标源:
在本例中,HPA 将 pod 的平均利用率保持在 scale 目标为 60%。使用率是当前资源使用量与 pod 请求的资源之间的比率。
2.4.4. 最佳实践 复制链接链接已复制到粘贴板!
所有 pod 都必须配置资源请求
HPA 根据 OpenShift Container Platform 集群中观察的 pod 或内存使用率值做出缩放决定。利用率值计算为各个容器集的资源请求的百分比。缺少资源请求值可能会影响 HPA 的最佳性能。
配置冷却期
在横向 pod 自动扩展过程中,可能会快速扩展事件,而不会造成时间差。配置 cool down 周期,以防止频繁的副本波动。您可以通过配置 stabilizationWindowSeconds 字段指定 cool down period。当用于扩展的指标保持波动时,stabilization 窗口用于限制副本数的波动。自动扩展算法使用这个窗口来推断以前的预期状态,并避免对工作负载扩展不需要的更改。
例如,为 scaleDown 字段指定了 stabilization 窗口:
behavior:
scaleDown:
stabilizationWindowSeconds: 300
behavior:
scaleDown:
stabilizationWindowSeconds: 300
在上例中,过去 5 分钟的所有所需状态都被视为。此近似滚动的最大值,避免让扩展算法频繁删除 pod,仅在稍后触发同等的 pod 重新创建。
2.4.4.1. 扩展策略 复制链接链接已复制到粘贴板!
autoscaling/v2 API 允许您为 pod 横向自动扩展添加扩展策略。扩展策略用于控制 OpenShift Container Platform 横向自动扩展(HPA)如何扩展 pod。扩展策略允许您通过设置在指定时间段内扩展的特定数量或特定百分比来限制 HPA 扩展或缩减的速率。您还可以定义一个稳定化窗口(stabilization window),在指标有较大波动时,使用之前计算出的期望状态来控制扩展。您可以为相同的扩展方向创建多个策略,并根据更改的大小决定使用哪些策略。您还可以通过计时的迭代限制缩放。HPA 在迭代过程中扩展 pod,然后在以后的迭代中执行扩展(如果需要)。
带有扩展策略的 HPA 对象示例
- 1
- 指定扩展策略的方向,可以是
scaleDown或scaleUp。本例为缩减创建一个策略。 - 2
- 定义扩展策略。
- 3
- 决定策略是否在每次迭代过程中根据特定的 pod 数量或 pod 百分比进行扩展。默认值为
pod。 - 4
- 在每次迭代过程中缩放数量(pod 数量或 pod 的百分比)的限制。在按 pod 数量进行缩减时没有默认的值。
- 5
- 决定扩展迭代的长度。默认值为
15秒。 - 6
- 按百分比缩减的默认值为 100%。
- 7
- 如果定义了多个策略,则决定首先使用哪个策略。指定
Max使用允许最多更改的策略,Min使用允许最小更改的策略,或者Disabled阻止 HPA 在策略方向进行扩展。默认值为Max。 - 8
- 决定 HPA 应该重新查看所需状态的时间周期。默认值为
0。 - 9
- 本例为扩展创建了策略。
- 10
- 扩展数量的限制(按 pod 的数量)。扩展 pod 数量的默认值为 4%。
- 11
- 扩展数量的限制(按 pod 的百分比)。按百分比扩展的默认值为 100%。
缩减策略示例
在本例中,当 pod 的数量大于 40 时,则使用基于百分比的策略进行缩减。这个策略会产生较大变化,这是 selectPolicy 需要的。
如果有 80 个 pod 副本,在第一次迭代时 HPA 会将 pod 减少 8 个,即 80 个 pod 的 10%(根据 type: Percent 和 value: 10 参数),持续一分钟(periodSeconds: 60)。对于下一个迭代,pod 的数量为 72。HPA 计算剩余 pod 的 10% 为 7.2,这个数值被舍入到 8,这会缩减 8 个 pod。在每一后续迭代中,将根据剩余的 pod 数量重新计算要缩放的 pod 数量。当 pod 的数量低于 40 时,基于 pod 的策略会被应用,因为基于 pod 的数值会大于基于百分比的数值。HPA 每次减少 4 个 pod(type: Pod 和 value: 4),持续 30 秒(periodSeconds: 30),直到剩余 20 个副本(minReplicas)。
selectPolicy: Disabled 参数可防止 HPA 扩展 pod。如果需要,可以通过调整副本集或部署集中的副本数来手动扩展。
如果设置,您可以使用 oc edit 命令查看扩展策略:
oc edit hpa hpa-resource-metrics-memory
$ oc edit hpa hpa-resource-metrics-memory
输出示例
2.4.5. 使用 Web 控制台创建 pod 横向自动扩展 复制链接链接已复制到粘贴板!
在 web 控制台中,您可以创建一个 pod 横向自动扩展(HPA),用于指定要在 Deployment 或 DeploymentConfig 对象上运行的 pod 的最小和最大数量。您还可以定义 pod 的目标 CPU 或内存用量。
HPA 不能添加到作为 Operator 支持服务、Knative 服务或 Helm chart 一部分的部署中。
流程
在 web 控制台中创建 HPA:
- 在 Topology 视图中,点击节点公开侧面板。
在 Actions 下拉列表中,选择 Add HorizontalPodAutoscaler 来打开 Add HorizontalPodAutoscaler 表单。
图 2.2. 添加 HorizontalPodAutoscaler
在 Add HorizontalPodAutoscaler 表单中,定义名称、最小和最大 pod 限值、CPU 和内存用量,并点 Save。
注意如果缺少 CPU 和内存用量的值,则会显示警告。
在 web 控制台中编辑 HPA:
- 在 Topology 视图中,点击节点公开侧面板。
- 在 Actions 下拉列表中,选择 Edit HorizontalPodAutoscaler 来打开 Edit Horizontal Pod Autoscaler 表单。
- 在 Edit Horizontal Pod Autoscaler 表单中,编辑最小和最大 pod 限值以及 CPU 和内存用量,然后点 Save。
在 web 控制台中创建或编辑 pod 横向自动扩展时,您可以从 Form 视图切换到 YAML 视图。
在 web 控制台中删除 HPA:
- 在 Topology 视图中,点击节点公开侧面板。
- 在 Actions 下拉列表中,选择 Remove HorizontalPodAutoscaler。
- 在确认弹出窗口中点击 Remove 删除 HPA。
2.4.6. 使用 CLI 根据 CPU 使用率创建 pod 横向自动扩展 复制链接链接已复制到粘贴板!
使用 OpenShift Container Platform CLI,您可以创建一个 pod 横向自动扩展(HPA)来自动扩展现有的 Deployment、DeploymentConfig、ReplicaSet、ReplicationController 或 StatefulSet 对象。HPA 扩展与该对象关联的 pod,以维护您指定的 CPU 用量。
除非需要特定功能或由其他对象提供的行为,否则建议使用 Deployment 对象或 ReplicaSet 对象。
HPA 会在最小和最大数量之间增加和减少副本数,以保持所有 pod 的指定 CPU 使用率。
为 CPU 使用率自动扩展时,您可以使用 oc autoscale 命令,并指定要在任意给定时间运行的 pod 的最小和最大数量,以及 pod 的目标平均 CPU 使用率。如果未指定最小值,则 OpenShift Container Platform 服务器会为 pod 赋予一个默认值。
要自动缩放特定 CPU 值,创建一个带有目标 CPU 和 pod 限制的 HorizontalPodAutoscaler 对象。
先决条件
要使用 pod 横向自动扩展,您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标,输出类似于以下示例,其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
输出示例
流程
为 CPU 使用率创建 pod 横向自动扩展:
执行以下之一:
要根据 CPU 使用率百分比来缩放,请为现有对象创建一个
HorizontalPodAutoscaler对象:oc autoscale <object_type>/<name> \ --min <number> \ --max <number> \ --cpu-percent=<percent>
$ oc autoscale <object_type>/<name> \1 --min <number> \2 --max <number> \3 --cpu-percent=<percent>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如,以下命令显示
image-registryDeployment对象的自动扩展。初始部署需要 3 个 pod。HPA 对象将最小值增加到 5。如果 pod 的 CPU 用量达到 75%,pod 将增加到 7:oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75
$ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要扩展特定 CPU 值,请为现有对象创建类似如下的 YAML 文件:
创建一个类似以下示例的 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本:
-
对于
Deployment,ReplicaSet、Statefulset对象,使用apps/v1。 -
对于
ReplicationController,使用v1。 -
对于
DeploymentConfig,使用apps.openshift.io/v1。
-
对于
- 4
- 指定对象类型。对象需要是
Deployment,DeploymentConfig/dc,ReplicaSet/rs,ReplicationController/rc, 或StatefulSet. - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率,使用
metrics参数。 - 9
- 为 CPU 使用率指定
cpu。 - 10
- 设置为
AverageValue。 - 11
- 使用目标 CPU 值设置为
averageValue。
创建 Pod 横向自动扩展:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 pod 横向自动扩展是否已创建:
oc get hpa cpu-autoscale
$ oc get hpa cpu-autoscaleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE cpu-autoscale Deployment/example 173m/500m 1 10 1 20m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE cpu-autoscale Deployment/example 173m/500m 1 10 1 20mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.7. 使用 CLI 根据内存使用率创建 pod 横向自动扩展对象 复制链接链接已复制到粘贴板!
使用 OpenShift Container Platform CLI,您可以创建一个 pod 横向自动扩展(HPA)来自动扩展现有的 Deployment、DeploymentConfig、ReplicaSet、ReplicationController 或 StatefulSet 对象。HPA 扩展与该对象关联的 pod,以维护您指定的平均内存使用率(可以是直接值,也可以是请求的内存百分比)。
除非需要特定功能或由其他对象提供的行为,否则建议使用 Deployment 对象或 ReplicaSet 对象。
HPA 增加和减少最小和最大数量之间的副本数量,以维护所有 pod 的指定内存使用率。
对于内存使用率,您可以指定 pod 的最小和最大数量,以及 pod 的目标平均内存使用率。如果未指定最小值,则 OpenShift Container Platform 服务器会为 pod 赋予一个默认值。
先决条件
要使用 pod 横向自动扩展,您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标,输出类似于以下示例,其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler
输出示例
流程
根据内存使用率创建 pod 横向自动扩展:
为以下之一创建一个 YAML 文件:
要扩展特定内存值,请为现有对象创建类似如下的
HorizontalPodAutoscaler对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本:
-
对于
Deployment、ReplicaSet或Statefulset对象,请使用apps/v1。 -
对于
ReplicationController,使用v1。 -
对于
DeploymentConfig,使用apps.openshift.io/v1。
-
对于
- 4
- 指定对象类型。对象必须是
Deployment、DeploymentConfig、ReplicaSet、ReplicationController或StatefulSet。 - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率,使用
metrics参数。 - 9
- 为内存使用率指定
memory。 - 10
- 将类型设置为
AverageValue。 - 11
- 指定
averageValue和一个特定的内存值。 - 12
- 可选:指定一个扩展策略来控制扩展或缩减率。
要缩放一个百分比,请为现有对象创建一个类似如下的
HorizontalPodAutoscaler对象:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本:
-
对于 ReplicationController,使用
v1。 -
对于 DeploymentConfig,使用
apps.openshift.io/v1。 -
对于 Deployment、ReplicaSet 和 Statefulset 对象,使用
apps/v1。
-
对于 ReplicationController,使用
- 4
- 指定对象类型。对象必须是
Deployment、DeploymentConfig、ReplicaSet、ReplicationController或StatefulSet。 - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率,使用
metrics参数。 - 9
- 为内存使用率指定
memory。 - 10
- 设置
Utilization。 - 11
- 为所有 pod 指定
averageUtilization和一个目标平均内存利用率,以请求内存的百分比表示。目标 pod 必须配置内存请求。 - 12
- 可选:指定一个扩展策略来控制扩展或缩减率。
创建 Pod 横向自动扩展:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc create -f hpa.yaml
$ oc create -f hpa.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created
horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 pod 横向自动扩展是否已创建:
oc get hpa hpa-resource-metrics-memory
$ oc get hpa hpa-resource-metrics-memoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-resource-metrics-memory Deployment/example 2441216/500Mi 1 10 1 20m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-resource-metrics-memory Deployment/example 2441216/500Mi 1 10 1 20mCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe hpa hpa-resource-metrics-memory
$ oc describe hpa hpa-resource-metrics-memoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.8. 使用 CLI 了解 pod 横向自动扩展状态条件 复制链接链接已复制到粘贴板!
您可以使用设置的状态条件来判断 pod 横向自动扩展 (HPA) 是否能够缩放,以及目前是否受到某种方式的限制。
HPA 状态条件可通过 v2 版的自动扩展 API 使用。
HPA 可以通过下列状态条件给予响应:
AbleToScale条件指示 HPA 是否能够获取和更新指标,以及是否有任何与退避相关的条件阻碍了缩放。-
True条件表示允许缩放。 -
False条件表示因为指定原因不允许缩放。
-
ScalingActive条件指示 HPA 是否已启用(例如,目标的副本数不为零),并且可以计算所需的指标。-
True条件表示指标工作正常。 -
False条件通常表示获取指标时出现问题。
-
ScalingLimited条件表示所需的规模由 pod 横向自动扩展限定最大或最小限制。-
True条件表示您需要提高或降低最小或最大副本数才能进行缩放。 False条件表示允许请求的缩放。oc describe hpa cm-test
$ oc describe hpa cm-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- pod 横向自动扩展状态消息。
-
下例中是一个无法缩放的 pod:
输出示例
下例中是一个无法获得缩放所需指标的 pod:
输出示例
Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
下例中是一个请求的自动缩放低于所需下限的 pod:
输出示例
2.4.8.1. 使用 CLI 查看 pod 横向自动扩展状态条件 复制链接链接已复制到粘贴板!
您可以查看 pod 横向自动扩展 (HPA) 对 pod 设置的状态条件。
pod 横向自动扩展状态条件可通过 v2 版本的自动扩展 API 使用。
先决条件
要使用 pod 横向自动扩展,您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标,输出类似于以下示例,其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
输出示例
流程
要查看 pod 上的状态条件,请使用以下命令并提供 pod 的名称:
oc describe hpa <pod-name>
$ oc describe hpa <pod-name>
例如:
oc describe hpa cm-test
$ oc describe hpa cm-test
这些条件会出现在输出中的 Conditions 字段里。
输出示例
2.5. 使用垂直 pod 自动扩展自动调整 pod 资源级别 复制链接链接已复制到粘贴板!
OpenShift Container Platform Vertical Pod Autoscaler Operator(VPA)会自动检查 pod 中容器的运行状况和当前的 CPU 和内存资源,并根据它所了解的用量值更新资源限值和请求。VPA 使用单独的自定义资源(CR)来更新与工作负载对象关联的所有 Pod,如 Deployment、Deployment Config、StatefulSet、Job、DaemonSet、ReplicaSet 或 ReplicationController。
VPA 可帮助您了解 Pod 的最佳 CPU 和内存使用情况,并可以通过 pod 生命周期自动维护 pod 资源。
2.5.1. 关于 Vertical Pod Autoscaler Operator 复制链接链接已复制到粘贴板!
Vertical Pod Autoscaler Operator(VPA)作为 API 资源和自定义资源(CR)实现。CR 决定 VPA Operator 对与特定工作负载对象(如守护进程集、复制控制器等)关联的 pod 执行的操作。
VPA Operator 由三个组件组成,每个组件在 VPA 命名空间中都有自己的 pod:
- Recommender
- VPA recommender 监控当前和过去的资源消耗,并根据这些数据决定关联工作负载对象中的 pod 的最佳 CPU 和内存资源。
- Updater
- VPA updater 检查相关工作负载对象中的 pod 是否具有正确的资源。如果资源正确,则 updater 不执行任何操作。如果资源不正确,则 updater 会终止 pod,以便它们的控制器可以使用更新的请求重新创建它们。
- 准入控制器
- VPA 准入控制器在关联的工作负载对象中的每个新 pod 上设置正确的资源请求,无论 pod 是新的,还是因为 VPA updater 的操作由它的控制器重新创建的。
您可以使用默认推荐程序,或使用您自己的备选推荐程序根据您自己的算法自动扩展。
默认推荐器会自动计算这些 pod 中容器的流程以及当前的 CPU 和内存使用情况,并使用这些数据来决定优化的资源限制和请求,以确保这些 pod 始终高效操作。例如,默认推荐器会建议,减少请求资源超过使用资源的 pod 的资源,并为没有请求充足资源的 pod 增加资源。
VPA 每次自动删除任何与建议不兼容的 pod,以便您的应用程序可以在不需要停机的情况下继续满足请求。然后,工作负载对象使用原始资源限制和请求重新部署 pod。VPA 使用一个变异准入 webhook 来更新 pod,在 pod 被允许到节点前,具有优化的资源限制和请求。如果您不希望 VPA 删除 pod,可以查看 VPA 资源限制和请求,并根据需要手动更新 pod。
默认情况下,工作负载对象必须至少指定两个副本,以便 VPA 自动删除其 pod。指定了比这个最小值更少的副本数的工作负载对象不会被删除。如果您手动删除这些 pod,当工作负载对象重新部署 pod 时,VPA 会使用其建议更新新的 pod。您可以通过修改 VerticalPodAutoscalerController 对象来更改这个最小值,如更改 VPA 最小值所示。
例如,您有一个 pod 使用了 CPU 的 50%,但只请求 10%。VPA 会认定该 pod 消耗的 CPU 多于请求的 CPU,并删除 pod。工作负载对象(如副本集)会重启 pod,VPA 使用推荐的资源更新新 pod。
对于开发人员,您可以使用 VPA 来帮助确保 pod 在高负载时可以继续工作,具体方法是将 pod 调度到每个 pod 具有适当资源的节点上。
管理员可以使用 VPA 来更好地利用集群资源,例如防止 pod 保留比所需的 CPU 资源更多的资源。VPA 监控实际使用的工作负载,并对资源进行调整,以确保可以满足其他工作负载的需要。VPA 还维护初始容器配置中指定的限值和请求之间的比例。
如果您停止在集群中运行 VPA,或删除特定的 VPA CR,则已由 VPA 修改的 pod 的资源请求不会改变。任何新 pod 都会根据工作负载对象中的定义获得资源,而不是之前由 VPA 提供的的建议。
2.5.2. 安装 Vertical Pod Autoscaler Operator 复制链接链接已复制到粘贴板!
您可以使用 OpenShift Container Platform web 控制台安装 Vertical Pod Autoscaler Operator(VPA)。
流程
- 在 OpenShift Container Platform Web 控制台中,点击 Operators → OperatorHub。
- 从可用 Operator 列表中选择 VerticalPodAutoscaler,点 Install。
-
在 Install Operator 页面中,确保选择了 Operator 推荐的命名空间 选项。这会在
openshift-vertical-pod-autoscaler命名空间中创建 Operator。如果这个命名空间还没有存在,会自动创建它。 - 点 Install。
验证
列出 VPA Operator 组件来验证安装:
- 导航到 Workloads → Pods。
-
从下拉菜单中选择
openshift-vertical-pod-autoscaler项目,并验证是否运行了四个 pod。 - 进入 Workloads → Deployments 以验证运行了四个部署。
可选:使用以下命令在 OpenShift Container Platform CLI 中验证安装:
oc get all -n openshift-vertical-pod-autoscaler
$ oc get all -n openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示四个 pod 和四个部署:
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3. 移动 Vertical Pod Autoscaler Operator 组件 复制链接链接已复制到粘贴板!
Vertical Pod Autoscaler Operator (VPA),每个组件在 control plane 节点上的 VPA 命名空间中都有自己的 pod。您可以通过在 VPA 订阅和 VerticalPodAutoscalerController CR 中添加节点选择器,将 VPA Operator 和组件 pod 移到基础架构节点。
您可以创建并使用基础架构节点来创建仅托管基础架构组件的机器,如默认路由器、集成的容器镜像 registry 以及集群指标和监控的组件。这些基础架构节点不计入运行环境所需的订阅总数中。如需更多信息,请参阅创建基础架构机器集。
您可以根据您的机构,将组件移到同一节点或单独的节点。
以下示例显示了 VPA pod 到 control plane 节点的默认部署。
输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-master-1 <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-master-1 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-master-0 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-master-1 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-master-1 <none> <none>
vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-master-1 <none> <none>
vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-master-0 <none> <none>
vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-master-1 <none> <none>
流程
通过将节点选择器添加到 VPA Operator 的
Subscription自定义资源 (CR)中来移动 VPA Operator pod:编辑 CR:
oc edit Subscription vertical-pod-autoscaler -n openshift-vertical-pod-autoscaler
$ oc edit Subscription vertical-pod-autoscaler -n openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加节点选择器以匹配您要安装 VPA Operator pod 的节点上的节点角色标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果 infra 节点使用污点,则需要为
SubscriptionCR 添加容限。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在要移动 VPA Operator pod 的节点上为污点指定容限。
通过将节点选择器添加到
VerticalPodAutoscaler自定义资源 (CR) 来移动每个 VPA 组件:编辑 CR:
oc edit VerticalPodAutoscalerController default -n openshift-vertical-pod-autoscaler
$ oc edit VerticalPodAutoscalerController default -n openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加节点选择器以匹配您要安装 VPA 组件的节点上的节点角色标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果目标节点使用污点,则需要为
VerticalPodAutoscalerControllerCR 添加容限。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
您可以使用以下命令验证 pod 是否已移动:
oc get pods -n openshift-vertical-pod-autoscaler -o wide
$ oc get pods -n openshift-vertical-pod-autoscaler -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod 不再部署到 control plane 节点。
输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-infra-eastus3-2bndt <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-infra-eastus1-lrgj8 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-infra-eastus3-2bndt <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-infra-eastus1-lrgj8 <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
其他资源
2.5.4. 关于使用 Vertical Pod Autoscaler Operator 复制链接链接已复制到粘贴板!
要使用 Vertical Pod Autoscaler Operator(vpa),您需要为集群中的工作负载对象创建 VPA 自定义资源(CR)。VPA 学习并应用与该工作负载对象关联的 pod 的最佳 CPU 和内存资源。您可以使用 VPA 与部署、有状态集、作业、守护进程集、副本集或复制控制器工作负载对象一起使用。VPA CR 必须与您要监控的 pod 位于同一个项目中。
您可以使用 VPA CR 关联一个工作负载对象,并指定 VPA 使用什么模式运行:
-
Auto和Recreate模式会在 pod 生命周期内自动应用 VPA 对 CPU 和内存建议。VPA 会删除项目中任何与建议不兼容的 pod。当由工作负载对象重新部署时,VPA 会在其建议中更新新 pod。 -
Initial模式仅在创建 pod 时自动应用 VPA 建议。 -
Off模式只提供推荐的资源限制和请求信息,用户可以手动应用其中的建议。off模式不会更新 pod。
您还可以使用 CR 使特定容器不受 VPA 评估和更新的影响。
例如,pod 具有以下限制和请求:
在创建了一个设置为 auto 的 VPA 后,VPA 会了解资源使用情况并删除 pod。重新部署时,pod 会使用新的资源限值和请求:
您可以使用以下命令查看 VPA 建议:
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml
几分钟后,输出显示 CPU 和内存请求的建议,如下所示:
输出示例
输出显示推荐的资源、目标、最低推荐资源、lowerBound、最高推荐资源、upperBound、以及最新资源建议和 uncappedTarget。
VPA 使用 lessBound 和 upperBound 值来确定一个 pod 是否需要更新。如果 pod 的资源请求低于 lowerBound 值,或高于 upperBound 值,则 VPA 会终止 pod,并使用 target 值重新创建 pod。
2.5.4.1. 更改 VPA 最小值 复制链接链接已复制到粘贴板!
默认情况下,工作负载对象必须至少指定两个副本,以便 VPA 自动删除和更新其 pod。因此,VPA 不会自动执行指定少于两个副本的工作负载对象。如果 pod 由 VPA 外部的一些进程重启,VPA 会从这些工作负载对象更新的新 pod。您可以通过修改 VerticalPodAutoscalerController 自定义资源(CR)中的 minReplicas 参数来更改此集群范围的最小值。
例如,如果您将 minReplicas 设置为 3,则 VPA 不会为指定少于三个副本的工作负载对象删除和更新 pod。
如果将 minReplicas 设置为 1,则 VPA 可以为只指定一个副本的工作负载对象删除唯一的 pod。只有在 VPA 删除 pod 以调整其资源时,您的工作负载可以允许停机时,才应使用此设置来使用一个副本对象。为了避免使用一个副本的对象出现不必要的停机时间,将带有 podUpdatePolicy 设置的 VPA CR 配置为 Initial,这只有在 VPA 外部的一些进程重启时,或状态为 Off 时才重启。这可让您在适合的时间手动更新 pod。
VerticalPodAutoscalerController 对象示例
- 1
- 指定 VPA 中要操作的工作负载对象中的最小副本数。VPA 不会自动删除任何小于最小副本的对象。
2.5.4.2. 自动应用 VPA 建议 复制链接链接已复制到粘贴板!
要使用 VPA 来自动更新 pod,为特定工作负载对象创建一个 VPA CR,并将 updateMode 设置为 Auto 或 Recreate。
当为工作复杂对象创建 pod 时,VPA 会持续监控容器以分析其 CPU 和内存需求。VPA 会删除任何不满足 VPA 对 CPU 和内存的建议的 pod。重新部署后,pod 根据 VPA 建议使用新的资源限值和请求,并遵循您的应用程序的 pod 中断预算。建议被添加到 VPA CR 的 status 字段中以进行引用。
默认情况下,工作负载对象必须至少指定两个副本,以便 VPA 自动删除其 pod。指定了比这个最小值更少的副本数的工作负载对象不会被删除。如果您手动删除这些 pod,当工作负载对象重新部署 pod 时,VPA 会使用其建议更新新的 pod。您可以通过修改 VerticalPodAutoscalerController 对象来更改这个最小值,如更改 VPA 最小值所示。
Auto 模式的 VPA CR 示例
在 VPA 可以决定资源建议并将推荐的资源应用到新 pod 之前,操作 pod 必须存在并在项目中运行。
如果工作负载的资源使用情况(如 CPU 和内存)一致,VPA 可以在几分钟内决定资源的建议。如果工作负载的资源使用情况不一致,VPA 必须以各种资源使用量间隔收集指标,以便 VPA 做出准确的建议。
2.5.4.3. 在创建 pod 时自动应用 VPA 建议 复制链接链接已复制到粘贴板!
要仅在 pod 首次部署时使用 VPA 来应用推荐的资源,为特定的工作负载对象创建一个 VPA CR,将 updateMode 设置为 Initial。
然后,手动删除与您要使用 VPA 建议的工作负载对象关联的 pod。在 Initial 模式中,VPA 不会删除 pod,也不会更新 pod,它会学习新的资源建议。
Initial 模式的 VPA CR 示例
在 VPA 可以决定推荐的资源并对新 pod 应用建议之前,操作 pod 必须存在并在项目中运行。
要从 VPA 获取最准确的建议,请至少等待 8 天,让 pod 运行以及 VPA 稳定。
2.5.4.4. 手动应用 VPA 建议 复制链接链接已复制到粘贴板!
要使用 VPA 来仅决定推荐的 CPU 和内存值而不进行实际的应用,对特定的工作负载创建一个 VPA CR,把 updateMode 设置为 off。
当为该工作负载对象创建 pod 时, VPA 会分析容器的 CPU 和内存需求,并在 VPA CR 的 status 字段中记录推荐。VPA 会提供新的资源建议,但不会更新 pod。
使用 Off 模式的 VPA CR 示例
您可以使用以下命令查看建议。
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml
根据建议,您可以编辑工作负载对象以添加 CPU 和内存请求,然后删除 pod 并使用推荐的资源重新部署 pod。
在 VPA 可以决定推荐的资源并对新 pod 应用建议之前,操作 pod 必须存在并在项目中运行。
要从 VPA 获取最准确的建议,请至少等待 8 天,让 pod 运行以及 VPA 稳定。
2.5.4.5. 阻止容器特定容器应用 VPA 建议 复制链接链接已复制到粘贴板!
如果您的工作负载对象有多个容器,且您不希望 VPA 对所有容器进行评估并进行操作,请为特定工作负载对象创建一个 VPA CR,添加一个 resourcePolicy 已使特定容器不受 VPA 的影响。
当 VPA 使用推荐的资源更新 pod 时,任何带有 resourcePolicy 的容器都不会被更新,且 VPA 不会对这些 pod 中的容器提供建议。
例如,一个 pod 有两个容器,它们有相同的资源请求和限值:
在启用一个带有 backend 排除容器设置的 VPA CR 后,VPA 终止并使用推荐的资源重新创建 pod 的行为只适用于 frontend 容器:
2.5.4.6. 性能调优 VPA Operator 复制链接链接已复制到粘贴板!
作为集群管理员,您可以调整 Vertical Pod Autoscaler Operator (VPA) 的性能,以限制 VPA 对 Kubernetes API 服务器发出请求的速率,并为 VPA recommender, updater 和准入控制器组件 pod 指定 CPU 和内存资源。
另外,您可以将 VPA Operator 配置为仅监控由 VPA 自定义资源 (CR) 管理的工作负载。默认情况下,VPA Operator 会监控集群中的所有工作负载。这允许 VPA Operator 为所有工作负载处理和存储 8 天的历史数据,如果为工作负载创建新的 VPA CR,Operator 可以使用该数据。但是,这会导致 VPA Operator 使用大量 CPU 和内存,这可能会导致 Operator 失败,特别是在大型集群中。通过将 VPA Operator 配置为仅监控 VPA CR 的工作负载,您可以在 CPU 和内存资源上保存。一个权衡方案是,如果您有一个运行的工作负载,并且创建一个 VPA CR 来管理那个工作负载,则 VPA Operator 没有该工作负载的历史数据。因此,在工作负载运行了一段时间后,初始建议并没有这些有用。
这些调整允许您确保 VPA 有足够资源以峰值效率运行,并防止 pod 准入中的节流和可能的延迟。
您可以通过编辑 VerticalPodAutoscalerController 自定义资源 (CR) 在 VPA 组件上执行以下调整:
-
要防止节流和 pod 准入延迟,使用
kube-api-qps和kube-api-burst参数为 Kubernetes API 服务器的 VPA 请求设置 queries-per-second (QPS) 和突发率。 -
为确保足够的 CPU 和内存,请使用标准
cpu和memory资源请求为 VPA 组件 pod 设置 CPU 和内存请求。 -
要将 VPA Operator 配置为仅监控由 VPA CR 管理的工作负载,请将 recommender 组件的
memory-saver参数设置为true。
以下示例 VPA 控制器 CR 设置 VPA API QPS 和突发(burts)率,配置组件 pod 资源请求,并为 recommender 将 memory-saver 设置为 true :
示例 VerticalPodAutoscalerController CR
您可以验证设置是否已应用到每个 VPA 组件 pod。
updater pod 示例
准入控制器 pod 示例
recommender pod 示例
2.5.4.7. 使用一个替代推荐器 复制链接链接已复制到粘贴板!
您可以根据自己的算法使用自己的推荐器来自动扩展。如果您没有指定替代的推荐器,OpenShift Container Platform 会使用默认的推荐器,它会根据历史使用情况推荐 CPU 和内存请求。因为没有适用于所有工作负载的通用推荐策略,您可能需要为特定工作负载创建和部署不同的推荐器。
例如,当容器出现某些资源行为时,默认的推荐器可能无法准确预测将来的资源使用量,例如,在监控应用程序使用的使用量高峰和闲置间交替的模式,或者重复与深度学习应用程序使用的模式。将默认推荐器用于这些使用行为可能会导致应用程序的过度置备和内存不足(OOM)终止。
有关如何创建推荐器的说明超出了本文档的范围,
流程
为 pod 使用替代推荐器:
为替代推荐器创建服务帐户,并将该服务帐户绑定到所需的集群角色:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要在集群中添加备选推荐程序,请创建一个类似如下的 Deployment 对象:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为同一命名空间中的备选推荐器创建新 pod。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE frontend-845d5478d-558zf 1/1 Running 0 4m25s frontend-845d5478d-7z9gx 1/1 Running 0 4m25s frontend-845d5478d-b7l4j 1/1 Running 0 4m25s vpa-alt-recommender-55878867f9-6tp5v 1/1 Running 0 9s
NAME READY STATUS RESTARTS AGE frontend-845d5478d-558zf 1/1 Running 0 4m25s frontend-845d5478d-7z9gx 1/1 Running 0 4m25s frontend-845d5478d-b7l4j 1/1 Running 0 4m25s vpa-alt-recommender-55878867f9-6tp5v 1/1 Running 0 9sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 配置包含替代推荐器
Deployment对象名称的 VPA CR。VPA CR 示例,使其包含替代的推荐程序
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.5. 使用 Vertical Pod Autoscaler Operator 复制链接链接已复制到粘贴板!
您可以通过创建 VPA 自定义资源(CR)来使用 Vertical Pod Autoscaler Operator(VPA)。CR 指明应分析哪些 pod,并决定 VPA 应该对这些 pod 执行的操作。
先决条件
- 要自动扩展的工作负载对象必须存在。
- 如果要使用替代的推荐器,则必须存在包括那个推进器的部署。
流程
为特定工作负载对象创建 VPA CR:
切换到您要缩放的工作负载对象所在的项目。
创建一个 VPA CR YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定您需要这个 VPA 管理的工作负载对象类型:
Deployment、StatefulSet、Job、DaemonSet、ReplicaSet或ReplicationController。 - 2
- 指定您希望此 VPA 管理的现有工作负载对象的名称。
- 3
- 指定 VPA 模式:
-
auto会在与控制器关联的 pod 上自动应用推荐的资源。VPA 会终止现有的 pod,并使用推荐的资源限制和请求创建新 pod。 -
recreate会在与工作负载对象关联的 pod 上自动应用推荐的资源。VPA 会终止现有的 pod,并使用推荐的资源限制和请求创建新 pod。recreate模式应该很少使用,只有在需要确保每当资源请求改变时 pod 就需要重启时才使用。 -
Initial在创建与工作负载对象关联的 pod 时自动应用推荐的资源。VPA 会学习新的资源建议,但不会更新 pod。 -
off仅为与工作负载对象关联的 pod 生成资源建议。VPA 不会更新 pod,它只会学习新的资源建议,且不会将建议应用到新 pod。
-
- 4
- 可选。指定不需要受 VPA 影响的容器,将模式设置为
Off。 - 5
- 可选。指定替代的推荐器。
创建 VPA CR:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在一段短暂的时间后,VPA 会了解与工作负载对象关联的 pod 中容器的资源使用情况。
您可以使用以下命令查看 VPA 建议:
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示 CPU 和内存请求的建议,如下所示:
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.6. 卸载 Vertical Pod Autoscaler Operator 复制链接链接已复制到粘贴板!
您可以从 OpenShift Container Platform 集群中删除 Vertical Pod Autoscaler Operator(VPA)。卸载后,已由现有 VPA CR 修改的 pod 的资源请求不会改变。任何新 pod 都会根据工作负载对象中的定义获得资源,而不是之前由 VPA 提供的的建议。
您可以使用 oc delete vpa <vpa-name> 命令删除特定的 VPA CR。在卸载垂直 pod 自动扩展时,同样的操作适用于资源请求。
删除 VPA Operator 后,建议您删除与 Operator 相关的其他组件,以避免潜在的问题。
先决条件
- 已安装 Vertical Pod Autoscaler Operator。
流程
- 在 OpenShift Container Platform web 控制台中,点击 Operators → Installed Operators。
- 切换到 openshift-vertical-pod-autoscaler 项目。
-
对于 VerticalPodAutoscaler Operator,点 Options 菜单
并选择 Uninstall Operator。
- 可选: 要删除与 Operator 关联的所有操作对象,请在对话框中选择 Delete all operand instance for this operator 复选框。
- 点 Uninstall。
可选: 使用 OpenShift CLI 删除 VPA 组件:
删除 VPA 命名空间:
oc delete namespace openshift-vertical-pod-autoscaler
$ oc delete namespace openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 VPA 自定义资源定义 (CRD) 对象:
oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
$ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
$ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd verticalpodautoscalers.autoscaling.k8s.io
$ oc delete crd verticalpodautoscalers.autoscaling.k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 CRD 会删除关联的角色、集群角色和角色绑定。
注意此操作会从集群中移除,集群中的所有用户创建的 VPA CR。如果重新安装 VPA,您必须再次创建这些对象。
运行以下命令来删除
MutatingWebhookConfiguration对象:oc delete MutatingWebhookConfiguration vpa-webhook-config
$ oc delete MutatingWebhookConfiguration vpa-webhook-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 VPA Operator:
oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
$ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. 使用 secret 为 pod 提供敏感数据 复制链接链接已复制到粘贴板!
有些应用程序需要密码和用户名等敏感信息,但您不希望开发人员持有这些信息。
作为管理员,您可以使用 Secret 对象在不以明文方式公开的前提下提供此类信息。
2.6.1. 了解 secret 复制链接链接已复制到粘贴板!
Secret 对象类型提供了一种机制来保存敏感信息,如密码、OpenShift Container Platform 客户端配置文件和私有源存储库凭证等。secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中,系统也可以使用 secret 代表 Pod 执行操作。
主要属性包括:
- Secret 数据可以独立于其定义来引用。
- Secret 数据卷由临时文件工具 (tmpfs) 支持,永远不会停留在节点上。
- secret 数据可以在命名空间内共享。
YAML Secret 对象定义
您必须先创建 secret,然后创建依赖于此 secret 的 Pod。
在创建 secret 时:
- 使用 secret 数据创建 secret 对象。
- 更新 pod 的服务帐户以允许引用该 secret。
-
创建以环境变量或文件(使用
secret卷)形式消耗 secret 的 pod。
2.6.1.1. secret 的类型 复制链接链接已复制到粘贴板!
type 字段中的值指明 secret 的键名称和值的结构。此类型可用于强制使 secret 对象中存在用户名和密钥。如果您不想进行验证,请使用 opaque 类型,这也是默认类型。
指定以下一种类型来触发最小服务器端验证,确保 secret 数据中存在特定的键名称:
-
kubernetes.io/basic-auth:使用基本身份验证 -
kubernetes.io/dockercfg:用作镜像 pull secret -
kubernetes.io/dockerconfigjson: 用作镜像 pull secret -
kubernetes.io/service-account-token:用来获取旧的服务帐户 API 令牌 -
kubernetes.io/ssh-auth:与 SSH 密钥身份验证一起使用 -
kubernetes.io/tls:与 TLS 证书颁发机构一起使用
如果您不想要验证,请指定 type: Opaque,即 secret 没有声明键名称或值需要符合任何约定。opaque secret 允许使用无结构 key:value 对,可以包含任意值。
您可以指定其他任意类型,如 example.com/my-secret-type。这些类型不是在服务器端强制执行,而是表明 secret 的创建者意在符合该类型的键/值要求。
有关创建不同类型的 secret 的示例,请参阅 了解如何创建 secret。
2.6.1.2. Secret 数据密钥 复制链接链接已复制到粘贴板!
Secret 密钥必须在 DNS 子域中。
2.6.1.3. 自动生成的镜像 pull secret 复制链接链接已复制到粘贴板!
默认情况下,OpenShift Container Platform 为每个服务帐户创建一个镜像 pull secret。
在 OpenShift Container Platform 4.16 之前,还会为创建的每个服务帐户生成长期服务帐户 API 令牌 secret。从 OpenShift Container Platform 4.16 开始,不再创建此服务帐户 API 令牌 secret。
升级到 4.17 后,任何现有的长期服务帐户 API 令牌 secret 都不会被删除,并将继续正常工作。有关检测集群中使用的长期 API 令牌,以及在不需要时删除它们的信息,请参阅红帽知识库文章 OpenShift Container Platform 中的 Long-lived 服务帐户 API 令牌。
此镜像 pull secret 需要将 OpenShift 镜像 registry 集成到集群的用户身份验证和授权系统中。
但是,如果您不启用 ImageRegistry 功能,或者在 Cluster Image Registry Operator 配置中禁用集成的 OpenShift 镜像 registry,则不会为每个服务帐户生成镜像 pull secret。
当在之前启用的集群中禁用集成的 OpenShift 镜像 registry 时,之前生成的镜像 pull secret 会被自动删除。
2.6.2. 了解如何创建 secret 复制链接链接已复制到粘贴板!
作为管理员,您必须先创建 secret,然后开发人员才能创建依赖于该 secret 的 pod。
在创建 secret 时:
创建包含您要保留 secret 的数据的 secret 对象。在以下部分中取消每个 secret 类型所需的特定数据。
创建不透明 secret 的 YAML 对象示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
data或stringdata字段,不能同时使用这两个字段。更新 pod 的服务帐户以引用 secret:
使用 secret 的服务帐户的 YAML
apiVersion: v1 kind: ServiceAccount ... secrets: - name: test-secret
apiVersion: v1 kind: ServiceAccount ... secrets: - name: test-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以环境变量或文件(使用
secret卷)形式消耗 secret 的 pod:pod 的 YAML 使用 secret 数据填充卷中的文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod 的 YAML 使用 secret 数据填充环境变量
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定消耗 secret 密钥的环境变量。
构建配置的 YAML 使用 secret 数据填充环境变量
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定消耗 secret 密钥的环境变量。
2.6.2.1. Secret 创建限制 复制链接链接已复制到粘贴板!
若要使用 secret,pod 需要引用该 secret。可以通过三种方式将 secret 用于 Pod:
- 为容器产生环境变量。
- 作为挂载到一个或多个容器上的卷中的文件。
- 在拉取 Pod 的镜像时通过 kubelet 使用。
卷类型 secret 使用卷机制将数据作为文件写入到容器中。镜像拉取 secret 使用服务帐户,将 secret 自动注入到命名空间中的所有 pod。
当模板包含 secret 定义时,模板使用提供的 secret 的唯一方法是确保验证 secret 卷源通过验证,并且指定的对象引用实际指向 Secret 类型的对象。因此,secret 需要在依赖它的任何 Pod 之前创建。确保这一点的最有效方法是通过使用服务帐户自动注入。
Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。
每个 secret 的大小限制为 1MB。这是为了防止创建可能会耗尽 apiserver 和 kubelet 内存的大型 secret。不过,创建许多较小的 secret 也可能会耗尽内存。
2.6.2.2. 创建不透明 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个不透明 secret,它允许您存储包含任意值的无结构 key:value 对。
流程
在 YAML 文件中创建
Secret对象。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定不透明 secret。
使用以下命令来创建
Secret对象:oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret,如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件(使用 secret 卷)形式消耗
secret的 pod,如"创建 secret"部分所示。
2.6.2.3. 创建旧的服务帐户令牌 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个旧的服务帐户令牌 secret,该 secret 允许您将服务帐户令牌分发到必须通过 API 进行身份验证的应用程序。
建议您使用 TokenRequest API 获取绑定的服务帐户令牌,而不使用旧的服务帐户令牌 secret。只有在无法使用 TokenRequest API 且在可读的 API 对象中存在非过期令牌时,才应创建服务帐户令牌 secret。
绑定服务帐户令牌比服务帐户令牌 secret 更安全,原因如下:
- 绑定服务帐户令牌具有绑定的生命周期。
- 绑定服务帐户令牌包含受众。
- 绑定服务帐户令牌可以绑定到 pod 或 secret,绑定令牌在删除绑定对象时无效。
工作负载自动注入投射卷以获取绑定服务帐户令牌。如果您的工作负载需要额外的服务帐户令牌,请在工作负载清单中添加额外的投射卷。
如需更多信息,请参阅"使用卷投射配置绑定服务帐户令牌"。
流程
在 YAML 文件中创建
Secret对象:Secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象:oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret,如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件(使用 secret 卷)形式消耗
secret的 pod,如"创建 secret"部分所示。
2.6.2.4. 创建基本身份验证 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个基本身份验证 secret,该 secret 允许您存储基本身份验证所需的凭证。在使用此 secret 类型时,Secret 对象的 data 参数必须包含以下密钥,采用 base64 格式编码:
-
用户名:用于身份验证的用户名 -
密码:用于身份验证的密码或令牌
您可以使用 stringData 参数使用明文内容。
流程
在 YAML 文件中创建
Secret对象:secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象:oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret,如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件(使用 secret 卷)形式消耗
secret的 pod,如"创建 secret"部分所示。
2.6.2.5. 创建 SSH 身份验证 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个 SSH 验证 secret,该 secret 允许您存储用于 SSH 验证的数据。在使用此 secret 类型时,Secret 对象的 data 参数必须包含要使用的 SSH 凭证。
流程
在控制平面节点上的 YAML 文件中创建
Secret对象:secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象:oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret,如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件(使用 secret 卷)形式消耗
secret的 pod,如"创建 secret"部分所示。
2.6.2.6. 创建 Docker 配置 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个 Docker 配置 secret,该 secret 允许您存储用于访问容器镜像 registry 的凭证。
-
kubernetes.io/dockercfg。使用此机密类型存储本地 Docker 配置文件。secret对象的data参数必须包含以 base64 格式编码的.dockercfg文件的内容。 -
kubernetes.io/dockerconfigjson。使用此机密类型存储本地 Docker 配置 JSON 文件。secret对象的data参数必须包含以 base64 格式编码的.docker/config.json文件的内容。
流程
在 YAML 文件中创建
Secret对象。Docker 配置
secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker 配置 JSON
secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret,如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件(使用 secret 卷)形式消耗
secret的 pod,如"创建 secret"部分所示。
2.6.2.7. 使用 Web 控制台创建 secret 复制链接链接已复制到粘贴板!
您可以使用 Web 控制台创建 secret。
流程
- 导航到 Workloads → Secrets。
点 Create → From YAML。
- 点 Create。
点 Add Secret to workload。
- 从下拉菜单中选择要添加的工作负载。
- 点击 Save。
2.6.3. 了解如何更新 secret 复制链接链接已复制到粘贴板!
修改 secret 值时,值(由已在运行的 pod 使用)不会动态更改。若要更改 secret,您必须删除原始 pod 并创建一个新 pod(可能具有相同的 PodSpec)。
更新 secret 遵循与部署新容器镜像相同的工作流程。您可以使用 kubectl rolling-update 命令。
secret 中的 resourceVersion 值不在引用时指定。因此,如果在 pod 启动的同时更新 secret,则将不能定义用于 pod 的 secret 版本。
目前,无法检查 Pod 创建时使用的 secret 对象的资源版本。按照计划 Pod 将报告此信息,以便控制器可以重启使用旧 resourceVersion 的 Pod。在此期间,请勿更新现有 secret 的数据,而应创建具有不同名称的新数据。
2.6.4. 创建和使用 secret 复制链接链接已复制到粘贴板!
作为管理员,您可以创建一个服务帐户令牌 secret。这可让您将服务帐户令牌分发到必须通过 API 进行身份验证的应用程序。
流程
运行以下命令,在命名空间中创建服务帐户:
oc create sa <service_account_name> -n <your_namespace>
$ oc create sa <service_account_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将以下 YAML 示例保存到名为
service-account-token-secret.yaml的文件中。这个示例包括可用于生成服务帐户令牌的Secret对象配置:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过应用文件来生成服务帐户令牌:
oc apply -f service-account-token-secret.yaml
$ oc apply -f service-account-token-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,从 secret 获取服务帐户令牌:
oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode$ oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA
ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHACopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将 <sa_token_secret> 替换为服务帐户令牌 secret 的名称。
使用您的服务帐户令牌与集群的 API 进行身份验证:
curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>"
$ curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>"1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.5. 关于将签名证书与 secret 搭配使用 复制链接链接已复制到粘贴板!
若要与服务进行安全通信,您可以配置 OpenShift Container Platform,以生成一个签名的服务用证书/密钥对,再添加到项目中的 secret 里。
服务用证书 secret 旨在支持需要开箱即用证书的复杂中间件应用程序。它的设置与管理员工具为节点和 master 生成的服务器证书相同。
为服务用证书 secret 配置的服务 Pod 规格。
- 1
- 指定证书的名称
其他 pod 可以信任集群创建的证书(仅对内部 DNS 名称进行签名),方法是使用 pod 中自动挂载的 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 文件中的 CA 捆绑。
此功能的签名算法是 x509.SHA256WithRSA。要手动轮转,请删除生成的 secret。这会创建新的证书。
2.6.5.1. 生成签名证书以便与 secret 搭配使用 复制链接链接已复制到粘贴板!
要将签名的服务用证书/密钥对用于 pod,请创建或编辑服务以添加到 service.beta.openshift.io/serving-cert-secret-name 注解,然后将 secret 添加到该 pod。
流程
创建服务用证书 secret:
-
编辑服务的
Podspec。 使用您要用于 secret 的名称,添加
service.beta.openshift.io/serving-cert-secret-name注解。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 证书和密钥采用 PEM 格式,分别存储在
tls.crt和tls.key中。创建服务:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 secret 以确保已成功创建:
查看所有 secret 列表:
oc get secrets
$ oc get secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE DATA AGE my-cert kubernetes.io/tls 2 9m
NAME TYPE DATA AGE my-cert kubernetes.io/tls 2 9mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看您的 secret 详情:
oc describe secret my-cert
$ oc describe secret my-certCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
编辑与该 secret 搭配的
Podspec。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当它可用时,您的 Pod 就可运行。该证书对内部服务 DNS 名称
<service.name>.<service.namespace>.svc有效。证书/密钥对在接近到期时自动替换。在 secret 的
service.beta.openshift.io/expiry注解中查看过期日期,其格式为 RFC3339。注意在大多数情形中,服务 DNS 名称
<service.name>.<service.namespace>.svc不可从外部路由。<service.name>.<service.namespace>.svc的主要用途是集群内或服务内通信,也用于重新加密路由。
2.6.6. secret 故障排除 复制链接链接已复制到粘贴板!
如果服务证书生成失败并显示以下信息( 服务的 service.beta.openshift.io/serving-cert-generation-error 注解包含):
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
生成证书的服务不再存在,或者具有不同的 serviceUID 。您必须删除旧 secret 并清除服务上的以下注解 service.beta.openshift.io/serving-cert-generation-error, service.beta.openshift.io/serving-cert-generation-error-num 以强制重新生成证书:
删除 secret:
oc delete secret <secret_name>
$ oc delete secret <secret_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 清除注解:
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在用于移除注解的命令中,要移除的注解后面有一个 -。
2.7. 使用外部 secret 存储为 pod 提供敏感数据 复制链接链接已复制到粘贴板!
有些应用程序需要密码和用户名等敏感信息,但您不希望开发人员持有这些信息。
使用 Kubernetes Secret 对象提供敏感信息的一个替代选择是,使用外部 secret 存储来存储敏感信息。您可以使用 Secrets Store CSI Driver Operator 与外部 secret 存储集成,并将 secret 内容挂载为 pod 卷。
Secret Store CSI Driver Operator 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
2.7.1. 关于 Secret Store CSI Driver Operator 复制链接链接已复制到粘贴板!
Kubernetes secret 以 Base64 编码的形式存储。etcd 为这些 secret 提供加密,但在检索 secret 时,它们会被解密并提供给用户。如果没有在集群中正确配置基于角色的访问控制,则具有 API 或 etcd 访问权限的任何人都可以检索或修改 secret。另外,有权在命名空间中创建 pod 的任何人都可以使用该命名空间中的任何 secret 来读取该命名空间中的任何 secret。
要安全地存储和管理您的 secret,您可以将 OpenShift Container Platform Secrets Store Container Storage Interface (CSI) Driver Operator 配置为使用供应商插件从外部 secret 管理系统(如 Azure Key Vault)挂载 secret。应用程序可以使用 secret,但 secret 在应用程序 pod 被销毁后不会在系统中保留。
Secret Store CSI Driver Operator(secrets-store.csi.k8s.io)允许 OpenShift Container Platform 将存储在企业级外部 secret 中的多个 secret、密钥和证书作为卷挂载到 pod 中。Secrets Store CSI Driver Operator 使用 gRPC 与供应商通信,以从指定的外部 secret 存储获取挂载内容。附加卷后,其中的数据将挂载到容器的文件系统。Secret 存储卷以 in-line 形式挂载。
2.7.1.1. Secret 存储供应商 复制链接链接已复制到粘贴板!
以下 secret 存储供应商可用于 Secret Store CSI Driver Operator:
- AWS Secrets Manager
- AWS Systems Manager Parameter Store
- Azure Key Vault
- Google Secret Manager
- HashiCorp Vault
2.7.1.2. 自动轮转 复制链接链接已复制到粘贴板!
Secrets Store CSI 驱动程序会定期使用外部 secret 存储中的内容轮转挂载卷中的内容。如果外部 secret 存储中更新了 secret,secret 将在挂载的卷中更新。Secrets Store CSI Driver Operator 每 2 分钟轮询一次更新。
如果启用了将挂载内容作为 Kubernetes secret 同步,则 Kubernetes secret 也会被轮转。
使用 secret 数据的应用程序必须监视是否有对 secret 的更新。
2.7.2. 安装 Secret Store CSI 驱动程序 复制链接链接已复制到粘贴板!
先决条件
- 访问 OpenShift Container Platform Web 控制台。
- 集群的管理员访问权限。
流程
安装 Secret Store CSI 驱动程序:
安装 Secret Store CSI Driver Operator:
- 登录到 web 控制台。
- 点 Operators → OperatorHub。
- 通过在过滤器框中输入 "Secrets Store CSI" 来查找 Secrets Store CSI Driver Operator。
- 点 Secrets Store CSI Driver Operator 按钮。
- 在 Secrets Store CSI Driver Operator 页面中,点 Install。
在 Install Operator 页面中,确保:
- 选择 All namespaces on the cluster (default)。
- 安装的命名空间 被设置为 openshift-cluster-csi-drivers。
点 Install。
安装完成后,Secret Store CSI Driver Operator 会在 web 控制台的 Installed Operators 部分列出。
为驱动程序创建
ClusterCSIDriver实例 (secrets-store.csi.k8s.io):- 点 Administration → CustomResourceDefinitions → ClusterCSIDriver。
在 Instances 选项卡上,单击 Create ClusterCSIDriver。
使用以下 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 点 Create。
2.7.3. 将 secret 从外部 secret 存储挂载到 CSI 卷 复制链接链接已复制到粘贴板!
安装 Secret Store CSI Driver Operator 后,您可以将 secret 从以下外部 secret 存储挂载到 CSI 卷:
2.7.3.1. 从 AWS Secrets Manager 挂载 secret 复制链接链接已复制到粘贴板!
您可以使用 Secrets Store CSI Driver Operator 将 secret 从 AWS Secret Manager 挂载到 OpenShift Container Platform 中的 Container Storage Interface (CSI) 卷。要从 AWS Secrets Manager 挂载 secret,您的集群必须安装在 AWS 上,并使用 AWS 安全令牌服务 (STS)。
先决条件
- 您的集群安装在 AWS 上,并使用 AWS 安全令牌服务 (STS)。
- 已安装 Secrets Store CSI Driver Operator。具体步骤请参阅 安装 Secret Store CSI 驱动程序。
- 已将 AWS Secret Manager 配置为存储所需的 secret。
-
已提取并准备好
ccoctl二进制文件。 -
已安装
jqCLI 工具。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
安装 AWS Secrets Manager 供应商:
使用供应商资源的以下配置创建一个 YAML 文件:
重要Secret Store CSI 驱动程序的 AWS Secrets Manager 供应商是一个上游供应商。
此配置会根据上游 AWS 文档中提供的配置进行修改,以便它可以与 OpenShift Container Platform 正常工作。对此配置的更改可能会影响功能。
aws-provider.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,授予
csi-secrets-store-provider-aws服务帐户的特权访问权限:oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers
$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-driversCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建供应商资源:
oc apply -f aws-provider.yaml
$ oc apply -f aws-provider.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
授予服务帐户读取 AWS secret 对象的权限:
运行以下命令,创建一个目录使其包含凭证请求:
mkdir credentialsrequest-dir-aws
$ mkdir credentialsrequest-dir-awsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下配置为凭证请求创建 YAML 文件:
credentialsrequest.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来检索 OIDC 供应商:
oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
$ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
https://<oidc_provider_name>
https://<oidc_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从输出中复制 OIDC 供应商名称
<oidc_provider_name>,在下一步中使用。运行以下命令,使用
ccoctl工具处理凭证请求:ccoctl aws create-iam-roles \ --name my-role --region=<aws_region> \ --credentials-requests-dir=credentialsrequest-dir-aws \ --identity-provider-arn arn:aws:iam::<aws_account>:oidc-provider/<oidc_provider_name> --output-dir=credrequests-ccoctl-output$ ccoctl aws create-iam-roles \ --name my-role --region=<aws_region> \ --credentials-requests-dir=credentialsrequest-dir-aws \ --identity-provider-arn arn:aws:iam::<aws_account>:oidc-provider/<oidc_provider_name> --output-dir=credrequests-ccoctl-outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds
2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-credsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从输出中复制
<aws_role_arn>以在下一步中使用。例如,arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds。运行以下命令,使用角色 ARN 绑定服务帐户:
oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"
$ oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 secret 供应商类以定义您的 secret 存储供应商:
创建定义
SecretProviderClass对象的 YAML 文件:secret-provider-class-aws.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SecretProviderClass对象:oc create -f secret-provider-class-aws.yaml
$ oc create -f secret-provider-class-aws.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署以使用此 secret 供应商类:
创建定义
Deployment对象的 YAML 文件:deployment.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Deployment对象:oc create -f deployment.yaml
$ oc create -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证您可以从 pod 卷挂载中的 AWS Secrets Manager 访问 secret:
运行以下命令,列出 pod 挂载中的 secret:
oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
$ oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
testSecret
testSecretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看 pod 挂载中的 secret:
oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret
$ oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
<secret_value>
<secret_value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以使用 Secrets Store CSI Driver Operator 将 AWS Systems Manager 参数 Store 中的 secret 挂载到 OpenShift Container Platform 中的 Container Storage Interface (CSI) 卷。要从 AWS Systems Manager Parameter Store 挂载 secret,您的集群必须安装在 AWS 上,并使用 AWS 安全令牌服务(STS)。
先决条件
- 您的集群安装在 AWS 上,并使用 AWS 安全令牌服务 (STS)。
- 已安装 Secrets Store CSI Driver Operator。具体步骤请参阅 安装 Secret Store CSI 驱动程序。
- 您已配置了 AWS 系统管理器参数存储来存储所需的 secret。
-
已提取并准备好
ccoctl二进制文件。 -
已安装
jqCLI 工具。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
安装 AWS Systems Manager Parameter Store 供应商:
使用供应商资源的以下配置创建一个 YAML 文件:
重要Secret Store CSI 驱动程序的 AWS Systems Manager Parameter Store 供应商是一个上游供应商。
此配置会根据上游 AWS 文档中提供的配置进行修改,以便它可以与 OpenShift Container Platform 正常工作。对此配置的更改可能会影响功能。
aws-provider.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,授予
csi-secrets-store-provider-aws服务帐户的特权访问权限:oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers
$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-driversCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建供应商资源:
oc apply -f aws-provider.yaml
$ oc apply -f aws-provider.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
授予服务帐户读取 AWS secret 对象的权限:
运行以下命令,创建一个目录使其包含凭证请求:
mkdir credentialsrequest-dir-aws
$ mkdir credentialsrequest-dir-awsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下配置为凭证请求创建 YAML 文件:
credentialsrequest.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来检索 OIDC 供应商:
oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
$ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
https://<oidc_provider_name>
https://<oidc_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从输出中复制 OIDC 供应商名称
<oidc_provider_name>,在下一步中使用。运行以下命令,使用
ccoctl工具处理凭证请求:ccoctl aws create-iam-roles \ --name my-role --region=<aws_region> \ --credentials-requests-dir=credentialsrequest-dir-aws \ --identity-provider-arn arn:aws:iam::<aws_account>:oidc-provider/<oidc_provider_name> --output-dir=credrequests-ccoctl-output$ ccoctl aws create-iam-roles \ --name my-role --region=<aws_region> \ --credentials-requests-dir=credentialsrequest-dir-aws \ --identity-provider-arn arn:aws:iam::<aws_account>:oidc-provider/<oidc_provider_name> --output-dir=credrequests-ccoctl-outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds
2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-credsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 从输出中复制
<aws_role_arn>以在下一步中使用。例如,arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds。运行以下命令,使用角色 ARN 绑定服务帐户:
oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"
$ oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 secret 供应商类以定义您的 secret 存储供应商:
创建定义
SecretProviderClass对象的 YAML 文件:secret-provider-class-aws.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SecretProviderClass对象:oc create -f secret-provider-class-aws.yaml
$ oc create -f secret-provider-class-aws.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署以使用此 secret 供应商类:
创建定义
Deployment对象的 YAML 文件:deployment.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Deployment对象:oc create -f deployment.yaml
$ oc create -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证您可以从 pod 卷挂载中的 AWS Systems Manager Parameter Store 访问 secret:
运行以下命令,列出 pod 挂载中的 secret:
oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
$ oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
testParameter
testParameterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看 pod 挂载中的 secret:
oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret
$ oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
<secret_value>
<secret_value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.3. 从 Azure Key Vault 挂载 secret 复制链接链接已复制到粘贴板!
您可以使用 Secrets Store CSI Driver Operator 将 secret 从 Azure Key Vault 挂载到 OpenShift Container Platform 中的 Container Storage Interface (CSI) 卷。要从 Azure Key Vault 挂载 secret,您的集群必须安装在 Microsoft Azure 上。
先决条件
- 集群安装在 Azure 上。
- 已安装 Secrets Store CSI Driver Operator。具体步骤请参阅 安装 Secret Store CSI 驱动程序。
- 已将 Azure Key Vault 配置为存储所需的 secret。
-
已安装 Azure CLI (
az)。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
安装 Azure Key Vault 供应商:
使用供应商资源的以下配置创建一个 YAML 文件:
重要Secrets Store CSI 驱动程序的 Azure Key Vault 供应商是一个上游供应商。
此配置会根据上游 Azure 文档中提供的配置进行修改,以便它可以与 OpenShift Container Platform 正常工作。对此配置的更改可能会影响功能。
azure-provider.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,授予
csi-secrets-store-provider-azure服务帐户的特权访问权限:oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-azure -n openshift-cluster-csi-drivers
$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-azure -n openshift-cluster-csi-driversCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建供应商资源:
oc apply -f azure-provider.yaml
$ oc apply -f azure-provider.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建服务主体来访问密钥库:
运行以下命令,将服务主体客户端 secret 设置为环境变量:
SERVICE_PRINCIPAL_CLIENT_SECRET="$(az ad sp create-for-rbac --name https://$KEYVAULT_NAME --query 'password' -otsv)"
$ SERVICE_PRINCIPAL_CLIENT_SECRET="$(az ad sp create-for-rbac --name https://$KEYVAULT_NAME --query 'password' -otsv)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将服务主体客户端 ID 设置为环境变量:
SERVICE_PRINCIPAL_CLIENT_ID="$(az ad sp list --display-name https://$KEYVAULT_NAME --query '[0].appId' -otsv)"
$ SERVICE_PRINCIPAL_CLIENT_ID="$(az ad sp list --display-name https://$KEYVAULT_NAME --query '[0].appId' -otsv)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用服务主体客户端 secret 和 ID 创建通用 secret:
oc create secret generic secrets-store-creds -n my-namespace --from-literal clientid=${SERVICE_PRINCIPAL_CLIENT_ID} --from-literal clientsecret=${SERVICE_PRINCIPAL_CLIENT_SECRET}$ oc create secret generic secrets-store-creds -n my-namespace --from-literal clientid=${SERVICE_PRINCIPAL_CLIENT_ID} --from-literal clientsecret=${SERVICE_PRINCIPAL_CLIENT_SECRET}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用
secrets-store.csi.k8s.io/used=true标签,以允许供应商查找此nodePublishSecretRefsecret:oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=true
$ oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 secret 供应商类以定义您的 secret 存储供应商:
创建定义
SecretProviderClass对象的 YAML 文件:secret-provider-class-azure.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SecretProviderClass对象:oc create -f secret-provider-class-azure.yaml
$ oc create -f secret-provider-class-azure.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署以使用此 secret 供应商类:
创建定义
Deployment对象的 YAML 文件:deployment.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Deployment对象:oc create -f deployment.yaml
$ oc create -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证您可以从 pod 卷挂载中的 Azure Key Vault 访问 secret:
运行以下命令,列出 pod 挂载中的 secret:
oc exec my-azure-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
$ oc exec my-azure-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
secret1
secret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看 pod 挂载中的 secret:
oc exec my-azure-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/secret1
$ oc exec my-azure-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/secret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
my-secret-value
my-secret-valueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.4. 从 Google Secret Manager 挂载 secret 复制链接链接已复制到粘贴板!
您可以使用 Secrets Store CSI Driver Operator 将 Google Secret Manager 中的 secret 挂载到 OpenShift Container Platform 中的 Container Storage Interface (CSI) 卷。要从 Google Secret Manager 挂载 secret,您的集群必须安装在 Google Cloud Platform (GCP) 上。
先决条件
- 已安装 Secrets Store CSI Driver Operator。具体步骤请参阅 安装 Secret Store CSI 驱动程序。
- 已将 Google Secret Manager 配置为存储所需的 secret。
-
您已从 Google Cloud 服务帐户创建一个名为
key.json的服务帐户密钥。 -
您可以使用具有
cluster-admin角色的用户访问集群。
流程
安装 Google Secret Manager 供应商:
使用供应商资源的以下配置创建一个 YAML 文件:
gcp-provider.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为
csi-secrets-store-provider-gcp服务帐户授予特权访问权限:oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-gcp -n openshift-cluster-csi-drivers
$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-gcp -n openshift-cluster-csi-driversCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建供应商资源:
oc apply -f gcp-provider.yaml
$ oc apply -f gcp-provider.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
授予读取 Google Secret Manager secret 的权限:
运行以下命令创建新项目:
oc new-project my-namespace
$ oc new-project my-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 pod 安全准入标记
my-namespace命名空间:oc label ns my-namespace security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite
$ oc label ns my-namespace security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwriteCopy to Clipboard Copied! Toggle word wrap Toggle overflow 为 pod 部署创建服务帐户:
oc create serviceaccount my-service-account --namespace=my-namespace
$ oc create serviceaccount my-service-account --namespace=my-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,从
key.json文件创建通用 secret:oc create secret generic secrets-store-creds -n my-namespace --from-file=key.json
$ oc create secret generic secrets-store-creds -n my-namespace --from-file=key.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 您已从 Google Secret Manager 创建此
key.json文件。
应用
secrets-store.csi.k8s.io/used=true标签,以允许供应商查找此nodePublishSecretRefsecret:oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=true
$ oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 secret 供应商类以定义您的 secret 存储供应商:
创建定义
SecretProviderClass对象的 YAML 文件:secret-provider-class-gcp.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SecretProviderClass对象:oc create -f secret-provider-class-gcp.yaml
$ oc create -f secret-provider-class-gcp.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署以使用此 secret 供应商类:
创建定义
Deployment对象的 YAML 文件:deployment.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Deployment对象:oc create -f deployment.yaml
$ oc create -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证您是否可以从 pod 卷挂载中的 Google Secret Manager 访问 secret:
运行以下命令,列出 pod 挂载中的 secret:
oc exec my-gcp-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
$ oc exec my-gcp-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
testsecret1
testsecret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看 pod 挂载中的 secret:
oc exec my-gcp-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testsecret1
$ oc exec my-gcp-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testsecret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
<secret_value>
<secret_value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.5. 从 HashiCorp Vault 挂载 secret 复制链接链接已复制到粘贴板!
您可以使用 Secrets Store CSI Driver Operator 将 secret 从 HashiCorp Vault 挂载到 OpenShift Container Platform 中的 Container Storage Interface (CSI) 卷。
使用 Secrets Store CSI Driver Operator 从 HashiCorp Vault 挂载 secret 已使用以下云供应商测试:
- Amazon Web Services (AWS)
- Microsoft Azure
其他云供应商可能可以正常工作,但还没有测试。以后可能会测试其他云供应商。
先决条件
- 已安装 Secrets Store CSI Driver Operator。具体步骤请参阅 安装 Secret Store CSI 驱动程序。
- 已安装 Helm。
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
运行以下命令来添加 HashiCorp Helm 仓库:
helm repo add hashicorp https://helm.releases.hashicorp.com
$ helm repo add hashicorp https://helm.releases.hashicorp.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,更新所有仓库以确保 Helm 了解最新版本:
helm repo update
$ helm repo updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 安装 HashiCorp Vault 供应商:
运行以下命令,为 Vault 创建一个新项目:
oc new-project vault
$ oc new-project vaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 pod 安全准入标记
vault命名空间:oc label ns vault security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite
$ oc label ns vault security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwriteCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,授予
vault服务帐户的特权访问权限:oc adm policy add-scc-to-user privileged -z vault -n vault
$ oc adm policy add-scc-to-user privileged -z vault -n vaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,授予
vault-csi-provider服务帐户的访问权限:oc adm policy add-scc-to-user privileged -z vault-csi-provider -n vault
$ oc adm policy add-scc-to-user privileged -z vault-csi-provider -n vaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来部署 HashiCorp Vault:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,修补
vault-csi-driver守护进程,将securityContext设置为privileged:oc patch daemonset -n vault vault-csi-provider --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'$ oc patch daemonset -n vault vault-csi-provider --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
vault-csi-providerpod 是否已正确启动:oc get pods -n vault
$ oc get pods -n vaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE vault-0 1/1 Running 0 24m vault-csi-provider-87rgw 1/2 Running 0 5s vault-csi-provider-bd6hp 1/2 Running 0 4s vault-csi-provider-smlv7 1/2 Running 0 5s
NAME READY STATUS RESTARTS AGE vault-0 1/1 Running 0 24m vault-csi-provider-87rgw 1/2 Running 0 5s vault-csi-provider-bd6hp 1/2 Running 0 4s vault-csi-provider-smlv7 1/2 Running 0 5sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
配置 HashiCorp Vault 以存储所需的 secret:
运行以下命令来创建 secret:
oc exec vault-0 --namespace=vault -- vault kv put secret/example1 testSecret1=my-secret-value
$ oc exec vault-0 --namespace=vault -- vault kv put secret/example1 testSecret1=my-secret-valueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证
secret/example1的路径是否可读:oc exec vault-0 --namespace=vault -- vault kv get secret/example1
$ oc exec vault-0 --namespace=vault -- vault kv get secret/example1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
将 Vault 配置为使用 Kubernetes 身份验证:
运行以下命令来启用 Kubernetes auth 方法:
oc exec vault-0 --namespace=vault -- vault auth enable kubernetes
$ oc exec vault-0 --namespace=vault -- vault auth enable kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Success! Enabled kubernetes auth method at: kubernetes/
Success! Enabled kubernetes auth method at: kubernetes/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置 Kubernetes auth 方法:
运行以下命令,将令牌查看器设置为环境变量:
TOKEN_REVIEWER_JWT="$(oc exec vault-0 --namespace=vault -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
$ TOKEN_REVIEWER_JWT="$(oc exec vault-0 --namespace=vault -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将 Kubernetes 服务 IP 地址设置为环境变量:
KUBERNETES_SERVICE_IP="$(oc get svc kubernetes -o go-template="{{ .spec.clusterIP }}")"$ KUBERNETES_SERVICE_IP="$(oc get svc kubernetes -o go-template="{{ .spec.clusterIP }}")"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来更新 Kubernetes auth 方法:
oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="${TOKEN_REVIEWER_JWT}" \ kubernetes_host="https://${KUBERNETES_SERVICE_IP}:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt$ oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="${TOKEN_REVIEWER_JWT}" \ kubernetes_host="https://${KUBERNETES_SERVICE_IP}:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Success! Data written to: auth/kubernetes/config
Success! Data written to: auth/kubernetes/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令,为应用程序创建一个策略:
oc exec -i vault-0 --namespace=vault -- vault policy write csi -<<EOF path "secret/data/*" { capabilities = ["read"] } EOF$ oc exec -i vault-0 --namespace=vault -- vault policy write csi -<<EOF path "secret/data/*" { capabilities = ["read"] } EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Success! Uploaded policy: csi
Success! Uploaded policy: csiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,创建一个身份验证角色来访问应用程序:
oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/role/csi \ bound_service_account_names=default \ bound_service_account_namespaces=default,test-ns,negative-test-ns,my-namespace \ policies=csi \ ttl=20m
$ oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/role/csi \ bound_service_account_names=default \ bound_service_account_namespaces=default,test-ns,negative-test-ns,my-namespace \ policies=csi \ ttl=20mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Success! Data written to: auth/kubernetes/role/csi
Success! Data written to: auth/kubernetes/role/csiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证所有
vaultpod 是否都正常运行:oc get pods -n vault
$ oc get pods -n vaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE vault-0 1/1 Running 0 43m vault-csi-provider-87rgw 2/2 Running 0 19m vault-csi-provider-bd6hp 2/2 Running 0 19m vault-csi-provider-smlv7 2/2 Running 0 19m
NAME READY STATUS RESTARTS AGE vault-0 1/1 Running 0 43m vault-csi-provider-87rgw 2/2 Running 0 19m vault-csi-provider-bd6hp 2/2 Running 0 19m vault-csi-provider-smlv7 2/2 Running 0 19mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证所有
secrets-store-csi-driverpod 是否正常运行:oc get pods -n openshift-cluster-csi-drivers | grep -E "secrets"
$ oc get pods -n openshift-cluster-csi-drivers | grep -E "secrets"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 secret 供应商类以定义您的 secret 存储供应商:
创建定义
SecretProviderClass对象的 YAML 文件:secret-provider-class-vault.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
SecretProviderClass对象:oc create -f secret-provider-class-vault.yaml
$ oc create -f secret-provider-class-vault.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建部署以使用此 secret 供应商类:
创建定义
Deployment对象的 YAML 文件:deployment.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建
Deployment对象:oc create -f deployment.yaml
$ oc create -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证您是否可以从 pod 卷挂载中的 HashiCorp Vault 访问 secret:
运行以下命令,列出 pod 挂载中的 secret:
oc exec busybox-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
$ oc exec busybox-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
testSecret1
testSecret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,查看 pod 挂载中的 secret:
oc exec busybox-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret1
$ oc exec busybox-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
my-secret-value
my-secret-valueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.4. 启用对作为 Kubernetes secret 挂载的内容进行同步 复制链接链接已复制到粘贴板!
您可以启用同步,从挂载的卷中的内容创建 Kubernetes secret。您可能要启用同步的示例是使用部署中的环境变量来引用 Kubernetes secret。
如果您不想将 secret 存储在 OpenShift Container Platform 集群和 etcd 中,请不要启用同步。仅在需要它时启用此功能,比如当您想要使用环境变量来引用 secret 时。
如果启用了同步,在启动挂载 secret 的 pod 后,来自挂载卷的 secret 会同步为 Kubernetes secret。
当所有挂载内容的 pod 被删除时,同步的 Kubernetes secret 会被删除。
先决条件
- 已安装 Secrets Store CSI Driver Operator。
- 已安装 secret 存储供应商。
- 您已创建了 secret 供应商类。
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
运行以下命令来编辑
SecretProviderClass资源:oc edit secretproviderclass my-azure-provider
$ oc edit secretproviderclass my-azure-provider1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
my-azure-provider替换为 secret 供应商类的名称。
使用同步的 Kubernetes secret 配置添加
secretsObjects部分:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存文件以使改变生效。
2.7.5. 查看 pod 卷挂载中的 secret 状态 复制链接链接已复制到粘贴板!
您可以查看 pod 卷挂载中 secret 的详细信息,包括版本。
Secrets Store CSI Driver Operator 在与 pod 相同的命名空间中创建一个 SecretProviderClassPodStatus 资源。您可以查看此资源来查看详细信息,包括版本,以及 pod 卷挂载中的 secret。
先决条件
- 已安装 Secrets Store CSI Driver Operator。
- 已安装 secret 存储供应商。
- 您已创建了 secret 供应商类。
- 您已部署了从 Secrets Store CSI Driver Operator 挂载卷的 pod。
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
运行以下命令,查看 pod 卷挂载中 secret 的详细信息:
oc get secretproviderclasspodstatus <secret_provider_class_pod_status_name> -o yaml
$ oc get secretproviderclasspodstatus <secret_provider_class_pod_status_name> -o yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- secret 供应商类 pod 状态对象的名称采用
<pod_name>-<namespace>-<secret_provider_class_name>的格式。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.6. 卸载 Secret Store CSI Driver Operator 复制链接链接已复制到粘贴板!
先决条件
- 访问 OpenShift Container Platform Web 控制台。
- 集群的管理员访问权限。
流程
卸载 Secret Store CSI Driver Operator:
-
停止所有使用
secrets-store.csi.k8s.io供应商的应用程序 pod。 - 为所选 secret 存储删除任何第三方供应商插件。
删除 Container Storage Interface (CSI) 驱动程序和相关清单:
- 点 Administration → CustomResourceDefinitions → ClusterCSIDriver。
- 在 Instances 选项卡上,对于 secrets-store.csi.k8s.io,点左侧的下拉菜单,然后点 Delete ClusterCSIDriver。
- 出现提示时,单击 Delete。
- 验证 CSI 驱动程序 pod 是否不再运行。
卸载 Secret Store CSI Driver Operator:
注意在卸载 Operator 前,必须先删除 CSI 驱动程序。
- 点 Operators → Installed Operators。
- 在 Installed Operators 页面中,在 Search by name 框中输入 "Secrets Store CSI" 来查找 Operator,然后点击它。
- 在 Installed Operators > Operator 详情页面 的右上角,点 Actions → Uninstall Operator。
当在 Uninstall Operator 窗口中提示时,点 Uninstall 按钮从命名空间中删除 Operator。Operator 在集群中部署的任何应用程序都需要手动清理。
卸载后,Secret Store CSI Driver Operator 不再列在 web 控制台的 Installed Operators 部分。
2.8. 使用短期凭证验证 pod 复制链接链接已复制到粘贴板!
有些 OpenShift Container Platform 集群 对集群外创建和管理的独立组件使用短期安全凭证。这些集群上的客户工作负载中的应用程序可以使用集群使用的短期身份验证方法进行身份验证。
2.8.1. 为工作负载配置短期身份验证 复制链接链接已复制到粘贴板!
要在应用程序中使用此验证方法,您必须完成以下步骤:
- 在云供应商的 Identity and Access Management (IAM)设置中创建一个联邦身份服务帐户。
- 创建 OpenShift Container Platform 服务帐户,用于模拟云供应商的服务帐户。
- 配置与应用程序相关的任何工作负载,以使用 OpenShift Container Platform 服务帐户。
2.8.1.1. 环境和用户访问权限要求 复制链接链接已复制到粘贴板!
要配置这个验证方法,您必须满足以下要求:
- 集群必须使用 短期安全凭证。
-
您必须可以使用具有
cluster-admin角色的用户访问 OpenShift CLI (oc)。 - 在云供应商控制台中,您必须具有具有特权的用户访问,以管理 Identity and Access Management (IAM)和联邦身份配置。
2.8.2. 为 GCP 上的应用程序配置 GCP Workload Identity 身份验证 复制链接链接已复制到粘贴板!
要将短期身份验证用于使用 GCP Workload Identity 身份验证的 GCP 集群上的应用程序,您必须完成以下步骤:
创建联邦 GCP 服务帐户
您可以使用 Google Cloud 控制台创建工作负载身份池和供应商,并允许 OpenShift Container Platform 服务帐户模拟 GCP 服务帐户。
先决条件
- 您的 GCP 集群正在运行 OpenShift Container Platform 版本 4.17.4 或更高版本,并使用 GCP Workload Identity。
- 您可以使用具有管理 Identity and Access Management (IAM)和工作负载身份配置权限的用户访问 Google Cloud 控制台。
- 您已创建了用于应用程序的 Google Cloud 项目。
流程
- 在 Google Cloud 项目的 IAM 配置中,识别集群用于 GCP Workload Identity 身份验证的身份池和供应商。
为外部身份授予模拟 GCP 服务帐户的权限。通过这些权限,OpenShift Container Platform 服务帐户可以充当联邦工作负载身份。
如需更多信息,请参阅有关 允许外部工作负载访问 Google Cloud 资源的 GCP 文档。
为 GCP 创建 OpenShift Container Platform 服务帐户
您可以创建一个 OpenShift Container Platform 服务帐户,并注解它来模拟 GCP 服务帐户。
先决条件
- 您的 GCP 集群正在运行 OpenShift Container Platform 版本 4.17.4 或更高版本,并使用 GCP Workload Identity。
- 您已创建了一个联邦 GCP 服务帐户。
-
您可以使用具有
cluster-admin角色的用户访问 OpenShift CLI (oc)。 -
您可以使用具有管理 Identity and Access Management (IAM)和工作负载身份配置权限的用户访问 Google Cloud CLI (
gcloud)。
流程
运行以下命令,创建一个 OpenShift Container Platform 服务帐户以用于 GCP Workload Identity pod 身份验证:
oc create serviceaccount <service_account_name>
$ oc create serviceaccount <service_account_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,使用身份提供程序和 GCP 服务帐户注解服务帐户:
oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/workload-identity-provider": "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"}}}'$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/workload-identity-provider": "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 &
lt;project_number> , <identity_pool> , 和 <identity_provider> 替换为您的配置的值。注意对于
<project_number>,请指定 Google Cloud 项目号,而不是项目 ID。运行以下命令,使用 GCP 服务帐户的电子邮件地址注解服务帐户:
oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/service-account-email": "<service_account_email>"}}}'$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/service-account-email": "<service_account_email>"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<service_account_email> 替换为 GCP 服务帐户的电子邮件地址。提示GCP 服务帐户电子邮件地址通常使用 <
service_account_name>@<project_id>.iam.gserviceaccount.com格式运行以下命令,注解服务帐户以使用
直接外部凭证配置注入模式:oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/injection-mode": "direct"}}}'$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/injection-mode": "direct"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在这个模式中,Workload Identity Federation Webhook 控制器直接生成 GCP 外部凭证配置,并将它们注入 pod。
运行以下命令,使用 Google Cloud CLI (
gcloud)指定工作负载的权限:gcloud projects add-iam-policy-binding <project_id> --member "<service_account_email>" --role "projects/<project_id>/roles/<role_for_workload_permissions>"
$ gcloud projects add-iam-policy-binding <project_id> --member "<service_account_email>" --role "projects/<project_id>/roles/<role_for_workload_permissions>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<role_for_workload_permissions> 替换为工作负载的角色。指定授予工作负载所需的权限的角色。
验证
要验证服务帐户配置,请运行以下命令来检查
ServiceAccount清单:oc get serviceaccount <service_account_name>
$ oc get serviceaccount <service_account_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下示例中,
service-a/app-xOpenShift Container Platform 服务帐户可以模拟名为app-x的 GCP 服务帐户:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
部署通过 GCP Workload Identity 进行身份验证的客户工作负载
要在应用程序中使用短期身份验证,您必须将其相关的 pod 配置为使用 OpenShift Container Platform 服务帐户。使用 OpenShift Container Platform 服务帐户会触发 Webhook 来模拟 pod,以便它们能够模拟 GCP 服务帐户。
以下示例演示了如何部署使用 OpenShift Container Platform 服务帐户的 pod 并验证配置。
先决条件
- 您的 GCP 集群正在运行 OpenShift Container Platform 版本 4.17.4 或更高版本,并使用 GCP Workload Identity。
- 您已创建了一个联邦 GCP 服务帐户。
- 您已为 GCP 创建了一个 OpenShift Container Platform 服务帐户。
流程
要创建使用 GCP Workload Identity 验证的 pod,请创建一个类似以下示例的部署 YAML 文件:
部署示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定 OpenShift Container Platform 服务帐户的名称。
运行以下命令来应用部署文件:
oc apply -f deployment.yaml
$ oc apply -f deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证 pod 是否使用短期身份验证,请运行以下命令:
oc get pods -o json | jq -r '.items[0].spec.containers[0].env[] | select(.name=="GOOGLE_APPLICATION_CREDENTIALS")'
$ oc get pods -o json | jq -r '.items[0].spec.containers[0].env[] | select(.name=="GOOGLE_APPLICATION_CREDENTIALS")'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
{ "name": "GOOGLE_APPLICATION_CREDENTIALS", "value": "/var/run/secrets/workload-identity/federation.json" }{ "name": "GOOGLE_APPLICATION_CREDENTIALS", "value": "/var/run/secrets/workload-identity/federation.json" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow GOOGLE_APPLICATION_CREDENTIALS环境变量存在表示使用 GCP Workload Identity 进行身份验证的 pod。要验证其他配置详情,请检查 pod 规格。以下 pod 规格示例显示了 webhook 变异的环境变量和卷字段。
带有
直接注入模式的 pod 规格示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9. 创建和使用配置映射 复制链接链接已复制到粘贴板!
以下部分定义配置映射以及如何创建和使用它们。
2.9.1. 了解配置映射 复制链接链接已复制到粘贴板!
许多应用程序需要使用配置文件、命令行参数和环境变量的某些组合来进行配置。在 OpenShift Container Platform 中,这些配置工件与镜像内容分离,以便使容器化应用程序可以移植。
ConfigMap 对象提供了将容器注入到配置数据的机制,同时保持容器与 OpenShift Container Platform 无关。配置映射可用于存储细粒度信息(如个别属性)或粗粒度信息(如完整配置文件或 JSON blob)。
ConfigMap 对象包含配置数据的键值对,这些数据可在 Pod 中消耗或用于存储控制器等系统组件的配置数据。例如:
ConfigMap 对象定义
从二进制文件(如镜像)创建配置映射时,您可以使用 binaryData 字段。
可以在 Pod 中以各种方式消耗配置数据。配置映射可用于:
- 在容器中填充环境变量值
- 设置容器中的命令行参数
- 填充卷中的配置文件
用户和系统组件可以在配置映射中存储配置数据。
配置映射与 secret 类似,但设计为能更加便捷地支持与不含敏感信息的字符串配合。
配置映射限制
在 pod 中可以消耗它的内容前,必须创建配置映射。
可以编写控制器来容许缺少的配置数据。根据具体情况使用配置映射来参考各个组件。
ConfigMap 对象驻留在一个项目中。
它们只能被同一项目中的 pod 引用。
Kubelet 只支持为它从 API 服务器获取的 pod 使用配置映射。
这包括使用 CLI 创建或间接从复制控制器创建的 pod。它不包括通过 OpenShift Container Platform 节点的 --manifest-url 标记、--config 标记,或通过 REST API 创建的 pod,因为这些不是创建 pod 的通用方法。
2.9.2. 在 OpenShift Container Platform Web 控制台中创建配置映射 复制链接链接已复制到粘贴板!
您可以在 OpenShift Container Platform Web 控制台中创建配置映射。
流程
以集群管理员身份创建配置映射:
-
在 Administrator 视角中,选择
Workloads→Config Maps。 - 在该页面右上方选择 Create Config Map。
- 输入配置映射的内容。
- 选择 Create。
-
在 Administrator 视角中,选择
以开发者身份创建配置映射:
-
在 Developer 视角中,选择
Config Maps。 - 在该页面右上方选择 Create Config Map。
- 输入配置映射的内容。
- 选择 Create。
-
在 Developer 视角中,选择
2.9.3. 使用 CLI 创建配置映射 复制链接链接已复制到粘贴板!
您可以使用以下命令从目录、特定文件或文字值创建配置映射。
流程
创建配置映射:
oc create configmap <configmap_name> [options]
$ oc create configmap <configmap_name> [options]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9.3.1. 从目录创建配置映射 复制链接链接已复制到粘贴板!
您可以使用 --from-file 标志从目录创建配置映射。这个方法允许您使用目录中的多个文件来创建配置映射。
目录中的每个文件用于在配置映射中填充键,其中键的名称是文件名,键的值是文件的内容。
例如,以下命令会创建一个带有 example-files 目录内容的配置映射:
oc create configmap game-config --from-file=example-files/
$ oc create configmap game-config --from-file=example-files/
查看配置映射中的密钥:
oc describe configmaps game-config
$ oc describe configmaps game-config
输出示例
您可以看到,映射中的两个键都是从命令中指定的目录中的文件名创建的。这些密钥的内容可能非常大,因此 oc describe 的输出只显示键的名称及其大小。
前提条件
您必须有一个目录,其中包含您要使用填充配置映射的数据的文件。
以下流程使用这些示例文件:
game.properties和ui.properties:cat example-files/game.properties
$ cat example-files/game.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/ui.properties
$ cat example-files/ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNiceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
输入以下命令,创建包含此目录中每个文件内容的配置映射:
oc create configmap game-config \ --from-file=example-files/$ oc create configmap game-config \ --from-file=example-files/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用带有
-o选项的oc get命令以查看键的值:oc get configmaps game-config -o yaml
$ oc get configmaps game-config -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9.3.2. 从文件创建配置映射 复制链接链接已复制到粘贴板!
您可以使用 --from-file 标志从文件创建配置映射。您可以多次将 --from-file 选项传递给 CLI。
您还可以通过将 key=value 表达式传递给 --from-file 选项,在配置映射中为从文件中导入的内容指定要设置的键。例如:
oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties
$ oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties
如果从文件创建一个配置映射,您可以在不会破坏非 UTF8 数据的项中包含非 UTF8 的数据。OpenShift Container Platform 检测到二进制文件,并将该文件编码为 MIME。在服务器上,MIME 有效负载被解码并存储而不会损坏数据。
前提条件
您必须有一个目录,其中包含您要使用填充配置映射的数据的文件。
以下流程使用这些示例文件:
game.properties和ui.properties:cat example-files/game.properties
$ cat example-files/game.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/ui.properties
$ cat example-files/ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNiceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
通过指定特定文件来创建配置映射:
oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.properties$ oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过指定键值对来创建配置映射:
oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.properties$ oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用
-o选项为对象输入oc get命令,以查看文件中的键值:oc get configmaps game-config-2 -o yaml
$ oc get configmaps game-config-2 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
-o选项为对象输入oc get命令,以查看键值对中的键值:oc get configmaps game-config-3 -o yaml
$ oc get configmaps game-config-3 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 这是您在前面的步骤中设置的密钥。
2.9.3.3. 从字面值创建配置映射 复制链接链接已复制到粘贴板!
您可以为配置映射提供字面值。
--from-literal 选项采用 key=value 语法,它允许直接在命令行中提供字面值。
流程
通过指定字面值来创建配置映射:
oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charm$ oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charmCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
使用带有
-o选项的oc get命令以查看键的值:oc get configmaps special-config -o yaml
$ oc get configmaps special-config -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9.4. 用例: 在 pod 中使用配置映射 复制链接链接已复制到粘贴板!
以下小节描述了在 pod 中消耗 ConfigMap 对象时的一些用例。
2.9.4.1. 使用配置映射在容器中填充环境变量 复制链接链接已复制到粘贴板!
您可以使用配置映射在容器中填充各个环境变量,或从构成有效环境变量名称的所有键填充容器中的环境变量。
例如,请考虑以下配置映射:
有两个环境变量的 ConfigMap
带有一个环境变量的ConfigMap
流程
您可以使用
configMapKeyRef部分在 pod 中使用此ConfigMap的键。配置为注入特定环境变量的
Pod规格示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当此 pod 运行时,pod 日志包括以下输出:
SPECIAL_LEVEL_KEY=very log_level=INFO
SPECIAL_LEVEL_KEY=very log_level=INFOCopy to Clipboard Copied! Toggle word wrap Toggle overflow
示例输出中没有列出 SPECIAL_TYPE_KEY=charm,因为设置了 optional: true。
2.9.4.2. 使用配置映射为容器命令设置命令行参数 复制链接链接已复制到粘贴板!
您可以通过 Kubernetes 替换语法 $(VAR_NAME),使用配置映射来设置容器中的命令或参数的值。
例如,请考虑以下配置映射:
流程
要将值注入到容器中的一个命令中,使用您要用作环境变量的键。然后,您可以使用
$(VAR_NAME)语法在容器的命令中引用它们。配置为注入特定环境变量的 pod 规格示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用您要用作环境变量的键将值注入到容器中的命令中。
当此 pod 运行时,test-container 容器中运行的 echo 命令的输出如下:
very charm
very charmCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9.4.3. 使用配置映射将内容注入卷 复制链接链接已复制到粘贴板!
您可以使用配置映射将内容注入卷。
ConfigMap 自定义资源(CR)示例
流程
您可以使用配置映射将内容注入卷中有两个不同的选项。
使用配置映射将内容注入卷的最基本方法是在卷中填充键为文件名称的文件,文件的内容是键值:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 包含密钥的文件。
当这个 pod 运行时,cat 命令的输出将是:
very
veryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您还可以控制投射配置映射键的卷中的路径:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 配置映射键的路径。
当这个 pod 运行时,cat 命令的输出将是:
very
veryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.10. 使用设备插件来利用 pod 访问外部资源 复制链接链接已复制到粘贴板!
借助设备插件,您无需编写自定义代码,就能在 OpenShift Container Platform pod 中使用特定的设备类型,如 GPU、InfiniBand 或其他需要供应商专用初始化和设置的类似计算资源。
2.10.1. 了解设备插件 复制链接链接已复制到粘贴板!
设备插件提供一致并可移植的解决方案,以便跨集群消耗硬件设备。设备插件通过一种扩展机制为这些设备提供支持,从而使这些设备可供容器使用,提供这些设备的健康检查,并安全地共享它们。
OpenShift Container Platform 支持设备插件 API,但设备插件容器由各个供应商提供支持。
设备插件是在节点(kubelet 的外部)上运行的 gRPC 服务,负责管理特定的硬件资源。任何设备插件都必须支持以下远程过程调用 (RPC):
设备插件示例
对于简单设备插件参考实现,设备管理器代码中有一个 stub 设备插件: vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go。
2.10.1.1. 设备插件部署方法 复制链接链接已复制到粘贴板!
- 守护进程集是设备插件部署的推荐方法。
- 在启动时,设备插件会尝试在节点上 /var/lib/kubelet/device-plugin/ 创建一个 UNIX 域套接字,以便服务来自于设备管理器的 RPC。
- 由于设备插件必须管理硬件资源、主机文件系统的访问权以及套接字创建,它们必须在一个特权安全上下文中运行。
- 各种设备插件实现中提供了有关部署步骤的更多细节。
2.10.2. 了解设备管理器 复制链接链接已复制到粘贴板!
设备管理器提供了一种机制,可借助称为“设备插件”的插件公告专用节点硬件资源。
您可以公告专用的硬件,而不必修改任何上游代码。
OpenShift Container Platform 支持设备插件 API,但设备插件容器由各个供应商提供支持。
设备管理器将设备公告为外部资源。用户 pod 可以利用相同的限制/请求机制来使用设备管理器公告的设备,这一机制也用于请求任何其他扩展资源。
在启动时,设备插件会在 /var/lib/kubelet/device-plugins/kubelet.sock 上调用 Register 将自身注册到设备管理器,并启动位于 / var/lib/kubelet/device-plugins/<plugin>.sock 的 gRPC 服务,以服务设备管理器请求。
在处理新的注册请求时,设备管理器会在设备插件服务中调用 ListAndWatch 远程过程调用 (RPC)。作为响应,设备管理器通过 gRPC 流从插件中获取设备对象的列表。设备管理器对流进行持续监控,以确认插件有没有新的更新。在插件一端,插件也会使流保持开放;只要任何设备的状态有所改变,就会通过相同的流传输连接将新设备列表发送到设备管理器。
在处理新的 pod 准入请求时,Kubelet 将请求的扩展资源传递给设备管理器以进行设备分配。设备管理器在其数据库中检查,以验证是否存在对应的插件。如果插件存在并且有可分配的设备及本地缓存,则在该特定设备插件上调用 Allocate RPC。
此外,设备插件也可以执行其他几个特定于设备的操作,如驱动程序安装、设备初始化和设备重置。这些功能视具体实现而异。
2.10.3. 启用设备管理器 复制链接链接已复制到粘贴板!
启用设备管理器来实现设备插件,在不更改上游代码的前提下公告专用硬件。
设备管理器提供了一种机制,可借助称为“设备插件”的插件公告专用节点硬件资源。
输入以下命令为您要配置的节点类型获取与静态
MachineConfigPoolCRD 关联的标签。执行以下步骤之一:查看机器配置:
oc describe machineconfig <name>
# oc describe machineconfig <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc describe machineconfig 00-worker
# oc describe machineconfig 00-workerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker
Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设备管理器所需标签。
流程
为配置更改创建自定义资源 (CR)。
设备管理器 CR 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建设备管理器:
oc create -f devicemgr.yaml
$ oc create -f devicemgr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubeletconfig.machineconfiguration.openshift.io/devicemgr created
kubeletconfig.machineconfiguration.openshift.io/devicemgr createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 通过确认节点上已创建了 /var/lib/kubelet/device-plugins/kubelet.sock,确保已启用了设备管理器。这是设备管理器 gRPC 服务器在其上侦听新插件注册的 UNIX 域套接字。只有启用了设备管理器,才会在 Kubelet 启动时创建此 sock 文件。
2.11. 在 pod 调度决策中纳入 pod 优先级 复制链接链接已复制到粘贴板!
您可以在集群中启用 pod 优先级与抢占功能。pod 优先级代表与其他 pod 相比此 pod 的重要性,并根据优先级进行队列处理。抢占(preemption)则允许集群驱除低优先级 pod 或与之争抢,从而在合适的节点上没有可用空间时能够调度优先级较高的 pod。pod 优先级也会影响 pod 的调度顺序以及节点上资源不足驱除顺序。
要使用优先级和抢占功能,您需要创建优先级类来定义 pod 的相对权重。然后,在 pod 规格中引用优先级类,以应用这个权重来进行调度。
2.11.1. 了解 pod 优先级 复制链接链接已复制到粘贴板!
当您使用 pod 优先级与抢占功能时,调度程序会根据优先级来调度待处理 pod,而待处理 pod 会放在调度队列中优先级较低的其他待处理 pod 的前面。因此,如果达到调度要求,较高优先级的 pod 可能比低优先级的 pod 更早调度。如果 pod 无法调度,调度程序会继续调度其他较低优先级 pod。
2.11.1.1. Pod 优先级类 复制链接链接已复制到粘贴板!
您可以为 pod 分配一个优先级类,它是一种非命名空间的对象,用于定义从名称到优先级整数值的映射。数值越大,优先级越高。
优先级类对象可以取小于或等于 1000000000(十亿)的 32 位整数值。对于不得被抢占或被驱除的关键 pod,请保留大于或等于 10 亿的数值。默认情况下,OpenShift Container Platform 有两个保留优先级类,用于需要保证调度的关键系统 pod。
oc get priorityclasses
$ oc get priorityclasses
输出示例
NAME VALUE GLOBAL-DEFAULT AGE system-node-critical 2000001000 false 72m system-cluster-critical 2000000000 false 72m openshift-user-critical 1000000000 false 3d13h cluster-logging 1000000 false 29s
NAME VALUE GLOBAL-DEFAULT AGE
system-node-critical 2000001000 false 72m
system-cluster-critical 2000000000 false 72m
openshift-user-critical 1000000000 false 3d13h
cluster-logging 1000000 false 29s
system-node-critical - 此优先级类的值为 2000001000,用于所有不得从节点上驱除的 pod。具有此优先级类的 pod 示例是
ovnkube-node等。许多关键组件默认包括system-node-critical优先级类,例如:- master-api
- master-controller
- master-etcd
- ovn-kubernetes
- sync
system-cluster-critical - 此优先级类的值是 2000000000(二十亿),用于对集群而言很重要的 pod。在某些情况下,具有此优先级类的 Pod 可以从节点中驱除。例如,配置了
system-node-critical优先级类的 pod 可以拥有优先权。不过,此优先级类确实能够保证调度。具有此优先级类的 pod 示例有 fluentd 以及 descheduler 这样的附加组件等。许多关键组件默认包括system-cluster-critical优先级类,例如:- fluentd
- metrics-server
- descheduler
-
openshift-user-critical - 您可以使用带有重要 pod 的
priorityClassName字段,这些 pod 无法绑定其资源消耗,且没有可预测的资源消耗行为。openshift-monitoring和openshift-user-workload-monitoring命名空间下的 Prometheus Pod 使用openshift-user-criticalpriorityClassName。监控工作负载使用system-critical作为其第一个priorityClass,但在监控使用过量内存时造成问题,且无法驱除它们。因此,监控会丢弃优先级,为调度程序带来灵活性,并围绕移动繁重的工作负载来保持关键节点正常操作。 - cluster-logging - 此优先级类供 Fluentd 用于确保 Fluentd pod 优先于其他应用调度到节点上。
2.11.1.2. Pod 优先级名称 复制链接链接已复制到粘贴板!
拥有一个或多个优先级类后,您可以创建 pod,并在 Pod 规格中指定优先级类名称。优先准入控制器使用优先级类名称字段来填充优先级的整数值。如果没有找到给定名称的优先级类,pod 将被拒绝。
2.11.2. 了解 pod 抢占 复制链接链接已复制到粘贴板!
当开发人员创建 pod 时,pod 会排入某一队列。如果开发人员为 pod 配置了 pod 优先级或抢占,调度程序会从队列中选取 pod,并尝试将 pod 调度到某个节点上。如果调度程序无法在满足 pod 的所有指定要求的适当节点上找到空间,则会为待处理 pod 触发抢占逻辑。
当调度程序在节点上抢占一个或多个 pod 时,较高优先级 Pod spec 的 nominatedNodeName 字段 将设为该节点的名称,nodename 字段也是如此。调度程序使用 nominatedNodeName 字段来跟踪为 pod 保留的资源,同时也向用户提供与集群中抢占相关的信息。
在调度程序抢占了某一较低优先级 pod 后,调度程序会尊重该 pod 的安全终止期限。如果在调度程序等待较低优先级 pod 终止过程中另一节点变为可用,调度程序会将较高优先级 pod 调度到该节点上。因此,Pod spec 的 nominatedNodeName 字段和 nodeName 字段可能会有所不同。
另外,如果调度程序在某一节点上抢占 pod 并正在等待终止,这时又有优先级比待处理 pod 高的 pod 需要调度,那么调度程序可以改为调度这个优先级更高的 pod。在这种情况下,调度程序会清除待处理 pod 的 nominatedNodeName,使该 pod 有资格调度到其他节点上。
抢占不一定从节点中移除所有较低优先级 pod。调度程序可以通过移除一部分较低优先级 pod 调度待处理 pod。
只有待处理 pod 能够调度到节点时,调度程序才会对这个节点考虑 pod 抢占。
2.11.2.1. 非抢占优先级类 复制链接链接已复制到粘贴板!
抢占策略设置为 Never 的 Pod 会放置在较低优先级 pod 的调度队列中,但无法抢占其他 pod。等待调度的非抢占 pod 会保留在调度队列中,直到资源可用且可以调度。非抢占 pod 与其他 pod 一样,受调度程序后退避的影响。这意味着,如果调度程序尝试调度这些 pod,它们会以较低频率重试,允许在调度前调度其他优先级较低的 pod。
非抢占 pod 仍可被其他高优先级 pod 抢占。
2.11.2.2. Pod 抢占和其他调度程序设置 复制链接链接已复制到粘贴板!
如果启用 pod 优先级与抢占功能,请考虑其他的调度程序设置:
- pod 优先级和 pod 中断预算
- pod 中断预算指定某一时间必须保持在线的副本的最小数量或百分比。如果您指定了 pod 中断预算,OpenShift Container Platform 会在抢占 pod 时尽力尊重这些预算。调度程序会尝试在不违反 pod 中断预算的前提下抢占 pod。如果找不到这样的 pod,则可能会无视 pod 中断预算要求而抢占较低优先级 pod。
- pod 优先级和 pod 关联性
- pod 关联性要求将新 pod 调度到与具有同样标签的其他 pod 相同的节点上。
如果待处理 pod 与节点上的一个或多个低优先级 pod 具有 pod 间关联性,调度程序就不能在不违反关联要求的前提下抢占较低优先级 pod。这时,调度程序会寻找其他节点来调度待处理 pod。但是,不能保证调度程序能够找到合适的节点,因此可能无法调度待处理 pod。
要防止这种情况,请仔细配置优先级相同的 pod 的 pod 关联性。
2.11.2.3. 安全终止被抢占的 pod 复制链接链接已复制到粘贴板!
在抢占 pod 时,调度程序会等待 pod 安全终止期限到期,使 pod 能够完成工作并退出。如果 pod 在到期后没有退出,调度程序会终止该 pod。此安全终止期限会在调度程序抢占该 pod 的时间和待处理 pod 调度到节点的时间之间造成一个时间差。
要尽量缩短这个时间差,可以为较低优先级 pod 配置较短的安全终止期限。
2.11.3. 配置优先级和抢占 复制链接链接已复制到粘贴板!
您可以通过创建优先级类对象并使用 pod 规格中的 priorityClassName 将 pod 与优先级关联来应用 pod 优先级与抢占。
您不能直接将优先级类添加到现有调度的 pod 中。
流程
配置集群以使用优先级与抢占功能:
创建一个或多个优先级类:
创建一个类似以下示例的 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 优先级类对象的名称。
- 2
- 对象的优先级值。
- 3
- 可选。指定此优先级类是否被抢占或非抢占。抢占策略默认为
PreemptLowerPriority,它允许该优先级类中的 pod 抢占较低优先级 pod。如果抢占策略设置为Never,则该优先级类中的 pod 就不会被抢占。 - 4
- 可选。指定是否应该将这个优先级类用于没有指定优先级类名称的 pod。此字段默认为
false。集群中只能存在一个globalDefault设为true的优先级类。如果没有globalDefault:true的优先级类,则无优先级类名称的 pod 的优先级为零。添加具有globalDefault:true的优先级类只会影响在添加优先级类后创建的 pod,不会更改现有 pod 的优先级。 - 5
- 可选。描述开发人员应该用于此优先级类的 pod。输入任意文本字符串。
创建优先级类:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 pod spec 使其包含优先级类的名称:
创建一个类似以下示例的 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要用于此 pod 的优先级类。
创建 pod:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以将优先级名称直接添加到 pod 配置或 pod 模板中。
2.12. 使用节点选择器将 pod 放置到特定节点 复制链接链接已复制到粘贴板!
节点选择器指定一个键值对映射。使用节点中的自定义标签和 pod 中指定的选择器来定义规则。
若要使 pod 有资格在某一节点上运行,pod 必须具有指定为该节点上标签的键值对。
如果您在同一 pod 配置中同时使用节点关联性和节点选择器,请查看下方的重要注意事项。
2.12.1. 使用节点选择器控制 pod 放置 复制链接链接已复制到粘贴板!
您可以使用节点上的 pod 和标签上的节点选择器来控制 pod 的调度位置。使用节点选择器时,OpenShift Container Platform 会将 pod 调度到包含匹配标签的节点。
您可向节点、计算机器集或机器配置添加标签。将标签添加到计算机器集可确保节点或机器停机时,新节点具有该标签。如果节点或机器停机,添加到节点或机器配置的标签不会保留。
要将节点选择器添加到现有 pod 中,将节点选择器添加到该 pod 的控制对象中,如 ReplicaSet 对象、DaemonSet 对象、StatefulSet 对象、Deployment 对象或 DeploymentConfig 对象。任何属于该控制对象的现有 pod 都会在具有匹配标签的节点上重新创建。如果要创建新 pod,可以将节点选择器直接添加到 pod 规格中。如果 pod 没有控制对象,您必须删除 pod,编辑 pod 规格并重新创建 pod。
您不能直接将节点选择器添加到现有调度的 pod 中。
先决条件
要将节点选择器添加到现有 pod 中,请确定该 pod 的控制对象。例如, router-default-66d5cf9464-m2g75 pod 由 router-default-66d5cf9464 副本集控制:
oc describe pod router-default-66d5cf9464-7pwkc
$ oc describe pod router-default-66d5cf9464-7pwkc
输出示例
Web 控制台在 pod YAML 的 ownerReferences 下列出控制对象:
流程
使用计算机器集或直接编辑节点,为节点添加标签:
在创建节点时,使用
MachineSet对象向由计算机器集管理的节点添加标签:运行以下命令,将标签添加到
MachineSet对象中:oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-api$ oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来向计算机器集中添加标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc edit命令验证标签是否已添加到MachineSet对象中:例如:
oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
直接向节点添加标签:
为节点编辑
Node对象:oc label nodes <name> <key>=<value>
$ oc label nodes <name> <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如,若要为以下节点添加标签:
oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east
$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来向节点添加标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证标签是否已添加到节点:
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.30.3
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.30.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
将匹配的节点选择器添加到 pod:
要将节点选择器添加到现有和未来的 pod,请向 pod 的控制对象添加节点选择器:
带有标签的
ReplicaSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加节点选择器。
要将节点选择器添加到一个特定的新 pod,直接将选择器添加到
Pod对象中:使用节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您不能直接将节点选择器添加到现有调度的 pod 中。
2.13. Run Once Duration Override Operator 复制链接链接已复制到粘贴板!
2.13.1. Run Once Duration Override Operator 概述 复制链接链接已复制到粘贴板!
您可以使用 Run Once Duration Override Operator 指定运行一次 pod 的最大时间限制。
2.13.1.1. 关于 Run Once Duration Override Operator 复制链接链接已复制到粘贴板!
OpenShift Container Platform 依赖于运行一次 pod 来执行诸如部署 pod 或执行构建等任务。Run-once pod 是带有 RestartPolicy 为 Never 或 OnFailure 的 pod。
集群管理员可以使用 Run Once Duration Override Operator 来强制限制这些运行一次 pod 处于活跃状态的时间。时间限制过期后,集群将尝试主动终止这些 pod。具有此类限制的主要原因是防止构建等任务运行过长的时间。
要将 Run Once Duration Override Operator 中的运行一次持续时间覆盖应用到运行一次的 pod,您必须在每个适用的命名空间中启用它。
如果运行一次的 pod 和 Run Once Duration Override Operator 都设置了其 activeDeadlineSeconds 值,则会使用这两个值中的低值。
2.13.2. Run Once Duration Override Operator 发行注记 复制链接链接已复制到粘贴板!
集群管理员可以使用 Run Once Duration Override Operator 来强制对运行一次 pod 处于活跃状态的时间强制限制。时间限制过期后,集群会尝试终止运行一次的 pod。具有此类限制的主要原因是防止构建等任务运行过长的时间。
要将 Run Once Duration Override Operator 中的运行一次持续时间覆盖应用到运行一次的 pod,您必须在每个适用的命名空间中启用它。
本发行注记介绍了为 OpenShift Container Platform 的 Run Once Duration Override Operator 的开发。
有关 Run Once Duration Override Operator 的概述,请参阅关于 Run Once Duration Override Operator。
2.13.2.1. Run Once Duration Override Operator 1.2.0 复制链接链接已复制到粘贴板!
发布日期: 2024 年 10 月 16 日
以下公告可用于 Run Once Duration Override Operator 1.2.0: (RHSA-2024:7548)
2.13.2.1.1. 程序错误修复 复制链接链接已复制到粘贴板!
- 此 Run Once Duration Override Operator 发行版本解决了几个常见漏洞和暴露 (CVE)。
2.13.3. 覆盖运行一次 pod 的活动期限 复制链接链接已复制到粘贴板!
您可以使用 Run Once Duration Override Operator 指定运行一次 pod 的最大时间限制。通过在命名空间上启用运行一次持续时间覆盖,以后在该命名空间中创建或更新的所有运行一次 pod 将其 activeDeadlineSeconds 字段设置为 Run Once Duration Override Operator 指定的值。
如果运行一次的 pod 和 Run Once Duration Override Operator 都设置了其 activeDeadlineSeconds 值,则会使用这两个值中的低值。
2.13.3.1. 安装 Run Once Duration Override Operator 复制链接链接已复制到粘贴板!
您可以使用 Web 控制台安装 Run Once Duration Override Operator。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
为 Run Once Duration Override Operator 创建所需的命名空间。
- 进行 Administration → Namespaces,点 Create Namespace。
-
在 Name 字段中输入
openshift-run-once-duration-override-operator,然后点 Create。
安装 Run Once Duration Override Operator。
- 导航至 Operators → OperatorHub。
- 在过滤器框中输入 Run Once Duration Override Operator。
- 选择 Run Once Duration Override Operator 并点 Install。
在 Install Operator 页面中:
- Update channel 设置为 stable,它会安装 Run Once Duration Override Operator 的最新稳定版本。
- 选择 A specific namespace on the cluster。
- 从 Installed namespace 下的下拉菜单中选择 openshift-run-once-duration-override-operator。
选择一个 更新批准策略。
- Automatic 策略允许 Operator Lifecycle Manager(OLM)在有新版本可用时自动更新 Operator。
- Manual 策略需要拥有适当凭证的用户批准 Operator 更新。
- 点 Install。
创建
RunOnceDurationOverride实例。- 在 Operators → Installed Operators 页面中,点 Run Once Duration Override Operator。
- 选择 Run Once Duration Override 选项卡,然后点 Create RunOnceDurationOverride。
根据需要编辑设置。
在
runOnceDurationOverride部分下,您可以更新spec.activeDeadlineSeconds值(如果需要)。预定义的值为3600秒,或 1 小时。- 点 Create。
验证
- 登录到 OpenShift CLI。
验证所有 pod 均已创建并正确运行。
oc get pods -n openshift-run-once-duration-override-operator
$ oc get pods -n openshift-run-once-duration-override-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE run-once-duration-override-operator-7b88c676f6-lcxgc 1/1 Running 0 7m46s runoncedurationoverride-62blp 1/1 Running 0 41s runoncedurationoverride-h8h8b 1/1 Running 0 41s runoncedurationoverride-tdsqk 1/1 Running 0 41s
NAME READY STATUS RESTARTS AGE run-once-duration-override-operator-7b88c676f6-lcxgc 1/1 Running 0 7m46s runoncedurationoverride-62blp 1/1 Running 0 41s runoncedurationoverride-h8h8b 1/1 Running 0 41s runoncedurationoverride-tdsqk 1/1 Running 0 41sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13.3.2. 在命名空间中启用运行一次持续时间覆盖 复制链接链接已复制到粘贴板!
要将 Run Once Duration Override Operator 中的运行一次持续时间覆盖应用到运行一次的 pod,您必须在每个适用的命名空间中启用它。
先决条件
- 已安装 Run Once Duration Override Operator。
流程
- 登录到 OpenShift CLI。
添加标签,为命名空间启用运行一次持续时间覆盖:
oc label namespace <namespace> \ runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=true$ oc label namespace <namespace> \1 runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要启用运行一次持续时间覆盖的命名空间。
在此命名空间中启用运行一次持续时间覆盖后,在此命名空间中未来创建的运行一次的 pod 会将其 activeDeadlineSeconds 字段设置为 Run Once Duration Override Operator 的覆盖值。此命名空间中的现有 pod 也会在下一次更新时将设置其 activeDeadlineSeconds 值。
验证
在启用了运行一次持续时间覆盖的命名空间中创建一个测试运行一次 pod:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 pod 是否已设置其
activeDeadlineSeconds字段:oc get pods -n <namespace> -o yaml | grep activeDeadlineSeconds
$ oc get pods -n <namespace> -o yaml | grep activeDeadlineSecondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
activeDeadlineSeconds: 3600
activeDeadlineSeconds: 3600Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13.3.3. 更新运行一次活跃截止时间覆盖值 复制链接链接已复制到粘贴板!
您可以自定义 Run Once Duration Override Operator 适用于运行一次的 pod 的覆盖值。预定义的值为 3600 秒,或 1 小时。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 已安装 Run Once Duration Override Operator。
流程
- 登录到 OpenShift CLI。
编辑
RunOnceDurationOverride资源:oc edit runoncedurationoverride cluster
$ oc edit runoncedurationoverride clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新
activeDeadlineSeconds字段:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
activeDeadlineSeconds字段设置为所需的值,以秒为单位。
- 保存文件以使改变生效。
在启用了运行一次持续时间覆盖的命名空间中创建的任何运行后 pod 都会将其 activeDeadlineSeconds 字段设置为这个新值。这些命名空间中的现有运行一次 pod 会在更新时收到这个新值。
2.13.4. 卸载 Run Once Duration Override Operator 复制链接链接已复制到粘贴板!
您可以通过卸载 Operator 并删除其相关资源,从 OpenShift Container Platform 中删除 Run Once Duration Override Operator。
2.13.4.1. 卸载 Run Once Duration Override Operator 复制链接链接已复制到粘贴板!
您可以使用 Web 控制台卸载 Run Once Duration Override Operator。卸载 Run Once Duration Override Operator 不会取消设置运行一次的 pod 的 activeDeadlineSeconds 字段,但它不再将覆盖值应用到将来的运行一次 Pod。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
- 已安装 Run Once Duration Override Operator。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
- 导航到 Operators → Installed Operators。
-
从 Project 下拉列表中选择
openshift-run-once-duration-override-operator。 删除
RunOnceDurationOverride实例。- 点 Run Once Duration Override Operator 并选择 Run Once Duration Override 选项卡。
-
点 集群 条目旁的 Options 菜单
并选择 Delete RunOnceDurationOverride。
- 在确认对话框中,点 Delete。
卸载 Run Once Duration Override Operator Operator。
- 导航到 Operators → Installed Operators。
-
点 Run Once Duration Override Operator 条目旁边的 Options 菜单
,并点 Uninstall Operator。
- 在确认对话框中,点 Uninstall。
2.13.4.2. 卸载 Run Once Duration Override Operator 资源 复制链接链接已复制到粘贴板!
另外,在卸载 Run Once Duration Override Operator 后,您可以从集群中删除其相关资源。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
- 您已卸载了 Run Once Duration Override Operator。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
删除安装 Run Once Duration Override Operator 时创建的 CRD:
- 进入到 Administration → CustomResourceDefinitions。
-
在 Name 字段中输入
RunOnceDurationOverride来过滤 CRD。 -
点 RunOnceDurationOverride CRD 旁边的选项菜单
,选择 Delete CustomResourceDefinition。
- 在确认对话框中,点 Delete。
删除
openshift-run-once-duration-override-operator命名空间。- 导航至 Administration → Namespaces。
-
在过滤器框中输入
openshift-run-once-duration-override-operator。 -
点 openshift-run-once-duration-override-operator 条目旁的 Options 菜单
并选择 Delete Namespace。
-
在确认对话框中,输入
openshift-run-once-duration-override-operator并点 Delete。
从启用的命名空间中删除运行一次持续时间覆盖标签。
- 导航至 Administration → Namespaces。
- 选择您的命名空间。
- 点 Labels 字段旁的 Edit。
- 删除 runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=true 标签,然后点 Save。
2.14. 在 Linux 用户命名空间中运行 pod 复制链接链接已复制到粘贴板!
Linux 用户命名空间允许管理员隔离容器用户和组标识符 (UID 和 GID),以便容器可以在用户命名空间中拥有与它运行的主机系统不同的权限集。这允许容器在用户命名空间中以完全特权运行容器,但对主机上的操作可以以非特权运行这些进程。
默认情况下,容器在主机系统的 root 用户命名空间中运行。当容器需要仅在该用户命名空间中可用的功能时,在主机用户命名空间中运行容器很有用。但是,这会引入一些安全问题,如容器逃逸问题(container breakout)- 容器中的一个进程会逃逸到主机中,这个进程将可以访问或修改主机上的文件。
在独立用户命名空间中运行容器可以缓解容器逃逸的问题,以及其他可能会被破坏的容器对其他 pod 和节点本身造成影响的安全漏洞。
您可以通过将 pod 规格中的 hostUsers 参数设置为 false 来配置 Linux 用户命名空间,如以下步骤所示。
对 Linux 用户命名空间的支持只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
2.14.1. 配置 Linux 用户命名空间支持 复制链接链接已复制到粘贴板!
先决条件
您可以通过编辑名为
cluster的FeatureGateCR 为集群启用所需的技术预览功能:oc edit featuregate cluster
$ oc edit featuregate clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow FeatureGateCR 示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 启用所需的
UserNamespacesSupport和ProcMountType功能。
警告在集群中启用
TechPreviewNoUpgrade功能集无法撤消,并会阻止次版本更新。此功能集允许您在测试集群中启用这些技术预览功能,您可以在测试集群中完全测试它们。不要在生产环境集群中启用此功能。保存更改后,会创建新的机器配置,然后更新机器配置池,并在应用更改时在每个节点上调度。
您在 worker 节点上启用了 crun 容器运行时。crun 是目前发布的唯一一个支持用户命名空间的 OCI 运行时。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
运行以下命令,编辑部署 pod 的 OpenShift Container Platform 命名空间的默认用户 ID (UID) 和组 ID (GID) 范围:
oc edit ns/<namespace_name>
$ oc edit ns/<namespace_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 命名空间示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意范围 1000/10000 代表以 ID 1000 开始的 10,000 个值,因此它指定了从 1000 到 10,999 的 ID 范围。
通过创建一个配置为使用
restricted配置集运行,并将hostUsers参数设置为false的 pod 来启用 Linux 用户命名空间。创建一个类似以下示例的 YAML 文件:
pod 规格示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建 pod:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检查您创建的 pod 容器中使用的 pod 用户和组 ID。pod 位于 Linux 用户命名空间中。
使用您的 pod 中的容器启动一个 shell 会话:
oc rsh -c <container_name> pod/<pod_name>
$ oc rsh -c <container_name> pod/<pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 示例命令
oc rsh -c userns-container_name pod/userns-pod
$ oc rsh -c userns-container_name pod/userns-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 显示在容器内使用的用户和组 ID:
id
sh-5.1$ idCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
uid=1000(1000) gid=1000(1000) groups=1000(1000)
uid=1000(1000) gid=1000(1000) groups=1000(1000)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 显示容器用户命名空间中使用的用户 ID:
lsns -t user
sh-5.1$ lsns -t userCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NS TYPE NPROCS PID USER COMMAND 4026532447 user 3 1 1000 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
NS TYPE NPROCS PID USER COMMAND 4026532447 user 3 1 1000 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 10001 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 进程的 UID 是
1000,这与您在 pod 规格中设置的相同。
检查创建 pod 的节点上使用的 pod 用户 ID。节点位于 Linux 用户命名空间之外。此用户 ID 应该与容器中使用的 UID 不同。
为该节点启动一个 debug 会话:
oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
$ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9Copy to Clipboard Copied! Toggle word wrap Toggle overflow 示例命令
oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
$ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
/host设置为 debug shell 中的根目录:chroot /host
sh-5.1# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 显示节点用户命名空间中使用的用户 ID:
lsns -t user
sh-5.1# lsns -t userCopy to Clipboard Copied! Toggle word wrap Toggle overflow 示例命令
NS TYPE NPROCS PID USER COMMAND 4026531837 user 233 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 28 4026532447 user 1 4767 2908816384 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
NS TYPE NPROCS PID USER COMMAND 4026531837 user 233 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 28 4026532447 user 1 4767 2908816384 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 10001 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 进程的 UID 是
2908816384,它与您在容器集规格中设置的不同。
第 3 章 使用自定义 Metrics Autoscaler Operator 自动扩展 pod 复制链接链接已复制到粘贴板!
3.1. 发行注记 复制链接链接已复制到粘贴板!
3.1.1. 自定义 Metrics Autoscaler Operator 发行注记 复制链接链接已复制到粘贴板!
Red Hat OpenShift 的自定义 Metrics Autoscaler Operator 发行注记介绍了新的功能和增强功能、已弃用的功能以及已知的问题。
Custom Metrics Autoscaler Operator 使用基于 Kubernetes 的 Event Driven Autoscaler (KEDA),并基于 OpenShift Container Platform 横向自动扩展(HPA)构建。
Custom Metrics Autoscaler Operator for Red Hat OpenShift 作为可安装的组件提供,它与 OpenShift Container Platform 核心不同。Red Hat OpenShift Container Platform 生命周期政策概述了发行版本兼容性。
3.1.1.1. 支持的版本 复制链接链接已复制到粘贴板!
下表为每个 OpenShift Container Platform 版本定义自定义 Metrics Autoscaler Operator 版本。
| 版本 | OpenShift Container Platform 版本 | 公开发行(GA) |
|---|---|---|
| 2.14.1 | 4.16 | 公开发行(GA) |
| 2.14.1 | 4.15 | 公开发行(GA) |
| 2.14.1 | 4.14 | 公开发行(GA) |
| 2.14.1 | 4.13 | 公开发行(GA) |
| 2.14.1 | 4.12 | 公开发行(GA) |
3.1.1.2. 自定义 Metrics Autoscaler Operator 2.14.1-467 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.14.1-467 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供 CVE 和程序错误修复。以下公告可用于 RHSA-2024:7348。
在安装此版本的 Custom Metrics Autoscaler Operator 之前,请删除任何以前安装的技术预览版本或基于 Kubernetes 的社区支持的 Event Driven Autoscaler (KEDA)。
3.1.1.2.1. 程序错误修复 复制链接链接已复制到粘贴板!
- 在以前的版本中,自定义 Metrics Autoscaler Operator pod 的 root 文件系统是可写的,这并不是必需的,并可能会造成安全问题。在这个版本中,pod root 文件系统为只读方式,解决了潜在的安全问题。(OCPBUGS-37989)
3.1.2. Custom Metrics Autoscaler Operator 的过去发行版本发行注记 复制链接链接已复制到粘贴板!
以下发行注记适用于以前的自定义 Metrics Autoscaler Operator 版本。
有关当前版本,请参阅自定义 Metrics Autoscaler Operator 发行注记。
3.1.2.1. 自定义 Metrics Autoscaler Operator 2.14.1-454 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.14.1-454 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供 CVE、新功能和程序错误修复。以下公告可用于 RHBA-2024:5865。
在安装此版本的 Custom Metrics Autoscaler Operator 之前,请删除任何以前安装的技术预览版本或基于 Kubernetes 的社区支持的 Event Driven Autoscaler (KEDA)。
3.1.2.1.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
Custom Metrics Autoscaler Operator 现在可以使用 Cron trigger,根据每个小时的调度来扩展 pod。当您指定的时间段启动时,Custom Metrics Autoscaler Operator 会将 pod 扩展至所需数量。当时间段结束时,Operator 会缩减到以前的级别。
如需更多信息,请参阅了解 Cron 触发器。
3.1.2.1.2. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,如果您更改了
KedaController自定义资源中的审计配置参数,则keda-metrics-server-audit-policy配置映射不会被更新。因此,在自定义 Metrics Autoscaler 初始部署后,您无法更改审计配置参数。在这个版本中,对审计配置的更改现在可以在配置映射中正确显示,允许您在安装后随时更改审计配置。(OCPBUGS-32521)
3.1.2.2. Custom Metrics Autoscaler Operator 2.13.1 发行注记 复制链接链接已复制到粘贴板!
此 Custom Metrics Autoscaler Operator 2.13.1-421 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修正。以下公告可用于 RHBA-2024:4837。
在安装此版本的 Custom Metrics Autoscaler Operator 之前,请删除任何以前安装的技术预览版本或基于 Kubernetes 的社区支持的 Event Driven Autoscaler (KEDA)。
3.1.2.2.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
Custom Metrics Autoscaler Operator 现在可以使用自定义服务 CA 证书安全地连接到启用了 TLS 的指标源,如外部 Kafka 集群或外部 Prometheus 服务。默认情况下,Operator 仅使用自动生成的服务证书来连接到 on-cluster 服务。KedaController 对象中有一个新字段,您可以使用配置映射载入自定义服务器 CA 证书以连接到外部服务。
如需更多信息,请参阅 Custom Metrics Autoscaler 的自定义 CA 证书。
3.1.2.2.2. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,
custom-metrics-autoscaler和custom-metrics-autoscaler-adapter镜像缺少时区信息。因此,带有cron触发器的扩展对象无法正常工作,因为控制器无法找到时区信息。在这个版本中,镜像构建被更新为包含时区信息。因此,包含cron触发器的对象现在可以正常工作。Custom Metrics Autoscaler 目前不支持包含cron触发器的扩展对象。(OCPBUGS-34018)
3.1.2.3. 自定义 Metrics Autoscaler Operator 2.12.1-394 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.12.1-394 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了程序错误修正。以下公告可用于 RHSA-2024:2901。
在安装此版本的 Custom Metrics Autoscaler Operator 之前,请删除任何以前安装的技术预览版本或基于 Kubernetes 的社区支持的 Event Driven Autoscaler (KEDA)。
3.1.2.3.1. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,当对无效 JSON 的特定表单进行 unmarshaling 处理时,
protojson.Unmarshal函数会进入一个死循环。当 unmarshaling 到包含google.protobuf.Any值或设置了UnmarshalOptions.DiscardUnknown选项时,可能会出现此条件。此发行版本解决了这个问题。(OCPBUGS-30305) -
在以前的版本中,当解析多部分表单时,可以明确使用
Request.ParseMultipartForm方法明,或使用Request.FormValue、Request.PostFormValue或Request.FormFile方法隐式应用,解析表单的总大小限制不适用于消耗的内存。这可能导致内存耗尽。在这个版本中,解析过程可以正确地限制最大大小。(OCPBUGS-30360) -
在以前的版本中,当遵循 HTTP 重定向到不在匹配子域或初始域的完全匹配的域时,HTTP 客户端不会转发敏感标头,如
Authorization或Cookie。例如,从example.com到www.example.com的重定向会转发Authorization标头,但重定向到www.example.org不会转发标头。此发行版本解决了这个问题。(OCPBUGS-30365) -
在以前的版本中,验证包含带有未知公钥算法的证书的证书链会导致证书验证过程 panic。此条件会影响将
Config.ClientAuth参数设置为VerifyClientCertIfGiven或RequireAndVerifyClientCert值的所有加密和 Transport Layer Security (TLS) 客户端和服务器。默认行为是 TLS 服务器无法验证客户端证书。此发行版本解决了这个问题。(OCPBUGS-30370) -
在以前的版本中,如果从
MarshalJSON方法返回的错误包含用户控制的数据,攻击者可以使用数据中断 HTML 模板软件包的上下文自动转义行为。此条件允许后续操作将意外内容注入模板。此发行版本解决了这个问题。(OCPBUGS-30397) -
在以前的版本中,
net/http和golang.org/x/net/http2Go 软件包没有限制为 HTTP/2 请求读取的CONTINUATION帧的数量。这个条件可能会导致过量消耗 CPU。此发行版本解决了这个问题。(OCPBUGS-30894)
3.1.2.4. 自定义 Metrics Autoscaler Operator 2.12.1-384 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.12.1-384 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。以下公告可用于 RHBA-2024:2043。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.4.1. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,
custom-metrics-autoscaler和custom-metrics-autoscaler-adapter镜像缺少时区信息。因此,带有cron触发器的扩展对象无法正常工作,因为控制器无法找到时区信息。在这个版本中,镜像构建被更新为包含时区信息。因此,包含cron触发器的对象现在可以正常工作。(OCPBUGS-32395)
3.1.2.5. 自定义 Metrics Autoscaler Operator 2.12.1-376 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.12.1-376 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了安全更新和程序错误修复。以下公告可用于 RHSA-2024:1812。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.5.1. 程序错误修复 复制链接链接已复制到粘贴板!
- 在以前的版本中,如果在扩展对象元数据中指定无效值,如不存在的命名空间,则底层 scaler 客户端无法释放或关闭其客户端描述符,从而导致内存泄漏。在这个版本中,当出现错误时可以正确地关闭底层客户端描述符,从而导致内存泄漏。(OCPBUGS-30145)
-
在以前的版本中,
keda-metrics-apiserverpod 的ServiceMonitor自定义资源 (CR) 无法正常工作,因为 CR 引用了http的错误指标端口名称。在这个版本中,ServiceMonitorCR 修正了引用metrics的正确端口名称。因此,Service Monitor 可以正常工作。(OCPBUGS-25806)
3.1.2.6. 自定义 Metrics Autoscaler Operator 2.11.2-322 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.11.2-322 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了安全更新和程序错误修复。以下公告可用于 RHSA-2023:6144。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.6.1. 程序错误修复 复制链接链接已复制到粘贴板!
- 因为自定义 Metrics Autoscaler Operator 版本 3.11.2-311 已被发布,所以在 Operator 部署中不需要卷挂载,所以自定义 Metrics Autoscaler Operator pod 会每 15 分钟重启。在这个版本中,在 Operator 部署中添加了所需的卷挂载。因此,Operator 不再每 15 分钟重启。(OCPBUGS-22361)
3.1.2.7. 自定义 Metrics Autoscaler Operator 2.11.2-311 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.11.2-311 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。自定义 Metrics Autoscaler Operator 2.11.2-311 的组件在 RHBA-2023:5981 中发布。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.7.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
自定义 Metrics Autoscaler Operator 2.11.2-311 可以安装在 OpenShift ROSA 和 OpenShift Dedicated 受管集群上。自定义 Metrics Autoscaler Operator 的早期版本只能安装在 openshift-keda 命名空间中。这导致 Operator 无法安装到 OpenShift ROSA 和 OpenShift Dedicated 集群中。此自定义 Metrics Autoscaler 版本允许安装到其他命名空间,如 openshift-operators 或 keda,从而可以安装到 ROSA 和 Dedicated 集群中。
3.1.2.7.2. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,如果安装并配置 Custom Metrics Autoscaler Operator,但没有使用,OpenShift CLI 会在任何
oc命令输入后报告could not get resource list for external.metrics.k8s.io/v1beta1: Got empty response for: external.metrics.k8s.io/v1beta1错误。虽然这个消息并没有什么危害,但可能会造成混淆。在这个版本中,Got empty response for: external.metrics…不再会出现。(OCPBUGS-15779) - 在以前的版本中,任何注解或标签更改为由自定义 Metrics Autoscaler 管理的对象在修改 Keda Controller 时(例如在配置更改后)会被自定义 Metrics Autoscaler 恢复。这会导致对象中的标签持续更改。自定义 Metrics Autoscaler 现在使用自己的注解来管理标签和注解,注解或标签不再被错误地恢复。(OCPBUGS-15590)
3.1.2.8. 自定义 Metrics Autoscaler Operator 2.10.1-267 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.10.1-267 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。自定义 Metrics Autoscaler Operator 2.10.1-267 组件在 RHBA-2023:4089 中发布。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.8.1. 程序错误修复 复制链接链接已复制到粘贴板!
-
在以前的版本中,
custom-metrics-autoscaler和custom-metrics-autoscaler-adapter镜像不包含时区信息。因此,带有 cron 触发器的扩展对象无法正常工作,因为控制器无法找到时区信息。在这个版本中,镜像构建包含时区信息。因此,包含 cron 触发器的对象现在可以正常工作。(OCPBUGS-15264) -
在以前的版本中,自定义 Metrics Autoscaler Operator 会尝试拥有所有受管对象,包括其他命名空间中的对象和集群范围的对象。因此,自定义 Metrics Autoscaler Operator 无法创建角色绑定来读取 API 服务器所需的凭证。这会导致
kube-system命名空间中出现错误。在这个版本中,自定义 Metrics Autoscaler Operator 会跳过将ownerReference字段添加到另一个命名空间中的任何对象或任何集群范围的对象。现在,角色绑定会被创建,且没有任何错误。(OCPBUGS-15038) -
在以前的版本中,自定义 Metrics Autoscaler Operator 将
ownerReferences字段添加到openshift-keda命名空间中。虽然这不会造成功能问题,但存在此字段可能会给集群管理员造成混淆。在这个版本中,自定义 Metrics Autoscaler Operator 不会将ownerReference字段添加到openshift-keda命名空间中。因此,openshift-keda命名空间不再有一个 superfluousownerReference字段。(OCPBUGS-15293) -
在以前的版本中,如果您使用使用 pod 身份以外的身份验证方法配置的 Prometheus 触发器,并且
podIdentity参数设置为none,则触发器将无法扩展。在这个版本中,OpenShift 的自定义 Metrics Autoscaler 可以正确地处理nonepod 身份提供程序类型。因此,使用 pod 身份以外的身份验证方法配置的 Prometheus 触发器,其podIdentity参数设置为none现在可以正确扩展。(OCPBUGS-15274)
3.1.2.9. 自定义 Metrics Autoscaler Operator 2.10.1 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.10.1 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。自定义 Metrics Autoscaler Operator 2.10.1 的组件在 RHEA-2023:3199 中发布。
在安装自定义 Metrics Autoscaler Operator 的这个版本前,请删除任何以前安装的技术预览版本或社区支持的 KEDA 版本。
3.1.2.9.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
3.1.2.9.1.1. 自定义 Metrics Autoscaler Operator 正式发布 复制链接链接已复制到粘贴板!
现在,自定义 Metrics Autoscaler Operator 从自定义 Metrics Autoscaler Operator 版本 2.10.1 开始正式发布。
使用扩展作业进行扩展只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
3.1.2.9.1.2. 性能指标 复制链接链接已复制到粘贴板!
现在,您可以使用 Prometheus Query Language (PromQL) 查询自定义 Metrics Autoscaler Operator 的指标。
3.1.2.9.1.3. 暂停扩展对象的自定义指标自动扩展 复制链接链接已复制到粘贴板!
现在,您可以根据需要暂停扩展对象的自动扩展,并在就绪时恢复自动扩展。
3.1.2.9.1.4. 副本回退到扩展的对象 复制链接链接已复制到粘贴板!
现在,如果扩展对象无法从源获取指标,您可以指定要回退到的副本数。
3.1.2.9.1.5. 为扩展对象自定义 HPA 命名 复制链接链接已复制到粘贴板!
现在,您可以在扩展的对象中为 pod 横向自动扩展指定自定义名称。
3.1.2.9.1.6. 激活和扩展阈值 复制链接链接已复制到粘贴板!
因为 pod 横向自动扩展 (HPA) 无法扩展到 0 个副本或从 0 个副本进行扩展,所以在 HPA 执行缩放后,自定义 Metrics Autoscaler Operator 会进行该扩展。现在,您可以根据副本数指定 HPA 接管自动扩展的时间。这可以提高扩展策略的灵活性。
3.1.2.10. 自定义 Metrics Autoscaler Operator 2.8.2-174 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.8.2-174 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。Custom Metrics Autoscaler Operator 2.8.2-174 组件在 RHEA-2023:1683 中发布。
自定义 Metrics Autoscaler Operator 版本 2.8.2-174 是一个技术预览功能。
3.1.2.10.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
3.1.2.10.1.1. Operator 升级支持 复制链接链接已复制到粘贴板!
现在,您可以从 Custom Metrics Autoscaler Operator 的早期版本升级。有关升级 Operator 的信息,请参阅"添加资源"中的"删除 Operator 更新频道"。
3.1.2.10.1.2. must-gather 支持 复制链接链接已复制到粘贴板!
现在,您可以使用 OpenShift Container Platform must-gather 工具收集有关自定义 Metrics Autoscaler Operator 及其组件的数据。目前,使用带有自定义 Metrics Autoscaler 的 must-gather 工具的过程与其他 Operator 不同。如需更多信息,请参阅"添加资源"中的调试数据。
3.1.2.11. 自定义 Metrics Autoscaler Operator 2.8.2 发行注记 复制链接链接已复制到粘贴板!
此自定义 Metrics Autoscaler Operator 2.8.2 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。自定义 Metrics Autoscaler Operator 2.8.2 组件在 RHSA-2023:1042 中发布。
自定义 Metrics Autoscaler Operator 版本 2.8.2 是一个技术预览功能。
3.1.2.11.1. 新功能及功能增强 复制链接链接已复制到粘贴板!
3.1.2.11.1.1. 审计日志记录 复制链接链接已复制到粘贴板!
现在,您可以收集并查看自定义 Metrics Autoscaler Operator 及其相关组件的审计日志。审计日志是安全相关的按时间排序的记录,记录各个用户、管理员或其他系统组件影响系统的一系列活动。
3.1.2.11.1.2. 基于 Apache Kafka 指标扩展应用程序 复制链接链接已复制到粘贴板!
现在,您可以使用 KEDA Apache kafka 触发器/scaler 根据 Apache Kafka 主题扩展部署。
3.1.2.11.1.3. 根据 CPU 指标扩展应用程序 复制链接链接已复制到粘贴板!
现在,您可以使用 KEDA CPU 触发器/scaler 根据 CPU 指标扩展部署。
3.1.2.11.1.4. 根据内存指标扩展应用程序 复制链接链接已复制到粘贴板!
现在,您可以使用 KEDA 内存触发器/scaler 根据内存指标扩展部署。
3.2. 自定义 Metrics Autoscaler Operator 概述 复制链接链接已复制到粘贴板!
作为开发者,您可以使用 Custom Metrics Autoscaler Operator for Red Hat OpenShift 指定 OpenShift Container Platform 如何根据不基于 CPU 或内存的自定义指标自动增加或减少部署、有状态集、自定义资源或作业的数量。
Custom Metrics Autoscaler Operator 是一个基于 Kubernetes Event Driven Autoscaler (KEDA) 的可选 Operator,允许使用 pod 指标以外的其他指标源扩展工作负载。
自定义指标自动扩展目前仅支持 Prometheus、CPU、内存和 Apache Kafka 指标。
Custom Metrics Autoscaler Operator 根据特定应用程序的自定义外部指标扩展 pod。您的其他应用程序继续使用其他扩展方法。您可以配置 触发器 (也称为 scaler),这是自定义指标自动扩展器用来决定如何扩展的事件和指标的来源。自定义指标自动扩展使用 metrics API 将外部指标转换为 OpenShift Container Platform 可以使用的形式。自定义指标自动扩展会创建一个执行实际缩放的 pod 横向自动扩展(HPA)。
要使用自定义指标自动扩展,您可以为工作负载创建一个 ScaledObject 或 ScaledJob 对象,这是定义扩展元数据的自定义资源(CR)。您可以指定要缩放的部署或作业、要缩放的指标源 (trigger) 以及其他参数,如允许的最小和最大副本数。
您只能为每个您要扩展的工作负载创建一个扩展对象或扩展作业。另外,您不能在同一工作负载中使用扩展的对象或扩展作业以及 pod 横向自动扩展 (HPA)。
自定义指标自动扩展与 HPA 不同,可以缩减为零。如果将自定义指标自动扩展 CR 中的 minReplicaCount 值设置为 0,自定义指标自动扩展会将工作负载从 1 缩减到 0 个副本或从 0 个副本扩展到 1。这称为 激活阶段。扩展至 1 个副本后,HPA 会控制扩展。这称为 扩展阶段。
某些触发器允许您更改由集群指标自动扩展扩展的副本数量。在所有情况下,配置激活阶段的参数始终使用相同的短语,前缀为 激活。例如,如果 threshold 参数配置缩放,则 activationThreshold 将配置激活。通过配置激活和扩展阶段,您可以提高扩展策略的灵活性。例如,您可以配置更高的激活阶段,以便在指标特别低时防止扩展或缩减。
当每个决策不同时,激活值的优先级高于扩展值。例如,如果 threshold 被设置为 10,并且 activationThreshold 为 50,如果指标报告 40,则缩放器不会激活,并且 pod 缩减为零,即使 HPA 需要 4 个实例。
图 3.1. 自定义指标自动扩展工作流
- 您可以为集群中的工作负载创建或修改扩展对象自定义资源。对象包含该工作负载的扩展配置。在接受新对象前,OpenShift API 服务器将其发送到自定义指标自动扩展准入 webhook 进程,以确保对象有效。如果验证成功,API 服务器会保留对象。
- 自定义指标自动扩展控制器监视是否有新的或修改的扩展对象。当 OpenShift API 服务器通知更改控制器时,控制器会监控任何外部触发器源(也称为数据源)在对象中指定以更改指标数据。一个或多个 scalers 请求从外部触发器源扩展数据。例如,对于 Kafka 触发器类型,控制器使用 Kafka scaler 与 Kafka 实例通信来获取触发器请求的数据。
- 控制器为扩展的对象创建一个 pod 横向自动扩展对象。因此,Horizontal Pod Autoscaler (HPA) Operator 开始监控与触发器关联的扩展数据。HPA 请求从集群 OpenShift API 服务器端点扩展数据。
- OpenShift API 服务器端点由自定义指标自动扩展指标适配器提供。当 metrics 适配器收到自定义指标的请求时,它使用 GRPC 连接控制器来请求它以获取从 scaler 接收的最新触发器数据。
- HPA 根据从 metrics adapter 接收的数据做出缩放决策,并通过增加或减少副本来扩展工作负载。
- 当它运行时,工作负载可能会影响扩展指标。例如,如果扩展工作负载以处理 Kafka 队列中的工作,则队列大小会在工作负载处理所有工作后减小。因此,工作负载会缩减。
-
如果指标位于
minReplicaCount值指定的范围内,自定义指标自动扩展控制器会禁用所有扩展,并将副本数保留为固定级别。如果指标超过该范围,自定义指标自动扩展控制器将启用扩展并允许 HPA 扩展工作负载。当禁用扩展时,HPA 不会执行任何操作。
3.2.1. Custom Metrics Autoscaler 的自定义 CA 证书 复制链接链接已复制到粘贴板!
默认情况下,自定义 Metrics Autoscaler Operator 使用自动生成的服务 CA 证书连接到 on-cluster 服务。
如果要使用需要自定义 CA 证书的非集群服务,您可以将所需的证书添加到配置映射中。然后,将配置映射添加到 KedaController 自定义资源,如安装自定义指标自动扩展中所述。Operator 在启动时加载这些证书,并将其注册为 Operator 信任的证书。
配置映射可以包含一个或多个包含一个或多个 PEM 编码 CA 证书的证书文件。或者,您可以为每个证书文件使用单独的配置映射。
如果稍后更新配置映射以添加额外的证书,您必须重启 keda-operator-* pod 以使更改生效。
3.3. 安装自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以使用 OpenShift Container Platform Web 控制台安装自定义 Metrics Autoscaler Operator。
安装会创建以下五个 CRD:
-
ClusterTriggerAuthentication -
KedaController -
ScaledJob -
ScaledObject -
TriggerAuthentication
3.3.1. 安装自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以使用以下步骤安装自定义 Metrics Autoscaler Operator。
先决条件
- 删除之前安装的 Cluster Metrics Autoscaler Operator 的技术预览版本。
删除基于社区的 KEDA 的任何版本。
另外,运行以下命令来删除 KEDA 1.x 自定义资源定义:
oc delete crd scaledobjects.keda.k8s.io
$ oc delete crd scaledobjects.keda.k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd triggerauthentications.keda.k8s.io
$ oc delete crd triggerauthentications.keda.k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:如果您需要自定义 Metrics Autoscaler Operator 连接到非集群服务,如外部 Kafka 集群或外部 Prometheus 服务,请将任何所需的服务 CA 证书放在配置映射中。配置映射必须存在于安装 Operator 的同一命名空间中。例如:
oc create configmap -n openshift-keda thanos-cert --from-file=ca-cert.pem
$ oc create configmap -n openshift-keda thanos-cert --from-file=ca-cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
- 在 OpenShift Container Platform Web 控制台中,点击 Operators → OperatorHub。
- 从可用的 Operator 列表中选择 Custom Metrics Autoscaler,然后点 Install。
- 在 Install Operator 页面中,确保为 Installation Mode 选择 All namespaces on the cluster(default) 选项。这会在所有命名空间中安装 Operator。
- 确保为 Installed Namespace 选择了 openshift-keda 命名空间。如果集群中不存在命名空间,OpenShift Container Platform 会创建命名空间。
- 点 Install。
列出自定义 Metrics Autoscaler Operator 组件来验证安装:
- 导航到 Workloads → Pods。
-
从下拉菜单中选择
openshift-keda项目,并验证custom-metrics-autoscaler-operator-*pod 正在运行。 -
进入到 Workloads → Deployments 以验证
custom-metrics-autoscaler-operator部署是否正在运行。
可选:使用以下命令在 OpenShift CLI 中验证安装:
oc get all -n openshift-keda
$ oc get all -n openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出结果类似如下:
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 安装
KedaController自定义资源,该资源创建所需的 CRD:- 在 OpenShift Container Platform web 控制台中,点击 Operators → Installed Operators。
- 点 Custom Metrics Autoscaler。
- 在 Operator Details 页面中,点 KedaController 选项卡。
在 KedaController 选项卡中,点 Create KedaController 并编辑文件。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定自定义 Metrics Autoscaler Operator 应该在其中扩展应用程序的单个命名空间。将它留空,或将其留空,以便在所有命名空间中扩展应用程序。此字段应具有命名空间或为空。默认值为空。
- 2
- 指定自定义 Metrics Autoscaler Operator 日志消息的详细程度。允许的值有
debug、info和error。默认为info。 - 3
- 指定 Custom Metrics Autoscaler Operator 日志消息的日志记录格式。允许的值是
console或json。默认为console。 - 4
- 可选:使用 CA 证书指定一个或多个配置映射,自定义 Metrics Autoscaler Operator 可以使用它们安全地连接到启用了 TLS 的指标源。
- 5
- 指定自定义 Metrics Autoscaler Metrics 服务器的日志记录级别。允许的值是
0(用于info)和4(用于debug)。默认值为0。 - 6
- 激活自定义 Metrics Autoscaler Operator 的审计日志记录,并指定要使用的审计策略,如"配置审计日志记录"部分中所述。
- 点 Create 创建 KEDA 控制器。
3.4. 了解自定义指标自动扩展触发器 复制链接链接已复制到粘贴板!
触发器(也称为 scalers)提供自定义 Metrics Autoscaler Operator 用来扩展 pod 的指标。
自定义指标自动扩展目前只支持 Prometheus、CPU、内存和 Apache Kafka 触发器。
您可以使用 ScaledObject 或 ScaledJob 自定义资源为特定对象配置触发器,如后面的章节中所述。
您可以配置一个证书颁发机构与扩展对象一起使用,或配置为集群中的所有扩展程序。
3.4.1. 了解 Prometheus 触发器 复制链接链接已复制到粘贴板!
您可以基于 Prometheus 指标扩展 pod,该指标可以使用已安装的 OpenShift Container Platform 监控或外部 Prometheus 服务器作为指标源。如需有关使用 OpenShift Container Platform 监控作为指标源的信息,请参阅"配置自定义指标自动扩展以使用 OpenShift Container Platform 监控"。
如果 Prometheus 从自定义指标自动扩展扩展的应用程序收集指标,请不要在自定义资源中将最小副本设置为 0。如果没有应用程序 pod,自定义指标自动扩展没有任何要缩放的指标。
带有 Prometheus 目标的扩展对象示例
- 1
- 指定 Prometheus 作为触发器类型。
- 2
- 指定 Prometheus 服务器的地址。本例使用 OpenShift Container Platform 监控。
- 3
- 可选:指定您要缩放的对象的命名空间。如果将 OpenShift Container Platform 监控用作指标的源,则需要此参数。
- 4
- 指定在
external.metrics.k8s.ioAPI 中标识指标的名称。如果您使用的是多个触发器,则所有指标名称都必须是唯一的。 - 5
- 指定触发扩展的值。必须指定为带引号的字符串值。
- 6
- 指定要使用的 Prometheus 查询。
- 7
- 指定要使用的身份验证方法。Prometheus scalers 支持 bearer 身份验证 (
bearer)、基本身份验证 (basic) 或 TLS 身份验证 (tls)。您可以在触发器身份验证中配置特定的身份验证参数,如以下部分所述。根据需要,您还可以使用 secret。 - 8
- 9
- 可选:指定在 Prometheus 目标丢失时触发器应如何进行操作。
-
如果为
true,当 Prometheus 目标丢失时触发器将继续操作。这是默认的行为。 -
如果为
false,当 Prometheus 目标丢失时触发器会返回错误。
-
如果为
- 10
- 可选:指定是否应跳过证书检查。例如,如果在测试环境中运行并使用 Prometheus 端点上的自签名证书,您可以跳过检查。
-
如果为
false,则执行证书检查。这是默认的行为。 如果为
true,则不会执行证书检查。重要不建议跳过检查。
-
如果为
3.4.1.1. 配置自定义指标自动扩展以使用 OpenShift Container Platform 监控 复制链接链接已复制到粘贴板!
您可以使用已安装的 OpenShift Container Platform Prometheus 监控作为自定义指标自动扩展使用的指标的来源。但是,需要执行一些额外的配置。
外部 Prometheus 源不需要这些步骤。
您必须执行以下任务,如本节所述:
- 创建一个服务帐户。
- 创建为服务帐户生成令牌的 secret。
- 创建触发器身份验证。
- 创建角色。
- 将该角色添加到服务帐户。
- 在 Prometheus 使用的触发器验证对象中引用令牌。
先决条件
- 必须安装 OpenShift Container Platform 监控。
- OpenShift Container Platform 监控中必须启用对用户定义的工作负载的监控监控,如创建用户定义的工作负载监控配置映射部分所述。
- 必须安装 Custom Metrics Autoscaler Operator。
流程
使用您要缩放的对象切换到项目:
oc project my-project
$ oc project my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果集群没有服务帐户和令牌,请创建服务帐户和令牌:
使用以下命令创建
服务帐户对象:oc create serviceaccount thanos
$ oc create serviceaccount thanos1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定服务帐户的名称。
创建
secretYAML 来生成服务帐户令牌:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定服务帐户的名称。
使用以下命令创建 secret 对象:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令查找分配给服务帐户的令牌:
oc describe serviceaccount thanos
$ oc describe serviceaccount thanos1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定服务帐户的名称。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 在触发器身份验证中使用此令牌。
使用服务帐户令牌创建触发器身份验证:
创建用于读取 Thanos 指标的角色:
使用以下参数创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 CR 对象:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建用于读取 Thanos 指标的角色绑定:
现在,您可以部署扩展的对象或扩展作业来为应用程序启用自动扩展,如"了解如何添加自定义指标自动扩展"中所述。要将 OpenShift Container Platform 监控用作源,在触发器或 scaler 中,您必须包括以下参数:
-
triggers.type必须是prometheus -
triggers.metadata.serverAddress必须是https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 -
triggers.metadata.authModes必须是bearer -
triggers.metadata.namespace必须设置为要缩放的对象的命名空间 -
triggers.authenticationRef必须指向上一步中指定的触发器身份验证资源
3.4.2. 了解 CPU 触发器 复制链接链接已复制到粘贴板!
您可以根据 CPU 指标扩展 pod。此触发器使用集群指标作为指标的源。
自定义指标自动扩展扩展与对象关联的 pod,以维护您指定的 CPU 用量。自动缩放器增加或减少最小和最大数量之间的副本数量,以维护所有 pod 的指定 CPU 使用率。内存触发器考虑整个 pod 的内存使用率。如果 pod 有多个容器,则内存触发器会考虑 pod 中所有容器的总内存使用率。
-
此触发器不能与
ScaledJob自定义资源一起使用。 -
当使用内存触发器扩展对象时,对象不会扩展到
0,即使您使用多个触发器。
使用 CPU 目标扩展对象示例
3.4.3. 了解内存触发器 复制链接链接已复制到粘贴板!
您可以根据内存指标扩展 pod。此触发器使用集群指标作为指标的源。
自定义指标自动扩展扩展与对象关联的 pod,以维护您指定的平均内存用量。自动缩放器会增加和减少最小和最大数量之间的副本数量,以维护所有 pod 的指定内存使用率。内存触发器考虑整个 pod 的内存使用率。如果 pod 有多个容器,则内存使用率是所有容器的总和。
-
此触发器不能与
ScaledJob自定义资源一起使用。 -
当使用内存触发器扩展对象时,对象不会扩展到
0,即使您使用多个触发器。
使用内存目标扩展对象示例
3.4.4. 了解 Kafka 触发器 复制链接链接已复制到粘贴板!
您可以根据 Apache Kafka 主题或支持 Kafka 协议的其他服务扩展 pod。自定义指标自动扩展不会缩放 Kafka 分区数量,除非在扩展的对象或扩展任务中将 allowIdleConsumers 参数设置为 true。
如果消费者组数量超过主题中的分区数量,则额外的消费者组处于闲置状态。要避免这种情况,默认情况下副本数不会超过:
- 如果指定了主题,则主题上的分区数量
- 如果没有指定主题,则消费者组中的所有主题的分区数量
-
在扩展对象或扩展作业 CR 中指定的
maxReplicaCount
您可以使用 allowIdleConsumers 参数禁用这些默认行为。
使用 Kafka 目标扩展对象示例
- 1
- 指定 Kafka 作为触发器类型。
- 2
- 指定 Kafka 在处理偏移滞后的 Kafka 主题的名称。
- 3
- 指定要连接的 Kafka 代理的逗号分隔列表。
- 4
- 指定用于检查主题上的偏移以及处理相关滞后的 Kafka 消费者组的名称。
- 5
- 可选:指定触发扩展的平均目标值。必须指定为带引号的字符串值。默认值为
5。 - 6
- 可选:指定激活阶段的目标值。必须指定为带引号的字符串值。
- 7
- 可选:为 Kafka 使用者指定 Kafka 偏移重置策略。可用值包括:
latest和earliest。默认为latest。 - 8
- 可选:指定 Kafka 副本数是否可以超过主题中的分区数量。
-
如果为
true,则 Kafka 副本数可能会超过主题上的分区数量。这允许闲置 Kafka 用户。 -
如果为
false,则 Kafka 副本数不能超过主题上的分区数量。这是默认值。
-
如果为
- 9
- 指定当 Kafka 分区没有有效偏移时触发器的行为方式。
-
如果为
true,则该分区的用户将缩减为零。 -
如果为
false,则 scaler 为该分区保留单个消费者。这是默认值。
-
如果为
- 10
- 可选:指定触发器是否为当前偏移与之前轮询周期的当前偏移量相同或排除分区滞后。
-
如果为
true,则扩展程序会排除这些分区中的分区滞后。 -
如果为
false,则触发器在所有分区中包含所有消费者滞后。这是默认值。
-
如果为
- 11
- 可选:指定 Kafka 代理的版本。必须指定为带引号的字符串值。默认值为
1.0.0。 - 12
- 可选:指定一个以逗号分隔的分区 ID 列表来限制缩放。如果设置,则仅考虑计算滞后列出的 ID。必须指定为带引号的字符串值。默认为考虑所有分区。
- 13
- 可选:指定是否对 Kafka 使用 TSL 客户端身份验证。默认为
禁用。有关配置 TLS 的详情,请参考 "Understanding custom metrics autoscaler trigger authentications"。
3.4.5. 了解 Cron 触发器 复制链接链接已复制到粘贴板!
您可以根据时间范围扩展 pod。
当时间范围启动时,自定义指标自动扩展会将与对象关联的 pod 从配置的最少 pod 数量扩展到所需的 pod 数量。在时间范围结束时,容器集将重新扩展到配置的最小值。时间段必须以 cron 格式进行配置。
在以下示例中,从印度标准时间 6:00 AM 到 6:30 PM 时将与此扩展对象关联的 pod 从 0 扩展到 100。
使用 Cron trigger 扩展对象示例
3.5. 了解自定义指标自动扩展触发器身份验证 复制链接链接已复制到粘贴板!
触发器身份验证允许您在扩展对象或可供关联容器使用的扩展作业中包含身份验证信息。您可以使用触发器身份验证来传递 OpenShift Container Platform secret、平台原生 Pod 验证机制、环境变量等。
您可以在与您要缩放的对象相同的命名空间中定义一个 TriggerAuthentication 对象。该触发器身份验证只能由该命名空间中的对象使用。
另外,要在多个命名空间中对象间共享凭证,您可以创建一个可在所有命名空间中使用的 ClusterTriggerAuthentication 对象。
触发验证和集群触发器身份验证使用相同的配置。但是,集群触发器身份验证需要在扩展对象的验证引用中有一个额外的 kind 参数。
用于基本身份验证的 secret 示例
- 1
- 提供给触发器身份验证的用户名和密码。
data小节中的值必须采用 base-64 编码。
使用 secret 进行基本身份验证的触发器身份验证示例
使用用于基本身份验证的 secret 的集群触发器身份验证示例
带有证书颁发机构 (CA) 详细信息的 secret 示例
使用 secret 进行 CA 详情的触发器身份验证示例
带有 bearer 令牌的 secret 示例
- 1
- 指定与 bearer 身份验证一起使用的 bearer 令牌。
data小节中的值必须采用 base-64 编码。
使用 bearer 令牌进行触发器身份验证示例
使用环境变量的触发器身份验证示例
使用 pod 验证供应商的触发器身份验证示例
其他资源
- 如需有关 OpenShift Container Platform secret 的信息,请参阅向 pod 提供敏感数据。
3.5.1. 使用触发器身份验证 复制链接链接已复制到粘贴板!
您可以使用触发器验证和集群触发器身份验证,方法是使用自定义资源来创建身份验证,然后添加对扩展对象或扩展任务的引用。
先决条件
- 必须安装 Custom Metrics Autoscaler Operator。
如果使用 secret,
Secret对象必须存在,例如:secret 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
创建
TriggerAuthentication或ClusterTriggerAuthentication对象。创建定义对象的 YAML 文件:
使用 secret 的触发器验证示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
TriggerAuthentication对象:oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建或编辑使用触发器身份验证的
ScaledObjectYAML 文件:运行以下命令,创建定义对象的 YAML 文件:
使用触发器身份验证的扩展对象示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用集群触发器身份验证的扩展对象示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建扩展的对象:
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. 暂停扩展对象的自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以根据需要暂停并重启工作负载的自动扩展。
例如,您可能想要在执行集群维护前暂停自动扩展,或通过删除非传输工作负载来避免资源不足。
3.6.1. 暂停自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以通过将 autoscaling.keda.sh/paused-replicas 注解添加到扩展对象的自定义指标自动扩展中来暂停扩展对象的自动扩展。自定义指标自动扩展将该工作负载的副本扩展到指定的值,并暂停自动扩展,直到注解被删除为止。
流程
使用以下命令编辑工作负载的
ScaledObjectCR:oc edit ScaledObject scaledobject
$ oc edit ScaledObject scaledobjectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用任何值添加
autoscaling.keda.sh/paused-replicas注解:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定自定义 Metrics Autoscaler Operator 将副本扩展到指定的值,并停止自动扩展。
3.6.2. 为扩展的对象重启自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以通过删除该 ScaledObject 的 autoscaling.keda.sh/paused-replicas 注解来重启暂停的自定义指标自动扩展。
流程
使用以下命令编辑工作负载的
ScaledObjectCR:oc edit ScaledObject scaledobject
$ oc edit ScaledObject scaledobjectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除
autoscaling.keda.sh/paused-replicas注解。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 删除此注解以重启暂停的自定义指标自动扩展。
3.7. 收集审计日志 复制链接链接已复制到粘贴板!
您可以收集审计日志,它们是与安全相关的按时间排序的记录,记录各个用户、管理员或其他系统组件影响系统的一系列活动。
例如,审计日志可帮助您了解自动扩展请求来自哪里。当后端因为用户应用程序发出的请求造成过载时,这个信息非常重要,您需要确定哪个是有问题的应用程序。
3.7.1. 配置审计日志记录 复制链接链接已复制到粘贴板!
您可以通过编辑 KedaController 自定义资源来为自定义 Metrics Autoscaler Operator 配置审计。日志通过 KedaController CR 中的持久性卷声明发送到卷的审计日志文件。
先决条件
- 必须安装 Custom Metrics Autoscaler Operator。
流程
编辑
KedaController自定义资源以添加auditConfig小节:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定审计日志的输出格式,可以是
legacy或json。 - 2
- 指定用于存储日志数据的现有持久性卷声明。所有来自 API 服务器的请求都会记录到此持久性卷声明。如果将此字段留空,日志数据将发送到 stdout。
- 3
- 指定应记录哪些事件及其应包含哪些数据:
-
None:不记录事件。 -
Metadata:仅记录请求的元数据,如用户、时间戳等。不要记录请求文本和响应文本。这是默认值。 -
Request:仅记录元数据和请求文本,而不记录响应文本。这个选项不适用于非资源请求。 -
RequestResponse:日志事件元数据、请求文本和响应文本。这个选项不适用于非资源请求。
-
- 4
- 指定没有创建事件的阶段。
- 5
- 指定是否省略请求的 managed 字段,并从写入 API 审计日志的响应正文,可以是
true来省略字段,或false包含字段。 - 6
- 指定审计日志的大小和生命周期。
-
MaxAge:根据文件名中编码的时间戳,保留审计日志文件的最大天数。 -
maxBackup:要保留的审计日志文件的最大数量。设置为0以保留所有审计日志文件。 -
maxsize:在轮转审计日志文件前以 MB 为单位的最大大小。
-
验证
直接查看审计日志文件:
获取
keda-metrics-apiserver the pod的名称:oc get pod -n openshift-keda
oc get pod -n openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv 1/1 Running 0 8m20s keda-metrics-apiserver-65c7cc44fd-rrl4r 1/1 Running 0 2m55s keda-operator-776cbb6768-zpj5b 1/1 Running 0 2m55s
NAME READY STATUS RESTARTS AGE custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv 1/1 Running 0 8m20s keda-metrics-apiserver-65c7cc44fd-rrl4r 1/1 Running 0 2m55s keda-operator-776cbb6768-zpj5b 1/1 Running 0 2m55sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用类似如下的命令查看日志数据:
oc logs keda-metrics-apiserver-<hash>|grep -i metadata
$ oc logs keda-metrics-apiserver-<hash>|grep -i metadata1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 可选: 您可以使用
grep命令指定要显示的日志级别:Metadata、Request、RequestResponse。
例如:
oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata
$ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
... {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.28","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}} ...... {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.28","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}} ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
另外,您可以查看特定的日志:
使用类似如下的命令登录到
keda-metrics-apiserver thepod:oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-keda
$ oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-keda
$ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 进入
/var/audit-policy/目录:cd /var/audit-policy/
sh-4.4$ cd /var/audit-policy/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 列出可用的日志:
ls
sh-4.4$ lsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
log-2023.02.17-14:50 policy.yaml
log-2023.02.17-14:50 policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 根据需要查看日志:
cat <log_name>/<pvc_name>|grep -i <log_level>
sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 可选: 您可以使用
grep命令指定要显示的日志级别:Metadata、Request、RequestResponse。
例如:
cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request
sh-4.4$ cat log-2023.02.17-14:50/pvc-audit-log|grep -i RequestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
... {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}} ...... {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}} ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8. 收集调试数据 复制链接链接已复制到粘贴板!
在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。
要帮助排除您的问题,请提供以下信息:
-
使用
must-gather工具收集的数据。 - 唯一的集群 ID。
您可以使用 must-gather 工具来收集有关自定义 Metrics Autoscaler Operator 及其组件的数据,包括以下项目:
-
openshift-keda命名空间及其子对象。 - Custom Metric Autoscaler Operator 安装对象。
- Custom Metric Autoscaler Operator CRD 对象。
3.8.1. 收集调试数据 复制链接链接已复制到粘贴板!
以下命令为自定义 Metrics Autoscaler Operator 运行 must-gather 工具:
oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"
$ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"
标准 OpenShift Container Platform must-gather 命令 oc adm must-gather 将不会收集自定义 Metrics Autoscaler Operator 数据。
先决条件
-
以具有
cluster-admin角色的用户身份登录到 OpenShift Container Platform。 -
已安装 OpenShift Container Platform CLI (
oc)。
流程
进入要存储
must-gather数据的目录。注意如果集群使用受限网络,则需要执行额外的步骤。如果您镜像的容器镜像仓库有一个信任的 CA,您必须首先将这个信任的 CA 添加到集群中。对于受限网络中的所有集群,您必须运行以下命令来导入默认的
must-gather镜像作为镜像流。oc import-image is/must-gather -n openshift
$ oc import-image is/must-gather -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 执行以下之一:
要只获取自定义 Metrics Autoscaler Operator
must-gather数据,请使用以下命令:oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \ -n openshift-marketplace \ -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"$ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \ -n openshift-marketplace \ -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"Copy to Clipboard Copied! Toggle word wrap Toggle overflow must-gather命令的自定义镜像直接从 Operator 软件包清单中拉取,以便它可用于提供 Custom Metric Autoscaler Operator 的任何集群。除了 Custom Metric Autoscaler Operator 信息外,要收集默认的
must-gather数据:使用以下命令获取自定义 Metrics Autoscaler Operator 镜像并将其设置为环境变量:
IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \ -n openshift-marketplace \ -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"$ IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \ -n openshift-marketplace \ -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用带有自定义 Metrics Autoscaler Operator 镜像的
oc adm must-gather:oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}$ oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例 3.1. Custom Metric Autoscaler 的 must-gather 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从工作目录中创建的
must-gather目录创建一个压缩文件。例如,在使用 Linux 操作系统的计算机上运行以下命令:tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/
$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
must-gather-local.5421342344627712289/替换为实际目录名称。
- 在红帽客户门户中为您的问题单附上压缩文件。
3.9. 查看 Operator 指标 复制链接链接已复制到粘贴板!
Custom Metrics Autoscaler Operator 会公开从集群监控组件中提取的可随时使用的指标。您可以使用 Prometheus Query Language (PromQL) 来分析和诊断问题来查询指标。控制器 pod 重启时会重置所有指标。
3.9.1. 访问性能指标 复制链接链接已复制到粘贴板!
您可以使用 OpenShift Container Platform Web 控制台访问指标并运行查询。
流程
- 在 OpenShift Container Platform Web 控制台中选择 Administrator 视角。
- 选择 Observe → Metrics。
- 要创建自定义查询,请将 PromQL 查询添加到 Expression 字段中。
- 要添加多个查询,选择 Add Query。
3.9.1.1. 提供的 Operator 指标 复制链接链接已复制到粘贴板!
Custom Metrics Autoscaler Operator 会公开以下指标,您可以使用 OpenShift Container Platform Web 控制台查看这些指标。
| 指标名称 | 描述 |
|---|---|
|
|
特定的 scaler 是活跃的还是不活跃的。值 |
|
| 每个 scaler 的指标的当前值,由计算目标平均值中的 Horizontal Pod Autoscaler (HPA) 使用。 |
|
| 从每个 scaler 检索当前指标的延迟。 |
|
| 每个 scaler 发生的错误数量。 |
|
| 所有 scaler 遇到的错误总数。 |
|
| 每个扩展的对象发生的错误数量。 |
|
| 每个命名空间中的自定义 Metrics Autoscaler 自定义资源总数,每种自定义资源类型。 |
|
| 根据触发器类型的触发器总数。 |
自定义 Metrics Autoscaler Admission Webhook 指标
自定义 Metrics Autoscaler Admission Webhook 也会公开以下 Prometheus 指标。
| 指标名称 | 描述 |
|---|---|
|
| 扩展对象验证的数量。 |
|
| 验证错误的数量。 |
3.10. 了解如何添加自定义指标自动扩展 复制链接链接已复制到粘贴板!
要添加自定义指标自动扩展,请为部署、有状态集或自定义资源创建 ScaledObject 自定义资源。为作业创建 ScaledJob 自定义资源。
您只能为每个您要扩展的工作负载创建一个扩展对象。另外,您不能在同一工作负载中使用扩展的对象和 pod 横向自动扩展(HPA)。
3.10.1. 在工作负载中添加自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以为 Deployment、StatefulSet 或 custom resource 对象创建的工作负载创建自定义指标自动扩展。
先决条件
- 必须安装 Custom Metrics Autoscaler Operator。
如果您使用自定义指标自动扩展来根据 CPU 或内存进行扩展:
您的集群管理员必须已配置了集群指标。您可以使用
oc describe PodMetrics <pod-name>命令来判断是否已配置了指标。如果配置了指标,输出将类似以下示例,CPU 和 Memory 在 Usage 下显示。oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 与您要缩放的对象关联的 pod 必须包含指定的内存和 CPU 限值。例如:
pod 规格示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
创建一个类似如下的 YAML 文件:只有名称
<2>, 对象名称<4>, 和对象类型<5>是必需的。缩放对象示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 可选:指定自定义 Metrics Autoscaler Operator 将副本扩展到指定的值和停止自动扩展,如 "Pausing the custom metrics autoscaler for a workload" 部分所述。
- 2
- 指定此自定义指标自动扩展的名称。
- 3
- 可选:指定目标资源的 API 版本。默认为
apps/v1。 - 4
- 指定要缩放的对象名称。
- 5
- 指定
kind为Deployment,StatefulSet或CustomResource。 - 6
- 可选:指定目标资源中的容器的名称,其中的自定义自动扩展器获取包含 secret 的环境变量等。默认为
.spec.template.spec.containers[0]。 - 7
- 可选。指定一个在最后的触发器报告后等待的时间(以秒为单位),在经过这个时间后才会将部署缩减为
0(如果minReplicaCount设置为0)。默认值为300。 - 8
- 可选:指定扩展时的最大副本数量。默认值为
100。 - 9
- 可选:指定缩减时的最小副本数量。
- 10
- 可选:指定审计日志的参数。如"配置审计日志记录"部分中所述。
- 11
- 可选:指定在扩展程序无法从源中获取由
failureThreshold参数定义的次数时回退到的副本数。有关回退行为的更多信息,请参阅 KEDA 文档。 - 12
- 可选:指定检查每个触发器的时间间隔(以秒为单位)。默认值为
30。 - 13
- 可选:指定是否在删除扩展对象后将目标资源扩展为原始副本数。默认为
false,这会在删除扩展对象时保留副本数。 - 14
- 可选:指定 pod 横向自动扩展的名称。默认为
keda-hpa-{scaled-object-name}。 - 15
- 可选:指定一个扩展策略来控制用来扩展或缩减 pod 的速度,如"扩展策略"部分中所述。
- 16
- 指定用作扩展基础的触发器,如"识别自定义指标自动扩展触发器"部分中所述。本例使用 OpenShift Container Platform 监控。
- 17
- 可选:指定触发器身份验证或集群触发器身份验证。如需更多信息,请参阅附加资源部分中的 了解自定义指标自动扩展触发器身份验证。
-
输入
TriggerAuthentication来使用触发器身份验证。这是默认值。 -
输入
ClusterTriggerAuthentication来使用集群触发器身份验证。
-
输入
运行以下命令来创建自定义指标自动扩展:
oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
查看命令输出,以验证是否已创建自定义指标自动扩展:
oc get scaledobject <scaled_object_name>
$ oc get scaledobject <scaled_object_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE scaledobject apps/v1.Deployment example-deployment 0 50 prometheus prom-triggerauthentication True True True 17s
NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE scaledobject apps/v1.Deployment example-deployment 0 50 prometheus prom-triggerauthentication True True True 17sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 请注意输出中的以下字段:
-
TRIGGERS:指示正在使用的触发器或缩放器。 -
AUTHENTICATION:指示所使用的任何触发器身份验证的名称。 READY:指示扩展对象是否准备好启动缩放:-
如果为
True,则扩展的对象已就绪。 -
如果
False,由于您创建的对象中的一个或多个对象有问题,扩展的对象将不可用。
-
如果为
ACTIVE:指示扩展是否发生:-
如果为
True,则会进行缩放。 -
如果
False,则不会发生缩放,因为您创建的一个或多个对象中没有指标或多个问题。
-
如果为
FALLBACK:指示自定义指标自动扩展是否能够从源获取指标-
如果
False,自定义指标自动扩展器会获取指标。 -
如果为
True,自定义指标自动扩展会获取指标,因为您创建的一个或多个对象中没有指标或多个问题。
-
如果
-
3.10.2. 在作业中添加自定义指标自动扩展 复制链接链接已复制到粘贴板!
您可以为任何作业对象创建自定义指标自动扩展。
使用扩展作业进行扩展只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
先决条件
- 必须安装 Custom Metrics Autoscaler Operator。
流程
创建一个类似以下示例的 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定作业可以运行的最长持续时间。
- 2
- 指定作业的重试次数。默认值为
6。 - 3
- 可选:指定作业应并行运行多少个 pod 副本;默认为
1。-
对于非并行作业,请保留未设置。如果未设置,则默认值为
1。
-
对于非并行作业,请保留未设置。如果未设置,则默认值为
- 4
- 可选:指定标记作业完成需要成功完成多少个 pod。
-
对于非并行作业,请保留未设置。如果未设置,则默认值为
1。 - 对于具有固定完成计数的并行作业,请指定完成数。
-
对于带有工作队列的并行作业,请保留 unset。当取消设置默认值时,默认值为
parallelism参数的值。
-
对于非并行作业,请保留未设置。如果未设置,则默认值为
- 5
- 指定控制器创建的 pod 模板。
- 6
- 可选:指定扩展时的最大副本数量。默认值为
100。 - 7
- 可选:指定检查每个触发器的时间间隔(以秒为单位)。默认值为
30。 - 8
- 可选:指定成功完成作业的数量。默认值为
100。 - 9
- 可选:指定应保留多少个失败作业。默认值为
100。 - 10
- 可选:指定目标资源中的容器的名称,其中的自定义自动扩展器获取包含 secret 的环境变量等。默认为
.spec.template.spec.containers[0]。 - 11
- 可选:指定在更新扩展作业时是否被终止现有作业:
-
default:如果关联的扩展作业被更新,则自动扩展器会终止一个现有作业。自动扩展会使用最新的 specs 重新创建作业。 -
gradual:如果关联的扩展作业被更新,则自动扩展不会终止现有的作业。自动缩放器使用最新的 specs 创建新作业。
-
- 12
- 可选:指定一个扩展策略:
default、custom或accurate。默认为default。如需更多信息,请参阅下面的"添加资源"部分中的链接。 - 13
- 指定用作扩展基础的触发器,如"识别自定义指标自动扩展触发器"部分中所述。
- 14
- 可选:指定触发器身份验证或集群触发器身份验证。如需更多信息,请参阅附加资源部分中的 了解自定义指标自动扩展触发器身份验证。
-
输入
TriggerAuthentication来使用触发器身份验证。这是默认值。 -
输入
ClusterTriggerAuthentication来使用集群触发器身份验证。
-
输入
运行以下命令来创建自定义指标自动扩展:
oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
查看命令输出,以验证是否已创建自定义指标自动扩展:
oc get scaledjob <scaled_job_name>
$ oc get scaledjob <scaled_job_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME MAX TRIGGERS AUTHENTICATION READY ACTIVE AGE scaledjob 100 prometheus prom-triggerauthentication True True 8s
NAME MAX TRIGGERS AUTHENTICATION READY ACTIVE AGE scaledjob 100 prometheus prom-triggerauthentication True True 8sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 请注意输出中的以下字段:
-
TRIGGERS:指示正在使用的触发器或缩放器。 -
AUTHENTICATION:指示所使用的任何触发器身份验证的名称。 READY:指示扩展对象是否准备好启动缩放:-
如果为
True,则扩展的对象已就绪。 -
如果
False,由于您创建的对象中的一个或多个对象有问题,扩展的对象将不可用。
-
如果为
ACTIVE:指示扩展是否发生:-
如果为
True,则会进行缩放。 -
如果
False,则不会发生缩放,因为您创建的一个或多个对象中没有指标或多个问题。
-
如果为
-
3.11. 删除自定义 Metrics Autoscaler Operator 复制链接链接已复制到粘贴板!
您可以从 OpenShift Container Platform 集群中删除自定义指标自动扩展。删除自定义 Metrics Autoscaler Operator 后,删除与 Operator 相关的其他组件以避免出现潜在的问题。
首先删除 KedaController 自定义资源(CR)。如果没有删除 KedaController CR,OpenShift Container Platform 会在删除 openshift-keda 项目时挂起。如果在删除 CR 前删除了自定义 Metrics Autoscaler Operator,您将无法删除 CR。
3.11.1. 卸载自定义 Metrics Autoscaler Operator 复制链接链接已复制到粘贴板!
使用以下步骤从 OpenShift Container Platform 集群中删除自定义指标自动扩展。
先决条件
- 必须安装 Custom Metrics Autoscaler Operator。
流程
- 在 OpenShift Container Platform web 控制台中,点击 Operators → Installed Operators。
- 切换到 openshift-keda 项目。
删除
KedaController自定义资源。- 找到 CustomMetricsAutoscaler Operator 并点 KedaController 选项卡。
- 找到自定义资源,然后点 Delete KedaController。
- 点 Uninstall。
删除自定义 Metrics Autoscaler Operator:
- 点 Operators → Installed Operators。
-
找到 CustomMetricsAutoscaler Operator 并点 Options 菜单
并选择 Uninstall Operator。
- 点 Uninstall。
可选: 使用 OpenShift CLI 删除自定义指标自动扩展组件:
删除自定义指标自动扩展 CRD:
-
clustertriggerauthentications.keda.sh -
kedacontrollers.keda.sh -
scaledjobs.keda.sh -
scaledobjects.keda.sh -
triggerauthentications.keda.sh
oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh
$ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 CRD 会删除关联的角色、集群角色和角色绑定。但是,可能存在一些必须手动删除的集群角色。
-
列出任何自定义指标自动扩展集群角色:
oc get clusterrole | grep keda.sh
$ oc get clusterrole | grep keda.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除列出的自定义指标自动扩展集群角色。例如:
oc delete clusterrole.keda.sh-v1alpha1-admin
$ oc delete clusterrole.keda.sh-v1alpha1-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出任何自定义指标自动扩展集群角色绑定:
oc get clusterrolebinding | grep keda.sh
$ oc get clusterrolebinding | grep keda.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除列出的自定义指标自动扩展集群角色绑定。例如:
oc delete clusterrolebinding.keda.sh-v1alpha1-admin
$ oc delete clusterrolebinding.keda.sh-v1alpha1-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
删除自定义指标自动扩展项目:
oc delete project openshift-keda
$ oc delete project openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 Cluster Metric Autoscaler Operator:
oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-keda
$ oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-kedaCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 4 章 控制节点上的 pod 放置(调度) 复制链接链接已复制到粘贴板!
4.1. 使用调度程序控制 pod 放置 复制链接链接已复制到粘贴板!
Pod 调度是一个内部过程,决定新 pod 如何放置到集群内的节点上。
调度程度代码具有明确隔离,会监测创建的新 pod 并确定最适合托管它们的节点。然后,它会利用主 API 为 pod 创建 pod 至节点的绑定。
- 默认 pod 调度
- OpenShift Container Platform 附带一个满足大多数用户需求的默认调度程序。默认调度程序使用内置和自定义工具来决定最适合 pod 的调度程序。
- 高级 pod 调度
如果您想要更多地控制新 pod 的放置位置,可以利用 OpenShift Container Platform 高级调度功能来配置 pod,从而使 pod 能够根据要求或偏好在特定的节点上运行,或者与特定的 pod 一起运行。
您可以使用以下调度功能来控制 pod 放置:
4.1.1. 关于默认调度程序 复制链接链接已复制到粘贴板!
默认的 OpenShift Container Platform pod 调度程序负责确定新 pod 放置到集群中的节点上。它从 pod 读取数据,并查找最适合配置的配置集的节点。它完全独立存在,作为独立解决方案。它不会修改 pod;它会为将 pod 绑定到特定节点的 pod 创建绑定。
4.1.1.1. 了解默认调度 复制链接链接已复制到粘贴板!
现有的通用调度程序是平台默认提供的调度程序引擎,它可通过三步操作来选择托管 pod 的节点:
- 过滤节点
- 根据指定的约束或要求过滤可用的节点。这可以通过使用名为 predicates, 或 filters 的过滤器函数列表在每个节点上运行来实现。
- 排列过滤后节点列表的优先顺序
- 这可以通过一系列 priority, 或 scoring 来实现,这些函数为其分配分数介于 0 到 10 之间,0 表示不适合,10 则表示最适合托管该 pod。调度程序配置还可以为每个评分功能使用简单的 权重 (正数值)。每个评分功能提供的节点分数乘以权重(大多数分数的默认权重为 1),然后将每个节点通过为所有分数提供的分数相加。管理员可以使用这个权重属性为某些分数赋予更高的重要性。
- 选择最适合的节点
- 节点按照分数排序,系统选择分数最高的节点来托管该 pod。如果多个节点的分数相同,则随机选择其中一个。
4.1.2. 调度程序用例 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中调度的一个重要用例是支持灵活的关联性和反关联性策略。
4.1.2.1. 基础架构拓扑级别 复制链接链接已复制到粘贴板!
管理员可以通过在节点上指定标签,为基础架构(节点)定义多个拓扑级别。例如,region=r1、zone=z1、rack=s1。
这些标签名称没有特别的含义,管理员可以自由为其基础架构级别命名,比如城市/楼宇/房间。另外,管理员可以为其基础架构拓扑定义任意数量的级别,通常三个级别比较适当(例如:regions → zone → racks)。管理员可以在各个级别上以任何组合指定关联性和反关联性规则。
4.1.2.2. 关联性 复制链接链接已复制到粘贴板!
管理员应能够配置调度程序,在任何一个甚至多个拓扑级别上指定关联性。特定级别上的关联性指示所有属于同一服务的 pod 调度到属于同一级别的节点。这会让管理员确保对等 pod 在地理上不会过于分散,以此处理应用程序对延迟的要求。如果同一关联性组中没有节点可用于托管 pod,则不调度该 pod。
如果您需要更好地控制 pod 的调度位置,请参阅使用节点关联性规则控制节点上的 pod 放置,以及使用关联性和反关联性规则相对于其他 pod 放置 pod。
管理员可以利用这些高级调度功能,来指定 pod 可以调度到哪些节点,并且相对于其他 pod 来强制或拒绝调度。
4.1.2.3. 反关联性 复制链接链接已复制到粘贴板!
管理员应能够配置调度程序,在任何一个甚至多个拓扑级别上指定反关联性。特定级别上的反关联性(或分散)指示属于同一服务的所有 pod 分散到属于该级别的不同节点上。这样可确保应用程序合理分布,以实现高可用性目的。调度程序尝试在所有适用的节点之间尽可能均匀地平衡服务 pod。
如果您需要更好地控制 pod 的调度位置,请参阅使用节点关联性规则控制节点上的 pod 放置,以及使用关联性和反关联性规则相对于其他 pod 放置 pod。
管理员可以利用这些高级调度功能,来指定 pod 可以调度到哪些节点,并且相对于其他 pod 来强制或拒绝调度。
4.2. 使用调度程序配置集调度 pod 复制链接链接已复制到粘贴板!
您可以将 OpenShift Container Platform 配置为使用调度配置集将 pod 调度到集群内的节点上。
4.2.1. 关于调度程序配置集 复制链接链接已复制到粘贴板!
您可以指定一个调度程序配置集来控制 pod 如何调度到节点上。
可用的调度程序配置集如下:
LowNodeUtilization- 此配置集尝试在节点间平均分配 pod,以获得每个节点的资源用量较低。这个配置集提供默认的调度程序行为。
HighNodeUtilization- 此配置集会尝试将尽量多的 pod 放置到尽量少的节点。这样可最小化节点数,并且每个节点的资源使用率很高。
NoScoring- 这是一个低延迟配置集,通过禁用所有分数(score)插件来实现最快的调度周期。这可能会为更快的调度决策提供更好的要求。
4.2.2. 配置调度程序配置集 复制链接链接已复制到粘贴板!
您可以将调度程序配置为使用调度程序配置集。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。
流程
编辑
Scheduler对象:oc edit scheduler cluster
$ oc edit scheduler clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 指定在
spec.profile字段中使用的配置集:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置为
LowNodeUtilization、HighNodeUtilization或NoScoring。
- 保存文件以使改变生效。
4.3. 使用关联性和反关联性规则相对于其他 pod 放置 pod 复制链接链接已复制到粘贴板!
关联性是 pod 的一个属性,用于控制它们希望调度到的节点。反关联性是 pod 的一个属性,用于阻止 pod 调度到某个节点上。
在 OpenShift Container Platform 中,可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。
4.3.1. 了解 pod 关联性 复制链接链接已复制到粘贴板!
您可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。
- 如果新 pod 上的标签选择器与当前 pod 上的标签匹配,pod 关联性可以命令调度程序将新 pod 放置到与其他 pod 相同的节点上。
- 如果新 pod 上的标签选择器与当前 pod 上的标签匹配,pod 反关联性可以阻止调度程序将新 pod 放置到与具有相同标签的 pod 相同的节点上。
例如,您可以使用关联性规则,在服务内或相对于其他服务中的 pod 来分散或聚拢 pod。如果特定服务的 pod 的性能已知会受到另一服务的 pod 影响,那么您可以利用反关联性规则,防止前一服务的 pod 调度到与后一服务的 pod 相同的节点上。或者,您可以将服务的 pod 分散到节点间、可用性区域或可用性集,以减少相关的故障。
标签选择器可能与带有多个 pod 部署的 pod 匹配。在配置反关联性规则时,请使用标签的唯一组合以避免匹配的 pod。
pod 关联性规则有两种,即必要规则和偏好规则。
必须满足必要规则,pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则,但不保证一定能强制执行成功。
根据 pod 优先级和抢占设置,调度程序可能无法在不违反关联性要求的前提下为 pod 找到适合的节点。若是如此,pod 可能不会被调度。
要防止这种情况,请仔细配置优先级相同的 pod 的 pod 关联性。
您可以通过 Pod 规格文件配置 pod 关联性/反关联性。您可以指定必要规则或偏好规则,或同时指定这两种规则。如果您同时指定,节点必须首先满足必要规则,然后尝试满足偏好规则。
以下示例显示了配置了 pod 关联性和反关联性的 Pod 规格。
在本例中,pod 关联性规则指明,只有当节点至少有一个已在运行且具有键 security 和值 S1 的标签的 pod 时,pod 才可以调度到这个节点上。pod 反关联性则表示,如果节点已在运行带有键 security 和值 S2.的标签的 pod,则 pod 将偏向于不调度到该节点上。
具有 pod 关联性的 Pod 配置文件示例
具有 pod 反关联性的 Pod 配置文件示例
如果节点标签在运行时改变,使得不再满足 pod 上的关联性规则,pod 会继续在该节点上运行。
4.3.2. 配置 pod 关联性规则 复制链接链接已复制到粘贴板!
以下步骤演示了一个简单的双 pod 配置,它创建一个带有某标签的 pod,以及一个使用关联性来允许随着该 pod 一起调度的 pod。
您不能直接将关联性添加到调度的 pod 中。
流程
创建 pod 规格中具有特定标签的 pod:
使用以下内容创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
在创建其他 pod 时,配置以下参数以添加关联性:
使用以下内容创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加 pod 关联性。
- 2
- 配置
requiredDuringSchedulingIgnoredDuringExecution参数或preferredDuringSchedulingIgnoredDuringExecution参数。 - 3
- 指定必须满足的
key和values。如果您希望新 pod 与其他 pod 一起调度,请使用与第一个 pod 上标签相同的key和values参数。 - 4
- 指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist。例如,使用运算符In来要求节点上存在该标签。 - 5
- 指定
topologyKey,这是一个预填充的 Kubernetes 标签,供系统用于表示这样的拓扑域。
创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. 配置 pod 反关联性规则 复制链接链接已复制到粘贴板!
以下步骤演示了一个简单的双 pod 配置,它创建一个带有某标签的 pod,以及一个使用反关联性偏好规则来尝试阻止随着该 pod 一起调度的 pod。
您不能直接将关联性添加到调度的 pod 中。
流程
创建 pod 规格中具有特定标签的 pod:
使用以下内容创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
在创建其他 pod 时,配置以下参数:
使用以下内容创建 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加 pod 反关联性。
- 2
- 配置
requiredDuringSchedulingIgnoredDuringExecution参数或preferredDuringSchedulingIgnoredDuringExecution参数。 - 3
- 对于一个首选的规则,为节点指定一个 1-100 的权重。优先选择权重最高的节点。
- 4
- 指定必须满足的
key和values。如果您希望新 pod 不与其他 pod 一起调度,请使用与第一个 pod 上标签相同的key和values参数。 - 5
- 指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist。例如,使用运算符In来要求节点上存在该标签。 - 6
- 指定
topologyKey,它是一个预先填充的 Kubernetes 标签,用于表示这样的拓扑域。
创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.4. pod 关联性和反关联性规则示例 复制链接链接已复制到粘贴板!
以下示例演示了 pod 关联性和 pod 反关联性。
4.3.4.1. Pod 关联性 复制链接链接已复制到粘贴板!
以下示例演示了具有匹配标签和标签选择器的 pod 的 pod 关联性。
pod team4 具有标签
team:4。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod team4a 在
podAffinity下具有标签选择器team:4。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - team4a pod 调度到与 team4 pod 相同的节点上。
4.3.4.2. Pod 反关联性 复制链接链接已复制到粘贴板!
以下示例演示了具有匹配标签和标签选择器的 pod 的 pod 反关联性。
pod pod-s1 具有标签
security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod pod-s2 在
podAntiAffinity下具有标签选择器security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
pod pod-s2 无法调度到与
pod-s1相同的节点上。
4.3.4.3. 无匹配标签的 Pod 反关联性 复制链接链接已复制到粘贴板!
以下示例演示了在没有匹配标签和标签选择器时的 pod 的 pod 关联性。
pod pod-s1 具有标签
security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod pod-s2 具有标签选择器
security:s2。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 除非节点上具有带
security:s2标签的 pod,否则不会调度 pod-s2。如果没有具有该标签的其他 pod,新 pod 会保持在待处理状态:输出示例
NAME READY STATUS RESTARTS AGE IP NODE pod-s2 0/1 Pending 0 32s <none>
NAME READY STATUS RESTARTS AGE IP NODE pod-s2 0/1 Pending 0 32s <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.5. 使用 pod 关联性和反关联性来控制安装 Operator 的位置 复制链接链接已复制到粘贴板!
默认情况下,当安装 Operator 时,OpenShift Container Platform 会随机将 Operator pod 安装到其中一个 worker 节点。然而,在某些情况下,您可能希望该 pod 调度到特定节点或一组节点上。
以下示例描述了您可能希望将 Operator pod 调度到特定节点或一组节点的情况:
-
如果 Operator 需要特定的平台,如
amd64或arm64 - 如果 Operator 需要特定的操作系统,如 Linux 或 Windows
- 如果您希望 Operator 在同一个主机上或位于同一机架的主机上工作
- 如果您希望 Operator 在整个基础架构中分散,以避免因为网络或硬件问题而停机
您可以通过向 Operator 的 Subscription 对象添加 pod 关联性或反关联性来控制 Operator pod 的安装位置。
以下示例演示了如何使用 pod 反关联性来防止从具有特定标签的 pod 中安装自定义 Metrics Autoscaler Operator:
将 Operator pod 放置到一个或多个特定节点的 Pod 关联性示例
- 1
- 将 Operator 的 pod 放置到具有
app=test标签的 pod 的节点上的 pod 关联性。
防止 Operator pod 来自一个或多个特定节点的 Pod 反关联性示例
- 1
- 一个 pod 反关联性,它可防止 Operator 的 pod 调度到具有
cpu=high标签的 pod 的节点上。
流程
要控制 Operator pod 的放置,请完成以下步骤:
- 照常安装 Operator。
- 如果需要,请确保您的节点已标记为正确响应关联性。
编辑 Operator
Subscription对象以添加关联性:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加
podAffinity或podAntiAffinity。
验证
要确保 pod 部署到特定的节点上,请运行以下命令:
$ oc get pods -o wide
$ oc get pods -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. 使用节点关联性规则控制节点上的 pod 放置 复制链接链接已复制到粘贴板!
关联性是 pod 的一个属性,用于控制它们希望调度到的节点。
在 OpenShift Container Platform 中,节点关联性是由调度程序用来确定 pod 的可放置位置的一组规则。规则是使用节点中的自定义标签和 pod 中指定的选择器进行定义的。
4.4.1. 了解节点关联性 复制链接链接已复制到粘贴板!
节点关联性允许 pod 指定与可以放置该 pod 的一组节点的关联性。节点对放置没有控制权。
例如,您可以将 pod 配置为仅在具有特定 CPU 或位于特定可用区的节点上运行。
节点关联性规则有两种,即必要规则和偏好规则。
必须满足必要规则,pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则,但不保证一定能强制执行成功。
如果节点标签在运行时改变,使得不再满足 pod 上的节点关联性规则,该 pod 将继续在这个节点上运行。
您可以通过 Pod 规格文件配置节点关联性。您可以指定必要规则或偏好规则,或同时指定这两种规则。如果您同时指定,节点必须首先满足必要规则,然后尝试满足偏好规则。
下例中的 Pod spec 包含一条规则,要求 pod 放置到具有键为 e2e-az-NorthSouth 且值为 e2e-az-North 或 e2e-az-South 的标签的节点上:
具有节点关联性必要规则的 pod 配置文件示例
下例中的节点规格包含一条偏好规则,其规定优先为 pod 选择具有键为 e2e-az-EastWest 且值为 e2e-az-East 或 e2e-az-West 的节点:
具有节点关联性偏好规则的 pod 配置文件示例
没有明确的节点反关联性概念,但使用 NotIn 或 DoesNotExist 运算符就能实现这种行为。
如果您在同一 pod 配置中同时使用节点关联性和节点选择器,请注意以下几点:
-
如果同时配置了
nodeSelector和nodeAffinity,则必须满足这两个条件时 pod 才能调度到候选节点。 -
如果您指定了多个与
nodeAffinity类型关联的nodeSelectorTerms,那么其中一个nodeSelectorTerms满足时 pod 就能调度到节点上。 -
如果您指定了多个与
nodeSelectorTerms关联的matchExpressions,那么只有所有matchExpressions都满足时 pod 才能调度到节点上。
4.4.2. 配置节点关联性必要规则 复制链接链接已复制到粘贴板!
必须满足必要规则,pod 才能调度到节点上。
流程
以下步骤演示了一个简单的配置,此配置会创建一个节点,以及调度程序要放置到该节点上的 pod。
使用
oc label node命令给节点添加标签:oc label node node1 e2e-az-name=e2e-az1
$ oc label node node1 e2e-az-name=e2e-az1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来添加标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod 规格中具有特定标签的 pod:
使用以下内容创建 YAML 文件:
注意您不能直接将关联性添加到调度的 pod 中。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.3. 配置首选的节点关联性规则 复制链接链接已复制到粘贴板!
偏好规则指定在满足规则时调度程序会尝试强制执行规则,但不保证一定能强制执行成功。
流程
以下步骤演示了一个简单的配置,此配置会创建一个节点,以及调度程序尝试放置到该节点上的 pod。
使用
oc label node命令给节点添加标签:oc label node node1 e2e-az-name=e2e-az3
$ oc label node node1 e2e-az-name=e2e-az3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建具有特定标签的 pod:
使用以下内容创建 YAML 文件:
注意您不能直接将关联性添加到调度的 pod 中。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod。
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.4. 节点关联性规则示例 复制链接链接已复制到粘贴板!
以下示例演示了节点关联性。
4.4.4.1. 具有匹配标签的节点关联性 复制链接链接已复制到粘贴板!
以下示例演示了具有匹配标签的节点与 pod 的节点关联性:
Node1 节点具有标签
zone:us:oc label node node1 zone=us
$ oc label node node1 zone=usCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来添加标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 在节点关联性必要规则下具有
zone和us键/值对:cat pod-s1.yaml
$ cat pod-s1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 可以调度到 Node1 上:
oc get pod -o wide
$ oc get pod -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE pod-s1 1/1 Running 0 4m IP1 node1
NAME READY STATUS RESTARTS AGE IP NODE pod-s1 1/1 Running 0 4m IP1 node1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.4.2. 没有匹配标签的节点关联性 复制链接链接已复制到粘贴板!
以下示例演示了无匹配标签的节点与 pod 的节点关联性:
Node1 节点具有标签
zone:emea:oc label node node1 zone=emea
$ oc label node node1 zone=emeaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您还可以应用以下 YAML 来添加标签:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 在节点关联性必要规则下具有
zone和us键/值对:cat pod-s1.yaml
$ cat pod-s1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 无法调度到 Node1 上:
oc describe pod pod-s1
$ oc describe pod pod-s1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.5. 使用节点关联性来控制安装 Operator 的位置 复制链接链接已复制到粘贴板!
默认情况下,当安装 Operator 时,OpenShift Container Platform 会随机将 Operator pod 安装到其中一个 worker 节点。然而,在某些情况下,您可能希望该 pod 调度到特定节点或一组节点上。
以下示例描述了您可能希望将 Operator pod 调度到特定节点或一组节点的情况:
-
如果 Operator 需要特定的平台,如
amd64或arm64 - 如果 Operator 需要特定的操作系统,如 Linux 或 Windows
- 如果您希望 Operator 在同一个主机上或位于同一机架的主机上工作
- 如果您希望 Operator 在整个基础架构中分散,以避免因为网络或硬件问题而停机
您可以通过在 Operator 的 Subscription 对象中添加节点关联性约束来控制 Operator pod 的安装位置。
以下示例演示了如何使用节点关联性将自定义 Metrics Autoscaler Operator 实例安装到集群中的特定节点:
将 Operator pod 放置到特定节点的节点关联性示例