@@ -17,23 +17,14 @@ recommendations for the |k8s-op-full| when running in production.
17
17
18
18
.. _deploy_recommended-number-sets:
19
19
20
- Deploy the Recommended Number of MongoDB Replica Sets
21
- -----------------------------------------------------
20
+ Deploy Multiple MongoDB Replica Sets
21
+ ------------------------------------
22
22
23
23
We recommend that you use a single instance of the |k8s-op-short|
24
- to deploy up to 20 replica sets in parallel .
24
+ to deploy and manage your MongoDB replica sets.
25
25
26
- You **may** increase this number to 50 and expect a reasonable
27
- increase in the time that the |k8s-op-short| takes to download,
28
- install, deploy, and reconcile its resources.
29
-
30
- For 50 replica sets, the time to deploy varies and might take up to
31
- 40 minutes. This time depends on the network bandwidth of the |k8s|
32
- cluster and the time it takes each {+mdbagent+} to download MongoDB
33
- installation binaries from the Internet for each MongoDB cluster member.
34
-
35
- To deploy more than 50 MongoDB replica sets in parallel,
36
- use multiple instances of the |k8s-op-short|.
26
+ To deploy more than 10 MongoDB replica sets in parallel,
27
+ you can :ref:`increase the thread count of your Kubernetes Operator instance <increase-thread-count-ops-manager>`.
37
28
38
29
Specify CPU and Memory Resource Requirements
39
30
--------------------------------------------
@@ -356,12 +347,20 @@ sharded clusters and standalone deployments.
356
347
.. _operator_pod_resources:
357
348
358
349
Set CPU and Memory Utilization Bounds for the |k8s-op-short| Pod
359
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
350
+ ----------------------------------------------------------------
351
+
352
+ When you deploy MongoDB replica sets with the |k8s-op-short|, the initial
353
+ reconcilliation process increases CPU usage for the Pod running the
354
+ |k8s-op-short|. However, when the replica set deployment process completes,
355
+ the CPU usage by the |k8s-op-short| reduces considerably.
360
356
361
- When you deploy replica sets with the |k8s-op-short|, CPU usage for
362
- Pod used to host the |k8s-op-short| is initially high during the
363
- reconciliation process, however, by the time the deployment completes,
364
- it lowers.
357
+ .. note::
358
+
359
+ The severity of CPU usage spikes in the |k8s-op-short| is directly impacted
360
+ by :ref:`the thread count <increase-thread-count-ops-manager>` of the
361
+ |k8s-op-short|, as the thread count (defined by the :ref:`MDB_MAX_CONCURRENT_RECONCILES <mdb-max-concurrent-reconciles>` value)
362
+ is equal to the number of reconcilliation processes that can be running in
363
+ parallel at any given time.
365
364
366
365
For production deployments, to satisfy deploying up to 50 MongoDB
367
366
replica sets or sharded clusters in parallel with the |k8s-op-short|,
@@ -373,22 +372,16 @@ as follows:
373
372
- ``spec.template.spec.containers.resources.requests.memory`` to 200Mi
374
373
- ``spec.template.spec.containers.resources.limits.memory`` to 1Gi
375
374
376
- If you don't include the unit of measurement for CPUs, |k8s| interprets
377
- it as the number of cores. If you specify ``m``, such as 500m, |k8s|
378
- interprets it as ``millis``. To learn more, see
379
- :k8sdocs:`Meaning of CPU </concepts/configuration/manage-resources-containers/#meaning-of-cpu>`.
375
+
376
+ If you use Helm to deploy resources, define these values in
377
+ the :ref:`values.yaml file <k8s-op-resources-setting>`.
380
378
381
379
The following abbreviated example shows the configuration with
382
380
recommended CPU and memory bounds for the |k8s-op-short| Pod in your
383
381
deployment of 50 replica sets or sharded clusters. If you are
384
382
deploying fewer than 50 MongoDB clusters, you may use lower
385
383
numbers in the configuration file for the |k8s-op-short| Pod.
386
384
387
- .. note::
388
-
389
- Monitoring tools report the size of the |k8s-node| rather than the
390
- actual size of the container.
391
-
392
385
.. example::
393
386
394
387
.. code-block:: yaml
@@ -451,7 +444,7 @@ file.
451
444
.. _mdb_pods_resources:
452
445
453
446
Set CPU and Memory Utilization Bounds for MongoDB Pods
454
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
447
+ -------------------------------------------------------
455
448
456
449
The values for Pods hosting replica sets or sharded clusters map
457
450
to the :k8sdocs:`requests field </reference/generated/kubernetes-api/{+k8s-api-version+}/#resourcerequirements-v1-core>`
@@ -470,10 +463,8 @@ for the MongoDB Pod as follows:
470
463
- ``spec.podSpec.podTemplate.spec.containers.resources.requests.memory`` to 512M
471
464
- ``spec.podSpec.podTemplate.spec.containers.resources.limits.memory`` to 512M
472
465
473
- If you don't include the unit of measurement for CPUs, |k8s| interprets
474
- it as the number of cores. If you specify ``m``, such as 500m, |k8s|
475
- interprets it as ``millis``. To learn more, see
476
- :k8sdocs:`Meaning of CPU </concepts/configuration/manage-resources-containers/#meaning-of-cpu>`.
466
+ If you use Helm to deploy resources, define these values in
467
+ the :ref:`values.yaml file <k8s-op-resources-setting>`.
477
468
478
469
The following abbreviated example shows the configuration with
479
470
recommended CPU and memory bounds for each Pod hosting a MongoDB
@@ -587,3 +578,53 @@ configurations for sharded clusters and standalone MongoDB deployments.
587
578
588
579
- :k8sdocs:`Running in Multiple Zones </setup/best-practices/multiple-zones/>`
589
580
- :k8sdocs:`Node affinity </concepts/scheduling-eviction/assign-pod-node/#node-affinity>`
581
+
582
+ .. _increase-thread-count-ops-manager:
583
+
584
+ Increase Thread Count to Run multiple Reconciliation Processes in Parallel
585
+ --------------------------------------------------------------------------
586
+
587
+ If you plan to deploy more than 10 MongoDB replica sets in parallel,
588
+ you can configure the |k8s-op-short| to run multiple reconciliation processes
589
+ in parallel by setting :ref:`MDB_MAX_CONCURRENT_RECONCILES <mdb-max-concurrent-reconciles>` environment variable in your |k8s-op-short|
590
+ deployment or or through the :ref:`operator.maxConcurrentReconciles <mdb-max-concurrent-reconciles-helm>` field in your Helm
591
+ ``values.yaml`` file to configure a higher thread count.
592
+
593
+ Increasing the thread count of the |k8s-op-short| allows you to vertically scale your |k8s-op-short|
594
+ deployment to hundreds of |k8s-mdbrscs| running within your |k8s| cluster
595
+ and optimize CPU utilization.
596
+
597
+ Please monitor |k8s| API server and |k8s-op-short| resource usage and adjust their respective
598
+ resource allocation if necessary.
599
+
600
+ .. note::
601
+
602
+ - Proceed with caution when increasing the :ref:`MDB_MAX_CONCURRENT_RECONCILES <mdb-max-concurrent-reconciles>` beyond 10.
603
+ In particular, you must monitor the |k8s-op-short|, and the |k8s| API
604
+ closely to avoid downtime resulting from increased load on those components.
605
+
606
+ To determine the thread count that suits your deployment's needs,
607
+ use the following guidelines:
608
+
609
+ - Your requirements for how responsive the |k8s-op-short| must be when
610
+ reconciling many resources
611
+
612
+ - The compute resources available within your |k8s| environment and
613
+ the total processing load your |k8s| compute resources are under, including
614
+ resources that may be unrelated to MongoDB
615
+
616
+ - An alternative to increasing the thread count of a single |k8s-op-short|
617
+ instance, while still increasing the number of |k8s-mdbrscs| you can support
618
+ in your |k8s| cluster, is to deploy multiple |k8s-op-short| instances within
619
+ your |k8s| cluster. However, deploying multiple |k8s-op-short|
620
+ instances requires that you ensure that no two |k8s-op-short| instances
621
+ are monitoring the same |k8s-mdbrscs|.
622
+
623
+ Running more than one instance of the |k8s-op-short| should be done with care,
624
+ as more |k8s-op-short| instances (especially with parallel reconciliation enabled)
625
+ put the API server at greater risk of being overwhelmed.
626
+
627
+ - Scaling of the |k8s| API server is not a valid reason to run
628
+ more than one instance of the |k8s-op-short|. If you observe that performance of
629
+ the API server is affected, adding more instances of the |k8s-op-short| is
630
+ likely to compound the problem.
0 commit comments