世界百事通!用这个开源项目,网络小白也能搞定容器网络问题排查
溪恒、谢石、遐宇 阿里云云原生 2023-06-27 18:30 发表于浙江
Kubernetes 本身比较复杂,使用门槛较高,用户在开始容器化迁移时经常遇到各种各样的问题,由于缺乏故障定位的技能和工具,用户常常产生挫败感,甚至放弃业务容器化。其中网络问题表现尤为突出,Kubernetes 网络虚拟化导致网络问题排查的难度巨大。
KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具,支持主流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了降低网络问题排查难度,让没有网络知识的人也可以自动化地定位网络问题。
(资料图片)
Kubernetes 容器网络诊断工具:
https://github.com/alibaba/kubeskoop
KubeSkoop 能够自动构建出给定源和目的地址在容器网络中的访问路径,自动化地采集和分析链路上每一个网络节点的配置,结合 eBPF 内核监控以及 IaaS 层的网络配置检查,定位出导致网络不通的根因,极大地降低了网络问题定位的时间,即使没有任何网络技能的用户也可以使用。目前在阿里云容器服务的环境中,作为自运维工具解决了大量客户在大规模 Kubernetes 集群场景下遇到的网络问题。
本文将会对容器网络和传统定位手段带来的问题进行简单的介绍,以及对 KubeSkoop 的功能设计等方面进行总体解说。
容器网络
Cloud Native
网络连通性-CNI
容器网络是 Kubernetes 集群中及其重要的一部分,包括了构成集群网络连通性的 CNI 插件、Service 服务发现机制、NetworkPolicy 网络策略等。Kubernetes 集群网络保证了每个 Pod 拥有自己独立的网络空间,并且能够与集群中的 Pod 和 Node 互相通信。
CNI 插件是构成集群容器网络中的核心,实现集群级别唯一的地址分配,将集群维度的网络打通。
不同的 CNI 插件,如 Flannel、Calico、Cilium、Terway 等,有其不同的网络实现,包括地址分配,网络虚拟化实现,网络连通性实现等。
服务发现和网络策略
除 CNI 插件外,Kubernetes 还提供了 Service 作为服务发现,以及 NetworkPolicy 作为网络策略能力。这些能力也是通过可替换的组件来实现的。
复杂性和网络问题定位
由于概念繁多,以及插件实现选择的丰富性,导致 Kubernetes 网络问题存在着相当的复杂性,包括:
逻辑概念的复杂性 Ingress/Service/NetworkPolicy 配置灵活,可能导致配置错误/规则冲突等问题。 使用 ServiceMesh 或第三方 CNI 插件,带来更复杂的网络策略和扩展能力。 数据面实现的复杂性 数据平面经过不同组件的多层处理,且存在多种实现。 协议栈链路复杂,涉及到网卡驱动 /netfilter/route/bridge 等配置。 不同云厂商的底层配置不同,安全组、路由表等配置复杂。传统的容器网络问题定位手段,主要是通过抓包定位丢包点、压测复现、人工查配置等方式。存在着定位流程长、大量时间开销、人员经验要求高等问题。
在日常的工作中,排查容器网络问题占用了相当大部分的精力。因此,我们开发了 KubeSkoop 项目,来实现针对容器网络场景下问题的自动诊断系统。
KubeSkoop 功能
Cloud Native
在我们的分析中,常见的 Kubernetes 网络问题可以分为以下两类:
网络持续不通问题 持续的无法访问:ping 不同、connect 超时、DNS 无法解析等。 网络抖动问题 偶发的网络问题:偶尔的业务超时、504、偶发 reset 等。 网络性能问题:网络性能低、QPS 压不上去等。在这些问题中,80% 都是可以依赖经验解决的已知问题。而问题的处理时间主要浪费在 问题上报、信息收集和验证上。
KubeSkoop 即是针对这两类场景,通过信息收集(包括 CNI 插件、ServiceMesh、Kernel/eBPF、基础设施等)、推导和展示(容器服务智能运维、Prometheus、Grafana/Loki 等),实现全链路一键诊断、网络栈延迟分析、网络异常事件识别回溯,快速定位问题根因。
项目可分为两部分:诊断网络持续不通问题的 KubeSkoop 连通性诊断, 和分析网络抖动问题的 KubeSkoop 深度网络监控。
连通性诊断
通过 KubeSkoop,能够对网络持续不通问题进行一键诊断。
用户通过指定网络不通的来源 IP 和目的 IP 发起一次诊断。在诊断中,KubeSkoop 将会自动构建网络访问链路,收集网络栈信息,分析链路问题。
同时,诊断包含了 Service、NetworkPolicy 等 Kubernetes 概念的分析,全面覆盖协议栈、底层 IaaS 的连通性相关检查,让用户无需了解网络插件的实现,也无需拥有复杂网络问题排查经验,就能够一键定位网络问题并自助解决。
连通性诊断目前提供了 Flannel、Calico(内部包括 Terway)网络插件插件的诊断支持,以及阿里云作为基础设施的支持。关于诊断能力的完整使用文档,可见: https://kubeskoop.io/docs/guide/diagnose/intro
深度网络监控
针对网络抖动问题,KubeSkoop 深度网络监控提供了基于 eBPF 的,Pod 级别的容器网络异常监控能力。
基于 eBPF,KubeSkoop 提供了精简、低开销的内核异常监控能力,覆盖驱动、netfilter、TCP 等完整协议栈,几十种异常场景的识别。同时,基于云原生部署,提供了与 Prometheus 等可观测体系的对接,支持网络问题的 Metrics 查看和事件回溯。
关于深度网络监控能力的指标透出,可参考: https://kubeskoop.io/docs/guide/exporter/exporter-description
KubeSkoop 设计
Cloud Native
KubeSkoop 的设计,同样分为连通性诊断和深度网络监控两部分。
连通性诊断
工作流程
KubeSkoop 连通性诊断的工作流程可分为三步: 拓扑构建、信息采集和链路模拟。
拓扑构建通过用户所提供的信息,再通过 API Server 获取集群内的 Pod/Node 资源和 Service/NetworkPolicy 规则,匹配对应的 CNI 插件、基础设施,构建集群内的访问关系。
信息采集在构建链路的过程中,KubeSkoop 会按需向集群中的节点下发信息采集任务。采集的内容包括运行时信息、协议栈采集(路由、iptables、IPVS 等)和基础设施信息(ECS metadata)。采集后的信息用于后续的网络拓扑构建和诊断模拟过程。
链路模拟KubeSkoop 会根据网络拓扑和所收集到到的信息,进行检查和模拟。包括对路径上的拓扑点和链路的转发模拟、对于 CNI 插件实现的模拟、云厂商的模拟,快速发现链路中存在的丢包或错误路由配置。
最终,结合网络拓扑以及诊断中发现的异常链路,KubeSkoop 会输出诊断结果和链路中存在的问题,或在 Web UI 中进行直观地展示。
扩展性
KubeSkoop 连通性诊断提供了对 CNI 插件和基础设施架构的扩展,能够轻松地在框架中提供对其它 CNI 插件和云厂商的支持。
深度网络监控
工作流程
KubeSkoop 深度网络监控通过在需要采集信息的集群节点上运行 KubeSkkop exporter 的方式,采集节点上 Pod 的网络监控信息并以多种形式导出,包括:
深度容器网络采集 通过 eBPF 采集协议栈关键点 采集 procfs 下内核透出信息用于回溯 采用 CRI 接口关联采集点和 Pod 容器指标和异常事件预处理 网络异常 Metrics 过滤,减少开销 多指标聚合生成异常 Event 网络 Metrics 和 Event 展示 通过 Prometheus+Grafa 存储和回溯异常时间点指标 Grafana Loki 记录异常事件 KubeSkoop Inspector 查看实时异常事件流实现
在实现中,采用了 eBPF 作为 KubeSkoop 主要数据的采集来源。eBPF 可以达到在内核中动态注入代码的目的,eBPF 代码在内核中执行效率高,并且可以通过 map 和 pert_event 与用户态通信。eBPF 还自带了校验机制,避免了因挂载的程序问题而导致宕机。
为了兼容性和性能考虑,在使用 eBPF 的过程中,我们也做了许多优化措施:
采用 CO-RE 方式减少编译开销,提升内核兼容性 减少在关键路径上的注入 尽量在 eBPF 程序中过滤异常数据,以减少内存开销 默认注入低开销程序,根据需求可动态插拔 eBPF 采集模块和修改过滤参数未来规划
Cloud Native
目前,KubeSkoop 项目仍旧处于早期阶段。我们下一步的规划包括:
增加更多云厂商和网络插件的支持。 支持模拟发包和追踪以定位未知问题点,缩小排查范围。 提供 KubeSkoop Analysis 工具,智能分析 KubeSkoop 的指标和事件,降低诊断结果理解门槛。 不限于网络诊断,增加存储、性能诊断。 应用层感知能力,提供对7层协议(如 http、redis 等)的感知和处理。KubeSkoop 的官网位于: https://kubeskoop.io
欢迎大家前来试用&提供建议&贡献代码! 也欢迎通过搜索群号的方式加入 KubeSkoop 用户钉钉交流群~(群号:26720020148)