By integrating the Ingress service, the Container Service console allows you to create Ingresses to manage external access to the services in your cluster flexibly.

Prerequisites

  • A Container Service for Kubernetes cluster is created, and the Ingress controller is running properly in the cluster. For more information, see Create an ACK cluster.
  • An SSH connection to the master node is set up. For more information, see Use SSH to connect to a cluster.

Step 1: Create deployments and services

  1. Log on to the Container Service console.
  2. In the left-side navigation pane under Container Service - Kubernetes, choose Applications > Deployments.
  3. On the Deployments page that appears, click Create from Template in the upper-right corner.
  4. Select the cluster and namespace, select a sample template or Custom from the Sample Template drop-down list, and click Create.
    In this example, three NGINX applications are created, including old-nginx, new-nginx, and domain-nginx. The domain-nginx application is used for testing the access domain name of the cluster.
    The orchestration template for old-nginx is as follows:
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: old-nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          run: old-nginx
      template:
        metadata:
          labels:
            run: old-nginx
        spec:
          containers:
          - image: registry.cn-hangzhou.aliyuncs.com/xianlu/old-nginx
            imagePullPolicy: Always
            name: old-nginx
            ports:
            - containerPort: 80
              protocol: TCP
          restartPolicy: Always
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: old-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: old-nginx
      sessionAffinity: None
      type: NodePort
    The orchestration template for new-nginx is as follows:
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: new-nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          run: new-nginx
      template:
        metadata:
          labels:
            run: new-nginx
        spec:
          containers:
          - image: registry.cn-hangzhou.aliyuncs.com/xianlu/new-nginx
            imagePullPolicy: Always
            name: new-nginx
            ports:
            - containerPort: 80
              protocol: TCP
          restartPolicy: Always
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: new-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: new-nginx
      sessionAffinity: None
      type: NodePort
    The orchestration template for domain-nginx is as follows:
    apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1
    kind: Deployment
    metadata:
      name: domain-nginx
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9 # replace it with your exactly <image_name:tags>
            ports:
            - containerPort: 80
    
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: domain-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: nginx
      sessionAffinity: None
      type: NodePort
  5. In the left-side navigation pane under Container Service - Kubernetes, choose Ingresses and Load Balancing > Services. The Services page appears.
    After the services are created, you can find them on the Services page.

Step 2: Create an Ingress

  1. Log on to the Container Service console.
  2. In the left-side navigation pane under Container Service - Kubernetes, choose Ingresses and Load Balancing > Ingresses. The Ingresses page appears.
  3. Select the cluster and namespace, and click Create in the upper-right corner.
  4. In the dialog box that appears, enter the Ingress name. In this example, the name is nginx-ingress.
  5. Configure Ingress rules.

    Ingress rules are the rules that authorize inbound access to the cluster and are generally HTTP or HTTPS rules. The configurations of an Ingress rule include the domain name (or virtual hostname), path, service name, port, and weight. For more information, see Ingress configurations.

    In this example, two Ingress rules are configured for the default domain name and virtual hostname of the cluster respectively to demonstrate the Ingress service based on domain names.
    • Simple Ingress rule based on the default domain name: uses the default domain name of the cluster to provide external access.
      • Domain: Enter the default domain name of the cluster. In this example, the default domain name is test.[cluster-id].[region-id].alicontainer.com.

        The default domain name of the cluster is displayed, in the format of *.[cluster-id].[region-id].alicontainer.com. You can also obtain the default domain name from the basic information page of the cluster.

      • Services: Configure the path, name, port, and weight of the domain-nginx service.
        • Path: Enter the URL for accessing the service. The default path is the root path /. In this example, the default path is used. Each path is associated with a backend service. Server Load Balancer (SLB) forwards traffic to a backend service only when inbound requests match the domain name and path.
        • Service configuration: Configure the name, port, and weight of the service. You can configure multiple services in the same path. The Ingress traffic is split and forwarded to the matched services.
    • Simple fanout Ingress rule based on the test domain name: uses a virtual hostname as the test domain name of the cluster to provide external access. Configure weights for the old-nginx and new-nginx services and configure canary release for the new-nginx service. In your production environment, you can use a domain name for which an Internet Content Provider (ICP) filing has been obtained to provide external access.
      • Domain: Enter the test domain name foo.bar.com.

        You must modify the hosts file to add a domain name mapping rule.

        118.178.108.143 foo.bar.com       # The IP address is that of the Ingress.
      • Services: Configure the path, names, ports, and weights of the old-nginx and new-nginx services.
        • Path: Enter the URL for accessing the services. The default path is the root path /. In this example, the default path is used.
        • Name: Enter new-nginx and old-nginx respectively.
        • Port: Enter port 80.
        • Weight: Set the weights of the services under the specified path. The weight is a percentage value. The default value is 100. In this example, the old-nginx and new-nginx services have the same weight, that is, 50%.
  6. Configure canary release.
    Note Currently, only Ingress controllers of 0.12.0-5 and later versions support traffic splitting.
    Container Service supports multiple traffic splitting approaches to suit scenarios such as canary release and A/B testing, including:
    1. Traffic splitting based on request header
    2. Traffic splitting based on cookie
    3. Traffic splitting based on query parameter

    After canary release is configured, only requests that match the specified rules are routed to the new-nginx service. If the weight of new-nginx is lower than 100%, requests that match the specified rules are routed to this service based on the weight.

    This example sets the rule on the request header to foo=^bar$. Only requests that contain this header can access new-nginx.

    • Service: the service to be accessed.
    • Type: the type of the matching rule, such as Header, Cookie, or Query.
    • Name and Match Value: the custom request fields. The name and matching value comprise a key-value pair.
    • Matching Rule: supports regular expressions and exact matches.
  7. Configure annotations.
    Click Rewrite Annotation to add a typical rewrite annotation for the Ingress. nginx.ingress.kubernetes.io/rewrite-target: / indicates that /path is redirected to the root path /, which can be recognized by the backend service.
    Note In this example, no access path is configured for the service. Therefore, you do not need to configure rewrite annotations. Rewrite annotations enable the Ingress to forward paths as the root path to the backend service. This helps avoid 404 errors that are caused by incorrect paths.
    You can also click Add to add Ingress annotations, in key-value pairs. For more information, see Annotations.
  8. Configure TLS. Select Enable and configure the secure Ingress service. For more information, see Configure a safe routing service.
    • You can select Existing Secret.
      1. Log on to the master node and create the tls.key and tls.crt files.
        openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com/O=foo.bar.com"
      2. Create a Secret.
        kubectl create secret tls foo.bar --key tls.key --cert tls.crt
      3. Run the kubectl get secret command and check whether the Secret is created. Then, you can select the foo.bar Secret on the web UI.
    • You can use the TLS private key and certificate to create a Secret.
      1. Log on to the master node and create the tls.key and tls.crt files.
        openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com/O=foo.bar.com"
      2. Run the vim tls.key and vim tls.crt commands to obtain the private key and certificate that are generated.
      3. Copy the certificate and private key to the Cert and Key fields separately.
  9. Add labels.
    Add the labels to describe the characteristics of the Ingress.
  10. Click Create.
    The nginx-ingress Ingress appears on the Ingresses page.
  11. Click test.[cluster-id].[region-id].alicontainer.com and foo.bar.com in the Ingress to access the services. When you click the default domain name, the NGINX welcome page is displayed.
    When you click the domain name that points to the new-nginx service, the page for the old-nginx service page appears.
    Note By default, when you access the domain name in a browser, the request header does not contain foo=^bar$. As a result, the request is forwarded to the old-nginx service.
  12. Log on to the master node by using SSH. Run the following commands to simulate requests with specific headers and check the results:
    curl -H "Host: foo.bar.com" http://47.107.20.35
    old
     curl -H "Host: foo.bar.com" http://47.107.20.35
    old
     curl -H "Host: foo.bar.com" http://47.107.20.35                     # Similar to access requests in the browser.
    old
     curl -H "Host: foo.bar.com" -H "foo: bar" http://47.107.20.35           # Simulate a request with a specific header. The results are returned based on the weight.
    new
     curl -H "Host: foo.bar.com" -H "foo: bar" http://47.107.20.35
    old
     curl -H "Host: foo.bar.com" -H "foo: bar" http://47.107.20.35
    old
     curl -H "Host: foo.bar.com" -H "foo: bar" http://47.107.20.35
    new