k8sserviceuserspaceiptablesipvs默认算法

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

1.1 为什么要使用service

　　Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过 ReplicationController 能够动态地创建和销毁 Pod（例如，需要进行扩缩容，或者执行 滚动升级）。 每个 Pod 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？答案是：Service。

 

1.2 service介绍

　　Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector（下面我们会讲到我们为什么需要一个没有label selector的服务）实现的。

　　举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。 然而组成这一组 backend 程序的 Pod 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。 Service 定义的抽象能够解耦这种关联。

　　对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod 发生变更，应用程序就会被更新。 对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 Service，再由 Service 重定向到 backend Pod。

 

1.3 三种代理模式

  •  userspace 代理模式（K8S 1.1之前版本）

  •  iptables 代理模式（K8S 1.10之前版本）

  •  ipvs 代理模式（K8S 1.11 之后版本，激活ipvs需要修改配置）

1.3.1 userspace 代理模式

　　这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。 任何连接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的某个上面（如 Endpoints 所报告的一样）。 使用哪个 backend Pod，是基于 Service 的 SessionAffinity 来确定的。 最后，它安装 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到 backend Pod。

　　网络返回的结果是，任何到达 Service 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、Service、或 Pod 的任何信息。

　　默认的策略是，通过 round-robin 算法来选择 backend Pod。 实现基于客户端 IP 的会话亲和性，可以通过设置 service.spec.sessionAffinity 的值为 "ClientIP" （默认值为 "None"）。

 

 1.3.2 iptables 代理模式

　　这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会安装 iptables 规则，从而捕获到达该 Service 的 clusterIP（虚拟 IP）和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。 对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend Pod。

　　默认的策略是，随机选择一个 backend。 实现基于客户端 IP 的会话亲和性，可以将 service.spec.sessionAffinity 的值设置为 "ClientIP" （默认值为 "None"）。

　　和 userspace 代理类似，网络返回的结果是，任何到达 Service 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、Service、或 Pod 的任何信息。 这应该比 userspace 代理更快、更可靠。然而，不像 userspace 代理，如果初始选择的 Pod 没有响应，iptables 代理能够自动地重试另一个 Pod，所以它需要依赖 readiness probes。

 

1.3.3 ipvs代理模式

　　ipvs (IP Virtual Server) 实现了传输层负载均衡，也就是我们常说的4层LAN交换，作为 Linux 内核的一部分。ipvs运行在主机上，在真实服务器集群前充当负载均衡器。ipvs可以将基于TCP和UDP的服务请求转发到真实服务器上，并使真实服务器的服务在单个 IP 地址上显示为虚拟服务。

　　在kubernetes v1.8 中引入了 ipvs 模式，在 v1.9 中处于 beta 阶段，在 v1.11 中已经正式可用了。 iptables 模式在 v1.1 中就添加支持了，从 v1.2 版本开始 iptables 就是 kube-proxy 默认的操作模式，ipvs 和 iptables 都是基于netfilter的， ipvs 模式和 iptables 模式之间的差异：

  •  ipvs 为大型集群提供了更好的可扩展性和性能

  •  ipvs 支持比 iptables 更复杂的复制均衡算法（最小负载、最少连接、加权等等）

  •  ipvs 支持服务器健康检查和连接重试等功能

　　同时ipvs 也依赖 iptables，ipvs 会使用 iptables 进行包过滤、SNAT、masquared(伪装)。具体来说，ipvs 将使用ipset来存储需要DROP或masquared的流量的源或目标地址，以确保 iptables 规则的数量是恒定的，这样我们就不需要关心我们有多少服务了

ipvs虽然在v1.1版本中已经支持，但是想要使用，还需激活ipvs：

① 修改配置文件

1

2

[root@master ~]

# vim /etc/sysconfig/kubelet

KUBE_PROXY=MODE=ipvs

② 编写脚本，让kubelet所在的主机，启动时装入以下几个模块：

ip_vs，ip_vs_rr，ip_vs_wrr，ip_vs_sh，nf_conntrack_ipv4

 

 

LVS 有十种调度算法：

静态方法，根据算法本身进行轮询调度

  • RR, Round Robin

  • WRR，Wrighted RR

  • SH，SourceIP Hash

  • DH，Destination Hash

动态方法，根据算法以及 RS 的当前负载状态进行调度

  • LC，least connections

  • WLC，Weighted Least Connection

  • SED，Shortest Expection Delay

  • NQ，Never Queue

  • LBLC，Locality-Based Least Connection

  • LBLCR，Locality-Based Least Connections withReplication

kube-proxy 可以通过 --ipvs-scheduler 参数选择调度算法，默认情况下是 Round Robin 算法。

ipvsadm -ln 查看负载均衡

https://knarfeh.com/2018/07/28/Kubernetes%20%E6%BA%90%E7%A0%81%E7%AC%94%E8%AE%B0%EF%BC%88kube-proxy%EF%BC%89/

https://www.cnblogs.com/along21/p/10330076.html

以上是 k8sserviceuserspaceiptablesipvs默认算法 的全部内容， 来源链接： utcz.com/z/515546.html

回到顶部