前面有分享到 master 主节点上的 四个组件,etcd,ApiServer,scheduler,controller manager
接下来我们分享一波 woker 节点上的组件,xdm 还记得 worker 节点上都有什么吗?
kubectl 前面多多少少说了一些,但是 kubectl 具体是做啥的呢?
kubelet 是运行在节点中的关键节点之一,主要负责运行在该节点上的所有组件,总的来说 kubelet 会做这么 3 件事情:
上述第二点,是否会有这样的疑问,kubelet 是自己去运行 pod 吗?
实际上是 kubelet 会去告知配置好的容器,在运行的时候去拉取特定的镜像,接下来,kubelet 还会监控运行中的容器,并和 ApiServer 通信,告知 容器的状态,事件 和 资源消耗
可以画一个图来进行展示一波:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hLLj0cPX-1691758700208)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d42b3b7fa34f4ed29978262fece33a33~tplv-k3u1fbpfcp-zoom-1.image)]
通过上图我们可以看出,对于创建 pod,资源清单在 master 节点上或者是 worker 节点的本地清单目录里,kubelet 都是可以运行,管理和监控他们的
上述的容器 B 就是通过 ApiServer 来获取的 pod 资源清单,进而创建的 pod 容器,和监控 容器 B
容器 A 就会 worker 节点自身清单目录里面的 pod 清单,kubelet 仍然可以直接使用该清单创建 pod,管理并监控容器 A
首先来看看 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 了,就不再是给代理服务器了
可以这样理解,第一种和第二种代理方式的对比
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9yqACsbP-1691758700210)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a21f3a94e4084ec68550b515e412d37d~tplv-k3u1fbpfcp-zoom-1.image)]
明眼人都看得出来上述 演变过程的区别,第一种,iptables 会将数据传递给代理服务器,但是第二种是直接将数据给到 pod,所以 第二种的性能会更好,少了一个中间商赚差价
今天就到这里,学习所得,若有偏差,还请斧正
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ucgb5BqC-1691758700211)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/84ed6ab6b83748b18a8763f30e7a57d8~tplv-k3u1fbpfcp-zoom-1.image)]
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是阿兵云原生,欢迎点赞关注收藏,下次见~
更多的可以查看 零声每晚八点直播:https://ke.qq.com/course/417774