A network load balancer spreads incoming TCP traffic across a cluster at Layer 4. In GKE, a Kubernetes Service of type LoadBalancer can provision one in front of the Service. Clients connect to the Service’s external IP address; the load balancer uses network forwarding rules to send traffic to cluster nodes. GKE also configures VPC firewall rules to permit those connections. A static external IP can be assigned when the address must remain stable. section 10.2.1
Choose the entry point according to where clients run and what routing they need:
- Use an external load balancer for clients outside both the cluster and its VPC; use an internal load balancer for clients in the same VPC. Both are TCP/Layer 4 options. section 10.2.1
- Use HTTP(S) Ingress when web traffic needs application-level routing. An in-cluster Ingress controller can itself be exposed through an L3/L4 load balancer, allowing one Ingress VIP to serve multiple Services. section 10.2.1 section 10.3.2
- For Anthos client access without Anthos Service Mesh, expose a TCP Service with type LoadBalancer. For web-based Services, Ingress is the recommended alternative; ASM Ingress is recommended when ASM is in use. section 10.4.1
apiVersion: v1
kind: Service
metadata:
name: ilb-service
annotations:
cloud.google.com/load-balancer-type: "Internal" #1
labels:
app: hello
spec:
type: LoadBalancer #2
selector:
app: hello
ports:
- port: 80
targetPort: 8080
protocol: TCP
This Service manifest requests an internal load balancer with the cloud.google.com/load-balancer-type annotation. It exposes TCP port 80 and forwards to the selected workload on port 8080. section 10.2.1
In an Anthos hybrid or on-prem cluster, the load balancer may be bundled with installation or configured manually. A Service VIP gives resources outside the cluster a reachable address. Traffic follows the Service VIP to a node IP and the Service’s NodePort, then to the destination Pod IP and port. This path also lets a Service or Pod in one cluster reach a Service in another when the VIP is reachable across their networks. section 10.3.2
Plan addresses and backends before an on-prem deployment. Bundled and manual modes both require VIPs; manual mode also requires node IP addresses, NodePort choices, and load-balancer configuration. On bare metal, reserve a control-plane VIP per cluster, an Ingress VIP per user cluster, and a VIP for each LoadBalancer Service. A manually configured Service VIP must match the Service object and point to a backend group of worker-node IPs on that Service’s NodePort. section 10.2.1 section 17.3.4
Prepare a bundled on-prem load balancer
After validating the user-cluster configuration with gkectl check-config, create Seesaw nodes with gkectl create loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [CONFIG_FILE] before running gkectl create cluster. If the configuration selects the integrated load-balancer option but the Seesaw nodes do not exist, the cluster precheck fails. section 5.2.1
