You can deploy a Service Mesh (ASM) ingress gateway in a Kubernetes cluster to act as a single entry point for access to your applications over the Internet or an internal network. The ingress gateway can simplify the management and routing of traffic, and use load balancing capabilities at Layer 7 to intelligently distribute traffic to the corresponding backend services based on paths in HTTP requests, host headers, or other attributes.
Prerequisites
Procedure
Log on to the ASM console. In the left-side navigation pane, choose .
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose
.On the Ingress Gateway page, click Create. On the Create page, configure the required parameters of the gateway.
The following table describes the parameters. You can also click Create from YAML on the Ingress Gateway page to create an ingress gateway. For more information, see Create and manage an ingress gateway by using the Kubernetes API.
Parameter
Description
Name
The name of the ingress gateway.
Cluster
The cluster in which you want to deploy the ingress gateway.
Service Type
The service type. Valid values: LoadBalancer, ClusterIP, and NodePort. For descriptions of the three types, see Service.
NoteIf your cluster on the data plane is a registered cluster and you need to select LoadBalancer, make sure that the cluster supports LoadBalancer Services to prevent ingress gateway creation failures.
CLB Instance Type
The access type of the Classic Load Balancer (CLB) instance. You must specify this parameter when you set Service Type to LoadBalancer.
Valid values: Internet Access and Private Access.
Create a CLB Instance or Use Existing CLB Instance
You must select either of the two options when you set Service Type to LoadBalancer.
Use Existing CLB Instance: Select an existing CLB instance from the drop-down list.
Create a CLB Instance: Click Create a CLB Instance and select the CLB instance specifications that you need from the drop-down list.
ImportantWe recommend that you assign a CLB instance to each Kubernetes Service in the cluster. If multiple Kubernetes Services share the same CLB instance, the following risks and limits exist:
If you assign a Kubernetes Service with a CLB instance that is used by another Kubernetes Service, the existing listeners of the CLB instance are forcibly overwritten. This may interrupt the original Kubernetes Service and make your applications unavailable.
The CLB instance that is created for a Kubernetes Service cannot be shared by other Kubernetes Services. Only CLB instances that you create in the CLB console or by calling API operations can be shared.
Kubernetes Services that share the same CLB instance must use different frontend listening ports. Otherwise, port conflicts may occur.
If multiple Kubernetes Services share the same CLB instance, listener names and vServer group names are used as unique identifiers in Kubernetes. The names of listeners or vServer groups cannot be changed.
You cannot share a CLB instance across clusters or regions.
Port Mapping
The ports that services need to expose. Set Protocol and Service Port.
NoteBy default, two ports that are commonly used by Istio appear in the console. You can change the default ports as needed.
Resources Limits
The CPU and memory specifications for the pod of the ingress gateway.
Gateway instances
The number of pod replicas for the ingress gateway.
(Optional) Click Advanced Options and configure the parameters that are described in the following table.
Parameter
Description
External Traffic Policy
The policy to distribute external traffic. Valid values:
Local: Traffic is routed only to pods on the node where the ingress gateway is deployed.
Cluster: Traffic can be routed to pods on other nodes in the cluster.
HPA
Select HPA and set the following parameters:
metrics: Set Monitoring items and Threshold. If the metric value exceeds the specified threshold, the number of pod replicas increases for the ingress gateway. If the metric value is below the specified threshold, the number of pod replicas decreases for the ingress gateway.
If you specify thresholds for CPU utilization and memory usage, both thresholds take effect. In this case, if the CPU utilization or memory usage exceeds or is below the specified threshold, the ingress gateway is accordingly resized.
Maximum replicas: the maximum number of pod replicas for the ingress gateway.
Minimum number of replicas: the minimum number of pod replicas for the ingress gateway.
NoteThis feature is available only to ASM instances of Enterprise or Ultimate Edition.
Rolling Upgrade
Select Rolling Upgrade and set the following parameters:
Maximum number of unavailable instances: the maximum number of pod replicas that can be unavailable during a rolling update.
Exceeding the desired number of instances: the maximum number of pod replicas that can be created over the expected number of replicas during a rolling update. For example, if you set this parameter to 25%, the number of replicas during a rolling update cannot exceed 125% of the expected number of replicas.
Enable MultiBuffer-based TLS encryption and decryption performance optimization
Specifies whether to enable the Transport Layer Security (TLS) performance optimization feature. This feature speeds up TLS encryption and decryption.
supported nodeaffinity: Select the label of the nodes on which the performance optimization feature takes effect.
Poll Delay(ms): A specified polling delay reduces the time Multi-Buffer waits before processing requests. For more information, see the parameter description in the Enable Multi-Buffer for TLS acceleration topic.
NoteThis feature is available only to ASM instances of Enterprise or Ultimate Edition.
Deploy ASM Gateway replicas as widely as possible
When
podAntiAffinity
is set for the ingress gateway, gateway pods are preferentially deployed to different nodes.Custom Deployment Policy
You can configure the
nodeSelector
,tolerations
, andaffinity
fields for the ASM gateway. For more information about the fields, see CRD fields for an ASM gateway.Graceful Shutdown
After you select Graceful Shutdown, the ingress gateway is not affected if the CLB instance becomes unavailable.
Connection timeout (seconds): After the CLB instance is removed from the pod of the ingress gateway, the CLB instance is not disconnected from the pod of the ingress gateway until the specified time ends. During the specified time, the pod of the ingress gateway can handle the existing connections. The default offline grace period is 30 seconds. We recommend that you set a connection timeout that does not exceed 30 seconds.
NoteThis feature is available only to ASM instances of Enterprise or Ultimate Edition.
Click Create.
If the status of the ingress gateway is Running, the ingress gateway is created. Service address is the IP address of the ingress gateway.
Related operations
After the ingress gateway is created, you can manage the ingress gateway in the ASM console or view the ingress gateway in the ACK console.
Manage the ingress gateway in the ASM console
Log on to the ASM console. In the left-side navigation pane, choose .
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose
.On the Ingress Gateway page, perform the operations that are described in the following table.
Operation
Description
View or edit an ingress gateway
Method 1: Find the ingress gateway that you want to view or edit and click View Details. Then, you can modify the information based on your business requirements.
Method 2: Find the gateway that you want to view or modify and click YAML. In the Edit dialog box, modify the fields as needed and click OK. For more information about the fields, see CRD fields for an ASM gateway.
Delete an ingress gateway
Find the ingress gateway that you want to delete and click Delete. In the Submit message, click OK.
ImportantAfter the ingress gateway is deleted, external services cannot access services in the ASM instance by using the ingress gateway. An ingress gateway that is deleted cannot be restored. You can only create another one. Exercise caution when you perform this operation.
View the ingress gateway in the ACK console
To view the basic information about the ingress gateway, perform the following steps:
Log on to the ACK console and click Clusters in the left-side navigation pane.
On the Clusters page, click the name of the cluster that you want to manage and choose
in the left-side navigation pane.In the upper part of the Services page, select istio-system from the Namespace drop-down list.
You can view the basic information of the desired ingress gateway. The IP address in the External Endpoint column is the IP address of the ingress gateway.
To view the pod information of the ingress gateway, perform the following steps:
Log on to the ACK console and click Clusters in the left-side navigation pane.
On the Clusters page, click the name of the cluster that you want to manage and choose
in the left-side navigation pane.In the upper part of the Pods page, select istio-system from the Namespace drop-down list.
Click the desired pod to view the pod information about the ingress gateway.
References
For more information about how to create an ingress gateway by calling an API operation, see CreateASMGateway.
For more information about how to provide centralized traffic egress for applications in a mesh, see Create an egress gateway.
For more information about how to distribute traffic to different versions of a service based on a specified ratio, such as canary release and A/B testing, see Use Istio resources to route traffic to different versions of a service.
For more information about the call relationships and traffic flows among apps, services, and application versions, see Use Mesh Topology to view the topology of an application.
For more information about the features of ASM gateways, see Overview of ASM gateways.