Learn Istio - Service Discovery & External Services

#Introduction

So far our mesh contains Kubernetes services. But the real world is more complicated than that: there are external APIs, legacy databases, and virtual machines that are not ready to move to containers. Episode 10 covers how Istio discovers services outside Kubernetes and how to pull them into the mesh as members with ServiceEntry, WorkloadEntry, and WorkloadGroup.

#ServiceEntry: Bringing in External Services

#NONE Resolution

NONE resolution makes Envoy forward traffic to the destination address without doing any discovery. It suits cases where the name already points to a fixed, certain address:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-direct
spec:
  hosts:
  - ext.example.com
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: NONE
  location: MESH_EXTERNAL

resolution: NONE makes Envoy skip DNS lookups — the name is forwarded directly as the connection destination. It is the simplest option, but you get no endpoint control from Istio.

#STATIC Resolution

With STATIC, the endpoint list is written directly in the ServiceEntry:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-payment
spec:
  hosts:
  - api.payment.internal
  addresses:
  - 10.99.0.10
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: STATIC
  endpoints:
  - address: 192.168.50.21
  - address: 192.168.50.22
  location: MESH_EXTERNAL

endpoints provides two backend addresses that Envoy can use for load balancing and outlier detection. addresses is optional — a virtual IP used to select this ServiceEntry.

#DNS Resolution

With DNS, Envoy queries DNS periodically:

spec:
  hosts:
  - api.payment.example.com
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL

resolution: DNS is the most common choice: the name is resolved, the IP follows the DNS answer, and the TTL is managed by Envoy. Note that here Envoy does the resolving, not the application.

#WorkloadEntry for Non-Kubernetes Endpoints

ServiceEntry connects the mesh to external services. For workloads (VMs, bare-metal) that want to become part of the mesh and be governed by its policies, use WorkloadEntry:

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: vm-legacy-1
  namespace: legacy
spec:
  address: 10.0.3.15
  labels:
    app: legacy-app
    version: v1
  serviceAccount: legacy-sa
  network: network-legacy

address is the IP of the VM that will receive traffic. The labels field is special here: these labels become workload labels that can be used for subsets in a DestinationRule, exactly like Kubernetes Pod labels.

#WorkloadGroup and Mesh Expansion

#Auto-registration with WorkloadGroup

Defining WorkloadEntries one by one does not scale. WorkloadGroup lets VMs register themselves automatically:

apiVersion: networking.istio.io/v1
kind: WorkloadGroup
metadata:
  name: vm-pool
  namespace: legacy
spec:
  template:
    serviceAccount: legacy-sa
    network: network-legacy
  metadata:
    labels:
      app: legacy-app

A VM running the Istio agent creates its own WorkloadEntry from this template when it connects. Every new VM automatically joins the mesh without manual YAML edits.

#The Mesh Expansion Process

Mesh expansion connects VMs to the control plane in a few major steps:

1. Create the namespace, ServiceAccount, and WorkloadGroup in the cluster.
2. Install Istio on the VM together with the certificate from Citadel.
3. Configure the VM to use the control plane IP and the same trust domain.
4. Verify the VM workload appears in istioctl proxy-status.

istioctl install --set values.global.meshID=mesh1
ssh vm-legacy "curl -fsSL https://istio.io/downloadIstio | sh -"
scp istio-1.22.1/tools/istioctl.bash vm-legacy:

istioctl proxy on the VM connects to istiod and processes traffic with the same rules as a sidecar in the cluster. The main difference: because the VM has no Kubernetes, its identity comes from the ServiceAccount embedded during setup.

#Summary

Episode 10 expanded the reach of the mesh: ServiceEntry with three resolution strategies, WorkloadEntry for non-Kubernetes endpoints, WorkloadGroup for auto-registration, and the mesh expansion process for bringing VMs under the same traffic and security management.

Key takeaways:

• NONE for fixed destinations; STATIC for an IP list; DNS for dynamic resolution.
• addresses distinguishes ServiceEntry selection; endpoints are the real targets.
• WorkloadEntry represents a single VM endpoint.
• WorkloadGroup lets VMs register themselves automatically.
• WorkloadEntry labels can be used for subsets like Pod labels.
• The network field matters for multi-network architectures.
• Mesh expansion makes VMs a full part of mesh policies.

In the next episode, episode 11, we enter the security phase: security basics with mTLS, authentication, and authorization — PeerAuthentication for automatic mTLS, RequestAuthentication for JWT, and AuthorizationPolicy for identity-based access control.