Kubenetes的服务、负载均衡和联网

最新推荐文章于 2023-06-08 12:32:47 发布

长安故里

最新推荐文章于 2023-06-08 12:32:47 发布

阅读量166

点赞数

分类专栏： Kubernetes 文章标签：负载均衡 kubernetes docker linux

本文链接：https://blog.csdn.net/lsx_3/article/details/124986920

版权

Kubernetes 专栏收录该内容

12 篇文章 2 订阅

订阅专栏

服务、负载均衡和联网

Kubernetes 网络模型

在集群中，每一个的Pod都有自己的IP地址，从单纯的端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来说，Pod完全可以被视为一个独立的虚拟机或者是物理主机。
Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）：

节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信
运行在节点主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信

Kubernetes 网络解决四方面的问题：

一个 Pod 中的容器之间通过本地回路（loopback）通信。
集群网络在不同 pod 之间提供通信。
Service 资源允许你对外暴露 Pods 中运行的应用程序，以支持来自于集群外部的访问。
可以使用 Services 来发布仅供集群内部使用的服务。

Service

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。

使用场景

当Kubenetes创建或者销毁Pod时，以匹配集群状态的时候，因为Pod是一个非永久性的资源，被销毁或者重构的几率特别大，在销毁或者重构之后，之前属于它的IP地址就会发生变化，如果你一直使用Pod的自身的IP地址，那么很容易的就会发生网络不可达的情况。
比如如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？

Service资源

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 Service 所针对的 Pods 集合通常是通过选择算符来确定的。
举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。然而组成这一组后端程序的 Pod 实际上可能会发生变化，前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。

使用Service

Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。像所有的 REST 对象一样，Service 定义可以基于 POST 方式，请求 API server 创建新的实例。
假如有一组Pod，对外暴露了9376的端口，并且自带了app=myapp的标签

apiVersion: v1
kind: Service
metadata:
  name: my-service			# 创建的Service的名字
spec:
  selector:
    app: myapp					# 它将匹配Pod所带的标签
  ports:								# Pod的端口信息和service的端口信息及协议
    - protocol: TCP
      port: 80
      targetPort: 9376

当创建出这个Service资源的时候，集群会自动分配其一个IP地址，并且这个Service将自动和带有app=myapp的Pod进行绑定，也就是如果你想访问Pod的9376的端口，你则可以使用Service这个IP+端口进行访问，这样的优势在于无论你的Pod经过销毁或者重构，只要标签没有改变，那么Service就会一直存在。同时也提供和相关的负载均衡，在多个带有相同的标签的Pod共同绑定一个Servcie时，则会根据算法自动访问其中一个。

虚拟 IP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

userspace 代理模式

这种模式，kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到 Service 的后端 Pods 中的某个上面（如 Endpoints 所报告的一样）。使用哪个后端 Pod，是 kube-proxy 基于 SessionAffinity 来确定的。

最后，它配置 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。

默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。在这里插入图片描述

iptables 代理模式

这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。

默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。

你可以使用 Pod 就绪探测器验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
在这里插入图片描述

IPVS 代理模式

在 ipvs 模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 netlink 接口相应地创建 IPVS 规则，并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。

IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是：