Considerations
在此页面上
本页详细介绍了 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 都包含参数,允许您为 Pod 中的每个容器指定 CPU 资源 和内存资源。
为了指示资源边界,Kubernetes 使用 请求和限制 参数,其中:
request表示资源的下限。
limit表示资源的上限。
以下部分说明如何:
对于托管 的MongoDB Ops Manager Pod,请使用 默认资源限制配置。
使用静态容器(公共预览版)
静态容器比非静态容器更安全、更简单。 静态容器在运行时是不可变的。 此外:
运行时,静态容器无法通过网络连接下载二进制文件或运行脚本或其他实用程序。 静态容器只能下载运行时配置文件。
运行时,静态容器无法修改除存储卷挂载之外的任何文件。
静态容器不要求扫描容器中的安全漏洞,而非静态容器则需要容器安全扫描。 如果使用静态容器,则只能对容器映像本身运行安全扫描,而不能对其容器运行安全扫描。
如果您有气隙环境,则静态容器不要求您在托管MongoDB 的服务器或其他MongoDB Ops Manager HTTPS 服务器上托管 二进制文件。
您无法为静态容器运行大量
CMD
脚本。您无法使用
initContainer
在静态容器之间复制文件。
注意
作为静态容器部署时, Kubernetes Operator部署由两个容器组成 — 一个 mongodb-agent
容器和一个 mongodb-enterprise-server
容器。MongoDB 数据库自定义资源从 mongodb-agent
容器继承资源限制定义,该容器在静态容器部署中运行 mongod
进程。要修改MongoDB 数据库资源的资源限制,必须在 mongodb-agent
容器上指定所需的资源限制。
要学习;了解详情,请参阅静态容器(公共预览版)。
将mongos
Pod 与应用程序共置一地
您可以在同一mongos
节点 上运行轻量级 实例 作为使用 MongoDB 的应用程序。Kubernetes Operator 支持标准 Kubernetes 节点关联和反关联 功能。利用这些功能,您可以在与应用程序相同的节点上强制安装mongos
。
以下简短示例显示了关联性和多个可用区配置。
podAffinity
键确定是否将应用程序安装在与其他应用程序相同的 Pod、节点或数据中心上。
要指定 Pod 关联性,请执行以下操作:
在
spec.podSpec.podTemplate.metadata.labels
YAML集合中添加标签和值以标签部署。 请参阅spec.podSpec.podTemplate.metadata
和Kubernetes PodSpec v1Core 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线程数的Kubernetes,因为线程数(由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环境变量,或通过 .maxConcurrentReconciles 操作操作符,将Kubernetes Operator 配置为并行运行多个协调进程。 字段以配置更高的values.yaml
文件。
增加Kubernetes Operator 的线程数可让您将Kubernetes Operator部署垂直扩展为Kubernetes集群内运行的数百个MongoDB
资源,并优化 CPU 利用率。
请监控Kubernetes API 服务器和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 服务器面临更大的过载风险。
Kubernetes API服务器的扩展不是运行多个Kubernetes Operator实例的正当理由。 如果您发现API 服务器的性能受到影响,则添加更多Kubernetes Operator 实例可能会使问题变得更加复杂。