vxlan

查看集群各服务的进程是都在正常运行 kubectl get cs -o wide kubectl get nodes -o wide kubectl get svc kubernetes 容器一直在 pendding，node 节点的负载却很低 kube-scheduler 负责调度，查看这个服务的日志 node 节点无法访问 CLUSTER-IP 和 端口不通 看 kube-proxy 的日志，如果出现 "Failed to list *core.Endpoints: endpoints is forbidden: User "system:node:foo" cannot list endpoints at the cluster scope" ，则是 RBAC 的原因。 kube-proxy 没有权限访问 apiserver 的相应接口，导致获取不到 CLUSTER-IP，从而无法配置 iptables 策略导致访问失败。 cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: system:kube-nodes namespace: "" roleRef: apiGroup: rbac

跨节点通讯，需要通过NAT，即需要做源地址转换。 k8s网络通信： 　　1） 容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现； 2） pod之间的通信，pod ip <---> pod ip，pod和pod之间要不经过任何转换即可通信； 3） pod和service通信:pod ip <----> cluster ip（即service ip）<---->pod ip，他们通过iptables或ipvs实现通信，另外大家要注意ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换； 4） Service与集群外部客户端的通信 [root@master pki]# kubectl get configmap -n kube-system NAME DATA AGE coredns 1 22d extension-apiserver-authentication 6 22d kube-flannel-cfg 2 22d kube-proxy 2 22d kubeadm-config 1 22d kubelet-config-1.11 1 22d kubernetes-dashboard-settings 1 9h [root@master pki]# kubectl get configmap kube-proxy -o yaml -n

网络虚拟化中的 offload 技术：LSO/LRO、GSO/GRO、TSO/UFO、VXLAN 2014年02月14日 16:42:11 阅读数：7731 offload 现在，越来越多的网卡设备支持 offload 特性，来提升网络收/发性能。offload 是将本来该操作系统进行的一些数据包处理（如分片、重组等）放到网卡硬件中去做，降低系统 CPU 消耗的同时，提高处理的性能。 包括 LSO/LRO、GSO/GRO、TSO/UFO 等。 LSO/LRO 分别对应到发送和接收两个方向，是 Large Segment Offload 和 Large Receive Offload。 首先来看 LSO。我们知道计算机网络上传输的数据基本单位是离散的网包，既然是网包，就有大小限制，这个限制就是 MTU（Maximum Transmission Unit）的大小，一般是1518字节。比如我们想发送很多数据出去，经过os协议栈的时候，会自动帮你拆分成几个不超过MTU的网包。然而，这个拆分是比较费计算资源的（比如很多时候还要计算分别的checksum），由 CPU 来做的话，往往会造成使用率过高。那可不可以把这些简单重复的操作 offload 到网卡上呢？ 于是就有了 LSO，在发送数据超过 MTU 限制的时候（太容易发生了），OS 只需要提交一次传输请求给网卡，网卡会自动的把数据拿过来

Virtual Extensible Local Area Network，虚拟扩展局域网。VXLAN是一种网络虚似化技术，可以改进大型云计算在部署时的扩展问题，是对VLAN的一种扩展。VXLAN是一种功能强大的工具，可以穿透三层网络对二层进行扩展。它可通过封装流量并将其扩展到第三层网关，以此来解决VMS（虚拟内存系统）的可移植性限制，使其可以访问在外部IP子网上的服务器。 VxLAN（Virtual eXtensible Local Area Network，虚拟扩展局域网）技术很好地解决了现有VLAN技术无法满足大二层网络需求的问题。VxLAN技术是一种大二层的虚拟网络技术，主要原理是引入一个UDP格式的外层隧道作为数据链路层，而原有数据报文内容作为隧道净荷加以传输。由于外层采用了UDP作为传输手段，净荷数据可以轻松地在二三层网络中传送。 VXLAN主要解决现阶段大规模云计算数据中心虚拟网络不足的问题。VMware ESXi、Open vSwitch、当前主流的网络芯片均已支持VXLAN。 基本原理 VXLAN是一种隧道技术，能在三层网络的基础上建立二层以太网网络隧道，从而实现跨地域的二层互连。 VXLAN采取了将原始以太网报文封装在UDP数据包里的封装格式。将原来的二层数据帧加上VXLAN头部一起封装在一个UDP数据包里。 VXLAN头部包含有一个VXLAN标识（即VNI

一些服务器虚拟化软件可实现在两台虚拟化的物理服务器之间对虚拟机做动态迁移，迁移至另一中心的 虚拟机不仅保留原有IP地址，而且还保持迁移前的运行状态（如TCP会话状态），所以必须将涉及虚拟机 迁移的物理服务器接入同一个二层网络（虚拟机在迁移前后的网关不变），这种应用场景要求构建跨中 心的二层互联网络。 我的理解是，仅仅IP不变这一条件就要保证VLAN不改变(否则会引起路由动荡吧？），但这与保持迁移前 的会话状态有何关系？ 这是一个很好的问题，先来假设如果数据中心是三层互联，会出现什么幺蛾子。假定服务器A的IP为10.1.1.10/24，网关为10.1.1.1，数据中心三层互联，那三层连接的两个数据中心不可能使用同一网段的IP，另外一个数据中心不会再使用10.1.1.0/24 这个网段，否则如何路由？（如果有人说用NAT可以解决地址冲突问题，当我这里的文字没写）所以如果做服务器在不同数据中心的迁移，必须要给服务器重新分配不同的IP。所以TCP连接肯定断，另外增加网络管理负担。 如果数据中心是二层互联，服务器迁移前后在同一个VLAN中，服务器A可以继续使用10.1.1.10，如果只有一个网关GW1，假定服务器A从DC1迁移到DC2迁移前的双向流量模型： 客户端--->GW1---->A A--->GW1---->客户端 迁移后的双向流量模型： 客户端--->GW1---->DC1

Install and configure the Networking components on the controller node. Install the components # yum install openstack-neutron openstack-neutron-ml2 \ openstack - neutron - linuxbridge ebtables Configure the server component Edit the / etc / neutron / neutron . conf file and complete the following actions : ○ In the [ database ] section , configure database access : [ database ] # ... connection = mysql + pymysql : //neutron:neutron123@stack.flex.net/neutron 注意：注释或移除其它连接选项在[ database ]区域中 ○ In the [DEFAULT] section, enable the Modular Layer 2 (ML2) plug-in, router service, and overlapping IP

Virtual Extensible Local Area Network，虚拟扩展局域网。VXLAN是一种网络虚似化技术，可以改进大型云计算在部署时的扩展问题，是对VLAN的一种扩展。VXLAN是一种功能强大的工具，可以穿透三层网络对二层进行扩展。它可通过封装流量并将其扩展到第三层网关，以此来解决VMS（虚拟内存系统）的可移植性限制，使其可以访问在外部IP子网上的服务器。 VxLAN（Virtual eXtensible Local Area Network，虚拟扩展局域网）技术很好地解决了现有VLAN技术无法满足大二层网络需求的问题。VxLAN技术是一种大二层的虚拟网络技术，主要原理是引入一个UDP格式的外层隧道作为数据链路层，而原有数据报文内容作为隧道净荷加以传输。由于外层采用了UDP作为传输手段，净荷数据可以轻松地在二三层网络中传送。 VXLAN主要解决现阶段大规模云计算数据中心虚拟网络不足的问题。VMware ESXi、Open vSwitch、当前主流的网络芯片均已支持VXLAN。 基本原理 VXLAN是一种隧道技术，能在三层网络的基础上建立二层以太网网络隧道，从而实现跨地域的二层互连。 VXLAN采取了将原始以太网报文封装在UDP数据包里的封装格式。将原来的二层数据帧加上VXLAN头部一起封装在一个UDP数据包里。 VXLAN头部包含有一个VXLAN标识（即VNI

什么是VXLAN？ VXLAN，即Virtual Extensible LAN（虚假可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network） VXLAN的设计思想是： 在现有的三层网络之上，“覆盖”一层虚拟的、由内核VXLAN模块负责维护的二层网络，使得连接在这个VXLAN二nfcu网络上的“主机”（虚拟机或容器都可以），可以像在同一个局域网（LAN）里那样自由通信。 为了能够在二nfcu网络上打通“隧道”，VXLAN会在宿主机上设置一个我死的网络设备作为“隧道”的两端，叫VTEP：VXLAN Tunnel End Point（虚拟隧道端点） Flannel的VXLAN工作原理 flanel.1设备，就是VXLAN的VTEP，即有IP地址，也有MAC地址 与UPD模式类似，当container-发出请求后，上的地址10.1.16.3的IP包，会先出现在docker网桥，再路由到本机的flannel.1设备进行处理（进站） 为了能够将“原始IP包”封装并发送到正常的主机，VXLAN需要找到隧道的出口：上的宿主机的VTEP设备，这个设备信息，由宿主机的flanneld进程维护 VTEP设备之间通过二层数据桢进行通信 源VTEP设备收到原始IP包后

计算节点云主机获取IP地址异常 问题描述： 新增的计算节点物理机内核版本3.10.0-514.1.el7.x86_64，qemu版本1.5.3-501.el7.centos.bc.x86_64，libvirt版本1.2.17-13.el7_2.4.1.x86_64，OVS版本3.2.10-392-nuage，其他配置项服务运行正常，当创建运行虚拟机时，发现虚拟机无法获取IP地址。 问题根本原因分析： https://bugzilla.redhat.com/show_bug.cgi?id=1445054 新增计算节点物理机，因系统引导文件增加ipv6.disable = 1参数。导致 vxlan 无法初始化错误“vxlan ：无法绑定端口4789，err = -97” ，通常情况下EAFNOSUPPORT 状态很好，除了在第一次调用__vxlan_sock_add（）时，EAFNOSUPPORT而导致的IPv6检查失败的情况下，不会发生第二个非IPv6调用__vxlan_sock_add（）。 由于在__vxlan_add_sock （）中进行了检查：__vxlan_add_sock（）将通vxlan_sock_add - > __ vxlan_sock_add-> vxlan_create_sock-> udp_sock_create（）返回EAFNOSUPPORT而导致失败

在如今的网络世界，如果你还不知道VXLAN那么你就真的是out了。。。不管是各个厂商，还是各个论坛，都会或多或少的有一些VXLAN的文章，谈主也赶个时髦整理一些以前学习过的VXLAN知识。Ok，第一篇开始～ 一、什么是VXLAN 传统的802.1Q VLAN 标识符只有12 Bits，12 Bits表示最大可以有4096个唯一的二层网络分段。VXLAN扩展至了24 Bits，24 Bits表示最大可以有1600万个唯一的二层网络分段。 在虚拟化大量应用的今天，如果仍然使用802.1Q VLAN，那么VM 移动会被限制在本VLAN。使用VXLAN 封装，原始数据帧会被封装成MAC in UDP，这样，就允许二层网络连接跨越三层路由网络。 同时，保证VM迁移前后的IP地址、MAC地址不变。PS：本篇还讲不到，敬请期待后续～ 二、VXLAN 帧格式 从上图可知， 1、除原始数据帧外，外层头部需要消耗额外Bytes（上图几个header相加即可）。PS：如果有需要，我们就需要修改交换机接口MTU以适应VXLAN数据包，看具体业务包大小。 2、UDP 源端口：VTEP设备动态分配的。通过内层头部的L2/L3/L4信息做Hash计算得出。 3、UDP目的端口：固定的使用4789。 查看更多内容 来源： https://www.cnblogs.com/sdnlab1509/p/11534123