> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Virtual Services
> Explains Istio VirtualService L7 routing in Kubernetes, demonstrating HTTP path matching, rewrites, traffic splitting, fault injection, mirroring, and interaction with DestinationRule and Envoy
VirtualServices are a core Istio resource that provide L7 (HTTP/gRPC) routing for services running in Kubernetes. They let you define fine-grained routing rules—based on hostnames, paths, headers, or query parameters—and steer requests to specific service versions, enable canary rollouts, mirror traffic, inject faults, and more.
A helpful analogy is a university assignment system. Different courses (literature, mathematics, geography, etc.) are taught by different instructors. Students follow a curriculum and need a system that assigns them to the correct classes at the correct times. In this analogy:
* Students = incoming network traffic
* Courses/classes = Kubernetes Services / pods
* VirtualService = the assignment/routing system that decides where each student (request) goes
Traffic arrives at your cluster and a VirtualService defines how that traffic should be routed to Kubernetes Services and the pods behind them. Below is a minimal example Kubernetes workload to demonstrate routing with a VirtualService: a Deployment (1 replica) in the `frontend` namespace running image `app:1.1`, and a corresponding Service to expose it.
```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
namespace: frontend
spec:
replicas: 1
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: app:1.1
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: app-svc
namespace: frontend
spec:
ports:
- port: 80
name: http
targetPort: 80
selector:
app: app
```
Note: the label selector is `app: app` (label key `app` with value `app`) — this is valid for the example but in production you may prefer more descriptive labels.
Minimal VirtualService
Below is a minimal VirtualService that forwards all HTTP traffic for the `app-svc` host to the Kubernetes Service endpoint.
```yaml theme={null}
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: app-vs
namespace: frontend
spec:
hosts:
- app-svc
http:
- match:
- uri:
prefix: /
route:
- destination:
host: app-svc.frontend.svc.cluster.local
port:
number: 80
```
Path matching and rewrites
You can extend VirtualServices with multiple HTTP match rules and rewrites. In the example below, requests to `/login` are rewritten to `/` before being routed to the service, while all other paths match the root prefix.
```yaml theme={null}
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: app-vs
namespace: frontend
spec:
hosts:
- app-svc
http:
- match:
- uri:
prefix: /login
rewrite:
uri: /
route:
- destination:
host: app-svc.frontend.svc.cluster.local
port:
number: 80
- match:
- uri:
prefix: /
route:
- destination:
host: app-svc.frontend.svc.cluster.local
port:
number: 80
```
This demonstrates multiple HTTP match blocks within one VirtualService, each with its own rewrite or routing behavior.
Why use a VirtualService?
A Kubernetes Service performs L4 load balancing and service discovery. VirtualServices add L7 capabilities that are required for advanced traffic management:
* Fine‑grained routing based on HTTP headers, paths, or query parameters
* Traffic splitting between versions for canary or staged rollouts
* A/B testing and blue/green deployments
* Traffic mirroring to duplicate live traffic to a test service
Beyond routing: resiliency, mirroring, and load-balancing
VirtualServices also let you simulate faults (delay or abort), configure retries and timeouts, and mirror traffic for testing. Load‑balancing algorithms (e.g., `LEAST_CONN`, `ROUND_ROBIN`) and connection-pool settings are configured in a DestinationRule that complements a VirtualService.
VirtualServices are enforced by the [Envoy sidecar proxy](https://www.envoyproxy.io/docs/envoy/latest/). If the namespace does not have Istio sidecar injection enabled (i.e., no Envoy sidecars are present), the VirtualService configuration will not take effect.
Quick reference: L4 vs L7 responsibilities
| Layer | Kubernetes Service | Istio VirtualService |
| ------------------------ | --------------------------------- | ---------------------------------------------------------------------------------- |
| OSI Layer | L4 (TCP/UDP) | L7 (HTTP/gRPC) |
| Typical responsibilities | Load balancing, service discovery | Path/header-based routing, rewrites, mirroring, fault injection, traffic splitting |
| Configured via | `Service` resource | `VirtualService` (plus `DestinationRule` for policies) |
| Example use | expose pods on port 80 | route `/v1` to subset A and `/v2` to subset B |
Additional important notes
* Most Istio traffic-management features (mirroring, rewrites, fault injection, retries) require a VirtualService for request-level routing.
* Policies like load‑balancing algorithms and connection pool settings live in DestinationRules, which are applied alongside VirtualServices and Envoy configuration.
* VirtualServices operate at the HTTP/gRPC level (L7) and rely on Envoy sidecars to implement configured behaviors.
Many exam and production scenarios require VirtualServices. Review the [Istio Traffic Management documentation](https://istio.io/latest/docs/tasks/traffic-management/) to practice routing, HTTP match conditions, rewrites, mirroring, fault injection, and retries before applying them in real environments.
Links and references
* [Istio Traffic Management tasks](https://istio.io/latest/docs/tasks/traffic-management/)
* [Istio Documentation](https://istio.io/latest/docs/)
* [Envoy Proxy documentation](https://www.envoyproxy.io/docs/envoy/latest/)
Next steps
Try these VirtualService examples hands‑on: create the Deployment and Service, apply the VirtualService manifests, and observe traffic behavior. Experiment with path matches, rewrites, traffic splitting, and DestinationRules to see how L7 routing and policies change request flows.