k8s学习笔记（11）--- kubernetes核心组件之kubelet详解

一、kubelet简介

        在kubernetes集群中，每个Node节点都会启动kubelet进程，用来处理Master节点下发到本节点的任务，管理Pod和其中的容器。kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源。可以把kubelet理解成【Server-Agent】架构中的agent，是Node上的pod管家。

        流程图如下：

        Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命：
１．监视分配给该Node节点的 pods
２．挂载pod所需要的volumes
３．下载pod的secret
４．通过docker/rkt来运行pod中的容器
５．周期的执行pod中为容器定义的liveness探针
６．上报pod的状态给系统的其他组件
７．上报Node的状态

        整个kubelet也可以按如下模块划分，模块之间相互配合完成Kubelet的所有功能。

        上图解析如下：
１．10250 kubelet API，kublet暴露出来的端口，通过该端口可以访问获取node资源以及状态，另外可以配合kubelet的启动参数contention-profiling enable-debugging-handlers来提供了用于调试和profiling的api;
２．4194 cAdvisor，kublet通过该端口可以获取到本node节点的环境信息以及node上运行的容器的状态等内容；
３．10255 readonly API，kubelet暴露出来的只读端口，访问该端口不需要认证和鉴权，该http server提供查询资源以及状态的能力．注册的消息处理函数定义src/k8s.io/kubernetes/pkg/kubelet/server/server.go:149；
４．10248 /healthz –kubelet健康检查,通过访问该url可以判断Kubelet是否正常work, 通过kubelet的启动参数–healthz-port –healthz-bind-address来指定监听的地址和端口．默认值定义在pkg/kubelet/apis/kubeletconfig/v1alpha1/defaults.go；

二、kubelet核心功能

• PLEG
          PLEG全称为PodLifecycleEvent,PLEG会一直调用container runtime获取本节点的pods,之后比较本模块中之前缓存的pods信息，比较最新的pods中的容器的状态是否发生改变，当状态发生切换的时候，生成一个eventRecord事件，输出到eventChannel中．　syncPod模块会接收到eventChannel中的event事件，来触发pod同步处理过程，调用contaiener runtime来重建pod，保证pod工作正常。
  
• cAdvisor
          cAdvisor集成在kubelet中，起到收集本Node的节点和启动的容器的监控的信息，启动一个Http Server服务器，对外接收rest api请求．cAvisor模块对外提供了interface接口，可以通过interface接口获取到node节点信息，本地文件系统的状态等信息，该接口被imageManager，OOMWatcher，containerManager等所使用 cAdvisor相关的内容详细可参考github.com/google/cadvisor；
• GPUManager
          对于Node上可使用的GPU的管理，当前版本需要在kubelet启动参数中指定feature-gates中添加Accelerators=true，并且需要才用runtime=Docker的情况下才能支持使用GPU,并且当前只支持NvidiaGPU,GPUManager主要需要实现interface定义的Start()/Capacity()/AllocateGPU()三个函数；
• OOMWatcher
          系统OOM的监听器，将会与cadvisor模块之间建立SystemOOM,通过Watch方式从cadvisor那里收到的OOM信号，并发生相关事件；
• ProbeManager
          探针管理，依赖于statusManager,livenessManager,containerRefManager，实现Pod的健康检查的功能。当前支持两种类型的探针：
  １．LivenessProbe:用于判断容器是否存活，如果探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理；
  ２．ReadinessProbe: 用于判断容器是否启动完成 ；

探针有三种实现方式 :
１．execprobe:在容器内部执行一个命令，如果命令返回码为０，则表明容器健康;
２．tcprobe:通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康;
３．httprobe:通过容器的IP地址，端口号以及路径调用http Get方法，如果响应status>=200 && status<=400的时候，则认为容器状态健康;

• StatusManager
          该模块负责pod里面的容器的状态，接受从其它模块发送过来的pod状态改变的事件，进行处理，并更新到kube-apiserver中;

• Container/RefManager
          容器引用的管理，相对简单的Manager，通过定义map来实现了containerID与v1.ObjectReferece容器引用的映射。

• EvictionManager
          evictManager当node的节点资源不足的时候，达到了配置的evict的策略，将会从node上驱赶pod，来保证node节点的稳定性．可以通过kubelet启动参数来决定evict的策略．另外当node的内存以及disk资源达到evict的策略的时候会生成对应的node状态记录。

• ImageGC
          imageGC负责Node节点的镜像回收，当本地的存放镜像的本地磁盘空间达到某阈值的时候，会触发镜像的回收，删除掉不被pod所使用的镜像．回收镜像的阈值可以通过kubelet的启动参数来设置；

• ContainerGC
          containerGC负责NOde节点上的dead状态的container,自动清理掉node上残留的容器．具体的GC操作由runtime来实现。

• ImageManager
          调用kubecontainer.ImageService提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates的方法来保证pod运行所需要的镜像，主要是为了kubelet支持cni。

• VolumeManager
          负责node节点上pod所使用的ｖolume的管理，主要涉及如下功能 ：Volume状态的同步，模块中会启动gorountine去获取当前node上volume的状态信息以及期望的volume的状态信息，会去周期性的sync　volume的