Demo Virtual Services

In this demo we configure a simple Istio VirtualService for an httpbin sample app. VirtualServices are a core Istio resource — they control how requests are routed within the mesh and are required by many other features (gateways, retries, rewrites, etc.). This walkthrough covers:

Verifying Istio injection
Deploying httpbin
Creating a test pod in a separate namespace
Creating and applying a VirtualService
Demonstrating how namespace injection affects routing
URL rewrites
Quick reference of common VirtualService features

1. Verify Istio injection in namespaces

Check namespace labels to see whether istio-injection is enabled:

kubectl get ns --show-labels

Example output:

NAME              STATUS   AGE   LABELS
default           Active   15m   istio-injection=enabled,kubernetes.io/metadata.name=default
istio-system      Active   12m   kubernetes.io/metadata.name=istio-system
kube-node-lease   Active   15m   kubernetes.io/metadata.name=kube-node-lease
kube-public       Active   15m   kubernetes.io/metadata.name=kube-public
kube-system       Active   15m   kubernetes.io/metadata.name=kube-system

2. Deploy the httpbin sample app

Deploy the httpbin sample from the Istio repository:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/httpbin/httpbin.yaml

Confirm the httpbin pod is running and has a sidecar (2/2 ready):

kubectl get pods

Example:

NAME                        READY   STATUS    RESTARTS   AGE
httpbin-787cdcc9df-h5q2     2/2     Running   0          7s

3. Create a separate namespace and a test pod

Create a test namespace and run a simple nginx pod there:

kubectl create ns test
kubectl run test --image=nginx -n test
kubectl get pods -n test

Example pod status (without injection):

NAME   READY   STATUS    RESTARTS   AGE
test   1/1     Running   0          5s

A 1/1 READY means the Istio sidecar is not injected into this pod. We’ll use this to demonstrate how VirtualService behavior depends on sidecar injection.

4. Test connectivity from the non-injected test pod

Exec into the test pod and curl the httpbin service in the default namespace:

kubectl exec -ti -n test test -- /bin/bash
# inside container
curl httpbin.default.svc:8000/ip
curl httpbin.default.svc:8000/user-agent
exit

Example responses:

{
  "origin": "127.0.0.6:49657"
}

{
  "user-agent": "curl/7.88.1"
}

Note: By default Istio is permissive — services can communicate across namespaces unless you enable stricter mTLS policies or other restrictions.

If a pod’s namespace is not labeled for istio-injection, its traffic does not traverse the Envoy sidecar. VirtualService rules apply only when traffic routes through the sidecar.

5. Create the first VirtualService

Create vs.yaml defining a VirtualService that routes httpbin traffic to the httpbin service on port 8000:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  hosts:
    - httpbin
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: httpbin.default.svc.cluster.local
            port:
              number: 8000

Apply it:

kubectl apply -f vs.yaml
kubectl get virtualservice

Example:

NAME     GATEWAYS   HOSTS    AGE
httpbin  ["httpbin"]  10m

This VirtualService mirrors the existing Kubernetes service behavior (no changes yet), so requests routed through an Envoy sidecar will hit the service as before.

6. Break the VirtualService (for demonstration)

Edit the VirtualService and change the destination port to 9000 to intentionally misroute requests:

# modified vs.yaml - destination port changed to 9000
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  hosts:
    - httpbin
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: httpbin.default.svc.cluster.local
            port:
              number: 9000

Apply the modified VirtualService:

kubectl apply -f vs.yaml

If you curl from the test pod now you may still see it working — why?

If the test pod’s namespace is not Istio-injection-enabled (1/1 Ready), its traffic bypasses Envoy and the VirtualService has no effect. The traffic goes directly to the Kubernetes service which listens on port 8000, so the request succeeds.
Once the test namespace has injection enabled and the pod is re-created with the sidecar (2/2), the VirtualService will intercept the traffic and route it to port 9000 — which the service is not listening on — resulting in a 503 Service Unavailable.

7. Enable Istio injection for the test namespace and re-create the pod

You can use istioctl analyze to get hints and then label the namespace:

istioctl analyze -n test
kubectl label namespace test istio-injection=enabled

After labeling, delete the test pod so it gets re-created with a sidecar:

kubectl delete pod -n test test
kubectl run test --image=nginx -n test
kubectl get pods -n test

You should now see 2/2:

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

Now exec into the pod and curl the httpbin service:

kubectl exec -ti -n test test -- /bin/bash
curl httpbin.default.svc:8000/ip
curl httpbin.default.svc:8000/user-agent
curl -I httpbin.default.svc:8000/ip
exit

With the VirtualService pointing to port 9000 you will see a 503 Service Unavailable. Fix the VirtualService back to port 8000 and apply:

# restore vs.yaml to port 8000 then:
kubectl apply -f vs.yaml

Requests should succeed again.

When you enable istio-injection=enabled on a namespace, existing pods must be re-created (deleted) to get the Envoy sidecar injected. Labeling alone is not sufficient — restart the pods.

8. URL rewrites with VirtualService

You can add a rewrite rule in the VirtualService. Example: rewrite /hello to / and route to httpbin:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  hosts:
    - httpbin
  http:
    - match:
        - uri:
            prefix: /hello
      rewrite:
        uri: /
      route:
        - destination:
            host: httpbin.default.svc.cluster.local
            port:
              number: 8000
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: httpbin.default.svc.cluster.local
            port:
              number: 8000

Test steps:

Before applying the rewrite, curl httpbin.default.svc:8000/hello returns 404 page not found (no /hello endpoint).
Apply the VirtualService with the rewrite:
kubectl apply -f vs.yaml
After applying, curl httpbin.default.svc:8000/hello returns the root endpoint as if you requested /.

This shows how VirtualService can transform request URIs before routing to the service.

9. Quick reference: common VirtualService capabilities

The following table summarizes common VirtualService patterns and short YAML samples.

Feature	Use case	Example snippet
Basic routing	Route traffic to a specific host/port	See the `httpbin` VirtualService above
Rewrite	Rewrite request URI before routing	`rewrite: { uri: "/" }` in HTTP route
Redirect	Send client-side redirect to another path/authority	`redirect: { uri: "/v1/bookRatings", authority: newRatings.default.svc.cluster.local }`
Header match	Match requests by header value	`match: - headers: end-user: exact: jason`
Timeout	Set per-route timeout	`timeout: 5s` inside an http route
Retries	Configure retry attempts and per-try timeout	`retries: { attempts: 3, perTryTimeout: 2s, retryOn: "gateway-error,connect-failure,refused-stream" }`

Representative YAML examples:

DestinationRule with subsets:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-destination
  namespace: foo
spec:
  host: reviews # interpreted as reviews.foo.svc.cluster.local
  subsets:
  - name: v1
  - name: v2

VirtualService with a timeout:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: my-productpage-rule
  namespace: istio-system
spec:
  hosts:
    - productpage.prod.svc.cluster.local
  http:
    - timeout: 5s
      route:
        - destination:
            host: productpage.prod.svc.cluster.local

ServiceEntry for external hosts:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-wikipedia
spec:
  hosts:
    - wikipedia.org
  location: MESH_EXTERNAL

VirtualService with header-based match and URI prefix:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
    - ratings.prod.svc.cluster.local
  http:
    - match:
        - headers:
            end-user:
              exact: jason
          uri:
            prefix: "/ratings/v2/"
            ignoreUriCase: true
      route:
        - destination:
            host: ratings.prod.svc.cluster.local

VirtualService with retries:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
    - ratings.prod.svc.cluster.local
  http:
    - route:
        - destination:
            host: ratings.prod.svc.cluster.local
            subset: v1
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: gateway-error,connect-failure,refused-stream

10. Final notes & references

VirtualServices are foundational: you will use them extensively together with DestinationRules, Gateways, and Policies.
In exam / production scenarios, copy the YAML snippets from the official docs and adapt them — you are expected to reference documentation rather than memorize every field.
Always ensure the namespace/pod you are testing from is injection-enabled if you want VirtualService rules to be enforced by the Envoy sidecar.

Useful links:

Istio Documentation: https://istio.io/latest/docs/
Kubernetes: https://kubernetes.io/docs/
istioctl analyze: https://istio.io/latest/docs/ops/diagnostic-tools/istioctl-analyze/

This concludes the VirtualService demo. Next up: DestinationRules and advanced traffic management.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Demo Virtual Services

1. Verify Istio injection in namespaces

2. Deploy the httpbin sample app

3. Create a separate namespace and a test pod

4. Test connectivity from the non-injected test pod

5. Create the first VirtualService

6. Break the VirtualService (for demonstration)

7. Enable Istio injection for the test namespace and re-create the pod

8. URL rewrites with VirtualService

9. Quick reference: common VirtualService capabilities

10. Final notes & references

Watch Video

Practice Lab

​1. Verify Istio injection in namespaces

​2. Deploy the httpbin sample app

​3. Create a separate namespace and a test pod

​4. Test connectivity from the non-injected test pod

​5. Create the first VirtualService

​6. Break the VirtualService (for demonstration)

​7. Enable Istio injection for the test namespace and re-create the pod

​8. URL rewrites with VirtualService

​9. Quick reference: common VirtualService capabilities

​10. Final notes & references

Watch Video

Practice Lab

1. Verify Istio injection in namespaces

2. Deploy the httpbin sample app

3. Create a separate namespace and a test pod

4. Test connectivity from the non-injected test pod

5. Create the first VirtualService

6. Break the VirtualService (for demonstration)

7. Enable Istio injection for the test namespace and re-create the pod

8. URL rewrites with VirtualService

9. Quick reference: common VirtualService capabilities

10. Final notes & references