--- schema_version: "1" id: 5d00c3208f2defb94d238d9f12a95497fcdf68387ed1808ef4db1b1722d031dd title: Configure Node Selection for Flex Gateway Deployments on Kubernetes (Node Affinity) collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/1.12/flex-gateway-k8-node-affinity-config.md canonical_url: https://docs.mulesoft.com/gateway/1.12/flex-gateway-k8-node-affinity-config source_site: docs.mulesoft.com content_type: documentation content_hash: 6b96ef9c8cd20c900da12925423a7be18e88e9685c431de6f69ba8f40434b25e description: MuleSoft Documentation Site release: "1.12" latest: false --- --- product: Omni Gateway version: 1.12 --- # Configure Node Selection for Flex Gateway Deployments on Kubernetes (Node Affinity) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). 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](#list_add_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](#set_node_affinity)). 3. Upgrading your Helm chart with the YAML configuration (see [Upgrade the Helm Chart](#upgrade_helm_chart)). ## Before You Begin Meet the minimum Kubernetes and Helm version requirements described in the [software requirements](https://docs.mulesoft.com/gateway/1.12/flex-review-prerequisites#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: ```kubernetes kubectl get nodes --show-labels ``` - To create a label for a node in your cluster, run: ```kubernetes kubectl label nodes = ``` For related Kubernetes documentation, see [Add a Label to a Node](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#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](#required_node_matching) - [Configure a Preferred Node Matching Rule for a Pod Containing Flex Gateway](#preferred_node_matching) - [Configure Required and Preferred Node Matching Rules for a Pod Containing Flex Gateway](#mixed_node_matching) ### 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`. ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - 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](#upgrade_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. ```yaml affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other values. - weight: preference: matchExpressions: - key: operator: values: - # - 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](#upgrade_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](#required_node_matching) and [Configure a Preferred Node Matching Rule for a Pod Containing Flex Gateway](#preferred_node_matching). 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. ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other conditions. preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. - weight: preference: matchExpressions: - key: operator: values: - # - 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_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: ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ -f \ --set-file registration.content= ``` 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: ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --reuse-values -f ``` Notice that the command passes the YAML file with the node affinity rules. For information about the Helm command, see [Helm Upgrade](https://helm.sh/docs/helm/helm_upgrade).