Help Center/ Cloud Container Engine/ User Guide/ Networking/ Services/ LoadBalancer/ Network and Backend Configuration/ Disabling Listener Hosting for LoadBalancer Services
Updated on 2026-08-26 GMT+08:00
View PDF
Share

Disabling Listener Hosting for LoadBalancer Services

By default, CCE automatically creates and fully manages listeners for LoadBalancer Services, including creation, updates, and deletion. This satisfies most use cases. For scenarios requiring more flexibility, you can disable listener hosting. Once disabled, CCE no longer manages the associated listener, allowing you to independently configure timeout intervals, TLS certificates, ACLs, and other settings directly on the ELB. This supports advanced use cases such as multiple Services sharing a single listener.

Introduction

Use Case

Description

Supported Cluster Version

Disable during Service creation

When creating a Service, you can disable listener hosting. CCE creates only the backend server group, health check, and backend server members, but no listener.

v1.29.15-r90, v1.30.14-r90, v1.31.14-r50, v1.32.13-r20, v1.33.12-r0, v1.34.8-r0, v1.35.5-r0, v1.36.1-r10, or later

Disable for existing Service

Disable listener hosting on an existing Service. The listener is no longer managed by CCE and will not be updated or deleted by CCE.

Retain listener on Service deletion

When you delete a Service with listener hosting disabled, only the backend server group is removed, and the listener is preserved.

Share listener across Services

Multiple Services with listener hosting disabled can share the same listener while managing their own backend server groups independently.

Precautions

  • Disabling listener hosting is irreversible. To restore it, delete and recreate the Service.
  • After disabling listener hosting, you must create a listener on the ELB console and associate it with the backend server group. Otherwise, traffic will not be forwarded.
  • For application load balancers (HTTP/HTTPS), you must configure a forwarding policy on the ELB console.
  • When you delete a Service with listener hosting disabled, only the backend server group (including its health check and backend servers) is removed. The listener remains on the ELB and must be deleted manually.
  • Use a listener created on the ELB console rather than one created by another Service or ingress. If a Service with a CCE-managed listener shares a listener with a Service that has listener hosting disabled, deleting the Service with the CCE-managed listener will cascade-delete the listener, interrupting traffic to the other Service. Pay attention to dependencies between Services.
  • Disabling listener hosting is incompatible with the cross-cluster backend feature (kubernetes.io/elb.multicluster).
  • When a dedicated load balancer is used, CCE automatically adds the kubernetes.io/elb.listener-port and kubernetes.io/elb.listener-port-ranges-auto-generated annotations after a Service with listener hosting disabled is created. These annotations are for internal status management. Do not manually specify, modify, or delete them. Doing so will cause load balancer resource reclamation to fail.

Prerequisites

Creating a LoadBalancer Service with Listener Hosting Disabled

You can create the Service using either the CCE console or kubectl.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Services and Ingresses. In the upper right corner, click Create Service.

    In this example, only the mandatory parameters required to disable listener hosting are listed. Retain default values for all other parameters. For details, see Using the CCE Console.

  3. Configure basic parameters.

    Parameter

    Description

    Example

    Service Type

    Select LoadBalancer.

    None

    Service Name

    Enter a name, which can be the same as the workload name.

    nginx

    Namespace

    Select the namespace that the workload belongs to.

    default

    Selector

    Add the key and value of a pod label. The Service will be associated with the workload pods based on the label and direct traffic to the pods with this label.

    You can also click Reference Workload Label to use the label of an existing workload. In the dialog box displayed, select a workload and click OK.

    app:nginx

  4. Configure load balancer parameters.

    Parameter

    Description

    Example

    Load Balancer

    To cancel listener hosting, you can only select existing load balancers. Automatically created load balancers are not supported.

    Only load balancers in the same VPC as the cluster can be selected. If no load balancer is available, click Create Load Balancer to create one on the ELB console.

    An existing Dedicated load balancer of the Network (TCP/UDP/TLS) & Application (HTTP/HTTPS) type

    Listener Hosting

    If this option is selected, CCE manages the listener (default behavior). CCE automatically creates, updates, and deletes the listener. If you disable listener hosting when creating a Service, CCE creates only the backend server group, health check, and backend server members, but does not create or manage any listener.

    You must manually configure a listener on the ELB console and associate it with the backend server group generated by this Service. Once disabled, you cannot re-enable listener hosting for this Service.

    Deselect

  5. Configure access parameters.

    Parameter

    Description

    Example

    Service Affinity
    Whether to route external traffic to a local node or a cluster-wide endpoint. For details, see Service Affinity (externalTrafficPolicy).
    • Cluster-level: The IP addresses and ports of all nodes in a cluster can access the workload associated with the Service. However, accessing the Service may result in decreased performance due to route redirection, and the client's source IP address may not be obtainable.
    • Node-level: Only the IP address and port of the node where the workload is located can access the workload associated with the Service. Accessing the Service will not result in a performance decrease due to route redirection, and the client's source IP address can be obtained.

    Cluster-level

    Port
    • Protocol: the protocol used by the Service. According to the Kubernetes implementation, if a Service uses a load balancer with a non-UDP protocol, this parameter must be set to TCP and the corresponding listener frontend protocol must be selected. For details, see Protocols for Services.
    • Container Port: the port that the workload listens on. For example, Nginx uses port 80 by default.
    • Service Port: the port used by the Service.
      • Listen on a port: The port ranges from 1 to 65535.
      • Listen on ports: ELB allows you to create listeners that listen on ports within specified ranges. Each listener can support up to 10 non-overlapping port ranges.

        To configure port ranges for load balancer listeners, ensure the following conditions are met:

        • The cluster version must be v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0, v1.30.1-r0, or later.
        • A dedicated load balancer must be used with TCP/UDP/TLS selected.
        • This function requires ELB. Before using this function, check whether ELB supports full-port listening and forwarding for layer-4 protocols in the current region.
    • Frontend Protocol: Set the protocol of the load balancer listener for establishing connections with clients. When a dedicated load balancer is selected, HTTP/HTTPS can be configured only when Application (HTTP/HTTPS) is selected and TLS can be configured only when Network (TCP/UDP/TLS) is selected.
    NOTE:

    When a LoadBalancer Service is created, a random node port number (NodePort) is automatically generated.
    • Protocol: TCP
    • Container Port: 80
    • Service Port: 80
    • Frontend Protocol: HTTP

  6. Click Create.
  7. After the Service is created, manually create a listener on the ELB console and associate it with the backend server group. Otherwise, traffic cannot be forwarded. For details, see Configuring a Listener on ELB and Associating It with the Backend Server Group.
  • Disable during Service creation
    This section uses an existing load balancer as an example. An example YAML file with listener hosting disabled during Service creation is as follows: 
    apiVersion: v1
kind: Service
metadata:
  name: nginx-skip-listener
  labels:
    app: nginx
  namespace: default
  annotations:
    kubernetes.io/elb.class: performance          # Load balancer type
    kubernetes.io/elb.id: 35cb350b-23e6-4551-ac77-10d5298f5204   # ID of an existing load balancer
    kubernetes.io/elb.skip-managed-listener: 'true'  # Disable listener hosting.
    kubernetes.io/elb.protocol-port: http:80  # HTTP is used.
spec:
  selector:
    app: nginx
  externalTrafficPolicy: Cluster
  ports:
    - name: cce-service-0
      targetPort: 80
      nodePort: 0
      port: 80
      protocol: TCP
  type: LoadBalancer
  loadBalancerIP: **.**.**.**   # IP address of the load balancer
    Table 1 Key parameters

    Parameter

    Type

    Description

    kubernetes.io/elb.skip-managed-listener

    String

    Disables listener hosting. Once disabled, CCE no longer manages the listener associated with this Service.

    • true: disables listener hosting when creating a Service. CCE creates only the backend server group, health check, and backend server members, but does not create or manage any listener.
    • Not set or set to another value: retains the default behavior. CCE fully manages the listener.

    After the Service is created, you must manually create a listener on the ELB console and associate it with the backend server group. Otherwise, traffic cannot be forwarded. For details, see Configuring a Listener on ELB and Associating It with the Backend Server Group.

  • Example of sharing a listener across Services

    In network load balancing (TCP/UDP/TLS) scenarios, a listener can be associated with only one backend server group. Sharing a listener across multiple Services is applicable mainly to application load balancing (HTTP/HTTPS) scenarios.

    The following example shows how to configure two Services to share the same ELB listener:

    • Service A: 
      apiVersion: v1
kind: Service
metadata:
  name: service-a
  namespace: default
  annotations:
    kubernetes.io/elb.class: performance
    kubernetes.io/elb.id: 35cb350b-23e6-4551-ac77-10d5298f5204   # The same load balancer
    kubernetes.io/elb.skip-managed-listener: 'true'  # Disable listener hosting.
    kubernetes.io/elb.protocol-port: http:80  # HTTP is used.
spec:
  selector:
    app: app-a
  ports:
    - name: cce-service-0
      targetPort: 8080
      port: 80
      protocol: TCP
  type: LoadBalancer
    • Service B: 
      apiVersion: v1
kind: Service
metadata:
  name: service-b
  namespace: default
  annotations:
    kubernetes.io/elb.class: performance
    kubernetes.io/elb.id: 35cb350b-23e6-4551-ac77-10d5298f5204   # The same load balancer
    kubernetes.io/elb.skip-managed-listener: 'true'  # Disable listener hosting.
    kubernetes.io/elb.protocol-port: http:80  # HTTP is used.
spec:
  selector:
    app: app-b
  ports:
    - name: cce-service-0
      targetPort: 8081
      port: 80
      protocol: TCP
  type: LoadBalancer

    After creation, you must create a listener on the ELB console, associate the backend server groups of Service A and Service B with the listener through forwarding policies, and configure domain name/URL forwarding rules to distribute traffic. For details, see Configuring a Listener on ELB and Associating It with the Backend Server Group.

Configuring a Listener on ELB and Associating It with the Backend Server Group

After disabling listener hosting, you must create a listener on the ELB console and associate it with the backend server group. Otherwise, traffic will not be forwarded.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Services and Ingresses. Locate the row containing the target Service and click the load balancer name to go to the ELB console.
  3. In the navigation pane, choose Backend Server Groups. In the search box, enter the Service name to locate the corresponding backend server group.

    The name of a backend server group consists of the Service name, listener protocol, and port. If multiple backend server groups share the same name, check the description for the cluster ID and Service ID to differentiate them.

  4. In the navigation pane, choose Load Balancers. The load balancer details page is displayed.
  5. Switch to the Listeners tab, click Add Listener, and create a listener for the corresponding port.
  6. In the listener configuration, associate it with the backend server group you located.

    • Application load balancing: You must also configure forwarding policies by domain name or URL to associate different backend server groups with the same listener.
    • Network load balancing: A listener can be associated with only one backend server group.

  7. After configuration, verify that traffic is forwarded properly.
Parent Topic: Network and Backend Configuration