Skip to content
logo
Percona Operator for MongoDB
Anti-affinity and tolerations
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
        • Node selector
        • Affinity and anti-affinity
          • Simple approach - use antiAffinityTopologyKey of the Percona Operator for MongoDB
          • Advanced approach - use standard Kubernetes constraints
        • Tolerations
        • Priority Classes
        • Pod Disruption Budgets
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Node selector
    • Affinity and anti-affinity
      • Simple approach - use antiAffinityTopologyKey of the Percona Operator for MongoDB
      • Advanced approach - use standard Kubernetes constraints
    • Tolerations
    • Priority Classes
    • Pod Disruption Budgets

    Binding Percona Server for MongoDB components to Specific Kubernetes/OpenShift Nodes¶

    The operator does a good job of automatically assigning new pods to nodes to achieve balanced distribution across the cluster. There are situations when you must ensure that pods land on specific nodes: for example, for the advantage of speed on an SSD-equipped machine, or reduce costs by choosing nodes in the same availability zone.

    The appropriate (sub)sections (replsets, replsets.arbiter, backup, etc.) of the deploy/cr.yaml file contain the keys which can be used to do assign pods to nodes.

    Node selector¶

    The nodeSelector contains one or more key-value pairs. If the node is not labeled with each key-value pair from the Pod’s nodeSelector, the Pod will not be able to land on it.

    The following example binds the Pod to any node having a self-explanatory disktype: ssd label:

    nodeSelector:
      disktype: ssd
    

    Affinity and anti-affinity¶

    Affinity defines eligible pods that can be scheduled on the node which already has pods with specific labels. Anti-affinity defines pods that are not eligible. This approach is reduces costs by ensuring several pods with intensive data exchange occupy the same availability zone or even the same node or, on the contrary, to spread the pods on different nodes or even different availability zones for high availability and balancing purposes.

    Percona Operator for MongoDB provides two approaches for doing this:

    • simple way to set anti-affinity for Pods, built-in into the Operator,
    • more advanced approach based on using standard Kubernetes constraints.

    Simple approach - use antiAffinityTopologyKey of the Percona Operator for MongoDB¶

    Percona Operator for MongoDB provides an antiAffinityTopologyKey option, which may have one of the following values:

    • kubernetes.io/hostname - Pods will avoid residing within the same host,
    • failure-domain.beta.kubernetes.io/zone - Pods will avoid residing within the same zone,
    • failure-domain.beta.kubernetes.io/region - Pods will avoid residing within the same region,
    • none - no constraints are applied.

    The following example forces Percona Server for MongoDB Pods to avoid occupying the same node:

    affinity:
      antiAffinityTopologyKey: "kubernetes.io/hostname"
    

    Advanced approach - use standard Kubernetes constraints¶

    The previous method can be used without special knowledge of the Kubernetes way of assigning Pods to specific nodes. Still, in some cases, more complex tuning may be needed. In this case, the advanced option placed in the deploy/cr.yaml file turns off the effect of the antiAffinityTopologyKey and allows the use of the standard Kubernetes affinity constraints of any complexity:

    affinity:
       advanced:
         podAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
           - labelSelector:
               matchExpressions:
               - key: security
                 operator: In
                 values:
                 - S1
             topologyKey: failure-domain.beta.kubernetes.io/zone
         podAntiAffinity:
           preferredDuringSchedulingIgnoredDuringExecution:
           - weight: 100
             podAffinityTerm:
               labelSelector:
                 matchExpressions:
                 - key: security
                   operator: In
                   values:
                   - S2
               topologyKey: kubernetes.io/hostname
         nodeAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
             nodeSelectorTerms:
             - matchExpressions:
               - key: kubernetes.io/e2e-az-name
                 operator: In
                 values:
                 - e2e-az1
                 - e2e-az2
           preferredDuringSchedulingIgnoredDuringExecution:
           - weight: 1
             preference:
               matchExpressions:
               - key: another-node-label-key
                 operator: In
                 values:
                 - another-node-label-value
    

    See explanation of the advanced affinity options in Kubernetes documentation.

    Tolerations¶

    Tolerations allow Pods having them to be able to land onto nodes with matching taints. Toleration is expressed as a key with and operator, which is either exists or equal (the equal variant requires a corresponding value for comparison).

    Toleration should have a specified effect, such as the following:

    • NoSchedule - less strict
    • PreferNoSchedule
    • NoExecute

    When a taint with the NoExecute effect is assigned to a Node, any Pod configured to not tolerating this taint is removed from the node. This removal can be immediate or after the tolerationSeconds interval. The following example defines this effect and the removal interval:

    tolerations:
    - key: "node.alpha.kubernetes.io/unreachable"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    

    The Kubernetes Taints and Toleratins contains more examples on this topic.

    Priority Classes¶

    Pods may belong to some priority classes. This flexibility allows the scheduler to distinguish more and less important Pods when needed, such as the situation when a higher priority Pod cannot be scheduled without evicting a lower priority one. This ability can be accomplished by adding one or more PriorityClasses in your Kubernetes cluster, and specifying the PriorityClassName in the deploy/cr.yaml file:

    priorityClassName: high-priority
    

    See the Kubernetes Pods Priority and Preemption documentation to find out how to define and use priority classes in your cluster.

    Pod Disruption Budgets¶

    Creating the Pod Disruption Budget is the Kubernetes method to limit the number of Pods of an application that can go down simultaneously due to voluntary disruptions such as the cluster administrator’s actions during a deployment update. Distribution Budgets allow large applications to retain their high availability during maintenance and other administrative activities. The maxUnavailable and minAvailable options in the deploy/cr.yaml file can be used to set these limits. The recommended variant is the following:

    podDisruptionBudget:
       maxUnavailable: 1
    

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-03-14
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.