DockOne微信分享（二二 八）：HC Bridge容器网络模式分享

【编者的话】本文主要介绍在Kubernetes 环境下，有哪些场景需要使用Linux Bridge来满足应用对容器网络的需求。重点讲解HC Bridge容器网络插件与Kubernetes原生的Bridge CNI相比，有哪些改进，最后分享HC Bridge模式的结构和各组件的功能。

概述

Kubernetes网络原则

IP-per-Pod，每个Pod都拥有一个独立IP地址，Pod内所有容器共享一个网络命名空间。

集群内所有Pod都在一个直接连通的扁平网络中，可通过IP直接访问。

所有容器之间无需NAT就可以直接互相访问；所有Node和所有容器之间无需NAT就可以直接互相访问。

容器自己看到的IP跟其他容器看到的一样。

Service Cluster IP可在集群内部访问，外部请求需要通过NodePort、Load Balance或者Ingress来访问。

容器网络的常见需求

• 内部服务之间通过Kubernetes Service Name进行访问。
• 服务能够保留Kubernetes中原生Service的负载均衡、故障隔离、扩展的特性。
• Pod网络能够直被外部应用访问
  
  
• Pod网络能够被传统防火墙识别，不能使用Overlay网络
• 对于有状态服务，例如MySQL、ES、MQ、Redis等中间件，能够固定IP地址的功能

在Kubernetes集群里，一般采用虚拟网络，不能直接与外部的网络进行直接通信。当在Pod运行的微服务注册到注册中心时，如果没有使用NodePort/ingress暴露服务，Pod提供的服务不能被外部的访问。另外，部署在容器环境的应用要访问容器外部的服务时，通常使用Nat来把Pod IP转换为物理主机Node的IP，导致无法通过Pod 的IP精细准确地配置硬件防火墙策略。

• 原生的Flannel、Weave不满足此要求，没有将容器网络分发到其他网络的能力。
• Calico、Kube-router虽然有能力解决此问题，但是对物理交换机设备要求较高，而且增加了网络管理的管理成本。基于BGP和路由的网络模式对固定IP的支持不够友好，当出现固定IP需求时，PodIP需要能够跨Node漂移，路由条目无法聚合，路由条目数量和路由学习会成为瓶颈。
• Contiv、ovn-org/OVN-Kubernetes虽然满足要求，但是如果没有统一对接SDN南向接口，没有充分地发挥出SDN的优势，而且SDN的集中控制的模式在动态扩容、快速扩展的情况下存在瓶颈。

基于以上考虑，已有社区的CNI并不能满足要求，所以我们选择基于Linux Bridge自研了HC Bridge来应对这些需求。

HC Briddge 介绍

Docker Bridge模式

Docker Bridge模式

• Node内Pod间访问：对于一个Node内的多个Pod，都连接在docker0虚拟网桥，在同一个广播域，Pod之间可以通过IP地址和Mac地址直接访问。
• 跨Node内Pod访问：如果是跨Node的Pod访问，需要借助路由来实现，最简单的是Flannel的host-gw模式。
• Pod访问集群外部网络：对于Pod访问外部网络，每个Pod中配置网关为172.1.0.1，发出去的数据包先到达docker0，然后交给Node机器的协议栈，由于目的IP是外网IP，且host机器开启了IP forward功能，于是数据包会通过eth0发送出去，由于172.1.0.1是内网IP，发出去之前会先做NAT转换。

HC Bridge模式

HC Bridge结构

与Docker Bridge不同的是，HC Bridge将Pod与物理网络连接起来。

Pod之间可以通过Mac地址互相访问，Pod直接连接在物理网络。

Node内Pod间访问：对于同一个Node之间的Pod，可以直接借助Linux Bridge br0的二层转发来通信。

跨Node内Pod访问：对于跨Node的Pod，如果Pod在同一个VLAN内，Pod通过linux bridge br0转发到物理交换机，然后物理交换机转发到另一个Pod所在Node的Linux Bridge上，Linux Bridge再根据mac地址转发到被访问的Pod。对于在同一个VLAN的Pod，在同一个广播域，通过借助ARP协议就能实现互相访问。

Pod访问外部网络： 由于Pod网络地址等同于物理主机，Pod要访问其他网段的地址，只需要在网关上配置相应的路由规则即可。

相比社区的Bridge CNI，HC Bridge有什么特点

VLAN功能

Kubernetes自带的Bridge CNI，功能比较简单，在单台Node上只允许一个VLAN。远远没有达到生产上可以使用的程度。HC Bridge相比社区的Bridge CNI有以下增强：

丰富了VLAN的功能，社区VLAN功能非常简单，一个Node的所有Pod VLAN tag都相同，HC Bridge在创建Pod网络之前，先调用IPAM来确定Pod的VLAN和IP，这样同一个Node上的Pod可以根据业务属性选择不同的VLAN。通过支持VLAN功能，便于Pod规模的动态扩展和精细化管理。

HC Bridge VLAN功能

HC Bridge组件功能

HC Bridge：实现CNI接口的二进制文件，负责创建容器网络。

hcipam：实现CNI IPAM接口的二进制文件，在调用HC Bridge创建容器网络时，先调用hcipam获取容器的IP、路由、vlan tag等信息。对于有状态服务，提供固定IP地址的功能。

HA_Listner：用来保证容器网络的高可用，检查主机veth peer网卡的状态，定时检查和恢复；当网卡出现故障时，通过内核模块来监听在高可用组网环境下的主备网卡切换的消息，做出对应的操作来恢复容器网络。

hc-bridge-controller-manager：提供网络管理的rest api，提供管理IPPool的功能；监听apiserver的事件，在故障发生之后能够对IP只有进行回收和清理。

Q&A

Q：HC Bridge支持Kubernetes的Service吗？

A：HC Bridge原生就是支持ClusterIP和Service的。安装Kubernetes是就会开启Br_netfilter的特性，基于Netfilter的ClusterIP仍然能够使用，所以ServiceName也是支持的。

Q：能讲讲HC Bridge负载均衡是怎么做的吗？

A：HC Bridge采用Linux Bridge，不同于MacVLAN/SRIOV，本身具备Kubernetes原生的ClusterIP的机制。

Q：HC Bridge对于MacVLAN有什么优劣势？

A：MacVLAN性能略高于Bridge，Pod和Node二层隔离，需要借助三层才能通信；HC Bridge能够使用VLAN使Pod和Node在二层隔离，使用HC Bridge的Pod网络流量能够经过Node的协议栈，Pod流量能在Node层面统一管理和控制，并且具备ClusterIP。

Q：多租户/VPC模式下是否可以互相之间网段冲突？

A：HC Bridge网段是否可以冲突取决于底层基础设施。

Q：HC Bridge的监控怎么做的？

A：对于平台层面的网络质量监控、TCP层的监控，kubelet自带的cAdvisor就能够监控的要求；对于更加细粒度的业务层面的监控，我们自研的基于业务链路的监控来满足要求。

Q：HC Bridge对于硬件交换机有要求么？

A：几乎没有要求，只要交换机允许一个端口能够转发多个Mac地址的流量即可，大部分交换机都能够满足要求。

Q：通常在什么情况下会选择使用HC Bridge，而不是Calico？

A：希望容器能够被集群外应用直接访问，业务能够感知PodIP，而不是通过Ingress和NodePort。例如中间件集群、Dubbo集群、Spring Cloud集群。在传统行业，网络管理员希望容器网络和物理网络一样，能够被传统的硬件设备管控。

Q：HC Bridge在OpenStack环境下的兼容性怎么样？

A：如果使用Neutron网络，底层是使用的是Linux Bridge当做网络驱动，则是可以兼容的；如果底层是OVS作为网络驱动，则默认情况下是不兼容的。

Q：HC Bridge在VMWare环境下的兼容性怎么样？

A：在VMWare的绑定环境下的分布式交换机，要求网络是混杂网络，并且要求在宿主机上开启阻止混杂模式的重复数据包。

Q：为什么要自己在弄一个etcd？

A：结构图只是示意，etcd仍然可以复用Kubernetes本身的etcd，对于大规模场景，也可以考虑使用独立的etcd。

Q：HC Bridge支持和OpenStack资源池互通吗？

A：可以的互通的，容器网络可以和物理网络、虚拟机网络在同一个层。

Q：是不是你们Pod直接挂在虚拟机网卡上，Node之间是VLAN通信是不是二层互通？

A：这种设计应该也可以，但是动态扩展和容器网络管理完全依赖于虚拟机网络。我们没有直接使用虚拟机网卡，只是通过Bridge把容器网卡和虚拟机网卡连接起来，需要借助虚拟机网卡通信。

Q：HC Bridge和SDN结合紧密吗？

A：谈不上紧密结合，HC Bridge可以利用SDN的管理能力，这样HC Bridge本身不用做太多的网络管理。目前更多的是直接与传统网络对接。

Q：默认Bridge如果拉平网络，容器网关就是路由器的地址，Service就用不了。HC Bridge是如何支持Sercice的？

A：我们Pod的网关也是路由器地址，目前我们遇到Service不能使用的场景，主要是因为没有开启br_netfilter。

Q：Contiv的VLAN模式支持Service吗，还在学习中？

A：Contiv Service应该是可以支持Service的，但是不能依赖于Netfilter来实现。

Q：既然同一个二层，为何不用flannel hostgateway模式？集群规模可扩展性也较差吧？

A：flannel host-gw模式，跨Node的Pod通信时基于路由的，是三层；Flannel是基于路由的方案，需要借助BGP才能实现与其他网络的互通，对交换机有一定的要求；对于规模而言，HC Bridge的规模主要受限于VLAN数量和IP地址余量；对于扩展性而言，HC Bridge能够给Pod网络动态增加VLAN 和IPPool，能够保证扩展性。

Q：HC Bridge方式有什么缺点？下一步发展方向是什么？

A：二层网络在虚拟机平台，都需要在虚拟机平台的网络开启混杂模式，这一点是比较消耗性能的；目前主要是继续关注双栈的支持、容器网络流量监控和流量管理方面的事情。

Q：IP是如何分配的？追问：IPAM部署在哪里呢？IP地址段配置数据存在etcd里面是吗。

A：HC Bridge提供IPAM管理的功能，可以根据IP地址CIDR、VLAN等创建IPPool；然后可以根据业务、根据分区划分IP地址。HC Bridge的CNI和IPAM都会以DaemonSet形式分发到每个Node中。IP地址的相关信息肯定是存在etcd的。

以上内容根据2019年9月24日晚微信群分享内容整理。 分享人 刘泽宇，杭州谐云科技有限公司容器网络架构师，负责公司容器云网络整体架构 。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiese，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。