Load balancer issues

CFKE provisions a cloud load balancer for every Service of type LoadBalancer, in each provider and region where matching nodes run. This page covers the recurring problems around those load balancers. For the full feature reference, see Public cloud load balancing.

The load balancer IP keeps changing

Symptom: the external IP of your ingress or Service changes occasionally, breaking DNS records that point at it.

Cause: load balancer IPs are not stable by design. With externalTrafficPolicy: Local, CFKE creates the load balancer in the region where the backing pods run. When node consolidation moves a single-replica ingress controller to a node in another region, the old load balancer is deleted and a new one is created there, with a new IP. Bringing your own IP (spec.loadBalancerIP or provider floating IPs) is not supported for managed load balancers.

Fix:

1. Point DNS at the stable per-Service hostname instead of the IP. Cloudfleet maintains a DNS record for every load-balanced Service that always resolves to the current load balancer addresses:

   Copy

   SERVICE_NAME.NAMESPACE.CLUSTER_ID.CONTROL_PLANE_REGION.cfke.cloudfleet.dev

   Create a CNAME from your domain to this name. See Setting up DNS for your load balancer service for details.

2. Pin the ingress controller to one region so consolidation cannot move it across locations:

   yaml Copy

   nodeSelector:
     topology.kubernetes.io/region: nbg1

Choosing the external traffic policy

• externalTrafficPolicy: Cluster (default) creates a load balancer in every provider and region where any node exists, and traffic may take an extra hop between nodes. The client IP is not preserved.
• externalTrafficPolicy: Local creates load balancers only where the backing pods run, preserves the client source IP, and avoids the extra hop. This is the recommended setting for multi-region clusters and required for meaningful client IP logging.

There is no annotation to pin a load balancer to a specific location; the placement follows your pods, which you control with node selectors.

The load balancer has no healthy targets

Symptom: the load balancer accepts TCP connections but resets them, or health checks show zero healthy targets.

Checks:

1. With externalTrafficPolicy: Local, confirm a backing pod actually runs in the load balancer’s region; a Service whose pods all moved elsewhere leaves an empty load balancer behind.
2. Confirm the pods pass their readiness probes; only ready pods are registered as targets.
3. Avoid running multiple Fleets that provision nodes into the same provider location for the same Service; if you need distinct node groups in one location, use Fleet constraints and node selectors rather than parallel Fleets.

If targets remain missing after these checks, contact support.

General rules

• Never modify or delete Cloudfleet-created load balancers in the provider console; changes are reverted or break routing. Configure behavior through Service annotations instead (see the supported annotations).
• Gateway API: bring your own Gateway API implementation (for example Envoy Gateway or Istio); its LoadBalancer Services get cloud load balancers automatically. The built-in networking stack’s own Gateway API mode is not user-configurable.