k8s服务service发现与负载均衡

Kubernetes service有以下三种类型：

• ClusterIP:提供一个集群内部的虚拟IP以供Pod访问（k8s集群内的一种反向代理，微服务之间的互通互联，即集群内Service互相通信，比如部署的redis,mysql服务，只是集群内使用的）。
• NodePort:在每个Node上打开一个端口以供外部访问（端口范围是30000-32767，对外网暴露服务）。
• LoadBalancer:通过外部的负载均衡器来访问。(只有公有云支持,如阿里云)

1.pod如何实现访问？

端口转发：Port-Forward

2.什么是Service 

Service是一个抽象的概念。它通过一个虚拟的IP的形式(VIPs)，映射出来指定的端口，通过代理客户端 发来的请求转发到后端一组Pods中的一台（也就是endpoint）。

Service定义了Pod逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了统一的服务访问 入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。 外 部系统访问Service的问题: -> 首先需要弄明白Kubernetes的三种IP这个问题 - Node IP：Node节点的 IP地址 - Pod IP： Pod的IP地址 - Cluster IP：Service的IP地址。

-> 首先,Node IP是Kubernetes集群中节点的物理网卡IP地址，所有属于这个网络的服务器之间都能通 过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者 TCP/IP服务的时候，必须通过Node IP进行通信。

-> 其次，Pod IP是每个Pod的IP地址，他是Docker Engine根据docker0网桥的IP地址段进行分配的，通 常是一个虚拟的二层网络。

最后Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，原因有以下几点: -> Cluster IP仅仅作用 于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址 -> Cluster IP无法被ping，他没有 一个“实体网络对象”来响应 -> Cluster IP只能结合Service Port组成一个具体的通信端口，单独的 Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。 -> Kubernetes集 群之内，Node IP网、Pod IP网于Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程 方式的特殊路由规则。
 

3.service原理

4.service服务注册与发现 

 service通过打标机制找到具体的pod

5.service是如何产生的？ 

6.service的负载策略 

7.IPTables 

Iptables模式为Services的默认代理模式。在iptables 代理模式中，kube-proxy不在作为反向代理的在 VIPs 和backend Pods之间进行负载均衡的分发。这个工作放给工作在四层的iptables来实现。iptables 和netfilter紧密集成，密切合作，都在kernelspace 就实现了包的转发。 在这个模式下，kube-proxy 主要有这么几步来实现实现报文转发：

通过watching kubernetes集群 cluster API， 获取新建、删除Services或者Endpoint Pod指令。
kube-proxy 在node上设置iptables规则，当有请求转发到Services的 ClusterIP上后，会立即被捕 获，并重定向此Services对应的一个backend的Pod。
kube-proxy会在node上为每一个Services对应的Pod设置iptables 规则，选择Pod默认算法是随机 策略。
在iptables模式中，kube-proxy把流量转发和负载均衡的策略完全委托给iptables/netfiter 来做，这些 转发操作都是在kernelspace 来实现，比userspace 快很多

在iptables 中kube-proxy 只做好watching API 同步最新的数据信息这个角色。路由规则信息和转发都 放在了kernelspace 的iptables 和netfiter 来做了。但是，这个这个模式不如userspace模式的一点是， 在usersapce模式下，kube-proxy做了负载均衡，如果选择的backend 一台Pod没有想要，kube-proxy 可以重试，在iptables模式下，就是一条条路由规则，要转发的backend Pod 没有响应，且没有被K8S 摘除，可能会导致转发到此Pod请求超时，需要配合K8S探针一起使用。

8. 什么是IPVS

PVS（IP虚拟服务器）实现传输层负载平衡，通常称为第4层LAN交换，是Linux内核的一部分。 IPVS在主机上运行，在真实服务器集群前充当负载均衡器。 IPVS可以将对基于TCP和UDP的服务的请求 定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。

9.IPVS vs. IPTABLES

IPVS模式在Kubernetes v1.8中引入，并在v1.9中进入了beta。 IPTABLES模式在v1.1中添加，并成为自 v1.2以来的默认操作模式。 IPVS和IPTABLES都基于netfilter。 IPVS模式和IPTABLES模式之间的差异如 下： 

IPVS为大型集群提供了更好的可扩展性和性能。
IPVS支持比iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）。
IPVS支持服务器健康检查和连接重试等。
我们都知道，在Linux 中iptables设计是用于防火墙服务的，对于比较少规则的来说，没有太多的性能 影响。但是对于，一个K8S集群来说，会有上千个Services服务，当然也会转发到Pods，每个都是一条 iptables规则，对集群来说，每个node上会有大量的iptables规则，简直是噩梦。 同样IPVS可以解决可能也会遇见这样大规模的网络转发需求，但是IPVS用hash tabels来存储网络转发 规则，比iptables 在这上面更有优势，而且它主要工作在kernelspace，减少了上下文切换带来的开 销。
 

————————————————
版权声明：本文为CSDN博主「爱上口袋的天空」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/K_520_W/article/details/116464369