6.13. 创建基础架构节点
您只能在 Machine API 操作的集群中使用高级机器管理和扩展功能。具有用户置备的基础架构的集群需要额外的验证和配置才能使用 Machine API。
具有基础架构平台类型 none
的集群无法使用 Machine API。即使附加到集群的计算机器安装在支持该功能的平台上,也会应用这个限制。在安装后无法更改此参数。
要查看集群的平台类型,请运行以下命令:
$ oc get infrastructure cluster -o jsonpath='{.status.platform}'
您可以使用基础架构机器集来创建仅托管基础架构组件的机器,如默认路由器、集成的容器镜像 registry 以及集群指标和监控的组件。这些基础架构机器不会被计算为运行环境所需的订阅总数。
在生产部署中,建议您至少部署三个机器集来容纳基础架构组件。OpenShift Logging 和 Red Hat OpenShift Service Mesh 部署 Elasticsearch,这需要三个实例安装到不同的节点上。这些节点都可以部署到不同的可用区以实现高可用性。此配置需要三个不同的机器集,每个可用区都有一个。在没有多个可用区的全局 Azure 区域,您可以使用可用性集来确保高可用性。
在基础架构节点上添加 NoSchedule
污点后,在该节点上运行的现有 DNS pod 被标记为 misscheduled
。您必须删除或在 misscheduled
DNS pod 中添加容限。
6.13.1. OpenShift Container Platform 基础架构组件
每个自我管理的 Red Hat OpenShift 订阅都包括 OpenShift Container Platform 和其他 OpenShift 相关组件的权利。这些权利包括在运行 OpenShift Container Platform control plane 和基础架构工作负载时,不需要在大小期间考虑这些权利。
要有资格成为基础架构节点并使用包含的权利,只有支持集群的组件,而不是最终用户应用程序的一部分,才能在这些实例上运行。示例包括以下组件:
- Kubernetes 和 OpenShift Container Platform control plane 服务
- 默认路由器
- 集成的容器镜像 registry
- 基于 HAProxy 的 Ingress Controller
- 集群指标集合或监控服务,包括监控用户定义的项目的组件
- 集群聚合日志
- Red Hat Quay
- Red Hat OpenShift Data Foundation
- Red Hat Advanced Cluster Management for Kubernetes
- Red Hat Advanced Cluster Security for Kubernetes
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
- Red Hat OpenShift Service Mesh
运行任何其他容器、Pod 或组件的所有节点都需要是您的订阅可涵盖的 worker 节点。
有关基础架构节点以及可在基础架构节点上运行,请参阅 OpenShift sizing and subscription guide for enterprise Kubernetes 文档中的 "Red Hat OpenShift control plane and infrastructure nodes"部分。
要创建基础架构节点,您可以使用机器集,标记节点,或使用机器配置池。
6.13.1.1. 创建基础架构节点
请参阅为安装程序置备的基础架构环境创建基础架构机器集,或为其 control plane 节点由机器 API 管理的任何集群创建基础架构机器集。
集群的基础架构系统(也称为 infra 节点)
的要求已被置备。安装程序只为 control plane 和 worker 节点提供置备。Worker 节点可以通过标记来指定为基础架构节点或应用程序(也称为 app
)。
流程
向您要充当应用程序节点的 worker 节点添加标签:
$ oc label node <node-name> node-role.kubernetes.io/app=""
向您要充当基础架构节点的 worker 节点添加标签:
$ oc label node <node-name> node-role.kubernetes.io/infra=""
检查相关节点现在是否具有
infra
角色或app
角色:$ oc get nodes
创建默认的集群范围节点选择器。默认节点选择器应用到在所有命名空间中创建的 pod。这会创建一个与 pod 上任何现有节点选择器交集的交集,这会额外限制 pod 的选择器。
重要如果默认节点选择器键与 pod 标签的键冲突,则不会应用默认节点选择器。
但是,不要设置可能会导致 pod 变得不可调度的默认节点选择器。例如,当 pod 的标签被设置为不同的节点角色(如
node-role.kubernetes.io/infra=""
)时,将默认节点选择器设置为特定的节点角色(如node-role.kubernetes.io/master=""
)可能会导致 pod 无法调度。因此,将默认节点选择器设置为特定节点角色时要小心。您还可以使用项目节点选择器来避免集群范围节点选择器键冲突。
编辑
Scheduler
对象:$ oc edit scheduler cluster
使用适当的节点选择器添加
defaultNodeSelector
字段:apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster spec: defaultNodeSelector: node-role.kubernetes.io/infra="" 1 # ...
- 1
- 这个示例节点选择器默认在基础架构节点上部署 pod。
- 保存文件以使改变生效。
现在,您可以将基础架构资源移到新标记的 infra
节点。
其他资源