istio/istio · error

workloadgroup %s not found in namespace %s: %v

Error message

workloadgroup %s not found in namespace %s: %v

What it means

RunE of `istioctl x workload entry configure` (istioctl/pkg/workload/workload.go:239): the -f path was empty so it fetched WorkloadGroups(namespace).Get(name) from the API server and the get returned an error (usually 404), wrapped as `workloadgroup %s not found in namespace %s: %v`. Note the call uses the raw namespace variable, not the kubeconfig default.

Source

Thrown at istioctl/pkg/workload/workload.go:239

			}
			return nil
		},
		RunE: func(cmd *cobra.Command, args []string) error {
			kubeClient, err := ctx.CLIClientWithRevision(ctx.RevisionOrDefault(opts.Revision))
			if err != nil {
				return err
			}

			wg := &clientnetworking.WorkloadGroup{}
			if filename != "" {
				if err := readWorkloadGroup(filename, wg); err != nil {
					return err
				}
			} else {
				wg, err = kubeClient.Istio().NetworkingV1().WorkloadGroups(namespace).Get(context.Background(), name, metav1.GetOptions{})
				// errors if the requested workload group does not exist in the given namespace
				if err != nil {
					return fmt.Errorf("workloadgroup %s not found in namespace %s: %v", name, namespace, err)
				}
			}

			// extract the cluster ID from the injector config (.Values.global.multiCluster.clusterName)
			if !validateFlagIsSetManuallyOrNot(cmd, "clusterID") {
				// extract the cluster ID from the injector config if it is not set by user
				clusterName, err := extractClusterIDFromInjectionConfig(kubeClient, ctx.IstioNamespace())
				if err != nil {
					return fmt.Errorf("failed to automatically determine the --clusterID: %v", err)
				}
				if clusterName != "" {
					clusterID = clusterName
				}
			}

			if err = createConfig(kubeClient, wg, ctx.IstioNamespace(), clusterID, ingressIP, internalIP, externalIP, outputDir, cmd.OutOrStderr()); err != nil {
				return err
			}

View on GitHub (pinned to 8dc789c5cf)

Solutions

  1. Confirm the resource exists: `kubectl get workloadgroups -n <ns> <name>`
  2. If missing, generate and apply it first: `istioctl x workload group create --name <name> -n <ns> ... | kubectl apply -f -`
  3. Verify context/cluster: `kubectl config current-context`
  4. Alternatively switch to the artifact path: `-f workloadgroup.yaml` to bypass the API server lookup

Example fix

# before
istioctl x workload entry configure --name foo -n bar -o config   # not found
# after
istioctl x workload group create --name foo -n bar --serviceAccount sa | kubectl apply -f -
istioctl x workload entry configure --name foo -n bar -o config
Defensive patterns

Strategy: validation

Validate before calling

kubectl get workloadgroup "$WG_NAME" -n "$WG_NS" >/dev/null 2>&1 || {
  echo "workloadgroup missing; creating" >&2
  istioctl x workload group create --name "$WG_NAME" -n "$WG_NS" | kubectl apply -f -
}

Prevention

When it happens

Trigger: `configure --name foo -n wrong-ns -o config` where foo lives elsewhere; WorkloadGroup never created (step `workload group create` skipped or its output not applied with kubectl); wrong cluster context; RBAC denial is also surfaced here since any Get error triggers it.

Common situations: Multi-step VM onboarding where `istioctl x workload group create` YAML was generated but never `kubectl apply`ed; typo in name/namespace; pointing at the wrong cluster in a multi-cluster mesh.

Related errors


AI-assisted analysis of istio/istio@8dc789c5cf (2026-08-15). Data as JSON: /api/errors/b18e8d70dc73ee67. Report an issue: GitHub.