网格中的每个 Envoy sidecar,在处理流量的过程中,已经在生成详尽的指标和追踪数据;为使这些数据存在,不需要对你的应用添加任何东西。没有额外的组件时,缺少的是把它发送到哪里、存储在哪里、在哪里查看。本指南安装完成这些的各个部分,让网格的流量真正变得可见。

每个插件的用途

• Prometheus 抓取并存储每个 sidecar 暴露的指标:请求速率、错误率、延迟,按服务和路由划分。本资料库中专门的 Prometheus 指南深入介绍了这个工具本身;这里它具体是 Istio 自己的仪表板所查询的后端。
• Grafana 通过预置的 Istio 仪表板将这些 Prometheus 数据可视化:网格范围的流量概览、每个服务的详情、控制平面健康。
• 分布式追踪后端(Jaeger 一直是 Istio 示例插件中资格最老的选择;有些环境改用 Zipkin 或基于 OpenTelemetry 的后端)收集追踪,显示单个请求在它所触及的每个服务中的完整路径,这使你能看到多跳请求中究竟哪里发生了变慢,而不只是知道它在某处发生了。
• Kiali 是专为 Istio 构建的服务网格控制台:一个展示服务之间实际如何通信的实时拓扑图,由相同的指标和追踪数据支持,并且在某些情况下还可以直接从其 UI 检查和编辑网格配置。

安装示例插件

Istio 的发布包在 samples/addons 下包含所有这些的现成可应用清单:

cd istio-*  # the directory from installing istioctl
kubectl apply -f samples/addons
kubectl get pods -n istio-system

你应该会看到 prometheus、grafana、kiali 和一个追踪后端的 Pod 与 istiod 以及已经在 istio-system 中运行的任何网关一起启动。这些示例清单用于评估和学习,而不是作为每个工具的生产就绪部署:默认的资源限制、存储和保留期都很有限,真正的部署通常会让 Prometheus 和 Grafana 运行在它们自己专用的、规模得当的配置上,而不是依赖捆绑的示例。

访问 Kiali

默认情况下,这些插件都没有暴露在集群之外。使用 port-forward 访问 Kiali 的 UI:

kubectl port-forward svc/kiali -n istio-system 20001:20001

打开 http://localhost:20001。当有流量流经已入网的服务时,Kiali 的图视图会实时渲染:哪些服务在与哪些服务通信,按健康状况着色,并在每条连接上显示请求量和错误率。

为什么图可能看起来不对,或者是空的

如果 Kiali 的拓扑视图是空的、稀疏的,或者显示了明明应该在相互通信的断开节点,最常见的原因与上一篇指南所述相同:底层 Deployment 和 Service 缺少 app 标签。Kiali 根据该标签构建它的图;没有它的工作负载存在于网格中并且流量传输完全正常,但 Kiali 没有可靠的方式在其可视化中识别并连接它们。在断定网格本身配置错误之前,先检查这个标签。

第二常见的原因就是还没有流量:Kiali 的图反映的是在所选时间窗口内观察到的流量,所以刚入网、还没有收到任何请求的服务没有东西可显示。发送几个请求,然后刷新。

Grafana 的预置仪表板

以同样的方式 port-forward 到 Grafana:

kubectl port-forward svc/grafana -n istio-system 3000:3000

示例安装自带已经 provision 好的 Istio 专用仪表板,网格范围的流量、每个服务的详情、控制平面性能,而不需要你从头构建它们。它们是了解 Istio 暴露哪些指标以及它们如何组织的一个很好的起点;本资料库其他地方的 Grafana 指南介绍了在你走出对默认设置的探索之后,如何自定义和扩展类似的仪表板。

把示例安装视为起点,而不是终点

一旦你确认网格是可观测的,并且了解了每个工具显示什么,对于超出本地评估的任何场景,自然的下一步是用配置得当、独立管理的安装来取代捆绑的示例,很可能使用本资料库中关于 Prometheus 和 Grafana 的专门指南,而不是无限期地依赖 samples/addons。这些示例清单的存在,是为了让你快速达到”我能看到我的网格”这一步,而不是成为生产集群的长期可观测性栈。