使用节点仪表板可视化Kubelet性能

在捕鱼大亨网络版 1.4中,我们引入了一种新的节点性能分析工具,称为 节点性能仪表板,以更丰富的细节可视化和探索Kubelet的行为。这项新功能将使Kubelet开发人员更容易理解和提高代码性能,并使群集维护人员根据提供的服务水平目标(SLO)设置配置。

背景

捕鱼大亨网络版 集群由主节点和工作节点组成。主节点管理集群的状态,工作节点执行运行和管理Pod的实际工作。为此,在每个工作程序节点上,都有一个称为 Kubelet ,监视容器配置中的任何更改,并采取相应的措施以确保容器成功运行。对于整个捕鱼大亨网络版集群来说,Kubelet的高性能(例如,与新的pod配置融合的低延迟和低资源使用率的高效内务处理)都是至关重要的。为了衡量这种性能,捕鱼大亨网络版使用 端到端(e2e)测试 以不断监视具有新功能的最新版本的基准更改。

捕鱼大亨网络版 SLO由以下基准定义 :

* API响应度 :99%的所有API调用在不到1秒的时间内返回。
* Pod启动时间 :99%的吊舱及其容器(带有预拉图像)在5秒钟内开始。

在1.4版之前,我们仅在集群级别进行了测量和定义,从而增加了其他因素可能影响结果的风险。除此之外,我们还希望拥有更多与性能相关的SLO,例如特定机器类型的Pod的最大数量,以最大程度地利用群集。为了正确进行测量,我们希望引入一组仅针对节点性能的测试。此外,我们的目标是从新测试中收集更多细粒度的Kubelet资源使用情况和操作跟踪数据。

数据采集

从1.4开始,现在将节点特定密度和资源使用情况测试添加到e2e节点测试集中。资源使用情况由独立的cAdvisor窗格测量,以实现灵活的监视间隔(与Kubelet集成的cAdvisor相比)。性能数据(例如延迟和资源使用百分比)记录在持久性测试结果日志中。这些测试还记录时间序列数据,例如创建时间,pod的运行时间以及实时资源使用情况。 Kubelet 操作的跟踪数据与测试结果一起记录在其日志中。

节点性能仪表板

从捕鱼大亨网络版 1.4开始,我们将不断构建最新的Kubelet代码并运行节点性能测试。数据是通过我们新的性能信息中心收集的,网址为: node-perf-dash.k8s.io。图1给出了仪表板的预览。您可以通过选择测试来开始探索它,方法是使用简短测试名称(区域(a))的下拉列表,或者一个接一个地选择测试选项(区域(b))。测试详细信息显示在(c)区域中,其中包含来自Ginkgo(捕鱼大亨网络版使用的Go测试框架)的完整测试名称。然后在区域(d)中选择节点类型(图像和机器)。

| | |图1.选择一个要显示在节点性能仪表板上的测试。 |

“ BUILDS”页面显示了不同版本之间的性能数据(图2)。这些图包括Pod启动延迟,Pod创建吞吐量以及Kubelet和运行时(当前为Docker)的CPU /内存使用情况。这样,当签入新功能时,很容易监视性能随时间的变化。

| | |图2.不同构建之间的性能数据。 |

比较不同的节点配置

比较不同配置之间的性能总是很有趣的,例如比较不同机器类型,不同数量的Pod的启动等待时间,或者比较托管不同数量的Pod的资源使用情况。仪表板提供了一种方便的方法。只需单击测试选择菜单右上角的“比较”按钮(图1中的区域(e))。选定的测试将被添加到“ COMPARISON”页面的比较列表中,如图3所示。一系列构建中的数据被汇总为一个值以方便比较,并显示在条形图中。

| | |图3.比较不同的测试配置。 |

时间序列和跟踪:深入研究绩效数据

吊舱启动延迟是Kubelet的重要指标,尤其是在每个节点创建大量吊舱时。使用仪表板,您可以看到延迟的变化,例如,在创建105个窗格时,如图4所示。当您看到高度可变的行时,您可能会认为差异是由于不同的构建造成的。但是,由于此处的测试是针对相同的捕鱼大亨网络版代码运行的,因此我们可以得出结论,差异是由于性能波动引起的。当我们比较内部版本#162和#173的99%延迟时,方差接近40s,这是非常大的。要深入了解波动的原因,请查看“时间序列”页面。

| | |图4.创建105个吊舱时的吊舱启动延迟。 |

专门查看版本162,我们可以看到在pod创建延迟图表中绘制的跟踪数据(图5)。每条曲线是已经到达某个跟踪探针的吊舱操作数量的累积直方图。跟踪Pod的时间戳是从性能测试中收集的,或者是通过分析Kubelet日志收集的。当前,我们收集以下跟踪数据:

  • “创建”(在测试中):测试通过API客户端创建容器;
  • “正在运行”(测试中):测试监视pod正在从API服务器运行;
  • “ pod_config_change”:Kubelet SyncLoop检测到的pod配置更改;
  • “ runtime_manager”:运行时管理器开始创建容器;
  • “ infra_container_start”:容器的基础容器启动;
  • “ container_start”:容器的容器开始;
  • “ pod_running”:窗格正在运行;
  • “ pod_status_running”:状态管理器更新正在运行的pod的状态;

时间序列图说明状态管理器需要很长时间才能更新容器状态(由于与“ pod_status_running”重叠,因此未显示“正在运行”的数据)。我们发现此延迟是由于Kubelet向API服务器的每秒查询(QPS)限制(默认值为5)而引入的。意识到这一点之后,我们在其他测试中发现,通过增加QPS限制,曲线“运行”逐渐与“ pod_running”收敛,并导致更低的延迟,因此以前的e2e测试吊舱启动结果反映了两个Kubelet的组合延迟以及上传状态的时间,因此Kubelet的性能被低估了。

| | |图5.使用来自版本162的数据的时间序列页面。 |

此外,通过比较内部版本号162(图5)和内部版本号173(图6)的时间序列数据,我们发现性能容器启动延迟实际上是在更新容器状态期间发生的。版本162具有多个延迟时间长的拖尾“ pod_status_running”事件。因此,它为将来的优化提供了有用的想法。 

| | |图6.构建#173的Pod启动延迟。 |

将来,我们计划在捕鱼大亨网络版中使用事件,该事件具有固定的日志格式,以便更方便地收集跟踪数据。您可以提取自己的跟踪探针而不是提取现有的日志条目,而将其插入Kubelet并获取每个段的分解延迟。 

您可以在“ TRACING”页面中检查跨不同版本的任意两个探针之间的等待时间,如图7所示。例如,通过选择“ pod_config_change”作为开始探针,并选择“ pod_status_running”作为结束探针,它可以提供连续构建过程中Kubelet的延迟差异,而无需状态更新开销。开发人员可以监视Kubelet中特定代码部分的性能变化。

| | |图7.绘制任意两个探针之间的等待时间。 |

未来的工作

节点性能仪表板 是一项全新功能。它仍处于积极开发中的Alpha版本。我们将继续优化数据收集和可视化,为开发人员和集群维护人员提供更多测试,指标和工具。 

请加入我们的社区,并帮助我们打造捕鱼大亨网络版的未来!如果您对节点或性能测试特别感兴趣,请通过与我们聊天来参与 松弛通道 或参加我们在太平洋标准时间每周二上午10点开会的会议 SIG节点环聊 .

-周芳,Google软件工程实习生