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
- Confirm the resource exists: `kubectl get workloadgroups -n <ns> <name>`
- If missing, generate and apply it first: `istioctl x workload group create --name <name> -n <ns> ... | kubectl apply -f -`
- Verify context/cluster: `kubectl config current-context`
- 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
- Chain group create | kubectl apply before entry configure in onboarding scripts
- Prefer -f workloadgroup.yaml on VMs to avoid cluster lookups entirely
- Assert kubectl config current-context equals the intended cluster in multi-cluster setups
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
- configmap %s was not found in namespace %s: %v
- namespace: %s not found
- expecting a workload name
- expecting a workload namespace
- expecting a WorkloadGroup artifact file or the name and name
AI-assisted analysis of istio/istio@8dc789c5cf (2026-08-15).
Data as JSON: /api/errors/b18e8d70dc73ee67.
Report an issue: GitHub.