共计 9023 个字符，预计需要花费 23 分钟才能阅读完成。
本文是 8 月 17 日直播的文字稿整顿，微信公众号「阿里云云原生」可观看直播回放。除去文章内容外，还包含针对实际网络问题的实战环节。
容器网络抖动问题产生频率低，工夫短，是网络问题中最难定位和解决的问题之一。不仅如此，对 Kubernetes 集群内的网络状态进行日常的持续性监测，也是集群运维中很重要的一环。
KubeSkoop 基于 eBPF 技术，提供了 Pod 粒度的、低开销的、可热插拔的实时网络监测能力，不仅能够满足日常网络监控的须要，也可能在呈现网络问题后，通过开启对应的探针，疾速定位及解决问题。KubeSkoop 提供了基于 Prometheus 的指标和 Grafana 大盘，同时也提供了基于命令行、基于 Loki 的异样事件透出能力，提供问题现场的详细信息。
本次分享将包含：
- 利用如何收到 / 收回数据包网络问题排查的难点，传统网络问题排查工具以及传统工具的问题
- 对 KubeSkoop 和网络监测局部（即 KubeSkoop exporter）的简略介绍
- 联合内核中的不同的模块具体介绍 KubeSkoop exporter 的探针、指标和事件
- 在日常监测和异样排查中应用 KubeSkoop exporter 的个别流程
- KubeSkoop exporter 的将来布局。
容器中的利用如何收到 / 收回数据包？
在网络中，数据是以数据包为单位进行传输的。在 Linux 零碎上，数据包须要通过内核中各个模块层层解决，才可能失常地被利用接管，或是被利用发送。
咱们先来看接管过程：
- 网卡驱动收取网络报文后，发动中断
- 内核 ksoftirqd 失去调度后，失去数据，进入到协定栈解决
- 报文进入网络层，网络层通过 netfilter 等解决后，进入传输层
- 传输层解决报文后，将报文的 payload 放入 socket 接管队列中，唤醒利用过程，让出 CPU
- 利用过程被调度后，通过零碎调用将数据收取的用户态进行解决
再来看发送过程：
- 应用程序通过零碎调用向 socket 发送队列写入数据
- 进入到内核态，socket 调用传输层进行报文发送
- 传输层组装报文，调用网络层发送
- 网络层通过 netfilter 等解决后，进入 tc egress
- tc qdisc 将报文依照顺序调用网卡驱动进行发送
咱们在入方向并没有关注到 tc 的解决，但在出方向着重的提了一下，这也是链路中产生丢包异样的常见起因之一。
由下面的介绍能够看出，一个包在 Linux 内核中须要通过简单的解决步骤。内核网络子系统的模块泛滥，代码量宏大且简单，是造成网络问题排查的难点之一；包的接管和发送通过的链路长，给问题定位带来了相当的难度。同时网络相干零碎的参数繁多，配置简单，因为某些性能或者参数的限度导致了网络问题，也须要咱们花大量的工夫去定位；同时，零碎的磁盘、调度、业务代码缺点等，都可能体现为网络问题，须要对系统状态进行全面的观测。
罕用网络排查工具
接下来，咱们再来介绍一下 Linux 环境下常见网络问题排查工具，以及其背地的实现技术。
net-tools（netstat 等）
net-tools 所提供的工具，可能用于查看网络统计信息，包含网络以后状态、异样统计计数等
它的原理是，通过 procfs 中的 /proc/snmp 和 /proc/netstat 文件获取以后的网络状态和异样计数，特点是性能好，开销小，然而它所能提供的信息绝对较少，并且不可定制。
procs 是 linux 所提供的虚构文件系统之一。它可能提供零碎的运行信息、过程信息和计数器信息。用户过程通过 write() 或者 read() 零碎调用函数，对 procfs 所提供的文件进行拜访，如 /proc/net/netstat，或 /proc/<pid>/net/snmp 等。内核中的 procfs 实现，会将信息通过虚构文件系统 vfs 返回用户。
和 net-tools 工具包相似的命令还有 nstat、sar、iostat 等。
iproute2（ip、ss 等）
iproute2 工具包中的 ip、ss 工具也提供了查看网络统计信息和网络状态的多种实用工具。但它的原理与 netstat 等工具不同，是基于 netlink 取得信息的。它相比于 net-tools，可能提供更加全面的网络信息，和更好的扩大能力，然而性能相较于通过 procfs 会差一些。
netlink 是 Linux 中一种非凡的 socket 类型，用户程序能够通过规范的 socket API 和内核进行通信。用户程序通过 AF_NETLINK 类型的 socket 进行数据的发送和收取。内核中将会通过 socket 层来解决用户的申请。
与其类似的命令还有 tc、conntrack、ipvsadm 等。
bcc-tools
bcc-tools 提供了多种的内核态观测工具，包含网络、磁盘、调度等方面。它的外围实现是基于 eBPF 计数，有着十分强的扩展性和不错的性能，然而应用门槛相较于上述工具会更高一些。
eBPF 是 Linux 中比拟年老的技术，也是近期社区的热门关注点之一。eBPF 是内核中的一个小型虚拟机，能够动静加载用户本人编写的代码并在内核中运行，同时内核会帮忙你校验程序的安全性，确保不会因为自定义的 eBPF 代码导致内核呈现工作异样。
在 eBPF 程序加载进内核后，它能够通过 map 来与用户态的程序进行数据的替换。用户过程能够通过用户态的 bpf() 零碎调用来取得 map 中的数据，而 eBPF 程序也能够在内核中应用内核 API 来被动更新 map 数据，来实现内核与用户过程之间的交换。
与 bcc-tools 中提供的工具类似的，还有 bpftrace、systemtap 等。
传统工具在云原生场景下的问题
上述的工具，通过 Linux 的不同能力提供了丰盛的状态信息，帮忙咱们排查零碎中产生的网络问题。然而，在云原生容器的简单场景下，传统工具也有着一些局限性：
- 大部分工具以本机 / 网络命名空间为维度进行观测，难以针对某个特定容器
- 对于简单拓扑的观测，没有短缺的内核问题排查教训，可能会难以下手
- 对于偶发问题，很难实时抓到现场应用这些工具
- 这些工具提供了大量的信息，然而信息之间的关联并不显著
- 一些观测工具本人自身同时也会带来性能方面的问题
KubeSkoop
基于以上 Linux 网络解决的简单链路、传统工具在云原生容器场景下的缺点。基于云原生环境的网络观测要求，KubeSkoop 我的项目应运而生。
在介绍 KubeSkoop 的网络监测局部，也就是 KubeSkoop exporter 之前，咱们先来回顾一下 KubeSkoop 我的项目的全貌。
KubeSkoop 是一个容器网络问题的主动诊断系统。它针对了网络继续不通问题，如 DNS 解析异样，service 无法访问等场景，提供了一键诊断的能力；针对网络抖动问题，如提早增高、偶发 reset、偶发丢包等场景，提供了实时监测的能力。KubeSkoop 提供了全链路一键诊断、网络站提早剖析和网络异样事件辨认回溯的能力。
本次分享中，咱们的重点在 KubeSkoop 的网络监测能力局部。
KubeSkoop exporter 基于 eBPF、procfs、netlink 等多种数据源的容器网络异样监控，提供了 Pod 级别的网络监控能力，可能提供网络监控指标、网络异样事件记录和实时事件流，笼罩驱动、netfilter、TCP 等残缺协定栈和几十种异样场景，与云上 Prometheus、Loki 等可观测体系对接。
KubeSkoop exporter 提供了针对内核中不同地位采集信息的探针，反对探针的热插拔和按需加载的能力。开启的探针会以 Prometheus 指标或是异样事件的模式透出所采集到的统计信息或网络异样。
探针、指标和事件
针对内核中的不同模块，KubeSkoop exporter 提供了多种探针，实用于不同的观测需要和不同的网络问题场景。
指标（metrics）是对网络中要害信息，以 Pod 维度汇总的统计数据，如连接数、重传数等。这些信息可能为用户提供网络状态随工夫的变动信息，可能更好的帮忙用户了解目前容器中的网络情况。
事件会在网络异样产生的时候产生，如丢包、TCP reset、数据处理呈现提早等。相比于指标，事件可能提供更多有对于问题现场的信息，如呈现丢包的具体位置、呈现提早的具体统计等。事件更多用来针对某一个具体的网络异样，来进行更加深刻的观测和问题定位。
探针列表
上面将会介绍目前 KubeSkoop 所提供的探针，阐明作用、实用场景、开销以及它所提供的指标 / 事件。
对于探针、指标和事件的阐明，也能够拜访 KubeSkoop 文档 https://kubeskoop.io 获取更多信息。
socketlatency
socketlatency 探针通过追踪内核内 socket 相干以及上下游的符号，取得用户态从 socket 数据筹备好到读取数据，以及 socket 接管到数据，到传递到 TCP 层进行解决的提早状况。该探针个别次要关注在数据达到 socket 层时，用户态数据读取的提早状况。探针提供了 socket 读取 / 写入提早的相干指标以及事件。
开销：高
实用场景：狐疑过程因为调度、解决不及时等起因，读取数据慢的状况
常见问题：因为容器过程 CPU 超限导致的网络抖动
sock
sock 探针的数据来源于 /proc/net/sockstat 文件，提供了 Pod 外部对于 socket 的统计指标，采集了 TCP 处于不同状态 (inuse、orphan、tw) 的 socket 数量，以及内存的应用状况。可能因为应用逻辑、零碎参数配置等问题，导致 socket、tcpmem 耗尽等状况，产生连贯失败的状况，影响并发性能。该探针开销极小，因而也能够做为日常状态中连贯大体状态的观测。
开销：低
实用场景：日常观测连贯状态，socket 透露、reuse、socket 内存占用过低等状况
常见问题：因为 socket 透露导致的内存占用持续增长；连贯过多、reuse、tcpmem 耗尽等导致的建连失败 / 偶发 RST 状况
tcp/udp/tcpext
通过 /proc/net/netstat 和 /proc/net/snmp 两个文件采集的对于 TCP/UDP 协定层的根底信息采集，如 TCP 新建连贯 / 胜利建设连贯的数量，重传报文数，UDP 协定谬误计数等。tcpext 同时也提供了 TCP 更加细粒度的指标，如发送 RST 报文的统计等。该指针在 TCP/UDP 连贯相干的异样问题中（如负载不均、连贯建设失败、异样连贯敞开）等提供要害信息，同时作为基于 procfs 采集信息的探针，能够用于日常对流量状态的观测。
开销：低
实用场景：日常对 TCP 和 UDP 相干状态的观测。呈现 TCP 连贯异样重传、连贯建设失败、reset 报文等状况的信息采集，呈现 DNS 解析失败等状况的信息采集
常见问题：利用连贯出现异常敞开；因为重传导致的延时抖动
tcpsummary
tcpsummary 探针通过与内核进行 netlink 音讯 (SOCK_DIAG_BY_FAMILY) 的通信，获取到 Pod 内的所有 TCP 连贯信息，并聚合 TCP 连贯状态和发送 / 承受队列状态产生指标。该探针须要聚合所有连贯信息失去最终统计后果，因而在连贯较多的高并发场景下，可能会带来较大的开销。
开销：中
实用场景：偶发提早、连贯失败等场景下提供 TCP 连贯的状态信息
常见问题：用户态过程 hang 住，接管队列沉积导致的丢包
tcpreset
tcpreset 探针通过在内核中追踪 tcp_v4_send_reset 和 tcp_send_active_reset 的调用，在 TCP 连贯中发送 RST 报文时，记录 socket 信息和状态，产生事件。在 tcp_receive_reset 被调用，即收到 RST 报文时，也会记录以上信息。探针基于内核中冷门路的追踪，因而开销较低。该探针只产生事件，倡议在呈现 tcp reset 问题时再开启。
开销：低
实用场景：TCP 连贯被异样 reset 时，追踪内核中的 reset 地位
常见问题：因为客户端与服务端两端超时工夫设置问题，导致的偶发连贯 reset
ip
ip 探针是从 /proc/net/snmp 文件中采集到的 IP 相干的信息指标。包含因为路由目标地址不可达以及数据包长度小于 IP 头中示意长度两种状况的计数器，可能对因为上述两种起因呈现丢包的状况做出判断。探针开销极小，也倡议在日常监测场景下关上该探针。
开销：低
实用场景：日常对 IP 相干状态的观测。呈现丢包等问题时
常见问题：因为节点上路由设置不正确，目标不可达导致的丢包
kernellatency
kernellatency 对报文接管和报文发送全过程的多个关键点进行工夫记录，计算报文在内核中的解决提早。指针提供了接管和发送数据包解决呈现提早的指标，同时也提供了事件，包含了报文五元组和内核中各个点位之间的解决工夫。本探针波及所有报文的工夫统计和大量的 map 查问操作，开销较高，因而倡议仅在相干问题产生时启用该探针。
开销：高
实用场景：连贯超时，网络抖动问题
常见问题：因为 iptables 规定过多导致的内核解决提早高
ipvs
ipvs 探针采集了 /proc/net/ip_vs_stats 文件中的信息，提供了 IPVS 相干的统计计数。IPVS 是内核提供的 4 层负载平衡能力，在 kube-proxy 的 IPVS 模式中被应用。探针提供的指标次要包含 IPVS 的连接数、出 / 如数据包数和出 / 入数据字节数。该探针实用于日常监测中对 IPVS 统计信息的观测，也对拜访 service IP 呈现网络抖动或连贯建设失败等状况起辅助参考作用。
开销：低
实用场景：日常对 IPVS 相干状态的观测
常见问题：无
conntrack
conntrack 探针通过 netlink，提供用于追踪 conntrack 模块的统计数据。conntrack 模块是基于内核提供的 netfilter 框架，对网络层以上的数据流量进行连贯追踪，包含每条连贯的创立工夫，报文数，字节数等数据，并提供依据信息的匹配进行 nat 等下层操作的机制。探针的指标中提供了以后 conntrack 中处于各个状态的条目标统计计数，以及 conntrack 以后条目和条目下限的数量。因为探针须要遍历所有 conntrack 条目，因而在高并发场景下会有较大开销。
开销：高
实用场景：连贯建设失败、丢包，conntrack 串流等问题
常见问题：因为 conntrack 溢出导致的连贯建设失败、丢包
netdev
netdev 探针通过采集 /proc/net/dev 文件，提供了网络设备层面的统计指标，包含发送 / 接管字节数、谬误数、数据包数、丢包数。探针通常用于宏观的发现网络问题，在偶发 TCP 握手失败等场景有价值。探针开销极小，倡议日常开启。
开销：低
实用场景：日常监控。网络抖动，设施底层丢包等状况
常见问题：网络设备丢包导致的网络抖动或建连失败
qdisc
qdisc 探针通过 netlink，提供了 tc qidsc 的统计指标，包含 qdisc 上的通过的流量统计，以及 qdisc 队列状态的统计计数。tc qdisc 是 LInux 内核中用于对网络设备进行流量管制的模块，qdisc 会依据调度规定管制数据包的发送。网卡上的 qdisc 规定可能会导致数据包被抛弃，或是提早高状况产生。探针开销较低，倡议日常开启。
开销：低
实用场景：日常监控。网络抖动丢包等状况
常见问题：因为 qdisc 队列超限导致丢包，产生网络抖动
netiftxlatency
对内核中网络设备解决局部的关键点位进行追踪并计算提早，次要集中在 qdisc 对报文的解决工夫，以及底层设施对外发送的工夫，提供了两局部提早超过肯定阈值的报文数量统计，以及蕴含报文五元组信息的异样事件。探针会对所有报文进行提早的计算，因而开销较高，倡议呈现提早问题时再开启。
开销：高
实用场景：连贯超时，网络抖动等状况
常见问题：底层网络抖动导致提早升高
softnet
softnet 探针的数据来源于内核的 proc 文件接口 /proc/net/softnet_stat，以 Pod 级别进行指标的聚合。softnet 探针依照 cpu 的形式对网卡收取的数据包进行整合，他表征着数据包从网卡设施进入 Linux 内核的软中断处理过程的状态，对外提供了接管和解决数据包的总览数据。探针对呈现爱你节点级别的网络问题时可能起到辅助作用，开销极小，倡议开启。
开销：低
实用场景：日常监控。呈现节点级别的网络问题时可能提供帮忙
常见问题：无
net_softirq
net_softirq 探针通过内核态程序，采集了与网络相干的两种中断 (netif_tx、netif_rx) 的调度和执行时长，包含软中断发动到开始执行，和软中断开始执行到执行实现的耗时，并将超过肯定阈值的报文以指标或者事件的模式进行统计透出。
开销：高
实用场景：呈现偶发提早，网络抖动常见问题：cpu 争抢导致的软中断调度提早，产生网络抖动
virtcmdlatency
virtcmdlat 探针通过对内核态调用虚拟化指定的办法 (virtnet_send_command) 的执行工夫进行计算，来获取虚拟机执行虚拟化调用的耗时，提供了呈现提早次数的指标和事件。virtio 是比拟常见的虚拟化网络计划，因为其半虚拟化的个性，虚拟机对网卡设施驱动的操作可能会因为底层物理机的阻塞而产生提早。探针开销较高，倡议狐疑因宿主机起因呈现网络抖动时再将其开启。
开销：高
实用场景：呈现偶发提早，网络抖动
常见问题：底层物理机资源争抢导致的网络抖动
fd
fd 探针通过对单个 Pod 内所有过程持有的句柄进行采集，获取 Pod 中过程关上的文件描述符及 socket 类型的文件描述符的数量。探针须要遍历过程的所有 fd，开销较高。
开销：高
实用场景：fd 透露，socket 透露等问题
常见问题：socket 未被用户态程序敞开，产生透露导致 TCP OOM，进而导致网络抖动
io
io 探针的数据来源于 /proc/io 提供的文件接口，用于表征单个 Pod 进行文件系统 io 的速率与总量。探针提供的指标包含文件系统读写操作的次数以及字节数。局部网络问题可能是因为同节点上其它进行进行大量 IO，导致用户过程响应慢产生的，在这种状况下，能够按需开启该探针以进行验证，也能够用于日常对 Pod IO 的监测。
开销：低
实用场景：因为用户过程响应慢导致的提早增长，重传升高
常见问题：大量文件读写导致的网络抖动问题
biolatency
biolatency 追踪了内核中块设施读取和写入调用的执行工夫，并将超过阈值的执行以异样事件的模式透出。设施 IO 提早减少，可能会导致用户过程的业务解决受到影响，进而产生网络抖动问题，在狐疑因为 IO 产生网络异样时，能够开启此探针。探针须要对所有块设施的读写操作进行统计，开销中等，倡议按需开启。
开销：中
实用场景：IO 读写慢导致的网络抖动、提早升高等
常见问题：因为块设施读写提早产生的网络抖动
如何应用 KubeSkoop exporter
KubeSkoop exporter 实用于日常监控以及网络异样问题产生时的排查两种场景。这两种场景对 KubeSkoop exporter 的应用形式有所不同，上面讲简略介绍。
日常监控
在日常监控中，举荐应用 Prometheus 收集 KubeSkoop exporter 所透出的指标，以及可选的通过 Loki 来收集异样事件的日志。收集到的指标和日志，能够透过 Grafana 大盘进行展现。KubeSkoo exporter 也提供了现成的 Grafana 大盘，能够间接应用。
在配置好指标收集和大盘后，还须要对 KubeSkoop exporter 自身进行一些配置。咱们在日常的监控中，为了对业务的流量造成影响，咱们能够选择性开启一些低开销的探针，如基于 porcfs 的大部分探针，和局部基于 netlink、eBPF 的低开销探针。如果应用了 Loki，还须要同时配置 Loki 的服务地址，并且将其启用。在这些筹备工作完结之后，咱们就能够在大盘上看到所启用的指标和事件状况。
在日常的监控之中，须要关注一些敏感的指标的异样。比如说新建连接数的异样突增，或者是连贯建设失败数上涨，reset 报文减少等。针对这些显著可能代表异样的指标，咱们也能够通过配置告警的模式，可能在出现异常时，更快的染指去进行问题的排查和复原。
异样问题排查
当咱们通过日常监控、业务告警、谬误日志等方面发现可能存在网络异样后，须要先对网络异样问题的类型进行一个简略的归类，如 TCP 建连失败、网络提早抖动等。通过简略的归类，可能更好的帮忙咱们确立问题的排查方向。
依据问题类型不同，咱们就能够依据问题类型，开启实用于该问题的探针。比方呈现了网络提早抖动的问题，咱们就能够开启 socketlatency 关注利用从 socket 读数据提早的状况，或是开启 kernellatency 追踪内核中提早的状况。
开启这些探针后，咱们就能够通过曾经配置好的 Grafana 来观测探针暴露出的指标或是事件后果。同时，异样事件也能够间接通过 Pod 日志，或是 exporter 容器中的 inspector 命令来间接观测。如果咱们这次开启的探针后果没有异样，或是无奈针对问题根因做出论断，能够思考开启其它方面的探针，持续辅助咱们进行问题的定位。
依据这些所失去的指标和异样事件，咱们最终会定位到问题的根因。问题的根因可能出自零碎中的某一些参数的调整，或者是呈现在用户的程序之中。咱们依据定位到的根因就能够进行这些零碎参数调整或者是程序代码的优化了。
将来布局
KubeSkoop 已于上周公布第一个正式版本 0.1.0，次要改良点包含：
诊断
- 反对 k3s 集群
- 反对节点 host interface 主动抉择
- 修复若干诊断谬误
网络监测
- 反对大部分支流操作系统的 btf 主动发现
- 优化 exporter 性能，CPU 开销大幅降落
- 反对探针的热加载
- 初步反对 flow 级别指标采集
以下是咱们近几个月的开发布局，包含：
- KubeSkoop exporter 代码重构，加强扩展性与稳定性
- 全面反对 flow 级别的 metrics 展现，疾速定位问题连贯
- 反对事件透出到本地文件 /ELK 等
- 更加敌对的 UI，反对集群内流量拓扑全览
结语
本次分享是对 KubeSkoop 我的项目的网络监测能力的重点介绍，次要介绍了 KubeSkoop exporter 所领有的指标，以及日常应用和排查问题的个别办法，可能帮忙您更好的应用本我的项目，对网络进行观测和问题排查。
相干链接：
[1] Github 我的项目主页
https://github.com/alibaba/kubeskoop
作者：遐宇、溪恒
点击立刻收费试用云产品 开启云上实际之旅！
原文链接
本文为阿里云原创内容，未经容许不得转载。
