kubelet运行机制

在kubernets集群中每个node节点都会运行kubelet服务进程。

kubelet进程负责处理下发到pod的任务，管理pod以及pod中的容器。

kubelet进程会在kube-apiserver上注册本节点信息，并定时向Matser节点汇报自身节点资源状况，并通过cAdvisor监控容器和节点资源。

节点管理

设置kubelet启动参数“--registry-node”参数为true是，kubelet会试着通过api server来注册自己。注册时，还包含下列参数：

--api-servers:告诉kubelet进程api server 的地址
--kubeconfig : 访问api server的证书地址
--node-status-update-frequency: kubelet进程向api server报告自身资源状况的时间间隔，默认10s

pod管理

kubelet进程通过以下几种方式获得本身节点所要运行的pod清单：

文件：kubelet启动参数“--config”指定配置目录下的文件（默认“/etc/kubernets/manifests”）。通过”--file-check-frequency“设置检查该文件的时间间隔，默认20s
http(url)：“--manifets-url”设置读取的http地址，“--http-check-frequency”设置检查时间间隔，默认20s。
API Server: kubelet通过API Server监听etcd目录，同步pod列表

kubelet通过API Server Client使用的Watch加List的方式监听“/registry/nodes/节点名称”和“registry/pod”目录，将获取的pod信息同步至本地。

kubelet监听etcd，所有针对pod的操作将会被kubelet监听，若发现有绑定到本节点的pod，则按照pod清单创建pod，其他操作类似。

pod创建和修改操作是，kubelet的执行流程：

为pod创建一个数据目录
从API Server读取pod
为pod挂载外部卷（External Volume）
下载pod用到的Secret
检查节点上已经运行的pod，若pod没有容易或者Pause容器没有启动，先停止pod里所有容器的进程，若有需要删除的容器，则先删除
用“kubernets/pause”镜像为每个pod创建一个容器。pause容器用于接管pod中所有出pause容器外的的网络。床架新的pod之前，都会先创建一个pause容器。
为pod中的每个容器做如下处理：
为容器计算一个hash值，用容器的容器去查询对应docker容器的hash值。若查到的容易hash值，且两者不同，则亭子docker容器中的进程以及与之关联的进程；相同则不做处理。

若容器被停止了，且没有指定restartPolicy,则不做处理

下载镜像，运行容器。

容器健康检查

大部分的应用程序我们在部署的时候都会适当的添加监控，对于运行载体容器则更应该如此。kubernetes提供了 liveness

probes的结果也有几个固定的可选项值：

Success：表示通过检测
Failure：表示没有通过检测
Unknown：表示检测没有正常进行

Liveness Probe的种类：

ExecAction

在container中执行指定的命令。当其执行成功时，将其退出码设置为0；

TCPSocketAction

执行一个TCP检查使用container的IP地址和指定的端口作为socket。如果端口处于打开状态视为成功；

HTTPGetAcction

执行一个HTTP默认请求使用container的IP地址和指定的端口以及请求的路径作为url，用户可以通过host参数设置请求的地址，通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间，设为成功。

当前kubelet拥有两个检测器，他们分别对应不通的触发器

Liveness Probe

表示container是否处于live状态。如果 LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉 container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为 Success，如果container没有提供LivenessProbe，则也认为是Success；

ReadinessProbe

表示container是否以及处于可接受service请求的状态了。如果ReadinessProbe失败，endpoints controller将会从service所匹配到的endpoint列表中移除关于这个container的IP地址。因此对于Service匹配到的 endpoint的维护其核心是ReadinessProbe。默认Readiness的初始值是Failure，如果一个container没有提供 Readiness则被认为是Success。

参数

initialDelaySeconds：用来表示初始化延迟的时间，也就是告诉监测从多久之后开始运行，单位是秒
timeoutSeconds: 用来表示监测的超时时间，如果超过这个时长后，则认为监测失败。当前对每一个Container都可以设置不同的restartpolicy，有三种值可以设置： Always: 只要container退出就重新启动 OnFailure: 当container非正常退出后重新启动 Never: 从不进行重新启动如果restartpolicy没有设置，那么默认值是Always。如果container需要重启，仅仅是通过kubelet在当前节点进行container级别的重启。最后针对LivenessProbe如何使用，请看下面的几种方式，如果要使用ReadinessProbe只需要将livenessProbe修改为readinessProbe即可：

apiVersion: v1
kind: Pod
metadata:
  name: probe-exec
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 5
      timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: probe-http
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /
        port: 80
        host: www.baidu.com
        scheme: HTTPS
      initialDelaySeconds: 5
      timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 80

使用上面的construct创建资源：

kubectl create -f probe.yaml
kubectl get event

通过event我们可以发现对应的container由于probe监测失败一直处于循环重启中，其事件原因：unhealthy