ISTIOCTL-EXPERIM...LOAD-GROUP-CREATE(1)

πŸ“¦ version 1.31.3, in nixos 26.05, nixpkgs unstable

πŸ’… ISTIOCTL-EXPERIMENTAL-WORKLOAD-GROUP-CREATE πŸ’…

okay bestie, welcome to the istioctl-experimental-workload-group-create page β€” yes the title is a whole mouthful, the manpage machinery just truncated it up top, but we're saying the whole thing okurrr πŸ’–


✨ NAME ✨

istioctl-experimental-workload-group-create β€” creates a WorkloadGroup resource that gives you a template for all the associated WorkloadEntries 🫢


🌸 SYNOPSIS 🌸

istioctl experimental workload group create [flags]

that's the whole vibe. flags go at the end, periodt.


πŸ¦‹ DESCRIPTION πŸ¦‹

So what does this actually do? It creates a WorkloadGroup resource, and that resource is literally the template for its associated WorkloadEntries ✨ like a little blueprint that says "here's what my workloads look like" and then the WorkloadEntries follow along.

The default output is serialized YAML β€” and bestie that is the move, because you can just pipe it straight into kubectl apply -f - and send the artifact to the API Server. no cap, no extra steps. iconic behavior honestly πŸ‘‘


πŸŽ€ OPTIONS πŸŽ€

  • -a, --annotations=[] β€” the annotations you want to slap onto the workload instances πŸ’Œ
  • -h, --help[=false] β€” help for create. your classic little helper πŸ₯Ί
  • -l, --labels=[] β€” the labels to apply to the workload instances; e.g. -l env=prod,vers=2 🏷️
  • --locality="" β€” the locality associated with the endpoint πŸ“
  • --name="" β€” the name of the workload group, yes you gotta give it a name bestie πŸ’œ
  • -n, --namespace="" β€” the namespace that the workload instances will belong to πŸ—‚οΈ
  • --network="" β€” Network enables Istio to group endpoints resident in the same L3 domain/network 🌐
  • -p, --ports=[] β€” the incoming ports exposed by the workload instance πŸ”Œ
  • -s, --serviceAccount="default" β€” the service identity to associate with the workload instances (defaults to default, as it should) πŸͺͺ
  • -w, --weight=0 β€” the load balancing weight associated with the endpoint βš–οΈ

🌈 OPTIONS INHERITED FROM PARENT COMMANDS 🌈

these are the family hand-me-downs, still lowkey essential:

  • --as="" β€” username to impersonate for the operation. User could be a regular user or a service account in a namespace 🎭
  • --as-group=[] β€” group to impersonate for the operation, this flag can be repeated to specify multiple groups πŸ”
  • --as-uid="" β€” UID to impersonate for the operation πŸ†”
  • --context="" β€” Kubernetes configuration context 🧭
  • -i, --istioNamespace="istio-system" β€” Istio system namespace (default is istio-system) 🌌
  • --kubeclient-timeout="15s" β€” Kubernetes client timeout as a time.Duration string, defaults to 15 seconds ⏳
  • -c, --kubeconfig="" β€” Kubernetes configuration file πŸ“„
  • --vklog=0 β€” number for the log level verbosity. Like -v flag. ex: --vklog=9 πŸ”Š

πŸ“ EXAMPLE πŸ“

okay here's the whole thing in action, copy-paste energy fr fr:

istioctl x workload group create --name foo --namespace bar --labels app=foo,bar=baz --ports grpc=3550,http=8080 --annotations annotation=foobar --serviceAccount sa

look at that. name, namespace, labels, ports, annotations, serviceAccount β€” all the little details doing their thing πŸ’…βœ¨


🧚 SEE ALSO 🧚

istioctl-experimental-workload-group(1) β€” go read the parent one too, bestie 🫢


heads up: this page is Auto generated by spf13/cobra, dated Jan β€” so yeah, the robots made it, we just gave it the glow-up πŸ’– stay slay, bye! πŸŒΈπŸ¦‹
πŸ“¦ where this page comes from