WorkloadGroup describes a collection of workload instances.
It provides a specification that the workload instances can use to bootstrap
their proxies, including the metadata and identity. It is only intended to
be used with non-k8s workloads like Virtual Machines, and is meant to mimic
the existing sidecar injection and deployment specification model used for
Kubernetes workloads to bootstrap Istio proxies.
The following example declares a workload group representing a collection
of workloads that will be registered under reviews in namespace
bookinfo. The set of labels will be associated with each workload
instance during the bootstrap process, and the ports 3550 and 8080
will be associated with the workload group and use service account default.
app.kubernetes.io/version is just an arbitrary example of a label.
WorkloadGroup enables specifying the properties of a single workload for bootstrap and
provides a template for WorkloadEntry, similar to how Deployment specifies properties
of workloads via Pod templates. A WorkloadGroup can have more than one WorkloadEntry.
WorkloadGroup has no relationship to resources which control service registry like ServiceEntry
and as such doesn’t configure host name for these workloads.
Metadata that will be used for all corresponding WorkloadEntries.
User labels for a workload group should be set here in metadata rather than in template.
Template to be used for the generation of WorkloadEntry resources that belong to this WorkloadGroup.
Please note that address and labels fields should not be set in the template, and an empty serviceAccount
should default to default. The workload identities (mTLS certificates) will be bootstrapped using the
specified service account’s token. Workload entries in this group will be in the same namespace as the
workload group, and inherit the labels and annotations from the above metadata field.
ReadinessProbe describes the configuration the user must provide for healthchecking on their workload.
This configuration mirrors K8S in both syntax and logic for the most part.
No
ReadinessProbe
Field
Type
Description
Required
initialDelaySeconds
int32
Number of seconds after the container has started before readiness probes are initiated.
No
timeoutSeconds
int32
Number of seconds after which the probe times out.
Defaults to 1 second. Minimum value is 1 second.
No
periodSeconds
int32
How often (in seconds) to perform the probe.
Default to 10 seconds. Minimum value is 1 second.
No
successThreshold
int32
Minimum consecutive successes for the probe to be considered successful after having failed.
Defaults to 1 second.
No
failureThreshold
int32
Minimum consecutive failures for the probe to be considered failed after having succeeded.
Defaults to 3 seconds.