Configuring TCP/UDP load balancing

Overview

You can create a TCP/UDP Load Balancer by creating a Service with type: LoadBalancer in its specification. This page explains the parameters you can use to configure LoadBalancer Services. For more information specific to internal load balancers, see Using an internal TCP/UDP load balancer. For more information specific to external load balancers, see Exposing applications using services.

Service parameters

The following parameters are supported for Google Kubernetes Engine (GKE) LoadBalancer Services.

Feature	Summary	Service Field	GKE Version Support
Local External Traffic Policy	Configures whether or not external traffic is load balanced across GKE nodes.	spec:externalTrafficPolicy:Local	GKE 1.14+
Load Balancer Source Ranges	Configures optional firewall rules in GKE and in the VPC to only allow certain source ranges.	spec:loadBalancerSourceRanges	All supported versions
Load Balancer IP	Specifies an IP for the load balancers	spec:loadBalancerIP	All supported versions
All-ports	The ability for the TCP/UDP load balancer to forward all ports instead of specific ports	N/A	No native support

External traffic policy

The externalTrafficPolicy is a standard Service option that defines how and whether traffic incoming to a GKE node is load balanced. Cluster is the default policy but Local is often used to preserve the source IP of traffic coming into a cluster node. Local effectively disables load balancing on the cluster node so that traffic that is received by a local Pod sees the original source IP address.

Note: Using the Local policy to preserve source IP addresses will not work if ip-masq-agent is running on your cluster and the Pod IP address range is not excluded from IP masquerading. See Specifying nonMasqueradeCIDRs for instructions on excluding IP address ranges from masquerading.

externalTrafficPolicy is supported for internal LoadBalancer Services (via the TCP/UDP load balancer), but load balancing behavior depends on where traffic originates from and the configured traffic policy.

Traffic sourced from outside the cluster to a TCP/UDP load balancer will have the following behavior if there is at least one healthy Pod of the Service in the cluster:

• Cluster policy: Traffic will be load balanced to any healthy GKE node in the cluster and then the kube-proxy will send it to a node with the Pod.
• Local policy: Nodes that do not have one of the backend Pods appear as unhealthy to the TCP/UDP load balancer. Traffic will only be sent to one of the remaining healthy cluster nodes which has the Pod. Traffic is not routed again by the kube-proxy and instead will be sent directly to the local Pod with its IP header information intact.

If traffic to a given LoadBalancer Service IP is sourced from a GKE node inside the cluster, there is a different traffic behavior. The following table summarizes the traffic behavior for traffic sourced by a node or Pod inside the cluster destined for a member Pod of a LoadBalancer Service:

externalTrafficPolicy	Service member Pod running on same node where traffic originates?	Traffic behavior
Cluster	Yes	Packets are delivered to any member Pod, either on the node or on a different node.
Cluster	No	Packets are delivered to any member Pod, which must be on a different node.
Local	Yes	Packets are delivered to any member Pod on the same node.
Local	No	Kubernetes 1.14 and earlier: Packets are dropped. Kubernetes 1.15 and later: Packets are delivered to any member Pod, which must be on a different node.

Load balancer source ranges

The spec: loadBalancerSourceRanges array specifies one or more internal IP address ranges. loadBalancerSourceRanges restricts traffic through the load balancer to the IPs specified in this field. With this configuration, kube-proxy creates the corresponding iptables rules in Kubernetes nodes. GKE also creates a firewall rule in your VPC network automatically. If you omit this field, your Service accepts traffic from any IP address (0.0.0.0/0).

For more information about the Service specification, see the Service API reference.

Warning: When you create any load balancer Service, unless you set the loadBalancerSourceRanges field yourself, you create a firewall rule based on the field's default IP range, 0.0.0.0/0. Be aware that this may expose other node processes using the same port.

If other processes are bound to the port on a node, the firewall also applies to those processes and the processes are exposed through the node's external IP. GCP does not currently support matching destination IP addresses for incoming traffic. Kubernetes services are still protected by kube-proxy.

Load balancer IP

The spec: loadBalancerIP enables you to choose a specific IP address for the load balancer. The IP address must not be in use by another internal TCP/UDP load balancer or Service. If omitted, an ephemeral IP is assigned. For more information, see [Reserving a Static Internal IP Address].

All-ports

If you create an internal TCP/UDP load balancer by using an annotated Service, there is no way to set up a forwarding rule that uses all ports. However, if you create an internal TCP/UDP load balancer manually, you can choose your Google Kubernetes Engine nodes' instance group as the backend. Kubernetes Services of type: NodePort are available through the ILB.

What's next

• Read the GKE network overview.
• Learn more about Compute Engine load balancers.
• Learn about internal load balancers.
• Learn about exposing applications externally using services.