揭秘 kubelet：Kubernetes 集群中的节点管理器 (揭秘昆虫)

简介

在 Kubernetes 生态系统中，kubelet 是一个至关重要的组件，负责管理集群中的每个节点。它作为 Kubernetes 控制平面和节点之间的桥梁，协调节点上的容器生命周期和资源分配。

kubelet 的职责

kubelet 的职责包括：

• 启动和管理容器：创建、启动和停止 pod 中的容器。
• 监控和报告节点健康状况：收集并报告有关节点资源使用情况、事件和状态的指标。
• 资源分配：根据节点可用资源分配容器资源。
• 安全管理：执行安全策略并验证容器映像。

---

kubernetes集群的node节点组件服务是

节点组件服务是kubelet、kube-proxy、ContainerRuntime、kube-dns/CoreDNS、fluentd/FluentBit、kubelet-cadviso。 1、kubelet：是每个node节点上的主要组件，用于管理node节点上的容器。 kubelet负责与KubernetesAPIServer交互，接收Pod的描述信息，并确保Pod中的容器正常运行。 2、kube-proxy：是Kubernetes中用于实现Service的组件之一。 kube-proxy负责为Service提供负载均衡和服务发现功能，同时维护着node节点上的iptables规则，以便将Service的流量正确地路由到后端Pod。 3、ContainerRuntime：是Kubernetes中用于运行容器的底层组件。 Kubernetes支持多种容器运行时，如Docker、containerd、CRI-O等，其中Docker是最为常用的容器运行时之一。 4、kube-dns/CoreDNS：是Kubernetes中用于服务发现和DNS解析的组件。 kube-dns/CoreDNS负责将Service名称解析为对应的PodIP地址，以便其他Pod能够与该Service通信。 5、fluentd/FluentBit：是Kubernetes中用于日志收集和聚合的组件。 fluentd/FluentBit可以将Pod和node节点上产生的日志收集并发送到指定的日志存储系统中，例如Elasticsearch、Logstash等。 6、ubelet-cadvisor：是Kubernetes中用于监控node节点上容器资源使用情况的组件。 kubelet-cadvisor会定期收集node节点上的容器资源使用情况，并将数据发送到KubernetesAPIServer，以供管理员进行监控和分析。

2021-10-这一篇 K8S（Kubernetes）我觉得可以了解一下！！！28

Kubernetes是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。

Kubernetes简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。

Kubernetes即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从创建应用>应用部署>提供服务>动态伸缩>应用更新 一系列服务，提高了容器集群管理的便捷性。

大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。

但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：

如果我想要部署，以下几台机器：

如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。

并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务弹性扩容机制也能够很好的应对突发流量。

Docker-Compose是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去操作，是非常耗费时间的，如果有了 Docker-Compose只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。

Docker Swarm是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose单节点的缺陷， Docker Swarm可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，

Kubernetes它本身的角色定位是和 Docker Swarm是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes正在成为容器编排领域的领导者，其 可配置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。

在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种

打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。

Pod里面到底装的是什么？

具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。

pause容器：

Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的 一个Pod中的应用容器共享同一个资源：

在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。

在 Kubernetes中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service

Service是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信

我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service是通过 Label Selector来进行定义的。

使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。

Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行操作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行操作。

用户通过Kubectl 提交一个创建Replication Controller 请求，这个请求通过 API Server写入 etcd中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server写到我们 etcd里面

到下面，如果被 Scheduler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人操心，然后通过 API Server将这个结果也写到etcd中，随后，我们的Node 上运行的小管家 Kubelet 进程通过 API Server检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。

然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。

kube-proxy：是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的

kubelet：用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里

etcd：用于持久化存储集群中所有的资源对象，API Server提供了操作 etcd的封装接口API，这些API基本上都是对资源对象的操作和监听资源变化的接口

API Server ：提供资源对象的操作入口，其他组件都需要通过它提供操作的API来操作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。

Scheduler ：调度器，负责Pod在集群节点中的调度分配。

Controller Manager：集群内部管理控制中心，主要是实现Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由Controller Manager 完成。

到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。

关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。

我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。

超全K8s集群构建指南，建议收藏

1. 什么是kubernetes 　Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

2. kubernetes核心组件说明 Kubernetes 集群中主要存在两种类型的节点，分别是 master 节点 ，以及 minion 节点 。

Minion 节点是实际运行 Docker 容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。

Master 节点负责对外提供一系列管理集群的 API 接口，并且通过和 Minion 节点交互来实现对集群的操作管理。

apiserver ：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查操作，提供了 RESTFul 风格的 API 接口，通过 etcd 来实现持久化并维护对象的一致性。

scheduler ：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheduler 通过一定的调度算法从而找到最合适的节点。

controller-manager ：主要是用于保证 replicationController 定义的复制数量和实际运行的 pod 数量一致，另外还保证了从 service 到 pod 的映射关系总是最新的。

kubelet ：运行在 minion 节点，负责和节点上的 Docker 交互，例如启停容器，监控运行状态等。

proxy ：运行在 minion 节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。

etcd ：key-value键值存储数据库，用来存储kubernetes的信息的。

flannel ：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。

我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。

Flannel 的目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。

3. Kubernetes的核心概念

运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。

Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

Replication Controller Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。

集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。

Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。

Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

Node是Kubernetes集群架构中运行Pod的服务节点（或agent）。

Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。

4. 前置条件设置 三台Centos7系统的虚拟机（1个master+2个node）,三台机器上的防火墙，SELINUX全部关掉。我的实验坏境可以上网，默认的YUM源就可以用。

5. 部署规划 192.168.10.1 # master节点(etcd,kubernetes-master)192.168.10.2 # node1节点(etcd,kubernetes-node,docker,flannel)192.168.10.3 # node2节点(etcd,kubernetes-node,docker,flannel)

6. 开始安装

step1：在master上安装 yum install kubernetes-master etcd flannel -y

step2：在node上安装 yum install kubernetes-node etcd flannel -y

step3：etcd集群配置 在master节点上编辑etcd配置文件

在node1节点上编辑etcd配置文件

在node2节点上编辑etcd配置文件

到此etcd集群就部署完了，然后每个节点上启动systemctl start etcd

step4：验证

step6：启动Master上的三个服务

step7：kubernetes node安装

node2 节点重复上述操作step8：分别启动kubernetes node服务

7. 网络配置 因为kubernetes集群中网络部分是插件形式安装的，我们这里选用flannel上述安装步骤已经install 了

为flannel创建分配的网络

8. 执行kubectl 命令检查 在master上执行下面，检查kubernetes的状态

9. 常用排错命令如下

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！