2022- 基于eBPF 的Kubernetes 问题排查全景图
当Kubernetes 成为云原生事实标准,可观测性挑战随之而来
当前,云原生技术以容器技术为基础,通过标准可扩展的调度、网络、存储、容器运行时接口来提供基础设施。同时,通过标准可扩展的声明式资源和控制器来提供运维能力,两层标准化推动了开发与运维关注点分离,各领域进一步提升规模化和专业化,达到成本、效率、稳定性的全面优化。
在这样的大技术背景下,越来越对的公司引入了云原生技术来开发、运维业务应用。正因为云原生技术带来了越发纷繁复杂的可能性,业务应用出现了微服务众多、多语言开发、多通信协议的鲜明特征。同时,云原生技术本身将复杂度下移,给可观测性带来了更多挑战:
混沌的微服务架构,多语言和多网络协议混杂
业务架构因为分工问题,容易出现服务数量多,调用协议和关系非常复杂的现象,导致的常见问题包括:
- 无法准确清晰了解、掌控全局的系统运行架构;
- 无法回答应用之间的连通性是否正确;
- 多语言、多网络调用协议带来埋点成本呈线性增长,且重复埋点
ROI 低,开发一般将这类需求优先级降低,但可观测数据又不得不采集。
下沉的基础设施能力屏蔽实现细节,问题定界越发困难
基础设施能力继续下沉,开发和运维关注点继续分离,分层后彼此屏蔽了实现细节,数据方面不好关联了,出现问题后不能迅速地定界问题出现在哪一层。开发同学只关注应用是否正常工作,并不关心底层基础设施细节,出现问题后需要运维同学协同排查问题。运维同学在问题排查过程中,需要开发同学提供足够的上下游来推进排查,否则只拿到“某某应用延迟高”这么笼统的表述,这很难有进一步结果。所以,开发同学和运维同学之间需要共同语言来提高沟通效率,
繁多监测系统,造成监测界面不一致
复杂系统带来的一个严重副作用就是监测系统繁多。数据链路不关联、不统一,监测界面体验不一致。很多运维同学或许大多都有过这样的体验:定位问题时浏览器打开几十个窗口,在
为了解决上述问题,我们需要使用一种支持多语言,多通信协议的技术,并在产品层面尽可能覆盖软件栈端到端的可观测性需求,通过调研,我们提出一种立足于容器界面和底层操作系统,向上关联应用性能监测的可观测性解决思路。
Kubernetes 可观测性全景视角
有了上述产品能力,基于阿里巴巴在容器、
- 大体结构上是以服务和
Deployment (应用)为入口,大多数开发只需要关注这一层就行了。重点关注服务和应用是否错慢,服务是否连通,副本数是否符合预期等 - 再往下一层是提供真正工作负载能力的
Pod 。Pod 重点关注是否有错慢请求,是否健康,资源是否充裕,下游依赖是否健康等 - 最底下一层是节点,节点为
Pod 和服务提供运行环境和资源。重点关注节点是否健康,是否处于可调度状态,资源是否充裕等。
网络问题
网络是
Kubernetes 的网络架构复杂度高,节点、Pod、容器、服务、VPC 交相辉映,简直能让你眼花缭乱;- 网络问题排查需要一定的专业知识,大多数对网络问题都有种天生的恐惧;
- 分布式
8 大谬误告诉我们网络不是稳定的、网络拓扑也不一成不变的、延时不可忽视,造成了端到端之间的网络拓扑不确定性。
conntrack 记录满问题;IP 冲突;CoreDNS 解析慢、解析失败;- 节点没开外网
。 (对,你没听错) ; - 服务访问不通;
- 配置问题(
LoadBalance 配置、路由配置、device 配置、网卡配置) ; - 网络中断造成整个服务不可用。
网络问题千千万万,但万变不离其宗的是网络有其表征其是否正常运行的”黄金指标“:
- 网络流量和带宽;
- 丢包数(率)和重传数(率
) ; - RTT。
下面的示例展示了因网络问题导致的慢调用问题。从
节点问题
针对这些繁杂的问题,总结出如下排查流程图:
以一个
1、节点状态
2、查看对应的
服务响应慢
造成服务响应非常多,场景可能的原因有代码设计问题、网络问题、资源竞争问题、依赖服务慢等原因。在复杂的
-
横向:主要是端到端层面来看,首先看自己服务的黄金指标是否有问题,再逐步看下游的网络指标。注意如果从客户端来看调用下游耗时高,但从下游本身的黄金指标来看是正常的,这时候非常有可能是网络问题或者操作系统层面的问题,此时可以用网络性能指标(流量、丢包、重传、
RTT 等)来确定。 -
纵向:确定应用本身对外的延时高了,下一步就是确定具体哪个原因了,确定哪一步
/ 哪个方法慢可以用火焰图来看。如果代码没有问题,那么可能执行代码的环境是有问题的,这时可以查看系统的CPU/Memory 等资源是否有问题来做进一步排查。
下面举个
第二个例子是应用本身慢的例子,这时候自然会问具体哪一步、哪个函数造成了慢,
应用/Pod 状态问题
接下来我们看一个典型的案例:下游服务在发布过程中灰度了一个