All Products
Search
Document Center

Container Service for Kubernetes:Expose services with ALB Ingress

Last Updated:Jun 20, 2026

By default, services in an ACK cluster are isolated from the external network. An ALB Ingress exposes these services by using an Application Load Balancer (ALB) as the entry point for external traffic. ALB provides domain-based routing, security, and high availability.

How it works

  1. Resource association

    An AlbConfig object defines the specific configurations of an ALB instance, such as its feature edition and listeners. Each AlbConfig object has a one-to-one mapping to an ALB instance. The path mappings and associated Services defined in an Ingress are automatically translated into routing rules and server groups for the ALB instance.

  2. Dynamic synchronization

    The ALB Ingress Controller continuously watches the API server for changes to Ingress and AlbConfig resources and dynamically updates the associated ALB instance.

  3. Traffic forwarding

    Unlike the Nginx Ingress Controller, the ALB Ingress Controller is a managed component that acts as the control plane for the ALB instance. It does not directly handle data plane traffic. The ALB instance processes user traffic and forwards it to the Service's backend pods.

image

Service type limitations

When using the Flannel network plugin, backend services for an ALB Ingress are limited to the NodePort and LoadBalancer types.

Install the ALB Ingress Controller

On cluster creation

  1. Log on to the ACK console and click Create Kubernetes Cluster.

  2. In the Component Configuration step, go to the Ingress section and select ALB Ingress.

  3. This example uses the New option. Follow the on-screen instructions to create the cluster.

    ALB Instance

    Description

    New

    Automatically creates an ALB instance, an AlbConfig, and an IngressClass.

    • ALB instance: Automatically creates a standard, pay-as-you-go, public or private ALB instance in the cluster's VPC and configures an HTTP:80 listener.

    • AlbConfig and IngressClass: Automatically creates the corresponding AlbConfig and IngressClass resources in the cluster and associates them with the ALB instance.

    Select Existing VPC

    This option is available only when the cluster is configured to use an existing Virtual Private Cloud (VPC).

    Uses an existing ALB instance and automatically creates an AlbConfig and an IngressClass. The specified ALB instance must be a Standard or WAF-enhanced edition, be in the same VPC as the cluster, and not be associated with another cluster.

    None

    Installs only the ALB Ingress Controller component. You must manually create an AlbConfig and an IngressClass later. This is suitable for scenarios where you need to customize the ALB instance configuration.

For an existing cluster

  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Components and Add-ons.

  3. Use the search box or click the Networking tab to find the component. On the ALB Ingress Controller component card, click Install in the lower-right corner.

  4. This example uses the New option. Click OK.

    ALB Instance

    Description

    New

    Automatically creates an ALB instance, an AlbConfig, and an IngressClass.

    • ALB instance: Automatically creates a standard, pay-as-you-go, public or private ALB instance in the cluster's VPC and configures an HTTP:80 listener.

    • AlbConfig and IngressClass: Automatically creates the corresponding AlbConfig and IngressClass resources in the cluster and associates them with the ALB instance.

    Existing

    Uses an existing ALB instance and automatically creates an AlbConfig and an IngressClass. The specified ALB instance must be a Standard or WAF-enhanced edition, be in the same VPC as the cluster, and not be associated with another cluster.

    None

    Installs only the ALB Ingress Controller component. You must manually create an AlbConfig and an IngressClass later. This is suitable for scenarios where you need to customize the ALB instance configuration.

Create a sample application

The sample application deploys a Deployment named coffee and a corresponding Service named coffee-svc.

Console

  1. On the Clusters page, click the name of your cluster. In the left navigation pane, click Workloads > Deployments.

  2. Click Create from YAML. Select Custom from the Sample Template drop-down list. Then, copy the following content into the template editor and click Create.

    Sample application YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: coffee
      template:
        metadata:
          labels:
            app: coffee
        spec:
          containers:
          - name: coffee
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
            ports:
            - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: coffee-svc
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP  # When you use the flannel network plugin, the backend Service of an ALB Ingress supports only the NodePort and LoadBalancer types.
  3. In the confirmation dialog box, click View and verify that the Pod status is Running.

kubectl

  1. Connect to a cluster by using kubectl.

  2. Create a file named coffee-deployment-service.yaml that contains the following content.

    Sample application YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: coffee
      template:
        metadata:
          labels:
            app: coffee
        spec:
          containers:
          - name: coffee
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
            ports:
            - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: coffee-svc
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP  # When you use the flannel network plugin, the backend Service of an ALB Ingress supports only the NodePort and LoadBalancer types.
  3. Create the Deployment and Service for the sample application.

    kubectl apply -f coffee-deployment-service.yaml
  4. Verify that the Pod status is Running.

     kubectl get pod -l app=coffee

    Expected output:

    NAME                      READY   STATUS    RESTARTS   AGE
    coffee-84bd6*****-*****   1/1     Running   0          4m22s
    coffee-84bd6*****-*****   1/1     Running   0          4m22s

Create an ALB Ingress

Configure the domain name and path mappings for the ALB Ingress to route requests for ingress-demo.com/coffee to the coffee-svc Service within the cluster.

To use an ALB Ingress in an ACK dedicated cluster, you must grant access permissions to the ALB Ingress Controller.

Console

  1. In the navigation pane on the left, choose Network > Ingresses. Select the default namespace and click Create Ingress.

  2. Specify the following Ingress parameters and click OK.

    • Name: coffee-ingress

    • Domain Name: ingress-demo.com

    • Mappings: Path: /coffee, Match Rule: Prefix, Service: coffee-svc, Port: 80.

      Matching rule (pathType)

      Description

      Prefix

      Matches the request path based on its prefix. For example, requests for /coffee/1 or /coffee/buy/1 are matched, but requests for /cof or /coffeebuy/1 are not.

      Exact

      Matches the request path exactly. Only requests for /coffee are matched.

      ImplementationSpecific

      The matching behavior depends on the Ingress controller implementation. For the ALB Ingress Controller, this type is equivalent to an Exact match.

  3. Obtain the Endpoint address.

    An ALB Ingress takes about 10 seconds to take effect. You can click the refresh button to get the endpoint information. If the endpoint is not updated after a long time, click the Ingress name and go to the Events tab to troubleshoot issues.

    In the Endpoint column of the Ingress list, find the ALB endpoint address, which is in a format similar to alb-<instance_id>.cn-wulanchabu.alb.aliyuncsslb.com.

  4. Test access to the domain and endpoint. An HTTP status code of 200 indicates that the ALB Ingress is working correctly.

    curl -H "Host:ingress-demo.com" http://<endpoint_address>/coffee -s -o /dev/null -w "%{http_code}\n"

kubectl

  1. Create a file named coffee-ingress.yaml with the following content. Then, run the kubectl apply -f coffee-ingress.yaml command to create the ALB Ingress.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: coffee-ingress
      namespace: default
    spec:
      ingressClassName: alb
      rules:
      - host: ingress-demo.com
        http:
          paths:
          - path: /coffee
            backend:
              service: 
                name: coffee-svc
                port:
                  number: 80
            pathType: Prefix

    Matching rule (pathType)

    Description

    Prefix

    Matches the request path based on its prefix. For example, requests for /coffee/1 or /coffee/buy/1 are matched, but requests for /cof or /coffeebuy/1 are not.

    Exact

    Matches the request path exactly. Only requests for /coffee are matched.

    ImplementationSpecific

    The matching behavior depends on the Ingress controller implementation. For the ALB Ingress Controller, this type is equivalent to an Exact match.

  2. View the Ingress and obtain the endpoint address from the ADDRESS field.

    kubectl get ingress coffee-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

    Expected output:

    alb-******************.cn-wulanchabu.alb.aliyuncsslb.com
  3. Test access to the domain and endpoint. An HTTP status code of 200 indicates that the ALB Ingress is working correctly.

    curl -H "Host:ingress-demo.com" http://<endpoint_address>/coffee -s -o /dev/null -w "%{http_code}\n"

Billing

  • ALB Ingress Controller: This is a managed ACK component and is free of charge.

  • ALB instance: Each AlbConfig resource object creates a corresponding ALB instance. ALB instances use pay-as-you-go billing.

Production deployment

  • Configure DNS: Create a CNAME record to map your service domain to the ALB instance's public endpoint. This decouples the domain from the instance endpoint, ensuring a highly available and flexible service entry point.

  • Enable HTTPS: Use Certificate Management Service to centrally manage your certificates, and declaratively reference them in the tls field of an Ingress resource to secure service traffic with HTTPS.

Quotas and limits

FAQ

Why does an Ingress return HTTP error codes?

Causes

  • 503 (Service Temporarily Unavailable) error

    • No matching routing rule: The request path does not match any routing rules configured in the Ingress.

    • No healthy backend pods: The associated Service has no ready pods, which results in an empty endpoints object.

  • 502 (Bad Gateway) error

    After an HTTP or HTTPS listener receives a client connection request, the ALB sends an HTTP 502 Bad Gateway status code to the client because it fails to forward the request to a Pod or receive a response from the Pod.

  • 404 (Not Found) error

    This typically occurs when a request matches an Ingress routing rule, but its URL does not match the service path of the application in the backend pod.

  • 400 (Bad Request) error

    This can occur for several reasons, such as sending an HTTP request to an HTTPS listener.

For more information about HTTP error codes, see ALB status codes.

Solution

  1. Check the Ingress status: Run the kubectl describe ingress <ingress-name> -n <namespace> command and inspect the Events section for error messages. If an event like listener is not exist in alb appears, add the required listener configuration to your AlbConfig.

    ...
    Events:
      Type     Reason                  Age     From     Message
      ----     ------                  ----    ----     -------
      Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
      Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
    ...
  2. Check the backend endpoints: Run the kubectl get endpoints <service-name> -n <namespace> command to confirm that the ENDPOINTS field lists at least one healthy pod IP address and port. If it is empty, verify that the selector of the Service matches the labels of the pods, and that the pods are in the Running state.

  3. Check the pod status and logs: Run kubectl get pod -l <app=your-app> -n <namespace> to view the pod status. Then, use the pod name to run kubectl logs <pod-name> -n <namespace> and check the application logs for startup failures or request processing errors.

  4. Test network connectivity: From within a pod or from a node, use curl to access the backend Service's ClusterIP or a pod IP to verify that the service is reachable within the cluster.

Why is HTTPS inaccessible after TLS configuration?

Causes

  • The ALB instance is not listening on port 443: You have configured TLS for the Ingress, but the corresponding HTTPS:443 listener has not been created.

  • Incorrect certificate configuration: The Secret type is not kubernetes.io/tls or IngressTLS, or the content of tls.crt and tls.key in the data field is incorrect or does not match.

  • Stale certificate: The ALB instance may be using an old certificate. This happens if you update a certificate in Alibaba Cloud Certificate Management Service but do not update the certificate ID in your AlbConfig, or if automatic discovery and reconciliation fails to trigger.

Solution

  1. Check the listener port: Run the kubectl describe albconfig <alb-name> -n <namespace> command to verify that the spec.listeners.port: 443 and spec.listeners.protocol: HTTPS configurations are present.

  2. Check the Ingress configuration: Verify that the Ingress configuration includes the alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}] annotation. This annotation associates the Ingress with HTTP and HTTPS listeners.

  3. Check the Secret configuration: In the Ingress configuration, check the secretName field of spec.tls to confirm that the correct Secret is referenced. Run the kubectl get secret <secret-name> -n <namespace> -o yaml command to confirm the Secret type and data integrity.

How to configure Ingress domain resolution?

  1. Register a domain name.

  2. Add a CNAME record.

    For example, add a DNS record with the record type CNAME, the host record @ (which represents the root domain, such as ingress-demo.com), and the record value as the Ingress endpoint address.
  3. In a browser, go to http://ingress-demo.com/coffee to verify that the domain name resolution is working.

    After access is successful, an NGINX test page is returned, displaying information such as the Server address, Server name, Date, and URI (with the value /coffee) of the backend pod. This indicates that the Ingress has correctly routed the request to the backend pod.

    For verification, replace the example with your registered domain name. If the domain name resolution fails, see Quick troubleshooting for domain name resolution failures.

How do I configure HTTPS for an Ingress?

  1. Purchase an official certificate, and apply for a certificate. Make sure that the certificate you want to use is in the Issued state.

  2. Download the SSL certificate.

    This example shows how to download the PEM-formatted certificate file for the ingress-demo.com domain, with the server type set to Other.
  3. Create a Secret to store the certificate file.

    1. On the Clusters page, click the name of your cluster. In the left navigation pane, click Configurations > Secrets.

    2. On the Secrets page, select the default namespace and then click Create on the left. Add the following configurations and click OK.

      • Name: ingress-tls

      • Type: TLS Certificate

      • Certificates: The full content of the downloaded and unzipped certificate file (.pem).

      • Key: The full content of the downloaded and unzipped private key file (.key).

  4. Update the AlbConfig to add an HTTPS:443 listener for the ALB instance.

    1. In the left-side navigation pane, choose Workloads > Custom Resources. On the Resource Objects tab, search for AlbConfig, and then click the search result.

    2. In the list of AlbConfig resource objects, find the target resource alb and click Edit YAML in the Actions column.

    3. Add the spec.listeners.port: 443 and spec.listeners.protocol: HTTPS fields, and then click OK.

      spec:
          config:
            addressAllocatedMode: Fixed
            addressType: Internet
            zoneMappings:
              - vSwitchId: vsw-xxx
              - vSwitchId: vsw-xxx
          listeners:
            - port: 80
              protocol: HTTP
            - port: 443
              protocol: HTTPS
  5. Update the Ingress to add a TLS configuration and associate it with the HTTPS:443 listener.

    1. In the left-side navigation pane, choose Network > Ingresses. In the Actions column of the target Ingress, click Update.

    2. Add the following configurations and click OK.

      • TLS Settings: Enabled

      • Domain Name: ingress-demo.com

      • Secrets: ingress-tls

      • Annotations: alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]

  6. In a browser, go to https://ingress-demo.com/coffee to verify HTTPS access.

    The page displays the NGINX logo and server response information. The Server address, Server name, and URI (with the value /coffee) are returned as expected. This confirms that HTTPS is configured correctly and that the Ingress routes requests to the coffee backend pod.

    For verification, replace the example with your registered domain name.

For more information about how to configure HTTPS certificates, see Configure HTTPS certificates for encrypted communication.

How to manually create AlbConfig and IngressClass?

Create an AlbConfig

  1. Log on to the VPC console and record the IDs of at least two vSwitches that are in different availability zones within the VPC where the cluster is deployed.

    The availability zones of the configured vSwitches must be supported by ALB. For more information, see ALB regions and zones.
  2. Replace zoneMappings.vSwitchId in the following code with the vSwitch IDs that you obtained in the previous step. Save the content to a file named albconfig.yaml and run kubectl apply -f albconfig.yaml to create the AlbConfig.

    For more detailed steps, see Create an AlbConfig.
    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: alb # Do not create another AlbConfig resource with the same name.
    spec:
      config:
        name: alb-test
        addressType: Internet
        zoneMappings:
        - vSwitchId: vsw-****cg2a9g71hx8go**** # Replace with your actual vSwitch ID.
        - vSwitchId: vsw-****un9tql5t8nh15**** # Replace with your actual vSwitch ID.
      listeners:
        - port: 80
          protocol: HTTP

Create an IngressClass

The IngressClass resource associates an AlbConfig with Ingress resources. When you specify ingressClassName: alb in an Ingress, it uses the AlbConfig defined in the alb IngressClass.

Save the following content to a file named IngressClass.yaml, and then run kubectl apply -f IngressClass.yaml to create the IngressClass.

The spec.parameters.name field must be set to the name of the AlbConfig. The default AlbConfig created when you install the component is named alb. For more information, see Use IngressClass to associate an AlbConfig with an Ingress.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb # This must match the name of the AlbConfig resource.

Related documentation

Advanced ALB Ingress Usage

Customizing ALB Ingress Forwarding Rules

Performing a Canary Release with ALB Ingress