乐趣区

关于云原生:深度解析|基于-eBPF-的-Kubernetes-一站式可观测性系统

作者:李煌东、炎寻

摘要

阿里云目前推出了面向 Kubernetes 的一站式可观测性零碎,旨在解决 Kubernetes 环境下架构复杂度高、多语言 & 多协定并存带来的运维难度高的问题,数据采集器采纳当下火出天际的 eBPF 技术,产品上反对无侵入地采集利用黄金指标,构建成全局拓扑,极大地升高了私有云用户运维 Kubernetes 的难度。

前言

背景与问题

以后,云原生技术次要是以容器技术为根底围绕着 Kubernetes 的标准化技术生态,通过规范可扩大的调度、网络、存储、容器运行时接口来提供基础设施,同时通过规范可扩大的申明式资源和控制器来提供运维能力,两层标准化推动了细化的社会分工,各畛域进一步晋升规模化和专业化,全面达到老本、效率、稳定性的优化,在这样的背景下,大量公司都应用云原生技术来开发运维利用。正因为云原生技术带来了更多可能性,以后业务利用呈现了微服务泛滥、多语言开发、多通信协议的特色,同时云原生技术自身将复杂度下移,给可观测性带来了更多挑战:

1、混沌的微服务架构

业务架构因为分工问题,容易呈现服务数量多,服务关系简单的景象(如图 1)。


图 1 混沌的微服务架构(图片起源见文末)

这样会引发一系列问题:

无法回答以后的运行架构;
无奈确定特定服务的上游依赖服务是否失常;
无奈确定特定服务的上游依赖服务流量是否失常;
无法回答利用的 DNS 申请解析是否失常;
无法回答利用之间的连通性是否正确;

2、多语言利用

业务架构外面,不同的利用应用不同的语言编写(如图 2),传统可观测办法须要对不同语言应用不同的办法进行可观测。


图 2 多语言(图片起源见文末)

这样也会引发一系列问题:

  • 不同语言须要不同埋点办法,甚至有的语言没有现成的埋点办法;
  • 埋点对利用性能影响无奈简略评估;

3、多通信协议

业务架构外面,不同的服务之间的通信协议也不同(如图 3),传统可观测办法通常是在应用层特定通信接口进行埋点。


图 3 多通信协议

这样也会引发一系列问题:

  • 不同通信协议因为不同的客户端须要不同埋点办法,甚至有的通信协议没有现成的埋点办法;
  • 埋点对利用性能影响无奈简略评估;

4、Kubernetes 引入的端到端复杂度

复杂度是永恒的,咱们只能找到办法来治理它,无奈打消它,云原生技术的引入尽管缩小了业务利用的复杂度,然而在整个软件栈中,他只是将复杂度下移到容器虚拟化层,并没有打消(如图 4)。


图 4 端到端软件栈

这样也会引发一系列问题:

  • Deployment 的冀望正本数和理论运行正本数不统一;
  • Service 没有后端,无奈解决流量;
  • Pod 无奈创立或者调度;
  • Pod 无奈达到 Ready 状态;
  • Node 处于 Unknown 状态;

解决思路与技术计划

为了解决下面的问题,咱们须要应用一种反对多语言,多通信协议的技术,并且在产品层面尽可能得笼罩软件栈端到端的可观测性需求,通过调研咱们提出一种立足于容器界面和底层操作系统,向上关联利用性能观测的可观测性解决思路(如图 5)。

数据采集


图 5 端到端可观测性解决思路

咱们以容器为外围,采集关联的 Kubernetes 可观测数据,与此同时,向下采集容器相干过程的零碎和网络可观测数据,向上采集容器相干利用的性能数据,通过关联关系将其串联起来,实现端到端可观测数据的笼罩。

数据传输链路

咱们的数据类型蕴含了指标,日志和链路,采纳了 open telemetry collector 计划(如图 6)反对对立的数据传输。


图 6 OpenTelemetry Collector(图片起源见文末)

数据存储

背靠 ARMS 已有的基础设施,指标通过 ARMS Prometheus 进行存储,日志 / 链路通过 XTRACE 进行存储。

产品外围性能介绍

外围场景上反对架构感知、错慢申请剖析、资源耗费剖析、DNS 解析性能剖析、内部性能剖析、服务连通性剖析和网络流量剖析。反对这些场景的根底是产品在设计上遵循了从整体到个体的准则:先从全局视图动手,发现异常的服务个体,如某个 Service,定位到这个 Service 后查看这个 Service 的黄金指标、关联信息、Trace 等进行进一步关联剖析。


图 7 外围业务场景

永不过期的黄金指标

什么是黄金指标?用来可观测性零碎性能和状态的最小汇合:latency、traffic、errors、saturation。以下引自 SRE 圣经 Site Reliability Engineering 一书:

The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.

为什么黄金指标十分重要?一,间接了然地表白了零碎是否失常对外服务。二,面向客户的,能进一步评估对用户的影响或事态的严重性,这样能大量节俭 SRE 或研发的工夫,设想下如果咱们取 CPU 使用率作为黄金指标,那么 SRE 或研发将会奔于疲命,因为 CPU 使用率高可能并不会造成多大的影响,尤其在运行安稳的 Kubernetes 环境中。所以 Kubernetes 可观测性反对这些黄金指标:

  • 申请数 /QPS
  • 响应工夫及分位数(P50、P90、P95、P99)
  • 谬误数
  • 慢调用数


图 8 黄金指标

次要反对以下场景:

1、性能剖析
2、慢调用剖析

全局视角的利用拓补

不谋全局者,有余谋一域。– 诸葛亮

随着当下技术架构、部署架构的复杂度越来越高,产生问题后定位问题变得越来越辣手,进而导致 MTTR 越来越高。另一个影响是对影响面的剖析带来十分大的挑战,通常顾得了这头顾不了那头。因而,有一张像地图一样的大图十分必要。全局拓扑具备以下特点:

  • 零碎架构感知:零碎架构图通常称为程序员理解一个新零碎的重要参考,当咱们拿到一个零碎,起码咱们得晓得流量的入口在哪里,有哪些外围模块,依赖了哪些外部内部组件等。在异样定位过程中,有一张全局架构的图对异样定位过程有十分大的推动作用。一个简略电商利用的拓扑示例,整个架构一览无遗:


图 9 架构感知

  • 依赖剖析:有一些问题是呈现在上游依赖,如果这个依赖不是本人团队保护就会比拟麻烦,当本人零碎和上游零碎没有足够的可观测性的时候就更麻烦了,这种状况下就很难跟依赖的维护者讲清楚问题。在咱们的拓扑中,通过将黄金指标的上下游用调用关系连起来,造成了一张调用图。边作为依赖的可视化,能查看对应调用的黄金信号。有了黄金信号就能疾速地剖析上游依赖是否存在问题。下图为底层服务调用微服务产生慢调用导致利用整体 RT 高的定位示例,从入口网关,到外部服务,到 MySQL 服务,最终定位到产生慢 SQL 的语句:


图 10 依赖剖析

  • 高可用剖析:拓扑图能不便地看出零碎之间的交互,从而看出哪些零碎是次要外围链路或者是被重度依赖的,比方 CoreDNS,简直所有的组件都会通过 CoreDNS 进行 DNS 解析,所以咱们进一步看到可能存在的瓶颈,通过查看 CoreDNS 的黄金指标预判利用是否衰弱、是否容量有余等。


图 11 高可用剖析

  • 无侵入:跟蚂蚁的 linkd 和团体的 eagleeye 不同的是,咱们的计划是齐全无侵入的。有时候咱们之所以短少某个方面的可观测性,并不是说做不到,而是因为利用须要改代码。作为 SRE 为了更好的可观测性诚然出发点很好,然而要让全团体的利用 owner 陪你一起改代码,显然是不适合的。这时候就显示出无侵入的威力了:利用不须要改代码,也不须要重启。所以在接入老本上是非常低的。

协定 Trace 不便根因定位

协定 Trace 区别于分布式追踪,只跟踪一次调用。协定 Trace 同样是无入侵、语言无关的。如果申请内容中存在分布式链路 TraceID,能自动识别进去,不便进一步下钻到链路追踪。应用层协定的申请、响应信息有助于对申请内容、返回码进行剖析,从而晓得具体哪个接口有问题。


图 12 协定详情

开箱即用的告警性能

任何一个可观测性零碎不反对告警是不适合的。

1、默认模板下发,阈值通过业界最佳实际。


图 13 告警

2、反对用户多种配置形式

动态阈值,用户只须要配置阈值即可,不须要手动写 PromQL
基于灵敏度调节的动静阈值,适宜不好确定阈值的场景
兼容 PromQL,须要肯定的学习老本,适宜高级用户

丰盛的上下文关联

datadog 的 CEO 在一次采访中婉言 datadog 的产品策略不是反对越多功能越好,而是思考怎么在不同团队和成员之间架起桥梁,尽可能把信息放在同一个页面中(to bridge the gap between the teams and get everything on the same page)。产品设计上咱们将要害的上下文信息关联起来,不便不同背景的工程师了解,从而减速问题的排查。

目前咱们关联的上下文有告警信息、黄金指标、日志、Kubernetes 元信息等,同时一直新增有价值的信息。比方告警信息,告警信息主动关联到对应的服务或利用节点上,清晰地看到哪些利用有异样,点击利用或告警能主动开展利用的详情、告警详情、利用的黄金指标,所有的动作都在一个页面中进行:


图 14 上下文关联

其余

一、网络性能可观测性:

网络性能导致响应工夫变长是常常遇到的问题,因为 TCP 底层机制屏蔽了一部分的复杂性,应用层对此是无感的,这对丢包率高、重传率高这种场景带来一些麻烦。Kubernetes 反对了重传 & 丢包、TCP 连贯信息来表征网络情况,下图展现了重传高导致 RT 高的例子:


图 15 网络性能可观测性

eBPF 超能力揭秘


图 16 数据处理流程

eBPF 相当于在内核中构建了一个执行引擎,通过内核调用将这段程序 attach 到某个内核事件上,做到监听内核事件;有了事件咱们就能进一步做协定推导,筛选出感兴趣的协定,对事件进一步解决后放到 ringbuffer 或者 eBPF 自带的数据结构 Map 中,供用户态过程读取;用户态过程读取这些数据后,进一步关联 Kubernetes 元数据后推送到存储端。这是整体处理过程。

eBPF 的超能力体现在能订阅各种内核事件,如文件读写、网络流量等,运行在 Kubernetes 中的容器或者 Pod 里的所有行为都是通过内核零碎调用来实现的,内核晓得机器上所有过程中产生的所有事件,所以内核简直是可观测性的最佳观测点,这也是咱们为什么抉择 eBPF 的起因。另一个在内核上做监测的益处是利用不须要变更,也不须要从新编译内核,做到了真正意义上的无侵入。当集群里有几十上百个利用的时候,无侵入的解决方案会帮上大忙。

eBPF 作为新技术,人们对其有些担心是失常的,这里别离作简略的答复:

1、eBPF 安全性如何?eBPF 代码有诸多限度,如最大堆栈空间以后为 512、最大指令数为 100 万,这些限度的目标就是充分保证内核运行时的安全性。

2、eBPF 探针的性能如何?大概在 1% 左右。eBPF 的高性能次要体现在内核中解决数据,缩小数据在内核态和用户态之间的拷贝。简略说就是数据在内核里算好了再给用户过程,比方一个 Gauge 值,以往的做法是将原始数据拷贝到用户过程再计算。

总结

产品价值

阿里云 Kubernetes 可观测性是一套针对 Kubernetes 集群开发的一站式可观测性产品。基于 Kubernetes 集群下的指标、利用链路、日志和事件,阿里云 Kubernetes 可观测性旨在为 IT 开发运维人员提供整体的可观测性计划。

阿里云 Kubernetes 可观测性具备以下个性:

  • 代码无侵入:通过旁路技术,不须要对代码进行埋点即可获取到丰盛的网络性能数据。
  • 语言无关:在内核层面进行网络协议解析,反对任意语言,任意框架。
  • 高性能:基于 eBPF 技术,能以极低的耗费获取丰盛的网络性能数据。
  • 强关联:通过网络拓扑,资源拓扑,资源关系从多个维度形容实体关联,与此同时也反对各类数据(可观测指标、链路、日志和事件)之间的关联。
  • 数据端到端笼罩:涵盖端到端软件栈的观测数据。
  • 场景闭环:控制台的场景设计,关联起架构感知拓扑、利用可观测性、Prometheus 可观测性、云拨测、衰弱巡检、事件核心、日志服务和云服务,蕴含利用了解,异样发现,异样定位的残缺闭环。

点击此处,返回阿里云可观测专题页查看更多详情!

图片起源:

图 1:
https://www.infoq.com/present…

图 2:
https://www.lackuna.com/2013/…

图 6:
https://opentelemetry.io/docs…

欢送大家扫码或搜寻钉钉群号(31588365)退出答疑交换群进行交换。

退出移动版