kubernetes/kops · error

waiting for load-balancer %s: %w

Error message

waiting for load-balancer %s: %w

What it means

kOps wraps failures from `lbService.WaitForLb` after creating/updating a front-end; the SDK polls the LB until it is stable. If the LB never becomes ready in the retry budget or the polling calls fail, this error is returned from RenderScw of LoadBalancerFrontend.

Source

Thrown at upup/pkg/fi/cloudup/scalewaytasks/lb_frontend.go:169

			LBID:        fi.ValueOf(expected.LoadBalancer.LBID),
			Name:        fi.ValueOf(expected.Name),
			InboundPort: fi.ValueOf(expected.InboundPort),
			BackendID:   fi.ValueOf(expected.LBBackend.ID),
		})
		if err != nil {
			return fmt.Errorf("creating front-end for load-balancer %s: %w", fi.ValueOf(expected.LoadBalancer.Name), err)
		}

		expected.ID = &frontendCreated.ID

	}

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

	return nil
}

type terraformLBFrontend struct {
	BackendID   *terraformWriter.Literal `cty:"backend_id"`
	LBID        *terraformWriter.Literal `cty:"lb_id"`
	Name        *string                  `cty:"name"`
	InboundPort *int32                   `cty:"inbound_port"`
}

func (_ *LBFrontend) RenderTerraform(t *terraform.TerraformTarget, actual, expected, changes *LBFrontend) error {
	tf := terraformLBFrontend{
		LBID:        expected.LoadBalancer.TerraformLink(),
		BackendID:   expected.LBBackend.TerraformLink(),
		Name:        expected.Name,
		InboundPort: expected.InboundPort,

View on GitHub (pinned to 4c8573c808)

Solutions

1. Rerun `kops update cluster` after giving the LB time to stabilize
2. Check LB status in the Scaleway console; recreate if permanently stuck
3. Verify expected.Zone is set and matches the LB's actual zone
4. Check Scaleway status page for LB incidents
5. Increase Scaleway client retry/timeout configuration if timeouts recur

Example fix

// before: default wait
_, err := lbService.WaitForLb(&lb.ZonedAPIWaitForLBRequest{LBID: lbID, Zone: zone})
// after: bound with explicit retry and clearer error
err = retry.Do(func() error {
    _, err := lbService.WaitForLb(&lb.ZonedAPIWaitForLBRequest{LBID: lbID, Zone: zone})
    return err
}, retry.Attempts(5), retry.Delay(15*time.Second))

// verify LB exists in expected zone before waiting
lbs, err := lbService.ListLBs(&lb.ZonedAPIListLBsRequest{Zone: scw.Zone(fi.ValueOf(expected.Zone)), Name: lbName}, scw.WithAllPages())
if err != nil || lbs.TotalCount != 1 { return fmt.Errorf("LB %s not found in zone %s", lbName, fi.ValueOf(expected.Zone)) }

var serr *scw.ResponseError
if errors.As(err, &serr) && (serr.Status == 429 || serr.Status >= 500) {
    // transient: safe to re-run kops update cluster later
}

When it happens

Trigger: After CreateFrontend/UpdateFrontend, RenderScw calls WaitForLb with expected.LoadBalancer.LBID and Zone=expected.Zone; polling fails due to API errors, wrong zone, deleted LB, or the LB stays in a pending/migrating state beyond the timeout.

Common situations: Front-end changes triggering LB migration longer than the SDK's wait budget; LB deleted out-of-band mid-reconcile; zone field missing/wrong in the task spec; Scaleway API incident.

Related errors

• waiting for load-balancer %s: %w
• waiting for load-balancer %s after deletion: %w
• deregistering cloud instance %s of group %q: %w
• deregistering cloud instance %s of group %q: listing load-ba
• deregistering cloud instance %s of group %q: removing IP fro

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