Kubernetes 网络的可视化指南

Kubernetes 内部的网络与物理世界中的网络没有太大区别。有了网络基础知识,你就可以轻松实现容器 Pod 和服务之间的
摘要

Kubernetes 内部的网络与物理世界中的网络没有太大区别。有了网络基础知识,你就可以轻松实现容器 Pod 和服务之间的通信。

从使用交换机、路由器和以太网电缆的物理网络转移到使用软件定义网络 ( SDN ) 和虚拟接口的虚拟网络需要一段轻微的学习曲线。当然,原则保持不变,但有不同的规范和最佳实践。Kubernetes 有自己的一套规则,如果你处理的是容器和云,这有助于了解 Kubernetes 网络是如何工作的。

Kubernetes 网络模型有一些需要记住的一般规则:

每个 pod 都有自己的 IP 地址:不需要在 Pod 之间创建链接,也不需要将容器端口映射到主机端口。

不需要 NAT:节点上的 Pod 应该能够与没有 NAT 的所有节点上的所有 Pod 通信。

代理获得所有访问权限:节点 ( 系统守护进程、Kubelet ) 上的代理可以与该节点中的所有 Pod 通信。

共享命名空间:Pod 中的容器共享网络命名空间 ( IP 和 MAC 地址 ) ,因此它们可以使用环回地址相互通信。

Kubernetes 网络解决了什么问题

Kubernetes 网络旨在确保 Kubernetes 中的不同实体类型可以通信。Kubernetes 基础设施的布局在设计上有很多分离。命名空间、容器和 Pod 旨在保持组件彼此不同,因此高度结构化的通信计划非常重要。

容器到容器的网络

容器到容器的网络通过 Pod 网络命名空间进行。网络命名空间允许你拥有独立的网络接口和路由表,这些接口和路由表与系统的其余部分隔离并独立运行。每个 Pod 都有自己的网络命名空间,其中的容器共享相同的 IP 地址和端口。这些容器之间的所有通信都是通过 localhost 进行的,因为它们都是同一命名空间的一部分。 ( 由图中的绿线表示。 )

Pod 到 Pod 的网络

对于 Kubernetes,每个节点都有一个指定的用于 Pod 的 CIDR IP 范围。这确保每个 Pod 都能收到集群中其他 Pod 可以看到的唯一 IP 地址。创建新 Pod 时,IP 地址从不重叠。与容器到容器的网络不同,Pod 到 Pod 的通信使用真实的 IP 进行,无论你是将 Pod 部署在同一节点上还是集群中的不同节点上。

上图显示,为了使 Pod 相互通信,流量必须在 Pod 网络命名空间和根网络命名空间之间流动。这是通过虚拟以太网设备或 veth 对 ( 图中 veth0 到 Pod 命名空间 1,veth1 到 Pod 命名空间 2 ) 连接 Pod 命名空间和根命名空间来实现的。虚拟网桥连接这些虚拟接口,允许通信使用地址解析协议 ( ARP ) 在它们之间流动。

当数据从 Pod 1 发送到 Pod 2 时,事件流为:

—— Pod 1 流量通过 eth0 流向根网络命名空间的虚拟接口 veth0。

——然后,流量通过 veth0 到达连接到 veth1 的虚拟网桥。

——流量通过虚拟网桥到达 veth1。

——最后,流量通过 veth1 到达 Pod 2 的 eth0 接口。

Pod 到服务的网络

Pod 很动态。它们可能需要根据需求扩大或缩小规模。在应用程序崩溃或节点故障的情况下,可以再次创建它们。这些事件会导致 Pod 的 IP 地址发生变化,这将给联网带来挑战。

Kubernetes 网络的可视化指南

Kubernetes 通过使用 Service 功能来解决此问题,该功能执行以下操作:

在前端分配静态虚拟 IP 地址,以连接与服务关联的任何后端吊舱。

负载将寻址到此虚拟 IP 的所有流量平衡到后端 Pod 集。

跟踪 Pod 的 IP 地址,这样即使 Pod IP 地址更改,客户端也不会有任何问题,因为它们只直接连接到服务本身的静态虚拟 IP 地址。

集群内负载均衡有两种方式:

IPTABLES:在这种模式下,kube-proxy 监视 API 服务器中的更改。对于每个新服务,它都会安装 iptables 规则,这些规则将流量捕获到 Service 的 clusterIP 和端口,然后将流量重定向到服务的后端 Pod。Pod 是随机选择的。此模式可靠,系统开销较低,因为 Linux Netfilter 处理流量时不需要在用户空间和内核空间之间切换。

IPV:IPV 构建在 Netfilter 之上,并实现传输层负载均衡。IPVS 使用 Netfilter 钩子函数,使用哈希表作为底层数据结构,并在内核空间中工作。这意味着 IPVS 模式下的 kube 代理比 iptables 模式下的 kube 代理具有更低的延迟、更高的吞吐量和更好的性能来重定向流量。

上图显示了从 Pod 1 到 Pod 3 的包流通过 Service 到不同节点 ( 以红色标记 ) 。前往虚拟网桥的包必须使用默认路由 ( eth0 ) ,因为网桥上运行的 ARP 无法理解该服务。之后,包必须通过 iptables 进行过滤,iptables 使用 kube 代理在节点中定义的规则。因此,该图显示了当前的路径。

Internet 到服务的网络

到目前为止,已经讨论了如何在集群内路由流量。然而,Kubernetes 网络还有另一面,那就是将应用程序暴露于外部网络。