For each LoadBalancer service (a service with field type: LoadBalancer), the Cloud Controller Manager (CCM) add-on of VKE creates or reuses a CLB/NLB instance for the service. This topic describes the key considerations in configuring a LoadBalancer Service.
Creating or reusing an LB instance
You can either create a new CLB/NLB instance or reuse an existing one when configuring a service through the console or YAML settings. The following table shows the differences between creating and reusing CLB/NLB instances.
CCM tuning mechanism
For each LoadBalancer service, i.e., the service with field type: LoadBalancer, Cloud Controller Manager (CCM) add-on of VKE will create a new CLB/NLB or reuse the resources of an existing one, including the instance, listener, and backend server group.
Additionally, the CCM add-on starts tuning in the following scenarios:
- Changes occur in the backend when you create, delete, and modify the Service. For example, pod IP addresses change, or pods are created or deleted.
- The configuration fields of the Service change, including Annotation, spec, and status.
- The controller pod is restarted.
Configuration considerations
- We recommend specifying the parameters of the CLB/NLB instance either in the VKE console or through YAML. If you modify resources or configurations managed by the Service (such as forwarding rules) in the CLB/NLB console, your changes may be overwritten by the controller.
- If you manually modify the configurations of the CLB/NLB instance in the CLB/NLB console, the controller cannot detect the changes. Therefore, the controller cannot write the updated configurations in the CLB/NLB console into the Annotation field of the Service. When the Service triggers tuning, the updated configurations in the CLB/NLB console may be refreshed by the controller based on the configurations in the Annotation field.
- Part of the configurations for the CLB/NLB instance can be specified both through the Annotation field of the Service and the CLB/NLB console. Therefore, to avoid mutual overwriting of configurations that will cause business failures, you need to configure the CLB/NLB instance in VKE by the following logic:
- When you configure the CLB/NLB instance for the first time, if related configurations (such as the access control of the listener) exist in the Annotation field of the Service, keep the CLB/NLB instance configurations the same as those in the Annotation field.
- After you manually modify the configurations of the CLB/NLB instance in the CLB/NLB console, the configurations of the CLB/NLB instance remain consistent with those manual changes until the next tuning of the Service. When the Service is tuned again, the system will refresh the configurations based on the updated configurations in the spec and Annotation fields of the Service:
- If the spec and Annotation fields of the Service do not change during the next tuning, the configurations of the CLB/NLB instance will not be refreshed. In this case, the actual configurations of the CLB/NLB instance remain consistent with the updated configurations in the CLB/NLB console.
- If the spec field or the Annotation field of the Service changes during the next tuning, the configurations of the CLB/NLB instance will be refreshed based on the Annotation field. In this case, the updated configurations in the CLB/NLB console will be overwritten.
Warning
After you modify the spec field or the Annotation field of the Service, Service tuning may cause the manually updated configurations of the CLB/NLB instance in the CLB/NLB console to be overwritten. To prevent the preceding issues, when you modify the configurations of the CLB/NLB instance through the Annotation field of the Service, make sure that all configurations are consistent with those in the CLB/NLB console.
Other considerations
- Do not change the CLB instance, listener, backend server group, or forwarding rule created or managed by the Service in the CLB/NLB console without authorization. Otherwise, exceptions may occur in the LoadBalancer Service within the cluster.
- Do not modify any content prefixed with k8s_ in the name of a listener or backend server group.
- Do not modify any content prefixed with k8s_ in the description of a forwarding rule.