《k8s-1.13版本源码分析》-源码调试

时间:2021-06-09 07:01:12

源码分析系列文章已经开源到github,地址如下:

  • github:https://github.com/farmer-hutao/k8s-source-code-analysis
  • gitbook:https://farmer-hutao.github.io/k8s-source-code-analysis

源码调试

1. 概述

本节内容并不是在准备好k8s环境后就写的,大家也不需要在开始看源码前研究怎么调试代码。今天之前我已经发了《调度器优选过程》也就是差不多准备好k8s环境后一个月了。所以大家也可以先跳过本节,先开始看后面的源码分析,灵活把握开始调试源码的时间吧。

Debug应该是所有“攻城狮”的基本技能。除非是“Hello World”之类的小程序,不然都会出错,俗称bug,有bug就要debug. 今天不赘述调试本身的技术,我们只以调度器为例聊聊怎么把k8s的代码单步执行跑起来,看看内存里是个啥~

2. k8s环境

我们前面已经搭建了3节点的集群,相关组件主要是static pod的方式在运行,所以调试调度器的时候我们应该把kube-scheduler容器停掉:

1、找到static pod 的yaml文件:

《k8s-1.13版本源码分析》-源码调试

这时候scheduler是运行状态:

《k8s-1.13版本源码分析》-源码调试

2、挪开yaml文件,让scheduler停止:

《k8s-1.13版本源码分析》-源码调试

这时候再看scheduler可以发现pod已经没了

《k8s-1.13版本源码分析》-源码调试

3. 配置goland

《k8s-1.13版本源码分析》-源码调试

在main函数前面点一下这个绿色的三角形,当然这样运行肯定会失败,但是点一下会为我们生成一些配置,可以简化很多事情。点完之后开始配置:

《k8s-1.13版本源码分析》-源码调试

点击上面的Edit,可以看到下面窗口:

《k8s-1.13版本源码分析》-源码调试

这里的Program arguments默认是空的,我们怎么知道这里配置啥呢?

从前面挪动的yaml中可以看到如下配置:

《k8s-1.13版本源码分析》-源码调试

很明显,拷贝这个scheduler.conf到goland所在的机子,加上--kubeconfig这个flag之后就可以运行了。从前面的截图中可以看到我是将其放在了/etc/kubernetes/scheduler.conf.

开启调试:

《k8s-1.13版本源码分析》-源码调试

如上,进入了熟悉的界面。

当然到这里还没有和api server交互,要进入调度逻辑需要有待调度的pod才行。我们使用前面验证环境的使用的tomcat:

《k8s-1.13版本源码分析》-源码调试

创建这个Deployment之后可以看到pod是pending的:

《k8s-1.13版本源码分析》-源码调试

我们把断点打在scheduleOne()里面:

《k8s-1.13版本源码分析》-源码调试

非常熟悉的界面来了:

《k8s-1.13版本源码分析》-源码调试

这样就能跟到调度器里的各种逻辑了。

当调度器跑完后,pod也就起来了:

《k8s-1.13版本源码分析》-源码调试

最后说下我的goland是跑在哪里的:

  • k8s master:29.123.161.240
  • k8s node:29.123.161.207 29.123.161.208
  • goland:29.123.161.241

所以goland不在k8s集群内。当然这个没有啥讲究,也可以跑在一起,灵活决定。

4. 写在后面

本来计划讲一下scheduler里的一些主要流程的调试,但是debug这一节放在调度器那章里感觉又不合适,最后决定放在环境准备里面。让新接触本书的小伙伴可以早点看到,灵活决定开始调试的时间。放在这里的话讲太多调度器的知识也不合适。所以这次就不多说具体代码的调试了,在各个章节里如果哪个模块讲解时我觉得需要插一个调试过程,就直接插在对应的地方吧~

《k8s-1.13版本源码分析》-源码调试