在前面的几篇文章里我们介绍了基于flannel的underlay网络和overlay网络,包括host-gw模式的underlay网络,基于vxlan的overlay网络,基于udp的overlay网络。这里我们做一下回顾总结和对比,相关文章可以参考如下:
通过第一章容器网络基础的学习,我们已经实现了单机容器间的互通、容器访问外部网络及容器对外提供服务。 在实际的应用场景中,为了保证业务的高可用性,我们的容器多是跨宿主机部署的,并且部署在不同宿主机上的容器会进行大量的网络通信。那么,怎么实现容器的跨宿主机通信呢?
VXLAN是为了在现有的三层网络之上,覆盖一层虚拟的由内核VXLAN模块负责维护的二层网络,使得连接在VXLAN之上的主机可以像在一个局域网里那样实现自由通信。
上篇文章结尾提到 Linux 是支持 VXLAN 的,我们可以使用 Linux 搭建基于 VXLAN 的 overlay 网络,以此来加深对 VXLAN 的理解,毕竟光说不练假把式。
坚持看下去,文末送机械键盘一个 本文中,笔者主要结合自己使用flannel心得,以及flannel的技术演进,介绍下flannel网络实现方案。在没有介绍flannel overlay网络实现方案之前,先回顾下docker网络实现方案。
1. NSH-SFC概述 当前SFC的实现方案主要分为两种:一种基于NSH(network service header)。数据封装时,在L2或者L3数据后添加NSH头,然后进行L3或L4的封装。转发时,根据nshheader去转发SFC中的数据,整个过程都是依据同一个SPI(service path id)和递减的SI(service index);另一种无NSH头,在转发过程中,SFF需要不停对新来的数据包进行判断,确定是否属于某个SFC。ODL的子项目SFC就是第一种的实现。 1.1 NSH-SFC组
Kubernetes中解决网络跨主机通信的一个经典插件就是Flannel。Flannel实质上只是一个框架,真正为我们提供网络功能的是后端的Flannel实现,目前Flannel后端实现的方式有三种:
接前面这个写起,比较过linux kernel vxlan device和ovs vxlan的性能,很好奇ovs vxlan是怎么实现的,linux kernel vxlan device是用如下命令创建的。
底层网络 Underlay Network 顾名思义是指网络设备基础设施,如交换机,路由器, DWDM 使用网络介质将其链接成的物理网络拓扑,负责网络之间的数据包传输。
在上期,我们介绍了CNI所需要实现的命令字和接口。常见的开源CNI实现有flannel和calico。
曾记得有一位哲人说过:“在云计算当中,计算最基础,存储最重要,网络最复杂”,而PaaS云平台Kubernetes的出现也使得网络的应用场景变得更加复杂多变。本文试图从Kubernetes当中容器跨节点网络通信方案Flannel的实际应用场景出发,带领读者梳理Kubernetes当中容器跨节点网络通信的实现过程以及背后的实现原理。
VXLAN是Virtual eXtensible Local Area Network的缩写,RFC 7348的标题“A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”,说明了VXLAN是一个在传统Layer 3网络上架设出来的Layer 2 overlay网络。RFC Abstract如下:
前面一章我们介绍了Node节点上面不同的容器之间的通讯方式,主要是根据docker0(网桥)+Veth Pair的方式来玩起来的。
你是否之前看过 k8s 的网络部分,第一次看是否会觉得很困难?或者说你有没有想过为什么 k8s 要这样设计它的网络,跨主机之间的网络通信究竟是怎么实现的?今天就来搞一篇干货,其实想写这个很久了,但是一直拖延症,这次正好碰到了一个新的点想让我仔细重新审视一下。
Docker Overlay 网络是一种用于跨主机通信的虚拟网络。它使用 VXLAN 技术将多个 Docker 主机上的容器连接到同一个网络中,使它们可以在不同的主机之间进行通信。在本文中,我们将深入探讨 Docker Overlay 网络的实现原理和底层原理。
注意: 本文中使用 ip 命令创建或修改的任何网络配置,都是未持久化的,主机重启即消失。
pip在上期,我们讲到,对于私有化部署的容器平台,传统开源的calico,flannel等基于iptables/ipvs的容器插件无法同时满足以下几点
云计算三大组成部分:计算、存储和网络。VXLAN属于云计算虚拟化网络的非常重要的一部分,现在大多数云计算虚拟化网络都是基于此协议实现数据中心互联和虚拟机迁移 ,在数量级很大的虚拟机上完成这些工作是一个非常大的挑战。主要面临以下挑战:
overlay 网络是在Underlay网络上构建的一个逻辑网络,满足数据中心构建大二层网络的要求。
在过去十几年中,虚拟化已经改变了应用、数据、服务的实现部署方式。服务器的虚拟化给数据中心网络带来了根本性的变化。在传统的数据中心网络架构基础上,出现了一个新的、位于物理服务器内的接入层。这个新的接入层包含的设备是运行在x86服务器中的vSwitch,而这些vSwitch连接着一个服务器内的多个workload(包括容器和虚机)。
在上篇文章中,我们已经探讨了 VxLAN 的概念和基本原理,本文就基于 Linux 对 VxLAN 做一个实践。如果有相关概念不懂的可以先看那篇文章。
容器的网络解决方案有很多种,每支持一种网络实现就进行一次适配显然是不现实的,而 CNI 就是为了兼容多种网络方案而发明的。CNI 是 Container Network Interface 的缩写,是一个标准的通用的接口,用于连接容器管理系统和网络插件。
在之前的两篇文章中分别介绍了pod与主机连接并且上外网的原理及service的clusterIP和nodeport的实现原理,对于组织pod的网络这件事来说,还有最后一环需要打通,就是分布在不同集群节点的pod之间如何相互通信,本章我们来解决这最后一环的问题
1 实验目的 该实验通过Open vSwitch构建Overlay的VxLAN网络,更直观的展现VxLAN的优势。在实验过程中,可以了解如何建立VxLAN隧道并进行配置,并实现相同网段和不同网段之间的通信。 2 实验原理 VxLAN 是 Virtual eXtensible LANs 的缩写,它是对 VLAN 的一个扩展,是非常新的一个 tunnel 技术,在Open vSwitch中应用也非常多。Linux 内核的 upstream 中也刚刚加入 VXLAN 的实现。相比 GRE tunnel 它有着很好
flannel有udp、vxlan和host-gw三种模式,udp模式因为性能较低现在已经比较少用到,host-gw我们在前面简单介绍过,因为使用场景比较受限,所以vxlan模式是flannel使用最多的模式,本章我们来介绍一下vxlan模式的原理。
不必太纠结于当下,也不必太忧虑未来,当你经历过一些事情的时候,眼前的风景已经和从前不一样了。——村上春树
本文作者 / yogazhao 爱自然科学,赞叹于大师级码农高超的艺术境界;爱生命科学,诚服于古圣先贤的天地气象。 可能大多数瓜农都对《艺伎回忆录》比较熟悉,作为一个IT界的码农,当然也有自己类似的经历,该文分为上篇和下篇,此篇为《OVS BUG撸码回忆录•上篇》 回忆录缘起 以前为排查ovs的某个bug,无奈撸了把相关内核流程。当时因为调用链太多,脑袋栈溢出,处理不过来,所以临时用txt比较零散的记录了下关键点,做完了就丢了。后面想起来,无奈用everything找了好久才找到, 再读之,发现忘了很
一篇文章围绕一张图,讲述一个主题。不过这个主题偏大,我估计需要好几篇文章才能说得清楚。
今天我们接着上节课介绍的 Linux 网络知识,继续来学习它们在虚拟化网络方面的应用,从而为后续学习容器编排系统、理解各个容器是如何通过虚拟化网络来协同工作打好基础。
摩尔定律被硅芯片物理极限限制->多核技术推动虚拟化大规模应用->数据中心网络大规模虚拟机入网;
在Docker 1.9 出世前,跨多主机的容器通信方案大致有如下三种: 1、端口映射 将宿主机A的端口P映射到容器C的网络空间监听的端口P’上,仅提供四层及以上应用和服务使用。这样其他主机上的容器通过访问宿主机A的端口P实 现与容器C的通信。显然这个方案的应用场景很有局限。 2、将物理网卡桥接到虚拟网桥,使得容器与宿主机配置在同一网段下 在各个宿主机上都建立一个新虚拟网桥设备br0,将各自物理网卡eth0桥接br0上,eth0的IP地址赋给br0;同时修改Docker daemon的DOCKER_OPTS
将宿主机A的端口P映射到容器C的网络空间监听的端口P’上,仅提供四层及以上应用和服务使用。这样其他主机上的容器通过访问宿主机A的端口P实 现与容器C的通信。显然这个方案的应用场景很有局限。
flannel是 coreos 开源的 Kubernetes CNI 实现。它使用 etcd 或者 Kubernetes API 存储整个集群的网络配置。每个 kubernetes节点上运行 flanneld 组件,它从 etcd 或者 Kubernetes API 获取集群的网络地址空间,并在空间内获取一个 subnet ,该节点上的容器 IP都从这个 subnet 中分配,从而保证不同节点上的 IP不会冲突。flannel通过不同的 backend 来实现跨主机的容器网络通信,目前支持 udp , vxlan , host-gw 等一系列 backend实现。
惠伟:virtio+ovs转发原理和性能分析zhuanlan.zhihu.com
数据平面开发套件(DPDK [1] ,Data Plane Development Kit)是由6WIND,Intel等多家公司开发,主要基于Linux系统运行,用于快速数据包处理的函数库与驱动集合,可以极大提高数据处理性能和吞吐量,提高数据平面应用程序的工作效率。
以前提到过vdpa,只有mellanox connectx-5网卡,不支持vdpa,公司最近来了mellanox DPU,也就是bluefield-2,自带connectx-6网卡,硬件支持vdpa,再分析一下看怎么个搞法。
在上一篇文章里我们介绍了k8s集群中flannel vxlan overlay网络的创建,这在里我们基于上一篇文章中的例子,来介绍在flannel vxlan overlay网络中pod到pod的通讯。
Cilium[1]是一种开源网络实现方案,与其他网络方案不同的是,Cilium着重强调了其在网络安全上的优势,可以透明的对Kubernetes等容器管理平台上的应用程序服务之间的网络连接进行安全防护。
上一篇文章我演示了docker bridge网络模型的实验,这次我将展示如何利用Overlay 网络实现跨主机容器的通信。
在前文[2]中我们提到, cilium install 默认安装后, Cilium 功能启用和禁用情况如下:
在Kubernetes中设计了一种网络模型,要求无论容器运行在集群中的哪个节点,所有容器都能通过一个扁平的网络平面进行通信,即在同一IP网络中。需要注意的是:在K8S集群中,IP地址分配是以Pod对象为单位,而非容器,同一Pod内的所有容器共享同一网络名称空间。
IP层叫分片,TCP/UDP层叫分段。网卡能做的事(TCP/UDP组包校验和分段,IP添加包头校验与分片)尽量往网卡做,网卡不能做的也尽量迟后分片(发送)或提前合并片(接收)来减少在网络栈中传输和处理的包数目,从而减少数据传输和上下文切换所需要的CPU计算时间。
chroot,即 change root directory (更改 root 目录)。在 linux 系统中,系统默认的目录结构都是以 `/`,即是以根 (root) 开始的。而在使用 chroot 之后,系统的目录结构将以指定的位置作为 `/` 位置。
引言 本文主要对OpenvSwitch(基于2.3.90版本)重点模块的源码实现流程做了简要的阅读记录,Open vSwitch源码阅读笔记(上)已提供,此篇是对上篇的追述及补充,适合阅读OpenvS
在以前系列文章中我们以学习为目的介绍了二进制手动安装k8s集群,这里也是一个系列文章,同样以学习为目的,我们介绍k8s集群网络。对于网络基本涉及两个方面,一是到各个服务的网络间负载均衡,另一个是网络间的通讯。
k8s网络模型设计基础原则:每个Pod都拥有一个独立的 IP地址,而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中 。 所以不管它们是否运行在同 一 个 Node (宿主机)中,都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因 是,用户不需要额外考虑如何建立 Pod 之间的连接,也不需要考虑将容器端口映射到主机端口等问题。
这个问题 flannel 和 calico 的 VXLAN 模式下都会发生,部分人的集群的A记录 UDP 下查询可能有问题。原因是 v1.17+ 的 kubernetes 某部分会引起内核的某个 UDP 相关的 BUG 而不是 CNI 的软件层面, WEAVE 没有这个问题,原因后面会说到。
LXC(Linux Containers),即Linux容器,是一种操作系统层级的虚拟化技术,为Linux内核容器功能的一个用户空间接口。它将应用软件系统打包成一个软件容器(Container),内含应用软件本身的代码,以及所需要的操作系统核心和库。通过统一的命名空间(Namespace)和共享API来分配不同软件容器的可用硬件资源,创造出应用程序的独立沙箱运行环境,使得Linux用户可以容易的创建和管理系统或应用容器。
virtio是一种I/O半虚拟化解决方案,是一套通用I/O设备虚拟化的程序,是对半虚拟化Hypervisior中的一组通用I/O设备的抽象。virtio分为前端和后端,一个backend组件和一个frontend组件。backend组件是virtio接口的host端,frontend组件是virtio的guest端。
领取专属 10元无门槛券
手把手带您无忧上云