You need to enable JavaScript to run this app.
Volcengine Kubernetes Engine

Volcengine Kubernetes Engine

Copy page
Download PDF
CLB Ingress
Creating CLB Ingresses through the console
Copy page
Download PDF
Creating CLB Ingresses through the console
A CLB Ingress combines a load balancer and Ingress controller to enable more powerful Ingress traffic management. This topic describes how to configure a CLB Ingress.​
warning​
Before you begin, thoroughly read CLB Ingress considerations.​
Prerequisites​
  • The target cluster has been connected through kubectl. For details, see Connecting clusters.​
Procedure​
  1. Log in to the VKE console .​
  1. In the left navigation bar, click Cluster.​
  1. In the cluster list, click the name of the cluster for which you want to configure an Ingress.​
  1. In the left navigation bar, click Services and Ingresses. On the page that appears, click Create Ingress.​
  • Basic configuration​
  • ​
    Parameter​
    Description​
    Name​
    Specify an Ingress name based on the on-screen prompts. The name must be unique within the same namespace.​
    Namespace​
    Select the namespace to which the Ingress belongs. We recommend that you select the namespace created by yourself or the default namespace created by the system. For details about namespaces, see Namespace overview.​
    Annotation​
    Click Add annotation to create an annotation, which is a key-value pair. You can also configure specific annotations in the Ingress YAML files to achieve more comprehensive Layer 7 LoadBalancer capabilities and more diverse service routing rules. For details, see Using annotations to configure CLB Ingresses.​
    ​
  • Ingress configuration​
  • ​
    Parameter​
    Description​
    Ingress type​
    Select the type of Ingress controller. In this example, CLB is selected.​
    ​
  • Load balancer configuration​
  • ​
    Parameter​
    Description​
    LB-to-pod direct access mode​
    It is available only to clusters using the VPC-CNI network model. This mode is enabled by default. This mode allows pods to directly serve as the backend of load balancing and supports health checks, eliminating the need for NodePort-based forwarding.​
    warning​
    The number of backend servers supported by a CLB is limited, so you need to plan backend servers accordingly. For details about the limitations, see Constraints and limits of CLB.​
    Load balancer​
    Select an existing load balancer or have a new one automatically created. There are two access modes: Public NAT for internet endpoint and Private access.​
    • Use existing: Use an existing CLB instance that is not used by Volcengine Kubernetes Engine. Using an existing CLB instance will not bring any changes to the existing listener rules of that instance.​
    • We recommend creating a new CLB instance unless it is required to use the existing ones.​
    • Automatically create: Automatically create a new CLB instance. You need to configure the following parameters. For detailed parameter descriptions, see Creating LoadBalancer instances.​
    warning​
    • Do not use this automatically created CLB instance in another Ingress or service to prevent orphaned resources.​
    • The CLB created through Volcengine Kubernetes Engine console features multiple availability zones. If the current region supports fault tolerance across multiple availability zones, LoadBalancer instances are created in the primary and secondary availability zones by default. When the primary one fails, traffic is switched to the secondary one.​
    • Name: Set a load balancer name in accordance with the displayed naming rules.​
    • Subnet: Select a private subnet that provides private IP addresses for LoadBalancer instances.​
    • After a LoadBalancer instance is created successfully, its private IP address cannot be changed.​
    • Line type: Select a line type for Internet access. Different line types vary in performance and billing standards. Available options include BGP (multi-line), Fusion BGP, China Mobile, China Telecom, and China Unicom.​
    warning​
    All the line types, except BGP (multi-line), are beta features of Elastic IP Address. To apply for these beta features, contact your account manager.​
    • Billing method: Select a billing method for the LoadBalancer instance. The following billing methods are available:​
    • Pay-as-you-go - bandwidth limit: It will be charged based on usage duration with an upper limit on bandwidth.​
    • Pay-as-you-go - actual traffic: It will be charged based on the actual amount of traffic flowing to the Internet instead of usage duration.​
    • Bandwidth limit: The maximum bandwidth for Internet access measured in Mbps. The upper limit of bandwidth can be changed anytime as needed.​
    • IP version: Select an IP version. Currently, only IPv4 is supported.​
    • Instance specification: Select a CLB instance specification. You need to select a specification that meets your actual performance requirements for your application. For specification details, see Product types and specifications.​
    Listener​
    The listener is responsible for monitoring the requests on the LoadBalancer and distributing traffic. You need to select a scheduling algorithm for the listener and decide whether to enable health check:​
    • Scheduling algorithm: It is the rules that the listener follows when forwarding requests.​
    • Weighted Round Robin: Traffic is forwarded based on weight values. The higher the weight of the backend server, the more frequently (probabilistically) it is selected as the forwarding destination.​
    • Weighted Least Connection: Traffic is forwarded first to the backend with the smallest real-time ratio of connections to weight.​
    • Source Hashing: Traffic is always forwarded to a single backend server if the hash of the source IP remains unchanged.​
    • Health check: Optional and can be enabled if needed. If enabled, the following parameters are available:​
    tip​
    The health check path for a CLB Ingress type only supports / and cannot be changed.​
    • Health check method: select a request method used to perform a health check on the listener. Available options include GET and HEAD. The GET method is used by default.​
    • The HEAD method allows the server to return only the headers and thereby reduces backend overhead. To use the HEAD method, ensure that your server supports this method.​
    • To use the GET method, ensure that your server supports this method.​
    • Normal status code: select status codes that indicate the normal status of your server. By default, 2xx and 3xx are selected.​
    • Response timeout: the waiting time for health check response. It is considered anomalous if the backend server fails to respond correctly within the specified time.​
    • Detection interval: the time interval between health check requests. The default interval is 2 seconds, which means the backend server will be checked every 2 seconds.​
    warning​
    The time interval of health check needs to be longer than the response timeout.​
    • Health threshold: the number of health check requests required to determine that the backend server is running properly. The default number is 3, which means the backend server is determined to be "healthy" if all the 3 requests get the responses indicating a normal status.​
    • Unhealthy threshold: The number of health check requests required to mark a backend server as unhealthy. The default value is 3, meaning a backend server is marked "unhealthy" if all 3 requests return abnormal responses.​
    ​
  • Listener configuration​
  • ​
    Parameter​
    Description​
    Protocol​
    Select a protocol for the listener. VKE supports two external protocols: HTTP and HTTPS.​
    When an Ingress is created, the CLB instance automatically provisions a listener based on your listener configurations. The listener follows the naming convention k8s_ <namespace of the CLB Ingress>_<CLB Ingress name>_<port number> (for example, k8s_ default_demo-ingress_80).​
    Port number​
    The port number that the listener listens on. If you do not specify a port number, the default port number is 80 for HTTP and 443 for HTTPS.​
    Certificate​
    When you select HTTPS for Protocol, you need to select a server certificate to support encryption and authentication for data transmission. You need to create a key and bind the server certificate. By default, all the specified domain names use the same key.​
    • Select a certificate source from the certificate drop-down menu. Available certificate sources include All certificates, CLB, and Certificate center.​
    • Select a secret from the secret drop-down menu. If no secret is available, click Create Secret to create one. When you create a secret, you need to configure the following parameters:​
    • Name: set a secret name in accordance with the displayed naming rules. Secret names must be unique within the same namespace.​
    • Namespace: select the namespace of this Ingress.​
    • Certificate source: select the source of the encryption certificate. Supported sources include CLB and Certificate center.​
    • Project: Select the project where the certificate is located.​
    • Server certificate: select a server certificate.​
    tip​
    Using certificates from the certificate center to create HTTPS-enabled CLB Ingresses is currently in the beta stage. To use this feature, contact your account manager to apply for a trial.​
    ​
  • Forwarding configuration​
  • ​
    Parameter​
    Description​
    Forwarding rules​
    If the target address of a request hits a forwarding rule, the request is forwarded to the corresponding service. Click Add forwarding rule to add one or more forwarding rules.​
    • Domain name: When the requested domain name matches the domain name set here, the request is forwarded to the specified service.​
    warning​
    You cannot set a domain name pattern that ends with *.​
    • Path: When the requested path matches the one set here, the request is forwarded to the specified service.​
    • Path matching rule: A CLB Ingress supports only prefix matching. Any path that hits the prefix condition is accessible. For example, if the path is /foo, both /foo/v1 and /foo/v2 can access the backend service.​
    • Service: the target service and port to which the request is forwarded. If no service is available, create one by following steps described in Services.​
    warning​
    • When the network model of the cluster is Flannel, you can select a service only in the NodePort or LoadBalancer (direct pod access disabled) category.​
    • When the network model of the cluster is VPC-CNI:​
    • If you enable LB-to-pod direct access mode, you can select a service in the NodePort, LoadBalancer (direct pod access enabled or disabled), or ClusterIP category.​
    • If you do not enable LB-to-pod direct access mode, you can select a service only in the NodePort or LoadBalancer (direct pod access enabled or disabled) category.​
    ​
  1. Click Confirm.​
​
Last updated: 2026.07.24 14:51:36