多集群架构图: MongoDB Ops Manager和应用程序数据库
下图显示了Ops Manager 应用程序、应用程序数据库、备份守护程序和相应的 持久卷 部署在多个Kubernetes集群上。
在此图中:
Member Cluster 0
也是一个“Operator 集群”,因为您在其上安装了 Kubernetes Operator。 它也是一个“成员集群”,可以托管任何多集群自定义资源。Member Cluster 0
存储 kubeconfig 文件 ,其中描述了 Kubernetes配置 针对成员集群、用户和上下文。当您使用kubectl mongodb
插件为多集群部署配置Kubernetes Operator 时,它会创建以下资源:mongodb-enterprise-operator-multi-cluster-kubeconfig
密钥,包含 Kubernetes Operator 将管理的所有 Kubernetes 集群的档案。 如果您计划将 Operator 集群用作成员集群,则此密钥可能包含您安装 Kubernetes Operator 的同一集群的档案。
当Kubernetes Operator 在多集群模式时,它会存储所需的资源,例如 ConfigMap 和有关其要管理的集群的密钥。 这些资源与Kubernetes Operator 属于同一命名空间。 KubernetesOperator 使用这些资源在多个MongoDB Ops Manager Kubernetes集群上部署 应用程序和应用程序数据库。
Kubernetes Operator 还为其管理的每个MongoDB Ops Manager应用程序和应用程序数据库部署创建并维护一些额外的多集群部署状态 ConfigMap。
Member Cluster 0
存储此配置,其中包括以下 ConfigMap:<om_resource_name>-cluster-mapping
ConfigMap 包含spec.clusterSpecList
中列出的成员集群名称到集群索引的映射,在本文档中称为cluster_index
,例如Cluster 0
或Cluster 1
。 Kubernetes Operator 将这些索引分配给每个集群名称。<om_resource_name>-db-cluster-mapping
ConfigMap 包含spec.applicationDatabase.clusterSpecList
中列出的成员集群名称到集群索引的映射。<om_resource_name>-db-member-spec
ConfigMap 包含为每个成员集群配置的应用程序数据库副本数。 有了这些信息, Kubernetes Operator 就可以在灾难恢复中正确扩展或重新配置副本集,例如在丢失整个成员集群后。
MongoDBOpsManager
资源的配置是您创建的一个文件,用于描述多集群MongoDB Ops Manager部署。 Kubernetes Operator 使用此文件来部署MongoDB Ops Manager组件。以下示例显示了导致Kubernetes Operator 部署此图中描述的MongoDB Ops Manager组件的配置。 此示例省略了一些与此图表不相关的设置,例如 TLS配置。
1 apiVersion: mongodb.com/v1 2 kind: MongoDBOpsManager 3 metadata: 4 name: om 5 namespace: om-ns 6 spec: 7 replicas: 1 # You can set this value and use it as a global or default 8 # setting for all clusters. The spec.clusterSpecList.members 9 # setting overrides this setting. 10 topology: MultiCluster 11 version: 6.0.22 12 adminCredentials: om-admin-secret 13 clusterSpecList: 14 - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1" 15 members: 2 16 backup: # Backup settings for "Member Cluster 1" 17 members: 2 # Overrides spec.backup.members 18 - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2" 19 members: 1 20 backup: # Backup settings for "Member Cluster 2" 21 members: 2 # Overrides spec.backup.members 22 applicationDatabase: # Global {+appdb+} settings 23 topology: MultiCluster 24 version: 6.0.5-ent 25 members: 3 # In multi-cluster mode, the Operator ignores this field. 26 # The Operator sets the number of members for the Application 27 # Database in spec.applicationDatabase.clusterSpecList.members. 28 clusterSpecList: 29 - clusterName: "Member Cluster 1" 30 members: 3 31 - clusterName: "Member Cluster 2" 32 members: 2 33 backup: # Global settings for the Backup Daemon 34 enabled: true 35 members: 1 # Set this value and use it as a global or default setting. 36 # To override this value, set the value for 37 # spec.clusterSpecList.backup.members. 38 # The Backup Daemon's configuration for each cluster isn't 39 # stored here. Use the Ops Manager's spec.clusterSpecList.backup to 40 # specify the Backup Daemon configuration for each member cluster. Kubernetes Operator 连接到引用以下任一项的MongoDB Ops Manager实例:
为MongoDB Ops Manager 资源创建的服务的默认 FQDN ,
<om_resource_name>-svc.<namespace>.svc.cluster.local
或您在
spec.opsManagerURL
中指定的URL 。 在某些部署中,例如当安装Kubernetes Operator 的集群未连接到服务网格时,可能无法访问默认服务FQDN 。 在这种情况下, Kubernetes Operator 会将MongoDBOpsManager
资源状态报告为Failed
,表示连接错误。 考虑到此类情况,请在URL 中提供MongoDB Ops Manager 的spec.opsManagerURL
。此URL可能是外部公开的MongoDB Ops Manager实例的主机名。 要学习;了解更多信息,请参阅网络概述。
两个成员集群托管MongoDB Ops Manager应用程序。 在每个集群中, Kubernetes Operator 部署一个名为
<om_resource_name>-<cluster_index>
的 StatefulSet。StatefulSet 在
Member Cluster 1
中部署MongoDB Ops Manager应用程序的两个实例,在Member Cluster 2
中部署一个实例。您在
spec.clusterSpecList.members
中定义实例的数量。 您可以设立实例数设置为零,以便此集群不部署任何MongoDB Ops Manager应用程序实例。 示例,如果您想使用此集群仅托管备份守护程序实例,这非常有用。如果从
spec.clusterSpecList
删除一个集群,则相当于在spec.clusterSpecList.members
和spec.clusterSpecList[*].backup.members
中指定零个成员。对于每个集群中的每个 StatefulSet, Kubernetes Operator 都会配置一个 服务 类型为
ClusterIP
且名为 的<om_resource_name>-svc
Pod,其中包含集群端点列表上的所有 Pod。此服务的 FQDN<om_resource_name>-svc.<namespace>.svc.cluster.local
是默认主机名, Kubernetes Operator 使用它来访问权限MongoDB Ops Manager应用程序的已部署端点。如果指定
spec.externalConnectivity
, Kubernetes Operator 还会为每个集群创建一个名为<om_resource_name>-svc-ext
的外部KubernetesLoadBalancer
类型服务。 在每个集群中,您可以使用spec.clusterSpecList.externalConnectivity
为此外部服务指定自己的配置。 示例,您可以更改服务类型或定义注解。
应用程序数据库。 Kubernetes Operator 在两个集群上部署应用程序数据库。
Member Cluster 1
包含应用程序数据库的三个mongod
进程,Member Cluster 2
包含两个mongod
进程。您可以使用
spec.applicationDatabase
设置定义应用程序数据库配置。 在每个成员集群上, Kubernetes Operator 创建一个名为<om_resource_name>-db-<cluster_index>
的 StatefulSet,其数量在spec.applicationDatabase.clusterSpecList.members
中定义。 在多集群模式, Kubernetes Operator 会忽略您为spec.applicationDatabase.members
字段设立的值。 Kubernetes Operator 配置一个副本集由部署在所有成员集群上的mongod
进程组成。对于
<statefulset_name>-<pod_index>
中托管名为 的MongoDB进程的每个 Pod,<om_resource_name>-db-<cluster_index>-<pod_index>
Kubernetes Operator 都会创建一个KubernetesClusterIP
类型服务,用于通过其mongod
FQDN 访问各个<om_resource_name>-db-<cluster_index>-<pod_index>-svc
进程。副本集的每个mongod
进程必须可唯一寻址。副本集配置中的进程必须将其进程主机名配置为该 Pod 服务的FQDN :
<om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.local
。要从所有
mongod
进程形成副本集,每个进程都必须连接到其他进程以进行复制。 为此,请将部署应用程序数据库的所有成员集群纳入同一服务网格配置中。服务网格处理跨集群 DNS 查询并相应地路由流量。 服务网格协助解析所有集群中每个 Pod 服务的FQDN
<om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.local
,并允许在公开的mongod
端口(默认为27017 )上进行连接。例如,当
mongod
om-db-1-0
中 Pod 中运行的Member Cluster 1
进程连接到mongod
中om-db-2-1
Pod 中运行的Member Cluster 2
,第一个mongod
进程使用自动化配置om-db-2-1-svc.om-ns.svc.cluster.local:27017
和服务网格将此请求路由到Member Cluster 2
到om-db-2-1-svc
服务。如果没有服务网格,KubernetesMember Cluster 1
就没有有关部署在Member Cluster 2
中的om-db-2-1-svc
服务的信息,并且om-db-2-1-svc.om-ns.svc.cluster.local
的 DNS 解析将失败。当应用程序数据库和MongoDB Ops Manager应用程序实例处于
Running
状态时, Kubernetes Operator 会向应用程序数据库 StatefulSets 添加一个额外的监控容器。 这会导致所有集群中的所有应用程序数据库 Pod滚动重启。 Kubernetes Operator 按顺序更新所有集群的 StatefulSet,以便在滚动重启进程,每个集群中只有一个副本集的成员暂时不可用。监控代理使用MongoDB Ops Manager MongoDB Ops Manager服务的 FQDN
<om_resource_name>-svc.<namespace>.svc.cluster.local
或 中的值(如果您指定)连接到spec.opsManagerURL
应用程序实例。MongoDB Ops Manager应用程序和备份守护程序始终使用包含所有副本集成员的应用程序数据库的连接string 。 连接string始终使用 pod 服务 FQDN 构建。
如果您将
spec.backup.enabled
设置为true
,Kubernetes Operator 会部署备份守护程序 StatefulSet。在
spec.clusterSpecList
中列出的每个成员集群上,Kubernetes Operator 都会创建一个备份守护程序 StatefulSet,名为<om_resource_name>-backup-daemon-<cluster_index>
,并将备份守护程序实例的数量设置为spec.backup.members
。或者,您可以在
spec.clusterSpecList[*].backup.members
中配置每个集群的备份守护程序实例的数量。备份守护程序实例仅使用与 应用程序实例相同的连接string MongoDB Ops Manager连接到应用程序数据库副本集。
此外,在此图中,您可以观察服务网格和组件之间的网络连接:
该图周围的虚线显示了单个服务网格,其中包括所有集群的网络配置。
跨成员集群的MongoDB Ops Manager应用程序周围的虚线表示这些实例是无状态的,并且流量可以平均分布式给所有实例,示例使用循环负载负载均衡器。
跨成员集群的应用程序数据库周围的虚线表示这些实例相互通信并形成单个 MongoDB 副本集。