了解工作节点上的组件——kubelet

最新推荐文章于 2024-07-14 02:16:53 发布

达分奇先生

最新推荐文章于 2024-07-14 02:16:53 发布

阅读量756

点赞数 16

分类专栏： k8s学习指南文章标签： kubelet 云原生 kubernetes 容器 linux

本文链接：https://blog.csdn.net/lhq1363511234/article/details/137408434

版权

k8s学习指南专栏收录该内容

15 篇文章 0 订阅

订阅专栏

花了几天总结完控制层面上的组件，还记得嘛？
第一个是apiserver,第二个是controller，然后是schedule。还记得它们有什么特性吗？

预告

核心组件快要解析完毕了，除了proxy还剩一个比较重要的数据库Etcd没有给大家解释清楚
还有一个很重要的在网络架构层面也非常重要，比如如何再集群内部进行抓包分析故障问题，我们可能还会学习一下各种组件、容器之间是如何通信的
在以上学习过的组件当中，有个单词经常出现，既陌生又熟悉——Pod，别着急，咱们慢慢学啊。

组件 kube-kubelet

一、运行机制

在Kubernetes架构中，Kubelet组件充当着工作节点（或称计算节点）的关键角色，职责在于与主节点上的控制平面紧密协作，确保工作节点上的Pod和容器按照预定的配置稳定、高效地运行。

Kubelet驻留在每个工作节点上，负责管理该节点上的容器生命周期。

首先，Kubelet启动时会与主节点上的API服务器建立连接，并在API服务器中注册当前工作节点作为一个Node资源实体，以便控制平面能够识别和调度Pod到此节点上。

接着，Kubelet持续监听API服务器的指令，一旦收到将Pod调度到本节点的通知，便会立即着手启动这些Pod。

这一过程包括解析Pod的定义，根据定义中的容器规格和镜像信息，调用底层容器运行时（如Docker、Containerd、或是其他兼容容器引擎）来创建和启动对应的容器。
在这里插入图片描述

在容器运行阶段，Kubelet不间断地监控容器的状态，包括健康检查、资源使用情况等，并将这些信息反馈给API服务器，以便集群全局视角的资源管理和调度决策。

Kubelet还会执行容器存活探针（Liveness Probes）和就绪探针（Readiness Probes），在探测失败时及时重启容器，确保服务的高可用性。

Kubelet并不完全依赖于API服务器来运行Pod。在某些特殊场景下，如运行控制平面自身的组件时，Kubelet还可以通过加载本地目录中的静态Pod清单文件，来启动和管理这些Pod。

这意味着在没有API服务器接入的情况下，Kubelet依然能够在节点上独立运行预定义的Pod。这种方式既可用于部署Kubernetes系统组件（如etcd、kube-apiserver等），也可用于运行用户自定义的静态Pod资源。

二、节点管理

1. 自注册功能

通过设置kubelet启动参数--register-node=true，kubelet将会尝试连接至指定的API Server (--api-servers) 自动注册节点信息。

这一过程依赖于安全配置文件kubeconfig (--kubeconfig) 来保障与API Server之间的安全通信。在公有云环境中，还需提供--cloud-provider参数以适配特定云服务商。

2. 权限管理

当前kubelet具有创建和修改任何节点的权限，但在未来规划中，kubelet的权限将受限于仅能对自己所处的节点进行操作，以增强安全性。

3. 节点扩容

在集群资源紧张的情况下，可通过增加机器并利用kubelet的自注册功能实现集群扩容，简化集群管理。

4. 手动配置节点

当kubelet不启用自注册模式时（通过--register-node=false设置），集群管理员需自行在API Server上配置节点资源信息，并确保节点上的kubelet知晓API Server的位置。这种情况下，管理员可以手动创建和修改节点信息。

5. 节点状态上报

kubelet启动后不仅进行节点注册，还会按照设定的时间间隔（由--node-status-update-frequency参数定义，默认为10秒）向API Server报告节点的最新状态，API Server接收到这些状态信息后会将其存储到etcd中，以便整个集群实时了解各节点的状态变化。

三、Pod管理

它是在集群中管理节点上Pod生命周期的核心组件，它通过多种方式获取并执行节点上Pod的运行清单：

1. 文件方式

kubelet会周期性（默认每20秒）检查指定配置文件目录（如"/etc/kubernetes/manifests/"）下是否有新的或更新的Pod清单文件。

2. HTTP端点

kubelet也可以通过HTTP端点获取Pod清单，并定期（默认每20秒）检查更新。

3. API Server

主要方式是通过与API Server通信，kubelet监听etcd中关于Pod的相关操作。

对于非通过API Server创建的Pod称为Static Pod，kubelet会为其在API Server上创建Mirror Pod进行状态同步。

kubelet通过API Server实时监听本节点相关的Pod事件

包括新增、修改和删除等操作，并据此对本地Pod进行相应管理：

当监听到新绑定到本节点的Pod时，kubelet会按照Pod清单创建该Pod。
若检测到Pod被修改，kubelet会根据变更内容调整本地Pod的状态，如删除不再需要的容器等。
如果发现需要删除本节点上的Pod，kubelet不仅会删除Pod对象，还会通过Docker Client删除相关容器。

在处理创建和修改Pod任务时

kubelet执行以下步骤：

创建Pod的数据目录。
从API Server获取Pod清单。
挂载Pod所需的外部卷。
下载Pod使用的Secret信息。
管理已存在Pod的容器状态，确保正确启动或停止容器，并保证每个Pod内部都有一个 Pause 容器作为网络共享的基础设施。
对于Pod中的每个容器，kubelet会进行Hash值比对，决定是否需要重新拉取或启动容器，并依据容器的restartPolicy来决定是否需要自动重启容器。

简单来说，kubelet通过监控和执行Pod清单，结合与API Server的交互以及对节点资源的管理，实现了对Pod生命周期的自动化控制和维护。

四、容器健康检查

Pod中为了确定容器的运行状态，引入了两种类型的探针：LivenessProbe和ReadinessProbe。

LivenessProbe

主要用来检测容器是否存活且正常运行。

kubelet会定期执行LivenessProbe检查，如果探针返回的结果表明容器不健康，kubelet将依据容器的重启策略采取行动，可能是重启容器。

若容器未定义LivenessProbe，kubelet默认认为容器始终处于健康状态。例如：

LivenessProbe 实践示例：

ExecAction 示例：

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 15
  periodSeconds: 10

在这个示例中，kubelet将在容器启动15秒后开始执行cat /tmp/healthy命令，每10秒执行一次。只要命令成功执行（即退出状态码为0），就认为容器健康。

TCPSocketAction 示例：

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10

这里kubelet会在容器启动15秒后开始尝试连接到容器的8080端口，每10秒检查一次。只要端口能建立TCP连接，就表示容器健康。

HTTPGetAction 示例：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10

kubelet同样会在容器启动15秒后开始通过HTTP GET方法请求容器的8080端口上的/healthz路径，每10秒检查一次。只要HTTP响应状态码在200-400之间，就认为容器状态健康。

ReadinessProbe

用于判断容器是否准备好接受流量。

当ReadinessProbe检测失败时，kubelet会将Pod标记为不可用，从而Endpoint Controller会从对应Service的Endpoint列表中移除该Pod的IP地址，直到容器变为可用状态为止。

ReadinessProbe也支持上述三种实现方式，其配置和使用方式与LivenessProbe相似。

五、三种开放接口

kubelet组件实现了3种开放接口
在这里插入图片描述

Container Runtime Interface (CRI)

Kubernetes 项目中定义的一个标准化接口层，旨在将kubelet与具体的容器运行时引擎解耦。

通过CRI，kubelet能够与符合接口规范的任意容器运行时进行通信，以管理Pod及其内部容器的生命周期，包括创建、启动、停止、删除容器，以及镜像的拉取、管理等操作。

CRI使用gRPC协议定义了一系列接口，将容器管理拆分为独立的Sandbox（用于隔离Pod级别的网络和存储空间）和服务级别（针对单个容器）的操作。

Container Network Interface (CNI)

它是一种容器网络模型的标准接口，它为容器提供了统一的网络配置方案。

CNI插件在容器创建和销毁时负责动态配置网络，使得容器能够接入网络，并与其他容器、服务或外部网络进行通信。

CNI定义了一系列插件API，允许第三方开发者开发兼容的网络插件来满足多样化的网络需求。

Container Storage Interface (CSI)

为容器提供持久化存储解决方案的标准接口，它允许不同的存储提供商为Kubernetes集群提供一致的存储卷插件。

当创建容器时，CSI插件负责将外部存储系统中的存储卷挂载到容器内部，以及在容器销毁时释放存储资源。

通过CSI，Kubernetes可以无缝对接各种存储服务，实现存储资源的按需分配和管理。

实践注意

kubelet 的启动参数通常是在kubelet服务的配置文件或者在系统启动kubelet服务时直接指定的。

具体位置取决于Kubernetes集群是如何安装和配置的。有几种常见情况：

在 systemd 配置文件中：
在systemd的Linux系统中（如Ubuntu、CentOS等），kubelet服务的配置通常位于 /etc/systemd/system/kubelet.service 或 /etc/systemd/system/kubelet.service.d/ 目录下的某个配置文件中。可以在 ExecStart 行后追加启动参数，例如：
```
[Service]
ExecStart=/usr/bin/kubelet --register-node=false [... 其他参数 ...]
```
kubelet配置文件：
Kubelet 可能会读取一个单独的配置文件，比如 /var/lib/kubelet/config.yaml 或 /etc/kubernetes/kubelet.conf。
在这样的配置文件中，会看到类似的键值对结构，需要修改对应的字段。
```
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
registerNode: false
```
命令行启动：
如果是直接在命令行启动kubelet，那么可以在启动命令后面加上 --register-node=false 参数。