一、简介

每个 Node 节点（又称 Minion ）上都会启动 kubelet 服务进程。该进程用于处理 Master 节点下发到本节点的任务，管理 Pod及Pod 中的容器。每个Kubelet会在 API Server 上注册节点自身信息，定期向 Master 节点汇报节点资源的使用情况，并通过cAdvisor 监控容器和节点资源。

二、节点管理

点通过设置 kubelet 启动参数--register-node ，来决定是否向 API Server 注册自己.注册时包括以下参数

  • --api-servers: API Server 的位置。
  • --kubeconfig: kubeconfig 文件，用于访问 API Server 的安全配置文件
  • --cloud-provider ：云服务商IaaS地址，仅用于公有云环境

每个 kubelet 被授予创建和修改任何节点的权限。但是在实践中，它仅仅创建和修改自己。

三、Pod管理

kubelet 通过以下几种方式获取自身 Node 上所要运行的 Pod 清单。

  1. 文件： kubelet 启动参数 “--config ”指定的配置文件目录下的文件（默认目录为“ /etc/kubernetes/manifests/)。通过--file-check-frequency 设置检查该文件目录的时间间隔，默认为20s。
  2. HTTP 端点 （URL ）：通过“--manifest-url ”参数设置。通过--http-check-frequency 设置检查该 HTTP 端点数据的时间间隔，默认为 20S
  3. API Server： kubelet 通过 API Server 监听 etcd 目录，同步 Pod 表。

有以非 API Server方式创建的 Pod 都叫作 Static Pod ，kubelet将 Static Pod 的状态汇报给API Server, API Server 为该 Static Pod 创建一个 Mirror Pod 其相匹配。 Mirror Pod 的状态将真实反映 Static Pod 的状态。

kubelet 通过API Server Client 使用 Watch-List 的方式监听“ /registry/nodes/$ 当前节点的名称”和“/registry/pods ”目录，将获取的信息同步到本地缓存中。

kubelet 监听 etcd 所有针对 Pod 操作将会被 kubelet 监听到 。如果发现有新的绑定到本节点的 Pod ，则按照 Pod 清单的要求创建该 Pod。

kubelet 读取监听到的信息，如果是创建和修改 Pod ，则做如下处理。

  • 为该 Pod 创建一个数据目录
  • 从 API Server 读取该 Pod 清单。
  • 为该 Pod 挂载外部卷 （External Volume）
  • 下载 Pod 用到的 Secret
  • 检查己经运行在节点中的 Pod ，如果该 Pod 没有容器或 Pause 容器（“ kubernetes/pause镜像创建的容器）没有启动，则先停止 Pod 里所有容器的进程。如果在 Pod 中有需要删除的容器，则删除这些容器。
  • 用“kuberbnetes/pause ”镜像为每个 Pod 创建一个容器。该 Pause 容器用于接管 Pod所有其他容器的网络。每创建一个新的 Pod, kubelet 都会先创建 Pause 容器，然后创建其他容器。Kubernetes/pause 镜像大概为 200KB ，是 个非常小的容器镜像。
  • 为Pod 中的每个容器做如下处理。
    • 为容器计算一个 hash 值，然后用容器的名字去查询对应 Docker 容器的 hash 值。若查找到容器，且两者的 hash 值不同，则停止 Docker 中容器的进程，井停止与之关联的Pause 容器的进程；若两者相同，则不做任何处理
    • 如果容器被终止了，且容器没有指定的 restartPolicy （重启策略〉，则不做任何处理。
    • 调用 Docker Client 下载容器镜像，调用 Docker Client 运行容器

四、容器健康检查

Pod 通过两类探针来检查容器的健康状态。一个是 LivenessProbe 探针，用于判断容器是否健康，告诉 kubelet 一个容器什么时候处于不健康的状态。如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将删除该容器，并根据容器的重启策略做相应的处理。

另一类是 ReadinessProbe 探针，用于判断容器是否启动完成，且准备接收请求。如果ReadinessProbe 探针检测到失败，则 Pod 的状态将被修改， Endpoint Controller 将从 ServiceEndpoint 中删除包含该容器所在 Pod 地址的 Endpoint 条目

LivenessProbe 包含：

  • ExecAction ：在容器内部执行一个命令，如果该命令的退出状态码为 ，则表明容器健康。
  • TCPSocketAction ：通过容器的 IP 地址和端口号执行 TCP 查，如果端口能被访问，则表明容器健康。
  • HTTPGetAction ：通过容器的 IP 地址和端口号及路径调用 HTTP Get 法，如果响应的状态码大于等于 200 且小于等于 400 ，则认为容器状态健康。

LivenessProbe 探针包含在 Pod 定义的 spec.containers ｛某个容器｝中。下面的例子展示了两种Pod 中容器健康检查的方式： HTTP 检查和容器命令执行检查。下面所列的内容实现了通过容器命令执行检查：

1
2
3
4
5
6
7
8
#在容器中执行“cat /tmp/health ”命令，如果该命令返回的值为 ，则表明容器处健康状态，否则表明容器处于不健康状态。
livenessProbe: 
  exec : 
    command: 
    - cat 
    - /tmp/health 
    initialDelaySeconds: 15 
    timeoutSeconds : 1

容器的 HTTP 检查：

1
2
3
4
5
6
7
#容器的 HTTP 检查：
livenessProbe : 
  httpGet: 
    path: /healthz 
    port : 8080 
  initialDelaySeconds: 15 
  timeoutSeconds: 1

五、cAdvisor 资源监控

Heapster 项目为 Kubernetes 提供了一个基本的监控平台，它是集群级别的监控和事件数据集成器（Aggregator Heapster 作为 Pod 运行在 Kubernetes 集群中，和运行在 Kubernetes 集群中的其他应用相似。 Heapster Pod 通过 kubelet （运行在节点上的 Kubernetes 代理）发现所有运行在集群中的节点，并查看来自这些节点的资源使用状况信息。 kubelet 通过 cAdvisor 获取其所在节点及容器的数据， Heapster 通过带着关联标签的 Pod 分组这些信息，这些数据被推到一个可配置的后端，用于存储和可视化展示。当前支持的后端包括 InfluxDB

cAdvisor 自动查找所有在其所在节点上的容器，自动采集 CPU、内存、文件系统和网络使用的统计信息。