逻辑上，如上图所示。在LB部分的实现上，K8s很巧妙的要求每个节点上面都一个“小LB”。
所以实现上，大致如上图所示。
Ø 本地LB
本地LB，要求每个节点都有。所以最开始的版本，K8s使用了Linux使用广泛的iptables来实现。
后面由于iptables性能不是特别给力，又有了 IPVS 实现。然后其他各式各样的民间实现也有。
Ø 本地控制器
LB需要一个控制器，每个本地“小LB”带配备一个小控制器，一样的，也是每个节点一个。和小LB一一对应。K8s给它取了个名字：Kube-proxy
Ø 假IP地址
每个K8s上的App，都可以申请“行走江湖的名号”，用来代表自己。K8s就会给你的App分配一个Service许可证，许可证上面带着“影子IP”，任何集群内部只要访问这个IP，就等于访问你的App。
实现上：
1. 先到K8s那登记，说我想要个“名号”
2. 通过后，K8s会告知每个节点上的本地LB
3. 从此以后，每个LB都认识这个“影子IP”了，访问它，就代表访问对应App。
由于这个“名号”是集群颁布的，所以仅在集群内有效。K8s取名：ClusterIP（3）。
关于东西流量的故事，还可以去看看唐老师之前的《网络骗子》篇。
4.3 Docker原生访问方式除了上面几种访问方式，K8s也为原生的Docker访问通道留了个名字：NodePort（4）。
这种方式，在《Docker网络实现》里面说过，靠主机Host转发实现。既然是主机搞定，所以这条路和本地LB实现，就合并一起搞定了。
如上图，K8s下发规则的时候，顺便把这条路的规则也下发下去。
ps：由于每个本地LB都收到了K8s的通告小皮鞭，所以每个K8s的节点，都开通了NodePort通道哦。即：无论哪个Slaver节点的Port都可以通往该App。
4.4 小结K8s在实现容器网络的时候，造了很多概念：
（1）LoadBalancer
（2）Ingress
（3）ClusterIP
（4）NodePort
本质都是一样的，就是LB+登记规范。 如果你看过《DNS篇》+《Docker网络实现》，这些就比较好理解。