摘要：源碼版本介紹在分析啟動流程時，老是會碰到各類，這里多帶帶提出來做下較詳細的分析。主要由兩部分組成使用指定的回收策略，刪除那些已經結束的所有的生命周期管理就是通過來實現的，其實該也是依賴了。相關配置該值表示磁盤占用率達到該值后會觸發。

kubernetes version： v1.3.0

在分析kubelet啟動流程時，老是會碰到各類GC，這里多帶帶提出來做下較詳細的分析。
kubelet"s Garbage Collection主要由兩部分組成：

containerGC: 使用指定的container回收策略，刪除那些已經結束的containers

imageManager: k8s所有images的生命周期管理就是通過imageManager來實現的，其實該imageManager也是依賴了cAdvisor。

imageManager的回收策略結構如下：

type ImageGCPolicy struct {
    // Any usage above this threshold will always trigger garbage collection.
    // This is the highest usage we will allow.
    HighThresholdPercent int

    // Any usage below this threshold will never trigger garbage collection.
    // This is the lowest threshold we will try to garbage collect to.
    LowThresholdPercent int

    // Minimum age at which a image can be garbage collected.
    MinAge time.Duration
}

該結構的出廠設置在cmd/kubelet/app/server.go中的UnsecuredKubeletConfig()接口進行。

func UnsecuredKubeletConfig(s *options.KubeletServer) (*KubeletConfig, error) {
...
    imageGCPolicy := kubelet.ImageGCPolicy{
            MinAge:               s.ImageMinimumGCAge.Duration,
            HighThresholdPercent: int(s.ImageGCHighThresholdPercent),
            LowThresholdPercent:  int(s.ImageGCLowThresholdPercent),
        }
...
}

賦值的KubeletServer的幾個參數的初始化在cmd/kubelet/app/options/options.go中的NewKubeletServer()接口中進行：

func NewKubeletServer() *KubeletServer {
    return &KubeletServer{
        ...
        ImageMinimumGCAge:            unversioned.Duration{Duration: 2 * time.Minute},
        ImageGCHighThresholdPercent:  90,
        ImageGCLowThresholdPercent:   80,
        ...
    }
}

從上面的初始化過程可以得出：

在磁盤的占用率高于90%時，imageGC將一直被觸發

在磁盤的占用率低于80%時，imageGC將不會觸發

imageGC會嘗試先delete最少使用的image，但是如果該image的創建時間才低于2min，將不會被刪除。

上面介紹的都是imageManager的回收策略參數初始化，下面開始介紹imageManager。
結構所在目錄：pkg/kubelet/image_manager.go
結構如下：

type imageManager interface {
    // Applies the garbage collection policy. Errors include being unable to free
    // enough space as per the garbage collection policy.
    GarbageCollect() error

    // Start async garbage collection of images.
    Start() error

    GetImageList() ([]kubecontainer.Image, error)

    // TODO(vmarmol): Have this subsume pulls as well.
}

可以看到imageManager是個interface,實際初始化的結構體是realImageManager：

type realImageManager struct {
    // Container runtime
    runtime container.Runtime

    // Records of images and their use.
    imageRecords     map[string]*imageRecord
    imageRecordsLock sync.Mutex

    // The image garbage collection policy in use.
    policy ImageGCPolicy

    // cAdvisor instance.
    cadvisor cadvisor.Interface

    // Recorder for Kubernetes events.
    recorder record.EventRecorder

    // Reference to this node.
    nodeRef *api.ObjectReference

    // Track initialization
    initialized bool
}

該接口的初始化需要先回到pkg/kubelet/kubelet.go中的NewMainKubelet()接口中：

func NewMainKubelet(
    hostname string,
    nodeName string,
...
) (*Kubelet, error) {
...
    // setup containerGC
    containerGC, err := kubecontainer.NewContainerGC(klet.containerRuntime, containerGCPolicy)
    if err != nil {
        return nil, err
    }
    klet.containerGC = containerGC

    // setup imageManager
    imageManager, err := newImageManager(klet.containerRuntime, cadvisorInterface, recorder, nodeRef, imageGCPolicy)
    if err != nil {
        return nil, fmt.Errorf("failed to initialize image manager: %v", err)
    }
    klet.imageManager = imageManager
...
}

可以看到上面的接口中對containerGC和imageManager都進行了初始化,這里先介紹imageManager,containerGC留到下面再講。
newImageManager()接口如下：

func newImageManager(runtime container.Runtime, cadvisorInterface cadvisor.Interface, recorder record.EventRecorder, nodeRef *api.ObjectReference, policy ImageGCPolicy) (imageManager, error) {
    // 檢查policy參數有效性
    if policy.HighThresholdPercent < 0 || policy.HighThresholdPercent > 100 {
        return nil, fmt.Errorf("invalid HighThresholdPercent %d, must be in range [0-100]", policy.HighThresholdPercent)
    }
    if policy.LowThresholdPercent < 0 || policy.LowThresholdPercent > 100 {
        return nil, fmt.Errorf("invalid LowThresholdPercent %d, must be in range [0-100]", policy.LowThresholdPercent)
    }
    if policy.LowThresholdPercent > policy.HighThresholdPercent {
        return nil, fmt.Errorf("LowThresholdPercent %d can not be higher than HighThresholdPercent %d", policy.LowThresholdPercent, policy.HighThresholdPercent)
    }
    // 初始化realImageManager結構
    im := &realImageManager{
        runtime:      runtime,
        policy:       policy,
        imageRecords: make(map[string]*imageRecord),
        cadvisor:     cadvisorInterface,
        recorder:     recorder,
        nodeRef:      nodeRef,
        initialized:  false,
    }

    return im, nil
}

查看上面的初始化接口，可以看出該imageManager跟容器runtime、cAdvisor、EventRecorder、nodeRef、Policy都有關。
這里可以進行大膽的猜測：

runtime用于進行image的刪除操作

cAdvisor用于獲取image占用磁盤的情況

EventRecorder用于發送具體的回收事件

Policy就是具體的回收策略了

nodeRef干嘛的？猜不到，還是后面繼續看源碼吧！

所有的參數初始化結束后，需要開始進入真正的GC啟動流程，該步驟還是需要查看CreateAndInitKubelet()接口。
接口目錄：cmd/kubelet/app/server.go
接口調用流程：main -> app.Run -> run -> RunKubelet -> CreateAndInitKubelet
接口如下：

func CreateAndInitKubelet(kc *KubeletConfig) (k KubeletBootstrap, 
    pc *config.PodConfig, err error) {
...
    k.StartGarbageCollection()

    return k, pc, nil
}

該接口調用了啟動GC的接口StartGarbageCollection()，具體實現如下：

func (kl *Kubelet) StartGarbageCollection() {
    go wait.Until(func() {
        if err := kl.containerGC.GarbageCollect(kl.sourcesReady.AllReady()); err != nil {
            glog.Errorf("Container garbage collection failed: %v", err)
        }
    }, ContainerGCPeriod, wait.NeverStop)

    go wait.Until(func() {
        if err := kl.imageManager.GarbageCollect(); err != nil {
            glog.Errorf("Image garbage collection failed: %v", err)
        }
    }, ImageGCPeriod, wait.NeverStop)
}

上面的接口分別啟動了containerGC和imageManager的協程，可以看出containerGC是每1分鐘觸發回收，imageManager是每5分鐘觸發回收。
該GarbageCollect()接口需要根據之前參數初始化時的realImageManager結構進行查看，進入kl.imageManager.GarbageCollect()一看究竟：

func (im *realImageManager) GarbageCollect() error {
    // 獲取節點上所存在的images的磁盤占用率
    fsInfo, err := im.cadvisor.ImagesFsInfo()
    if err != nil {
        return err
    }
    // 容量及可利用的空間
    capacity := int64(fsInfo.Capacity)
    available := int64(fsInfo.Available)
    if available > capacity {
        glog.Warningf("available %d is larger than capacity %d", available, capacity)
        available = capacity
    }

    // Check valid capacity.
    if capacity == 0 {
        err := fmt.Errorf("invalid capacity %d on device %q at mount point %q", capacity, fsInfo.Device, fsInfo.Mountpoint)
        im.recorder.Eventf(im.nodeRef, api.EventTypeWarning, container.InvalidDiskCapacity, err.Error())
        return err
    }

    // 查看images的磁盤占用率是否大于等于HighThresholdPercent
    usagePercent := 100 - int(available*100/capacity)
    if usagePercent >= im.policy.HighThresholdPercent {
        // 嘗試去回收images的占用率到LowThresholdPercent之下
        amountToFree := capacity*int64(100-im.policy.LowThresholdPercent)/100 - available
        glog.Infof("[ImageManager]: Disk usage on %q (%s) is at %d%% which is over the high threshold (%d%%). Trying to free %d bytes", fsInfo.Device, fsInfo.Mountpoint, usagePercent, im.policy.HighThresholdPercent, amountToFree)
        // 真正的回收接口
        freed, err := im.freeSpace(amountToFree, time.Now())
        if err != nil {
            return err
        }

        if freed < amountToFree {
            err := fmt.Errorf("failed to garbage collect required amount of images. Wanted to free %d, but freed %d", amountToFree, freed)
            im.recorder.Eventf(im.nodeRef, api.EventTypeWarning, container.FreeDiskSpaceFailed, err.Error())
            return err    ·
        }
    }

    return nil
}

這里最關鍵的接口便是im.freeSpace(),該接口才是真正進行資源回收的接口。
該接口有兩個參數：第一個便是設置這次打算回收的空間，第二個是傳入調用回收接口的當前時間。
具體的回收，我們進入接口繼續細看：

func (im *realImageManager) freeSpace(bytesToFree int64, freeTime time.Time) (int64, error) {
    // 用im.runtime遍歷現存的所有的images,并更新im.imageRecords，下面會用到。
    err := im.detectImages(freeTime)
    if err != nil {
        return 0, err
    }
    // 操作imageRecords的鎖
    im.imageRecordsLock.Lock()
    defer im.imageRecordsLock.Unlock()

    // 獲取所有的images
    images := make([]evictionInfo, 0, len(im.imageRecords))
    for image, record := range im.imageRecords {
        images = append(images, evictionInfo{
            id:          image,
            imageRecord: *record,
        })
    }
    sort.Sort(byLastUsedAndDetected(images))

    // 下面的循環將嘗試刪除images，直到滿足需要刪除的空間為止
    var lastErr error
    spaceFreed := int64(0)
    for _, image := range images {
        glog.V(5).Infof("Evaluating image ID %s for possible garbage collection", image.id)
        // Images that are currently in used were given a newer lastUsed.
        if image.lastUsed.Equal(freeTime) || image.lastUsed.After(freeTime) {
            glog.V(5).Infof("Image ID %s has lastUsed=%v which is >= freeTime=%v, not eligible for garbage collection", image.id, image.lastUsed, freeTime)
            break
        }

        // Avoid garbage collect the image if the image is not old enough.
        // In such a case, the image may have just been pulled down, and will be used by a container right away.
        // 查看該image的空閑時間是否夠久，不夠久的話將不刪除
        // 這個時間在GC的策略中有配置
        if freeTime.Sub(image.firstDetected) < im.policy.MinAge {
            glog.V(5).Infof("Image ID %s has age %v which is less than the policy"s minAge of %v, not eligible for garbage collection", image.id, freeTime.Sub(image.firstDetected), im.policy.MinAge)
            continue
        }

        // 調用runtime(即Docker)的接口刪除指定的image
        glog.Infof("[ImageManager]: Removing image %q to free %d bytes", image.id, image.size)
        err := im.runtime.RemoveImage(container.ImageSpec{Image: image.id})
        if err != nil {
            lastErr = err
            continue
        }
        // 將刪除的鏡像從imageRecords中去除，所以前面需要加鎖
        delete(im.imageRecords, image.id)
        // 增加已經刪除的image的size
        spaceFreed += image.size
        // 如果已經刪除的image的大小已經滿足要求，則退出回收流程
        if spaceFreed >= bytesToFree {
            break
        }
    }

    return spaceFreed, lastErr
}

基本的imageManager模塊流程差不多就這樣了，這里還可以繼續深入學習下cAdvisor和docker runtime的接口實現。

containerGC回收策略相關結構如下：

type ContainerGCPolicy struct {
    // Minimum age at which a container can be garbage collected, zero for no limit.
    MinAge time.Duration

    // Max number of dead containers any single pod (UID, container name) pair is
    // allowed to have, less than zero for no limit.
    MaxPerPodContainer int

    // Max number of total dead containers, less than zero for no limit.
    MaxContainers int
}

該結構的初始化是在cmd/kubelet/app/kubelet.go文件中的CreateAndInitKubelet()接口中進行。
調用流程：main --> app.Run --> RunKubelet --> CreateAndInitKubelet

func CreateAndInitKubelet(kc *KubeletConfig) (k KubeletBootstrap, pc *config.PodConfig, err error) {
    var kubeClient clientset.Interface
    if kc.KubeClient != nil {
        kubeClient = kc.KubeClient
        // TODO: remove this when we"ve refactored kubelet to only use clientset.
    }

    // containerGC的回收策略初始化
    gcPolicy := kubecontainer.ContainerGCPolicy{
        MinAge:             kc.MinimumGCAge,
        MaxPerPodContainer: kc.MaxPerPodContainerCount,
        MaxContainers:      kc.MaxContainerCount,
    }
...
}

可以看到實際的參數來源于kc結構,而該結構的初始化是在cmd/kubelet/app/kubelet.go文件中的UnsecuredKubeletConfig()接口中進行。
調用流程：main --> app.Run --> UnsecuredKubeletConfig

func UnsecuredKubeletConfig(s *options.KubeletServer) (*KubeletConfig, error) {
...
        MaxContainerCount:            int(s.MaxContainerCount),
        MaxPerPodContainerCount:      int(s.MaxPerPodContainerCount),
        MinimumGCAge:                 s.MinimumGCAge.Duration,
...
}

最開始的參數都來源于KubeletServer中的KubeletConfiguration結構，相關的參數如下：

type KubeletConfiguration struct {
...
    // containerGC會回收已經結束的container，但是該container結束后必須要停留
    // 大于MinimumGCAge時間才能被回收。 default: 1min
    MinimumGCAge unversioned.Duration `json:"minimumGCAge"`
    // 用于指定每個已經結束的Pod最多可以存在containers的數量，default: 2
    MaxPerPodContainerCount int32 `json:"maxPerPodContainerCount"`
    // 集群最大支持的container數量
    MaxContainerCount int32 `json:"maxContainerCount"`
    
}

而該入參的初始化還是需要回到cmd/kubelet/app/options/options.go中的NewKubeletServer()接口,實際初始化如下：

func NewKubeletServer() *KubeletServer {
...
            MaxContainerCount:            240,
            MaxPerPodContainerCount:      2,
            MinimumGCAge:                 unversioned.Duration{Duration: 1 * time.Minute},

從上面的初始化可以看出：

該節點可以創建的最大container數量是240

每個Pod最大可以容納2個containers

container結束之后，至少需要在1分鐘之后才能被containerGC回收

所以基本的containerGC策略就明白了。

策略結構初始化完之后，還要進行最后一步containerGC結構初始化,需要進入pkg/kubelet/kubelet.go的NewMainKubelet()接口查看：

func NewMainKubelet(...) {
...
    // setup containerGC
    containerGC, err := kubecontainer.NewContainerGC(klet.containerRuntime, containerGCPolicy)
    if err != nil {
        return nil, err
    }
    klet.containerGC = containerGC
...
}

繼續查看NewContainerGC()，該接口在pkg/kubelet/container/container_gc.go中，看下干了啥：

func NewContainerGC(runtime Runtime, policy ContainerGCPolicy) (ContainerGC, error) {
    if policy.MinAge < 0 {
        return nil, fmt.Errorf("invalid minimum garbage collection age: %v", policy.MinAge)
    }

    return &realContainerGC{
        runtime: runtime,
        policy:  policy,
    }, nil
}

接口很簡單，根據之前的策略結構體又初始化了一個realContainerGC結構，可以看出該接口就比較完整了，可以想象一下需要進行container的回收的話，必須要用到runtime的接口(比如查看當前容器狀態，刪除容器等操作)，所以結構中帶入實際使用的runtime是必然的。
可以關注下該對象支持的方法，后面會用到。

所有的參數初始化結束后，需要開始進入真正的GC啟動流程，該步驟上面講imageManager時已經提及，這里直接進入正題。
啟動containerGC的接口是StartGarbageCollection()，具體實現如下：

func (kl *Kubelet) StartGarbageCollection() {
    go wait.Until(func() {
        if err := kl.containerGC.GarbageCollect(kl.sourcesReady.AllReady()); err != nil {
            glog.Errorf("Container garbage collection failed: %v", err)
        }
    }, ContainerGCPeriod, wait.NeverStop)

    go wait.Until(func() {
        if err := kl.imageManager.GarbageCollect(); err != nil {
            glog.Errorf("Image garbage collection failed: %v", err)
        }
    }, ImageGCPeriod, wait.NeverStop)
}

接下來我們一起看下containerGC的GarbageCollect()接口，但要找到這個接口的話，我們得回到之前初始化containerGC的步驟。
實際初始化containerGC時真正返回的是realContainerGC結構，所以GarbageCollect()是該結構的方法：

func (cgc *realContainerGC) GarbageCollect(allSourcesReady bool) error {
    return cgc.runtime.GarbageCollect(cgc.policy, allSourcesReady)
}

看到這里，發現containerGC的套路跟imageManager一樣，所以一招鮮吃遍天。
我們使用的runtime就是docker，所以需要去找docker的GarbageCollect()接口實現，具體runtime的初始化可以查看之前一篇文章的介紹，這里就不講具體的初始化了，直接進入正題。
Docker的GarbageCollect()接口在pkg/kubelet/dockertools/container_gc.go中：

func (cgc *containerGC) GarbageCollect(gcPolicy kubecontainer.ContainerGCPolicy, allSourcesReady bool) error {
    // 從所有的容器中分離出那些可以被回收的contianers
    // evictUnits: 可以識別的但已經dead，并且創建時間大于回收策略中的minAge的containers
    // unidentifiedContainers： 無法識別的containers
    evictUnits, unidentifiedContainers, err := cgc.evictableContainers(gcPolicy.MinAge)
    if err != nil {
        return err
    }

    // 先刪除無法識別的containers
    for _, container := range unidentifiedContainers {
        glog.Infof("Removing unidentified dead container %q with ID %q", container.name, container.id)
        err = cgc.client.RemoveContainer(container.id, dockertypes.ContainerRemoveOptions{RemoveVolumes: true})
        if err != nil {
            glog.Warningf("Failed to remove unidentified dead container %q: %v", container.name, err)
        }
    }

    // 所有資源都已經準備好之后，可以刪除那些已經dead的containers
    if allSourcesReady {
        for key, unit := range evictUnits {
            if cgc.isPodDeleted(key.uid) {
                cgc.removeOldestN(unit, len(unit)) // Remove all.
                delete(evictUnits, key)
            }
        }
    }

    // 檢查所有的evictUnits, 刪除每個Pod中超出的containers
    if gcPolicy.MaxPerPodContainer >= 0 {
        cgc.enforceMaxContainersPerEvictUnit(evictUnits, gcPolicy.MaxPerPodContainer)
    }

    // 確保節點的最大containers數量
    // 檢查節點containers數量是否超出了最大限制，是的話就刪除多出來的containers
    // 優先刪除最先創建的containers
    if gcPolicy.MaxContainers >= 0 && evictUnits.NumContainers() > gcPolicy.MaxContainers {
        // 計算每個單元最多可以有幾個containers
        numContainersPerEvictUnit := gcPolicy.MaxContainers / evictUnits.NumEvictUnits()
        if numContainersPerEvictUnit < 1 {
            numContainersPerEvictUnit = 1
        }
        // 
        cgc.enforceMaxContainersPerEvictUnit(evictUnits, numContainersPerEvictUnit)

        // 需要刪除containers的話，優先刪除最老的containers
        numContainers := evictUnits.NumContainers()
        if numContainers > gcPolicy.MaxContainers {
            flattened := make([]containerGCInfo, 0, numContainers)
            for uid := range evictUnits {
                // 先整合所有的containers
                flattened = append(flattened, evictUnits[uid]...)
            }
            sort.Sort(byCreated(flattened))
            // 刪除numContainers-gcPolicy.MaxContainers個最先創建的contianers
            cgc.removeOldestN(flattened, numContainers-gcPolicy.MaxContainers)
        }
    }

    // 刪除containers之后，需要清除對應的軟連接
    logSymlinks, _ := filepath.Glob(path.Join(cgc.containerLogsDir, fmt.Sprintf("*.%s", LogSuffix)))
    for _, logSymlink := range logSymlinks {
        if _, err = os.Stat(logSymlink); os.IsNotExist(err) {
            err = os.Remove(logSymlink)
            if err != nil {
                glog.Warningf("Failed to remove container log dead symlink %q: %v", logSymlink, err)
            }
        }
    }

    return nil
}

上面通過源碼介紹了imageManager和containerGC的實現，里面也涉及到了GC Policy的配置，我們也可以通過手動修改kubelet的flags來改變參數默認值。

image-gc-high-threshold： 該值表示磁盤占用率達到該值后會觸發image garbage collection。默認值是90%

image-gc-low-threshold： 該值表示image GC嘗試以回收的方式來達到的磁盤占用率，若磁盤占用率原本就小于該值，不會觸發GC。默認值是80%

minimum-container-ttl-duration： 表示container結束后多長時間可以被GC回收，默認是1min

maximum-dead-containers-per-container： 表示每個已經結束的Pod中最多可以存在多少個containers,默認值是2個

maximum-dead-containers： 表示kubelet所在節點最多可以保留已經結束的containers的數量，默認值是240

容器在停止工作后是可以被garbage collection進行回收，但是我們也需要對containers進行保留，因為有些containers可能是異常停止的，而container可以保留有logs或者別的游泳的數據用于開發進行問題定位。
根據上面的需求，我們就可以通過maximum-dead-containers-per-container和maximum-dead-containers很好的來實現這個目標。