本文主要介绍在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:
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:
是不是你们Pod直接挂在虚拟机网卡上,Node之间是VLAN通信是不是二层互通?
A:这种设计应该也可以,但是动态扩展和容器网络管理完全依赖于虚拟机网络。我们没有直接使用虚拟机网卡,只是通过Bridge把容器网卡和虚拟机网卡连接起来,需要借助虚拟机网卡通信。
Q:
HC Bridge和SDN结合紧密吗?
A:谈不上紧密结合,HC Bridge可以利用SDN的管理能力,这样HC Bridge本身不用做太多的网络管理。目前更多的是直接与传统网络对接。
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的。
基于Kubernetes的DevOps实战培训
基于Kubernetes的DevOps实战培训将于2019年10月11日在上海开课,3天时间带你系统掌握Kubernetes,学习效果不好可以继续学习。本次培训包括:容器特性、镜像、网络;Kubernetes架构、核心组件、基本功能;Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则;Kubernetes的数据库、运行时、网络、插件已经落地经验;微服务架构、组件、监控方案等,点击下方图片或者阅读原文链接查看详情。