k8s 自身原理 3

前面有分享到 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 通信,告知 容器的状态,事件 和 资源消耗

可以画一个图来进行展示一波:

k8s 自身原理 3_第1张图片

通过上图我们可以看出,对于创建 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 了,就不再是给代理服务器了

可以这样理解,第一种和第二种代理方式的对比

k8s 自身原理 3_第2张图片

明眼人都看得出来上述 演变过程的区别,第一种,iptables 会将数据传递给代理服务器,但是第二种是直接将数据给到 pod,所以 第二种的性能会更好,少了一个中间商赚差价

今天就到这里,学习所得,若有偏差,还请斧正

欢迎点赞,关注,收藏

朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力

k8s 自身原理 3_第3张图片

好了,本次就到这里

技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。

我是阿兵云原生,欢迎点赞关注收藏,下次见~

你可能感兴趣的:(kubernetes)