Kubernetes-基于flannel的集群网络

本文深入解析Docker的多种网络模式,包括bridge、host、none、overlay、macvlan和Networkplugins,以及它们的工作原理。同时,详细阐述Kubernetes如何解决容器间通信、Pod与Pod、Pod与服务及外部应用与服务的通信问题,特别是flannel网络插件在Kubernetes中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、Docker网络模式

在讨论Kubernetes网络之前,让我们先来看一下Docker网络。Docker采用插件化的网络模式,默认提供bridge、host、none、overlay、maclan和Network plugins这几种网络模式,运行容器时可以通过–network参数设置具体使用那一种模式。

  • bridge:这是Docker默认的网络驱动,此模式会为每一个容器分配Network Namespace和设置IP等,并将容器连接到一个虚拟网桥上。如果未指定网络驱动,这默认使用此驱动。
  • host:此网络驱动直接使用宿主机的网络。
  • none:此驱动不构造网络环境。采用了none 网络驱动,那么就只能使用loopback网络设备,容器只能使用127.0.0.1的本机网络。
  • overlay:此网络驱动可以使多个Docker daemons连接在一起,并能够使用swarm服务之间进行通讯。也可以使用overlay网络进行swarm服务和容器之间、容器之间进行通讯,
  • macvlan:此网络允许为容器指定一个MAC地址,允许容器作为网络中的物理设备,这样Docker daemon就可以通过MAC地址进行访问的路由。对于希望直接连接网络网络的遗留应用,这种网络驱动有时可能是最好的选择。
  • Network plugins:可以安装和使用第三方的网络插件。可以在Docker Store或第三方供应商处获取这些插件。

在默认情况,Docker使用bridge网络模式,bridge网络驱动的示意图如下,此文以bridge模式对Docker的网络进行说明。

1.1 bridge网络的构建过程如下:

1)安装Docker时,创建一个名为docke0的虚拟网桥,虚拟网桥使用“10.0.0.0 -10.255.255.255 “、”172.16.0.0-172.31.255.255″和“192.168.0.0——192.168.255.255”这三个私有网络的地址范围。

通过 ifconfig 命令可以查看docker0网桥的信息:

通过 docker network inspect bridge 可以查看网桥的子网网络范围和网关:

2)运行容器时,在宿主机上创建虚拟网卡veth pair设备,veth pair设备是成对出现的,从而组成一个数据通道,数据从一个设备进入,就会从另一个设备出来。将veth pair设备的一端放在新创建的容器中,命名为eth0;另一端放在宿主机的docker0中,以veth为前缀的名字命名。通过 brctl show 命令查看放在docker0中的veth pair设备

1.2 外部访问

bridge的docker0是虚拟出来的网桥,因此无法被外部的网络访问。因此需要在运行容器时通过-p和-P参数对将容器的端口映射到宿主机的端口。实际上Docker是采用 NAT的 方式,将容器内部的服务监听端口与宿主机的某一个端口port 进行绑定,使得宿主机外部可以将网络报文发送至容器。

1)通过-P参数,将容器的端口映射到宿主机的随机端口:

$ docker run -P {images}

2)通过-p参数,将容器的端口映射到宿主机的制定端口:

$ docker run -p {hostPort}:{containerPort} {images}

2、Kubernetes网络模式

Kubernetes与Docker网络有些不同。Kubernetes网络需要解决下面的4个问题:

  • 集群内:
    • 容器与容器之间的通信
    • Pod和Pod之间的通信
    • Pod和服务之间的通信
  • 集群外:
    • 外部应用与服务之间的通信

因此,Kubernetes假设Pod之间能够进行通讯,这些Pod可能部署在不同的宿主机上。每一个Pod都拥有自己的IP地址,因此能够将Pod看作为物理主机或者虚拟机,从而能实现端口设置、命名、服务发现、负载均衡、应用配置和迁移。为了满足上述需求,则需要通过集群网络来实现。

在本文主要分析容器与容器之间,以及Pod和Pod之间的通信;Pod和服务之间,以及外部应用与服务之间的通信请参考《Kubernetes-核心资源之Service》和《Kubernetes-核心资源之Ingress》。

2.1 同一个Pod中容器之间的通信

这种场景对于Kubernetes来说没有任何问题,根据Kubernetes的架构设计。Kubernetes创建Pod时,首先会创建一个pause容器,为Pod指派一个唯一的IP地址。然后,以pause的网络命名空间为基础,创建同一个Pod内的其它容器(–net=container:xxx)。因此,同一个Pod内的所有容器就会共享同一个网络命名空间,在同一个Pod之间的容器可以直接使用localhost进行通信。

2.2 不同Pod中容器之间的通信

对于此场景,情况现对比较复杂一些,这就需要解决Pod间的通信问题。在Kubernetes通过flannel、calic等网络插件解决Pod间的通信问题。本文以flannel为例说明在Kubernetes中网络模型,flannel是kubernetes默认提供网络插件。Flannel是由CoreOs团队开发社交的网络工具,CoreOS团队采用L3 Overlay模式设计flannel, 规定宿主机下各个Pod属于同一个子网,不同宿主机下的Pod属于不同的子网。

flannel会在每一个宿主机上运行名为flanneld代理,其负责为宿主机预先分配一个子网,并为Pod分配IP地址。Flannel使用Kubernetes或etcd来存储网络配置、分配的子网和主机公共IP等信息。数据包则通过VXLAN、UDP或host-gw这些类型的后端机制进行转发。

看一下flannel在Kubernetes中运行的整体过程:

1)设置集群网络

flannel默认使用etcd作为配置和协调中心,首先使用etcd设置集群的整体网络。通过如下的命令能够查询网络配置信息:

$ etcdctl ls /coreos.com/network/config

2)设置Node节点上的子网

基于在etcd中设置的网络,flannel为每一个Node分配IP子网。

#获取子网列表

$ etcdctl ls /coreos.com/network/subnets

#获取子网信息

$ etcdctl ls /coreos.com/network/subnets/{IP网段}

3)在每个Node上启动flannelid

flannel在每个Node上启动了一个flanneld的服务,在flanneld启动后,将从etcd中读取配置信息,并请求获取子网的租约。所有Node上的flanneld都依赖etcd cluster来做集中配置服务,etcd保证了所有node上flanned所看到的配置是一致的。同时每个node上的flanned监听etcd上的数据变化,实时感知集群中node的变化。flanneld一旦获取子网租约、配置后端后,会将一些信息写入/run/flannel/subnet.env文件。

$ cat /var/run/flannel/subnet.env

4)创建虚拟网卡

在Node节点上,会创建一个名为flannel.1的虚拟网卡。

$ ip addr show flannel.1

5)创建Docker网桥

并为容器配置名为docker0的网桥,实际是通过修改Docker的启动参数–bip来实现的。通过这种方式,为每个节点的Docker0网桥设置在整个集群范围内唯一的网段,从保证创建出来的Pod的IP地址是唯一。

$ ip addr show docker0

6)修改路由表

flannel会对路由表进行修改,从而能够实现容器跨主机的通信。

$ route -n

2.3 数据传递过程

在源容器宿主机中的数据传递过程:

1)源容器向目标容器发送数据,数据首先发送给docker0网桥

在源容器内容查看路由信息:

$ kubectl exec -it -p {Podid} -c {ContainerId} -- ip route

2)docker0网桥接受到数据后,将其转交给flannel.1虚拟网卡处理

docker0收到数据包后,docker0的内核栈处理程序会读取这个数据包的目标地址,根据目标地址将数据包发送给下一个路由节点:

查看源容器所在Node的路由信息:

$ ip route

3)flannel.1接受到数据后,对数据进行封装,并发给宿主机的eth0

flannel.1收到数据后,flannelid会将数据包封装成二层以太包。

Ethernet Header的信息:

  • From:{源容器flannel.1虚拟网卡的MAC地址}
  • To:{目录容器flannel.1虚拟网卡的MAC地址}

4)对在flannel路由节点封装后的数据,进行再封装后,转发给目标容器Node的eth0

由于目前的数据包只是vxlan tunnel上的数据包,因此还不能在物理网络上进行传输。因此,需要将上述数据包再次进行封装,才能源容器节点传输到目标容器节点,这项工作在由linux内核来完成。

Ethernet Header的信息:

  • From:{源容器Node节点网卡的MAC地址}
  • To:{目录容器Node节点网卡的MAC地址}

IP Header的信息:

  • From:{源容器Node节点网卡的IP地址}
  • To:{目录容器Node节点网卡的IP地址}

通过此次封装,就可以通过物理网络发送数据包。

在目标容器宿主机中的数据传递过程:

5)目标容器宿主机的eth0接收到数据后,对数据包进行拆封,并转发给flannel.1虚拟网卡;

6)flannel.1 虚拟网卡接受到数据,将数据发送给docker0网桥;

7)最后,数据到达目标容器,完成容器之间的数据通信。

 

参考资料

1.《Cluster Networking》地址:https://kubernetes.io/docs/concepts/cluster-administration/networking/

2.《Running flannel》地址:https://github.com/coreos/flannel/blob/master/Documentation/running.md

3.《理解Kubernetes网络之Flannel网络》 作者:Tony Bai 地址:https://tonybai.com/2017/01/17/understanding-flannel-network-for-kubernetes/

作者简介:
季向远,北京神舟航天软件技术有限公司产品经理。本文版权归原作者所有。

转载于:https://www.cnblogs.com/felixzh/p/9765391.html

<think>我们正在处理用户关于使用Helm安装Cilium v1.14.0时缺少参数的问题。根据用户提供的错误信息和引用内容,我们可以推断用户可能在使用较新版本的Cilium(如v1.15)时遇到了问题,但用户现在指定要安装的是v1.14.0。然而,用户的问题描述中提到了一个错误,该错误指出在v1.15中移除了tunnel参数,因此我们需要确保在安装v1.14.0时正确设置参数以避免将来升级的问题。 根据用户提供的引用[1],我们可以使用cilium-cli来获取之前的配置并重新安装。但是,用户现在的问题是使用Helm安装,并且询问缺少哪些参数。 用户之前遇到的错误是: Error: INSTALLATION FAILED: execution error at (cilium/templates/validate.yaml:41:5): tunnel was deprecated in v1.14 and has been removed in v1.15. 这个错误出现在v1.15的安装中,但用户现在指定安装v1.14.0。因此,在v1.14.0中,tunnel参数仍然可用,但已被标记为废弃。所以,在安装v1.14.0时,我们可以继续使用tunnel参数,但建议开始迁移到新的参数。 然而,用户的问题是:“Helm install Cilium cilium/cilium version 1.14.0 namespace kube-system missing parameters”,即在使用Helm安装Cilium 1.14.0时缺少哪些参数? 实际上,Cilium的安装需要一些必要的配置参数,这些参数取决于用户的集群环境。常见的必要参数包括: 1. 网络相关参数:如Pod CIDR、Service CIDR等。 2. 路由模式:tunnel(vxlan或geneve)或直接路由(native)等。 3. 其他特性:如kube-proxy替换、负载均衡模式等。 但是,根据错误信息,我们知道在v1.14中tunnel参数已被废弃,因此即使我们使用v1.14,也应该避免使用tunnel参数,而使用新的参数配置。 在v1.14中,新的参数是: - `routingMode`:替代tunnel参数,可选值有`tunnel`、`native`、`disabled`(其中`disabled`用于BPF主机路由模式)。 - `ipv4NativeRoutingCIDR`:当使用`routingMode=native`时,必须设置此参数为集群的Pod CIDR。 因此,在安装v1.14.0时,我们应使用新的参数,以避免将来升级到v1.15时出现问题。 所以,用户在使用Helm安装v1.14.0时,应该使用新的参数,而不是废弃的tunnel参数。 下面是一个示例的Helm命令,使用新的参数安装Cilium v1.14.0: ```bash helm install cilium cilium/cilium --version 1.14.0 \ --namespace kube-system \ --set routingMode=native \ --set ipv4NativeRoutingCIDR=10.0.0.0/8 # 请替换为你的集群Pod CIDR ``` 或者使用values文件: ```yaml # values.yaml routingMode: native ipv4NativeRoutingCIDR: 10.0.0.0/8 ``` 然后运行: ```bash helm install cilium cilium/cilium --version 1.14.0 -f values.yaml -n kube-system ``` 注意:`ipv4NativeRoutingCIDR`必须设置为集群的Pod CIDR,这样Cilium才能知道哪些IP是本地路由的。 如果用户之前使用的是tunnel模式,那么可以这样设置: ```yaml routingMode: tunnel tunnelProtocol: vxlan # 或者geneve ``` 另外,根据引用[1],如果用户之前已经安装过Cilium,可以通过获取保存的配置来重新安装。但是,用户现在的问题是关于缺少参数,所以我们需要确保在安装时提供必要的参数。 总结:在安装Cilium v1.14.0时,必须设置`routingMode`和(如果是native模式)`ipv4NativeRoutingCIDR`参数,以替代废弃的`tunnel`参数。 现在,我们来回答用户的问题:在使用Helm安装Cilium v1.14.0时,缺少的参数是`routingMode`和(如果使用native模式)`ipv4NativeRoutingCIDR`。用户需要根据自己集群网络模式选择设置这些参数。 同时,我们也可以参考引用[3]中关于Cilium安全可见性的内容,但这不是安装所必需的。 因此,回答如下:</think>### 使用 Helm 安装 Cilium v1.14.0 的必要参数配置 在安装 Cilium v1.14.0 时,核心参数已从 `tunnel` 迁移到新的路由模式配置。以下是完整参数指南(基于 Cilium 官方文档和最佳实践[^1][^3]): #### 1. **核心网络参数(必须配置)** ```yaml # 路由模式 (替代废弃的 tunnel 参数) routingMode: native # 可选值: native, tunnel, disabled # 当使用 native 模式时必须设置 ipv4NativeRoutingCIDR: "10.0.0.0/8" # 替换为您的集群 Pod CIDR # IPAM 模式 ipam: mode: kubernetes # 或 cluster-pool, azure, etc ``` #### 2. **完整 Helm 安装命令** ```bash helm install cilium cilium/cilium --version 1.14.0 \ --namespace kube-system \ --set routingMode=native \ --set ipv4NativeRoutingCIDR="10.0.0.0/8" \ --set ipam.mode=kubernetes \ --set kubeProxyReplacement=strict \ --set bpf.masquerade=true ``` #### 3. **关键参数说明表 | 参数 | 必需 | 默认值 | 说明 | |------|------|--------|------| | **`routingMode`** | 是 | - | 替换废弃的 `tunnel` 参数,定义路由机制 | | **`ipv4NativeRoutingCIDR`** | 当 `routingMode=native` | - | 集群的 Pod IP CIDR 范围 | | `ipam.mode` | 是 | `cluster-pool` | IP 地址分配机制 | | `kubeProxyReplacement` | 推荐 | `disabled` | 启用 eBPF 替代 kube-proxy | | `bpf.masquerade` | 推荐 | `false` | 启用 IP 伪装 | #### 4. **验证配置保存(升级时关键步骤) ```bash # 获取历史配置(如存在) kubectl -n kube-system get secret/cilium-cli-helm-values -o yaml > cilium-values.yaml # 使用保存的配置安装 cilium install \ --helm-values cilium-values.yaml \ --version v1.14.0 \ --context kubernetes-admin@kubernetes ``` #### 5. **服务账户配置(可选但推荐) ```yaml # 创建服务账户(用于安全策略) apiVersion: v1 kind: ServiceAccount metadata: name: cilium-sa namespace: kube-system ``` ```bash kubectl create serviceaccount cilium-sa -n kube-system ``` > **重要提示**:在 v1.14 中 `tunnel` 参数已被废弃,必须使用 `routingMode` 替代。安装后可通过 `cilium status` 验证路由模式[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值