kubernetes的核心竞争力是对各种workload的抽象和编排，在与计算、存储和网络对接中，分别对应衍生了其对接的事实标准CRI、CNI和CSI。今天我们来重点分析kubelet运行时，另外二者在接下来的文章中再做详细的介绍。
kubelet有以下的启动参数用来指定运行时：
–container-runtime string
The container runtime to use. Possible values: ‘docker’, ‘remote’, ‘rkt(deprecated)’. (default “docker”)
–container-runtime-endpoint string
[Experimental] The endpoint of remote runtime service. Currently unix socket is supported on Linux, and tcp is supported on windows.
这是一篇很长很长的文章，是去年CKA考试刚开始推出来的时候，我参与考试复习做过的一些知识点。基于做过的题，大概列出了具体的知识点，当时考试的时候还在使用v1.7版本，现在应该都要到v1.12了。
补充：这周收到CNCF的邮件，说是之前认证两年到期的CKA证书又延长了一年了（感叹：这是为了诱惑大家都来考证吗^_^）。
在上一篇文章中，我们提到container GC在后续kuberntes版本会放入eviction manager中来处理。今天我们就来简单的分析一下kubelet eviction的实现机制。
在上一篇文章中，概括的划分了kubelet的核心模块，这一篇文章重点来分析一下其中Config和GC在源码中是如何实现的。
这部分其实就是kubelet的业务入口，此处所谓的config不是指kubelet的配置参数，而是指业务（也就是pod）配置的意思。形象的说，当你在/etc/kubernetes/manifests下放上pod的yaml文件时，kubelet就通过config模块来扫描到pod配置文件的内容，然后在kubelet中创建出对应的static pod。同理，当你通过kubectl创建的pod被scheduler调度到该节点时，config模块就会感知到Api-Server上的配置的变动，然后对应的将pod创建出来。
最近将kubelet的代码整体过了一遍，其实也没有想象中复杂。代码涉及到的细枝末节较多，如果先前对kubernetes的产品功能不够了解的话，可能直接上源码分析会云里雾里。我的建议是“先把握框架和主干，然后再逐步深入到各个细节”，做架构要有分层的思想，读代码也如此。写这篇文章一方面是为了记录下当下转瞬即逝的一些思路，另一方面如果后续有人在网上爬到，也希望它能对你有一点点帮助！
言归正传，下面先总体上谈谈kubelet代码的框架，然后分别介绍kubelet的各主要模块。
下面是大图(确实很大！看细节请自行放大)，简要汇总了kubelet从初始化到Run成功后，整个都处于运行中的goRoutines。就是靠这些goRoutine的紧密协作，保障了pod整个生命周期中，完全按照我们的要求来运行。
kubernetes官网的文档比较详细，但是所有的安装步骤都有个前提(你有足够自由的互联络)，之前在香港和亚马逊的服务器都是直接照着手册执行脚本一路顺畅。无奈天朝的网络只能够借助于阿里云镜像站了，先前只是在使用该站点的各种linux发行版安装包，最近发现还支持了kubernetes。具体可以访问阿里巴巴开源镜像站。
