G行全栈云容器大规模运行在信创服务器的虚拟机里,发现如跨NUMA访问CPU可能导致性能不均衡、容器网络和IaaS SDN耦合、虚拟层本身资源消耗等诸多问题。为解决这些问题,G行探索将容器运行在裸金属服务器上,推出裸金属容器平台方案,使用纯三层网络设计,其中东西向网络流量使用开源Calico容器组件,南北向网络流量使用自研ELB。本文主要介绍Calico BGP相关技术原理、实践和思考。
BGP(Border Gateway Protocol,边界网关协议)为取代外部网关协议(EGP)协议而创建,属于经典网络路由协议。BGP相关的开源项目有bird、goBGP 等,开源软件运行在云平台的宿主主机上,使主机与网络设备交换路由信息,实现云上网络和云下网络的通信。
关键概念:
图一 网络架构
在典型Spine-Leaf架构下,Spine与Leaf之间运行EBGP协议,Leaf与裸金属服务器之间运行IBGP协议。
Calico是基于CNI实现的纯三层网络开源项目,首个版本在2015年发布,截止当前版本为Calico 3.26.1。该项目已被业界广泛接受,并拥有许多大规模的实际案例。
图二 Calico架构示意图
Felix负责管理容器网络,配置容器IP地址、路由、iptables、安全策略等功能。在每个Worker节点运行代理程序,负责与容器管理平面通信,获取并配置网络和安全策略。
监控Calico相关数据(BGP配置、IPAM配置等),动态生成Bird配置文件,并使Brid重新加载配置文件。
发布路由:从Felix获取路由,并把路由分发给BGP邻居,外部流量通过该路由找到POD所在Worker节点。
路由反射 (Route Reflector): 收到IBGP邻居发布的BGP路由,并反射路由给其他IBGP邻居。
路由过滤:物理网络设备的所有路由表项会同步到本机,配置路由过滤,可以大量减少本机的路由条目。
Flex通过Tyhpa直接跟Etcd交互,不再经过容器管理平面,在百节点以上的规模,能够有效降低对容器管理平面的访问压力。
Calico默认网络架构,IPIP可理解为IPinIP,属于overlay的网络架构。不依赖于外部交换机设备,即可实现网络组网。缺点是报文的封装和解封装对网络效率有影响,节点规模有限制。
Calico最佳实践推荐该模式,计算节点与网络设备建立BGP邻居,并对外宣告POD的路由信息,网络设备学习到路由信息后,外部用户就可通过路由直接访问POD的地址,期间不涉及到报文的封装,网络效率非常高。在合理的网络架构设计下,节点规模灵活扩展且不影响网络效率。缺点是一般硬件网络设备和云平台的计算节点是由不同团队管理,遇到网络故障时需联合处置。
?Calico通过IPPool进行IPAM管理,IPPool定义了地址池名字、地址段、blockSize等字段。IPPool的配置样例如下:
apiVersion:crd.projectcalico.org/v1
kind: IPPool
metadata:
name: ippool-test-0
spec:
blockSize: 32
cidr: 1.1.1.0/24
ipipMode: Never
natOutgoing: false
nodeSelector: “!all()”
vxlanMode: Never
nodeSelector: 该字段与Kube.NETes节点的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)等。
举例说明,创建1.1.1.0/31的地址池,IPPool配置如下:
root@master1:~# calicoctl get ippool ippool-test-0
NAME CIDR SELECTOR
ippool-test-0 1.1.1.0/31 all()
使用该地址池,创建一个名字为nettool的POD,创建完成后,查看workloadendpoint资源信息。可查看得到,POD的IP地址为1.1.1.1/32,其网络接口对应在worker01节点的网卡为cali200f7a51a47。
root@master1:~# calicoctl get workloadendpoint
NAMESPACE WORKLOAD NODE NETWORKS INTERFACE
default nettool worker01 1.1.1.1/32 cali200f7a51a47
进入该容器,查看路由和接口信息。可查看得到,容器默认路由为169.254.1.1,且均指向eth0。通过ethtool查看得到,eth0接口的peer_ifindex为532。
root@master1:~# kubectl exec -it nettool sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
sh-4.4# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if532: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
link/ether 86:61:23:4e:4e:d0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 1.1.1.1/32 scope global eth0
valid_lft forever preferred_lft forever
sh-4.4# ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
sh-4.4# ethtool -S eth0
NIC statistics:
peer_ifindex: 532
rx_queue_0_xdp_packets: 0
rx_queue_0_xdp_bytes: 0
rx_queue_0_xdp_drops: 0
登录worker01节点,查看index为532的网卡接口,正是该接口cali200f7a51a47。worker01节点已经配置了ARP代理(主机上网卡不管ARP请求的内容,直接将自己的mac地址作为应答的行为称为ARP Proxy)。Calico把worker01节点当做容器的默认网关使用,所有报文会发送到节点上,节点再根据路由信息进行转发。
root@worker01:~# ip a |grep 532
532: cali200f7a51a47@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
root@worker01:~# cat /proc/sys/net/ipv4/conf/cali200f7a51a47/proxy_arp
1
针对回程报文,我们查看节点的1.1.1.1对应路由,也正是该接口cali200f7a51a47。此时worker01节点的收发报文通路已经明了。
root@worker01:~# route -n |grep cali200f7a51a47
1.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 cali200f7a51a47
最后,确认下交换机的路由情况。目的地址为1.1.1.1的下一跳为192.168.1.4,该IP地址是worker01主机IP。此时POD就可以跟外部进行通信。
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.1/32 IBGP 255 0 RD 192.168.1.4 vlanif100
<switch>
综合考虑微隔离、网路可观测等技术储备已在G行推广使用,Calico默认不开启网络安全策略,依靠微隔离做网络安全管控。主要考虑BGP和IPAM上设计和管理网络。
1) 创建BGPconfigurations配置文件,声明节点的默认AS号。
root@master1:~# cat bgpconfigurations.yaml
apiVersion: crd.projectcalico.org/v1
kind: BGPConfiguration
metadata:
name: default
spec:
asNumber: 1111111
logSeverityScreen: Info
nodeToNodeMeshEnabled: false
2) 创建BGPPeer,明确交换机的AS号、BGP Peer IP,并将含有rr-group=rr1 的节点与交换机建立邻居。
root@master:~# cat bgppper1.yaml
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
name: bgp-peer-1
spec:
asNumber: 1111111
nodeSelector: rr-group == 'rr1'
peerIP: 192.168.1.1
3) Kubernetes的节点打rr-group=rr1的标签
root@master1:~# kubectl get node --show-labels |grep rr1 |grep worker01
worker01 Ready worker 21d v1.23.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,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:~# calicoctl node status
Calico process is running.
IPv4 BGP status
+--------------+---------------+-------+------------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+--------------+---------------+-------+------------+-------------+
| 192.168.1.1 | node specific | up | 2023-08-17 | Established |
| 192.168.1.2 | node specific | up | 2023-08-17 | Established |
+--------------+---------------+-------+------------+-------------+
IPv6 BGP status
No IPv6 peers found.
G行云平台底座和业务的IP分开管理,业务自行决定POD的亲和或反亲和,业务部署在自己的命名空间,不会出现多种业务在同一个命名空间部署的情况。
在超过20个节点的容器平台,应用POD会频繁发生IP地址借用情况,block的路由聚合效率大幅度降低。综合考虑交换机性能和容量,地址池的blockSize设置为32,交换机不开启RR特性。
为确保IP不会被其他业务使用,设定所有地址池的nodeSelector为!all()。
root@master1:~# calicoctl get ippool
NAME CIDR SELECTOR
ippool-test-0 1.1.1.0/24 !all()
ippool-test-1 1.1.2.0/24 !all()
ippool-test-2 1.1.3.0/24 !all()
ippool-test-3 1.1.4.0/24 !all()
在namespace中设定对应annotation。
apiVersion: v1
kind: Namespace
metadata:
annotations:
cni.projectcalico.org/ipv4pools: '["ippool-test-0"]'
name: test
Calico监控体系从三个方面进行覆盖。
图三 Calico监控体系
建设方面:Calico BGP建设需要多团队的配合。管理物理网络设备的团队,需全局规划网络设备的BGP信息、AS号和静态路由等,技术上避免单台交换机宕机引起路由的震荡(如一对Leaf交换机拥有不同AS号,会造成路由震荡);管理云平台的团队,需要合理配置iBGP和IPPool,避免发布非法路由,影响其他网络设备。
运维方面:变更管理/故障管理需云和网配合进行,明确双方分工和问题界定,紧密协作。比如管理云平台的团队配置BGP Filter功能,物理网络设备配置BGP Policy,防止对外发布非法路由,形成双保险。在技术探索过程中,引入可观测平台全链路流量和BGP监控等工具,最大程度将问题边界描述清晰,并提高运维效率。
后续细化Calico BGP监控指标,探索Calico eBPF数据面的实现,弱化iptables对网络的影响。