istio: pilot failure on OpenShift: a cluster is returned without a matching service-key in /v1/registration

This example stopped working in 0.3.0. https://github.com/snowdrop/spring-boot-quickstart-istio

listeners, clusters, routes and endpoints info here - https://gist.github.com/cmoulliard/19614d3e05d64e5ddba3f699162ec241#file-gistfile1-txt-L275

For a domain “greeting-service”, the following cluster is defined:

{
            "connect_timeout_ms": 1000,
            "lb_type": "round_robin",
            "name": "out.greeting-service.demo-istio.svc.cluster.local|http",
            "service_name": "greeting-service.demo-istio.svc.cluster.local|http",
            "type": "sds"
},

However, /v1/registration does not return the matching service_key for “greeting-service.demo-istio.svc.cluster.local|http”.

The instructions for deploying the examples are here https://github.com/snowdrop/spring-boot-quickstart-istio#instructions .

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 15 (7 by maintainers)

Commits related to this issue

Most upvoted comments

No PR is required as the fault is coming from our Java enricher which was not up to date according to info that we have within the configMap. I will change it

I will create separate tickets to improve istio and get more infos (log, …) when such a situation occurs

  • The istio proxy should be monitored by kube health check and pod not started if the envoy proxy can’t call the pilot
  • Message should be logged that calling to the pilot is failing (without the need to change the logging level to debug for the proxy) -> so we should maybe use info level instead of warning by default to see such message within the log “[2017-12-13 16:20:46.508][25][info][upstream] external/envoy/source/common/upstream/cds_subscription.cc:70] cds: fetch failure: network error”
  • Watcher of istio proxy should be maybe enhanced in order to change the address of the pilot, mesh, … if configmap changes

So I’ve got this example deployed on OpenShift 3.7 using k8s Deployment not OpenShift DeploymentConfig and using the istioctl tooling, not the maven plugin Charles is using. Everything works as expected (all SDS/RDS/CDS). So i’m not seeing a bug in istio per-se. The next step is to figure out if OpenShift DeploymentConfigs or the maven tooling is setting up the Pilot agent incorrectly or where else the difference is.

@vadimeisenbergibm Instructions followed to setup istio 0.3.0 with our Spring Boot project are defined here in fact : https://github.com/snowdrop/spring-boot-quickstart-istio/blob/master/INSTALLATION.md#with-istio-03

Master branch of the example will continue to use 0.2.12 version as default value to inject the proxy