在学习 Kubernetes 网络模型的过程中,了解各种网络组件的作用以及如何交互非常重要。本文就介绍了各种网络组件在 Kubernetes 集群中是如何交互的,以及如何帮助每个 Pod 都能获取 IP 地址。 Kubernetes 网络模型的核心要求之一是每个 Pod 都拥有自己的 IP 地址并可以使用该 IP 地址进行通信。很多人刚开始使用 Kubernetes 时,还不清楚如何为每个 Pod 分配 IP 地址。他们了解各种组件如何独立工作,但不清楚这些组件如何组合在一起使用。例如,他们了解什么是 CNI 插件,但是不知道它们是如何被调用的。本文就介绍了各种网络组件在 Kubernetes 集群中是如何交互的,以及如何帮助每个 Pod 都获取 IP 地址。 在 Kubernetes 中有多种网络设置方法,以及 container runtime 的各种选项。这篇文章将使用 Flannel 作为 network provider,并使用 Containered 作为 container runtime。
背景概念
容器网络 同一主机上的容器 在同一主机上运行的容器通过 IP 地址相互通信的方法之一是使用 Linux Bridge,即在 Kubernetes(和 Docker)世界中,创建 veth(虚拟以太网)设备。该 veth 设备的一端连接在容器网络命名空间,另一端连接到主机网络上的 Linux Bridge。同一主机上的所有容器都将这 veth pair 的一端连接到 Linux Bridge,它们可以通过 Bridge 使用 IP 地址相互通信。Linux Bridge 也被分配了一个 IP 地址,它充当从目的地到不同节点的 Pod 流出流量的网关。
如果要求所有 Pod 具有 IP 地址,那么就要确保整个集群中的所有 Pod 的 IP 地址是唯一的。这可以通过为每个节点分配一个唯一的子网来实现,即从子网中为 Pod 分配节点 IP 地址。 节点 IPAM 控制器 当 nodeipam 传递给 kube-controller-manager 的 --controllers 命令行标志时,它将为每个节点分配来自集群 CIDR(集群网络的 IP 范围)的专用子网(podCIDR)。由于这些 podCIDR 是不相交的子网,因此它可以为每个 Pod 分配唯一的 IP 地址。 当 Kubernetes 节点首次在集群上注册时,会被分配一个 podCIDR。要更改分配给集群中节点的 podCIDR,需要先注销节点,然后使用应用于 Kubernetes 控制平面的任何配置更改来重新注册节点。podCIDR 可以使用以下命令列出节点的名称:
Kubelet、Container Runtime 和 CNI 插件交互
当在节点上调度 Pod 时,一启动 Pod 就会发生很多事情。这里我们仅关注与 Pod 配置网络有关的动态。一旦在节点上调度了 Pod,将配置网络并启动应用程序容器。
主机本地 IPAM(IP 地址管理)插件从中返回容器的 IP 地址,subnet将分配的 IP 本地存储在主机下dataDir指定的目录中/var/lib/cni/networks/<network-name=cni0>/<ip>。/var/lib/cni/networks/<network-name=cni0>/<ip>文件包含 IP 分配到的容器 ID。 调用时,主机本地 IPAM 插件返回以下有效负载:
总结
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地址。