I try to do a mirror test of my service
But I haven't configured the mirror testing config yet, but Pod b has already received the traffic. It seems that the Service distributes the traffic instead of being controlled by VirtualService ?
Here I create a sample about it
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld
spec:
hosts:
- helloworld
http:
- route:
- destination:
host: helloworld
subset: v1
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: helloworld
spec:
host: helloworld
subsets:
- name: v1
labels:
version: v1
---
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
selector:
app: helloworld
ports:
- name: http
protocol: TCP
port: 80
targetPort: 3000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
version: v1
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v1
template:
metadata:
labels:
app: helloworld
version: v1
spec:
containers:
- name: helloworld-v1
image: surprised128/nodetestserver:log
ports:
- containerPort: 3000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
version: v2
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v2
template:
metadata:
labels:
app: helloworld
version: v2
spec:
containers:
- name: helloworld-v2
image: surprised128/nodetestserver:v2
ports:
- containerPort: 3000
And I use curl to send request, then we can see the response was contain result of v1 and v2.
for i in `seq 1 100`; do curl http://helloworld.connext3.svc.cluster.local/nodejs/hello; done
Here is the istioctl test, nothing looks wrong
This Yaml is work well in istio version 1.13.0, but fail in 1.16.4, Are there any differences between versions?
Finally, I found the problem. The root cause was the pod which I using to curl target service was out of istio service mesh(means it has no istio proxy sidecar in pod)
So the request from this pod was pass by k8s service, not managed by the virtual service or destination rule.
https://istio.io/latest/docs/ops/deployment/requirements/
In order to support Istio’s traffic routing capabilities, traffic leaving a pod may be routed differently than when a sidecar is not deployed.