This topic provides answers to some frequently asked questions about the features provided by Container Service for Kubernetes (ACK).
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 Simple 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 analyze and monitor the access log of the Ingress component, see Analyze and monitor the access log of nginx-ingress-controller.
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:
Kubernetes components belong to the kube-system namespace. Do not delete the namespace.
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
When you modify or change an SLB instance, make sure that no traffic is forwarded to the cluster. Do not delete the original SLB instance before the listener of the new SLB instance takes effect. For more information, see Considerations for configuring a LoadBalancer Service.
For more information, see Use an existing CLB instance and forcefully overwrite the listeners of the CLB instance.
Step 3: Delete the original SLB instance
We recommend that you delete the original SLB instance after the network traffic is switched to the new SLB instance.
Check whether network traffic is switched to the new SLB instance. For more information about how to monitor network traffic, see View monitoring data of CLB.
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?
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 releases.
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. For more information, see Use Kruise Rollout to perform canary releases and A/B testing.
OpenKruise is a set of standard extensions for Kubernetes. It can be used with open source Kubernetes to efficiently manage application pods, sidecar containers, and image distribution. For more information, see Use OpenKruise to deploy cloud-native applications.
What are the recommended solutions if I want to use Istio?
If you want to use Istio, we recommend that you activate Service Mesh. You do not need to install or deploy Istio. Service Mesh 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 top of 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 in ACK clusters.