Kubernetes网络的可视化指南

导读 Kubernetes内部的网络与物理世界没有太大区别。有了网络的基础知识,你就可以轻松实现container Pod和services之间的通信。从使用交换机

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

从使用交换机、路由器和以太网电缆的物理网络迁移到使用软件定义网络(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的网络

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

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

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

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

3354然后,流量到达连接到veth1到veth0的虚拟桥。

3354流量通过虚拟桥到达veth1。

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

Pod到服务网络

Pod很有活力。它们可能需要根据需求放大或缩小。在应用程序崩溃或节点故障的情况下,可以重新创建它们。这些事件会导致Pod的IP地址发生变化,给组网带来挑战。

Kubernetes通过使用服务函数解决了这个问题,该函数执行以下操作:

在前端分配一个静态虚拟IP地址,以连接到与服务相关联的任何后端pod。

将发往此虚拟IP的所有流量平衡到后端Pod集。

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

集群中有两种负载平衡方式:

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

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

图中显示了从Pod 1到Pod 3通过服务到达不同节点的数据包流(用红色标记)。去往虚拟网桥的数据包必须使用默认路由(eth0 ),因为网桥上运行的ARP无法理解该服务。后来

,包必须通过iptables进行过滤,iptables使用kube代理在节点中定义的规则。因此,该图显示了当前的路径。

  Internet到服务的网络

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

  

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

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

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

  发现服务

  Kubernetes发现服务有两种方式:

  环境变量:在Pod运行的节点上运行的kubelet服务负责以{SVCNAME}u serviceu HOST和{SVCNAME}u serviceu 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和服务之间的通信。

免责声明:本文由用户上传,如有侵权请联系删除!

猜你喜欢

最新文章