14Service的基本工作逻辑 三种模式四种类型

Posted 2023-03-12

Service与服务发现

Service资源基础
   ◼ Service的功用
   ◼ Service的类型

流量转发
   ◼ Service规范及创建
   ◼ 标签和标签选择器
   ◼ 外部流量策略
   ◼ Load Balancer类型的Service

Service名称解析
   ◼ CoreDNS和Service的名称资源记录
   ◼ Headless Service和ExternalName Service

流量转发机制

Service：

Service的功能和作用：
    1、服务的固定访问入口，用于实现服务发现
    2、流量的负载均衡
    
Service的发现机制：Service的Label Selector去判断pod上的label是否符合条件
Service并不直接通过Label Selector发现pod，中间还有个层级的对象--Endpoint（端点资源），新版为EndpointSlice
每创建一个Service，系统会自动创建一个同名的Endponit资源，这个资源才是真正借助于Label Selector发现pod的关键所在。
       评估条件：1、符合标签选择器的条件  2、pod处于Ready状态
       
       
访问：
Service：会自动分配一个IP地址，集群地址，service地址
给用户提供一个便捷的访问入口，通过service Name来实现对serviceIP的访问，支持这个功能的是
ClusterDNS：经历了三代 
第一代SkyDNS，第二代KubeDNS，第三代CoreDNS
CoreDNS:自动从API Service发现每一个Service的定义，Service Name、IP和Port，就会被作为数据项自动创建为资源记录。
资源记录分为三种：A记录、PTR记录、SRV记录（用于服务发现，基于Service Name、IP和Port来完成）

注册监视：让注册中心接受请求，并把数据挑选来，当数据发生变动，反过来通知监视方，你所请求监视的内容发生了变动
注册监视就是告诉API server期望监视那个资源。API server支持你来请求监视哪些资源
而CoreDNS能够请求API server去监视所有的service资源，只要service资源变动，API server就会通知给CoreDNS，CoreDNS实时记录并更新。

deployment控制器就是用于注册监视pod，service基于标签选择器也可以监控pod
CoreDNS能够注册监视service的变动

Service Mode：

如何将发现的各端点（IP：PORT）构建为集群并能够接收和分发流量？
    
把service所提供的负载均衡功能基于某一个功能节点或多个节点落地为接入流量还能实现负载均衡的机制就可以了
三种解决方案：
第一种：iptables
第二种：ipvs
第三种：在用户空间运行一个进程，基于虚拟主机的方式来提供服务

客户端侧的负载均衡机制：客户端pod所在的节点，就是客户端要访问的目标service的负载均衡器。

针对某一特定服务，如何将集群中的每个节点都变成负载均衡器：
1、在每个节点上运行一个kube-proxy，由kube-proxy注册监视API Server的Service资源；（创建、删除、修改）
2、将Service的定义，转为本地负载均衡功能的落地实现；
    （1）在用户空间运行一个应用程序，通过虚拟主机的方式来完成为每个服务的负载均衡功能（性能差，已废弃）
    （2）借助内核空间的iptables（默认方式）
    （3）借助内核空间的ipvs    （适用于大集群）
这三种就叫做Service Mode
kubeadm默认使用iptables，可改为ipvs模式，最好在部署集群的时候指明，或者改后重启集群，至少重建kube-proxy
查看所用的模式：kubectl get cm kube-proxy -o yaml -n kube-system > kube-proxy,yaml
修改mode字段的值：空值是iptables，改为ipvs  
kubectl apply -f kube-proxy,yaml

3、同一个集群当中的所有节点只能同时使用一种Mode，不能交叉使用
使用哪一种，通过kube-peoxy修改。（kube-system名称空间中，有一个configmap/kube-proxy资源）
4、服务数量N，平均每服务的端点量M(加入服务很多，会导致iptables的规则会非常多，即便在内核中处理速度非常快，但流量如果非常大，对性能的影响也是不可小觑的，而ipvs相对来说，规则相对iptables会少很多)
如果集群节点在50个以下，服务数量在2000个以下，两者性能区别不大，再大就要用ipvs了
并且ipvs支持多种负载均衡算法，但iptables只支持一种负载均衡算法

Service的类型：

1、ClusterIP：定义service，只要指明ServiceIP、Service Port就能把他转换成内核中iptablies的DANT规则或virtualserver的定义，集群内的客户端基于该ip和port所生成的规则，就能够用负载均衡的功能。
2、NodePort：集群外部的客户端通过NodePort来接入，通过节点ip加port到达节点网络，然后才能到达节点之上所在的某个pod网络中。 
3、LoadBalancer：外部的负载均衡器（LBaas），外部软负载均衡服务的实现，要具有与API Server联动能力。
定义流量策略有两种：
externalTrafficPolicy:内部流量策略
     local:接入流量的节点，只能把流量调度给当前节点上的pod；（性能有提升，负载均衡效果会下降）
     clustre:接入流量的节点，可以把流量调度给该服务在集群上的任何一个pod；（负载均衡效果好，性能会影响）

internalTrafficPolicy:外部流量策略（结合LoadBalancer去使用local流量策略是最妥当的选择，生产环境当中部署在公有云上，如华为云的CCE，他的LoadBalancer允许创建的时候完成自动设置流量策略，自动选择合适的接入节点，而且内外可以实现联动，以确保性能的表现）
    
4、externalName：外部名称
     目标：将外部服务，定义到集群上，成为集群的服务。
     实现方法：把ServiceName解析成外部服务的DNS名称
            在CoreDNS上，ServiceName要通过CNAME记录，解析为外部服务的DNS名称

NodePort是增强版的ClusterIP，LoadBalancer是增强版的NodePort，并且对外部环境有依赖关系。

Service的基本工作逻辑总结

1、Service的功能和作用：
    1、服务的固定访问入口，用于实现服务发现
    2、流量的负载均衡
Service的发现机制：Service的Label Selector去判断pod上的label是否符合条件，能被发现的lable都能成为该服务上游的可用端点之一。 

2、service可以借助于CoreDNS完成名称解析和对应资源的自动生成和管理。

3、Service Mode：三种  
    （1）在用户空间运行一个应用程序，通过虚拟主机的方式来完成为每个服务的负载均衡功能（性能差，已废弃）
    （2）借助内核空间的iptables
    （3）借助内核空间的ipvs    （适用于大集群）
4、

集群外部访问时如何实现访问不越点情况的发生

解决下面两种情况就可以实现访问不越点情况的发生

1、客户端流量只会指向运行由目标sevice对应的pod的节点
2、节点在接入流量调度的时候也只会调度到当前节点上的pod，不调度到其他节点上的pod
就能确保性能在表现上就不会出现越点情况的发生

解决办法：
1、配置集群外部的负载均衡器，其可与集群的API Server交互，通过查询API Server知道对应的目标service和pod被调度到哪个节点上。
2、节点接入流量后，需要在service之上加以约束指定流量策略。（外部流量策略）