源碼分析系列文章已經開源到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這一節放在調度器那章里感覺又不合適，最后決定放在環境准備里面。讓新接觸本書的小伙伴可以早點看到，靈活決定開始調試的時間。放在這里的話講太多調度器的知識也不合適。所以這次就不多說具體代碼的調試了，在各個章節里如果哪個模塊講解時我覺得需要插一個調試過程，就直接插在對應的地方吧～
