Introduction

A Kubernetes Service and an Istio VirtualService both affect how traffic reaches workloads, but they solve different problems. A Kubernetes Service gives clients a stable network identity for a set of pods. An Istio VirtualService adds higher-level routing rules on top of that identity, such as traffic splitting, path matching, retries, and header-based routing.

What a Kubernetes Service Does

A Kubernetes Service selects pods with labels and exposes them behind a stable name and virtual IP. It solves discovery and basic load balancing.

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

With that object in place, other workloads can call http://reviews inside the cluster without caring which pod IPs are currently alive.

A Service works at the Kubernetes networking layer. It does not by itself express rules such as "send 10 percent of traffic to v2" or "route requests with header x-user: beta to a canary deployment."

What an Istio VirtualService Does

A VirtualService tells the Istio proxies how to route traffic to a destination service. It operates at the request-routing layer, not just at the endpoint-selection layer.

1apiVersion: networking.istio.io/v1
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 replace the Kubernetes Service. It tells Istio how to route requests that target the reviews service.

In a typical mesh setup, the VirtualService works together with a DestinationRule that defines the subsets:

1apiVersion: networking.istio.io/v1
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

Without the Service, clients would not have the normal Kubernetes service identity. Without the VirtualService, Istio would not know about the advanced routing policy.

Different Layers, Different Responsibilities

A practical way to think about the difference is this:

• Kubernetes Service: "Which pods back this stable service name?"
• Istio VirtualService: "Given a request to that service, how should traffic be routed?"

That distinction shows up in real features.

A Kubernetes Service gives you:

• stable DNS name
• stable virtual IP
• basic load balancing across matching pods

An Istio VirtualService gives you:

• path and header matching
• canary and blue-green traffic splitting
• retries, timeouts, and fault injection in traffic rules
• routing to different versions of the same service

Example: You Usually Need Both

Suppose you run two versions of reviews, tagged version: v1 and version: v2.

The Kubernetes Service selects all reviews pods so the service exists at one cluster DNS name. The VirtualService then tells Istio to send most traffic to v1 and a smaller percentage to v2.

That is why asking "Service or VirtualService?" is often the wrong framing. In Istio, the common answer is "both, for different reasons."

Common Pitfalls

• Expecting a Kubernetes Service to handle canary routing or header-based traffic rules by itself.
• Creating a VirtualService without understanding that the destination still refers to a real service host.
• Forgetting the matching DestinationRule when routing to subsets like v1 and v2.
• Treating Istio routing objects as a replacement for basic Kubernetes service discovery.
• Debugging only the VirtualService when the underlying Service selector is wrong and no healthy endpoints exist.

Summary

• A Kubernetes Service provides stable discovery and basic load balancing for pods.
• An Istio VirtualService adds application-level routing policy for traffic that targets that service.
• The VirtualService usually depends on a real service host and often a DestinationRule.
• Use a Service for identity and endpoint grouping.
• Use a VirtualService for canary releases, header matching, retries, and other traffic-management rules.