共计 857 个字符，预计需要花费 3 分钟才能阅读完成。
好不容易，终于来到 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 和端口了
就看这个流程，如同也不简单嘛，那么理论生产环境中也会是这样的吗？咱们能够思考一下
明天就到这里，学习所得，若有偏差，还请斧正
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~