问题标签 [istio-kiali]

我将 Istio 与 Kiali 一起使用，我想将图形表示与其权重集成到我自己的代码中。

Istio 或 Kiali 本身是否为此目的提供 API？例如将图形导出为 JSON 对象？

我想向您寻求帮助 - 在启用 Istio 指标监控时，如何防止 Prometheus 因内存不足而被杀死？我使用 Prometheus Operator 并且对指标的监控工作正常，直到我为 Istio 创建 ServiceMonitors，取自Prune on Medium 的这篇文章。从文章来看，它们如下：

数据平面的 ServiceMonitor：

控制平面的 ServiceMonitor：

创建 Istio 数据平面的 ServiceMonitor 后，内存使用量在一分钟内从大约 10GB 增加到 30GB，并且 Prometheus 副本被 Kubernetes 杀死。CPU使用率正常。怎样才能防止资源使用量出现如此巨大的增长？重新标记有什么问题吗？它应该从大约 500 个端点抓取指标。

[编辑]

从调查看来，这对资源使用有很大影响的是重新标记。例如，如果我将 targetLabel 更改为 pod 而不是 pod_name，则资源使用量会立即增加。

无论如何，我没有找到解决这个问题的方法。我在 GithHub 上使用了 Istio 提供的半官方ServiceMonitor 和 PodMonitor，但它只是让 Prometheus 在 Out Of Memory Exception 之前运行得更久。现在，从 ~10GB 到 32GB 的内存使用大约需要一个小时。

我可以看到的是，启用 Istio 指标后，时间序列的数量增长得非常快并且永不停止，在我看来这看起来像是内存泄漏。在启用 Istio 监控之前，这个数字相当稳定。

你有什么其他的建议？

我已经完成了 Istio 1.9 的初始设置并部署了 bookInfo 应用程序以复制 Istio 站点中提供的示例以进行速率限制。正如我们在应用程序中有实现速率限制的用例一样。我将 Istio 项目作为解决方案，但在运行 Istio 官方链接本身提供的 yaml 时面临挑战。

有人可以帮帮我吗？ https://istio.io/latest/docs/tasks/policy-enforcement/rate-limit/

我已经从以下链接部署了 bookinfo 示例

特使 YAML

应用 envoy yaml 时出错：

我已经在我的 minikube 集群中部署了一个应用程序，通过http://172.18.97.73:31566/的入口网关服务可以访问应用程序。

但 kiali 图表显示未知的流量来源。

基阿里图

我不明白出了什么问题，你能帮帮我吗？

清单在这里：

我的仪表板<dashboard>.foobar.com毫无问题地暴露在外，现在我试图将上面提到的仪表板暴露给www.foobar.com/dashboard/<kiali> 我用一个简单的.net后端容器测试过这个VS设置：

然后我有： foobar.com/bla/api/hello-> dummyservice/api/hello foobar.com/bla/api/deeper/hello->dummyservice/api/deeper/hello 这很好。但是，如果我将相同的方法应用于这些仪表板，则没有任何效果！这是我对仪表板的设置：

正如有人提到的那样，有一个已知问题，/所以 你可以看到我rewrite对他们两个都有。但仍然没有任何效果。大多数人都得到了 404，grafana 将我重定向到www.foobar.com/login

以前有人做过吗？我在想这些仪表板可能包含在前端，所以它不像我的 .net 后端容器那么简单？

我在同一网络中的 2 个 GKE 集群上设置了多主 helloworld 示例。我已按照 Istio 示例页面上的所有说明进行操作，并且能够在命令行中验证跨集群流量。

但是，当我从一个集群（比如安装了 helloworld-v1 的集群）安装并打开 kiali 仪表板时，我无法打开 helloworld-v2 的工作负载详细信息（在创建流量时显示在应用程序图中），我得到以下错误

我希望可以从任一控制平面访问 v1 和 v2 工作负载。我哪里错了？我该如何调试呢？

我正在尝试使用 SAML 探索所有监控工具的 sso，我想知道 Kiali 是否支持 SAML 2.0，因为我在文档中找不到任何内容

我们使用 istio 已经有一段时间了，但最近发现了一个我们无法用异常值检测来解释的问题。我们有 50 多个微服务，并且发现其中一些“至少 2-3”流量似乎没有进行负载平衡，我们已将其追踪到异常值检测，因为一旦我们将其从目标规则中删除，负载平衡就可以正常工作。

该图像显示 1% 的流量流向以 8kh2p 结尾的 pod 我的主要问题是，即使我们可以复制问题并通过删除异常值检测来解决它，我们也没有看到任何指标显示断路器/异常值检测被绊倒了。根据这个 github 问题 - https://github.com/istio/istio/issues/8902 - 我们应该能够使用类似于

我还找到了一些特使文档，我应该可以在其中进行跟踪

这些指标似乎都没有显示任何被触发的东西。

我确实想在stackoverflow.com上指出一个类似的帖子，它似乎没有解决我们的问题

如果有人可以通过异常值检测或至少一种我们可以跟踪其被绊倒的方式来帮助找出负载平衡不正确的原因，将不胜感激。-

我们的虚拟服务看起来像

对等身份验证

Kubernetes 版本 v1.21.x

Istio 版本 1.10.x

普罗米修斯 2.28.x 版

更新

我已经更新了我们的目标规则，尝试将 Continuous5xxErrors 和 ContinuousGatewayErrors 都更改为 0，但问题仍然存在，有 2 个 Pod，一个 Pod 占用 100% 的流量，而另一个 Pod 没有负载均衡。下面的新设置

我在 Istio 服务网格上设置了 Kiali 和 Prometheus 插件。目前，我将这些服务公开为 LoadBalancer，以便我可以从本地计算机访问集群外部的这些服务。

我可以创建一个 Ingress 控制器并使用 Ingress 控制器路由到 Prometheus 和 Kiali，以便我可以使用单个 LoadBalancer 来访问两个仪表板

我有一个服务器到服务器的调用，我使用 GRPC（带有 .net core 5）它在本地工作和测试。

之后，我将所有服务移至 Kubernetes Pod（Docker 桌面），并通过流程进行了测试（使用 swagger post-call），它也在那里工作。

现在为了监控，我添加了 ISTIO 并将标签添加到我的命名空间“ istio-injection=enabled ”重新启动了我所有的 Pod，现在每个 Pod 内都有 2 个容器。

我测试了基本服务（再次大摇大摆）并且它正在工作。在测试 GRPC 调用时。呼叫方说呼叫失败

Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="upstream connect error or disconnect/reset before headers.reset reason: protocol error")

我检查了 GRPC 服务器端的日志，它对这个调用一无所知，并且服务正在运行。然后我有点认为错误来自调用方，而它无法或无法调用 GRPC 服务器。

错误详情：

再次，我删除了 Istio 并进行了测试，它再次开始工作（没有改变任何东西）我添加了 istio 并且它再次开始失败。所有其他服务都在使用 istio 但不是这个调用（这只是我有的 GRPC 调用）。