What causes "waiting for load-balancer %s: %w" in kubernetes/kops?

Rerun `kops update cluster` later — the LB may simply need more time

waiting for load-balancer %s: %w

Error message

waiting for load-balancer %s: %w

What it means

kOps wraps failures from `lbService.WaitForLb`, the Scaleway SDK helper that polls the LB until it leaves a transient state, after creating or updating a back-end. If the LB never becomes ready within the SDK's retry budget (or the polling API calls fail), this error surfaces. Thrown at the end of RenderScw for LoadBalancerBackend.

Source

Thrown at upup/pkg/fi/cloudup/scalewaytasks/lb_backend.go:199

				CheckDelay:      scw.TimeDurationPtr(1001),
			},
			ServerIP:      controlPlanesIPs,
			ProxyProtocol: lb.ProxyProtocol(fi.ValueOf(expected.ProxyProtocol)),
		})
		if err != nil {
			return fmt.Errorf("creating back-end for load-balancer %s: %w", fi.ValueOf(expected.LoadBalancer.Name), err)
		}

		expected.ID = &backendCreated.ID

	}

	_, err = lbService.WaitForLb(&lb.ZonedAPIWaitForLBRequest{
		LBID: fi.ValueOf(expected.LoadBalancer.LBID),
		Zone: zone,
	})
	if err != nil {
		return fmt.Errorf("waiting for load-balancer %s: %w", fi.ValueOf(expected.LoadBalancer.Name), err)
	}

	return nil
}

type terraformLBBackend struct {
	LBID            *terraformWriter.Literal   `cty:"lb_id"`
	Name            *string                    `cty:"name"`
	ForwardProtocol *string                    `cty:"forward_protocol"`
	ForwardPort     *int32                     `cty:"forward_port"`
	ProxyProtocol   *string                    `cty:"proxy_protocol"`
	ServerIPs       []*terraformWriter.Literal `cty:"server_ips"`
}

func (l *LBBackend) RenderTerraform(t *terraform.TerraformTarget, actual, expected, changes *LBBackend) error {
	var serverIPs []*terraformWriter.Literal
	resources, err := t.GetResourcesByType()
	if err != nil {

View on GitHub (pinned to 4c8573c808)

Solutions

Rerun `kops update cluster` later — the LB may simply need more time
Check LB status in Scaleway console; if stuck, detach/reattach or recreate the LB
Verify the zone/LBID are correct and the LB was not deleted out-of-band
Check Scaleway status page for ongoing LB incidents
Increase the SDK retry config (Retry/timeout options on the Scaleway client) if timeouts recur

Example fix

// before: default wait options
_, err = lbService.WaitForLb(&lb.ZonedAPIWaitForLBRequest{LBID: lbID, Zone: zone})
// after: longer retry budget via client options
scwClient.Options = append(scwClient.Options, scw.WithDefaultRetryConfig(&scw.RetryConfig{MaxRetries: 10}))
_, err = lbService.WaitForLb(&lb.ZonedAPIWaitForLBRequest{LBID: lbID, Zone: zone})

Defensive patterns

Strategy: retry

Validate before calling

// confirm LB exists and check its state before waiting
lbs, err := lbService.ListLBs(&lb.ZonedAPIListLBsRequest{Zone: zone, Name: lbName}, scw.WithAllPages())
if err != nil || lbs.TotalCount != 1 { return fmt.Errorf("LB %s not found in %s", lbName, zone) }
if lbs.LBs[0].Status != lb.LBStatusReady && lbs.LBs[0].Status != lb.LBStatusPending { return fmt.Errorf("unexpected LB status %s", lbs.LBs[0].Status) }

Try / catch

var serr *scw.ResponseError
if errors.As(err, &serr) && (serr.Status == 429 || serr.Status >= 500) {
    // transient: schedule a re-run instead of failing hard
}

Prevention

Allow generous time windows for LB migrations on Scaleway
Never delete LBs out-of-band while kOps manages them
Pin the Scaleway SDK version with known-good retry defaults
Check Scaleway status page before large reconcile runs

When it happens

Trigger: After SetBackendServers/CreateBackend completes, RenderScw calls WaitForLb on expected.LoadBalancer.LBID; the LB stays in 'migrating'/'pending' state too long, or polling ListLB/GetLB requests fail (auth, network, LB deleted).

Common situations: Large LB migrations on Scaleway exceeding WaitForLb default timeout; LB deleted out-of-band mid-reconcile; Scaleway API incident; wrong zone so the LB is not found.

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/cb516758f7bb4518. Report an issue: GitHub.