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. DNS records that point at the IP break.

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. Node consolidation can move a single-replica ingress controller to a node in another region. CFKE then deletes the old load balancer and creates a new one in that region, with a new IP. spec.loadBalancerIP is not supported.

Fix:

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

    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 
    nodeSelector:
  topology.kubernetes.io/region: nbg1

  3. On Hetzner, keep a fixed IP with your own Primary IPs. Set the networking.cfke.io/hetzner-primary-ips annotation on the Service, and the load balancer keeps the same address when CFKE recreates it. See Using your own IP addresses (Hetzner).

Choosing the external traffic policy

  • externalTrafficPolicy: Cluster (default) creates a load balancer in every provider and region where any node exists. 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. It preserves the client source IP and avoids the extra hop. It is recommended for multi-region clusters and required for meaningful client IP logging.

No annotation pins 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 that a backing Pod runs in the load balancer’s region. If all Pods of a Service moved elsewhere, an empty load balancer stays behind.
  2. Confirm that the Pods pass their readiness probes. Only ready Pods are registered as targets.
  3. Do not run multiple Fleets that provision nodes into the same provider location for the same Service. For 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.
Previous
← Network connectivity issues
Next
Control plane pressure and API throttling →
On this page