Istioctl proxy-config routes missing a virtualservice host

1

Hello,
Istio: 1.2.0
K8s: 1.14.5

The routing to this virtualservice (prod-artifactory.myco.com) was working but after a redeploy of the deployment the route dissapeared from istio despite the virtualservice being created successfully. Now if I go in my browser envoy returns a 404.

I have a virtual service:

$ kubectl --context prod1 get vs -n artifactory
NAME                          GATEWAYS                   HOSTS                         AGE
artifactory-service           [star-cert.istio-system]   [prod-artifactory.myco.com]   44d

This returns nothing:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-5b77dd5989-n72h9 -o json | grep prod-artifactory

I tried restarting the istio-ingressgateway and istio-pilot pods but that did not help.

2

@jstockhausen

Istio: 1.2.3
K8s: 1.13

I have seen a similar issue which disappeared when I deleted and recreated my service entry and virtual service. You can try that.

I have been trying to reproduce this problem but wan’t able to do so. In my case, a cluster upgrade happened which brought up a new pilot instance and hours later started seeing 404s which didn’t go away until the service entry and virtual service were deleted and recreated.

If you can state the exact steps or provide with the sample configuration to do so, that will help.

1 Like
3

@anilcs0405

I was upgrading from k8s 1.14.1 to 1.14.5. The service that started to 404 wasn’t caught for a few days because it was a in a lower level environment. After looking at the logs it was found out that the 404s started after the upgrade.

I then restarted the ingress, pilot and citadel pods. Did not fix it. Route still wasn’t showing up.

Then when I did a kubectl apply -f with the k8s yaml file that contained the virtualservice resource I got the output virtualservice.networking.istio.io/artifactory-service configured even though that code never changed. This ended up fixing the 404s and the route started showing up.

4

@jstockhausen
Did you check if virtualservice existed before you applied it using kubectl? To me looks like virtual service was wiped out during your cluster upgrade (because it said configured)?

1 Like
5

@anilcs0405

The code snippet in my first post in this thread related to the virtualservice was from after k8s upgrade and before re-applying the virtualservice. When I made this post it was from before I fixed it via re-applying the virtualservice. So yes, it did exist. Or at least according to kubectl it did.

6

@jstockhausen
Ok, I am doing some tests today, will get back to you when I can reproduce it.

1 Like