All Products
Search
Document Center

Container Service for Kubernetes:Use MSE Ingresses to access applications in ACK clusters

Last Updated:Mar 01, 2026

Standard NGINX Ingress Controller does not support complex traffic routing, multiple application-layer protocols such as Dubbo and QUIC, or Layer 7 traffic balancing. MSE Ingress is an Ingress implementation built on cloud-native gateways of Alibaba Cloud Microservices Engine (MSE). It is compatible with NGINX Ingresses and NGINX Ingress annotations, and addresses these gaps with the following capabilities:

  • Protocol support: Handles Dubbo, QUIC, and other application-layer protocols in addition to HTTP/HTTPS.

  • Traffic governance: Provides canary releases for multiple service versions and flexible traffic routing rules.

  • Security protection: Includes built-in security features at the gateway level.

  • High availability: Runs as a fully managed, multi-replica gateway.

This topic describes how to configure an MSE Ingress to route external traffic to applications in a Container Service for Kubernetes (ACK) cluster. For more information about MSE Ingresses and how they work, see MSE Ingress management.

Prerequisites

Before you begin, make sure that:

Step 1: Create an MSE cloud-native gateway

An MseIngressConfig is a CustomResourceDefinition (CRD) provided by MSE Ingress Controller. It manages the lifecycle and global configurations of an MSE cloud-native gateway.

Important

One MseIngressConfig maps to one cloud-native gateway. If you need multiple gateways, create multiple MseIngressConfigs. Deleting an MseIngressConfig also deletes its mapped cloud-native gateway, except in the reuse scenario.

Run the following command to create a gateway named mse-ingress with three replicas. Each replica uses 2 vCPUs and 4 GB of memory.

cat << EOF | kubectl apply -f -
apiVersion: mse.alibabacloud.com/v1alpha1
kind: MseIngressConfig
metadata:
  name: test
spec:
  name: mse-ingress                # Name of the cloud-native gateway
  common:
    instance:
      spec: 2c4g                   # 2 vCPUs, 4 GB memory per replica (default: 4c8g)
      replicas: 3                  # Number of gateway replicas (default: 3)
EOF
Note

When you omit optional configurations, the system applies defaults:

  1. vSwitch: Automatically selects the vSwitch of the Kubernetes node scheduled by the MSE Ingress Controller. Only one vSwitch is configured. For production environments, manually configure two vSwitches.

  2. SLB: Automatically creates an Internet-facing Server Load Balancer (SLB) instance with slb.s2.small specifications.

  3. Security group: Automatically creates a basic security group.

The following table describes the parameters in spec.

Parameter

Required

Default

Description

spec.name

No

-

The name of the cloud-native gateway.

spec.common.instance.spec

No

4c8g

The specifications per replica. For example, 2c4g means 2 vCPUs and 4 GB of memory.

spec.common.instance.replicas

No

3

The number of gateway replicas.

For the full parameter reference, see Configure an MseIngressConfig.

Step 2: Create an IngressClass resource

An IngressClass resource declares which Ingress controller handles a set of Ingress resources. Associate the IngressClass with the MseIngressConfig created in Step 1 so that the cloud-native gateway processes matching Ingress rules.

Choose one of the following methods based on your scenario.

Method 1: Use a Kubernetes IngressClass resource (recommended)

Use this method for new services that access the MSE Ingress. Run one of the following commands based on your cluster's Kubernetes version.

Clusters running Kubernetes versions earlier than v1.19

cat << EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
  name: mse
spec:
  controller: mse.alibabacloud.com/ingress
  parameters:
    apiGroup: mse.alibabacloud.com       # API group of MseIngressConfig
    kind: MseIngressConfig               # Resource kind
    name: test                           # Name of the MseIngressConfig from Step 1
EOF

Clusters running Kubernetes v1.19 or later

cat << EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: mse
spec:
  controller: mse.alibabacloud.com/ingress
  parameters:
    apiGroup: mse.alibabacloud.com       # API group of MseIngressConfig
    kind: MseIngressConfig               # Resource kind
    name: test                           # Name of the MseIngressConfig from Step 1
EOF

Method 2: Use MseIngressConfig resources (for migration)

Use this method when migrating from NGINX Ingress to MSE Ingress, or in scenarios where IngressClass resources cannot be created. During migration, both NGINX Ingress and MSE Ingress must listen to the same IngressClass resource. This method lets you configure the IngressClass directly within the MseIngressConfig, avoiding IngressClass name conflicts.

Add the ingressClass field to the MseIngressConfig created in Step 1:

apiVersion: mse.alibabacloud.com/v1alpha1
kind: MseIngressConfig
metadata:
  name: test
spec:
  name: mse-ingress
  common:
    instance:
      spec: 2c4g
      replicas: 3
  ingress:
    local:
      ingressClass: mse                  # IngressClass name to listen on

The following table describes the ingress.local.ingressClass values.

Value

Behavior

Not configured

The gateway does not listen to any Ingress resources.

mse

The gateway listens to Ingress resources associated with the IngressClass named mse.

"" (empty string)

The gateway listens to all Ingress resources.

nginx

The gateway listens to Ingress resources associated with the IngressClass named nginx, and Ingress resources not associated with any IngressClass.

Other values

The gateway listens to Ingress resources associated with the specified IngressClass.

Note

If both a Kubernetes IngressClass resource (Method 1) and this parameter are configured, the Kubernetes IngressClass resource takes precedence.

Verify the gateway status

Run the following command to check the MseIngressConfig status:

kubectl get MseIngressConfig test

Expected output:

NAME   STATUS      AGE
test   Listening   3m15s

The Listening status confirms that the cloud-native gateway is running and watching for Ingress resources associated with the mse IngressClass.

The status transitions in the following order:

StatusDescription
PendingThe gateway is being created. This process takes about 3 minutes.
RunningThe gateway is created and running.
ListeningThe gateway is running and listening to Ingress resources in the cluster.
FailedThe gateway is invalid. Run kubectl describe MseIngressConfig test and check the Message field in Status to identify the cause.

Step 3: Route traffic to an application

Deploy a sample backend service

Run the following command to deploy the go-httpbin service:

cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-httpbin
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-httpbin
  template:
    metadata:
      labels:
        app: go-httpbin
        version: v1
    spec:
      containers:
        - image: specialyang/go-httpbin:v3
          args:
            - "--port=8090"            # Application listens on port 8090
            - "--version=v1"           # Reports version v1
          imagePullPolicy: Always
          name: go-httpbin
          ports:
            - containerPort: 8090
---
apiVersion: v1
kind: Service
metadata:
  name: go-httpbin
  namespace: default
spec:
  ports:
    - port: 80                         # Service port exposed to Ingress
      targetPort: 8090                 # Forwards to container port 8090
      protocol: TCP
  selector:
    app: go-httpbin
EOF

Create an Ingress resource

Run one of the following commands to create an Ingress resource. The Ingress routes requests for example.com/version to the go-httpbin service.

Clusters running Kubernetes versions earlier than v1.19

cat << EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: default
spec:
  ingressClassName: mse                  # Associates with the MSE IngressClass
  rules:
   - host: example.com
     http:
      paths:
      - path: /version
        backend:
          serviceName: go-httpbin
          servicePort: 80
EOF

Clusters running Kubernetes v1.19 or later

cat << EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  namespace: default
spec:
  ingressClassName: mse                  # Associates with the MSE IngressClass
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          service:
            name: go-httpbin
            port:
              number: 80
        path: /version
        pathType: Prefix
EOF

Verify the result

  1. Get the address assigned to the Ingress: Expected output:

       kubectl get ingress ingress
       NAME      CLASS   HOSTS            ADDRESS         PORTS   AGE
       ingress   mse     example.com      114.55.XX.XX   80      12m
  2. Send a test request using the Ingress address: Expected output: The version:v1 response confirms that traffic is routed through the MSE Ingress to the go-httpbin backend service.

       curl -H "host: example.com" <ADDRESS>/version
       version:v1
Note

If the ADDRESS field is empty, the cloud-native gateway may still be provisioning. Wait a few minutes and run kubectl get ingress ingress again. If the issue persists, check the MseIngressConfig status with kubectl describe MseIngressConfig test.

Clean up resources

To remove the sample resources created in this tutorial, run the following commands:

kubectl delete ingress ingress
kubectl delete service go-httpbin
kubectl delete deployment go-httpbin
Warning

Deleting the MseIngressConfig also deletes the associated MSE cloud-native gateway. Only delete it if you no longer need the gateway:

kubectl delete MseIngressConfig test

What's next