Customizing node affinity and pod annotations

The FNCM operator allows for setting node affinity or anti-affinity, giving you a choice over the nodes where your pods are deployed. With this feature, you can add custom labels and annotations to the deployed pods.

About this task

Node affinity feature uses the requiredDuringSchedulingIgnoredDuringExecution scheduler rule. If a node does not satisfy the affinity clause, the pod is still scheduled. For more information, see Node affinity in Kubernetes documentation. You can assign multiple selector match expressions to your deployments.

The node affinity cannot be used to assign architecture, as kubernetes.io/arch label is not recognized.

Pod annotations and labels are key-value pairs that are used to identify important information about an object that a user might find useful. For more information, see Labels and Selectors and Annotations in Kubernetes documentation.

Procedure

  1. Assign all Navigator and Content Platform Engine pods to a specific node.
    1. Obtain existing node labels.
      kubectl get nodes --show-labels=true
      Note: To better organize your deployment, you can consider adding new custom labels to your nodes. For more information, see Add a label to a node in Kubernetes documentation.
    2. Add the node_affinity section to the custom resource.
      ecm_configuration:
        cpe:
          node_affinity:
            custom_node_selector_match_expression:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker0
      
      navigator_configuration:
        node_affinity:
          custom_node_selector_match_expression:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - worker1
                - worker3
      
      Note: You can use many different combinations of operators within your custom node affinity match expression. For more information, see Operators in Kubernetes documentation.
    3. To assign node anti-affinity, adjust the node affinity match expression with the NotIn operators.
      ecm_configuration:
        node_affinity:
          custom_node_selector_match_expression:
            - key: kubernetes.io/hostname
              operator: NotIn
              values:
                - worker0
      
      Note: The above example specifies node affinity at the ecm_configuration level. This applies to all components under ecm_configuration.
    4. Apply the updated custom resource.
      kubectl replace -f ibm_fncm_cr_production.yaml
    After the operator reconciles, all the Content Platform Engine pods are moved to node with label kubernetes.io/hostname=worker0 and all Navigator pods will be moved to nodes with label kubernetes.io/hostname=worker1, kubernetes.io/hostname=worker3.
  2. Add custom annotations to the Content Platform Engine and custom labels to the Navigator pods to specify use.
    Annotations:
    DepartmentAnnotation: Sales
    DivisionAnnotation: TechSales
    Labels:
    DepartmentLabel: Sales
    DivisionLabel: TechSales
    1. Add the custom_annotations section to the custom resource.
      ecm_configuration:
        cpe:
          custom_annotations:
            DepartmentAnnotation: Sales
            DivisionAnnotation: TechSales
          
    2. Add the custom_labels section to the custom resource.
      navigator_configuration:
        custom_labels:
          DepartmentLabel: Sales
          DivisionLabel: TechSales
    3. Apply the updated custom resource.
      kubectl replace -f ibm_fncm_cr_production.yaml
    After the operator reconciles, all the Content Platform Engine pods will have two new annotations and Navigator will have two new labels. To verify the changes, describe pod and check the Labels and Annotations section:
    export cpe_pod=$(kubectl get pods | grep cpe | awk '{print $1}')
    kubectl describe pod $cpe_pod