服务的体系结构和依赖关系
审查集群 Red Hat® OpenShift® on IBM Cloud® 的示例架构、组件及依赖关系。
在 Red Hat OpenShift on IBM Cloud 中,您的集群包含由 IBM 管理的控制节点,该节点负责保护 API 服务器和 等组件的安全 etcd;同时还包含由客户管理的 worker 节点,您可配置这些节点来运行应用工作负载,以及 Red Hat OpenShift 提供的默认组件。 集群中的默认组件(如 Web Red Hat OpenShift 控制台) OperatorHub, 会随集群 Red Hat OpenShift 版本而变化。
经典 Red Hat OpenShift 体系结构
请查看架构图,然后浏览以下表格,了解在经典基础设施上运行的 Red Hat OpenShift on IBM Cloud 集群中主节点和工作节点组件的说明。 有关 OpenShift Container Platform 架构的更多信息,请参阅 Red Hat OpenShift 文档。
在运行 4.17 及更早版本的集群中,当您执行 oc get nodes 时,可能会发现工作节点(worker nodes)的 ROLES 同时被标记为 master,worker。 这些节点是 IBM Cloud 中的工作节点,不包含由 IBM 管理的控制组件。 相反,这些节点被标记为 master,因为它们运行着 OpenShift Container Platform
组件,这些组件用于在集群内配置和管理默认资源,例如 OperatorHub 和内部注册表。 在运行 4.18 及更高版本的集群中,工作节点上不再设置 node-role.kubernetes.io/master 节点标签。
Red Hat OpenShift 主组件
请检查集群 Red Hat OpenShift on IBM Cloud 中 -managed IBM 主节点中的以下组件。
无法修改这些组件。 IBM 在主补丁更新期间管理组件并自动更新组件。
在 OpenShift Container Platform 4 中,许多组件由相应的操作程序配置,以便于管理。 下表一起讨论了这些操作程序和组件,以关注组件向集群提供的主要功能。
- 单租户
-
主组件和所有主组件仅供您专用,并且不会与其他 IBM 客户共享。
- 副本
-
主组件(包括 Red Hat OpenShift API服务器和 etcd 数据存储)各有三个副本;如果位于多区域大都市区中,这些组件会分布在各个区域,以实现更高的可用性。
cloud-controller-manager-
云控制器管理器管理特定于云提供者的组件,例如 IBM Cloud 负载均衡器。
cluster-health-
集群运行状况组件监视集群的运行状况,并与服务的 IBM Cloud 监视和度量集成。
cluster-policy-controller-
cluster-policy-controller维护在集群中创建 pod 所需的策略资源。 cluster-version-operator-
集群版本操作程序 (CVO) 将安装并更新在集群中运行的其他操作程序。 有关更多信息,请参阅 GitHub 项目。
control-plane-operator-
控制平面操作员管理主控机中控制平面组件的安装和更新。
etcd,etcd-molecule,etcd-operator-
etcd 是一种高可用性键/值存储,用于存储集群的所有 Kubernetes 资源(例如,服务、部署和 pod)的状态。 etcd 中的数据每 8 小时会备份一次,备份至由 IBM 管理的加密存储实例中。
kube-controller-manager,openshift-controller-manager-
Kubernetes 控制器 监视集群中对象的状态,例如工作负载的副本集。 当对象的状态发生变化时(例如,复制集中的某个 Pod 发生故障),控制器管理器会启动纠正措施,以恢复到所需状态。 Red Hat OpenShift 控制器对特定于 Red Hat OpenShift API 的对象 (例如项目) 执行相同的功能。
kube-scheduler-
Kubernetes 调度器会监听新创建的Pod,并根据容量、性能需求、策略约束、反亲和性规范以及工作负载要求来决定将它们部署到何处。 如果找不到与这些需求相匹配的工作程序节点,那么不会在集群中部署 pod。
manifests-bootstrapper-
manifests-boot-strapper作业设置具有所需证书的主节点,以连接为集群的主节点。 oauth-openshift-
内置的 OAuth 服务器会自动设置为与 IBM Cloud Identity and Access Management (IAM) 集成。 无法将其他受支持的身份提供者添加到集群。 有关如何通过 IAM 对群集进行身份验证的详细信息,请参阅 访问 Red Hat OpenShift 群集。
openshift-apiserver,openshift-apiserver-operator,kube-apiserver-
API 服务器是来自工作节点发往主节点的所有集群管理请求的主要入口点。 API 服务器验证并处理更改 Kubernetes 对象 (例如 pod 或服务) 和 Red Hat OpenShift 对象 (例如项目或用户) 的状态的请求。 然后,API 服务器将此状态存储在 etcd 数据存储器中。
konnectivity-server,konnectivity-operator-
Konnectivity 服务器与 Konnectivity 代理协同工作,以安全的方式将主节点与工作节点连接起来。 该连接支持向您的 Pod 和服务发起
apiserver proxy请求;向 kubelet 发起oc exec、attach和logs请求;以及变异型和验证型 webhook。 - 许可控制器
-
在 Red Hat OpenShift on IBM Cloud 集群中,针对特定功能实现了访问控制器。 通过许可控制器,可以在集群中设置策略,用于确定是否允许执行集群中的特定操作。 在策略中,您可以指定在哪些情况下用户无法执行某项操作,即使该操作属于您通过 RBAC 授予该用户的通用权限范围。 因此,在 Red Hat OpenShift API服务器处理API请求之前,准入控制器可以为您的集群提供额外的安全保障。 创建 Red Hat OpenShift 集群时,将按照给定顺序在 Red Hat OpenShift 主节点中自动安装以下 Kubernetes 许可控制器,用户无法更改这些控制器:
NamespaceLifecycleLimitRangerServiceAccountDefaultStorageClassResourceQuotaStorageObjectInUseProtectionPersistentVolumeClaimResizePriorityBuildByStrategyOriginPodNodeEnvironmentPodNodeSelectorExternalIPRangerNodeRestrictionSecurityContextConstraintSCCExecRestrictionsPersistentVolumeLabelOwnerReferencesPermissionEnforcementPodTolerationRestrictionopenshift.io/JenkinsBootstrapperopenshift.io/BuildConfigSecretInjectoropenshift.io/ImageLimitRangeopenshift.io/RestrictedEndpointsAdmissionopenshift.io/ImagePolicyopenshift.io/IngressAdmissionopenshift.io/ClusterResourceQuotaMutatingAdmissionWebhookValidatingAdmissionWebhook
-
您可以在 集群中安装自定义准入控制器,也可以从 Red Hat OpenShift on IBM Cloud 提供的可选准入控制器中进行选择。 容器映像安全性实施: 安装 Portieris 以阻止来自未签名映像的容器部署。
-
如果您是手动安装的访问控制器,且不再需要使用它们,请务必将其彻底移除。 如果未完全移除访问控制器,它们可能会阻止您在集群上执行的所有操作。
Red Hat OpenShift 工作节点组件
检查集群 Red Hat OpenShift on IBM Cloud 中客户管理的工作节点中的以下组件。
这些组件在工作程序节点上运行,因为您能够将它们用于部署到集群的工作负载。 例如,应用程序可能使用 OperatorHub 中的操作程序,该操作程序从内部注册表中的映像运行容器。 您负责使用这些组件,但 IBM 在您选择应用的工作程序节点补丁更新中提供了这些组件的更新。
在 OpenShift Container Platform中,许多组件由相应的操作程序配置,以便于管理。 下表一起讨论了这些操作程序和组件,以关注组件向集群提供的主要功能。
- 单租户
- 工作站节点和所有工作站节点组件仅供您使用,不与其他 IBM 客户共享。 但是,如果使用工作节点虚拟机,则可能与其他 IBM 客户共享底层硬件,具体取决于您选择的硬件隔离级别。
- 操作系统
- 有关按集群版本列出的受支持操作系统的列表,请参阅 版本信息。
- CRI-O 容器运行时
- 工作程序节点以 CRI-O 作为容器运行时接口进行安装。 有关更多信息,请参阅 容器运行时。
- 项目
- Red Hat OpenShift 将您的资源组织到项目中,这些项目是带有注解的 Kubernetes 命名空间,并且包含比社区版 Kubernetes 集群更多的组件,用于运行 Red Hat OpenShift 中的各项功能,例如目录。 以下各行中描述了项目的精选组件。 有关更多信息,请参阅 项目工作。
calico-system,tigera-operator- Calico 负责管理集群的网络策略,并包含若干组件,用于管理容器网络连接、IP地址分配以及网络流量控制。 Tigera 操作程序安装和管理 Calico 组件的生命周期。
default- 如果您未指定项目,也未为您的 Kubernetes 资源创建项目,则将使用此项目。
ibm-system- 该项目包含
ibm-cloud-provider-ip部署,该部署与keepalived配合使用,为发往应用Pod的请求提供健康检查和第4层负载均衡。 kube-system- 该项目包含许多组件,用于在工作节点上运行 Kubernetes。
ibm-master-proxy:ibm-master-proxy是一个守护进程集,用于将来自工作节点的请求转发至高可用主副本的 IP 地址。 在单专区集群中,主节点有三个副本,每个副本位于单独的主机上。 对于位于支持多专区的专区中的集群,主节点的三个副本在各专区中进行分布。 高可用性负载均衡器会将向主节点域名发出的请求转发到主节点副本。kubelet: kubelet 是一个工作节点代理,运行在每个工作节点上,负责监控在该工作节点上运行的 Pod 的健康状况,并监听 API 服务器发送的事件。 根据这些事件,kubelet 会创建或删除 Pod,确保运行状态和就绪性探针正常工作,并将 Pod 的状态反馈给 API 服务器。vpn: Konnectivity 代理与 Konnectivity 服务器协同工作,以安全的方式将主节点与工作节点连接起来。 此连接支持对 pod 和服务的apiserver proxy调用,还支持对 kubelet 的oc exec、attach和logs调用。- 其他组件:
kube-system项目还包含用于管理 IBM 提供的资源的组件,例如用于文件存储和块存储的存储插件、入站应用程序负载均衡器(ALB)以及keepalived。
openshift-cloud-credential-operator- 云凭证操作程序管理请求云提供者凭证的 Red Hat OpenShift 组件的控制器。 控制器确保仅使用操作所需的凭证,而不使用任何已提升的许可权 (如
admin)。 有关更多信息,请参阅 GitHub 项目。 openshift-cluster-node-tuning-operator- IBM 管理 节点调整操作程序,该操作程序在集群中的每个工作程序节点上运行一个守护程序集以调整工作程序节点。
openshift-cluster-samples-operator- 缺省情况下,样本操作程序 管理随 Red Hat OpenShift 集群提供的选择映像流和模板。 您可以从 开发者 透视图的 Red Hat OpenShift Web 控制台 中部署这些模板。
openshift-cluster-storage-operator- 集群存储操作程序确保设置了缺省存储类。
openshift-console,openshift-console-operator- Red Hat OpenShift 网络控制台是一个基于网络的界面,可用于管理群集中运行的 Red Hat OpenShift 和 Kubernetes 资源。 您还可以使用控制台来显示
oc login令牌,以通过 CLI 向集群进行认证。 有关更多信息,请参阅导航 Red Hat OpenShift 控制台。 openshift-dns,openshift-dns-operator- DNS 项目包含用于根据工作节点上配置的
iptables规则对传入网络流量进行验证的组件,并代理允许进入或离开集群的请求。 openshift-image-registry- Red Hat OpenShift 提供了内部 容器映像注册表,可用于通过控制台本地管理和查看映像。 或者,您可以 设置专用 IBM Cloud Container Registry 或 将映像从 IBM Cloud Container Registry 导入内部注册表。 内部注册表随附 IBM Cloud 基础架构帐户中用于 存储注册表映像 的 File Storage for Classic 卷。 通过
image-registry-storage持久卷声明 (PVC) 供应文件存储卷。 openshift-ingress,openshift-ingress-operator- Red Hat OpenShift 使用 路由直接在主机名上公开应用程序的服务,以便外部客户端可以访问该服务。 要创建路径,集群将使用 Ingress 操作程序。 您还可以使用 Ingress 在外部公开应用程序并定制路由。 入口由三个组件组成 :Ingress 操作程序,Ingress 控制器和 Route 资源。 Ingress 控制器将服务映射到主机名。 默认情况下,Ingress 控制器包含两个副本。 请确保您的集群至少有两个工作节点,以便 Ingress 控制器能在不同的计算主机上运行,从而提高可用性。
openshift-marketplace- 缺省情况下,市场包含 Red Hat OpenShift 集群随附的 OperatorHub。 OperatorHub 包括来自 Red Hat 和第三方供应商的运营商。 请注意,这些运算符由社区提供,可能无法与您的集群集成,也不受 IBM 的支持。 您可以通过 Red Hat OpenShift 网络控制台中的 OperatorHub 启用操作员。
openshift-monitoring- OpenShift Container Platform 包含针对集群的 内置监视堆栈,其中包含度量值和警报管理功能。 有关内置监视堆栈与其他选项 (例如 IBM Cloud Monitoring) 的比较,请参阅 了解用于日志记录和监视的选项。
openshift-multus- OpenShift Container Platform 使用 Multus 容器网络接口 (CNI) 插件来允许 多个 pod 网络。 但是,无法将集群配置为使用多个 pod 网络。Red Hat OpenShift on IBM Cloud 集群仅支持 Calico(缺省情况下为集群设置)。 如果已启用,Service Mesh 将使用 Multus 插件。
openshift-network-operator- 集群网络操作员(CNO) 管理缺省情况下设置的集群网络组件,例如 CNI pod 网络提供者插件和 DNS 操作员。
openshift-operator-lifecycle-manager- 操作程序生命周期管理器(OLM) 管理集群中运行的所有操作程序和目录的生命周期,包括缺省组件的操作程序以及您添加的任何定制操作程序。
openshift-service-ca,openshift-service-ca-operator- 认证中心 (CA) 操作程序运行证书签名,并将证书注入到集群中的 API 服务器资源和配置映射中。 有关更多信息,请参阅 GitHub 项目。
VPC 集群服务体系结构
以下架构概述专门针对 VPC 基础设施提供商。 有关经典基础设施提供商的架构概述,请参阅《 经典集群服务架构 》。
查看体系结构图,然后滚动浏览下表,了解在虚拟私有云(VPC)计算基础设施上运行的 Red Hat OpenShift on IBM Cloud 集群中主节点和工作节点组件的描述。
具有公共和私有云服务端点的集群
下图显示了集群的组件以及在同时启用 公共和私有云服务端点 时这些组件的交互方式。 由于两个服务端点都已启用,因此 VPC 将为入站流量的每个服务创建一个公共负载均衡器。
仅具有私有云服务端点的集群
下图显示了集群的组件以及在仅启用 私有云服务端点 时这些组件的交互方式。 由于仅启用私有云服务端点,因此 VPC 会为入站流量的每个服务创建一个私有负载均衡器。
VPC 主节点和工作程序节点组件
主节点 和 工作程序节点 包含集群的经典集群体系结构中描述的相同组件。 有关该 OpenShift Container Platform 架构的更多信息,请参阅 文档 Red Hat OpenShift。
- Master
- 主节点组件(包括 API 服务器和 etcd)有三个副本,可跨专区分布,以实现更高可用性。 主节点包含集群的经典集群体系结构中描述的相同组件。 主组件和所有主组件仅供您专用,并且不会与其他 IBM 客户共享。
- 工作程序节点
- 使用 Red Hat OpenShift on IBM Cloud 时,集群管理的虚拟机是称为工作程序节点的实例。 这些工作节点虚拟机和所有工作节点组件仅供您使用,不与其他 IBM 客户共享。 但是,底层硬件与其他 IBM 客户共享。 您可以通过 Red Hat OpenShift on IBM Cloud 提供的自动化工具(如 API、CLI 或控制台)管理 Worker 节点。 与经典集群不同,您无法在基础设施门户或单独的基础设施账单中看到 VPC 计算工作节点,而是需要通过 Red Hat OpenShift on IBM Cloud 管理这些工作节点的所有维护和计费操作。
- 工作节点包含与经典集群架构中所述相同的 组件。
- 运行
oc get nodes时,您可能会注意到工作程序节点的 ROLES 标记为两个master,worker。 这些节点是 IBM Cloud 中的工作节点,不包含由 IBM 管理的控制组件。 相反,这些节点被标记为master,因为它们运行着 OpenShift Container Platform 组件,这些组件用于在集群内配置和管理默认资源,例如 OperatorHub 和内部注册表。 - 集群联网
- 工作程序节点在指定专区中的 VPC 子网中进行创建。 主节点与工作程序节点之间的通信在专用网络上执行。 如果在启用了公共和私有云服务端点的情况下创建集群,那么已认证的外部用户可以通过公用网络与主节点进行通信,例如运行
oc命令。 如果创建仅启用了私有云服务端点的集群,那么已认证的外部用户只能通过专用网络与主节点进行通信。 通过在专用网络上设置 VPC VPN,IBM Cloud Direct Link或 IBM Cloud Transit Gateway,可以设置集群以与内部部署网络,其他 VPC 或经典基础架构中的资源进行通信。 - 应用程序联网
- 对于在集群中创建的任何联网服务,将在集群外部的 VPC 中自动创建虚拟私有云负载均衡器。 例如,缺省情况下,VPC 负载均衡器会公开集群中的路由器服务。 或者,您可以为应用程序创建 Kubernetes
LoadBalancer服务,并自动生成 VPC 负载均衡器。 VPC 负载均衡器是针对应用程序的多专区和路由请求,通过在工作程序节点上自动打开的专用节点端口。 如果启用了公共和私有云服务端点,那么缺省情况下会将路由器和 VPC 负载均衡器创建为公共路由器和 VPC 负载均衡器。 如果仅启用私有云服务端点,那么缺省情况下会将路由器和 VPC 负载均衡器创建为私有。 有关更多信息,请参阅 公共 或 VPC 集群的专用应用程序联网。 Calico 用作集群联网策略光纤网。 - 存储器
- 只能设置 IBM Cloud Object Storage 和 Cloud Databases。