作者：溪恒、谢石、遐宇
Kubernetes 本身比较复杂，使用门槛较高，用户在开始容器化迁移时经常遇到各种各样的问题，由于缺乏故障定位的技能和工具，用户常常产生挫败感，甚至放弃业务容器化。其中网络问题表现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度巨大。
KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，支持主流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了降低网络问题排查难度，让没有网络知识的人也可以自动化地定位网络问题。
Kubernetes 容器网络诊断工具：github.com/alibaba/kub…
KubeSkoop 能够自动构建出给定源和目的地址在容器网络中的访问路径，自动化地采集和分析链路上每一个网络节点的配置，结合 eBPF 内核监控以及 IaaS 层的网络配置检查，定位出导致网络不通的根因，极大地降低了网络问题定位的时间，即使没有任何网络技能的用户也可以使用。目前在阿里云容器服务的环境中，作为自运维工具解决了大量客户在大规模 Kubernetes 集群场景下遇到的网络问题。
本文将会对容器网络和传统定位手段带来的问题进行简单的介绍，以及对 KubeSkoop 的功能设计等方面进行总体解说。
容器网络
网络连通性-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 功能
在我们的分析中，常见的 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）网络插件插件的诊断支持，以及阿里云作为基础设施的支持。关于诊断能力的完整使用文档，可见：kubeskoop.io/docs/guide/…
深度网络监控
针对网络抖动问题，KubeSkoop 深度网络监控提供了基于 eBPF 的，Pod 级别的容器网络异常监控能力。
基于 eBPF，KubeSkoop 提供了精简、低开销的内核异常监控能力，覆盖驱动、netfilter、TCP 等完整协议栈，几十种异常场景的识别。同时，基于云原生部署，提供了与 Prometheus 等可观测体系的对接，支持网络问题的 Metrics 查看和事件回溯。
关于深度网络监控能力的指标透出，可参考：kubeskoop.io/docs/guide/…
KubeSkoop 设计
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 采集模块和修改过滤参数
未来规划
目前，KubeSkoop 项目仍旧处于早期阶段。我们下一步的规划包括：
- 增加更多云厂商和网络插件的支持。
- 支持模拟发包和追踪以定位未知问题点，缩小排查范围。
- 提供 KubeSkoop Analysis 工具，智能分析 KubeSkoop 的指标和事件，降低诊断结果理解门槛。
- 不限于网络诊断，增加存储、性能诊断。
- 应用层感知能力，提供对7层协议（如 http、redis 等）的感知和处理。
KubeSkoop 的官网位于：kubeskoop.io
欢迎大家前来试用&提供建议&贡献代码！也欢迎通过搜索群号的方式加入 KubeSkoop 用户钉钉交流群~（群号：26720020148）
点击此处了解 KubeSkoop 更多详情
