url地址如何获取_【转载】Kubernetes Pod 如何获取 IP 地址

ecd20e7d7136058a07e657d43216e3d8.png

在学习 Kubernetes 网络模型的过程中,了解各种网络组件的作用以及如何交互非常重要。本文就介绍了各种网络组件在 Kubernetes 集群中是如何交互的,以及如何帮助每个 Pod 都能获取 IP 地址。

作者:Ronak Nathani

翻译:Bach(才云)

校对:星空下的文仔(才云)、bot(才云)

Kubernetes 网络模型的核心要求之一是每个 Pod 都拥有自己的 IP 地址并可以使用该 IP 地址进行通信。 很多人刚开始使用 Kubernetes 时,还不清楚如何为每个 Pod 分配 IP 地址。 他们了解各种组件如何独立工作,但不清楚这些组件如何组合在一起使用。 例如,他们了解什么是 CNI 插件,但是不知道它们是如何被调用的。 本文就介绍 了各种网络组件 在   Kubernetes 集群中是如何交互的 ,以 及 如何帮助每个 Pod 都 获取 IP 地址。

在 Kubernetes 中有多种网络设置方法,以及 container runtime 的各种选项。这篇文章将使用 Flannel 作为 network provider,并使用 Containered 作为 container runtime。

K8sMeetup

背景概念

容器网络 同一主机上的容器 在同一主机上运行的容器通过 IP 地址相互通信的方法之一是使用 Linux Bridge,即在 Kubernetes(和 Docker)世界中,创建 veth(虚拟以太网)设备。该 veth 设备的一端连接在容器网络命名空间,另一端连接到主机网络上的 Linux Bridge。同一主机上的所有容器都将这 veth pair 的一端连接到 Linux Bridge,它们可以通过 Bridge 使用 IP 地址相互通信。Linux Bridge 也被分配了一个 IP 地址,它充当从目的地到不同节点的 Pod 流出流量的网关。

108ccfd664dbf9388e9d30bfde247d92.png

不同主机上的容器 在不同主机上运行的容器可以通过其 IP 地址相互通信的方式之一是使用数据包封装(packet encapsulation)。Flannel 通过 vxlan 使用该功能,vxlan 将原始数据包封装在 UDP 数据包中并将其发送到目的地。 在 Kubernetes 集群中,Flannel 会在每个节点上创建一个 vxlan 设备和一些路由表。每个发往不同主机上的容器的数据包都会通过 vxlan 设备,并封装在 UDP 数据包中。在目标位置,它会提取封装的数据包,然后将数据包路由到目的地 Pod。

52455ba04fc69776385a2a8da5529e9a.png

注意:这只是配置容器之间网络的方法之一。
CRI CRI(容器运行时接口)是一个插件接口,允许 kubelet 使用不同的 container runtimes。各种 container runtimes 都实现了 CRI API,这使用户可以在 Kubernetes 安装中使用他们想要的 container runtimes。CNI

CNI(容器网络接口)项目包含一个为 Linux 容器提供基于通用插件网络解决方案的规则。它由各种插件组成,这些插件在配置 Pod 网络时执行不同的功能。CNI 插件是遵循 CNI 规范的可执行文件。

K8sMeetup

为节点子网分配 Pod IP 地址

如果要求所有 Pod 具有 IP 地址,那么就要确保整个集群中的所有 Pod 的 IP 地址是唯一的。这可以通过为每个节点分配一个唯一的子网来实现,即从子网中为 Pod 分配节点 IP 地址。

节点 IPAM 控制器 当  nodeipam  传递给 kube-controller-manager 的  --controllers  命令行标志时,它将为每个节点分配来自集群 CIDR(集群网络的 IP 范围)的专用子网(podCIDR)。由于这些 podCIDR 是不相交的子网,因此它可以为每个 Pod 分配唯一的 IP 地址。 当 Kubernetes 节点首次在集群上注册时,会被分配一个 podCIDR。要更改分配给集群中节点的 podCIDR,需要先注销节点,然后使用应用于 Kubernetes 控制平面的任何配置更改来重新注册节点。 podCIDR  可以使用以下命令列出节点的名称: 37d3f84d96f1227735a75b098ddfc5f8.png K8sMeetup

Kubelet、Container Runtime 和 CNI 插件交互

当在节点上调度 Pod 时,一启动 Pod 就会发生很多事情。这里我们仅关注与 Pod 配置网络有关的动态。一旦在节点上调度了 Pod,将配置网络并启动应用程序容器。

84901211673ec9649f6d13511e0ac7e3.png

参考:容器式 cri 插件架构Container Runtime 与 CNI 插件的交互 每个 network provider 都有一个 CNI 插件,container runtime 会调用该插件,在 Pod 启动时配置网络。使用容器化作为 container runtime,容器化 CRI 插件将调用 CNI 插件。每个 network provider 都在每个 Kubernetes 节点上安装了一个代理,以配置 Pod 网络。安装 network provider agent 后,它会随 CNI 一起配置或者在节点上创建,CRI 插件会使用它来确定要调用哪个 CNI 插件。 CNI 配置文件的位置是可配置的,默认值为  /etc/cni/net.d/ 。集群管理员需要在每个节点上交付 CNI 插件。CNI 插件的位置也是可配置的,默认值为  /opt/cni/bin 。 如果使用 containerd 作为 container runtime,则可以在 containerd config 部分下  [plugins."io.containerd.grpc.v1.cri".cni]  指定 CNI 配置和 CNI 插件的路径。 本文中我们将 Flannel 作为 network provider,这里简单介绍一下 Flannel 的设置。Flanneld 是 Flannel 守护程序,通常 install-cni 作为带有初始化容器的守护程序安装在 Kubernetes 集群上。install-cni 容器创建 CNI 配置文件在每个节点上  /etc/cni/net.d/10-flannel.conflist 。Flanneld 创建一个 vxlan 设备,从 apiserver 获取网络元数据,并监控 Pod 上的更新。创建 Pod 时,它将在整个集群中为所有 Pod 分配路由,这些路由允许 Pod 通过 IP 地址相互连接。 Containerd CRI 插件和 CNI 插件之间的交互可以如下所示:

3c07a7baf2d2396876f462c1a2e06960.png

如上所述,kubelet 调用 Containered CRI 插件创建容器,再调用 CNI 插件为容器配置网络。 Network provider CNI 插件调用其他基本 CNI 插件来配置网络。 CNI 插件之间的交互如下所述。 CNI 插件之间的交互 有多种 CNI 插件可帮助配置主机上容器之间的网络,本文主要讨论以下 3 个插件。 Flannel CNI 插件 当使用 Flannel 作为 network provider 时,Containered CRI 插件使用 CNI 配置文件,调用 Flannel CNI 插件 /etc/cni/net.d/10-flannel.conflist

c98056db71e798ae2988b837d863c7f8.png

Fannel CNI 插件与 Flanneld 结合使用,当 Flanneld 启动时,它将从 apiserver 中获取 podCIDR 和其他与网络相关的详细信息,并将它们存储在文件中 /run/flannel/subnet.env

59c71900a885b01e2b8e5b7b10e944ae.png

Flannel CNI 插件使用  /run/flannel/subnet.env  的信息来配置和调用 Bridge CNI 插件。 Bridge CNI 插件 Flannel CNI 插件使用以下配置调用 Bridge CNI 插件:

3741b33c2a5fac890b7f7378bba2ad6d.png

当 Bridge CNI 插件第一次调用时,它会创建一个 Linux Bridge  "name": "cni0"  在配置文件中,然后为每个 Pod 创建 veth pair,其一端在容器的网络命名空间中,另一端连接到主机网络上的 Linux Bridge。使用 Bridge CNI 插件,主机上的所有容器都连接到主机网络上的 Linux Bridge。 配置完 veth pair 后,Bridge 插件将调用主机本地 IPAM CNI 插件。我们可以在 CNI config 中配置要使用的 IPAM 插件,CRI 插件用于调用 Flannel CNI插件。 主机本地 IPAM CNI 插件 Bridge CNI 插件使用以下配置调用主机本地 IPAM CNI 插件:

8b15ad9d6c304d6b44ec3d788da4eea2.png

主机本地 IPAM(IP 地址管理)插件从中返回容器的 IP 地址,subnet将分配的 IP 本地存储在主机下 dataDir 指定的目录中 /var/lib/cni/networks///var/lib/cni/networks// 文件包含 IP 分配到的容器 ID。 调用时,主机本地 IPAM 插件返回以下有效负载: f0d9f6e59e638fd3c3cba6e6f8dff052.png K8sMeetup

总结

Kube-controller-manager 为每个节点分配一个 podCIDR。从 podCIDR 中的子网值为节点上的 Pod 分配了 IP 地址。由于所有节点上的 podCIDR 是不相交的子网,因此它允许为每个 pod 分配唯一的IP地址。

Kubernetes 集群管理员可配置和安装 kubelet、container runtime、network provider,并在每个节点上分发 CNI 插件。Network provider agent 启动时,将生成 CNI 配置。在节点上调度 Pod 后,kubelet 会调用 CRI 插件来创建 Pod。在容器情况下,容器的 CRI 插件调用 CNI 配置中指定的 CNI 插件来配置 Pod 网络。所有这些都会影响 Pod 获取 IP地址。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Kubernetes的网络模型是一种用于在集群中连接和管理容器的方法。Kubernetes提供了一组核心网络概念,例如Pod,Service和Ingress,来帮助管理网络流量和容器间通信。 PodKubernetes中最小的可管理单位,通常由一个或多个容器组成。Pods共享同一网络空间,并且可以在同一个Node上的不同的Pods之间直接通信。 Service是Kubernetes中的逻辑抽象,用于代表一组相关的Pods。Services通过定义一个统一的IP地址和端口,提供了一种简单的方法来访问Pod的群集。 Ingress是一种在Kubernetes集群外部访问应用程序的方法。Ingress定义了应用程序的URL路径和请求路由方式,并且允许将外部请求路由到集群内的合适的Service或PodKubernetes还支持使用多种网络插件,如Calico,Flannel,Cilium等来实现它的网络模型。这些插件可以定义如何在集群中配置网络,以及如何管理网络流量。 总的来说,Kubernetes的网络模型为在集群中的容器间提供了一种简单,高效和可扩展的方法来进行通信。 ### 回答2: Kubernetes的网络模型包括主机网络、Pod网络和服务网络三个方面。 首先,主机网络是指每个Kubernetes节点所连接的物理网络。每个节点上会有一个或多个网络接口,用于与其他节点通信,以及与外部网络进行数据交换。这些接口通常是以太网、无线网络或虚拟网桥等。 其次,Pod网络是指在同一个Kubernetes节点上运行的一组容器共享的虚拟网络。在每一个节点上,Kubernetes创建一个称为容器网络接口(CNI)的软件插件,该插件负责为Pod分配唯一的IP地址、创建虚拟网络和实现跨节点的通信。Pod可以通过直接使用IP地址进行通信,而无需进行任何网络地址转换。 最后,服务网络是一种抽象层,用于为Kubernetes集群中的应用程序提供网络服务的发现和负载均衡功能。Kubernetes中的服务是一组Pod的逻辑分组,并为这些Pod提供一个唯一的DNS名称和虚拟IP地址。当应用程序需要访问服务时,它们可以通过使用该名称和IP地址来进行通信,而无需关心具体的后端Pod在哪个节点上运行。 总的来说,Kubernetes的网络模型通过将主机网络、Pod网络和服务网络紧密结合在一起,为容器化应用程序提供了高度灵活、高度可扩展和高度可靠的网络通信方式。它可以让应用程序之间无缝通信,并实现高效的负载均衡和服务发现。 ### 回答3: Kubernetes的网络模型是指它提供的网络服务和架构。Kubernetes使用的网络模型主要包括了两个重要概念:Pod和Service。 首先,PodKubernetes中最基本的运行单元,它由一个或多个紧密关联的容器组成,这些容器共享相同的IP地址和网络命名空间。每个Pod都有独立的IP地址,并且可以在集群中的任意节点上运行。Pod内的容器可以通过localhost进行通信,可以实现容器之间的高效通信。 其次,Kubernetes提供了Service来实现对外部网络的访问。Service是一组Pod的逻辑分组,它们可以被集群内外的其他服务访问。Service会为这些Pod分配一个虚拟IP地址,这个虚拟IP地址可以用作其他服务或终端用户与Pod进行通信的入口点。在这个过程中,Service会根据一定的负载均衡算法将请求路由到相应的Pod上。 Kubernetes的网络模型还采用了一种称为CNI(Container Network Interface)的标准,它定义了容器和主机之间的网络接口和驱动。Kubernetes集群中的每个节点都有一个CNI插件来管理网络,这些插件可以实现不同的网络方案,如自定义网络、软件定义网络等。CNI插件可以与底层网络设备进行通信,以确保Pod和Service之间的网络正常工作。 总结来说,Kubernetes的网络模型通过使用Pod和Service等概念,以及CNI插件来实现容器之间和容器与外部网络之间的通信。这个模型能够提供灵活、可扩展和高性能的网络服务,为Kubernetes集群中的应用程序提供可靠的网络支持。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值