k8s原始碼分析-----kubelet（8）pod管理
說明：此文章為騰訊雲機器自動從本人csdn部落格搬遷過來。是本人授權操作。
申明：無本人授權，不可轉載本文。如有轉載，本人保留追究其法律責任的權利。
龔浩華，QQ 29185807，月牙寂 道長
第一時間獲取文章，可以關注本人公眾號 月牙寂道長 yueyajidaozhang
原始碼為k8s v1.1.1穩定版本
3、Pod管理
前面的7篇文章都是為這篇文章做準備的。終於要進入到正題中，pod的管理
3.1 pod清單
1、引數
程式碼在k8s.iokubernetescmdkubeletapp中
結構體變數
type KubeletServer struct { ... Config string FileCheckFrequency time.Duration ManifestURL string ManifestURLHeader string HTTPCheckFrequency time.Duration ... }
預設引數
func NewKubeletServer() *KubeletServer {
return &KubeletServer{
...
FileCheckFrequency: 20 * time.Second,
HTTPCheckFrequency: 20 * time.Second,
...
}
}flag引數
func (s *KubeletServer) AddFlags(fs *pflag.FlagSet) { ... fs.StringVar(&s.Config, "config", s.Config, "Path to the config file or directory of files") fs.DurationVar(&s.FileCheckFrequency, "file-check-frequency", s.FileCheckFrequency, "Duration between checking config files for new data") fs.StringVar(&s.ManifestURL, "manifest-url", s.ManifestURL, "URL for accessing the container manifest") fs.StringVar(&s.ManifestURLHeader, "manifest-url-header", s.ManifestURLHeader, "HTTP header to use when accessing the manifest URL, with the key separated from the value with a ':', as in 'key:value'") fs.DurationVar(&s.HTTPCheckFrequency, "http-check-frequency", s.HTTPCheckFrequency, "Duration between checking http for new data") ... }
Config：配置的檔案路徑或目錄
FileCheckFrequency：檔案定期檢查文變化間隔
ManifestURL：獲取pod定義的url地址
ManifestURLHeader：頭部定義
HTTPCheckFrequency：url定期獲取時間間隔
2、構建
我們看看生產者的構建
入口是在createAndInitKubelet中
繼續makePodSourceConfig
這裡構建了一個chan，並作為返回值返回給了上一級呼叫者。
然後生產方式一共有三種
1、檔案方式
程式碼在k8s.iokubernetespkgkubeletconfigfile.go
初始化了檔案路徑，nodename，還有一個updates的chan
然後開起了一個定期執行的run
從上圖我們看到，檢測檔案目錄，然後將pod資訊通過chan傳送出去
2、url方式
程式碼在k8s.iokubernetespkgkubeletconfighttp.go
初始化了url路徑，header，還有定期時間間隔，最後也有一個chan
上圖中構建了一個http Client，然後進行了http get請求
上圖中，將獲取到的資訊解碼，然後將解析出來的pod資訊傳送給chan
3、Api server方式
程式碼在k8s.iokubernetespkgkubeletconfigapiserver.go
這個比較簡單，構建了一個listwatcher，然後將獲取到的pod資訊傳送到chan
4、小結
通過三種方式進行pod資訊的獲取，也就是生產者，通過chan的方式法送給消費者。
3.2 pod管理
上一節中，我們已經知道了生產者，通過chan的方式傳送給消費者
1、傳遞管道
在makePodSourceConfig中初始化了一個cfg
我們來看看cfg是什麼
程式碼在k8s.iokubernetespkgkubeletconfigconfig.go
然後三種方式分別註冊了不同的chan
傳送給消費者的介面
注：這裡的程式碼其實需要深入的話，需要去分析config.Mux，這個程式碼比較簡單，這裡篇幅關係就不做分析了。
2、構建與工作流程
構建
程式碼在k8s.iokubernetescmdkubeletapp中
podcfg就是上面構建的傳送管道，最後啟動了kubelet的Run函式
工作流程
程式碼在k8s.iokubernetespkgkubeletkubelet.go
run中的manager我們在之前的文章中基本都有介紹。最後進行syncLoop，其引數updates就是傳送的管道
我們繼續跟蹤
其中的update被傳遞下來了，handler其實就是kubelet自身
再繼續跟蹤
終於到了處理地方。
從傳送管道中，獲取到pod資訊，然後根據pod的型別，分別呼叫了不同的處理介面。
我們也說了handler其實就是kubelet自身
1、add
呼叫了func (kl *Kubelet) HandlePodAdditions(pods []*api.Pod) {
2、update
呼叫了func (kl *Kubelet) HandlePodUpdates(pods []*api.Pod) {
3、remove
呼叫了func (kl *Kubelet) HandlePodDeletions(pods []*api.Pod) {
呼叫了deletepod
通過chan把pod傳送給了podkillingch
從上面可以看到，接收到需要kill的pod然後最終呼叫了killpod。而從下圖，我們看到其實最終呼叫了containerrumtime的killpod，這個我們在上一篇文章中已經講解過了。
4、set
暫時不支援
5、定時sync
呼叫了func (kl *Kubelet) HandlePodSyncs(pods []*api.Pod) {
我們看到add update sync都最後呼叫了dispatchWork。下一篇我們就來分析podwork