Skip to main content

MarkLogic Server on Kubernetes

High availability and pod anti-affinity

To attempt to provide the highest availability deployment, the MarkLogic Helm chart provides a default affinity configuration that prefers to schedule one MarkLogic pod per worker node using the preferred rule. However, if a one-MarkLogic-pod-per-worker node configuration must be strictly enforced, the required rule is recommended.

Preferred rule

The preferred rule, podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution, is a softly enforced rule that prefers scheduling MarkLogic pods on different worker nodes:

affinity: 
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - marklogic
        topologyKey: kubernetes.io/hostname

However, the rule will still co-locate the MarkLogic pods if the worker nodes are limited.

Required rule

The strict rule, podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution, is a rigidly enforced rule that requires scheduling MarkLogic pods on different worker nodes:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/name
          operator: In
          values:
          - marklogic
      topologyKey: kubernetes.io/hostname

Use this rule, for example, if there is only one worker node but you want to create two MarkLogic pods. In this case, the rule will cause the second pod to remain in pending status until a second worker node with adequate resources is created.

Pods running on different worker nodes and in separate zones

Spreading resources across availability zones is part of the availability equation in the cloud. However, because the MarkLogic Helm chart may be used in non-cloud environments, there is no default affinity setting that includes zones. To deploy to the cloud and to deploy across zones, include a pod affinity for topologyKey: topology.kubernetes.io/zone. This affinity rule prefers scheduling pods to run on different worker nodes and in separate zones:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - marklogic
        topologyKey: kubernetes.io/hostname
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - marklogic
        topologyKey: topology.kubernetes.io/zone
In this section: