当前位置:首页 > 数码 > 深化探求容器间路由和服务发现-BGP-容器网络通常-Calico (深化探求容器的方法)

深化探求容器间路由和服务发现-BGP-容器网络通常-Calico (深化探求容器的方法)

admin5个月前 (05-12)数码16

前言

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出去。

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: 容器

“深化探求容器间路由和服务发现-BGP-容器网络通常-Calico (深化探求容器的方法)” 的相关文章

容器资源自愈-深入了解其益处和最佳实践 (容器资源限制)

容器资源自愈-深入了解其益处和最佳实践 (容器资源限制)

前言 容器作为一种新的资源类型,已经应用于各大公司,G行也不例外。容器的轻量化特性使得它能够在故障发生时快速进行重建,将对业务的影响降到最低,我们通常称它为自愈。 容器自愈本质 谈到容器自...

Go-调度器-理解-深入剖析云原生基础架构-容器以及Linux (调度器模式)

Go-调度器-理解-深入剖析云原生基础架构-容器以及Linux (调度器模式)

在容器中部署的 Go 应用程序通常需要设置 CPU 限制,以确保容器不会耗尽主机上的所有 CPU。但是,由于 Go 运行时不知道在容器上设置的 CPU 限制,因此它可能会使用所有可用的 CPU,从...

Docker的替代品-Containerd容器管理 (docker logs)

Docker的替代品-Containerd容器管理 (docker logs)

Introduction CRI-O is a container runtime engine developed by Red Hat. It is a lightweight altern...

不要把容器当做宇宙的中心!-Docker成立十周年-1号员工反思

不要把容器当做宇宙的中心!-Docker成立十周年-1号员工反思

作者丨Sam Alba 编译丨诺亚 本文作者 Sam Alba 目前是 Dagger 的联合创始人兼工程副总裁,也是前 Docker 的工程副总裁。他于 2010 年作为第一位员工加入...

几款热门容器化编排工具对比

几款热门容器化编排工具对比

什么是容器管理? 容器管理是一系列涉及部署、运行、监控和维护容器化应用程序的操作,以有效管理这些应用程序。 容器编排工具 Kubernetes Docker...

Kubernetes-容器编排的行业标准 (kubernetes与docker的关系)

Kubernetes-容器编排的行业标准 (kubernetes与docker的关系)

Kubernetes(简称K8s)是一个开源的容器编排平台,它能够自动化管理容器的部署、扩展、维护和升级。本文将深入探讨 Kubernetes 的概念、特点、应用场景以及未来发展趋势。 1....

容器资源分配策略-兼顾稳定性和成本效益 (容器资源管理)

容器资源分配策略-兼顾稳定性和成本效益 (容器资源管理)

弹性云分级保障体系:确保容器服务稳定性 前言 随着假期出行的兴起和需求的增加,弹性云服务面临着巨大的稳定性保障压力。本文将介绍弹性云分级保障体系,旨在通过提供明确的容器资源保障等级,确保不同优先级...