Workload Entry
WorkloadEntry
enables operators to describe the properties of a single non-Kubernetes workload such as a VM or a bare metal server as it is onboarded into the mesh. A WorkloadEntry
must be accompanied by an Istio ServiceEntry
that selects the workload through the appropriate labels and provides the service definition for a MESH_INTERNAL
service (hostnames, port properties, etc.). A ServiceEntry
object can select multiple workload entries as well as Kubernetes pods based on the label selector specified in the service entry.
When a workload connects to istiod
, the status field in the custom resource will be updated to indicate the health of the workload along with other details, similar to how Kubernetes updates the status of a pod.
The following example declares a workload entry representing a VM for the details.bookinfo.com
service. This VM has sidecar installed and bootstrapped using the details-legacy
service account. The service is exposed on port 80 to applications in the mesh. The HTTP traffic to this service is wrapped in Istio mutual TLS and sent to sidecars on VMs on target port 8080, that in turn forward it to the application on localhost on the same port.
v1alpha3 v1beta1
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
name: details-svc
spec:
# use of the service account indicates that the workload has a
# sidecar proxy bootstrapped with this service account. Pods with
# sidecars will automatically communicate with the workload using
# istio mutual TLS.
serviceAccount: details-legacy
address: 2.2.2.2
labels:
app: details-legacy
instance-id: vm1
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
name: details-svc
spec:
# use of the service account indicates that the workload has a
# sidecar proxy bootstrapped with this service account. Pods with
# sidecars will automatically communicate with the workload using
# istio mutual TLS.
serviceAccount: details-legacy
address: 2.2.2.2
labels:
app: details-legacy
instance-id: vm1
and the associated service entry
v1alpha3 v1beta1
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: details-svc
spec:
hosts:
- details.bookinfo.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
targetPort: 8080
resolution: STATIC
workloadSelector:
labels:
app: details-legacy
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: details-svc
spec:
hosts:
- details.bookinfo.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
targetPort: 8080
resolution: STATIC
workloadSelector:
labels:
app: details-legacy
The following example declares the same VM workload using its fully qualified DNS name. The service entry’s resolution mode should be changed to DNS to indicate that the client-side sidecars should dynamically resolve the DNS name at runtime before forwarding the request.
v1alpha3 v1beta1
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
name: details-svc
spec:
# use of the service account indicates that the workload has a
# sidecar proxy bootstrapped with this service account. Pods with
# sidecars will automatically communicate with the workload using
# istio mutual TLS.
serviceAccount: details-legacy
address: vm1.vpc01.corp.net
labels:
app: details-legacy
instance-id: vm1
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
name: details-svc
spec:
# use of the service account indicates that the workload has a
# sidecar proxy bootstrapped with this service account. Pods with
# sidecars will automatically communicate with the workload using
# istio mutual TLS.
serviceAccount: details-legacy
address: vm1.vpc01.corp.net
labels:
app: details-legacy
instance-id: vm1
and the associated service entry
v1alpha3 v1beta1
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: details-svc
spec:
hosts:
- details.bookinfo.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
targetPort: 8080
resolution: DNS
workloadSelector:
labels:
app: details-legacy
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: details-svc
spec:
hosts:
- details.bookinfo.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
targetPort: 8080
resolution: DNS
workloadSelector:
labels:
app: details-legacy
WorkloadEntry
WorkloadEntry enables specifying the properties of a single non-Kubernetes workload such a VM or a bare metal services that can be referred to by service entries.
Field | Type | Description | Required |
---|---|---|---|
address | string | Address associated with the network endpoint without the port. Domain names can be used if and only if the resolution is set to DNS, and must be fully-qualified without wildcards. Use the form unix:///absolute/path/to/socket for Unix domain socket endpoints. | Yes |
ports | map<string, uint32> | Set of ports associated with the endpoint. If the port map is specified, it must be a map of servicePortName to this endpoint’s port, such that traffic to the service port will be forwarded to the endpoint port that maps to the service’s portName. If omitted, and the targetPort is specified as part of the service’s port specification, traffic to the service port will be forwarded to one of the endpoints on the specified NOTE 1: Do not use for NOTE 2: endpoint port map takes precedence over targetPort. | No |
labels | map<string, string> | One or more labels associated with the endpoint. | No |
network | string | Network enables Istio to group endpoints resident in the same L3 domain/network. All endpoints in the same network are assumed to be directly reachable from one another. When endpoints in different networks cannot reach each other directly, an Istio Gateway can be used to establish connectivity (usually using the | No |
locality | string | The locality associated with the endpoint. A locality corresponds to a failure domain (e.g., country/region/zone). Arbitrary failure domain hierarchies can be represented by separating each encapsulating failure domain by /. For example, the locality of an an endpoint in US, in US-East-1 region, within availability zone az-1, in data center rack r11 can be represented as us/us-east-1/az-1/r11. Istio will configure the sidecar to route to endpoints within the same locality as the sidecar. If none of the endpoints in the locality are available, endpoints parent locality (but within the same network ID) will be chosen. For example, if there are two endpoints in same network (networkID “n1”), say e1 with locality us/us-east-1/az-1/r11 and e2 with locality us/us-east-1/az-2/r12, a sidecar from us/us-east-1/az-1/r11 locality will prefer e1 from the same locality over e2 from a different locality. Endpoint e2 could be the IP associated with a gateway (that bridges networks n1 and n2), or the IP associated with a standard service endpoint. | No |
weight | uint32 | The load balancing weight associated with the endpoint. Endpoints with higher weights will receive proportionally higher traffic. | No |
serviceAccount | string | The service account associated with the workload if a sidecar is present in the workload. The service account must be present in the same namespace as the configuration ( WorkloadEntry or a ServiceEntry) | No |