云计算·大数据 频道

Kubernetes网络的可视化指南

  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通过使用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网络还有另一面,那就是将应用程序暴露于外部网络。

  你可以通过两种不同的方式将应用程序公开给外部网络。

  出口:当你想要将流量从Kubernetes服务路由到Internet时,请使用此选项。在这种情况下,iptables执行源NAT,因此流量似乎来自节点,而不是Pod。

  入口:这是从外部世界到服务的传入流量。入口还允许并阻止使用连接规则与服务进行的特定通信。通常,有两种入口解决方案在不同的网络堆栈区域上运行:服务负载均衡器和入口控制器。

  发现服务

  Kubernetes发现服务有两种方式:

  环境变量:在Pod运行的节点上运行的kubelet服务负责以{SVCNAME}\u service\u HOST和{SVCNAME}\u service\u PORT的格式为每个活动服务设置环境变量。你必须在客户端Pod出现之前创建服务。否则,这些客户端Pod将不会填充其环境变量。

  DNS:DNS服务实现为Kubernetes服务,映射到一个或多个DNS服务器Pod,这些Pod与任何其他Pod一样进行调度。集群中的Pod配置为使用DNS服务,DNS搜索列表包括Pod自己的命名空间和集群的默认域。集群感知DNS服务器(如CoreDNS)监视Kubernetes API以获取新服务,并为每个服务创建一组DNS记录。如果在整个集群中启用了DNS,则所有Pod都可以根据其DNS名称自动解析服务。Kubernetes DNS服务器是访问ExternalName服务的唯一方式。

  发布服务的ServiceTypes:

  Kubernetes服务提供了一种访问一组Pod的方法,通常通过使用标签选择器来定义。这可能是应用程序试图访问集群中的其他应用程序,也可能允许你将集群中运行的应用程序公开给外部世界。Kubernetes ServiceTypes允许你指定所需的服务类型。

  不同的ServiceTypes包括:

  ClusterIP:这是默认的ServiceType。它使服务只能从集群内访问,并允许集群内的应用程序相互通信。没有外部访问。

  LoadBalancer:此服务类型使用云提供商的负载均衡器对外公开服务。来自外部负载均衡器的流量被定向到后端POD。云提供商决定如何实现负载均衡。

  NodePort:这允许外部通信通过在所有节点上打开特定端口来访问服务。然后,发送到此端口的任何流量都会转发到该服务。

  ExternalName:这种类型的服务使用ExternalName字段的内容,通过返回CNAME记录及其值,将服务映射到DNS名称。未设置任何类型的代理。

  网络软件

  只要你了解所使用的技术,Kubernetes内部的网络与物理世界中的网络没有太大区别。好好学习,记住网络基础知识,就可以轻松实现容器、Pod和服务之间的通信。

0
相关文章