K8S之kubelet介绍

这篇具有很好参考价值的文章主要介绍了K8S之kubelet介绍。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

 一、总体概述:

一旦Pod被调度到对应的宿主机之后,后续要做的事情就是创建这个Pod,并管理这个Pod的生命周期,这里面包括:Pod的增删改查等操作,在K8S里面这部分功能是通过kubelet 这个核心组件来完成的。

  对于一个Pod来说,它里面一般会存在多个容器,每个容器里面可以关联不同的镜像,进而运行不同的程序,如此以来:Pod的创建就需要下面的几个核心事件:

  1. 感知Pod被创建的命令,并清楚的知道这个Pod创建出来的话需要哪一些具体的信息,而这部分信息的获取是kubelet与k8s交互才能获取到的。

  2. kubelet在获取到这部分数据之后,会根据这些资源信息(包括:cpu、mem、network、image等)操作宿主机来完成资源的分配,网络的构建,并下载镜像到本地,进而将pod启动起来。

这就说明kubelet的功能需要分成两类:
一类:k8s进行交互,获取pod相关的数据,监控当前的Pod变化的事件。
二类:kubelet操作当前宿主机的资源信息,并启动Pod。

二、kubelet与K8S交互部分:

kubelet 本身,也是按照“控制器”模式来工作的,工作原理如下所示:

K8S之kubelet介绍

kubelet 的工作核心,就是一个控制循环SyncLoop,驱动这个控制循环运行的事件,包括四种:

1.Pod 更新事件
2.Pod 生命周期变化
3.kubelet 本身设置的执行周期
4.定时的清理事件


SyncLoop 需要处理的数据的来源:是kubelet注册到k8s里面的informer获取的。对于kubelet 来说,它启动的时候,要做的第一件事情,就是设置 Listers,也就是注册它所关心的各种事件的 Informer。

kubelet 还负责维护着很多其他的子控制循环,比如 Volume Manager、Image Manager、Node Status Manager 等等,这些控制循环的责任,就是通过控制器模式,完成 kubelet 的某项具体职责。

例如:Node Status Manager,就负责响应 Node 的状态变化,然后将 Node 的状态收集起来,并通过 Heartbeat 的方式上报给 APIServer。CPU Manager,就负责维护该 Node 的 CPU 核的信息,以便在 Pod 通过 cpuset 的方式请求 CPU 核的时候,能够正确地管理 CPU 核的使用量和可用量。
kubelet 通过 Watch 机制,监听了与自己相关的 Pod 对象的变化:

  1. 这个 Watch 的过滤条件是该 Pod 的 nodeName 字段与自己相同,kubelet 会把这些 Pod 的信息缓存在自己的内存里。

  2. 当一个 Pod 完成调度、与一个 Node 绑定起来之后, 这个 Pod 的变化就会触发 kubelet 在控制循环里注册的 Handler,也就是上图中的 HandlePods 部分。

  3. 通过检查该 Pod 在 kubelet 内存里的状态,kubelet 就能够判断出这是一个新调度过来的 Pod,从而触发 Handler 里 ADD 事件对应的处理逻辑。(备注:在具体的处理过程当中,kubelet 会启动一个名叫 Pod Update Worker 的、单独的 Goroutine 来完成对 Pod 的处理工作。)

例如:ADD 事件,kubelet 就会为这个新的 Pod 生成对应的 Pod Status,检查 Pod 所声明使用的 Volume 是不是已经准备好。然后,调用下层的容器运行时,开始创建这个 Pod 所定义的容器。

三、kubelet操作宿主机启动部分

kubelet 调用下层容器运行时的执行过程,并不会直接调用 Docker 的 API,而是通过一组叫作 CRI(Container Runtime Interface,容器运行时接口)的 gRPC 接口来间接执行的。kubelet 实际上就会调用一个叫作 GenericRuntime 的通用组件来发起创建 Pod 的 CRI 请求。Kubernetes 通过虚拟出一个CRI shim(例如:dockershim)让容器项目能够自主开发,进而为k8s提供一个统一的容器抽象层,使得下层容器运行时可以自由地对接进入 Kubernetes 当中。

K8S之kubelet介绍

CRI是Container Runtime Interface(容器运行时接口)的简写,CRI解耦了kubelet与容器运行时,让kubelet无需重新编译就可以支持多种容器运行时,kubelet将通过CRI接口来跟第三方容器运行时进行通信,来操作容器与镜像。实现了 CRI 接口的容器运行时通常称为 CRI shim, 这是一个 gRPC Server,监听在本地的 unix socket  上;而 kubelet 作为 gRPC 的客户端来调用 CRI 接口,来进行Pod  和容器、镜像的生命周期管理。另外,容器运行时需要自己负责管理容器的网络,推荐使用 CNI。

CRI shim 的能力:将 Kubernetes 发出的 CRI 请求,转换成对 containerd 的调用,然后创建出 runC 容器,runC 项目,负责执行设置容器 Namespace、Cgroups 和 chroot 等基础操作的组件的操作。

K8S之kubelet介绍

对于CRI shim来说主要针对的是下面runtimeService和imageService两类操作,Pod运行时会通过调用这些接口来把容器运行起来,如下所示:

K8S之kubelet介绍

例如:kubectl run 创建了一个名叫 foo 的Pod(备注:Pod里面包括了 A、B 两个容器)。这个 Pod 的信息最后来到 kubelet,kubelet 就会按照图中所示的顺序来调用 CRI 接口,这些接口里面会封装好对于cpu、mem、网络等资源的操作,而这部分操作无非就是调用操作系统内核的对应接口来完成。

K8S之kubelet介绍

参考文档:

极客时间:深入剖析 Kubernetes

K8S权威指南第5版

https://blog.csdn.net/alex_yangchuansheng/article/details/119686419文章来源地址https://www.toymoban.com/news/detail-462821.html

到了这里,关于K8S之kubelet介绍的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 学习笔记三十一:k8s安全管理:认证、授权、准入控制概述SA介绍

    认证基本介绍:kubernetes主要通过APIserver对外提供服务,那么就需要对访问apiserver的用户做认证,如果任何人都能访问apiserver,那么就可以随意在k8s集群部署资源,这是非常危险的,也容易被黑客攻击渗透,所以需要我们对访问k8s系统的apiserver的用户进行认证,确保是合法的符

    2024年02月06日
    浏览(38)
  • 第四篇:k8s之节点kubelet预留资源配置

    最近k8s在使用过程中遇到这样一个问题 由于Pod没有对内存及CPU进行限制,导致Pod在运行过程中所需的内存超过了节点本身的内存(OOM),从而导致节点崩溃,使得运行在该节点上的所有Pod都失败了 为了解决这个问题以及提高节点的稳定性,综合k8s的一些特性,方案如下 每个

    2024年02月15日
    浏览(41)
  • 主机重启后k8s kubelet无法自动启动问题解决梳理

    OS Version:CentOS Linux release 7.9.2009 (Core) K8S Version:Kubernetes v1.20.4 K8S安装配置完成后,重启服务器发现,kubelet没有正常启动(systemctl status kubelet) 命令: systemctl status kubelet 输入kubectl -n kube-system get pods命令,有如下报错: 命令: kubectl -n kube-system get pods 由于K8S的要求,在部署K8S的服

    2024年02月03日
    浏览(46)
  • k8s中,kubelet 出现问题, k8s-master node not found.

    由于一些其他问题,需要kubeadm reset,在做完kubeadm reset后,出现以下问题。 执行systemctl restart kubelet。 出现 k8s-master node not found,尽管 kubelet依旧是active状态 排查 hostname、etc/hosts等均正常。 通过journalctl -xe kubelet查看,依旧是如下错误。  经过多方尝试未果。又尝试着kubelet初

    2024年02月07日
    浏览(44)
  • k8s kubelet coredns ubuntu修改dns配置文件读取路径

    coredns 服务默认使用节点上的dns配置,由于在 Ubuntu18 及以上版本,默认是启用 systemd-resolved 服务的,且配置nameserver配置文件默认为 /run/systemd/resolve/resolv.conf , 且kubelet默认的dns文件读取也是该文件。因不习惯使用该服务来管理dns配置,所以需要修改kubelet的默认读取dns的文件

    2024年02月15日
    浏览(46)
  • 【K8S系列】深入解析K8S调度

    做一件事并不难,难的是在于坚持。坚持一下也不难,难的是坚持到底。 文章标记颜色说明: 黄色 :重要标题 红色 :用来标记结论 绿色 :用来标记论点 蓝色 :用来标记论点 Kubernetes (k8s) 是一个容器编排平台,允许在容器中运行应用程序和服务。今天学习一下k8s调度相关

    2024年02月11日
    浏览(37)
  • k8s kubectl 启动失败Unit kubelet.service entered failed state.

    怀疑是配置文件的路径出现问题 使用命令查看具体的报错信息: 报错显示没有 /usr/local/bin/kubelet 这个文件或目录,实际ls查看是有的。 此时配置文件存在,怀疑是路径出现问题,找不到。后来检查kubelet.service文件,发现配置了 “WorkingDirectory”,给它指定了工作目录。重新

    2024年01月16日
    浏览(51)
  • K8S调度

    1.scheduler 的调度策略 1.标签的管理 2.亲和性 2.1节点亲和性 2.2Pod亲和性 2.3亲和性的策略 3.污点(taint) 3.1配置 3.2污点删除 3.3查看节点有哪些污点 4.容忍 (tolerations) 4.1配置 5.不可调度(cordon) 6.不可调度 + 驱逐(drain) 7.Pod的启动过程 8.Pod的生命周期 生命周期状态 说明 Pendi

    2024年02月13日
    浏览(30)
  • k8s资源调度

    默认的情况下,一个pod在哪个node节点上运行,是由scheduler组件采取对应的算法计算出来的,这个过程是不受人工控制的,在实际的使用过程中,这不能够满足客观的场景,针对这样的情况,k8s 提供了四大类调度方式: 自动调度: 运行在哪个node节点上完全由scheduler 经过一些里

    2024年02月08日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包