浅谈k8s网络模型及不同node上Pod如何互访

k8s网络模型

接上一篇文章: Overlay和Underlay网络协议区别及概述讲解
Kubernetes 对容器技术做了更多的抽象,其中最重要的一点是提出 pod 的概念,pod 是 Kubernetes 资源调度的基本单元,我们可以简单地认为 pod 是容器的一种延伸扩展,从网络的角度来看,pod 必须满足以下条件:

  1. 每一个 pod 都有独特的 IP 地址,所有 pod 都在一个可以直接连通的、扁平的网络空间中;
  2. 同一个 pod 内的所有容器共享同一个网络命名空间;
    image

基于这样的基本要求,我们可以知道:

  1. 同一个 pod 内的所有容器之间共享端口,可直接通过 localhost + port 来访问;
  2. 由于每个 pod 有单独的 IP,所以不需要考虑容器端口与主机端口映射以及端口冲突问题;

事实上,Kubernetes 进一步确定了对一个合格集群网络的基本要求:

  1. 任意两个 pod 之间其实是可以直接通信的,无需显式地使用 NAT 进行地址的转换;
  2. 任意集群节点与任意 pod 之间是可以直接通信的,无需使用明显的地址转换,反之亦然;
  3. 任意 pod 看到自己的 IP 跟别人看见它所用的 IP 是一样的,中间不能经过地址转换;

也就是说,必须同时满足以上三点的网络模型才能适用于 Kubernetes,事实上,在早期的 Kubernetes 中,并没有什么网络标准,只是提出了以上基本要求,只有满足这些要求的网络才可以部署 Kubernetes,基于这样的底层网络假设,Kubernetes 设计了pod-deployment-service 的经典三层服务访问机制。直到1.1发布,Kubernetes 才开始采用全新的 CNI(Container Network Interface) 网络标准。

CNI

其实,我们在前面介绍容器网络的时候,就提到了 CNI 网络规范,CNI 相对于 CNM(Container Network Model) 对开发者的约束更少、更开放,不依赖于容器运行时。事实上,CNI 规范确实非常简单,详情可以参考github资料:https://github.com/containernetworking/cni/blob/master/SPEC.md
image

实现一个 CNI 网络插件只需要一个配置文件和一个可执行文件:

  • 配置文件描述插件的版本、名称、描述等基本信息;
  • 可执行文件会被上层的容器管理平台调用,一个 CNI 可执行文件需要实现将容器加入到网络的 ADD 操作以及将容器从网络中删除的 DEL 操作(以及一个可选的 VERSION 查看版本操作);

Kubernetes 使用 CNI 网络插件的基本工作流程:

  1. kubelet 先创建 pause 容器创建对应的网络命名空间;
  2. 根据配置调用具体的 CNI 插件,可以配置成 CNI 插件链来进行链式调用;
  3. 当 CNI 插件被调用时,它根据环境变量以及命令行参数来获得网络命名空间、容器的网络设备等必要信息,然后执行 ADD 操作;
  4. CNI 插件给 pause 容器配置正确的网络,pod 中其他的容器都是复用 pause 容器的网络;

如果不清楚什么是 pause 容器,它在pod中处于什么样的位置,请查看从 container 到 pod。

通常来说,CNI 插件可以分为三种:Overlay、路由及 Underlay。
image

  • Overlay 模式的典型特征是容器独立于主机的 IP 段,这个 IP 段进行跨主机网络通信时是通过在主机之间创建隧道的方式,将整个容器网段的包全都封装成底层的物理网络中主机之间的包。该方式的好处在于它不依赖于底层网络;

  • 路由模式中主机和容器也分属不同的网段,它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通,无需在不同主机之间做一个隧道封包。但路由打通就需要部分依赖于底层网络,比如说要求底层网络有二层可达的一个能力;

  • Underlay 模式中容器和宿主机位于同一层网络,两者拥有相同的地位。容器之间网络的打通主要依靠于底层网络。因此该模式是强依赖于底层能力的。

了解了以上三种常用的实现模式之后,再根据自己的环境、需求判断可由哪一种模式进行实现,再在对应的模式中去找 CNI 插件。不过社区中有那么多插件,它们又都属于哪种模式?如何进行选择呢?怎么挑选适合自己的呢?我们可以从以下 3 个方面来考虑。

pod 网络模型

要了解 Kubernetes 网络模型的实现原理,我们就要从单个 pod 入手,事实上,一旦熟悉了单个 pod 的网络模型,就会发现 Kubernetes 网络模型基本遵循和容器网络模型一样的原理。

通过前面的笔记从 container 到 pod,我们知道 pod 启动的时候先创建 pause 容器创建对应的网络命名空间,然后与其他容器共享此网络命名空间。而对于单个容器的网络模型我们之前也介绍过,主要就是通过 docker0 网桥设备与 veth 设备对连接不同的容器网络命名空间,由此,我们可以得到如下图所示的单个 pod 网络模型:
image

主流 Kubernetes 网络实现方案

上一小节我们知道单个 pod 的网络模型是容器网络模型的扩展,但是 pod 与 pod 之间的是怎么相互通信的呢?这其实与容器之间相互通信非常类似,也分为同一个主机上的 pod 之间与跨主机的 pod 之间两种情况。

如容器网络模型一样,对于同一主机上的 pod 之间,通过 docker0 网桥设备直接二层(数据链路层)网络上通过 MAC 地址直接通信:
image

而跨主机的 pod 之间的相互通信也主要有以下两个思路:

  1. 修改底层网络设备配置,加入容器网络 IP 地址的管理,修改路由器网关等,该方式主要和 SDN(Software define networking) 结合。

  2. 完全不修改底层网络设备配置,复用原有的 underlay 网络平面,解决容器跨主机通信,主要有如下两种方式:

  • 隧道传输(overlay):将容器的数据包封装到原主机网络的三层或者四层数据包中,然后使用主机网络的 IP 或者 TCP/UDP 传输到目标主机,目标主机拆包后再转发给目标容器。overlay 隧道传输常见方案包括 Vxlan、ipip 等,目前使用 overlay 隧道传输技术的主流容器网络有 Flannel 等;
    image

  • 修改主机路由:把容器网络加到主机路由表中,把主机网络设备当作容器网关,通过路由规则转发到指定的主机,实现容器的三层互通。目前通过路由技术实现容器跨主机通信的网络如 Flannel host-gw、Calico 等;
    image

下面简单介绍几种主流的方案:

  • **Flannel **是目前使用最为普遍的方案,提供了多种网络后端,它支持多种数据路径,也适合于 overlay/underlay 等多种场景。对于 overlay 的数据包封装,可以使用用户态的 UDP,内核态的 Vxlan(性能相对较好),甚至在集群规模不大,且处于同一个二层域时可以采用 host-gw 的方式修改主机路由表;

  • **Weave **工作模式与 Flannel 很相似的,它最早只提供了 UDP(称为 sleeve 模式)的网络方式,后来又加上了 fastpass 方式(基于 VxLAN),不过 Weave 消除了 Flannel 中用来存储网络地址的额外组件,自己集成了高可用的数据存储功能;

  • **Calico ** 主要是采用了修改主机路由,节点之间采用 BGP 的协议去进行路由的同步,但是现实中的网络并不总是支持 BGP 路由的,因此 Calico 也支持内核中的 IPIP 模式,使用 overlay 的方式来传输数据;

可以看到,同一个 pod 里面的其他容器共享 pause 容器创建的网络命名空间,也就是说,所有的容器共享相同的网络设备、路由表设置、服务端口等信息,仿佛是在同一台机器上运行的不同进程,所以这些容器之间可以直接通过 localhost + port 通信;对于集群外部的请求,则通过 docker0 网桥设备充当的网关,同时通过 iptables 做地址转换。到这里我们就会发现,这其实就是对单个容器的 bridge 网络模型的扩展。

Pod间如何互访

容器到容器的通信

同一个Pod内的容器可以用localhost地址访问彼此的端口。
image

Pod之间的通信
同一个Node内Pod之间的通信
image

不同Node上Pod之间的通信
image

总结
今天的数据中心包含多个集群以及海量的物理机,Overlay 网络是虚拟机和底层网络设备之间的中间层,通过 Overlay 网络这一个中间层,我们可以解决虚拟机的迁移问题、降低二层核心网络设备的压力并提供更大规模的虚拟网络数量:

  • 在使用 VxLAN 构成二层网络中,虚拟机在不同集群、不同可用区和不同数据中心迁移后,仍然可以保证二层网络的可达性,这能够帮助我们保证线上业务的可用性、提升集群的资源利用率、容忍虚拟机和节点的故障;

  • 集群中虚拟机的规模可能是物理机是几十倍,与物理机构成的传统集群相比,虚拟机构成的集群包含的 MAC 地址数量可能多一两个数量级,网络设备很难承担如此大规模的二层网络请求,Overlay 网络通过 IP 封包和控制平面可以减少集群中的 MAC 地址表项和 ARP 请求;

  • VxLAN 的协议头使用 24 位的 VNI 表示虚拟网络,总共可以表示 1600 万的虚拟网络,我们可以为不同的虚拟网络单独分配网络带宽,满足多租户的网络隔离需求;

需要注意的是,Overlay 网络只是一种在物理网络上的虚拟网络,使用该技术并不能直接解决集群中的规模性等问题,而 VxLAN 也不是组建 Overlay 网络的唯一方法,在不同场景中我们可以考虑使用不同的技术,例如:NVGRE、GRE 等。

posted @ 2021-11-17 16:41  记忆流年  阅读(5258)  评论(1编辑  收藏  举报
/* 看板娘 */ /* 粒子吸附*/