0

我正在尝试在现有集群上启动和运行ISTIO ，并为现有微服务启用。不幸的是，我对ISTIO和Envoy的了解不足，无法充分诊断我遇到的问题。

我做了什么：

  1. 安装Istio
  2. 配置Namespace为自动注入 sidecar
  3. 重新部署了我的一个应用程序（使用 GoSwagger 的 GolangApp）

怎么了：

我的 Golang 应用程序容器出现了 crashloop 退避。这似乎是因为我的活跃度探测和就绪探测失败了。

没有收到任何准备好的 pod 的指标 | 失败的GetResourceMetric | 2019 年 9 月 24 日下午 1:41:02 | 2019 年 9 月 24 日下午 2:21:08 | 154

配置：

  1. Readiness/Liveness Probes 配置在http://0.0.0.0/health/readiness和http://0.0.0.0/health/liveness
  2. 自动注入已配置
  3. 我的网络服务正在广播http://0.0.0.0:80
  4. Istio将其身份验证配置为AUTH_MUTUAL_TLS

Istio已启动并运行，当我开始部署时，我可以看到 sidecar 已正确注入。

很明显，我错误地配置了一些东西，我推测这是Istio https的工作方式与我的 goswagger webapp 的广播。

我只是不确定如何诊断它以及可能配置错误的内容。

我应该在我的 goswagger webapp 中从Istio中提取 tls 证书吗？

甚至不知道从哪里开始。

4

1 回答 1

0

假设您通过 GCP Web 控制台（带有复选框）安装了 Istio，那么我会尝试使用“AUTH_NONE”而不是“AUTH_MUTUAL_TLS”（只是为了缩小问题所在）。

此外，如果您使用的是私有集群，请确保您的集群有足够的连接性（例如通过 Cloud NAT）来拉取容器镜像。

所有这一切都假设 Liveness 探针很好，而 Readiness 探针失败了。

以下是一些解释 Istio Auth 的链接。GCP Istio

于 2019-09-30T18:09:11.707 回答