Kubernetes本身比较复杂，使用门槛较高，用户在开始容器化迁移时经常遇到各种各样的问题，由于缺乏故障定位的技能和工具，用户常常产生挫败感，甚至放弃业务容器化。其中网络问题表现尤为突出，Kubernetes网络虚拟化导致网络问题排查的难度巨大。 KubeSkoop是阿里云容器服务团队开源的Kubernetes容器网络诊断工具，支持主流的网络插件和云厂商的Kubernetes集群诊断。它正是为了降低网络问题排查难度，让没有网络知识的人也可以自动化地定位网络问题。 KubeSkoop能够自动构建出给定源和目的地址在容器网络中的访问路径，自动化地采集和分析链路上每一个网络节点的配置，结合eBPF内核监控以及IaaS层的网络配置检查，定位出导致网络不通的根因，极大地降低了网络问题定位的时间，即使没有任何网络技能的用户也可以使用。目前在阿里云容器服务的环境中，作为自运维工具解决了大量客户在大规模Kubernetes集群场景下遇到的网络问题。 本文将会对容器网络和传统定位手段带来的问题进行简单的介绍，以及对KubeSkoop的功能设计等方面进行总体解说。 容器网络是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项目，来实现针对容器网络场景下问题的自动诊断系统。 在我们的分析中，常见的Kubernetes网络问题可以分为以下两类： 网络持续不通问题 持续的无法访问：ping不同、connect超时、DNS无法解析等。 网络抖动问题 偶发的网络问题：偶尔的业务超时、504、偶发reset等。 网络性能问题：网络性能低、QPS压不上去等。 在这些问题中，80%都是可以依赖经验解决的已知问题。而问题的处理时间主要浪费在问题上报、信息收集和验证上。 KubeSkoop即是针对这两类场景，通过信息收集（包括CNI插件、ServiceMesh、Kernel/eBPF、基础设施等）、推导和展示（容器服务智能运维、Prometheus、Grafana/Loki等），实现全链路一键诊断、网络栈延迟分析、网络异常事件识别回溯，快速定位问题根因。 项目可分为两部分：诊断网络持续不通问题的KubeSkoop连通性诊断，和分析网络抖动问题的KubeSkoop深度网络监控。 通过KubeSkoop，能够对网络持续不通问题进行一键诊断。 同时，诊断包含了Service、NetworkPolicy等Kubernetes概念的分析，全面覆盖协议栈、底层IaaS的连通性相关检查，让用户无需了解网络插件的实现，也无需拥有复杂网络问题排查经验，就能够一键定位网络问题并自助解决。 连通性诊断目前提供了Flannel、Calico（内部包括Terway）网络插件插件的诊断支持，以及阿里云作为基础设施的支持。关于诊断能力的完整使用文档，可见： 针对网络抖动问题，KubeSkoop深度网络监控提供了基于eBPF的，Pod级别的容器网络异常监控能力。 基于eBPF，KubeSkoop提供了精简、低开销的内核异常监控能力，覆盖驱动、netfilter、TCP等完整协议栈，几十种异常场景的识别。同时，基于云原生部署，提供了与Prometheus等可观测体系的对接，支持网络问题的Metrics查看和事件回溯。 关于深度网络监控能力的指标透出，可参考： KubeSkoop的设计，同样分为连通性诊断和深度网络监控两部分。 工作流程 KubeSkoop连通性诊断的工作流程可分为三步：拓扑构建、信息采集和链路模拟。 拓扑构建 通过用户所提供的信息，再通过APIServer获取集群内的Pod/Node资源和Service/NetworkPolicy规则，匹配对应的CNI插件、基础设施，构建集群内的访问关系。 信息采集 在构建链路的过程中，KubeSkoop会按需向集群中的节点下发信息采集任务。采集的内容包括运行时信息、协议栈采集（路由、iptables、IPVS等）和基础设施信息（ECSmetadata）。采集后的信息用于后续的网络拓扑构建和诊断模拟过程。 链路模拟 KubeSkoop会根据网络拓扑和所收集到到的信息，进行检查和模拟。包括对路径上的拓扑点和链路的转发模拟、对于CNI插件实现的模拟、云厂商的模拟，快速发现链路中存在的丢包或错误路由配置。 最终，结合网络拓扑以及诊断中发现的异常链路，KubeSkoop会输出诊断结果和链路中存在的问题，或在WebUI中进行直观地展示。 扩展性 KubeSkoop连通性诊断提供了对CNI插件和基础设施架构的扩展，能够轻松地在框架中提供对其它CNI插件和云厂商的支持。 工作流程 KubeSkoop深度网络监控通过在需要采集信息的集群节点上运行KubeSkkopexporter的方式，采集节点上Pod的网络监控信息并以多种形式导出，包括： 深度容器网络采集 通过eBPF采集协议栈关键点 采集procfs下内核透出信息用于回溯 采用CRI接口关联采集点和Pod 容器指标和异常事件预处理 网络异常Metrics过滤，减少开销 多指标聚合生成异常Event 网络Metrics和Event展示 通过Prometheus+Grafa存储和回溯异常时间点指标 GrafanaLoki记录异常事件 KubeSkoopInspector查看实时异常事件流 实现 为了兼容性和性能考虑，在使用eBPF的过程中，我们也做了许多优化措施： 采用CO-RE方式减少编译开销，提升内核兼容性 减少在关键路径上的注入 尽量在eBPF程序中过滤异常数据，以减少内存开销 默认注入低开销程序，根据需求可动态插拔eBPF采集模块和修改过滤参数 目前，KubeSkoop项目仍旧处于早期阶段。我们下一步的规划包括： 增加更多云厂商和网络插件的支持。 支持模拟发包和追踪以定位未知问题点，缩小排查范围。 提供KubeSkoopAnalysis工具，智能分析KubeSkoop的指标和事件，降低诊断结果理解门槛。 不限于网络诊断，增加存储、性能诊断。 应用层感知能力，提供对7层协议（如http、redis等）的感知和处理。 KubeSkoop的官网位于： 欢迎大家前来试用提供建议贡献代码！也欢迎通过搜索群号的方式加入KubeSkoop用户钉钉交流群~（群号：26720020148）