k8s 网络模型( 四 ) _负载

对于类型的，k8s集群中的每个Node都会打开一个端口（所有Node上的端口相同），并将该端口上收到的流量重定向到具体的。
对于类型的，我们可以通过任何Node的ip和端口号来访问服务。
创建类型的服务：
image.png
如下图，服务暴露在两个节点的端口30123上，到达任何一个端口的链接会被重定向到一个随机选择的Pod 。
image.png
如何做到的？
是靠kube-proxy服务通过的nat转换功能实现的，kube-proxy会在运行过程中动态创建与相关的规则，这些规则实现了的请求流量重定向到kube-proxy进程上对应的的代理端口上。
kube-proxy接受到的请求访问后，会从对应的后端Pod中选择一个进行访问（RR）
但还没有完全解决外部访问的所有问题，比如负载均衡问题，假如我们的集群中有 10 个 Node，则此时最好有一个负载均衡器，外部的请求只需访问此负载均衡器的 IP 地址，由负载均衡器负责转发流量到后面某个 Node 的上
5.2.2 第四层流量入口：
该方式是方式的扩展，这使得可以通过一个专用的负载均衡器来访问，这个是由具体云服务提供商来提供的，负载均衡器将流量重定向到所有节点的端口上，如果云提供商不支持负载均衡，则退化为类型
创建k8s 时，可以选择指定。的实现由云控制器提供，该控制器知道如何为您的创建负载均衡器。创建后，它将公布负载均衡器的IP地址。作为最终用户，可以开始将流量定向到负载均衡器以开始与提供的进行通信。
创建一个负载均衡服务：
image.png
借助AWS，负载均衡器可以识别其目标组中的Node，并将平衡群集中所有节点的流量。一旦流量到达Node，之前在整个群集中为安装的规则将确保流量到达感兴趣的的Pod上。
下面看下到的一个数据包的流转过程：
image
上图显示了承载Pod的三个Node前面的网络负载平衡器。首先流量被传到的的负载均衡器（1）。一旦负载均衡器收到数据包（2），它就会随机选择一个VM 。这里我们故意选择了没有Pod运行的node：node 2 。在这里，node上运行的规则将使用kube-proxy安装在集群中的内部负载平衡规则将数据包定向到正确的Node 中的Pod 。执行正确的NAT并将数据包转发到正确的Pod（4）。
需要注意的是每个服务需要创建自己独有的负载均衡器，下面要讲解的一种方式所有服务只需要一个公开服务。
5.2.3 第七层流量入口：
这是一个与上面提到的两种方式完全不同的机制，通过一个公开的ip地址来公开多个服务，第7层网络流量入口是在网络堆栈的HTTP / HTTPS协议范围内运行，并建立在之上。
image.png
如上图，不像负载均衡器每个服务需要一个公开ip,所有服务只需要一个公网ip,当客户端向发送http请求时候，会根据请求的主机名和路径决定请求转发到那个服务。
创建资源：
image.png
如上定义了一个单一规则的,确保控制器接受的所有请求主机的http请求被发送到端口80上的kubia-服务上。
工作原理：
如下图，客户端首先对执行DNS查找，DNS服务器返回控制器的IP，客户端拿到IP后，向控制器发送Http请求，并在Host投中指定。控制器接受到请求后从Host头部就知道该访问那个服务，通过与该关联的对象查询Pod ip,并将请求转发到某一个Pod 。
这里并没把请求转发给，而是自己选择一个一个Pod来访问。
image.png
【k8s 网络模型】第7层负载均衡器的一个好处是它们具有HTTP感知能力，因此它们了解URL和路径。这允许您按URL路径细分服务流量。它们通常还在HTTP请求的X--For标头中提供原始客户端的IP地址。