前面有分享到 master 主节点上的 四个组件，etcd，ApiServer，scheduler，controller manager
接下来我们分享一波 woker 节点上的组件，xdm 还记得 worker 节点上都有什么吗？
- kubelet
- kube-proxy
- 实际的服务对应的容器
kubectl 前面多多少少说了一些，但是 kubectl 具体是做啥的呢？
Kubelet
kubelet 是运行在节点中的关键节点之一，主要负责运行在该节点上的所有组件，总的来说 kubelet 会做这么 3 件事情：
- 请求 ApiServer ，注册当前节点，创建一个 node 资源
- 持续监控 ApiServer 关于需要调度到自己节点的 pod，并启动 pod 容器
- kubelet 组件也会运行容器的存活探针
上述第二点，是否会有这样的疑问，kubelet 是自己去运行 pod 吗？
实际上是 kubelet 会去告知配置好的容器，在运行的时候去拉取特定的镜像，接下来，kubelet 还会监控运行中的容器，并和 ApiServer 通信，告知 容器的状态，事件 和 资源消耗
可以画一个图来进行展示一波：
[图片上传失败...(image-754094-1691758972230)]
通过上图我们可以看出，对于创建 pod，资源清单在 master 节点上或者是 worker 节点的本地清单目录里，kubelet 都是可以运行，管理和监控他们的
上述的容器 B 就是通过 ApiServer 来获取的 pod 资源清单，进而创建的 pod 容器，和监控 容器 B
容器 A 就会 worker 节点自身清单目录里面的 pod 清单，kubelet 仍然可以直接使用该清单创建 pod，管理并监控容器 A
节点中另一关键组件 - kube-proxy
首先来看看 kube-proxy 这个组件具体是干啥的，还记得之前我们也分享过，分享关于证书，访问 pod 元数据的那一篇
看名字应该知道他是一个 代理，具体作用是确保客户端可以通过 k8s 的 api 连接到咱们定义的服务上，这个可以看看之前分享的文章 【k8s 系列】k8s 学习二十四，如何访问 pod 元数据
那么为什么要叫他代理呢？
我们来回顾一下，叫代理，是因为他是一个中间商，可以促进两头的人进行正常的交易
例如：
小 A 期望和 小 C 合作，但是由于某种限制，小 A 无法与小 C 搭上线，可 小 B 可以直接和小 C 合作，小 A 也可以和小 B 说上话，那么 小A 就拜托小 B 帮忙和小 C 合作，完成 小 A 需要做的事情
那么这个时候，这里的 小 B 就是一个代理，若把 小 A 看成客户端，小 C 看成服务端，那么 小 B 还是一个正向代理 ， 对于 小 C 来说，小 A 是不可见的，是被隐藏的，对这一块感兴趣的可以查看一下往期文章：简单理解正向代理和反向代理
那么此处的 kube-proxy 是代理什么角色呢？
刚开始的一种代理方式是这样的， kube-proxy 代理配置 iptables， 将服务器的连接进行拦截，重定向到代理服务器，并代理给到 pod 中
向后发展的时候，就演化成了 iptables 代理模式，就逐渐演化成了给 iptables 配置规则，直接重定向数据包给到任意一个 pod 了，就不再是给代理服务器了
可以这样理解，第一种和第二种代理方式的对比
[图片上传失败...(image-c9af39-1691758972230)]
明眼人都看得出来上述 演变过程的区别，第一种，iptables 会将数据传递给代理服务器，但是第二种是直接将数据给到 pod，所以 第二种的性能会更好，少了一个中间商赚差价
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
[图片上传失败...(image-a1860a-1691758972230)]
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
网友评论