Container Service for Kubernetes:Product functions

• What is the Ingress component? Why do I need to configure an SLB instance for the Ingress component?

• How do I change the billing method of the SLB instance that is associated with the Ingress component to subscription?

• What are node pools?

• What deployment strategies does ACK support?

• What are the recommended solutions if I want to use Istio?

• How do I control access among pods?

What is the Ingress component? Why do I need to configure an SLB instance for the Ingress component?

The Ingress component is a network component of Kubernetes. The Ingress component supports Layer 7 load balancing over HTTP, which provides more benefits compared with Layer 4 load balancing over TCP. For example, Ingresses provide custom routing rules and use the following deployment strategies: canary release, blue-green deployment, and A/B testing. In addition, Ingresses support SSL encryption, visualized log analysis and monitoring, and custom configurations. Ingresses are commonly used in Kubernetes to expose HTTP and HTTPS Services.

If you want to allow external access to Services when you create a cluster, we recommend that you install the Ingress component. ACK uses the NGINX Ingress controller and Server Load Balancer (SLB) instances to expose Services. You can update the Ingress component in the ACK console. ACK is integrated with Log Service. This allows you to monitor the Ingress component and analyze the log of the Ingress component in a visualized manner.

For more information about how to monitor the Ingress component and analyze the access log of the Ingress component, see Analyze and monitor the access log of nginx-ingress.

How do I change the billing method of the SLB instance that is associated with the Ingress component to subscription?

The Ingress component is used to expose Services. You can modify the Service YAML file to change the billing method of the SLB instance. You cannot change the billing method of the SLB instance that is automatically created by the Service from pay-as-you-go to subscription. Otherwise, the Service cannot run as normal. To change the billing method of the SLB instance to subscription, perform the following steps:

Step 1: Create a subscription SLB instance

For more information, see Create and manage a CLB instance.

Step 2: Associate the Service with the subscription SLB instance

1. Log on to the ACK console.

2. In the left-side navigation pane of the ACK console, click Clusters.

3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.

4. In the left-side navigation pane of the details page, choose Network > Services

5. On the Services page, select kube-system from the Namespace drop-down list.

6. In the Name column of the Services page, find the Service named nginx-ingress-lb.

7. Click View in YAML in the Actions column of the nginx-ingress-lb Service.

8. In the Edit YAML dialog box, modify the YAML file.

   The following YAML template is provided as an example:

   apiVersion:v1
   kind: Service
   metadata:
     name: nginx-ingress-lb
     namespace: kube-system
     labels:
       app: nginx-ingress-lb
     annotations:
       service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "<$YOUR_LOADBALANCER_ID>"      #Specify the ID of the new SLB instance for the Service. 
       service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"  #Enable the cloud controller manager (CCM) to create listeners for the node. 
   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
     ports:
       - port: 80
         name: http
         targetPort: 80
       - port: 443
         name: https
         targetPort: 443
     selector:
       app: ingress-nginx

   For more information, see Use annotations to configure load balancing.

Step 3: Delete the original SLB instance

1. Check whether network traffic is switched to the new SLB instance. For more information about how to monitor network traffic, see View monitoring information about CLB.

2. If network traffic is switched to the new SLB instance, delete the original SLB instance. For more information about how to delete an SLB instance, see Create and manage a CLB instance.

What are node pools?

Labels are typically used to classify and manage nodes. However, as the numbers of nodes and labels increase, it becomes more complex to manage and maintain nodes. Node pools allow you to classify nodes from a different dimension. You can centrally manage nodes, schedule pods to specified nodes, and configure auto scaling for nodes by using node pools.

ACK provides regular node pools and managed node pools. For more information, see Node pool overview.

What deployment strategies does ACK support?

ACK supports four types of deployment strategies:

• You can use Ingresses provided by ACK to perform canary releases and blue-green deployments. For more information, see Use the NGINX Ingress controller to implement canary releases and blue-green deployments.

• You can implement Layer 4 canary releases by using SLB instances. SLB instances are weak in traffic forwarding control and the cost of SLB instances is higher. You can distribute traffic to different application versions only by changing the number of pods. For more information, see Implement Layer 4 canary releases by using SLB instances.

• Use Istio to implement blue-green deployments and canary releases based on Alibaba Cloud Service Mesh (ASM). Istio allows you to control traffic in a fine-grained manner and supports load balancing at multiple layers. However, Istio requires you to have technology expertise. If you use this deployment strategy, you must familiarize yourself with the basic models of Istio in addition to Kubernetes. For more information, see Use ASM to deploy an application in blue-green release mode and phased release mode.

• Canary releases help you update Deployments in a progressive manner. You can use canary releases with the Ingress controller to deploy multiple application versions, implement phased releases, distribute network traffic to different application versions based on the specified proportion, and perform health checks. This enables automated switchover of traffic to your applications.

What are the recommended solutions if I want to use Istio?

If you want to use Istio, we recommend that you activate ASM. You do not need to install and deploy Istio. ASM provides traffic control, mesh observation, and secure communication among services, which simplify service governance. In addition, ASM allows you to centrally manage services that run on heterogeneous computing infrastructure. You can add ACK clusters, ACK Serverless clusters, Elastic Compute Service (ECS) instances, and self-managed clusters to ASM instances.

For more information about ASM, see What is ASM?.

How do I control access among pods?

The Kubernetes networking model requires that all pods can communicate with each other. However, some pods in a Kubernetes cluster may not be able to directly access each other. For example, the pods that belong to two departments are isolated and do not have access permissions by default. In this case, you can use network policies to control access. You can use network policies to control the communication between pods. You can use label selectors to control the inbound and outbound traffic of specific pods. You can also control traffic based on CIDR blocks, ports, and protocols. For more information about how to use network policies, see Use network policies.