一、前言 k8s对Pods之间如何进行组网通信提出了要求,k8s对集群的网络有以下要求: 所有的Pods之间可以在不使用NAT网络地址转换的情况下相互通信 所有的Nodes之间可以在不使用NAT网络地址转换的情况下相互通信 二、容器和容器之间的网络 ? image.png 在k8s中每个Pod中管理着一组Docker容器,这些Docker容器共享同一个网络命名空间。 对于如何来配置网络,k8s在网络这块自身并没有实现网络规划的具体逻辑,而是制定了一套CNI(Container Network Interface)接口规范,开放给社区来实现。 在k8s中,iptables规则由kube-proxy控制器配置,该控制器监视K8s API服务器的更改。 这需要强调两个相关的问题:(1)从k8s的service访问Internet,以及(2)从Internet访问k8s的service. 5.1 k8s流量到Internet 从Node到公共Internet
K8s网络模型 K8s术语 K8S 是一个用于容器集群的分布式系统架构。 K8s管理层面。 K8s网络 K8s网络包括CNI、Service、Ingress、DNS 在K8s网络模型中,每个节点上的容器都有自己独立的IP段,节点之间的IP段不能重复,而节点也需要具备路由能力,使从本节点Pod里出来的流量可以根据目的 总结来说,K8s的容器网络重点关注两方面,IP地址分配和路由。 K8s主机内网络模型 K8s采用的是veth pair+bridge的模式,veth pair将容器与主机的网络协议栈连接起来,可以使pod之间通信。
一、背景介绍: 对于K8S里面容器之间的通讯基本上面可以分为三种类型: 1. POD里面不同容器之间的通讯: 因为同一个Pod里面的不同容器之间是共享同一个POD里面的网络资源,所以POD里容器之间的通讯基本上就是IPC之间的通讯方式,这个比较简单,不做详细介绍。 二、基础知识介绍: 网桥(Bridge): 在 Linux 中,能够起到虚拟交换机作用的网络设备,是一个工作在数据链路层(Data Link)的设备,主要功能是根据 MAC 地址学习来将数据包转发到网桥的不同端口 三、通讯过程介绍: 容器1的IP1访问容器2的IP2的交互过程如下所示: 1.在容器1中的路由规则里面查找IP2的地址,发现是是外部网络就会直接走容器1里面的eth0网卡(备注:走网卡的话,就是二层网路 从设备会被“剥夺”调用网络协议栈处理数据包的资格,从而“降级”成为网桥上的一个端口。
Kubernetes; 网络想做统一管理,k8s集群运行在OpenStack VM下, 如何做到更深层面的网络打通,典型的原因有: 1、 VM防arp欺骗,默认OpenStack虚拟机端口都开启了此功能 k8s集群,又跑了一层overlay网络,网络开销又增大了; 可选方案 k8s网络使用underlay网络 对现有应用需大量改造,应用内部大量使用内部service机制来调用其它服务,不兼容旧模型,pod 使用的是underlay网络,性能卓越; k8s网络使用多种cni k8s node运行ipvlan或macvlan+ptp的cni, node节点同时加载两个cni插件,ptp cni的作用是创建一对 适用于OpenStack和k8s集群是独立的环境,相当于由OpenStack接管service和NetworkPolicy,OpenStack实现变复杂; 最终选择k8s网络使用多种cni方案,基于保留 k8s原生特性,只需要改动k8s cni这部分。
内容来源:2018 年 1 月 10 日,灵雀云k8s首席专家刘梦馨在“云原生技术沙龙-北京站”进行《K8s高级网络实践》演讲分享。 Kubernetes的网络模型 Pod IP Kubernetes的网络模型主要分为三层。第一层是Pod的多个容器之间的互通,这层实现起来比较简单,因为所有的容器都共享一个网卡,所以可以直接通信。 另外每台Pod的网络路由和DNS都可以自行设置。 DHCP的随机分配模式在生产环境中很少得到应用,和容器网络也很难结合起来;host-local会限定每台机器的固定网络范围,增减机器的时候重新分配IP很困难。 未来我们可能会做一些更灵活的网络,通过插件在容器的生命周期内改变网络配置,包括固定MAC、动态路由、dns。另外还想要和现有系统解耦以及支持更多的网络模式。 以上为今天的全部分享内容,谢谢大家!
其实K8S确实是按照这个思路来玩的,不过这里引入了一个新概念Overlay Network(覆盖网络):通过软件构建一个覆盖在已有宿主机网络之上的、可以把所有容器连通在一起的虚拟网络。 二、通讯过程介绍 K8S解决容器间的网络通讯方案,采用的是CoreOS公司提供的Flannel项目,该项目的实现方式有下面三种,我们会一一介绍。 1. 设计思想是:在现有的三层网络之上,“覆盖”一层虚拟的、由内核 VXLAN 模块负责维护的二层网络,使得连接在这个 VXLAN 二层网络上的“主机”(虚拟机或者容器都可以)之间,可以像在同一个局域网(LAN 3.CNI插件 K8S里面的网络模型与2中介绍的原理基本一致,只不过用cni0网桥替代了docker0网桥,详细交互过程不在介绍,如下图所示: CNI 的设计思想:Kubernetes 在启动 Infra 容器之后,就可以直接调用 CNI 网络插件,为这个 Infra 容器的 Network Namespace,配置符合预期的网络栈。
在上一篇文章中我们概括了k8s集群网络大致包含哪些方面,包括服务在网络中的负载均衡方式(iptable和ipvs),以及underlay和overlay的组网。 在这里我们介绍宿主内的容器网络,当然我们还是以docker环境为例,介绍docker宿主环境中的容器网络。 Linux Network Namespace: 一提到linux网络,本质上就是由一系列组件组成,从而共同协作完成网络功能,一般这些组件包括: linux网络设备:例如network interface 这些设备可以完成网络数据包的收发,以及提供额外的修改数据包等功能。 下图用来表述宿主环境中的容器网络: ?
通过如下的命令能够查询网络配置信息: $ etcdctl --endpoints "http://node1.etcd.tulingapi.com:2379" ls /k8s/network/config /coreos.com/network/subnets/10.0.2.0-24 获取子网列表 $ etcdctl ls /k8s/network/subnets /k8s/network /subnets/10.0.86.0-24 /k8s/network/subnets/10.0.35.0-24 /k8s/network/subnets/10.0.24.0-24 3、启动flannel 验证flannel网络: 在node1节点上看etcd中的内容: $ etcdctl --endpoints "http://node1.etcd.tulingapi.com:2379" ls /k8s /k8s/network/subnets/10.0.24.0-24 在各个节点安装好以后最后要更改Docker的启动参数,使其能够使用flannel进行IP分配,以及网络通讯。
基本介绍 在实际工作中,我们经常会遇到一些疑似网络方面的故障问题,从而需要对 Kubernetes 集群中的 Pod 进行网络调试。 但是由于最小化原则,Pod 的容器镜像中通常并不会安装 ping、curl、telnet、tcpdump 等调试工具,或者在 Pod 容器中可以临时安装工具、但是效率不高,都会给 Pod 网络调试带来困难 针对上述实际场景,笔者将在本文介绍一种 Pod 网络调试方法,以灵活应对网络调试需求。 Pod 网络调试 1、调试工具 nsenter 是 Linux 操作系统的一种命令行工具,允许用户进入指定进程的某个命名空间,并在该命名空间下灵活使用主机的命令行工具、执行特权操作等。 由此可见,我们可以通过 nsenter 进入 Pod 中容器(进程)的网络命名空间,利用 Node 节点已有的命令行工具实现对 Pod 进行网络调试。
一 Kubernetes网络实现 1.1 Kubernetes网络优势 在实际的业务场景中,业务组件之间的关系十分复杂,微服务的理念更是让应用部署的粒度更加细小和灵活。 二 Kubernetes网络通信 2.1 容器之间通信 同一个Pod内的容器(Pod内的容器是不会跨宿主机的)共享同一个网络命名空间,共享同一个Linux协议栈。 在Kubernetes使用如下方式利用Docker的网络模型: 如上图所示,在Node1上运行着一个Pod实例,且运行着容器1和容器2。 其实,这和传统的一组普通程序运行的环境是完全一样的,传统程序不需要针对网络做特别的修改就可以移植了,它们之间的互相访问只需要使用localhost就可以。 由于Kubernetes的网络对Pod的地址是平面的和直达的,所以这些Pod的IP规划也很重要,若需要在整个集群中进行寻址,必须保证IP不能有冲突。
一 Kubernetes网络策略 1.1 策略说明 为实现细粒度的容器间网络访问隔离策略,Kubernetes发布Network Policy,目前已升级为networking.k8s.io/v1稳定版本 但仅定义一个网络策略是无法完成实际的网络隔离的,还需要一个策略控制器(Policy Controller)进行策略的实现。 1.2 网络策略配置 网络策略的设置主要用于对目标Pod的网络访问进行限制,在默认情况下对所有Pod都是允许访问的,在设置了指向Pod的Network Policy网络策略之后,访问Pod将会被限制。 示例1: [root@k8smaster01 study]# vi networkpolicy_01.yaml 1 apiVersion: networking.k8s.io/v1 2 kind policyTypes:网络策略的类型,包括ingress和egress两种,用于设置目标Pod的入站和出站的网络限制。
在这里我们主要介绍集群中的网络通讯,在以前文章中介绍过,对于容器之间的网络通讯基本分为两种,underlay方式和overlay方式。 我们在之前文章里采用的是基于flannel的underlay网络方式,所以这里主要介绍flannel underlay网络,以之前文章中安装的nginx-app为例: nginx-app的service 弦外之音,原始pod的host必须和目标pod的host在同一个二层网络里,因为只有这样才可以下一跳路由可达。 当然,这个也是flannel的underlay网络host gw方式的限制,既要求所有的k8s worker node节点都在同一个二层网络里(也可以认为是在同一个ip子网里)。 要求所有的worker node都在同一个二层网络里,来完成目标pod所在host的下一跳路由。
worker node and list the interfaces using, ip route and filter interface matching the pod IP. root@k8s-node calixxxxxxxxx -w /opt/capture.pcap & https://iximiuz.com/en/posts/container-learning-path/ https://learnk8s.io
基本介绍 在 Kubernetes 中,CNI(Container Network Interface,容器网络接口)是一个标准化的网络模型接口,负责定义容器如何在网络层面进行交互和通信。 在容器创建过程中,Kubelet 组件通过调用所需的 CNI 插件,即可使用相应的网络方案完成容器的网络配置,实现灵活的容器网络连接、网络资源释放等功能。 CRI 通过调用 CNI 插件来配置或清理容器网络,以确保容器网络配置过程与容器生命周期(主要是容器创建、销毁过程)紧密协调。 CNI 到 Pod:CNI 为 Pod 中的容器配置网络,将其连接到网络接口 Pod 到 CNI:Pod 中的容器网络配置完成后,向 CNI 返回信号 CNI 到 Kubelet:CNI 通知 Kubelet 组件,Pod 的网络已准备就绪 Kubelet 到 Pod:Kubelet 组件与 Pod 进行交互,获取 Pod 状态 其他相关 1、CNI 插件网络模式 覆盖网络(Overlay Network)
当集群部署完成以后,第一个要做的就是引入网络插件,只有引入了网络插件以后 ,不同节点的Pod才能进行通信。集群才算正常可用集群。 Flannel 是一个简单而轻量级的网络插件,广泛用于 Kubernetes 集群中来提供 Pod 之间的网络通信。 二层网络模型: Flannel 使用简单的二层网络模型,每个节点上的 Pod 分配一个唯一的子网 IP 地址。 网络通信:Pod 之间的通信通过节点的子网进行。 /v1 metadata: labels: k8s-app: flannel name: flannel roleRef: apiGroup: rbac.authorization.k8s.io
Calico 是一个广泛用于容器网络接口(CNI)的开源项目,它为 Kubernetes 等容器编排系统提供网络和网络安全策略管理功能。 主要特性 高性能网络:Calico 使用标准的 Linux 网络技术,如 BGP(边界网关协议),来提供高性能的网络连接,支持大规模集群环境。 IPIP (IP in IP) 模式 描述: 在这种模式下,Calico 使用 IP-in-IP 封装技术来通过底层网络传输数据包。这对于跨越多个子网或在不支持路由的网络环境中特别有用。 VXLAN 模式 描述: VXLAN(Virtual Extensible LAN)是一种网络虚拟化技术,允许创建覆盖网络。 适用场景: 当你需要构建一个覆盖网络以隔离不同租户或应用程序的网络流量时,VXLAN 提供了一种有效的解决方案。
说明 本文主要包括以下内容: vxlan简单介绍 为什么要使用vxlan k8s使用flannel(vxlan)如何进行pod之间的通信 vxlan简单介绍 VXLAN(Virtual eXtensible 它是一种overlay(覆盖网络)技术,通过三层的网络搭建虚拟的二层网络。 简单来讲,VXLAN是在底层物理网络(underlay)之上使用隧道技术,依托UDP层构建的overlay的逻辑网络,使逻辑网络与物理网络解耦,实现灵活的组网需求。 解决这个问题同时保证二层的广播域不会过分扩大,这也是云计算网络的要求 k8s中使用flannel(vxlan) 说明:我这里使用kubeadm安装的k8s,version为1.19,flannel的网络模式为 overruns 0 frame 0 TX packets 4765 bytes 1081070 (1.0 MiB) TX errors 0 dropped 8
CoreDNS 是一种使用 Golang 编写、由配置文件控制的插件式 DNS 服务器,自 Kubernetes 1.13 版本起,成为 Kubernetes 的默认 DNS 服务器,通常用于 Kubernetes 集群内部服务发现,允许应用程序之间直接、或通过 Service 对象名称互相访问。
在以前系列文章中我们以学习为目的介绍了二进制手动安装k8s集群,这里也是一个系列文章,同样以学习为目的,我们介绍k8s集群网络。 对于网络基本涉及两个方面,一是到各个服务的网络间负载均衡,另一个是网络间的通讯。 对于k8s来说网络间的负载均衡是由infrastructure实现的,即对于部署在集群中的各个pod是透明无感知的。 对于iptable方式是k8s默认的网络负载均衡模式,顾名思义就是利用linux iptable中的nat实现负载均衡。 我们以前文章里并没有刻意配置k8s负载均衡策略,所以是默认的iptable方式。如果希望以ipvs方式运行,那么需要在kube-proxy网络组件的启动参数中加入--proxy-mode=ipvs。 所以总结一下,对于k8s网络基本会包括以下方面 网络负载均衡 iptable方式(默认负载均衡策略) ipvs方式(v1.11以及以后版本) 网络间通讯 underlay网络:flannel host-gw
今天聊聊K8s的网络模型。 网络是K8s的核心部分,但想要理解它是如何工作的却有点难度。 K8s网络模型 简单来说,Kubernetes引入的网络模型提出了下列基本要求。只要满足了这些要求,即可成为一个K8s网络方案供应商。 说到"K8s网络边界"也就引出了一个重要的概念:K8s网络和宿主机网络。 宿主机网络:组成K8s集群的各个Node之间在没有安装K8s前就已经存在的网络拓扑。 当我们审视K8s集群相关的traffic时,比较好的方式是提醒自己:traffic目前在什么位置?是在K8s网络内部还是已经流出K8s网络到了宿主机网络环境? CNI插件的种类多种多样,但关键的功能不外乎以下两个: 网络插件,主要负责将Pod插入到K8s网络或从K8s网络删除。