PS： 以下都是博主的自学笔记 + 个人理解的概括，很抱歉没有准备图文形式描述，欢迎大家提问交流。
在上一章节的基本概念中，我们有提到Service基本概念。 我们知道Service是对Pod访问的一种抽象。
本章节，我们来聊一下，Service的工作原理。 概括总结几个常见疑惑。
一、负载均衡方式
Round Robin方式，对于这种方式我们成为“Cluster IP” 模式的Service;
二、 Kubernetes Service 究竟是如何工作的呢？
实际上，Service是由 kube-proxy组件，加上 iptables来共同实现的。
- kube-proxy 创建一条 iptables 规则。这条 iptables 规则的含义是：凡是目的地址是 clusterip(service vip如：10.0.1.17）、目的端口是 80 的 IP 包，都应该跳转到另外一条名叫 KUBE-SVC-NWV5X2332I4OT4T3 的 iptables 链进行处理。
- 而这个规则是一组随机模式的 iptables链，随机转发地址是 xxx,xxx,xxx,如： （KUBE-SEP-WNBA2IHDGP2BOBGZ、KUBE-SEP-X3P2623AGDH6CDF3 和 KUBE-SEP-57KPRZ3JQVENLNBR）
- 而者三条链(其实就是三条 DNAT规则)指向的最终目的地就是 service代理的三个pod
- DNAT规则就是，就是在 PREROUTING 检查点之前，也就是在路由之前，将流入 IP 包的目的地址和端口，改成–to-destination 所指定的新的目的地址和端口。可以看到，这个目的地址和端口，正是被代理 Pod 的 IP 地址和端口。
这样，访问 Service VIP 的 IP 包经过上述 iptables 处理之后，就已经变成了访问具体某一个后端 Pod 的 IP 包了。不难理解，这些 Endpoints 对应的 iptables 规则，正是 kube-proxy 通过监听 Pod 的变化事件，在宿主机上生成并维护的。
三、kube-proxy的ipvs模式又是啥？
kube-proxy iptables 模式需要一直刷新、监听、更改，消耗CPU资源，限制了kubernetes 项目承载更多的Pod。 kube-proxy就是解决这个问题行之有效的方法；
- 当我们创建了前面的 Service 之后，kube-proxy 首先会在宿主机上创建一个虚拟网卡（叫作：kube-ipvs0），并为它分配 Service VIP 作为 IP 地址；
- kube-proxy 就会通过 Linux 的 IPVS 模块，为这个 IP 地址设置三个 IPVS 虚拟主机，并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略；
- 这三个 IPVS 虚拟主机的 IP 地址和端口，对应的正是三个被代理的 Pod；
四、Service与DNS关系
在 Kubernetes 中，Service 和 Pod 都会被分配对应的 DNS A 记录（从域名解析 IP 的记录）
-
ClusterIp Service: {serviceName}.{namespace}.svc.cluster.local (可简写成 [svcname.namespace])，访问这条A记录的时候，解析到的是 service 的 vip
-
ClusterIp Service Pod 被分配的A记录：
-
Headless Service： {serviceName}.{namespace}.svc.cluster.local
-
访问这条A记录的时候，解析到的是 service 的 vip，解析到的时候 Pod ip 的集合
-
Headless Service Pods: ...svc.cluster.local