k8s篇之underlay网络和overlay区别

k8s中underlay网络和overlay区别

一、网络

1 Overlay网络:

Overlay叫叠加网络也叫覆盖网络,指的是在物理网络的基础之上迭代实现新的虚拟网络,即可使网络中的容器可以互相通信。
优点是对物理网络的兼容性比较好,可以实现pod的跨宿主机子网的通信

2 Underlay网络

Underlay网络就是传统IT基础设施网络,由交换机和路由等设备组成, 借助以太网协议、路由协议和VLAN协议等驱动,它还是Overlay网络的底层网络,为Overlay网络提供数据通信服务。
容器网络中的Underlay网络是指借助驱动程序将宿主机的底层网络接口直接暴露容器使用的一种网络构建技术,较为常见的解决方案有MAC VLAN、IP VLAN和直接路由等。

3 Non-Overlay 网络

Non-Overlay 网络是指不使用封装技术的网络。这种网络直接在 Underlay 网络上进行通信,不需要创建额外的网络层。

二、网络通信-总结:

1、Overlay和Underlay(Macvlan)区别

<think>好的,用户想了解Kubernetes网络架构设计工作原理。首先,我需要回忆一下K8s的基本网络模型相关组件。根据引用[1],Kubernetes网络功能是必备技能,涉及到Pod、Service、Namespace等核心组件。接下来,用户提到的设计、原理实现,可能需要分层次来讲解。 首先,Kubernetes网络模型有几个基本原则:每个Pod拥有独立IP,Pod内容器共享网络,Pod之间直接通信,以及Service与Pod解耦。这些原则是网络架构的基础,必须明确说明。然后,容器间通信、Pod间通信、Service负载均衡外部访问这几个部分需要详细展开。 容器间通信是通过Pod内的localhost共享网络命名空间实现的,这部分相对简单。Pod间通信涉及到跨节点的情况,这里需要解释CNI插件的作用,比如Flannel、Calico等,它们负责处理不同节点上的Pod通信,可能使用Overlay网络或者BGP路由。引用[3]提到CNI插件是实现网络配置转换的关键,需要强调这一点。 Service的负载均衡部分,需要解释kube-proxy如何工作,比如iptables或IPVS模式,将Service的虚拟IP映射到后端Pod。引用[2]中的K8s Service负载均衡实现原理应该在这里应用。另外,外部访问涉及到Ingress控制器,可能需要提到NodePort、LoadBalancerIngress的区别。 在实现原理部分,CNI插件的工作机制需要详细说明,包括IP地址管理网络策略。引用[4][5]提到Kubernetes网络系统原理实现,可以引用这些内容来支持解释。例如,Calico的网络策略如何通过iptables或eBPF实现,或者Flannel的VXLAN封装。 然后,用户可能对设计考量感兴趣,比如为什么选择这样的模型,如何保证扩展性安全性。Kubernetes采用解耦设计,允许不同的网络插件,这样提高了灵活性。同时,每个Pod独立IP简化了网络配置,但可能带来IP管理的挑战,需要CNI插件处理。 最后,生成相关问题需要考虑用户可能的后续疑问,比如CNI插件的选择、网络策略的应用、ServiceIngress的区别,以及性能优化等。这些问题需要覆盖基础概念实际应用,帮助用户进一步学习。</think>### Kubernetes网络架构设计与工作原理分步解析 #### 一、网络架构设计原则 1. **Pod独立IP原则**:每个Pod分配唯一IP地址,所有容器共享该IP(通过共享网络命名空间实现)[^1] 2. **扁平化网络模型**:Pod间通信无需NAT,跨节点直接可达 3. **服务抽象层**:通过Service实现负载均衡服务发现,与底层Pod解耦 4. **网络插件化**:通过CNI(Container Network Interface)规范实现网络功能扩展[^3] $$Pod_{network} = \bigcup_{node} (Pod_{IP} \in 172.16.0.0/16)$$ #### 二、核心通信机制 1. **容器间通信** - 同一Pod内容器通过$localhost$直接通信 - 共享网络命名空间(通过pause容器实现) 2. **Pod间通信** - 跨节点通信依赖CNI插件实现,例如: - Flannel使用VXLAN封装(Overlay网络) - Calico使用BGP协议路由(Underlay网络) - 流量路径示例: $$Pod_A \xrightarrow{veth} cni0 \xrightarrow{overlay} Node_B \xrightarrow{cni0} Pod_B$$ 3. **Service负载均衡** - kube-proxy维护iptables/IPVS规则: $$ClusterIP:Port \Rightarrow \sum_{i=1}^{n} PodIP_i:Port$$ - 支持三种类型: - ClusterIP(默认内部访问) - NodePort(节点端口映射) - LoadBalancer(云厂商集成) 4. **外部访问控制** - Ingress控制器实现七层路由: $$HTTP(S) \xrightarrow{Ingress} Service \Rightarrow Pods$$ #### 三、关键组件实现原理 1. **CNI插件工作机制** - IP地址分配:通过host-local或dhcp插件 - 网络连通:创建veth pair连接容器与宿主机 - 策略实施:网络策略通过iptables/ebpf实现 2. **kube-proxy核心逻辑** ```go func syncProxyRules() { for _, service := range serviceList { for _, endpoint := range service.Endpoints { iptables.AppendRule("PREROUTING", "-d", service.ClusterIP, "-j", "DNAT", "--to", endpoint.PodIP) } } } ``` 3. **DNS服务发现** - CoreDNS解析记录格式: $$<service>.<namespace>.svc.cluster.local \Rightarrow ClusterIP$$ #### 四、网络模型设计考量 1. **性能优化** - 避免双重NAT(Docker默认bridge模式存在此问题) - 选择低延迟网络方案(如Calico IPIP模式) 2. **安全控制** - NetworkPolicy实现微分段: $$Allow(Pod_A \leftrightarrow Pod_B) \cap Deny(all)$$ 3. **多云兼容性** - 通过CNI抽象层支持混合云部署 - 例如:AWS VPC CNI插件直接分配EC2 IP
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

听说唐僧不吃肉

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值