How to deploy gateway pods to specific nodes - Alibaba Cloud Service Mesh

When ASM gateway pods share nodes with application workloads, resource contention can degrade gateway performance or cause scheduling failures during traffic spikes. Dedicating specific nodes to gateway pods isolates ingress traffic handling from business logic, prevents resource competition, and creates a clear security boundary.

The following steps use node labels, taints, and node affinity to pin ASM gateway pods to specific nodes and keep other workloads off those nodes.

How it works

Dedicated scheduling combines three Kubernetes mechanisms:

Mechanism	Purpose
Node label	Identifies the target node so that affinity rules can select it
Taint	Repels all pods that lack a matching toleration, keeping other workloads off the node
Node affinity + toleration	Attracts gateway pods to the labeled node and allows them to tolerate the taint

Taints and tolerations work together to prevent the system from scheduling pods to inappropriate nodes:

If a pod does not tolerate a specific taint, a node with the matching taint does not accept the pod. The pod cannot be scheduled to that node.
If a pod tolerates a specific taint, the pod can but is not required to be scheduled to a node with the matching taint.

Without the taint, other pods can still land on the labeled node. Without node affinity, gateway pods can be scheduled elsewhere. Combining all three guarantees that gateway pods run only on the designated node.

Prerequisites

Before you begin, make sure that you have:

A cluster added to the ASM instance
An ingress gateway deployed
kubectl configured to connect to the cluster

Step 1: Label the target node

Add a label to the node where gateway pods should run. The scheduler uses this label in the node affinity rule configured in Step 3.

List all nodes in the cluster:
```
   kubectl get nodes
```
Add a label to the target node:
```
   # Syntax
   kubectl label nodes <node-name> <label-key>=<label-value>

   # Example
   kubectl label nodes node1 mykey4pod=asmgateway
```
Replace the following placeholders:
Placeholder Description Example
<node-name> Name of the target node from the output of kubectl get nodes node1
<label-key> A custom label key mykey4pod
<label-value> A custom label value asmgateway

Placeholder	Description	Example
`<node-name>`	Name of the target node from the output of `kubectl get nodes`	`node1`
`<label-key>`	A custom label key	`mykey4pod`
`<label-value>`	A custom label value	`asmgateway`

Verify the label:

   kubectl get nodes --show-labels | grep mykey4pod

Step 2: Taint the target node

Add a taint to the node to repel pods that lack a matching toleration. This keeps application workloads off the dedicated gateway node.

kubectl taint nodes node1 mykey=myvalue:NoSchedule

This taint has three components:

Component	Value	Meaning
Key	`mykey`	Identifies the taint
Value	`myvalue`	Paired with the key to form the taint identity
Effect	`NoSchedule`	Prevents new pods without a matching toleration from being scheduled to this node. Existing pods are not evicted.

Note

Note: Kubernetes supports three taint effects:

Effect	Behavior
`NoSchedule`	Blocks new pods that do not tolerate the taint. Existing pods remain.
`PreferNoSchedule`	Soft version of `NoSchedule`. The scheduler tries to avoid the node but does not guarantee it.
`NoExecute`	Blocks new pods and evicts existing pods that do not tolerate the taint.

For gateway node isolation, NoSchedule is typically sufficient. Use NoExecute if you also need to remove existing non-gateway pods from the node.

Step 3: Configure node affinity and tolerations on the ASM gateway

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.
On the Ingress Gateway page, find the target gateway and click YAML.

In the Edit dialog box, add the following block to the spec field, then click OK.

Field	Description
`requiredDuringSchedulingIgnoredDuringExecution`	Hard affinity rule -- the scheduler only places pods on nodes that match. Use `preferredDuringSchedulingIgnoredDuringExecution` for a soft rule that allows fallback to other nodes.
`matchExpressions.key` / `values`	Must match the label added in Step 1 (`mykey4pod=asmgateway`).
`tolerations.key` / `value` / `effect`	Must match the taint added in Step 2 (`mykey=myvalue:NoSchedule`).

   affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: mykey4pod
               operator: In
               values:
               - asmgateway
     tolerations:
     - key: "mykey"
       operator: "Equal"
       value: "myvalue"
       effect: "NoSchedule"

Step 4: Verify the scheduling result

Confirm that gateway pods are running on the dedicated node.

Option A: Use kubectl

kubectl get pods -n istio-system -o wide | grep <gateway-name>

The output is similar to:

<gateway-name>-xxx   1/1   Running   0   2m   10.x.x.x   node1   <none>   <none>

The NODE column should show node1 (or the node you labeled and tainted).

Option B: Use the ACK console

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster and click its name. In the left-side navigation pane, choose Workloads > Pods.
On the Pods page, select istio-system from the Namespace drop-down list.
Check the Node column for the gateway pods. The value should match the node you configured.

What to do next

To schedule gateway pods across multiple dedicated nodes for higher availability, label and taint additional nodes, then add their labels to the matchExpressions.values array.
To remove the scheduling constraints, delete the label and taint from the node, and remove the affinity and tolerations blocks from the gateway YAML.