Deploy a serverless ASM gateway to support elastic services - Alibaba Cloud Service Mesh

A serverless Service Mesh (ASM) gateway is provided based on virtual nodes and Elastic Container Instance. It is applicable to service scenarios that require elastic resources and do not require node maintenance. This topic describes how to deploy a serverless ASM gateway.

Prerequisites

A Container Service for Kubernetes (ACK) cluster (an ACK standard cluster, an ACK Pro cluster, or an ACK dedicated cluster) is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
Note
If you create an ASM gateway in a Serverless Kubernetes (ASK) cluster in the ASM console, the pods run on elastic container instances, and you do not need to perform the operations described in this topic. For more information about how to create a gateway, see Create an ingress gateway service.
The ack-virtual-node component is deployed. For more information, see Deploy the virtual node controller and use it to create Elastic Container Instance-based pods.
An ingress gateway is deployed.

Terms

Term	Description
Elastic Container Instance	Elastic Container Instance is a serverless elastic computing service. This container service provided by Alibaba Cloud frees you from O&M and provides strong isolation and fast startup for container runtime environments. Elastic Container Instance allows you to focus on container applications without the need to purchase and manage underlying Elastic Compute Service (ECS) servers or maintain the underlying infrastructure. You can create elastic container instances based on your business requirements and pay only for resources that you configure for containers based on the quantity and seconds. For more information, see What is Elastic Container Instance? and Billing overview.
Virtual node	A virtual node helps you significantly reduce computing costs and improve elastic computing efficiency in scenarios with obvious computing load fluctuations.
Taint	A taint allows a node to repel a set of pods. By default, all virtual nodes in an ACK cluster are added with the `virtual-kubelet.io/provider=alibabacloud:NoSchedule` taint. This prevents you from using elastic container instances by accident.
Toleration	Tolerations are applied to pods and allow the pods to be scheduled to nodes with matching taints. To allow pods in an ACK cluster to use elastic container instances, configure the following `tolerations` to tolerate the `virtual-kubelet.io/provider=alibabacloud:NoSchedule` taint. For more information, see Deploy the virtual node controller and use it to create Elastic Container Instance-based pods. `tolerations: - key: virtual-kubelet.io/provider operator: Equal value: alibabacloud effect: NoSchedule` Note Taints and tolerations work together to prevent the system from scheduling pods to inappropriate nodes. One or more taints can be applied to a node. If a pod does not tolerate a specific taint, a node with the matching taint does not accept the pod. Specifically, the pod cannot be scheduled to a node with the matching taint. If a pod tolerates a specific taint, the pod can but is not required to be scheduled to a node with the matching taint. For more information, see Taints and Tolerations.
Node affinity	Node affinity attracts pods to a set of nodes. Node affinity rules can be required or preferred. If no soft rules or preferred rules are met, the pods are scheduled to other nodes.

Step 1: Add a label to the desired node

Run the following command to obtain the names of the nodes in the specific cluster:
```
kubectl get nodes
```

Run the following command to add a label to the desired node:

# Command format 
kubectl label nodes <node-name> <label-key>=<label-value>

# Sample command 
kubectl label nodes node1 mykey4pod=asmgateway

Step 2: Add a taint to the node

Run the following command to add a taint to the node:

kubectl taint nodes node1 mykey=myvalue:NoSchedule

This command adds a taint to node1. The key is mykey, the value is myvalue, and the effect is NoSchedule. This way, only pods that tolerate the taint can be scheduled to node1.

Step 3: Set node affinity and tolerations for the ASM gateway

Configure the nodeAffinity-related parameters of the ASM gateway so that pods of the ASM gateway are scheduled to the corresponding nodes. Configure the tolerations-related parameters to match the taint created in Step 2 so that pods of the ASM gateway can be scheduled to node1.

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 gateway that you want to set and click YAML on the right.

In the Edit dialog box, add the following content to the spec field and click OK.

   affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - preference:
            matchExpressions:
              - key: type
                operator: In
                values:
                  - virtual-kubelet
          weight: 20
        - preference:
            matchExpressions:
              - key: mykey4pod
                operator: In
                values:
                  - asmgateway
          weight: 80
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: mykey4pod
                operator: In
                values:
                  - asmgateway
          - matchExpressions:
              - key: type
                operator: In
                values:
                  - virtual-kubelet
  tolerations:
    - effect: NoSchedule
      key: virtual-kubelet.io/provider
      operator: Equal
      value: alibabacloud
    - effect: NoSchedule
      key: mykey
      operator: Equal
      value: myvalue

The following table describes key parameters. For more information about the parameters, see Assigning Pods to Nodes.

Parameter	Description
`preferredDuringSchedulingIgnoredDuringExecution`	The scheduler tries to find a node that meets the rule. If no matching nodes are found, the scheduler still schedules the pods. This parameter is associated with two `matchExpressions` fields. The values of the `weight` field are relative values, and the configuration with a greater value is preferred. If the configuration with `weight` `20` is used, the pods are scheduled to use elastic container instances. If the configuration with `weight` `80` is used, the pods are scheduled to the ECS node with the specified label.
`requiredDuringSchedulingIgnoredDuringExecution`	The scheduler schedules the pods only when the rule is met. This parameter is associated with two `matchExpressions` fields. One indicates that the pods are scheduled to the ECS node with the specified label, and the other one indicates that the pods are scheduled to use elastic container instances.
`tolerations`	The configurations in the preceding example indicate that the pods tolerate the `virtual-kubelet.io/provider=alibabacloud:NoSchedule` taint and can use elastic container instances.

Check whether the node of the gateway pods meets expectations.
1. Log on to the ACK console and click Clusters in the left-side navigation pane.
2. On the Clusters page, click the name of a cluster and choose Workloads > Pods in the left-side navigation pane.
3. In the upper part of the Pods page, select istio-system from the Namespace drop-down list and check the node of the gateway pods.
  If the node of the gateway pods meets expectations, the desired node affinity and tolerations are set for the ASM gateway.