Configure Node Selection for Flex Gateway Deployments on Kubernetes (Node Affinity)

Flex Gateway is often critical to the performance and security of a cluster, so it is important to host it on a specialized node that meets specific requirements, instead of using the nodes that host other deployments.

To enable the Kubernetes scheduler to select a suitable host node for a Pod that contains Flex Gateway, you can set custom node affinity rules in a YAML configuration file that incorporates the Pod’s requirements into a Helm chart for your Flex Gateway deployment. For more information about node affinity, see the Kubernetes documentation.

The high-level tasks for configuring node affinity follow:

Finding or creating the node labels to use when defining node affinity rules and conditions (see List and Create Node Labels).
Specifying requirements and preferences in a YAML configuration file for a node that hosts a Pod with a containerized Flex Gateway application (see Configure Rules for Matching a Node to a Pod for a Flex Gateway Container).
Upgrading your Helm chart with the YAML configuration (see Upgrade the Helm Chart).

Before You Begin

Meet the minimum Kubernetes and Helm version requirements described in the software requirements.

List and Create Node Labels

Each node affinity rule requires the key of a node label and one or more of the label’s values. You can use existing node labels or create new ones. A node label is defined as a key-value pair.

To list a cluster’s nodes and node labels, run:
```
kubectl get nodes --show-labels
```

To create a label for a node in your cluster, run:

kubectl label nodes <node-name> <label-key>=<label-value>

For related Kubernetes documentation, see Add a Label to a Node.

Configure Rules for Matching a Node to a Pod for a Flex Gateway Container

The Kubernetes scheduler can use node affinity rules to match nodes to Pods. The matching process enables the scheduler to select the node into which a Pod is deployed.

Configure node affinity rules as required, preferred, or both:

requiredDuringSchedulingIgnoredDuringExecution: The node must match all node affinity rules configured for a Pod when the Kubernetes scheduler applies this type of matching. Otherwise, the deployment fails.
preferredDuringSchedulingIgnoredDuringExecution: Based on weighted preferences set for a Pod, the Kubernetes scheduler selects the best matching node. The scheduler must select a node, so if no node matches any of the preferences, the scheduler selects a node that does not match.

For guidance, see the following configuration options:

Configure a Required Node Matching Rule for a Pod Containing Flex Gateway
Configure a Preferred Node Matching Rule for a Pod Containing Flex Gateway
Configure Required and Preferred Node Matching Rules for a Pod Containing Flex Gateway

Configure a Required Node Matching Rule for a Pod Containing Flex Gateway

In required node matching, the node must meet all node affinity rules configured for a Pod. Otherwise, the deployment fails.

affinity:
 nodeAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
     nodeSelectorTerms:
     - matchExpressions:
       - key: <node-label-key>
         operator: <operator>
         values:
         - <node-label-value>
       # - Add any other node label values.
    # - Add any other required conditions.

You can add as many values and conditions as the node requires.

After configuring the YAML configuration file for the Pod, proceed to Upgrade the Helm Chart.

Configure a Preferred Node Matching Rule for a Pod Containing Flex Gateway

In preferred node matching, the Kubernetes scheduler selects a node based on weighted preferences. The scheduler must select a node, so if no node matches any preferences, the scheduler selects a node that does not match.

Configure a node affinity rule in the YAML configuration file for a Pod that contains Flex Gateway. Each condition to a rule requires a node label as a key, an operator, and one or more node label values to accept for a node with that key. For operators, you can use In, NotIn, Exists, DoesNotExist, Gt, and Lt. In addition, provide a weight value between 1 and 100 for each preference so that the Kubernetes scheduler can determine which rules are more important and select the best matching node. Matching is based on the sum of the weighted preferences that a node meets. The scheduler selects a node with the greatest total weight over other nodes of lesser weight.

affinity:
 nodeAffinity:
   preferredDuringSchedulingIgnoredDuringExecution:
   - weight: <integer-x>
     preference:
       matchExpressions:
       - key: <node-label-key1>
         operator: <operator>
         values:
         - <node-label-value>
       # - Add any other values.
    - weight: <integer-y>
      preference:
        matchExpressions:
        - key: <node-label-key2>
          operator: <operator>
          values:
          - <node-label-value>
        # - Add any other node label values.
      # - Add any other preferred conditions.
  # - Any any more preferred rules.

You can add any number of preferred values, conditions, and rules.

After configuring the YAML configuration file for the Pod, proceed to Upgrade the Helm Chart.

Configure Required and Preferred Node Matching Rules for a Pod Containing Flex Gateway

You can configure both types of node affinity (required and preferred) in the same YAML file.

The example combines the settings from Configure a Required Node Matching Rule for a Pod Containing Flex Gateway and Configure a Preferred Node Matching Rule for a Pod Containing Flex Gateway.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: <node-label-key>
          operator: <operator>
          values:
          - <node-label-value>
        # - Add any other node label values.
    # - Add any other conditions.
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: <integer-x>
        preference:
          matchExpressions:
          - key: <node-label-key1>
            operator: <operator>
            values:
            - <node-label-value>
          # - Add any other node label values.
      - weight: <integer-y>
        preference:
          matchExpressions:
          - key: <node-label-key2>
            operator: <operator>
            values:
            - <node-label-value>
          # - Add any other node label values.
       # - Add any other preferred conditions.
    # - Any any other preferred rules.

After configuring the YAML configuration file for the Pod, proceed to Upgrade the Helm Chart.

Upgrade the Helm Chart

After adding the node affinity settings to your YAML configuration file, incorporate the file into the Helm chart for a Flex Gateway deployment so that the Kubernetes scheduler can use the setting.

Use a helm command to incorporate the node affinity settings from your YAML configuration file into a Helm chart. The command to use depends on whether Flex Gateway is installed:

If you are installing Flex Gateway for the first time, use this command to set all values in the chart:
```
helm -n gateway upgrade -i --create-namespace \
--wait ingress flex-gateway/flex-gateway \
-f <path-to-yaml-file> \
--set-file registration.content=<path-to-registration>
```
Notice that the command passes the YAML file with the node affinity rules.
If Flex Gateway is installed already, use this command to reuse the chart’s existing configuration and set the node affinity configuration:
```
helm -n gateway upgrade -i --create-namespace \
--wait ingress flex-gateway/flex-gateway \
--reuse-values -f <path-to-yaml-file>
```
Notice that the command passes the YAML file with the node affinity rules.

For information about the Helm command, see Helm Upgrade.