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.

apiVersion: networking.istio.io/v1
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

apiVersion: networking.istio.io/v1
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.

apiVersion: networking.istio.io/v1
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

apiVersion: networking.istio.io/v1
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

The following example declares a VM workload without an address. An alternative to having istiod read from remote API servers is to write a WorkloadEntry in the local cluster that represents the Workload(s) in the remote network with the given labels. A single WorkloadEntry with weights represent the aggregate of all the actual workloads in a given remote network.

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: foo-workloads-cluster-2
spec:
  serviceAccount: foo
  network: cluster-2-network
  labels:
    app: foo

WorkloadEntry