Configure Node Selection for Flex Gateway Deployments on Kubernetes (Node Affinity) | MuleSoft Documentation
# 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:
  1. Finding or creating the node labels to use when defining node affinity rules and conditions (see List and Create Node Labels).
  2. 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).
  3. 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.
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`.
```
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.
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:
  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.