源码分析系列文章已经开源到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文件：
这时候scheduler是运行状态：
2、挪开yaml文件，让scheduler停止：
这时候再看scheduler可以发现pod已经没了
3. 配置goland
在main函数前面点一下这个绿色的三角形，当然这样运行肯定会失败，但是点一下会为我们生成一些配置，可以简化很多事情。点完之后开始配置：
点击上面的Edit，可以看到下面窗口：
这里的Program arguments默认是空的，我们怎么知道这里配置啥呢？
从前面挪动的yaml中可以看到如下配置：
很明显，拷贝这个scheduler.conf到goland所在的机子，加上--kubeconfig这个flag之后就可以运行了。从前面的截图中可以看到我是将其放在了/etc/kubernetes/scheduler.conf.
开启调试：
如上，进入了熟悉的界面。
当然到这里还没有和api server交互，要进入调度逻辑需要有待调度的pod才行。我们使用前面验证环境的使用的tomcat：
创建这个Deployment之后可以看到pod是pending的：
我们把断点打在scheduleOne()里面：
非常熟悉的界面来了：
这样就能跟到调度器里的各种逻辑了。
当调度器跑完后，pod也就起来了：
最后说下我的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这一节放在调度器那章里感觉又不合适，最后决定放在环境准备里面。让新接触本书的小伙伴可以早点看到，灵活决定开始调试的时间。放在这里的话讲太多调度器的知识也不合适。所以这次就不多说具体代码的调试了，在各个章节里如果哪个模块讲解时我觉得需要插一个调试过程，就直接插在对应的地方吧～