溪恒、谢石、遐宇 阿里云云原生 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）
关键词：
