由 dawei 概念上来讲，Kubernetes集群的服务，其实就是负载均衡、或反向代理。这跟阿里云的负载均衡产品，有很多类似的地方。和负载均衡一样，服务有它的IP地址以及前端端口;服务后边会挂载多个容器组Pod作为其“后端服务器”，这些“后端服务器”有自己的IP以及监听端口。
当这样的负载均衡和后端的架构，与Kubernetes集群结合的时候，我们可以想到的最直观的实现方式，就是集群中某一个节点专门做负载均衡(类似LVS)的角色，而其他节点则用来负载后端容器组。
这样的实现方法，有一个巨大的缺陷，就是单点问题。Kubernetes集群是Google多年来自动化运维实践的结晶，这样的实现显然与其智能运维的哲学相背离的。
自带通信员
边车模式(Sidecar)是微服务领域的核心概念。边车模式，换一句通俗一点的说法，就是自带通信员。熟悉服务网格的同学肯定对这个很熟悉了。但是可能比较少人注意到，其实Kubernetes集群原始服务的实现，也是基于Sidecar模式的。
在Kubernetes集群中，服务的实现，实际上是为每一个集群节点上，部署了一个反向代理Sidecar。而所有对集群服务的访问，都会被节点上的反向代理转换成对服务后端容器组的访问。基本上来说，节点和这些Sidecar的关系如下图所示。
把服务照进现实
前边两节，我们看到了，Kubernetes集群的服务，本质上是负载均衡，即反向代理;同时我们知道了，在实际实现中，这个反向代理，并不是部署在集群某一个节点上，而是作为集群节点的边车，部署在每个节点上的。
在这里把服务照进反向代理这个现实的，是Kubernetes集群的一个控制器，即kube-proxy。关于Kubernetes集群控制器的原理，请参考我另外一篇关于控制器的文章。简单来说，kube-proxy作为部署在集群节点上的控制器，它们通过集群API Server监听着集群状态变化。当有新的服务被创建的时候，kube-proxy则会把集群服务的状态、属性，翻译成反向代理的配置。
那剩下的问题，就是反向代理，即上图中Proxy的实现。
一种实现
Kubernetes集群节点实现服务反向代理的方法，目前主要有三种，即userspace、iptables以及IPVS。今天我们只深入分析iptables的方式，底层网络基于阿里云Flannel集群网络。
过滤器框架
现在，我们来设想一种场景。我们有一个屋子。这个屋子有一个入水管和出水管。从入水管进入的水，是不能直接饮用的，因为有杂质。而我们期望，从出水管流出的水，可以直接饮用。为了达到目的，我们切开水管，在中间加一个杂质过滤器。
过了几天，我们的需求变了，我们不止要求从屋子里流出来的水可以直接饮用，我们还希望水是热水。所以我们不得不再在水管上增加一个切口，然后增加一个加热器。
很明显，这种切开水管，增加新功能的方式是很丑陋的。因为需求可能随时会变，我们甚至很难保证，在经过一年半载之后，这跟水管还能找得到可以被切开的地方。
所以我们需要重新设计。首先我们不能随