k8s中的服务如何找到绑定的pod，实现Pod负载均衡的方法(k8s多Pod负载均衡)

k8s中的服务如何找到绑定的Pod，如何平衡Pod负载？

前言资源主要用于为Pod对象提供固定统一的访问接口和负载均衡能力。

服务是一组具有相同labelbod集合的抽象，集群内外的服务可以通过服务相互通信。

创建服务对象时，会相应地创建一个端点对象。端点用于容器发现。服务只关联多个pod，实际的路由和转发都是由kubernetes中的kube -代理组件实现的。因此，服务必须与kube-proxy结合使用。kube -代理组件可以在kubernetes集群中的每个节点上运行，也可以只在几个单独的节点上运行，它会根据服务和端点的变化来改变节点上iptables或ipv中存储的路由规则。

Endpointendpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个服务对应的所有pod的访问地址。

通过服务选择器与pod建立关联。K8s将根据与POD by service关联的podIP信息组合成一个端点。

如果服务没有选择器字段，则在创建服务时，端点控制器不会自动创建端点。

$ ku bectl get SVC -n study -k8s name TYPE cluster -IP external -IP PORT agego -web -SVC cluster IP 10 . 233 . 55 . 112 & lt；无& gt8000/ TCP 9d$ kubectl获取端点-n study-k8sNAME端点age go -web -SVC 1 0 . 233 . 111 . 171:8000，10.233.111.172: 8000，10.233.72.153: 800小编2 more...9d李茹

上面的服务go-web-svc有一个对应的端点，它显示了与服务相关的pod的ip地址和端口。

端点控制器加载维护端点对象，其主要功能如下

1.负责生成和维护所有端点对象的控制器；

2.监控服务和相应pod的变化；

3.监测到服务被删除后，删除与服务同名的端点对象；

4.监测到新服务创建后，根据新服务信息获取相关的pod列表，然后创建相应的端点对象；

5.监测到服务更新后，根据更新后的服务信息获取相关的pod列表，然后更新相应的端点对象；

6.监听到pod事件后，更新对应服务的端点对象，记录端点中的podIp

Kube-proxykube-proxy是Kubernetes的核心组件，部署在每个节点上。它是实现Kubernetes服务的通信和负载平衡机制的重要组成部分。Kube-proxy负责为Pod创建代理服务，从apiserver获取所有服务器信息，根据服务器信息创建代理服务，实现服务器对Pod的请求路由转发，从而实现K8s级的虚拟转发网络。

k8s中提供相同服务的一组pod可以抽象成一个服务，通过服务对外提供统一的服务。kube -代理存在于每个节点上，负责为服务提供集群内的服务发现和负载均衡，并负责PODs的网络代理。它会定期从etcd获取服务信息做出相应的策略，并维护网络规则和四层负载均衡。k8s中集群内的负载均衡是通过kube-proxy实现的，kube -proxy是k8s中的内部负载均衡器，是一个分布式代理服务器。每个节点中可以部署一个。部署的节点越多，提供负载平衡功能的kube -代理就越多，高可用性节点也就越多。

简单来说，k8s内部的pod想要访问服务，kube-proxy会将请求转发给服务所代表的特定pod，也就是与服务相关联的Pod。

同理，请求外部访问服务，无论是集群IP+target port；或者以Node IP+NodePort的方式，通过Node node的Iptables规则重定向到kube -代理监听服务的代理端口。kube-proxy收到服务的访问请求后，根据负载策略转发给后端Pod。

kube -代理的路由转发规则是通过其后端代理模块实现的，其中kube -代理模块目前有四种实现方案，分别是userspace、iptables、ipvs和kernelspace。

用户空间模式用户空间模式在k8s v1.2之后被取消了用户空间的作用是监视代理的用户空间中的一个端口。所有的SVC都到这个端口，然后代理的内部应用层转发它。代理将随机监控每个svc的端口，并添加一个iptables规则。

从客户端到ClusterIP:Port的消息将通过iptables规则重定向到代理端口。收到消息后，Kube-Proxy会将它们分发到相应的Pod。

在用户空间模式下，流量转发主要在用户空间完成。如上所述，客户端的请求需要借助iptables规则找到相应的代理端口。由于iptables在内核空间，会有一个从用户态到内核态再回到用户态的传输过程，一定程度上降低了服务性能。所以会认为这样会有一定的性能损失。

默认情况下，用户空间模式下的kube -代理通过循环算法选择后端。

Iptables让我们先简单看一下iptables:

Iptables是Linux中最常用的防火墙工具。除了防火墙，它还可以作为IP转发和简单的负载均衡功能。基于Linux的netfilter内核模块的实现。Netfilter在协议中加入了一些钩子，允许内核模块通过这些钩子注册回调函数，这样所有通过钩子的数据都会被响应钩子上注册的函数处理，包括修改包的内容，标记包或者丢弃包等。Iptables是一个运行在用户模式下的程序，它足够灵活，可以通过netlink和内核netfilter框架处理各种常见的数据包操作和过滤要求。它允许将灵活的规则序列附加到内核的数据包处理管道中的各种钩子上。

Netfilter是Linux 2.4.x推出的一个子系统，作为一个通用的抽象框架，它提供了一套完整的钩子函数管理机制，使得基于协议类型过滤数据包、网络地址转换(NAT)和跟踪连接成为可能。

Iptables在kubernetes v1.2之后成为默认的代理模式，在这种模式下，kube -代理监控Kubernetes master添加和删除服务对象和端点对象。对于每个服务，它将安装iptables规则，以便捕获到达服务的集群IP(虚拟IP)和端口的请求，然后将请求重定向到服务的一组后端之一。因为流量转发是在内核中完成的，所以性能更高，更可靠。

可以看到，在这种模式下，iptables被用作用户模式的入口。kube -代理只持续监视服务和端点对象的变化。iptables通过设置的转发策略直接将VIP请求转发给后端Pod。iptables使用DNAT完成转发，采用随机数实现负载均衡。

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

与用户空间模式相比，该模式克服了用户模式-内核模式下请求重复传输的问题，性能有所提升。但是，使用iptables NAT来完成转发会有明显的性能损失。iptables模式的主要问题是在服务数量较多的情况下会产生过多的iptables规则，使用非增量更新会引入一定的时间延迟，在大规模情况下会出现明显的性能问题。

Ipvs当集群规模比较大的时候，iptables规则的刷新会比较慢，很难支持大规模的集群。因为iptables的底层实现是链表，所以需要遍历一次链表来添加、删除和修改路由规则。

在kubernetes v1.2之后，Ipvs成为kube -代理的默认代理模式..Ipvs解决了这个问题。ipvs是LVS的负载平衡模块。与iptables相比，虽然ipvs的实现也是基于netfilter的hook函数，但它使用哈希表作为底层数据结构，工作在内核状态。也就是说，ipvs在重定向流量和同步代理规则方面有更好的性能，并且几乎允许无限制的规模扩展。

Ipvs支持三种负载平衡模式:

1.DR模式(直接路由)；

2.NAT模式(网络地址转换)；

3.隧道(也称为ipip模式)。

三种模式中只有NAT支持端口映射，所以ipvs使用NAT模式。linux内核原生的ipv只支持DNAT，在包过滤、SNAT、支持NodePort类型的业务等场景下，ipv还是会使用iptables。

Ipvs还支持更多的负载平衡算法:

RR:round -robin/polling；

LC:least connection/最小连接；

DH:目的散列/目的散列；

Sh:源哈希/源哈希；

Sed:最短期望延迟/最短期望延迟时间；

NQ:从不排队

Kernelspacekernelspace模式是windows上的一种代理模式，这里就不讨论了。

服务端点的发现解决了容器发现问题，但是如果不事先知道服务的集群IP，就无法知道服务service。Kubernetes支持两种基本的服务发现模式& mdash& mdash环境变量和DNS。

环境变量当创建一个pod时，kubelet将在pod中注册集群创建的所有与服务相关的环境变量。但是，应该注意的是，在创建服务之前，所有的pod都不会注册环境变量。因此，建议在正常使用中通过DNS进行服务间的服务发现。

例如，名为redis-primary的服务公开TCP端口6379，并为其分配群集IP地址10.0.0.11。该服务生成以下环境变量:

REDIS _ PRIMARY _ SERVICE _ HOST = 10 . 0 . 0 . 11 REDIS _ PRIMARY _ SERVICE _ PORT = 6379 REDIS _ PRIMARY _ PORT = TCP://10 . 0 . 0 . 11:6379 REDIS _ PRIMARY _ PORT _ 6379 _ TCP = 6379 REDIS _ PRIMARY _ PORT _ 6379 _ TCP _ PORT = 6379

DNS可以在集群中部署CoreDNS服务(旧的kubernetes集群中使用了kubeDNS)，这样集群中的pod就可以通过DNS在集群中的服务之间进行通信。

目前kubernetes集群默认使用CoreDNS作为默认DNS服务，主要是因为CoreDNS是基于Plugin扩展的，简单灵活，不完全被Kubernetes捆绑。

同时，k8s也建议使用DNS进行服务发现。

Kubernetes DNS服务器是访问ExternalName类型服务的唯一方式。

总结服务在k8s中的一般用途，为Pod对象提供固定统一的访问接口和负载均衡能力；

k8s中的负载均衡主要通过端点和kube -代理的方式实现；

端点是k8s集群中的一个资源对象，存储在etcd中记录一个服务对应的所有PODs的访问地址。当与服务相关联的pod被删除、更新或添加时，相应的端点资源将被更新。

Kube-proxy是Kubernetes的核心组件，部署在每个节点上。它是实现Kubernetes服务的通信和负载平衡机制的重要组成部分。Kube-proxy负责为Pod创建代理服务，从apiserver获取所有服务器信息，根据服务器信息创建代理服务，实现服务器对Pod的请求路由转发，从而实现K8s级别的虚拟转发网络；

kube -代理的路由转发规则通过其后端代理模块实现，其中kube -代理模块目前有四种实现方案:用户空间、iptables、ipvs、内核空间；

服务的端点和kube -代理解决了容器发现和负载均衡的问题，但是内部服务如何发现服务呢？Kubernetes支持两种基本的服务发现模式& mdash& mdash环境变量和域名系统；；

其中k8s推荐使用DNS进行服务发现。目前kubernetes集群默认使用CoreDNS作为默认DNS服务，主要是因为CoreDNS是基于Plugin扩展的，简单灵活，不完全被Kubernetes捆绑。

参考【库伯内特服务原则分析】https://zhuanlan.zhihu.com/p/111244353

【服务选择器】https://blog . csdn . net/Luan Peng 825485697/article/details/84296765

【了解kube -代理】https://zhuanlan.zhihu.com/p/337806843

【Kubernetes【网络组件】kube -代理用法详解】https://blog . csdn . net/xixihahalehe/article/details/115370095

【服务】https://Jimmy song . io/kubernetes -handbook/concepts/Service . html

【服务】https://kubernetes . io/zh-cn/docs/concepts/services -networking/Service/

【k8s中的服务如何找到绑定的Pod，如何平衡Pod负载】https://boilingfrog.github.io/2022/10/16/k8s中的服务如何找到绑定的Pod，如何平衡Pod负载/

关于k8s中的服务如何找到绑定的Pod以及如何实现Pod负载均衡的文章到此结束。关于k8s中的服务如何实现Pod负载均衡的更多信息，请搜索主机频道zhujipindao之前的文章。或者继续浏览下面的相关文章。希望大家支持主机频道zhujipindao。以后多来com！