前言

G行全栈云容器大规模运转在信创主机的虚构机里，发现如跨NUMA访问CPU或许造成性能不平衡、容器网络和IaaSSDN耦合、虚构层自身资源消耗等诸多疑问。为处置这些疑问，G行探求将容器运转在裸金属主机上，推出裸金属容器平台打算，经常使用纯三层网络设计，其中物品向网络流量经常使用开源Calico容器组件，南北向网络流量经常使用自研ELB。本文关键引见CalicoBGP关系技术原理、通常和思索。

BGP引见

BGP（BorderGatewayProtocol，边界网关协定）为取代外部网关协定（EGP）协定而创立，属于经典网络路由协定。BGP关系的开源名目有bird、goBGP等，开源软件运转在云平台的宿主主机上，使主机与网络设施替换路由消息，成功云上网络和云下网络的通讯。

关键概念：

图一网络架构

在典型Spine-Leaf架构下，Spine与Leaf之间运转EBGP协定，Leaf与裸金属主机之间运转IBGP协定。

Calico网络

Calico是基于CNI成功的纯三层网络开源名目，首个版本在2015年颁布，截止以后版本为Calico3.26.1。该名目已被业界宽泛接受，并领有许多大规模的实践案例。

图二Calico架构示用意

1.Calico关键组件

Felix担任治理容器网络，性能容器IP地址、路由、iptables、安保战略等性能。在每个Worker节点运转代理程序，担任与容器治理平面通讯，失掉并性能网络和安保战略。

监控Calico关系数据（BGP性能、IPAM性能等），灵活生成Bird性能文件，并使Brid从新加载性能文件。

颁布路由：从Felix失掉路由，并把路由散发给BGP街坊，外部流量经过该路由找到POD所在Worker节点。

路由反射(RouteReflector):收到IBGP街坊颁布的BGP路由，并反射路由给其余IBGP街坊。

路由过滤:物理网络设施的一切路由表项会同步到本机，性能路由过滤，可以少量缩小本机的路由条目。

Flex经过Tyhpa间接跟Etcd交互，不再经过容器治理平面，在百节点以上的规模，能够有效降落对容器治理平面的访问压力。

2.Calico组网形式

Calico自动网络架构，IPIP可了解为IPinIP，属于overlay的网络架构。不依赖于外部替换机设施，即可成功网络组网。缺陷是报文的封装和解封装对网络效率有影响，节点规模有限度。

Calico最佳通常介绍该形式，计算节点与网络设施树立BGP街坊，并对外宣告POD的路由消息，网络设施学习到路由消息后，外部用户就可经过路由间接访问POD的地址，时期不触及到报文的封装，网络效率十分高。在正当的网络架构设计下，节点规模灵敏裁减且不影响网络效率。缺陷是普通配件网络设施和云平台的计算节点是由不同团队治理，遇到网络缺点时需联结处置。

3.IPAM地址治理?

?Calico经过IPPool启动IPAM治理，IPPool定义了地址池名字、地址段、blockSize等字段。IPPool的性能样例如下：

apiVersion：crd.projectcalico.org/v1kind:IPPoolmetadata:name:ippool-test-0spec:blockSize:32cidr:1.1.1.0/24ipipMode:NevernatOutgoing:falsenodeSelector:!all()vxlanMode:Never

nodeSelector:该字段与Kubees节点的Label启动映射。默以为all(),表示一切节点均可经常使用。设置为!all()，表示一切node均无法智能经常使用，可经过设置命名空间或许POD的注解，成功IPPool的绑定。

block/blockSzie:block关键性能是路由聚合，缩小对外宣告路由条目。block在POD所在节点智能创立，如在worker01节点创立1.1.1.1的POD时，blocksize为29，则该节点智能创立1.1.1.0/29的block，对外宣告1.1.1.0/29的BGP路由，并且节点下发1.1.1.0/29的黑洞路由和1.1.1.1/32的明细路由。在IBGP形式下，黑洞路由可防止环路。假设blockSize设置为32，则不下发黑洞路由也不会形成环路，缺陷是路由没有聚合，路由表项会比拟多，须要思索替换机路由器的容量。

Calico创立block时，会出现借用IP的状况。如在worker01节点存在1.1.1.0/29的block，因为worker01节点负载很高，地址为1.1.1.2的POD被调度到worker02节点，这种现象为IP借用。woker02节点会对外宣告1.1.1.2/32的明细路由，在IBGP形式下，替换机须要开启RR形式，将路由反射给worker01上，否则在不同worker节点的同一个block的POD，因为黑洞路由的存在，造成POD之间网络不通。可经过ipamconfigs来治理能否准许借用IP(strictAffinity)、每个节点上最多准许创立block的数量(maxBlocksPerHost)等。

4BGP形式下路由剖析

举例说明，创立1.1.1.0/31的地址池，IPPool性能如下：

root@master1:~#calicoctlgetippoolippool-test-0NAMECIDRSELECTORippool-test-01.1.1.0/31all()

经常使用该地址池，创立一个名字为nettool的POD，创立成功后，检查workloadendpoint资源消息。可检查失掉，POD的IP地址为1.1.1.1/32，其网络接口对应在worker01节点的网卡为cali200f7a51a47。

root@master1:~#calicoctlgetworkloadendpointNAMESPACEWORKLOADNODENETWORKSINTERFACEdefaultnettoolworker011.1.1.1/32cali200f7a51a47

进入该容器，检查路由和接口消息。可检查失掉，容器自动路由为169.254.1.1，且均指向eth0。经过ethtool检查失掉，eth0接口的peer_ifindex为532。

root@master1:~#kubectlexec-itnettoolshkubectlexec[POD][COMMAND]isDEPRECATEDandwillberemovedinafutureversion.Usekubectlexec[POD]--[COMMAND]instead.sh-4.4#ipa1:lo:<LOOPBACK,UP,LOWER_UP>mtu65536qdiscnoqueuestateUNKNOWNgroupdefaultqlen1000link/loopback00:00:00:00:00:00brd00:00:00:00:00:00inet127.0.0.1/8scopehostlovalid_lftforeverpreferred_lftforever2:tunl0@NONE:<NOARP>mtu1480qdiscnoopstateDOWNgroupdefaultqlen1000link/ipip0.0.0.0brd0.0.0.04:eth0@if532:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1480qdiscnoqueuestateUPgroupdefaultlink/ether86:61:23:4e:4e:d0brdff:ff:ff:ff:ff:fflink-netnsid0inet1.1.1.1/32scopeglobaleth0valid_lftforeverpreferred_lftforeversh-4.4#iproutedefaultvia169.254.1.1deveth0169.254.1.1deveth0scopelinksh-4.4#ethtool-Seth0NICstatistics:peer_ifindex:532rx_queue_0_xdp_packets:0rx_queue_0_xdp_bytes:0rx_queue_0_xdp_drops:0

登录worker01节点，检查index为532的网卡接口，正是该接口cali200f7a51a47。worker01节点曾经性能了ARP代理(主机上网卡不论ARP恳求的内容，间接将自己的地址作为应对的行为称为ARPProxy)。Calico把worker01节点当做容器的自动网关经常使用，一切报文会发送到节点上，节点再依据路由消息启动转发。

root@worker01:~#ipa|grep532532:cali200f7a51a47@if4:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1480qdiscnoqueuestateUPgroupdefaultroot@worker01:~#cat/proc/sys/net/ipv4/conf/cali200f7a51a47/proxy_arp1

针对回程报文，咱们检查节点的1.1.1.1对应路由，也正是该接口cali200f7a51a47。此时worker01节点的收发报文通路曾经明了。

root@worker01:~#route-n|grepcali200f7a51a471.1.1.10.0.0.0255.255.255.255UH000cali200f7a51a47

最后，确认下替换机的路由状况。目的地址为1.1.1.1的下一跳为192.168.1.4，该IP地址是worker01主机IP。此时POD就可以跟外部启动通讯。

Destination/MaskProtoPreCostFlagsNextHopInterface1.1.1.1/32IBGP2550RD192.168.1.4vlanif100<switch>

全栈云探求通常

综合思索微隔离、网路可观测等技术储藏已在G行推行经常使用，Calico自动不开启网络安保战略，依托微隔离做网络安保存控。关键思索BGP和IPAM上设计和治理网络。

1.BGP性能

1)创立BGPconfigurations性能文件，申明节点的自动AS号。

root@master1:~#catbgpconfigurations.yamlapiVersion:crd.projectcalico.org/v1kind:BGPConfigurationmetadata:name:defaultspec:asNumber:1111111logSeverityScreen:InfonodeToNodeMeshEnabled:false

2)创立BGPPeer，明白替换机的AS号、BGPPeerIP，并将含有rr-group=rr1的节点与替换机树立街坊。

root@master:~#catbgppper1.yamlapiVersion:crd.projectcalico.org/v1kind:BGPPeermetadata:name:bgp-peer-1spec:asNumber:1111111nodeSelector:rr-group=='rr1'peerIP:192.168.1.1

3)Kubernetes的节点打rr-group=rr1的标签

root@master1:~#kubectlgetnode--show-labels|greprr1|grepworker01worker01Readyworker21dv1.23.15beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker01,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,rr-group=rr1

4)替换机性能

5)裸金属Kubernetes节点检查BGP形态，Established象征着BGP街坊曾经树立。

root@worker01:~#calicoctlnodestatusCalicoprocessisrunning.IPv4BGPstatus+--------------+---------------+-------+------------+-------------+|PEERADDRESS|PEERTYPE|STATE|SINCE|INFO|+--------------+---------------+-------+------------+-------------+|192.168.1.1|nodespecific|up|2023-08-17|Established||192.168.1.2|nodespecific|up|2023-08-17|Established|+--------------+---------------+-------+------------+-------------+IPv6BGPstatusNoIPv6peersfound.

2.IPAM性能关系消息

G行云平台底座和业务的IP离开治理，业务自行选择POD的亲和或反亲和，业务部署在自己的命名空间，不会出现多种业务在同一个命名空间部署的状况。

在超越20个节点的容器平台，运行POD会频繁出现IP地址借用状况，block的路由聚合效率大幅度降落。综合思索替换机性能和容量，地址池的blockSize设置为32，替换机不开启RR个性。

为确保IP不会被其余业务经常使用，设定一切地址池的nodeSelector为!all()。

root@master1:~#calicoctlgetippoolNAMECIDRSELECTORippool-test-01.1.1.0/24!all()ippool-test-11.1.2.0/24!all()ippool-test-21.1.3.0/24!all()ippool-test-31.1.4.0/24!all()

在namespace中设定对应annotation。

apiVersion:v1kind:Namespacemetadata:annotations:cni.projectcalico.org/ipv4pools:'["ippool-test-0"]'name:test

3.Calico关系监控

Calico监控体系从三个方面启动笼罩。

图三Calico监控体系

CalicoBGP形式关系思索

树立方面：CalicoBGP树立须要多团队的配合。治理物理网络设施的团队，需全局布局网络设施的BGP消息、AS号和静态路由等，技术上防止单台替换机宕机惹起路由的震荡（如一对Leaf替换机领有不同AS号，会形成路由震荡）；治理云平台的团队，须要正当性能iBGP和IPPool，防止颁布合法路由，影响其余网络设施。

运维方面：变卦治理/缺点治理需云和网配合启动，明白双方分工和疑问界定，严密单干。比如治理云平台的团队性能BGPFilter性能，物理网络设施性能BGPPolicy，防止对外颁布合法路由，构成双保险。在技术探求环节中，引入可观测平台全链路流量和BGP监控等工具，最大水平将疑问边界形容明晰，并提高运维效率。

后续细化CalicoBGP监控目的，探求CalicoeBPF数据面的成功，弱化iptables对网络的影响。

一文读懂underlay

一文解析Underlay网络模式：解锁高效、平滑的容器通信

在技术交流中，二哥以直观的图像为利器，他坚信“一张图胜过千言万语”。当我们探讨复杂的容器网络模式时，Underlay模式就像一座桥梁，连接宿主机与容器，提供了无损耗的通信体验。让我们一起深入理解这三种网络架构：Overlay、主机间路由，以及Underlay，看看它们如何影响性能和部署灵活性。

1. Overlay模式：便捷中的微妙妥协

Flannel的VXLAN和Calico的IPIP是Overlay模式的代表，它们便于实现，但性能可能会受到解封装和网络栈穿越的影响，大约有20%-30%的性能损耗。这种模式就像一个轻量级的“借道”，适合对性能要求不那么严格的应用场景。

2. 主机间路由模式：性能之选，但受限于环境

Flannel的host-gw和Calico的BGP路由模式，提供了高效率的通信，但需要BGP协议支持，且在云托管服务中可能存在使用限制。这就像一个直达的高速公路，但需要特定的交通规则，对于云环境中的大规模部署来说，可能不是最佳选择。

3. Underlay模式：共享网络，性能无损

Underlay模式将容器与宿主机的网络共享，避免了性能损耗，如阿里云和GKE等平台就是采用这种方式。它类似于“借道于基础设施”，实现了平等无损耗的通信，使得Pod成为网络中的真正一等公民。

图5：Underlay模式下的Pod通信路径，显示了Pod流量如何直接通过Open vSwitch，与root namespace保持同步，从而实现性能优势。

Linux容器的网络隔离通过Network namespace实现，Pod的流量可能根据网络实现的不同，选择使用root namespace资源。在Underlay模式下，multi-NIC热插拔技术使得Pod可以独立于root namespace，避免了iptables和路由设置的干扰，性能损耗更低。

总结来说，Underlay模式以其卓越的性能和与VM平等的地位，为容器网络世界带来了新的可能。然而，它的优势在于硬件支持，部署灵活性可能略逊于Overlay。随着SDN和VPC等技术的发展，Underlay模式的潜力正在被更多人关注。如果你对这一领域感兴趣，持续关注我们的公众号，让我们共同探索Underlay的更多奥秘。

Docker swarm中的LB和服务发现详解

Docker 提供了 overlay driver，使用户可以创建基于 VxLAN 的 overlay 网络。VxLAN 可将二层数据封装到 UDP 进行传输，VxLAN 提供与 VLAN 相同的以太网二层服务，但是拥有更强的扩展性和灵活性。linux下是使用了net namespace来隔离docker创建的overlay网络。

Docker 网络模型如下：

一个Sandbox包含了一个容器网络栈的配置。其中包括了对容器的网卡，路由表以及对DNS设置的管理。通常，一个Sandbox的实现可以是一个Linux Network Namespace，一个FreeBSD Jail或者其他类似的东西。一个Sandbox可以包含多个处于不同Network的Endpoint。

Endpoint将一个Sandbox加入一个Network。Endpoint的实现可以是一个veth对，一个Open vSwitch internal port或者其他类似的东西。一个Endpoint只能属于一个Network和一个Sandbox。

Network是一个能够互相通信的Endpoint的集合。Network的实现可以是一个Linux网桥，一个VLAN等等。

上图展示了请求两个不同资源dns返回的不同结果

环境： swarm-a(manager node)：10.10.8.92

swarm-b(work node)：10.10.8.93

swarm-c(work node)：10.10.8.94

在docker swarm集群创建的开始，docker 会给每台host创建除了docker0以外的两个网络，分是bridge类型(docker_gwbridge网桥)和overlay类型(ingress)的网络，以及一个过度的命名空间ingress_sbox，我们可以使用如下命令自建overlay网络，结果如下： docker network create --driver overlay mynet （后续会有用到）

注意1：要是想看到容器创建的两个Net Namespace需要执行 ln -s /var/run/docker/netns /var/run/netns

1)、部署一个service使用默认的ingress网络：

docker service create --name web_ingress_lb --replicas=2 --publish 8090:80 httpd

2)、Ingress Load Balancing实现方式：

这样一来即使容器的副本没有落到host上我们仍可以通过这种转发方式来访问到服务。这应该就是routing mesh吧！

1)、部署一个service使用我们自己创建的mynet网络：

docker service create --name web_mynet --replicas=2 --network=mynet --publish 8080:80 httpd 部署的两个容器分别处在a和c节点上：

结合例子如下：

2)、查看web_mynet.1容器和mynet网络命名空间的网卡情况：

3)、查看web_mynet.1容器和ingress\ingress_sbox网络命名空间的网卡对应情况：

可以看mynet网络下vlan-id 为4097，ingress网络空间同样操作可以得到vlan-id为4096

swarm-c节点上的情况也是差不多就不操作了，好了我们来画下网络连接的大致图：

可以看到这里ingress_sbox和创建容器的ns共用一个ingress网络空间。

4)、 Internal Load Balancing实现方式：

有两种实现方式dns rr和vip形式，在dns rr 的情况下可能会存在一定是的问题，当容器重启后dns的解析会存在一定时间的延迟。vip则是由vip+内核ipvs来实现。docker swarm默认使用的是vip，这里就以vip的形式来解析。（想要了解dns rr的可以看文章后面的参考链接都是大牛写的）

VIP形式下的流量路径：

操作流程如下： 通过busybox服务做dns解析，可以发现该服务后端挂载的容器和该服务对应的 VIP地址。web_mynet服务对应的VIP为10.0.0.6。

在Internal Load Balancing也就是文中我们自建的mynet overlay网络中，我们会看到创 建的service会同时应用到两个网络环境里面去，为何要这样呢？

原因是swarm自带ingress不具备有服务发现的功能，而容器的生命周期又是不固定的， service每次的消亡和启用都会改变容器内部的ip地址以及vip地址，那么集群中服务之间 的通信势必会造成问题，这里有人会说，要使多个service之间能够互相通信可以将所有 的service都publish出去，然后通过routing mesh 访问，这样是没错也能行得通，但是存 在一个缺点，那就是不安全，我们仅仅只需要的是将最终提供服务的端口publish即可。 那么不publish所有的service需要做到以下几点：

这里我理解的是ingress是单单提供LB实现routing mesh而mynet是服务发现和LB的结合

所以上文中Internal Load Balancing中的数据流应该分成两种情景如下：

1、当一个外部请求到主机端口8080之后， 数据包的流向如下所示： 主机端口8080 => Ingress-sbox-VIP:8080 => 容器Ingress-sbox => IPVS分发到containers。

2、处于 同mynet网络的service内部通信时： 处于 同mynet网络的test service(busybox容器)发起访问web_mynet域名的请求=>请求转发到docker engine内置的DNS解析web_mynet的vip=>web_mynet(容器)在其ns中将 VIP数据包打上标签，并通过ipvs来负载到后端对应的容器=>数据包通过vip地址路由到 mynet的ns，由mynet中的fdb来做转发走tunnel出去。