K8S基础--网络

最新推荐文章于 2025-07-17 17:43:16 发布

albenHong

最新推荐文章于 2025-07-17 17:43:16 发布

阅读量759

点赞数 21

CC 4.0 BY-SA版权

文章标签： kubernetes 网络 docker

本文链接：https://blog.csdn.net/wrfc_hgy/article/details/148741632

集群网络系统是K8S的核心部分，k8s的网络系统主要面临以下四个问题：

容器间通信问题（同一个pod里面的容器共享网络namespace，不再详述）
pod 间通信（同一个node节点上的pod，不同node节点上的pod）
pod和服务间通信问题
外部和服务间通信的问题

除此之外，还需要了解一下K8S里面常用的网络插件，包括flannel、calico、cilium等，本文并不会过于详细的介绍一些技术实现细节，只是会大致生成一个整个k8s网络模型的框架，方便理解。

基本概念：

CIDR：K8S 中，每个node节点都会被分配一个CIDR块，用来给node上的pod分配IP地址，另外还需要把Pod的IP和所在的nodeip进行关联。
underlay 网络以及 overlay 网络：
- underlay 网络是底层的物理网络，负责网络之间的数据包传递，可以是第二层的，也可以是第三层的，第二层网络主要用于以太网，通过VLAN进行划分。三层网络涉及到了一些路由协议，同一个自治域使用OSPF、IS-IS等协议进行路由控制，各个域之间采用 BGP 等协议进行路由传递和互联。
- overlay 网络，为了摆脱underlay网络的限制，采用网络虚拟化技术，在underlay 网络上构建出来的一层虚拟化网络，overlay 网络协议标准包括 vxlan等
CNI：CNCF 为 K8S 提供的一个统一的网络配置接口
- Main 插件：用来创建具体网络设备的二进制文件。比如，bridge、ipvlan、loopback、macvlan、ptp(point-to-point, Veth Pair 设备)，以及 vlan。如开源的 Flannel、Weave 等项目，都属于 bridge 类型的 CNI 插件，在具体的实现中，它们往往会调用 bridge 这个二进制文件。
- Meta 插件：由 CNI 社区维护的内置 CNI 插件，不能作为独立的插件使用，需要调用其他插件。tuning，是一个通过 sysctl 调整网络设备参数的二进制文件；portmap，是一个通过 iptables 配置端口映射的二进制文件；bandwidth，是一个使用 Token Bucket Filter (TBF) 来进行限流的二进制文件。
- IPAM 插件：IP Address Management，它是负责分配 IP 地址的二进制文件。比如，dhcp，这个文件会向 DHCP 服务器发起请求；host-local，则会使用预先配置的 IP 地址段来进行分配。
namespace 以及 cgroups：
- 容器技术的本质是一种特殊的进程隔离机制，它主要通过三个核心特性实现，隔离性（namespace）、限制性（cgroups）、可移植性（联合文件系统）
- namespace 是用来做资源隔离的
- cgroups 是用来做资源限制的，比如对cpu、内存进行资源限制

iptables：四表五链路(raw、filter、nat、mangle) (input、output、forward、preforward、postforward)
k8s 网络层级大致可以划分为以下几部分：

一、Pod 网络

同一个节点上Pod 网络互通，早期直接通过 docker0网桥来实现，后期的话有一部分是通过路由来实现的，可以在node节点上执行 route -n 命令，可以清晰的看到路由规则，但是 veth对等变化不大，只是去掉了 docker0网桥的部分。
不同node节点上的pod的通信
- 大体上可以归纳为两类封包-解包以及直接提供路由方式
- 封包-解包包含 flannel 的 vxlan 方式以及 calico的 ipip 方式，本质上是借用node节点上的原本已经存在的网络进行通信，但是由于存在封包以及解包的问题，所以会有一定的性能损耗，类似 overlay 网络
- 直接路由方式，类似 BGP，calico bgp模式只能支持 node 节点同网段使用，跨网段的话，node节点通信需要走路由，然而在 node节点上的路由表上无法同步 k8s 路由表的信息，可以在calico上配置 CrossSubnet 在同网段上使用 bgp，不同网段上走IP-IP模式。

二、pod 和服务之间通信

service 和 pod 之间通信，service 官方定义如下：Kubernetes 中 Service 是将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。

由于 k8s 中 pod 并不是持久的，版本更新等都会导致pod的摧毁与重建，所以需要 servcie 来提供一层抽象。

kube-proxy 是实现 service 的网络代理和负载均衡的关键组件，随着k8s的不断发现kube-proxy 的实现也在不断优化。

userspace 模式：kube-proxy 监听 k8s API 服务器中的 service 和 endpoints （与pod的Readiness Probe关联）的变化，它为每个 service 创建一个监听端口，并将该端口映射到后端pod，任何对这个端口的访问请求，都会被 kube-proxy 捕捉，并在用户空间中转发到后端的pod。实现简单，但是由于每一个数据包都需要经过用户空间所以性能损耗较大。
iptables模式：使用 iptables 规则直接在内核空间处理流量，将请求转发到后端pod，内部实现为链表，只适用于中小规模的k8s集群
ipvs 模式：类似iptables模式，同样基于 Netfilter，但是其底层实现采用的 hash 表，适用于大规模k8s集群。

三、外部和服务间通信

外部访问k8s集群内部的服务主要有以下几种方式，NodePort、Ingress、LoadBalancer（metallb、OpenELB），Service 的 ExternalIP 等几种方式。

Ingress 是最通用的方案之一：

externalIPs：service允许为其分配外部IP，如果外部IP路由到集群中一个或多个Node上，Service会被暴露给这些externalIPs。通过外部IP进入到集群的流量，将会被路由到Service的Endpoint上。
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持。借助第三方的云负载均衡器，将请求分发到所有的Node上，其底层还是NodePort。
NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的端口管理就是个灾难。因为每个端口只能是一种服务，默认端口范围只能是 30000-32767。