【Kubernetes系列】第10篇 网络原理解析(下篇)

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 3. 覆盖网络 - Overlay Network覆盖网络(overlay network)是将TCP数据包装在另一种网络包里面进行路由转发和通信的技术。Overlay网络不是默认必须的,但是它们在特定场景下非常有用。

3. 覆盖网络 - Overlay Network

覆盖网络(overlay network)是将TCP数据包装在另一种网络包里面进行路由转发和通信的技术。Overlay网络不是默认必须的,但是它们在特定场景下非常有用。比如当我们没有足够的IP空间,或者网络无法处理额外路由,抑或当我们需要Overlay提供的某些额外管理特性。一个常见的场景是当云提供商的路由表能处理的路由数是有限制时,例如AWS路由表最多支持50条路由才不至于影响网络性能。因此如果我们有超过50个Kubernetes节点,AWS路由表将不够。这种情况下,使用Overlay网络将帮到我们。

本质上来说,Overlay就是在跨节点的本地网络上的包中再封装一层包。你可能不想使用Overlay网络,因为它会带来由封装和解封所有报文引起的时延和复杂度开销。通常这是不必要的,因此我们应当在知道为什么我们需要它时才使用它。

为了理解Overlay网络中流量的流向,我们拿Flannel做例子,它是CoreOS 的一个开源项目。Flannel通过给每台宿主机分配一个子网的方式为容器提供虚拟网络,它基于Linux TUN/TAP,使用UDP封装IP包来创建overlay网络,并借助etcd维护网络的分配情况。

gif2_cross_node_overlay_network

Kubernetes Node with route table
(通过Flannel Overlay网络进行跨节点的Pod-to-Pod通信)

这里我们注意到它和之前我们看到的设施是一样的,只是在root netns中新增了一个虚拟的以太网设备,称为flannel0。它是虚拟扩展网络Virtual Extensible LAN(VXLAN)的一种实现,但是在Linux上,它只是另一个网络接口。

从pod1到pod4(在不同节点)的数据包的流向类似如下:

1.它由pod1中netns的eth0网口离开,通过vethxxx进入root netns。

2.然后被传到cbr0,cbr0通过发送ARP请求来找到目标地址。

3.数据封装

*a. 由于本节点上没有Pod拥有pod4的IP地址,因此网桥把数据包发送给了flannel0,因为节点的路由表上flannel0被配成了Pod网段的目标地址。
*b. flanneld daemon和Kubernetes apiserver或者底层的etcd通信,它知道所有的Pod IP,并且知道它们在哪个节点上。因此Flannel创建了Pod IP和Node IP之间的映射(在用户空间)。flannel0取到这个包,并在其上再用一个UDP包封装起来,该UDP包头部的源和目的IP分别被改成了对应节点的IP,然后发送这个新包到特定的VXLAN端口(通常是8472)。

flannel_packet_encapsulation

Packet-in-packet encapsulation
(notice the packet is encapsulated from 3c to 6b in previous diagram)

尽管这个映射发生在用户空间,真实的封装以及数据的流动发生在内核空间,因此仍然是很快的

*c. 封装后的包通过eth0发送出去,因为它涉及了节点间的路由流量。

4.包带着节点IP信息作为源和目的地址离开本节点。

5.云提供商的路由表已经知道了如何在节点间发送报文,因此该报文被发送到目标地址node2。

6.数据解包

*a. 包到达node2的eth0网卡,由于目标端口是特定的VXLAN端口,内核将报文发送给了 flannel0。
*b. flannel0解封报文,并将其发送到 root 命名空间下。从这里开始,报文的路径和我们之前在Part 1 中看到的非Overlay网络就是一致的了。
*c. 由于IP forwarding开启着,内核按照路由表将报文转发给了cbr0。

7.网桥获取到了包,发送ARP请求,发现目标IP属于vethyyy。

8.包跨过管道对到达pod4

这就是Kubernetes中Overlay网络的工作方式,虽然不同的实现还是会有细微的差别。有个常见的误区是,当我们使用Kubernetes,我们就不得不使用Overlay网络。事实是,这完全依赖于特定场景。因此请确保在确实需要的场景下才使用。

4. 动态集群

由于Kubernetes(更通用的说法是分布式系统)天生具有不断变化的特性,因此它的Pod(以及Pod的IP)总是在改变。变化的原因可以是针对不可预测的Pod或节点崩溃而进行的滚动升级和扩展。这使得Pod IP不能直接用于通信。

我们看一下Kubernetes Service,它是一个虚拟IP,并伴随着一组Pod IP作为Endpoint(通过标签选择器识别)。它们充当虚拟负载均衡器,其IP保持不变,而后端Pod IP可能会不断变化。

service_label_selector

Kubernetes service对象中的label选择器

整个虚拟IP的实现实际上是一组iptables(最新版本可以选择使用IPVS,但这是另一个讨论)规则,由Kubernetes组件kube-proxy管理。 这个名字现在实际上是误导性的。 它在v 1.0之前确实是一个代理,并且由于其实现是内核空间和用户空间之间的不断复制,它变得非常耗费资源并且速度较慢。 现在,它只是一个控制器,就像Kubernetes中的许多其它控制器一样,它watch api server的endpoint的更改并相应地更新iptables规则。

iptables_dnat

Iptables DNAT

有了这些iptables规则,每当数据包发往Service IP时,它就进行DNAT(DNAT=目标网络地址转换)操作,这意味着目标IP从Service IP更改为其中一个Endpoint - Pod IP - 由iptables随机选择。这可确保负载均匀分布在后端Pod中。

5_tuple_entries

conntrack表中的5元组条目

当这个DNAT发生时,这个信息存储在conntrack中——Linux连接跟踪表(iptables规则5元组转译并完成存储:protocol,srcIP,srcPort,dstIP,dstPort)。 这样当请求回来时,它可以un-DNAT,这意味着将源IP从Pod IP更改为Service IP。 这样,客户端就不用关心后台如何处理数据包流。

因此通过使用Kubernetes Service,我们可以使用相同的端口而不会发生任何冲突(因为我们可以将端口重新映射到Endpoint)。 这使服务发现变得非常容易。 我们可以使用内部DNS并对服务主机名进行硬编码。 我们甚至可以使用Kubernetes提供的service主机和端口的环境变量来完成服务发现。

专家建议: 采取第二种方法,你可节省不必要的DNS调用,但是由于环境变量存在创建顺序的局限性(环境变量中不包含后来创建的服务),推荐使用DNS来进行服务名解析。

4.1 出站流量

到目前为止我们讨论的Kubernetes Service是在一个集群内工作。但是,在大多数实际情况中,应用程序需要访问一些外部api/website。

通常,节点可以同时具有私有IP和公共IP。对于互联网访问,这些公共和私有IP存在某种1:1的NAT,特别是在云环境中。

对于从节点到某些外部IP的普通通信,源IP从节点的专用IP更改为其出站数据包的公共IP,入站的响应数据包则刚好相反。但是,当Pod发出与外部IP的连接时,源IP是Pod IP,云提供商的NAT机制不知道该IP。因此它将丢弃具有除节点IP之外的源IP的数据包。

因此你可能也猜对了,我们将使用更多的iptables!这些规则也由kube-proxy添加,执行SNAT(源网络地址转换),即IP MASQUERADE(IP伪装)。它告诉内核使用此数据包发出的网络接口的IP,代替源Pod IP同时保留conntrack条目以进行反SNAT操作。

4.2 入站流量

到目前为止一切都很好。Pod可以互相交谈,也可以访问互联网。但我们仍然缺少关键部分 - 为用户请求流量提供服务。截至目前,有两种主要方法可以做到这一点:

* NodePort /云负载均衡器(L4 - IP和端口)

将服务类型设置为NodePort默认会为服务分配范围为30000-33000的nodePort。即使在特定节点上没有运行Pod,此nodePort也会在每个节点上打开。此NodePort上的入站流量将再次使用iptables发送到其中一个Pod(该Pod甚至可能在其它节点上!)。

云环境中的LoadBalancer服务类型将在所有节点之前创建云负载均衡器(例如ELB),命中相同的nodePort。

* Ingress(L7 - HTTP / TCP)

许多不同的工具,如Nginx,Traefik,HAProxy等,保留了http主机名/路径和各自后端的映射。通常这是基于负载均衡器和nodePort的流量入口点,其优点是我们可以有一个入口处理所有服务的入站流量,而不需要多个nodePort和负载均衡器。

4.3 网络策略

可以把它想象为Pod的安全组/ ACL。 NetworkPolicy规则允许/拒绝跨Pod的流量。确切的实现取决于网络层/CNI,但大多数只使用iptables。

结束语

目前为止就这样了。 在前面的部分中,我们研究了Kubernetes网络的基础以及overlay网络的工作原理。 现在我们知道Service抽象是如何在一个动态集群内起作用并使服务发现变得非常容易。我们还介绍了出站和入站流量的工作原理以及网络策略如何对集群内的安全性起作用。

参考文章:

An illustrated guide to Kubernetes Networking - part1

An illustrated guide to Kubernetes Networking - part2

An illustrated guide to Kubernetes Networking - part3

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
4月前
|
运维 Kubernetes 前端开发
如何用 eBPF 实现 Kubernetes 网络可观测性?实战指南
本文深入探讨了Kubernetes网络观测的挑战与eBPF技术的应用。首先分析了传统工具在数据碎片化、上下文缺失和性能瓶颈上的局限性,接着阐述了eBPF通过零拷贝观测、全链路关联和动态过滤等特性带来的优势。文章进一步解析了eBPF观测架构的设计与实现,包括关键数据结构、内核探针部署及生产环境拓扑。实战部分展示了如何构建全栈观测系统,并结合NetworkPolicy验证、跨节点流量分析等高级场景,提供具体代码示例。最后,通过典型案例分析和性能数据对比,验证了eBPF方案的有效性,并展望了未来演进方向,如智能诊断系统与Wasm集成。
131 0
|
5月前
|
人工智能 监控 安全
NTP网络子钟的技术架构与行业应用解析
在数字化与智能化时代,时间同步精度至关重要。西安同步电子科技有限公司专注时间频率领域,以“同步天下”品牌提供可靠解决方案。其明星产品SYN6109型NTP网络子钟基于网络时间协议,实现高精度时间同步,广泛应用于考场、医院、智慧场景等领域。公司坚持技术创新,产品通过权威认证,未来将结合5G、物联网等技术推动行业进步,引领精准时间管理新时代。
|
18天前
|
机器学习/深度学习 人工智能 算法
卷积神经网络深度解析:从基础原理到实战应用的完整指南
蒋星熠Jaxonic带你深入卷积神经网络(CNN)核心技术,从生物启发到数学原理,详解ResNet、注意力机制与模型优化,探索视觉智能的演进之路。
239 11
|
19天前
|
安全 网络性能优化 网络虚拟化
网络交换机分类与功能解析
接入交换机(ASW)连接终端设备,提供高密度端口与基础安全策略;二层交换机(LSW)基于MAC地址转发数据,构成局域网基础;汇聚交换机(DSW)聚合流量并实施VLAN路由、QoS等高级策略;核心交换机(CSW)作为网络骨干,具备高性能、高可靠性的高速转发能力;中间交换机(ISW)可指汇聚层设备或刀片服务器内交换模块。典型流量路径为:终端→ASW→DSW/ISW→CSW,分层架构提升网络扩展性与管理效率。(238字)
372 0
|
2月前
|
XML JSON JavaScript
从解决跨域CSOR衍生知识 Network 网络请求深度解析:从快递系统到请求王国-优雅草卓伊凡
从解决跨域CSOR衍生知识 Network 网络请求深度解析:从快递系统到请求王国-优雅草卓伊凡
70 0
从解决跨域CSOR衍生知识 Network 网络请求深度解析:从快递系统到请求王国-优雅草卓伊凡
|
5月前
|
机器学习/深度学习 人工智能 算法
深度解析:基于卷积神经网络的宠物识别
宠物识别技术随着饲养规模扩大而兴起,传统手段存在局限性,基于卷积神经网络的宠物识别技术应运而生。快瞳AI通过优化MobileNet-SSD架构、多尺度特征融合及动态网络剪枝等技术,实现高效精准识别。其在智能家居、宠物医疗和防走失领域展现广泛应用前景,为宠物管理带来智能化解决方案,推动行业迈向新高度。
|
4月前
|
开发者
鸿蒙仓颉语言开发教程:网络请求和数据解析
本文介绍了在仓颉开发语言中实现网络请求的方法,以购物应用的分类列表为例,详细讲解了从权限配置、发起请求到数据解析的全过程。通过示例代码,帮助开发者快速掌握如何在网络请求中处理数据并展示到页面上,减少开发中的摸索成本。
鸿蒙仓颉语言开发教程:网络请求和数据解析
|
5月前
|
网络架构
广播域与冲突域:解析网络技术中的复杂性。
总的来说,理解广播域和冲突域的概念可以使我们在设计或维护网络的过程中,更有效地管理通信流程,避免出现网络瓶颈,提成整体网络性能。就像是如何有效地运作一个市场,把每个人的需求和在合适的时间和地点配对,确保每个人的声音都被听到,每个人的需求都被满足。
97 11
|
5月前
|
机器学习/深度学习 算法 测试技术
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析
本文探讨了基于图的重排序方法在信息检索领域的应用与前景。传统两阶段检索架构中,初始检索速度快但结果可能含噪声,重排序阶段通过强大语言模型提升精度,但仍面临复杂需求挑战
141 0
图神经网络在信息检索重排序中的应用:原理、架构与Python代码解析
|
5月前
|
网络协议 安全 Devops
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
145 4

热门文章

最新文章

推荐镜像

更多