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来访问。
1.jpg

2.jpg

容器网络的常见需求

3.jpg

  • 内部服务之间通过Kubernetes Service Name进行访问。
  • 服务能够保留Kubernetes中原生Service的负载均衡、故障隔离、扩展的特性。
  • Pod网络能够直被外部应用访问
    4.jpg
  • 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模式
5.jpg

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模式
6.jpg

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规模的动态扩展和精细化管理。
7.jpg

HC Bridge VLAN功能

HC Bridge组件功能
8.jpg

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,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册