I am attempting to get ISTIO up and running on an existing cluster and enabled for existing microservices. Unfortunately I am not knowledgeable enough on ISTIO and Envoy to adequately diagnose what the issues I'm having are.
What I did:
Namespace to Auto Inject sidecarWhat is Happening:
I am getting a crashloop backoff on my Golang Application Container. This appears to be due to the fact that my liveness probes and readiness probes are failing.
did not receive metrics for any ready pods | FailedGetResourceMetric | Sep 24, 2019, 1:41:02 PM | Sep 24, 2019, 2:21:08 PM | 154
Configuration:
http://0.0.0.0/health/readiness and http://0.0.0.0/health/livenesshttp://0.0.0.0:80AUTH_MUTUAL_TLSIstio is up and running and when I start my deployment I can see the sidecar is getting properly injected.
Clearly I have misconfigured something and I speculate it is how Istio https is working vs the broadcasting of my goswagger webapp.
I'm just not sure how to diagnose it and what could be misconfigured.
Should I be pulling the tls cert from Istio in my goswagger webapp?
Not even sure where to start.
Assuming you installed Istio via the GCP web console (with the checkbox), then I would try "AUTH_NONE" instead of "AUTH_MUTUAL_TLS" (just to narrow down where the problem might be).
Also, if you are using a private cluster please ensure that your cluster have enough connectivity (via Cloud NAT for instance) to pull container images.
All of this assuming the Liveness probes are fine and the Readiness probes are the ones failing.