当今K8s独霸天下之时，咱们站在更高的角度，好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆，是如何分别照顾 南北流量和东西流量的。

1      简单介绍下Kubernetes

略。。容器集群管理的事实标准了，不知道要打屁股。

（ps：本章节可参考唐老师的《K8S前世今生》文章）

2      世界上的集群都一个样

有点标题党哈，不过我接触过的各种集群也不少，各种各样：

Ø  OpenStack：在一大堆物理机上面，管理（启动/停止）VM的。

Ø  SGE，Slurm，PBS：在一大堆电脑集群里面，管理（启动/停止）App的。

Ø  Yarn：在一大堆电脑集群里面，管理（启动/停止）大数据App的。

Ø  CloudFoundry：在一大堆电脑集群里面，管理（启动/停止）容器的

Ø  Kubernetes：在一大堆电脑集群里面，管理（启动/停止）容器的。

它们都有一些共同特点：

2.1      跨节点跑xx程序

这个xx程序一定是首先单机可以运行的。比如OpenStack：单机上面可以用qemu启动VM，想跨节点管理VM，就引入了OpenStack。Kubernetes也一样：单机上面可以跑Docker容器；想跨节点管理容器，就得引入集群管理老大的概念。

2.2      有一个管事的老大

A）集群管理的老大，负责让手下的某个小弟干活。别管是命令式（直接下命令）的，还是申明式（发告示）的，小弟收到命令后，乖乖干活就是了。

B）       同时，这个集群管理的老大，需要有脑子，不然小弟数量多了管不好。所以它需要拿笔记一记。比如OpenStack的老大得带个Mysql数据库；Kubernetes把笔记记在了ETCD里面（不过ETCD这个本子太小，记得东西不能太大，这是另话）。

C）       不管哪种老大，都得有个军师。一个新活来到老大这里，那么多小弟，指派给谁不是干呀。这活实际分配给哪个小弟，这得军师说了算，所以每中集群软件都自己写了一套 Scheduler 算法，可谓程序员间浪费重复轮子之典型代表。

2.3      小弟上面都有一个Agent

这个小弟上面的Agent，时刻向老大汇报自己的状态：活不活着，忙还是闲，方便老大派活。同时，Agent也就是那台电脑里面的地头蛇了，帮忙老大负责各种临时事物。只是大家的取名不一样：

OpenStack：取名Nova

Kubernetes：取名Kubelet

Yarn：取名NodeManager

2.4      老大怎么给小弟发号施令

一般老大都是通过：消息队列来，给小弟发号施令的，而不是亲自上门（直连）下达命令。原因么，当然是小弟可能临时出门（故障）了呗~ 直接上门可能不通，放消息队列里面就可靠多了。等小弟出差回来，还能看到老大下达的任务令。

Ø  OpenStack：用 RabbitMQ 发号施令

Ø  Kubernetes：用 ETCD 发号施令

Ø  CloudFoundry：用 NATS 发号施令

上面这些组件都是带消息通知的功能，区别有些有名，有些没那么出名罢了。

比如我们的K8s：

特别需要提一下：K8s这个老大不简单，找了个ETCD这个好帮手。这小家伙挺神，既能当笔记本记点事情（代替OpenStack中的Mysql），又能当公告牌，通知点消息（代替OpenStack中的Rabbit）。所以K8s这个容器集群管理相对OpenStack这个虚机管理不需要数据库，666~

3      K8s怎么设计容器网络的呢

3.1      南北流量

要看到K8s诞生的时候，那时是有CloudFoundry和Docker的，且都已经比较成熟。那时作为PaaS一哥的CF对容器网络的抽象：

主要考虑平台外部，怎么访问容器里面的App。而平台内部的App之间如何互相访问，几乎没有太多的设计。

由上图所示，可以看到，平台外部访问，一般都是上下画的，所以也叫做南北流量。我们这么叫，也是便于程序员之间沟通和理解。

Ps：PaaS的基本原型大致都这样：

3.2      东西流量

K8s吸取了前辈们的精华，除了平台外部访问App，还新增考虑了平台内部，App之间如何互相访问。

即K8s通过增加一个负载均衡的“LB”设备，来搞定平台内部的App间互相访问。给每个App取个别名，在LB上面登记一下，就可以被内部其他App访问。

由上图所示，可以看到，平台内部访问，一般都是水平画的，所以也叫做东西流量。一个完整的PaaS平台，就是需要南北流量+东西流量，全套治理的。

3.3      Docker原生访问方式

还记得唐老师的《Docker网络实现》章节吧，Docker容器可以通过“节点IP+节点Port”的方式访问到容器。原理的容器所在节点，设置了NAT规则。报文一到达节点，根据目的端口，转发进入容器。

3.4      小结：K8s中3种访问容器的通道

（1）       通过南北流量（从集群外部访问App）访问App容器

（2）       通过东西流量（集群内App之间）访问App容器

（3）       通过Docker原生自带的方式，访问App容器

下一章节，我们简单介绍下每种方式，K8s分别怎么去实现的。

4      K8s怎么实现容器访问

虽然K8s上面，有多种访问App容器的方法。但是不管用什么方式访问，一个App想要能被访问，就得得到K8s的同意。K8s把这个许可证叫做“Service”：也就是不管什么南北流量、东西流量，你的App想要能被访问，就得先申请Service许可证。

4.1      南北流量

要实现一个App的访问通道，一定要2个东西：（1）LB负载均衡器 + （2）注册映射关系。

映射关系就是：报文来了，应该转发给哪个App实例？ 即：找到 “哪个App + 哪个实例”。

负载均衡器呢，一般大家爱用Nginx，不过也有其他类型的实现。

K8s比CF聪明的地方是，没有自己去实现LB。而只定义了App需要怎么样才能登记到LB上面。即只定规范，不限制实现（这种思路，在k8s里面好多，比如存储的CSI，运行时的CRI的，容器网络的CNI 都是这样。）

Ø  4层LB

最简单的4层LB实现，K8s取了个名字：LoadBalancer（1）。

即定义：xx协议+xx端口 =》xx应用，具体规则自己去看资料。

Ø  7层LB

为了定义7层LB的规则，K8s给规范取了名字：Ingress（2）。

即定义：xx网址+xx-URL路径 =》xx应用，具体规则也自己看K8s资料。

南北LB都是全局级的，即：全局一个（HA多实例，咱也当一个整体）就行；不需要每个Slaver节点上一个。

4.2      东西流量

东西流量，也一样，需要LB+规则注入。这里，K8s设计就比较有意思。

逻辑上，如上图所示。在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网络实现》，这些就比较好理解。

ps：具体本地LB怎么实现？真有兴趣可以去搜搜Kube-proxy的代码解读。我本身不是很关心，因为其实你给每个节点安装一个 Nginx 也可以做到的。

5      总结

K8s的网络概念，特别是Service，是K8s里面的精华，务必需要搞明白。

（1）       K8s南北流量，用Loadbalancer（4层）和Ingress（7层）搞定。

（2）       K8s的东西流量，用Service概念搞定。特别的，还给了个“行走江湖用的名号”，取名ClusterIP（一个不存在的假IP地址）。

（3）       容器所在Host组网，存在Docker原生通道，K8s给重新包装了个名字：NodePort。所以只要报文到达Slaver节点，就能通到容器里面。

另外，提一下一直没有说的东西（怕概念太多，影响理解）：K8s的整个网络底座，是要求节点IP和容器IP是能互相连通的（即：在节点上面ping容器IP，是可以通的）。具体则是通过容器网络实现的。这个实现很多，Flannel，Calico等，本质要么隧道，要么子网（可以看看物理网络里面的《VLAN和Vxlan》篇，关于如何划分门派的篇章）。