服务是如何实现的
kube-proxy
和Service相关的任何事情都有每个节点上运行的kube-proxy进程处理。开始的时候，kube-proxy确实是一个proxy，等待连接，对每个进来的连接，连接到一个pod。这称为userspace（用户空间）代理模式。后来，性能更好的iptables代理模式取代了它。iptables代理模式目前是默认的模式。
每个Service有其自己稳定的IP地址和端口。客户端（通常为pod）通过连接该IP和端口使用服务。IP地址是虚拟的，没有被分配给任何网络接口，当数据包离开节点时也不会列为数据包的源或目的IP地址。Service的一个关键细节是，它们包含一个IP、端口对（或者针对多端口Service有多个IP、端口对），所以服务IP本身并不代表任何东西。这就是为什么你不能够ping它们。
关于IPTABLES的手记
本文只介绍iptables操作时的一些命令记录，对于iptables的其它概念如表，链，规则等不再赘述
在对iptables操作时需要尤其小心，对于防火墙添加的失误会造成程序间端口无法访问，导致业务受影响甚至停摆。
–APPEND -A
-A chain – 指定规则应该添加到的 chain 的名称。例如，使用 INPUT 将会把规则添加到默认的 INPUT（入站）链的末尾，而使用 OUTPUT 则会将规则添加到出站链的末尾。
1 | iptables -A chain firewall-rule |
-A 的意思是附加（append），并不是添加（add）的意思，它是将规则添加到已有的防火墙链（chain）的末尾的操作指令。这是特别重要的，因为规则在 iptables 中的位置非常重要，所以千万记住，-A 的意思是将规则添加到末尾，因为一般情况下 iptables 中最后一条规则是丢弃所有数据包。如果你已经有了一条这样的规则，使用 -A 参数添加的规则将会在丢弃规则之后，以至于新规则根本无法起作用。如果要插入到中间位置，需要用 -I 指令。