K8s 的两个节点间通信案例
K8s中pod 间通信的两种情况
1.1 同一节点上的 Pod 通信原理
当两个 Pod 位于同一节点上时,它们的通信会通过节点的本地网络接口直接进行。整个过程通常比跨节点通信更加高效,因为数据包不需要通过外部网络进行传递或封装。
-
本地路由:
Kubernetes 节点上的所有 Pod 都通过虚拟网桥(例如cni0
)连接在一起。Pod 之间的通信只需通过这个虚拟网桥或节点的本地网络接口。数据包在本地节点内部路由,不需要离开节点,也不需要通过网络插件进行复杂的封装或隧道传输。 -
直接通信:
Pod 之间可以通过各自的 IP 地址直接通信。由于这些 Pod 处于同一节点,它们之间的通信通常通过 Linux 内核的网络堆栈直接完成,通信路径比跨节点的路径要短。 -
性能优势:
- 低延迟:同一节点上的通信只需通过节点内部的网络设备进行数据传递,避免了跨节点的网络延迟。
- 无网络隧道:不需要通过 CNI 插件创建隧道或进行额外的数据封装,因此性能更高。
- 本地负载:数据不需要离开节点,减少了网络设备的负载。
1.2 示例:同一节点上的 Pod 通信流程
假设有以下场景:
-
Pod A 和 Pod B 都位于节点 1,Pod A 的 IP 为
10.244.1.5
,Pod B 的 IP 为10.244.1.6
。
当 Pod A 需要与 Pod B 通信时,通信过程如下:
-
Pod A 向 Pod B 的 IP (
10.244.1.6
) 发送请求。 - 节点 1 的路由表 检查这个 IP 是否在本地(同一个节点的 IP 地址范围内),发现目标 Pod B 也在同一节点。
-
节点内部的虚拟网桥(例如
cni0
) 直接将数据包从 Pod A 转发到 Pod B。 - Pod B 接收到数据包并进行处理,然后将响应数据通过相同的路径返回给 Pod A。
由于不需要跨节点的复杂路由或封装,整个过程非常快速。
1.3 同一节点的通信 vs 跨节点通信
特性 | 同一节点 Pod 通信 | 跨节点 Pod 通信 |
---|---|---|
延迟 | 低延迟 | 相对较高,需跨节点传输 |
性能 | 高性能,本地通信无需封装 | 需通过网络隧道或路由转发,性能较低 |
复杂度 | 简单,无需复杂的网络配置或插件支持 | 依赖 CNI 插件和节点路由 |
数据路径 | 本地网桥或虚拟网络 | 通过网络隧道或跨节点路由 |
网络插件依赖 | 无需复杂插件支持 | 依赖 CNI 插件实现跨节点通信 |
网络封装 | 无需封装 | 可能需要使用 VXLAN、IPIP 等封装 |
网络插件在同一节点通信中的作用
虽然 Pod 之间的通信在同一节点上会通过本地网桥进行,但 CNI 插件仍然负责管理和分配 Pod 的 IP 地址,以及确保同一节点和跨节点的通信都能无缝进行。即使通信只发生在同一节点,CNI 插件仍会确保网络的可达性和隔离性(如果启用了 NetworkPolicy
)。
1.4 NetworkPolicy 的影响
即使 Pod 位于同一节点上,如果 Kubernetes 中启用了 NetworkPolicy
,也可以用来限制 Pod 之间的通信。例如,某些 Pod 可以通过策略被禁止访问其他 Pod,即使它们在同一节点上。NetworkPolicy
可以基于标签、IP 地址范围等对 Pod 间的流量进行控制,确保通信符合安全要求。
1.5 总结
- 同一节点上的 Pod 通信 是通过节点内部的虚拟网络进行的,具有较高的性能和低延迟,因为数据包不需要跨节点传输。
- Pod 通过本地路由和虚拟网桥进行通信,不依赖网络隧道或跨节点的复杂网络配置。
- CNI 插件负责管理 Pod 的 IP 地址和网络配置,但同一节点的通信无需复杂的封装和隧道传输。
同一节点上的通信相对高效,但 Kubernetes 的网络设计使得无论 Pod 位于哪个节点,用户都可以透明地进行通信,而无需关心底层的网络拓扑。
2.1 集群内部不同节点上的 Pod 通信原理
Kubernetes 依赖于集群网络插件(CNI,Container Network Interface)来确保所有节点上的 Pod 都在同一个虚拟网络中。具体原理如下:
-
Pod 的 IP 地址全局唯一:
每个 Pod 都有一个唯一的 IP 地址,无论它位于哪个节点,其他 Pod 都可以直接使用这个 IP 进行通信。Kubernetes 保证所有 Pod 之间的 IP 地址是全局可路由的(不需要 NAT 转换)。 -
跨节点的网络插件(CNI)支持:
Kubernetes 使用网络插件(例如 Calico、Flannel、Weave、Cilium 等)来管理集群中的 Pod 网络。CNI 插件的作用是在所有节点之间建立网络隧道,确保即使 Pod 位于不同节点上,它们也能够通过 IP 互相通信。这些插件通常会设置一些虚拟网络或者 overlay 网络(例如 VXLAN、IPIP 等),以保证跨节点的流量能够传递。 -
节点间路由:
Kubernetes 集群中的每个节点都会维护路由表,告诉节点如何将流量发送到其他节点上的 Pod。这些路由由 Kubernetes 控制平面和 CNI 插件自动管理,用户不需要手动配置。 -
Service 负载均衡:
如果 Pod 通过 Kubernetes Service 进行通信,Kubernetes 将通过 iptables 或 IPVS 来对流量进行负载均衡,无论目标 Pod 在哪个节点上。Service 资源使用 ClusterIP 对外暴露服务,集群内部的 Pod 可以通过 Service 的 ClusterIP 或者 DNS 名称来访问服务,背后 Kubernetes 会将请求转发给不同节点上的实际 Pod。
2.2 示例:跨节点 Pod 通信的流程
假设有以下场景:
-
Pod A 位于节点 1,IP 为
10.244.1.5
。 -
Pod B 位于节点 2,IP 为
10.244.2.7
。
当 Pod A 需要与 Pod B 通信时,通信过程如下:
-
Pod A 向 Pod B 的 IP (
10.244.2.7
) 发送请求。 - 节点 1 的路由表 检查这个 IP 不在当前节点,将数据包发送给节点 2。
- CNI 插件(例如 Calico 或 Flannel)在节点 1 和节点 2 之间建立了一个隧道(overlay 网络),通过这个隧道将数据包转发到节点 2。
- 节点 2 接收到数据包后,通过路由表找到目标 Pod B 并将数据包传递给它。
- Pod B 接收到数据包并进行处理,之后将响应数据通过相同的路径返回给 Pod A。
这个过程对用户透明,无需额外的配置。
2.3 跨节点通信需要注意的地方
-
网络插件选择:
不同的 CNI 插件可能使用不同的机制来实现跨节点的通信,例如:-
Flannel 使用
VXLAN
或host-gw
。 - Calico 使用 BGP 或 IPIP 隧道。
- Weave 和 Cilium 使用不同的 overlay 或路由方式。
你需要根据具体的集群需求选择合适的网络插件。
-
Flannel 使用
-
网络策略(
NetworkPolicy
):
如果需要控制Pod
之间的通信(例如限制某些 Pod 只能与特定的 Pod 通信),可以使用Kubernetes
的 NetworkPolicy 来实现。NetworkPolicy
允许你基于标签、IP 地址范围等限制 Pod 之间的流量,甚至可以限制跨节点的流量。 -
性能和延迟:
跨节点通信由于需要通过网络隧道或路由表,会有一定的延迟。特别是在使用 overlay 网络时(例如 Flannel 的 VXLAN),数据包需要封装和解封,可能会稍微影响性能。因此,如果性能要求很高,可以考虑选择一些高效的 CNI 插件或者在节点之间部署专用的网络加速解决方案。
2.4 总结
- 在 Kubernetes 集群中,Pod 即使位于不同的节点上,依然可以通过虚拟网络无缝通信。
- Kubernetes 通过 CNI 插件确保不同节点上的 Pod 都能互相通信,而无需用户手动管理跨节点的网络。
- 用户可以通过 Service 或直接使用 Pod IP 来进行跨节点通信,所有路由和负载均衡都由 Kubernetes 和 CNI 插件自动处理。
推荐阅读
-
K8s 的两个节点间通信案例
-
go语言Socket编程-Socket编程 什么是Socket Socket,英文含义是插座、插孔,一般称之为套接字,用于描述IP地址和端口。可以实现不同程序间的数据通信。 Socket起源于Unix,而Unix基本哲学之一就是“一切皆文件”,都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。Socket就是该模式的一个实现,网络的Socket数据传输是一种特殊的I/O,Socket也是一种文件描述符。Socket也具有一个类似于打开文件的函数调用:Socket,该函数返回一个整型的Socket描述符,随后的连接建立、数据传输等操作都是通过该Socket实现的。 套接字的内核实现较为复杂,不宜在学习初期深入学习,了解到如下结构足矣。 套接字通讯原理示意 在TCP/IP协议中,“IP地址+TCP或UDP端口号”唯一标识网络通讯中的一个进程。“IP地址+端口号”就对应一个socket。欲建立连接的两个进程各自有一个socket来标识,那么这两个socket组成的socket pair就唯一标识一个连接。因此可以用Socket来描述网络连接的一对一关系。 常用的Socket类型有两种:流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)。流式是一种面向连接的Socket,针对于面向连接的TCP服务应用;数据报式Socket是一种无连接的Socket,对应于无连接的UDP服务应用。 网络应用程序设计模式 C/S模式 传统的网络应用设计模式,客户机(client)/服务器(server)模式。需要在通讯两端各自部署客户机和服务器来完成数据通信。 B/S模式 浏览器(Browser)/服务器(Server)模式。只需在一端部署服务器,而另外一端使用每台PC都默认配置的浏览器即可完成数据的传输。 优缺点 对于C/S模式来说,其优点明显。客户端位于目标主机上可以保证性能,将数据缓存至客户端本地,从而提高数据传输效率。且,一般来说客户端和服务器程序由一个开发团队创作,所以他们之间所采用的协议相对灵活。可以在标准协议的基础上根据需求裁剪及定制。例如,腾讯所采用的通信协议,即为ftp协议的修改剪裁版。 因此,传统的网络应用程序及较大型的网络应用程序都首选C/S模式进行开发。如,知名的网络游戏魔兽世界。3D画面,数据量庞大,使用C/S模式可以提前在本地进行大量数据的缓存处理,从而提高观感。 C/S模式的缺点也较突出。由于客户端和服务器都需要有一个开发团队来完成开发。工作量将成倍提升,开发周期较长。另外,从用户角度出发,需要将客户端安插至用户主机上,对用户主机的安全性构成威胁。这也是很多用户不愿使用C/S模式应用程序的重要原因。 B/S模式相比C/S模式而言,由于它没有独立的客户端,使用标准浏览器作为客户端,其工作开发量较小。只需开发服务器端即可。另外由于其采用浏览器显示数据,因此移植性非常好,不受平台限制。如早期的偷菜游戏,在各个平台上都可以完美运行。 B/S模式的缺点也较明显。由于使用第三方浏览器,因此网络应用支持受限。另外,没有客户端放到对方主机上,缓存数据不尽如人意,从而传输数据量受到限制。应用的观感大打折扣。第三,必须与浏览器一样,采用标准http协议进行通信,协议选择不灵活。 因此在开发过程中,模式的选择由上述各自的特点决定。根据实际需求选择应用程序设计模式。 简单的C/S模型通信 Server端:Listen函数 func Listen(network, address string) (Listener, error) network:选用的协议:TCP、UDP, 如:“tcp”或 “udp” address:IP地址+端口号, 如:“127.0.0.1:8000”或 “:8000” Listener 接口: type Listener interface { Accept (Conn, error) Close error Addr Addr } Conn 接口: type Conn interface { Read(b byte) (n int, err error) Write(b byte) (n int, err error) Close error LocalAddr Addr RemoteAddr Addr SetDeadline(t time.Time) error SetReadDeadline(t time.Time) error SetWriteDeadline(t time.Time) error } 参看 [<u>https://studygolang.com/pkgdoc</u>](https://studygolang.com/pkgdoc) 中文帮助文档中的demo: 示例代码:TCP服务器.go package main import ( "net" "fmt" ) func main { // 创建监听 listener, err:= net.Listen("tcp", ":8000") if err != nil { fmt.Println("listen err:", err) return } defer listener.Close // 主协程结束时,关闭listener fmt.Println("服务器等待客户端建立连接...") // 等待客户端连接请求 conn, err := listener.Accept if err != nil { fmt.Println("accept err:", err) return } defer conn.Close // 使用结束,断开与客户端链接 fmt.Println("客户端与服务器连接建立成功...") // 接收客户端数据 buf := make(byte, 1024) // 创建1024大小的缓冲区,用于read n, err := conn.Read(buf) if err != nil { fmt.Println("read err:", err) return } fmt.Println("服务器读到:", string(buf[:n])) // 读多少,打印多少。 }
-
RPC - HDFS 节点间的通信桥梁
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)
-
供应链协同管理云平台系统研究需要什么设备 供应链信息协同-供应链协同的定义:供应链协同是指供应链全链条的各环节(包括上下游各企业及企业内各部门)实现协同运行的一系列活动或最终效果。即供应链全链条各节点确立共同目标,在互利共赢的基础上,深入合作、风险共担、信息共享、流程互通、共同创造客户价格的过程。 供应链协同的范围:供应链协同主要包括两个方面即:组织内协同和供需间协同。组织内协同指的是企业内的各个相关部门在共同目标的指引下相互协作,减少沟通障碍,打破部门墙,实现跨部门,跨体系的协同。如需求、设计、研发、计划、采购、库存、生产、仓储、物流、销售售后等基础活动以及财务、法务、人事等支持性活动间的协同;还包括战略与执行间的协同;企业总体目标、长期目标、年度目标间的协同等。 供需间协同是指供应链上下游的企业间共享重要信息,包括需求量、订单情况、库存情况、生产能力、销售数据等,上下游企业根据这些重点信息规划自己的生产、订单、销售、库存等的管理,避免各自为战、坐井观天。 供应链协同目标