-
Notifications
You must be signed in to change notification settings - Fork 157
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
9d262de
commit c0502ac
Showing
1 changed file
with
70 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
--- | ||
title: "Istio 可见性与故障排查:监控控制平面的关键指标" | ||
summary: "本文介绍了 Istio 控制平面的关键监控指标,包括延迟、流量、错误和饱和度,帮助提高诊断效率。" | ||
authors: ["Ric Hincapié"] | ||
translators: ["云原生社区"] | ||
categories: ["Istio"] | ||
tags: ["Istio","可观测性","Istiod"] | ||
draft: false | ||
date: 2025-01-10T11:53:24+08:00 | ||
links: | ||
- icon: language | ||
icon_pack: fa | ||
name: 阅读英文版原文 | ||
url: https://tetrate.io/blog/istio-visibility-and-troubleshooting-key-metrics-for-monitoring-the-control-plane/ | ||
--- | ||
|
||
Istio 服务网格拥有丰富的功能,为数百家公司的 Kubernetes 环境提供了更高的安全性、敏捷性和弹性。这些功能都由一个可扩展、无状态且松耦合的组件——**Istiod** 来协调。Istiod 是 Istio 的核心软件组件,持续接收 Kubernetes API 的更新,将配置和更新传递给 sidecar,同时还充当它们的 CA 授权中心。此外,它还生成了大量的指标。 | ||
|
||
尽管 **Istiod** 在开箱即用的情况下表现优异,但如果没有适当的维护,其性能可能无法长久保持最佳状态;尤其是当网格扩展到组织内的多个团队时,其承担的责任加重,更需要小心维护。 | ||
|
||
因此,服务网格运维人员必须密切关注 **Istiod** 生成的关键指标。这些指标不仅能帮助预防问题,还能在发生问题时快速诊断是否与网格相关。因为作为一个额外的网络层,Istio 参与了数据路径的每一步操作,而你需要工具和信息来回答这样的问题:“**我遇到的问题是否与服务网格有关?**” | ||
|
||
除了控制平面,Istio 还包括一个由注入到 Pod 和网关中的 Envoy sidecar 组成的数据平面。我将在后续文章中讨论 Istio 数据平面的关键指标(敬请期待)。 | ||
|
||
## 应关注的指标:Istio 黄金指标 | ||
|
||
快速确定“**在 Istiod 中应该观察什么?**”这一问题范围的一种方法是运行以下命令: | ||
|
||
```bash | ||
$ kubectl exec -it $(kubectl get po -l app=istiod -oname) -- curl localhost:15014/metrics | grep -P '^(?!#).*?' | awk -F'{' '{print $1}' | sort | uniq | wc -l | ||
|
||
87 | ||
``` | ||
|
||
这个命令显示了超过 87 个独特指标——还不包括一些因我的集群中值为 null 而未统计的饱和度和其他特定指标。建议重点关注与**延迟、流量、错误和饱和度**相关的指标。这组指标被称为黄金指标(Golden Metrics)。 | ||
|
||
## Istio 延迟指标 | ||
|
||
**Istiod** 的延迟指的是将消息传递给 sidecar 并被其处理所需的时间。这些消息包括 Istio 自定义资源定义(CRD)配置、新 Pod 的 IP 地址、Kubernetes 服务的删除通知,以及为新创建的 sidecar 提供的启动配置批量数据等。 | ||
|
||
一个必须关注的指标是 `pilot_proxy_convergence_time_bucket`,它表明 **Istiod** 配置在 sidecar 中生效所需的时间。此指标帮助我们客户在控制平面性能问题影响应用之前进行调整。 | ||
|
||
另一个推荐的指标是 `pilot_xds_push_time_bucket`,特别是针对 EDS(端点发现服务)维度,因为此配置流负责传递 Pod IP 的变更。例如,如果一个 Pod 被删除,而其他正在运行的 sidecar 更新需要 5 秒,这将影响到对未监听的 IP: 端口发送的请求。在某些情况下,通过了解此指标,可以解决瞬时超时和尾部延迟增加的问题。 | ||
|
||
## Istio 流量指标 | ||
|
||
流量指标反映了 **Istiod** 处理的活动量。它可以用来观察服务网格用户更改配置的频率,例如添加新路由,以及集群中变更的强度(例如 Pod 和 Kubernetes 服务变更)。它提供了一个集中点,来衡量某些集群变更在服务和 Istio 配置层面的影响,并结合其他相关数据进行分析,为未来规划提供依据。 | ||
|
||
一个关键指标是 `pilot_xds_pushes`,它默认包含一个 `type` 维度,映射到 CDS、LDS、RDS 和 EDS。前三者与 Istio 配置(如虚拟服务、网关或目标规则)相关,而最后一个密切跟踪 Pod IP 或端点的变更。此指标非常重要,因为它可以帮助你了解 **Istiod** 处理的变更内容及其强度。 | ||
|
||
## Istio 错误指标 | ||
|
||
这一类指标至关重要。**Istiod** 中的任何错误都需要立即处理。虽然由于松耦合架构,即使 sidecar 与 Istiod 的连接丢失,只要没有 Pod 或 CRD 的变更,sidecar 仍然可以正常工作。 | ||
|
||
两个需要注意的指标是: | ||
|
||
1. `sidecar_injection_failure_total`:此指标跟踪 **Istiod** 的一个功能——一个在 Pod 创建时改变其规范的变异 Webhook,用于插入 Istio 的组件(如 sidecar 和 init 容器)。 | ||
2. `pilot_xds_write_timeout`:此指标表明 **Istiod** 到 sidecar 的推送未能在双方规定的时间内处理完成。 | ||
|
||
## Istio 饱和度指标 | ||
|
||
最后但同样重要的是,若未进行适当的监控,**Istiod** 可能因资源不足而引发问题。CPU 和内存分配以及水平 Pod 自动伸缩(HPA)应根据历史模式(如新应用版本发布、节点升级引发的大规模驱逐以及过去几年的流量高峰)进行监控和调整。 | ||
|
||
曾经有一位客户在发布新应用版本时流量中断,这在以前从未发生过。在生产环境中,这是一个令人困惑且意外的情况。通过检查 `container_cpu_usage_seconds_total`,我们发现控制平面 CPU 使用率过高可能导致了问题。进一步分析后,发现 HPA 的期望副本数达到了允许的最大值。通过快速调整,集群恢复到了正常状态。 | ||
|
||
**Istiod** 的指标如 `process_virtual_memory_bytes` 需要与 kube-state-metrics 结合使用,才能直观地反映当前 **Istiod** 的内存饱和情况。 | ||
|
||
## 总结 | ||
|
||
一旦你拥有适当的仪表盘来观察上述指标,并让团队理解其重要性,你将获得更高的诊断准确性和速度、更好的弹性,以及更满意的终端用户体验。 |