Demo 2 Service Entries

In this lesson we demonstrate how to use an Istio ServiceEntry to register an external workload with the mesh (by static IP) and then route mesh traffic to that external endpoint using a VirtualService. This pattern is useful when you must bring externally-resolved services into the mesh without changing an outbound registry-only policy. It matches a common scenario in the Prep Course - Istio Certified Associate (ICA) Certification.

What you’ll accomplish

Register an external host (myapp.com) and a static endpoint with a ServiceEntry.
Configure a VirtualService so the mesh routes HTTP traffic to that external endpoint.
Verify traffic is intercepted by the Istio sidecar and routed correctly.

Prerequisites / quick checks

Istio is already installed and running.
An external NGINX server is reachable at myapp.com. In this lab environment this hostname is mapped to a local IP via /etc/hosts.

Recommended verification commands:

kubectl get pods -A
istioctl version

Confirm the external web app is resolvable and responding from the control-plane host:

curl myapp.com

A successful response will look like the NGINX welcome page (truncated):

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and working.</p>
...
</html>

Verify the /etc/hosts mapping:

cat /etc/hosts

Example entry:

192.168.121.2 myapp.com

Why use a ServiceEntry?

A ServiceEntry tells Istio how to resolve and route traffic for hosts that are outside the mesh. Use MESH_EXTERNAL for workloads outside the cluster and resolution: STATIC when you want to bind a fixed IP endpoint to a hostname.

We use MESH_EXTERNAL because the workload is outside the mesh. Use resolution: STATIC for fixed IPs; use resolution: DNS for externally resolved hostnames.

1) Create a ServiceEntry

Create a file named se.yaml. Replace the address value with the IP you observed from /etc/hosts.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: myapp-service-entry
spec:
  hosts:
    - myapp.com
  location: MESH_EXTERNAL
  ports:
    - number: 80
      name: http
      protocol: HTTP
  resolution: STATIC
  endpoints:
    - address: 192.168.121.2

Apply and verify the ServiceEntry:

kubectl apply -f se.yaml
kubectl get serviceentries.networking.istio.io

Expected output:

NAME                   HOSTS               LOCATION       RESOLUTION   AGE
myapp-service-entry    ["myapp.com"]       MESH_EXTERNAL  STATIC       30s

2) Run a test pod and try to curl

Start a simple test pod. The nginx image often includes curl; if not, use a curl-specific image (e.g., curlimages/curl).

kubectl run test --image=nginx --restart=Never
kubectl get pods

Exec into the pod and attempt to curl the host:

kubectl exec test -- curl myapp.com -s -S

You might see a redirect or unexpected HTML (e.g., 302 Found). This indicates the ServiceEntry is present but Istio is not yet performing HTTP routing for the host — a VirtualService is required.

3) Create a VirtualService

Create vs.yaml to capture HTTP traffic for myapp.com and forward it to the destination that matches the ServiceEntry.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
    - myapp.com
  http:
    - route:
        - destination:
            host: myapp.com
            port:
              number: 80

Apply and check the VirtualService:

kubectl apply -f vs.yaml
kubectl get virtualservices

Expected output:

NAME       GATEWAYS  HOSTS           AGE
myapp-vs             ["myapp.com"]   4s

4) Re-test from the test pod

Try curling again from the test pod:

kubectl exec test -- curl myapp.com -s -S

If the response is still incorrect, confirm whether the test pod has an Istio sidecar. Istio must intercept the pod’s traffic for the ServiceEntry + VirtualService routing to work. Check pod readiness and namespace labels:

kubectl get pods
kubectl get ns --show-labels

Run istioctl analyze for hints:

istioctl analyze

Sample analyzer message when namespace injection is disabled:

Info [IST0102] (Namespace default) The namespace is not enabled for Istio injection. Run 'kubectl label namespace default istio-injection=enabled' to enable it, or 'kubectl label namespace default istio-injection=disabled' to explicitly mark it as not needing injection.

5) Enable automatic sidecar injection and recreate the test pod

Label the namespace for injection so new pods receive the Envoy sidecar. Then recreate the test pod.

kubectl label namespace default istio-injection=enabled
kubectl delete pod test
kubectl run test --image=nginx --restart=Never
kubectl get pods

The test pod should now show 2/2 (application container + sidecar):

NAME   READY   STATUS    RESTARTS   AGE
test   2/2     Running   0          30s

Final curl — success

From the injected test pod, curl the external host again:

kubectl exec test -- curl myapp.com -s -S

You should now receive the expected NGINX default page served from the externally-registered endpoint. This confirms the mesh intercepted the traffic, the VirtualService matched and routed it to the ServiceEntry endpoint.

Summary / Key takeaways

ServiceEntry registers external hosts and endpoints with the mesh.
VirtualService captures and routes HTTP traffic for hosts — including external hosts defined by ServiceEntry.
Pods must have the Istio sidecar (injected) for the mesh to intercept and route their traffic.
Label namespaces for automatic injection before creating pods that need to be part of the mesh.

Quick reference table

Resource Type	Purpose	Example
ServiceEntry	Register external host and endpoints with the mesh	See `se.yaml` above
VirtualService	Capture and route HTTP traffic for a host to a destination	See `vs.yaml` above
Namespace label	Enable automatic sidecar injection for new pods	`kubectl label namespace default istio-injection=enabled`

Links and references

Give this a try in the labs to get hands-on experience bringing external workloads into the mesh.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Demo 2 Service Entries

What you’ll accomplish

Prerequisites / quick checks

Why use a ServiceEntry?

1) Create a ServiceEntry

2) Run a test pod and try to curl

3) Create a VirtualService

4) Re-test from the test pod

5) Enable automatic sidecar injection and recreate the test pod

Final curl — success

Summary / Key takeaways

Quick reference table

Links and references

Watch Video

Practice Lab

​What you’ll accomplish

​Prerequisites / quick checks

​Why use a ServiceEntry?

​1) Create a ServiceEntry

​2) Run a test pod and try to curl

​3) Create a VirtualService

​4) Re-test from the test pod

​5) Enable automatic sidecar injection and recreate the test pod

​Final curl — success

​Summary / Key takeaways

​Quick reference table

​Links and references

Watch Video

Practice Lab

What you’ll accomplish

Prerequisites / quick checks

Why use a ServiceEntry?

1) Create a ServiceEntry

2) Run a test pod and try to curl

3) Create a VirtualService

4) Re-test from the test pod

5) Enable automatic sidecar injection and recreate the test pod

Final curl — success

Summary / Key takeaways

Quick reference table

Links and references