tencent cloud

Feedback

Load Balancer FAQs

Last updated: 2022-07-13 15:51:36

    This document describes the FAQs of CLB, as well as the causes and solutions of various FAQs of Service/Ingress CLB.

    Prerequisites:

    • You are familiar with K8s Concepts, such as Pod, workload, Service, Ingress, etc.
    • You are familiar with the general operations of Elastic Cluster in the TKE console.
    • You can use kubectl command line tool to manage the resources in K8s clusters.

    You can manage the K8s cluster resources in various ways. This document describes how to manage K8s cluster resources in Tencent Cloud console and through the kubectl command line tool.

    Which Ingress can EKS create CLB instance for?

    EKS will create CLB instances for Ingress that meets the following conditions:

    Requirements for Ingress resources Notes
    Annotations contain the following key-value pairs: kubernetes.io/ingress.class: qcloud If you don’t want EKS to create a CLB instance for Ingress (if, for example, you want to use Nginx-Ingress), you only need to make sure the key-value pairs are not contained in the annotations.

    How do I view the CLB instance created by EKS for Ingress?

    If EKS has successfully created a CLB instance for Ingress, it will write the VIP of the CLB instance to the status.loadBalancer.ingress of the Ingress resource, and write the following key-value pairs to annotations.

    kubernetes.io/ingress.qcloud-loadbalance-id: CLB instance ID
    

    To view the CLB instance created by EKS for Ingress:

    1. Log in to the TKE console and select Elastic Cluster in the left sidebar.
    2. On the "Elastic cluster" page, click the ID of the target cluster to go to the cluster management page.
    3. On the cluster management page, select Service and route > Ingress in the left sidebar.
    4. You can find the CLB instance ID and its VIP on the Ingress page.

    Which Service can EKS create CLB instance for?

    EKS will create CLB instances for Service that meets the following conditions:

    K8s Version Requirements for Service Resources
    All K8s versions supported by EKS spec.type is LoadBalancer.
    The modified version of K8s (Server GitVersion returned by kubectl version has the "eks.*" or "tke.*" suffix) spec.type is ClusterIP, and the value of `spec.clusterIP` is notNone, indicating a non-Headless ClusterIP Service.
    The non-modified version of K8s (Server GitVersion returned by kubectl version does not have the "eks.*" or "tke.*" suffix) spec.type is ClusterIP, and spec.clusterIP is specified as an empty string ("").

    If the CLB instance is successfully created, EKS will write the following key-value pairs to Service annotations:

    service.kubernetes.io/loadbalance-id: CLB instance ID
    

    How do I view the CLB instance created by EKS for the Service?

    If EKS has successfully created a CLB instance for Service, it will write the VIP of the CLB instance to the status.loadBalancer.ingress of the Service resource, and write the following key-value pairs to annotations.

    kubernetes.io/ingress.qcloud-loadbalance-id: CLB instance ID
    

    To view the CLB instance created by EKS for Service:

    1. Log in to the TKE console and select Elastic Cluster in the left sidebar.
    2. On the "Elastic cluster" page, click the ID of the target cluster to go to the cluster management page.
    3. On the cluster management page, select Service and route > Service in the left sidebar.
    4. You can find the CLB instance ID and its VIP on the Service page.

    Why is the ClusterIP of Service invalid (cannot be accessed normally) or why is there no ClusterIP?

    For the Service whose spec.type is LoadBalancer, currently EKS does not allocate ClusterIP by default, or the allocated ClusterIP is invalid (cannot be accessed normally). If users need to use ClusterIP to access the Service, they can add the following key-value pairs in annotations to indicate that EKS implements ClusterIP based on the private network CLB.

    service.kubernetes.io/qcloud-clusterip-loadbalancer-subnetid: Service CIDR block subnet ID
    

    The Service CIDR block subnet ID, which is specified when you create the cluster, is a string in subnet-******** format. You can view the subnet ID on the CLB basic information page.

    Only EKS clusters that use the modified version of K8s (Server GitVersion returned by kubectl version has the "eks." or "tke." suffix) supports this feature. For the EKS clusters created earlier that use the non-modified version of K8s (the Server GitVersion returned by kubectl version does not have the "eks." or "tke." suffix), you need to upgrade the K8s version to use this feature.

    How do I specify the CLB instance type (public or private network)?

    You can specify the CLB instance type via TKE console or Kubectl command line tool.

    • For Ingress, select Public network or Private network for Network type to specify the CLB instance type.

    • For Service, set the Service access to specify the CLB instance type. Via VPC means the private network CLB instance.

    How do I specify the existing CLB instance?

    You can specify the existing CLB instance via TKE console or Kubectl command line tool.

    When creating a Service or Ingress, you can select Use existing to use the existing CLB instance. For Service, you can switch to “Use existing” to use the existing CLB instance through “Update access method” after Service is created.

    How do I view the access log of a CLB instance?

    Only the layer-7 CLB instance supports configuring access logs, but the access logs of layer-7 CLB instance created by EKS for Ingress is not enabled by default. You can enable the access log of the CLB instance in the details page of the CLB instance, as shown below:

    1. Log in to the TKE console and select Elastic Cluster in the left sidebar.
    2. On the "Elastic cluster" page, click the ID of the target cluster to go to the cluster management page.
    3. On the cluster management page, select Service and route > Ingress in the left sidebar.
    4. On the Ingress page, click the CLB instance ID to go to the CLB basic information page.
    5. In the Access log (layer-7) section of CLB basic information page, click to enable CLB access log.

    Why didn't EKS create a CLB instance for Ingress or Service?

    Please refer to Which Ingress can EKS create CLB instance for? and Which Service can EKS create CLB instance for? to confirm whether the corresponding resources have the conditions to create CLB instance. If the conditions are met but the CLB instance is not successfully created, you can use the kubectl describe command to view the related events of the resource.
    Generally, EKS will output the related “Warning” events. In the following example, the output event indicates that there are no available IP resources in the subnet, so the CLB instance cannot be successfully created.

    How do I use the same CLB in multiple Services?

    For EKS clusters, multiple Services cannot share the same CLB instance by default. If you hope that a Service uses the CLB occupied by other Services, please add this annotation and specify the value as "true": service.kubernetes.io/qcloud-share-existed-lb: true. For more information on this annotation, see Annotation.

    Why do I fail to access CLB VIP?

    Please follow the steps below to analyze:

    Viewing the CLB instance type

    1. On the Ingress page, click the CLB instance ID to go to the CLB basic information page.
    2. You can view the Instance type of the above CLB instance on the CLB basic information page.

    Confirming whether the environment for accessing CLB VIP is normal

    • If the Instance type of the CLB instance is the private network, its VIP can only be accessed in the VPC to which it belongs.
      Since the IP of the Pods in the EKS cluster is the ENI IP in the VPC, you can access the VIP of the CLB instance of any Service or Ingress in the cluster in the Pods.
    Note:

    LoadBalancer system always has loopback problems (for example, Troubleshoot Azure Load Balancer). Please do not access the services provided by the workload through the VIP opened by itself (via Service or Ingress) in the Pods to which this workload belongs. That is, Pods should not access the services provided by themselves through VIP (including "private network" and "public network"). Otherwise, the access delay may increase, or the access will be blocked when there is only one RS/Pod under the rules corresponding to the VIP.

    • If the Instance type of the CLB instance is the public network, its VIP can be accessed in an environment with public network access enabled.
      If you want to access the public network VIP in the cluster, please ensure that the public network access has been enabled for the cluster by configuring a NAT gateway or other methods.

    Viewing the RS in CLB including (and only including) the IP and port of the expected Pods

    On the CLB management page, select the Listener management tab to view the forwarding rules (layer-7 protocol) and the bound backend services (layer-4 protocol). The IP address is expected to be the IP of each Pod. The example is as follows:

    Confirming whether the corresponding Endpoints are normal

    If you have correctly set the labels for the workload and the Selectors for the Service resource, after the Pods of the workload run successfully, you can find that Pods are added by K8s to the ready IP list of the Endpoints corresponding to the Service by running the kubectl get endpoints command. The example is as follows:

    Pods that are created but in an abnormal state are added by K8s to the unready IP list of the Endpoints corresponding to the Service. The example is as follows:

    You can run the kubectl describe command to view the cause of the abnormal Pods. The command is as follows:

    kubectl describe pod nginx-7c7c647ff7-4b8n5 -n demo
    

    Confirming whether Pods can provide services normally

    Even Pods in the Running state may not be able to provide services normally due to some exceptions. For example, the specified protocol + port are not listened to, the internal logic of Pods is incorrect, the process is blocked, etc. You can run the kubectl exec command to log in to the Pod, and run the telnet/wget/curl command or use a custom client tool to directly access the Pod IP+ port. If the direct access fails in the Pod, you need to further analyze the reasons why the Pod cannot provide services normally.

    Confirming whether the security group bound to the Pod allows the protocol and port of the service provided by the Pod

    The security group controls the network access policy of Pods, just like the IPTables rules in the Linux server. Please check based on the actual situation:

    The interactive process requires to specify a security group, and EKS will use this security group to control the Pods' network access policy. The specified security group will be stored in the spec.template.metadata.annotations of the workload, and finally added to the annotations of the Pods. Examples are as follows:

    Contact us

    If the problem persists, please submit a ticket to contact us.

    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support