We have two Microservices A and B. A calls B through the istio-proxy side car.
We created a Virtual service. Please see below for the yaml
After creating the virtual service, when we check the routes in pod A using this command istioctl proxy-config routes a-75768cc7bc-ghzsr -o json
, we do NOT see weighted routes
If we replace tls with http, weighted routes are added. Can we use weighted routes with tls ?
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: b
namespace: default
spec:
hosts:
- b
tls:
- match:
- port: 443
route:
- destination:
host: b
subset: v1
weight: 50
- destination:
host: b
subset: v2
weight: 50
Adding service definition
apiVersion: v1
kind: Service
metadata:
labels:
svc: b
name: b
namespace: default
spec:
clusterIP: x.x.x.x
ports:
- name: https-b
port: 443
protocol: TCP
targetPort: 8080
selector:
svc: b
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
Adding Destination rule,
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: b
namespace: default
spec:
host: b
subsets:
- labels:
version: v1
name: v1
- labels:
version: v2
name: v2
Is it possible that Service definition has port name with http-service-a
?
From VirtualService documentation, HTTP and TLS have different spec.
http
HTTP routes will be applied to platform service ports named ‘http-’/‘http2-’/‘grpc-*’, gateway ports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPS and service entry ports using HTTP/HTTP2/GRPC protocols.
tls
TLS routes will be applied to platform service ports named ‘https-’, ‘tls-’, unterminated gateway ports using HTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and service entry ports using HTTPS/TLS protocols.
Given the above difference, it could explain the different behaviour.
Which version of Istio are you using? It would be good to see K8s definitions as well.