kubernetes/kops · error

waiting for load-balancer %s: %w

Error message

waiting for load-balancer %s: %w

What it means

In the load-balancer task's RenderScw, WaitForLb timed out or errored after CreateLB succeeded. The load-balancer exists but did not reach a ready state, so subsequent configuration (frontends/backends) was skipped; the LB ID identifies it.

Source

Thrown at upup/pkg/fi/cloudup/scalewaytasks/loadbalancer.go:197

		klog.Infof("Creating new load-balancer with name %q", fi.ValueOf(expected.Name))

		lbCreated, err := lbService.CreateLB(&lb.ZonedAPICreateLBRequest{
			Zone: scw.Zone(fi.ValueOf(expected.Zone)),
			Name: fi.ValueOf(expected.Name),
			Type: LbDefaultType,
			Tags: expected.Tags,
		})
		if err != nil {
			return fmt.Errorf("creating load-balancer: %w", err)
		}

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

		lbIPs := []string(nil)
		for _, ip := range lbCreated.IP {
			lbIPs = append(lbIPs, ip.IPAddress)
		}
		expected.LBID = &lbCreated.ID
		expected.LBAddresses = lbIPs

	}

	return nil
}

type terraformLBIP struct{}

type terraformLoadBalancer struct {
	Type        string                   `cty:"type"`

View on GitHub (pinned to 4c8573c808)

Solutions

1. Check the wrapped error for timeout details
2. Inspect the LB state in the Scaleway console
3. Re-run the apply; the existing LB is picked up as 'actual' and updated

When it happens

Trigger: Thrown at upup/pkg/fi/cloudup/scalewaytasks/loadbalancer.go:197 when the library encounters an invalid state.

Common situations: See trigger scenarios.

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