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 通信，告知 容器的状态，事件 和 资源消耗

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

通过上图我们可以看出，对于创建 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-20220219221227431

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