Kiali 可观测性集成

摘要：本文面向负责网格可观测性的 SRE。解释 Kiali 的架构、它依赖哪些数据源、如何部署到生产，以及怎样用它定位拓扑异常、配置错误与 mTLS 失效。覆盖版本 Istio 1.31，Kiali 通过 Helm 或 Istio addons 安装。

背景：mesh 默认就“可观测”，但缺一个大脑

Istio 数据面（Envoy）为每个请求自动产出指标、访问日志与 trace span，但原始数据散落在 Prometheus、Jaeger/Tempo、Grafana 中。Kiali 的角色是聚合这些源 + 读取 Istio 配置，把“指标 + 拓扑 + 配置正确性”统一成一个交互式界面，让 SRE 一眼看清：

• 服务是怎么连的（拓扑图，带流量、错误率、延迟）；
• 哪些 Istio 资源配置错了（校验）；
• 哪条链路没走 mTLS（锁图标）；
• 某个服务的健康度与黄金指标。

架构与依赖

硬依赖与可选组件

• Prometheus 是硬依赖：Kiali 的拓扑、指标、健康计算、问题发现都依赖它，且假定数据 schema 遵循 Istio Telemetry 约定。没有 Prometheus，Kiali 多数功能不可用。
• Jaeger/Tempo（可选）：提供分布式追踪 tab 与图上的追踪集成。
• Grafana（可选）：指标页提供跳转到 Grafana 的同指标链接。
• Istio 是前提：Kiali 依赖 Istio 存在，无法独立工作。

生产部署方式

方式一：Istio addons（评估/非生产）

# Istio 1.31 发行包 samples/addons 含 kiali/prometheus/grafana/jaeger
for ADDON in prometheus grafana jaeger kiali; do
  kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.31/samples/addons/$ADDON.yaml
done
kubectl rollout status deployment/kiali -n istio-system

方式二：Helm（生产推荐，控制更强）

helm repo add kiali https://kiali.org/helm-charts
helm repo update
cat > kiali-values.yaml <<'EOF'
auth:
  strategy: "token"        # 生产用 token / OIDC，禁用 anonymous
deployment:
  resources:
    requests:
      cpu: "100m"
      memory: "256Mi"
    limits:
      cpu: "500m"
      memory: "512Mi"
external_services:
  prometheus:
    url: "http://prometheus.istio-system:9090"
  tracing:
    enabled: true
    provider: jaeger
    internal_url: "http://jaeger-query.istio-system:16686"
EOF
helm install kiali-server kiali/kiali-server -n istio-system --values kiali-values.yaml

生产危险

addons 中的 Kiali 默认 auth.strategy: anonymous，任何人可访问。生产必须通过 Helm 设 token / OIDC，并用 Ingress + TLS 暴露，禁止匿名公网可达。

核心能力

视图	用途
Graph	近实时交互式拓扑，显示请求率、错误率、延迟、熔断状态；边上有 mTLS 锁图标
Applications / Workloads / Services	按应用/工作负载/服务分组查看健康与配置
Istio Config	校验 VirtualService、DestinationRule、Gateway、PeerAuthentication 等配置
Metrics	预置指标面板，可跳转 Grafana
Tracing	集成 Jaeger/Tempo，从拓扑直接下钻 trace
Validations	检测悬空 host、冲突端口、匹配为空的策略等常见错误

生产实践：用 Kiali 定位三类问题

1. 发现明文连接（mTLS 失效）

在 Graph 视图过滤命名空间，观察边上的锁图标：

• 闭合锁 = mTLS 已启用；
• 开放/红色锁 = 该连接绕过 mTLS。

出现开放锁通常意味着：某端 Pod 未注入 Sidecar，或存在 DestinationRule 错误地覆盖了 mTLS 模式。结合 istioctl authn tls-check 复核。

2. 发现配置错误（Validations）

Kiali 的 Istio Config 页会标红错误，例如：

• VirtualService 引用的 host 无对应 Service；
• DestinationRule 的 subset 与任何 Pod 标签都不匹配；
• 多个 Gateway 绑定同一端口冲突。

3. 定位高错误率链路

Graph 上错误率高的边会变色，点击节点/边查看指标详情，必要时下钻到 Tracing 看具体慢 span。

验证、回滚与排障

# 端口转发访问（或经 Ingress）
kubectl port-forward svc/kiali -n istio-system 20001:20001
# 等价于：istioctl dashboard kiali

# 排障：Kiali 拿不到数据，先确认依赖
kubectl get pods -n istio-system -l 'app in (kiali,prometheus,jaeger)'
kubectl logs deploy/kiali -n istio-system | tail -50

# 确认 Kiali 能连 Prometheus（看外部服务配置）
kubectl get configmap kiali -n istio-system -o yaml | grep -A3 prometheus

常见坑

• 拓扑为空：Prometheus 无数据 → 检查 Envoy 指标是否采集、Prometheus 是否 scrape 到 istio-system 下代理；或 Kiali external_services.prometheus.url 配错。
• mTLS 图标不准：Kiali 根据遥测推断，若采样/指标缺失可能误判，以 istioctl authn tls-check 为真值。
• 多集群：Kiali 支持多主（每集群独立 istiod）与主从（remote 连主控制面）模式，跨集群视图需正确配置凭证 [版本相关]。

多集群可观测性（简述）

• 多主模式（Multi-Primary）：每集群独立 istiod，Kiali 通过各集群 SA 凭证同时监控，适合强隔离场景。
• 主从模式（Primary-Remote）：remote 集群不运行 istiod，连主控制面，Kiali 单界面统一视图，适合集中管理。

资源与成本权衡

Kiali Server 自身很轻（百毫核级），真正的成本在它依赖的 Prometheus（长周期保留指标）与 Jaeger（trace 存储）。生产应给 Prometheus 配置合理保留与分片，避免指标膨胀撑爆存储。Kiali 无状态、无需持久卷。

替代方案与权衡

• Istio 自带 Grafana 面板：Mesh/Service/Workload Dashboard 覆盖指标，但缺乏拓扑图与配置校验。
• Meshery / Octarine（历史）：同类 mesh 可视化工具，生态与 Istio 耦合度不及 Kiali。
• 自研：PromQL + 图数据库：灵活但成本高，除非有特定合规/定制需求，否则直接用 Kiali 更划算。

参考资料

• Istio 官方文档 - 可观测性 addons（Kiali）
• Kiali 官方文档 - 安装（Helm）
• Red Hat OpenShift Service Mesh - Kiali 架构说明
• OneUptime - 用 Kiali 可视化 Istio 网格
• Kindatechnical - Mesh 可观测性：Kiali 与分布式追踪