重庆网站建设帝玖科技,手机网站建设价钱是多少,芜湖网站,flash网站源码带asp后台好不容易#xff0c;终于来到 k8s 自身的原理之 关于 Service 的一部分了
前面我们用 2 个简图展示了 pod 之间和 pod 与 node 之间是如何通信息的#xff0c;且通信的数据包是不会经过 NAT 网络地址转换的
那么 Service 又是如何实现呢#xff1f;
Service 我们知道是用…好不容易终于来到 k8s 自身的原理之 关于 Service 的一部分了
前面我们用 2 个简图展示了 pod 之间和 pod 与 node 之间是如何通信息的且通信的数据包是不会经过 NAT 网络地址转换的
那么 Service 又是如何实现呢
Service 我们知道是用来对外暴露服务的 ip 和 端口的好让外部的客户端可以访问到我们内部 pod 提供的服务
另外 Service 管理的 pod 实际的 ip 和 端口 列表都是存放在对应的 endpoints 里面的
目前为止我们也仅仅是停留在会使用 Service 了那么 Service 自身的原理又是如何呢我们一起来瞅瞅看
对于 Service 的服务 ip 地址也是一个虚拟的同时也是对外暴露了 1 个或者多个端口既然是虚拟的咱们肯定是 ping 不通的例如我的 minikube 环境 当然我们看了之前的分享之后发现 k8s 中对于资源的变动基本上都是使用的监听机制那么对于 Service 的行为 和 endpoints 的行为是不是同样是被不同的关键组件所监听呢
我们可以用一个简图来了解一下 图中我们可以看到
一个 Service 管控的是 2 个 pod具体的 ip 和 端口 列表 都是存放在 endpoints 中kube-proxy 会监控 ApiServer 中 Endpoints 对象的变化若 endpoints 这中 list 有变化kube-proxy 监听到之后就会通知 iptables 去配置新的规则例如环境中的 一个 pod 3 发请求给到咱们这个 Service发出来的 目的地址是 Service 的地址和端口但是通过 iptables 设定的规则进行转换目的地址和端口就变成了 Service 管控的 pod 自己的 ip 和端口了
就看这个流程好像也不复杂嘛那么实际生产环境中也会是这样的吗我们可以思考一下
今天就到这里学习所得若有偏差还请斧正
欢迎点赞关注收藏
朋友们你的支持和鼓励是我坚持分享提高质量的动力 好了本次就到这里
技术是开放的我们的心态更应是开放的。拥抱变化向阳而生努力向前行。
我是阿兵云原生欢迎点赞关注收藏下次见~ 更多的可以查看 零声每晚八点直播https://ke.qq.com/course/417774
