跟唐老师学习云网络 - Kubernetes网络实现

举报
tsjsdbd 发表于 2020/04/24 16:26:06 2020/04/24
【摘要】 当今K8s独霸天下之时,咱们站在更高的角度,好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆,是如何分别照顾 南北流量和东西流量的。

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

 

1      简单介绍下Kubernetes

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

ps:本章节可参考唐老师的《K8S前世今生》文章)

 

2      世界上的集群都一个样

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

Ø  OpenStack:在一大堆物理机上面,管理(启动/停止)VM的。

Ø  SGESlurmPBS:在一大堆电脑集群里面,管理(启动/停止)App的。

Ø  Yarn:在一大堆电脑集群里面,管理(启动/停止)大数据App的。

Ø  CloudFoundry:在一大堆电脑集群里面,管理(启动/停止)容器的

Ø  Kubernetes:在一大堆电脑集群里面,管理(启动/停止)容器的。

它们都有一些共同特点:

2.1      跨节点跑xx程序

image.png

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

 

2.2      有一个管事的老大

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

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

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

 

2.3      小弟上面都有一个Agent

image.png

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

OpenStack:取名Nova

Kubernetes:取名Kubelet

Yarn:取名NodeManager

 

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

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

Ø  OpenStack:用 RabbitMQ 发号施令

Ø  Kubernetes:用 ETCD 发号施令

Ø  CloudFoundry:用 NATS 发号施令

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

 

比如我们的K8s

image.png

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

 

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

3.1      南北流量

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

image.png

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

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

 

PsPaaS的基本原型大致都这样:

image.png

 

3.2      东西流量

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

1587716488103028427.png

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

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

 

3.3      Docker原生访问方式

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

image.png

 

3.4      小结:K8s3种访问容器的通道

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

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

(3)       通过Docker原生自带的方式,访问App容器

image.png

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

 

 

4      K8s怎么实现容器访问

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

 

4.1      南北流量

要实现一个App的访问通道,一定要2个东西:(1LB负载均衡器 + 2)注册映射关系。

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

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

image.png

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

 

Ø  4LB

最简单的4LB实现,K8s取了个名字:LoadBalancer1

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

 

Ø  7LB

为了定义7LB的规则,K8s给规范取了名字:Ingress2

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

 

南北LB都是全局级的,即:全局一个(HA多实例,咱也当一个整体)就行;不需要每个Slaver节点上一个。

 

4.2      东西流量

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

image.png

逻辑上,如上图所示。在LB部分的实现上,K8s很巧妙的要求每个节点上面都一个“小LB”。

image.png

所以实现上,大致如上图所示。

 

Ø  本地LB

本地LB,要求每个节点都有。所以最开始的版本,K8s使用了Linux使用广泛的iptables来实现。

后面由于iptables性能不是特别给力,又有了 IPVS 实现。然后其他各式各样的民间实现也有。

 

Ø  本地控制器

LB需要一个控制器,每个本地“小LB”带配备一个小控制器,一样的,也是每个节点一个。和小LB一一对应。K8s给它取了个名字:Kube-proxy

 

image.png

Ø  IP地址

每个K8s上的App,都可以申请“行走江湖的名号”,用来代表自己。K8s就会给你的App分配一个Service许可证,许可证上面带着“影子IP”,任何集群内部只要访问这个IP,就等于访问你的App

image.png

实现上:

1.     先到K8s那登记,说我想要个“名号”

2.     通过后,K8s会告知每个节点上的本地LB

3.     从此以后,每个LB都认识这个“影子IP”了,访问它,就代表访问对应App

image.png

由于这个“名号”是集群颁布的,所以仅在集群内有效。K8s取名:ClusterIP3

关于东西流量的故事,还可以去看看唐老师之前的《网络骗子》篇。

 

4.3      Docker原生访问方式

除了上面几种访问方式,K8s也为原生的Docker访问通道留了个名字:NodePort4

这种方式,在《Docker网络实现》里面说过,靠主机Host转发实现。既然是主机搞定,所以这条路和本地LB实现,就合并一起搞定了。

image.png

如上图,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南北流量,用Loadbalancer4层)和Ingress7层)搞定。

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

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

 

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


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。