Pod网络;Service网络;网络插件Calico

Pod网络

在K8S集群里,多个节点上的Pod相互通信,要通过网络插件来完成,比如Calico网络插件。

使用kubeadm初始化K8S集群时,有指定一个参数–pod-network-cidr=10.18.0.0/16 它用来定义Pod的网段。

而我们在配置Calico的时候,同样也有定义一个CALICO_IPV4POOL_CIDR的参数,它的值同样也是Pod的网段。

容器网络尤其是在跨主机容器间的网络是非常复杂的。目前主流的容器网络模型主要有Docker公司提出的Container Network Model(CNM)模型和CoreOS公司提出的Container Network Interface(CNI)模型,而Kubernetes采用了由CoreOS公司提出的CNI模型。

1)CNI

首先我们介绍一下什么是 CNI,它的全称是 Container Network Interface,即容器网络的 API 接口。

CNI本身并不能提供网络服务,它只是定义了对容器网络进行操作和配置的规范。CNI仅关注在创建容器时分配网络资源,和在销毁容器时删除网络资源,这使得CNI规范非常轻巧、易于实现,得到了广泛的支持。

而真正实现和落地这些规范的是CNI插件。常见的CNI插件包括Calico、flannel、Terway、Weave Net 以及 Contiv。

2)K8S如何使用CNI插件

K8s 通过 CNI 配置文件来决定使用什么 CNI。

基本的使用方法为:

  • 首先在每个节点上配置 CNI 配置文件(/etc/cni/net.d/xxnet.conf),其中 xxnet.conf 是某一个网络配置文件的名称;

  • 安装 CNI 配置文件中所对应的二进制插件;

  • ls /opt/cni/bin/
    
  • 在这个节点上创建 Pod 之后,Kubelet 就会根据 CNI 配置文件执行前两步所安装的 CNI 插件;

具体的流程如下图所示:

img

在集群里面创建一个 Pod 的时候,首先会通过 apiserver 将 Pod 的配置写入。apiserver 的一些管控组件(比如 Scheduler)会调度到某个具体的节点上去。Kubelet 监听到这个 Pod 的创建之后,会在本地进行一些创建的操作。当执行到创建网络这一步骤时,它首先会读取刚才我们所说的配置目录中的配置文件,配置文件里面会声明所使用的是哪一个插件,然后去执行具体的 CNI 插件的二进制文件,再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络。配置完成之后,Kuberlet 也就完成了整个 Pod 的创建过程,这个 Pod 就在线了。

3)基于Calico的Pod网络

img
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Service网络

在介绍Service这个api资源对象时,我们已经汇总过Service的几个type:ClusterIP、NodePort、LoadeBalancer,除了这三个还有其它的类型,在本章节我们暂且不去讨论。

这三种类型的Service,LoadBalancer依赖NodePort,而NodePort通常要和ClusterIP一起使用,如果在Service的yaml文件里定义type为LoadBalancer,则它会自动创建NodePort,而NodePort也会自动创建ClusterIP。

在这里插入图片描述

下面,再来演绎一下从Pod到Service的网络变化情况:

1)单个Pod之间通信

单个Pod和Pod之间通信只能通过Pod的IP和Port来通信,如下图

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2)Pod有多个

当引入了Deployment,并为Pod设置多个副本时,那么提供某一个服务(如Nginx服务)的Pod就不止一个了,此时即使知道了这些Pod的IP,那访问起来也并不方便。所以,这里需要有一个统一入口,其它Pod通过这个统一入口去请求该服务(Nginx)对应的所有Pod。 这时就有了Service这个资源对象,它主要作用就是用来提供统一入口,也就是说只需要一个IP就能访问所有的Pod,而这个入口IP就是ClusterIP,也就是Service的IP。

在这里插入图片描述

3)外部资源访问内部Pod

有了Service,的确可以很方便为内部的Pod提供入口,但是在集群外面访问这个内部的资源就没办法了。于是,就有了这个NodePort,使用Service的NodePort类型,可以将Service的ClusterIP对应的Port映射到每一个Node的IP上,映射出去的Port范围为30000~32767

在这里插入图片描述

4)借助公有云的负载均衡器

使用这个NodePort并不方便,毕竟它带着一个长长的端口号,而且还有一个非常尴尬的问题,就是访问时还得带着Node的IP,如果这个Node挂掉,那么就无法访问此资源,虽然可以通过另外一个Node去访问,但这样太麻烦了!所以,此时的解决方案是:借助三方的负载均衡器,将请求分发到所有的Node上,其底层还是NodePort。

在这里插入图片描述

总结:Service为内部Pod的统一入口,内部资源之间可以通过最简单的ClusterIP进行通信,而外部资源访问需要借助NodePort的形式,但是带着长长端口不方便,于是又衍生了LoadBalancer的形式,这种形式需要借助三方的负载均衡器,将请求分发到每一个NodePort上。

网络插件Calico

参考 https://www.cnblogs.com/goldsunshine/p/10701242.html

1)Calico是什么

Calico 是一个用于容器、虚拟机和主机的开源网络和网络安全解决方案。它是一个纯三层(L3)解决方案,利用 BGP(Border Gateway Protocol)协议为容器或虚拟机提供 IP 地址,并提供网络安全功能,包括网络策略和加密。

Calico 通过将网络策略应用于标签和选择器,提供了一种简单而强大的方法来保护容器或虚拟机之间的通信,并限制容器或虚拟机可以访问的网络资源。它还支持基于 Kubernetes 和 OpenStack 等平台的网络自动化和集成。

Calico 的另一个重要特点是其可扩展性。它使用了基于 BGP 的路由技术,这使得它能够轻松地扩展到非常大规模的网络中,而不会降低性能。

由于Calico是一种纯三层的方案,因此可以避免与二层方案相关的数据包封装的操作,中间没有任何的NAT,没有任何的overlay,所以它的转发效率是所有方案中最高的,因为它的包直接走原生TCP/IP的协议栈,它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则,所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。

2)Calico架构

在这里插入图片描述

各组件介绍:

  • Felix:Calico Agent,跑在K8S集群中的每台节点上,主要负责管理和维护该节点上的网络和安全策略,如 网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等;
  • Etcd:分布式键值存储,用来存储网络元数据、安全策略以及节点的状态信息,确保Calico网络状态的一致性和准确性,可以和K8S的etcd合用;
  • BGP Client(BIRD):跟Felix一样,每一个节点上都会部署BGP Client,主要负责把Felix写入Kernel的路由信息分发到当前Calico网络,确保各节点间的通信的有效性;
  • BGP Route Reflector(BIRD): 在大型网络规模中,如果仅仅使用BGP Client 形成mesh全网互联的方案就会导致规模限制,因为所有节点之间俩俩互联,需要 N^2 个连接,为了解决这个规模问题,可以采用 BGP 的 Router Reflector 的方法,使所有BGP Client仅与特定RR节点互联并做路由同步,从而大大减少连接数大规模部署时使用。

关键点:

  • Felix会定期查询Etcd数据库,从而获取到IP变化信息,比如说用户在这台机器上创建了一个容器,增加了一个IP等。当它发现数据变更后,比如用户创建pod后,Felix负责将其网卡、IP、MAC都设置好,然后在内核的路由表里面写一条,注明这个IP应该到这张网卡。同样如果用户制定了隔离策略,Felix同样会将该策略创建到ACL中,以实现隔离。
  • BIRD是一个标准的路由程序,它会从内核里面获取哪一些IP的路由发生了变化,然后通过标准BGP的路由协议扩散到整个其他的宿主机上,让外界都知道这个IP在这里,你们路由的时候得到这里来。

3)calico三种网络工作模式

模式说明特点
VXLAN封包, 在vxlan设备上将pod发来的数据包源、目的mac替换为本机vxlan网卡和对端节点vxlan网卡的mac。外层udp目的ip地址根据路由和对端vxlan的mac查fdb表获取只要k8s节点间三层互通, 可以跨网段, 对主机网关路由没有特殊要求。各个node节点通过vxlan设备实现基于三层的“二层”互通, 三层即vxlan包封装在udp数据包中, 要求udp在k8s节点间三层可达;二层即vxlan封包的源mac地址和目的mac地址是自己的vxlan设备mac和对端vxlan设备mac。
IPIP封包,在tunl0设备上将pod发来的数据包的mac层去掉,留下ip层封包。 外层数据包目的ip地址根据路由得到。相当于建立了隧道,把两个本来不通的节点网络通过点对点连接起来。只要k8s节点间三层互通, 可以跨网段, 对主机网关路由没有特殊要求。解包、封包都会造成一定的资源损耗。 适用于互相访问的pod不在同一个网段中、跨网段访问的场景。外层封装的ip能够解决跨网段的路由问题。
BGP边界网关协议(Border Gateway Protocol, BGP)是互联网上一个核心的去中心化自治路由协议。通俗的讲就是讲接入到机房的多条线路(如电信、联通、移动等)融合为一体,实现多线单IP不用封包解包,通过bgp协议可实现pod网络在主机间的三层可达, k8s节点不跨网段时和flannel的host-gw相似,支持跨网段,跨网段时,需要主机网关路由也充当BGP Speaker能够学习到pod子网路由并实现pod子网路由的转发。总之bgp适用于大规模网络场景。

4)IPIP模式说明

默认网络模式即IPIP模式,在所有节点上查看网卡,会有tunl0网卡。

5)BGP模式说明

将IPIP模式改为BGP

更改calico-node配置

kubectl edit ds calico-node -n kube-system #会进入vim编辑模式

搜索下面两行

​ - name: CALICO_IPV4POOL_IPIP

​ value: Always

在它的下面增加:

​ - name: CALICO_AUTODETECTION_METHOD

​ value: interface=eth0

保存即可生效

更改ippool,保存即可生效

kubectl edit ippool #会进入vim编辑模式

搜索ipipMode

将ipipMode: Always 改为 ipipMode: Never

查看ip,会发现三台机器的tunl0都没有IP地址了

ip add

再查看route,使用BGP模式不再显示tunl0

ip route

同样还是ng-deploy的两个Pod,对比之前Pod的IP已经发生了变化,因为我重启过机器,但IP段依然是68和206

如果使用BGP模式,68.188访问206.193时,它的路由是10.18.206.192/26 via 192.168.222.102 dev ens33 proto bird

但此时并不需要借助tunl0了,而是直接通过ens33来。

在这里插入图片描述

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐