共计 3624 个字符，预计需要花费 10 分钟才能阅读完成。
Kubernetes 自身比较复杂，应用门槛较高，用户在开始容器化迁徙时常常遇到各种各样的问题，因为不足故障定位的技能和工具，用户经常产生挫败感，甚至放弃业务容器化。其中网络问题体现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度微小。
KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，反对支流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了升高网络问题排查难度，让没有网络常识的人也能够自动化地定位网络问题。
Kubernetes 容器网络诊断工具：https://github.com/alibaba/kubeskoop
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）网络插件插件的诊断反对，以及阿里云作为基础设施的反对。对于诊断能力的残缺应用文档，可见：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 设计
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 等）的感知和解决。
作者：溪恒、谢石、遐宇
点击立刻收费试用云产品 开启云上实际之旅！
原文链接
本文为阿里云原创内容，未经容许不得转载。
