Introduction

An Istio VirtualService does not replace a normal Kubernetes Service. The Kubernetes Service still provides the stable network identity and endpoint selection, while the Istio VirtualService adds layer-7 routing rules such as path-based routing, header-based routing, retries, and traffic splitting on top of that service identity.

What a Kubernetes Service Still Does

A normal Kubernetes Service gives you:

• a stable DNS name
• a stable virtual IP
• selection of backend pods through labels

For example:

1apiVersion: v1
2kind: Service
3metadata:
4  name: reviews
5spec:
6  selector:
7    app: reviews
8  ports:
9    - port: 80
10      targetPort: 8080

This service is what makes reviews.default.svc.cluster.local resolve inside the cluster. Without the service, there is no stable destination identity for clients to call.

So even in Istio, the Kubernetes Service is still the foundation.

What a VirtualService Adds

A VirtualService tells Istio how to route requests addressed to a host. It can route by path, header, method, or weight.

Example:

1apiVersion: networking.istio.io/v1beta1
2kind: VirtualService
3metadata:
4  name: reviews
5spec:
6  hosts:
7    - reviews
8  http:
9    - route:
10        - destination:
11            host: reviews
12            subset: v1
13          weight: 90
14        - destination:
15            host: reviews
16            subset: v2
17          weight: 10

This does not create the service itself. It changes how Istio proxies route traffic for the host reviews.

That is the key relationship:

• Kubernetes Service defines reachability
• Istio VirtualService defines advanced routing behavior

Where DestinationRule Fits In

When a VirtualService routes to subsets such as v1 and v2, those subsets are usually defined by a DestinationRule.

1apiVersion: networking.istio.io/v1beta1
2kind: DestinationRule
3metadata:
4  name: reviews
5spec:
6  host: reviews
7  subsets:
8    - name: v1
9      labels:
10        version: v1
11    - name: v2
12      labels:
13        version: v2

Now the full picture is:

• 'Service gives the stable destination name'
• 'DestinationRule defines subsets and traffic policies'
• 'VirtualService decides which traffic goes to which subset'

This separation is what makes Istio routing flexible.

Why the Service Is Still Necessary

People sometimes think the VirtualService replaces the Service because both mention a host name. But the VirtualService is not a substitute service registry entry. It is a routing policy object consumed by the sidecars or gateways.

If you delete the Kubernetes Service and leave only the VirtualService, you lose the normal service identity and endpoint backing that the mesh depends on.

That is why the relationship is additive, not replacement.

Gateway Versus In-Cluster Traffic

The same pattern applies whether traffic comes from inside the mesh or through an ingress gateway. A VirtualService can attach to a gateway and still route to a Kubernetes service host.

In other words, the VirtualService can control both:

• internal mesh traffic
• external gateway traffic

But the actual backend destination usually still maps to a Kubernetes service.

A Good Mental Model

Think of the Kubernetes Service as the stable destination object and the Istio VirtualService as the policy that tells the mesh what to do with requests for that destination.

If all you need is plain service discovery, a normal Service is enough. If you need canary rollout, traffic shifting, retries, or header-based routing, add Istio routing resources on top.

Common Pitfalls

• Assuming a VirtualService replaces a Kubernetes Service leads to broken mental models about how endpoint discovery actually works.
• Defining subset routes in a VirtualService without a matching DestinationRule leaves Istio without the subset definitions you intended.
• Using the wrong host value in the VirtualService can make the routing rule apply to a different service name than expected.
• Treating Kubernetes Service load balancing and Istio layer-7 routing as the same feature hides where traffic behavior is really being controlled.
• Debugging pod labels before confirming the base Service resolves and selects endpoints can waste time when the problem is the routing policy host or subset configuration.

Summary

• A Kubernetes Service and an Istio VirtualService have different jobs.
• The Service provides stable naming and endpoint reachability.
• The VirtualService adds advanced layer-7 routing rules on top of that destination.
• 'DestinationRule usually defines the subsets that VirtualService routes to.'
• In Istio, the VirtualService extends the normal service model rather than replacing it.