IBM Cloud Docs
服务的体系结构和依赖关系

服务的体系结构和依赖关系

查看 Red Hat® OpenShift® on IBM Cloud® 集群的样本体系结构,组件和依赖关系。

在 Red Hat OpenShift on IBM Cloud中,集群由 IBM管理的主节点组成,用于保护组件 (例如 API 服务器和 etcd) 以及客户管理的工作程序节点 (您配置这些节点以运行应用程序工作负载) 以及 Red Hat OpenShift提供的缺省组件。 群集内的默认组件,如 Red Hat OpenShift Web 控制台或 OperatorHub, 会随群集的 Red Hat OpenShift 版本而变化。

经典 Red Hat OpenShift 体系结构

查看体系结构图,然后滚动浏览下表以获取在经典基础架构上运行的 Red Hat OpenShift on IBM Cloud 集群中主节点和工作程序节点组件的描述。 有关 OpenShift Container Platform 架构的更多信息,请参阅 Red Hat OpenShift 文档

运行 oc get nodes 时,您可能会注意到工作程序节点的 ROLES 标记为两个 master,worker。 这些节点是 IBM Cloud中的工作程序节点,并且不包含由 IBM管理的主组件。 而是将这些节点标记为 master,因为它们运行设置和管理集群中的缺省资源 (例如 OperatorHub 和内部注册表) 所需的 OpenShift Container Platform 组件。

Red Hat OpenShift on IBM Cloud cluster architecture
Red Hat OpenShift master components

Red Hat OpenShift 主组件

查看 Red Hat OpenShift on IBM Cloud 集群的 IBM管理的主节点中的以下组件。

无法修改这些组件。 IBM 在主补丁更新期间管理组件并自动更新组件。

在 OpenShift Container Platform 4 中,许多组件由相应的操作程序配置,以便于管理。 下表一起讨论了这些操作程序和组件,以关注组件向集群提供的主要功能。

单租户

主组件和所有主组件仅供您专用,并且不会与其他 IBM 客户共享。

副本

主组件(包括 Red Hat OpenShift API 服务器和 etcd 数据存储)有三个副本,如果位于多区地铁中,还可跨区分布,以提高可用性。 主节点组件每 8 小时备份一次。

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 代理合作,将主节点与工作节点安全地连接起来。 该连接支持 apiserver proxy 调用 pod 和服务; oc execattachlogs 调用 kubelet;以及突变和验证 webhook。

许可控制器

在 Red Hat OpenShift on IBM Cloud 集群中,针对特定功能实施了接入控制器。 通过许可控制器,可以在集群中设置策略,用于确定是否允许执行集群中的特定操作。 在策略中,您可以指定用户不能执行操作的条件,即使该操作是您通过 RBAC 为用户分配的一般权限的一部分。 因此,在 Red Hat OpenShift API 服务器处理 API 请求之前,准入控制器可为集群提供额外的安全保护。 创建 Red Hat OpenShift 集群时,将按照给定顺序在 Red Hat OpenShift 主节点中自动安装以下 Kubernetes 许可控制器,用户无法更改这些控制器:

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultStorageClass
  • ResourceQuota
  • StorageObjectInUseProtection
  • PersistentVolumeClaimResize
  • Priority
  • BuildByStrategy
  • OriginPodNodeEnvironment
  • PodNodeSelector
  • ExternalIPRanger
  • NodeRestriction
  • SecurityContextConstraint
  • SCCExecRestrictions
  • PersistentVolumeLabel
  • OwnerReferencesPermissionEnforcement
  • PodTolerationRestriction
  • openshift.io/JenkinsBootstrapper
  • openshift.io/BuildConfigSecretInjector
  • openshift.io/ImageLimitRange
  • openshift.io/RestrictedEndpointsAdmission
  • openshift.io/ImagePolicy
  • openshift.io/IngressAdmission
  • openshift.io/ClusterResourceQuota
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook

您可以 在群集中安装自己的接入控制器,也可以选择 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 服务器报告 pod 的状态。
  • vpn:Konnectivity 代理与 Konnectivity 服务器合作,安全地连接主节点和工作节点。 此连接支持对 pod 和服务的 apiserver proxy 调用,还支持对 kubelet 的 oc execattachlogs 调用。
  • 其他组件: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 Web 控制台是一个用户友好的基于 Web 的界面,可用于管理集群中运行的 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 控制器就可以在不同的计算主机上运行,以提高可用性。
openshift-marketplace
缺省情况下,市场包含 Red Hat OpenShift 集群随附的 OperatorHub。 OperatorHub 包含来自 Red Hat 和 3rd-party 提供程序的操作程序。 请记住,这些操作程序由社区提供,可能未与集群集成,并且不受 IBM支持。 您可以从 Red Hat OpenShift Web 控制台中的 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 将为入站流量的每个服务创建一个公共负载均衡器。

Red Hat OpenShift on IBM Cloud on VPC cluster architecture with public and private cloud service endpoints
Red Hat OpenShift on VPC cluster architecture with public and private cloud service endpoints

仅具有私有云服务端点的集群

下图显示了集群的组件以及在仅启用 私有云服务端点 时这些组件的交互方式。 由于仅启用私有云服务端点,因此 VPC 会为入站流量的每个服务创建一个私有负载均衡器。

Red Hat OpenShift on IBM Cloud on VPC cluster architecture with the private cloud service endpoint only
Red Hat OpenShift on VPC cluster architecture with the private cloud service endpoint only

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,因为它们运行设置和管理集群中的缺省资源 (例如 OperatorHub 和内部注册表) 所需的 OpenShift Container Platform 组件。
集群联网
工作程序节点在指定专区中的 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。