0

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:

  1. Installed Istio
  2. Configured Namespace to Auto Inject sidecar
  3. Redeployed One of my Applications (GolangApp Using GoSwagger)

What 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:

  1. Readiness/Liveness Probes were configured on http://0.0.0.0/health/readiness and http://0.0.0.0/health/liveness
  2. AutoInjection is configured
  3. My WebServices are broadcasting on http://0.0.0.0:80
  4. Istio is configured its auth as AUTH_MUTUAL_TLS

Istio 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.

fbraga
  • 711
  • 4
  • 9
mornindew
  • 1,993
  • 6
  • 32
  • 54

1 Answers1

0

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.

Here are some links explaining Istio Auth. GCP Istio

Frank
  • 525
  • 2
  • 8