kubernetes/kops · error

load balancer not yet ready (arn is empty)

Error message

load balancer not yet ready (arn is empty)

What it means

During RenderAWS of a TargetGroup task, the task carries a reference to its parent NetworkLoadBalancer, but the NLB has not been created yet so its loadBalancerArn is empty. Since target groups for NLBs are created in the NLB's VPC and tagged with the NLB's revision, kOps refuses to proceed rather than creating a target group tied to a non-existent load balancer. This is an ordering/dependency guard within a single cloudup apply run.

Source

Thrown at upup/pkg/fi/cloudup/awstasks/targetgroup.go:335

	ctx := context.TODO()
	shared := fi.ValueOf(e.Shared)
	if shared {
		return nil
	}

	tags := make(map[string]string)
	for k, v := range e.Tags {
		tags[k] = v
	}
	if a != nil {
		if a.revision != "" {
			tags[awsup.KopsResourceRevisionTag] = a.revision
		}
	}

	if e.networkLoadBalancer != nil {
		if e.networkLoadBalancer.loadBalancerArn == "" {
			return fmt.Errorf("load balancer not yet ready (arn is empty)")
		}
		nlbRevision := e.networkLoadBalancer.revision
		if nlbRevision != "" {
			tags[awsup.KopsResourceRevisionTag] = nlbRevision
		}
	}

	// You register targets for your Network Load Balancer with a target group. By default, the load balancer sends requests
	// to registered targets using the port and protocol that you specified for the target group. You can override this port
	// when you register each target with the target group.

	if a == nil {
		createTargetGroupName := *e.Name
		if tags[awsup.KopsResourceRevisionTag] != "" {
			s := *e.Name + tags[awsup.KopsResourceRevisionTag]
			// We always compute the hash and add it, lest we trick users into assuming that we never do this
			opt := truncate.TruncateStringOptions{
				MaxLength:     32,

View on GitHub (pinned to 4c8573c808)

Solutions

1. Re-run `kops update cluster` — the NLB is usually created in a prior pass and the ARN will then be populated
2. Check that the LoadBalancer task (networkLoadBalancer) is correctly wired to the TargetGroup so fi task dependencies enforce ordering
3. If persistent, inspect the NLB task in the cluster spec (kubectl.kubernetes.io/last-applied / kops get) for a failed NLB creation and fix the underlying NLB creation error
4. Upgrade kOps — NLB/target-group ordering bugs have been fixed over releases

// before apply: ensure NLB task is resolvable and will be created in the same run
nlb := findTask(t, &awstasks.NetworkLoadBalancer{})
if nlb == nil { return errors.New("NLB task missing from target; cannot create target group") }

if e.networkLoadBalancer != nil && e.networkLoadBalancer.loadBalancerArn != "" {
  // safe to proceed
}

When it happens

Trigger: Running `kops update cluster` with a NetworkLoadBalancer-backed service where the NLB task has not yet been rendered/created before the TargetGroup task's RenderAWS executes, so e.networkLoadBalancer.loadBalancerArn is still the empty string.

Common situations: First-time cluster bring-up or adding an NLB-backed load balancer where task dependency ordering fails; a partially-failed apply that created the target group reconciliation pass before the NLB; custom builds where NLB task ordering changed.

Related errors

• error deleting V2 LoadBalancer %q: %v
• error deleting TargetGroup %q: %v
• failed to attach target groups: %v
• failed to detach target groups from autoscaling group: %v
• error mapping DNSName %q to LoadBalancer: %v

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