【k8s 系列】k8s 学习二十七 - 6，k8s 自身原理之 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 和端口了

就看这个流程，好像也不复杂嘛，那么实际生产环境中也会是这样的吗？我们可以思考一下

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

欢迎点赞，关注，收藏

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

好了，本次就到这里

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

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