A load balancer receives client requests and distributes traffic across multiple servers. It is a core technology for avoiding problems that can occur when a single server handles every request.
In Kubernetes Engine, you can create and manage a load balancer by declaring Service.type=LoadBalancer and configuring spec.loadBalancerClass. Depending on the configured value, a Network Load Balancer (NLB) or Application Load Balancer (ALB) is created automatically.
Availability from August 25, 2026
This guide applies to Kubernetes Engine Services that use spec.loadBalancerClass and loadbalancer.kakaocloud.com/* annotations. These features are supported only on clusters running v1.30 or later.
Specify the load balancer type with spec.loadBalancerClass.
Use only loadbalancer.kakaocloud.com/* annotations.
If an existing cluster uses legacy annotations, see the legacy guide.
The protocols, annotations, and restrictions described in this guide apply to Kubernetes Engine Service integration.
They can differ from the full feature set of the KakaoCloud Load Balancing service.
Use the following procedure to create a load balancer in Kubernetes Engine.
caution
Load balancers created by Kubernetes Engine in the kr-central-2 region use a high-availability configuration. They are automatically distributed across all Availability Zones (AZs) included in the cluster network.
Even if workloads run in only some AZs, resources are allocated for the load balancer across all AZs. Load balancers created in each AZ are billable.
To create a Service object in Kubernetes, install kubectl and configure access to the cluster.
For instructions, see Configure kubectl.
Step 2. Register and manage SSL certificates (optional)
To terminate TLS on an ALB or NLB, configure loadbalancer.kakaocloud.com/tls-container-refs and register the SSL certificate first. Register or delete certificates in Management > Certificate Manager, and then specify the generated certificate ID in tls-container-refs.
Specify the load balancer type with spec.loadBalancerClass.
caution
You cannot change spec.loadBalancerClass after creating a Service. To change an existing LoadBalancer Service from NLB to ALB or vice versa, create a new Service with the required spec.loadBalancerClass value.
Type
Value
Description
NLB
loadbalancer.kakaocloud.com/nlb
L4 load balancer for TCP- or UDP-based services. When tls-container-refs is set, a TLS listener and TCP target group are created.
ALB
loadbalancer.kakaocloud.com/alb
L7 load balancer that uses HTTP by default. When tls-container-refs is set, an HTTPS listener and HTTP target group are created.
info
For tls-container-refs, enter a certificate path in the format https://key-manager.{region}/v1/secrets/{secret-id}.
An ALB without a certificate uses an HTTP listener. An NLB uses a TCP or UDP listener according to the Service protocol.
Use loadbalancer.kakaocloud.com/load-balancer-scheme to configure an internal or internet-facing load balancer.
Annotation
Value
Description
loadbalancer.kakaocloud.com/load-balancer-scheme
internal
Internal load balancer that uses private addresses (default)
loadbalancer.kakaocloud.com/load-balancer-scheme
internet-facing
External load balancer that can be publicly exposed
caution
When you set internet-facing, a new public IP is created and attached to the load balancer.
You cannot change internet-facing or internal after creation. If you used the wrong value, create a new Service with the correct setting, migrate traffic, and then delete the old Service.
If loadbalancer.kakaocloud.com/delete-floatingip is omitted or set to false, the public IP remains detached after Service deletion and can continue to incur charges.
Creating the load balancer can take several minutes. While creation is in progress, EXTERNAL-IP can display Pending or an IP address can appear before creation completes.
Even if EXTERNAL-IP has a value, requests might fail while the load balancer or high-availability group is in the Creating state.
You can inspect the load balancer and high-availability group in the console. Traffic can be handled normally after all related resources enter the Active state.
Disabling health monitoring: Setting enable-health-monitor=false is not recommended in production because traffic can continue to be sent to unhealthy nodes.
Configuration reconciliation: If you directly change a setting controlled by the Service spec or annotations in the console, a Kubernetes resource change or controller reconciliation can restore the value defined in the Service. Make changes through the Kubernetes resource.
Mixing annotations: Mixing ALB-only and NLB-only annotations can prevent normal operation.
Traffic loss: A delay between pod termination and load balancer or service endpoint updates can cause temporary traffic loss. The effect can be greater with externalTrafficPolicy: Local because external traffic is sent only to node-local endpoints. Configure a preStop hook and sufficient terminationGracePeriodSeconds to allow draining before termination. The recommended wait time is at least the LB health check propagation time (health-monitor-delay × health-monitor-max-retries). For more information, see the Kubernetes documentation.
The following loadbalancer.kakaocloud.com/* annotations are available on current-version clusters.
Notation
Select a Details link to review the supported values, defaults, and considerations for an annotation.
Specifies certificates for TLS termination on an ALB or NLB.
Values/default
"https://key-manager.{region}/v1/secrets/{secret-id}"; no default
Changes/notes
Only an annotation specified at Service creation can be updated; adding or removing it later is not supported. Specify up to six unique certificates, separated by commas. The first is the default certificate and the others are optional certificates. Configuring it at creation is recommended.
Can be changed after Service creation. Changing it deletes the existing health monitor and creates a new one. A non-default protocol can cause traffic loss during node scale-in.
Specifies the subnets in which the load balancer is created.
Values/default
Comma-separated subnet IDs such as "{subnet-id}"; no default
Changes/notes
Applied only at Service creation. Later changes do not affect the existing load balancer. When multiple subnets are specified, the first subnet for each AZ takes priority. For an unspecified AZ, a subnet from the cluster configuration is selected automatically.
Filters nodes used as load balancer target group members.
Values/default
List of key or key=value expressions; no default
Changes/notes
Can be changed after Service creation. Reconfiguring members can temporarily affect traffic. Only nodes whose labels include every specified expression are used.
Do not use loadbalancer.ke.kakaocloud.com/*, loadbalancer.openstack.org/*, or service.beta.kubernetes.io/openstack-internal-load-balancer on current-version clusters.