注意事项
在此页面上
本页详细介绍了 MongoDB Enterprise Kubernetes Operator 在生产环境中运行时的最佳实践和系统配置建议。
部署多个 MongoDB 副本集
我们建议您使用 Kubernetes Operator 的单个实例来部署和管理 MongoDB 副本集。
要并行部署超过10个 MongoDB 副本集,您可以增加 Kubernetes Operator 实例的线程数。
指定 CPU 和内存资源要求
注意
以下注意事项适用:
本节中通过 Kubernetes Operator 进行常见 MongoDB 部署的所有大小调整和性能建议均可能更改。 请勿将这些建议视为任何类型的保证或限制。
这些建议反映了性能测试结果,也是我们对生产部署的建议。 我们在一个集群上运行了测试,该集群由七个类型为
t2.2xlarge
的 AWS EC2 实例和一个类型为t2.medium
的主节点组成。本部分中的建议不讨论任何特定部署的特征。您的部署特征可能与创建这些建议时所做的假设不同。请联系MongoDB 支持部门以获取有关大小调整的更多帮助。
在 Kubernetes 中,每个 Pod 都包含参数,允许您指定 CPU 资源 和 内存资源 Pod 中的每个容器。
为了指示资源边界,Kubernetes 使用 请求和限制 参数,其中:
request表示资源的下限。
limit表示资源的上限。
以下部分说明如何:
对于托管 Ops Manager 的 Pod,请使用 默认资源限制配置。
考虑推荐的存储实践
以下建议适用于 Kubernetes Operator 管理的 MongoDB 部署和 Ops Manager 应用程序数据库部署。
注意
存储类不需要冗余,因为 MongoDB 会自动在副本集或分片的成员之间复制数据。
您不能在副本集或分片的成员之间共享存储。
根据您的限制,使用可提供最佳性能的存储类。请参阅扩展部署以了解更多信息。
配置
ReadWriteOnce
持久卷 支持存储类的 。在工作线程节点级别,应用Linux 上 MongoDB 的最佳实践。
确保使用支持 卷扩展 的存储类 以启用数据库卷大小调整。
使用静态容器(公共预览版)
静态容器比非静态容器更简单、更安全。静态容器在运行时是不可变的,这意味着它们不会从用于创建容器的映像中更改。此外:
运行时,静态容器不会通过网络连接下载二进制文件或运行脚本或其他实用程序。静态容器仅下载运行时配置文件。
运行时,静态容器不会修改除存储卷挂载之外的任何文件。
您可以对容器映像运行安全扫描,以确定实际运行的容器,并且运行的容器不会运行映像中定义以外的二进制文件。
静态容器不要求您在 Ops Manager 或其他 HTTPS服务器上托管 MongoDB 二进制文件,如果您有气隙环境,这一点尤其有用。
您无法为静态容器运行大量
CMD
脚本。您无法使用
initContainer
在静态容器之间复制文件。
要了解更多信息,请参阅静态容器(公共预览版)。
将mongos
Pod 与应用程序共置一地
您可以在同一mongos
节点 上运行轻量级 实例 作为使用 MongoDB 的应用程序。Kubernetes Operator 支持标准 Kubernetes 节点关联和反关联 功能。利用这些功能,您可以在与应用程序相同的节点上强制安装mongos
。
以下简短示例显示了关联性和多个可用区配置。
podAffinity
键确定是否将应用程序安装在与其他应用程序相同的 Pod、节点或数据中心上。
要指定 Pod 关联性,请执行以下操作:
在
spec.podSpec.podTemplate.metadata.labels
YAML 集合中添加标签和值以标记部署。请参阅spec.podSpec.podTemplate.metadata
和 Kubernetes PodSpec v1 核心 API。指定
mongos
在spec.mongosPodSpec.podAffinity
.requiredDuringSchedulingIgnoredDuringExecution.labelSelector
YAML collection中使用的标签。matchExpressions
collection定义了label
Kubernetes 操作符用来识别托管mongos
。
例子
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.2.1-ent 8 service: my-service 9 10 ... 11 podTemplate: 12 spec: 13 affinity: 14 podAffinity: 15 requiredDuringSchedulingIgnoredDuringExecution: 16 - labelSelector: 17 matchExpressions: 18 - key: security 19 operator: In 20 values: 21 - S1 22 topologyKey: failure-domain.beta.kubernetes.io/zone 23 nodeAffinity: 24 requiredDuringSchedulingIgnoredDuringExecution: 25 nodeSelectorTerms: 26 - matchExpressions: 27 - key: kubernetes.io/e2e-az-name 28 operator: In 29 values: 30 - e2e-az1 31 - e2e-az2 32 podAntiAffinity: 33 requiredDuringSchedulingIgnoredDuringExecution: 34 - podAffinityTerm: 35 topologyKey: nodeId
请参阅 replica-set-affinity.yaml 中的多个可用区和节点关联性配置的完整示例 在 Affinity Samples 目录。
此目录还包含分片集群和独立运行的实例 MongoDB 部署的关联性和多区域配置示例。
根据其用途为 MongoDB 服务命名
将spec.service
参数设置为标识此部署用途的值,如以下示例所示。
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: "6.0.0-ent" 8 service: drilling-pumps-geosensors 9 featureCompatibilityVersion: "4.0"
使用标签区分部署
使用 Pod 关联性 Kubernetes 具有以下功能:
分隔不同的 MongoDB 资源,例如
test
、staging
和production
环境。放置 Pod 在某些特定节点上,以利用 SSD 支持等功能。
1 mongosPodSpec: 2 podAffinity: 3 requiredDuringSchedulingIgnoredDuringExecution: 4 - labelSelector: 5 matchExpressions: 6 - key: security 7 operator: In 8 values: 9 - S1 10 topologyKey: failure-domain.beta.kubernetes.io/zone
自定义 Kubernetes Operator 监视的 CustomResourceDefinitions
您可以指定希望 Kubernetes Operator 监视哪些自定义资源。 这样,您就可以仅为希望 Kubernetes 操作符托管的资源安装 CustomResourceDefinition。
您必须使用helm
将 Kubernetes Operator 配置为仅监视您指定的自定义资源。 按照相关的helm
安装说明进行操作,但进行以下调整:
决定要安装哪个 CustomResourceDefinition。 您可以安装任意数量的以下内容:
值说明mongodb
安装数据库资源的 CustomResourceDefinitions 并监视这些资源。mongodbusers
为 MongoDB 用户资源安装 CustomResourceDefinitions 并监视这些资源。opsmanagers
安装 Ops Manager 的 CustomResourceDefinitions 并监视这些资源。安装 Helm Chart 并指定您希望 Kubernetes 操作符 监视的 CustomResourceDefinition。
用逗号分隔每个自定义资源:
helm install <deployment-name> mongodb/enterprise-operator \ --set operator.watchedResources="{mongodb,mongodbusers}" \ --skip-crds
确保正确的持久性配置
Kubernetes Operator 编排的 Kubernetes 部署是有状态的。 Kubernetes 容器使用 持久卷 在两次重启之间保持集群状态。
为了满足有状态要求,Kubernetes Operator 执行以下操作:
创建 持久卷 用于 MongoDB 部署。
将存储设备挂载到一个或多个称为挂载点的目录。
为每个 MongoDB 挂载点创建一个持久卷。
将每个 Kubernetes container中的默认路径设置为
/data
。
为了满足 MongoDB 集群的存储需求,请对使用 Kubernetes Operator 部署的每个副本集的配置进行以下更改:
验证是否在
spec.persistent
中启用了持久卷。 此设置默认为true
。为 Kubernetes 操作符指定足够的存储量,以便为每个卷分配。卷存储数据和日志。
要设置多个卷,每个卷用于数据、日志和
oplog
,请使用spec.podSpec.persistence.multiple.data
。要设置单个卷来存储数据、日志和
oplog
,请使用spec.podSpec.persistence.single
。
以下简短示例显示了建议的持久存储大小。
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-cluster 5 spec: 6 7 ... 8 persistent: true 9 10 11 shardPodSpec: 12 ... 13 persistence: 14 multiple: 15 data: 16 storage: "20Gi" 17 logs: 18 storage: "4Gi" 19 storageClass: standard
有关持久卷配置的完整示例,请参阅 副本集持久卷.yaml 在 持久卷样本 中 目录。此目录还包含分片集群和独立运行部署的持久卷配置示例。
为 Kubernetes 操作符 Pod 设置 CPU 和内存利用率边界
使用 Kubernetes Operator 部署 MongoDB 副本集时,初始协调进程会增加运行 Kubernetes Operator 的 Pod 的 CPU 使用率。但是,当副本集部署过程完成后,Kubernetes Operator 的 CPU 使用率会大幅降低。
注意
Kubernetes Operator 中 CPU 使用量峰值的严重性直接受 Kubernetes Operator线程数的影响,因为线程数(由MDB_MAX_CONCURRENT_RECONCILES值定义)等于可以在任何给定时间并行运行的调节进程数。时间。
对于生产部署,为了满足与 Kubernetes 操作符并行部署最多 50 个 MongoDB 副本集或分片集群的需求,请为 Kubernetes 操作符 Pod 设置 CPU 和内存资源及限制,如下所示:
spec.template.spec.containers.resources.requests.cpu
至 500mspec.template.spec.containers.resources.limits.cpu
至 1100mspec.template.spec.containers.resources.requests.memory
至 200Mispec.template.spec.containers.resources.limits.memory
至 1Gi
如果使用 Helm 部署资源,请在values.yaml 文件中定义这些值。
以下简短示例显示了在 50 个副本集或分片集群部署中 Kubernetes 操作符 Pod 的建议 CPU 和内存边界配置。如果您部署的 MongoDB 集群少于 50 个,则可以在 Kubernetes 操作符 Pod 的配置文件中使用较小的数字。
例子
1 apiVersion: apps/v1 2 kind: Deployment 3 metadata: 4 name: mongodb-enterprise-operator 5 namespace: mongodb 6 spec: 7 replicas: 1 8 selector: 9 matchLabels: 10 app.kubernetes.io/component: controller 11 app.kubernetes.io/name: mongodb-enterprise-operator 12 app.kubernetes.io/instance: mongodb-enterprise-operator 13 template: 14 metadata: 15 labels: 16 app.kubernetes.io/component: controller 17 app.kubernetes.io/name: mongodb-enterprise-operator 18 app.kubernetes.io/instance: mongodb-enterprise-operator 19 spec: 20 serviceAccountName: mongodb-enterprise-operator 21 securityContext: 22 runAsNonRoot: true 23 runAsUser: 2000 24 containers: 25 - name: mongodb-enterprise-operator 26 image: quay.io/mongodb/mongodb-enterprise-operator:1.9.2 27 imagePullPolicy: Always 28 args: 29 - "-watch-resource=mongodb" 30 - "-watch-resource=opsmanagers" 31 - "-watch-resource=mongodbusers" 32 command: 33 - "/usr/local/bin/mongodb-enterprise-operator" 34 resources: 35 limits: 36 cpu: 1100m 37 memory: 1Gi 38 requests: 39 cpu: 500m 40 memory: 200Mi
有关 Kubernetes Operator Pod 满足并行部署最多 个50 MongoDB 副本集的 CPU 和内存利用率资源和限制的完整示例,请参阅 mongodb-enterprise.yaml 文件。
为 MongoDB Pod 设置 CPU 和内存利用率边界
托管副本集或分片集群的 Pod 的值映射到 requests 字段 用于创建 Pod 的 CPU 和内存。这些值与针对 MongoDB 主机所述的注意事项一致。
Kubernetes Operator 使用分配的内存进行处理、WiredTiger 缓存以及在部署期间存储包。
对于生产部署,请按如下方式设置 MongoDB Pod 的 CPU 和内存资源及限制:
spec.podSpec.podTemplate.spec.containers.resources.requests.cpu
至 0.25spec.podSpec.podTemplate.spec.containers.resources.limits.cpu
至 0.25spec.podSpec.podTemplate.spec.containers.resources.requests.memory
至 512Mspec.podSpec.podTemplate.spec.containers.resources.limits.memory
至 512M
如果使用 Helm 部署资源,请在values.yaml 文件中定义这些值。
以下简短示例显示了部署中托管 MongoDB 副本集成员的每个 Pod 的配置以及建议的 CPU 和内存限制。
例子
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.0.0-ent 8 service: my-service 9 ... 10 11 persistent: true 12 podSpec: 13 podTemplate: 14 spec: 15 containers: 16 - name: mongodb-enterprise-database 17 resources: 18 limits: 19 cpu: "0.25" 20 memory: 512M
有关托管 MongoDB 副本集成员的 Pod 的 CPU 和内存利用率资源和限制的完整示例,请参阅 replica-set-podspec.yaml MongoDB Podspec 样本 中的文件 目录。
此目录还包含 Pod 的 CPU 和内存限制配置示例,用于:
一个分片集群,位于 sharded-cluster-podspec.yaml 中。
独立运行 MongoDB 部署,位于 standalone-podspec.yaml 中。
使用多个可用区
设置 Kubernetes Operator 和 StatefulSet 将一个副本集的所有成员分布到不同 节点 以确保高可用性。
以下简短示例显示了关联性和多个可用区配置。
例子
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.2.1-ent 8 service: my-service 9 ... 10 podAntiAffinityTopologyKey: nodeId 11 podAffinity: 12 requiredDuringSchedulingIgnoredDuringExecution: 13 - labelSelector: 14 matchExpressions: 15 - key: security 16 operator: In 17 values: 18 - S1 19 topologyKey: failure-domain.beta.kubernetes.io/zone 20 21 nodeAffinity: 22 requiredDuringSchedulingIgnoredDuringExecution: 23 nodeSelectorTerms: 24 - matchExpressions: 25 - key: kubernetes.io/e2e-az-name 26 operator: In 27 values: 28 - e2e-az1 29 - e2e-az2
在此示例中,Kubernetes Operator 将 Pod 部署安排到e2e-az1
或e2e-az2
可用区中具有标签kubernetes.io/e2e-az-name
的节点。 更改nodeAffinity
以安排将 Pod 部署到所需的区域。
请参阅 replica-set-affinity.yaml 中的多个可用区配置的完整示例 在 Affinity Samples 目录。
此目录还包含分片集群和独立运行的实例 MongoDB 部署的关联性和多区域配置示例。
增加线程数以并行运行多个调节进程
如果计划并行部署超过10个 MongoDB 副本集,则可以通过在 Kubernetes Operator 部署中设置MDB_MAX_CONCURRENT_RECONCILES环境变量,或通过 Helm 中的Operator.maxConcurrentReconciles字段,将 Kubernetes Operator 配置为并行运行多个协调进程。 values.yaml
文件以配置更高的线程数。
增加 Kubernetes Operator 的线程数可让您将 Kubernetes Operator 部署垂直扩展为 Kubernetes 集群内运行的数百个MongoDB
资源,并优化 CPU 利用率。
请监控 Kubernetes API Server 和 Kubernetes Operator 资源使用情况,并在必要时调整各自的资源分配。
注意
将MDB_MAX_CONCURRENT_RECONCILES 增加到超过10时,请务必谨慎。特别是,您必须密切监控 Kubernetes Operator 和 Kubernetes API,以避免因这些组件的负载增加而导致停机。
要确定适合部署需求的线程数,请遵循以下准则:
您对 Kubernetes Operator 在协调大量资源时的响应速度的要求
Kubernetes 环境中可用的计算资源以及 Kubernetes 计算资源承受的总处理负载,包括可能与 MongoDB 无关的资源
在增加单个 Kubernetes Operator 实例的线程数的同时,增加 Kubernetes 集群中可支持的
MongoDB
资源数量的另一种方法是在 Kubernetes 集群中部署多个 Kubernetes Operator 实例。但是,部署多个 Kubernetes Operator 实例需要确保没有两个 Kubernetes Operator 实例监控相同的MongoDB
资源。运行多个 Kubernetes Operator 实例时应小心谨慎,因为更多 Kubernetes Operator 实例(尤其是启用了并行协调功能的情况下)会使 API Server 面临更大的过载风险。
Kubernetes API 服务器的扩展不是运行多个 Kubernetes Operator 实例的正当理由。如果您发现 API Server 的性能受到影响,则添加更多 Kubernetes Operator 实例可能会使问题变得更加复杂。