Service

目录

Service功能：

工作模式：

分类：

ipvs模式：

Endpoint: 

Service的工作原理：

Service类型：

 ClustetrIP类：

HeadLiness类：

NodePort类：

LoadBalancer类：

ExternalName类：

---

Service功能：

        对提供同一个服务的多个pod进行聚合， 并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。

       Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行 着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它将最新的Service信息转换成对应的访问规则。

工作模式：

分类：

• userspace 模式
• iptables 模式
• ipvs 模式

 前两种已被淘汰，目前多用第三种，故此前两种不在此赘述

ipvs模式：

       kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

        注意：此模式必须安装ipvs内核模块，否则会降级为iptables。

Endpoint: 

        Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地 址，它是根据service配置文件中selector描述产生的。

Service的工作原理：

        apiServer将创建service的指令发送给kube-proxy，kube-proxy会生成一套ipvs的策略，当客户端策略转发进来后，根据对应生成的ipvs策略将请求转发到对应的pod节点上，进行后续操作。

Service类型：

 ClustetrIP类：

        主要是依靠Endpoint，他存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

负载分发策略：

• 如果不进行定义，则默认使用kube-proxy的策略，比如随机、轮询。
• 若进行定义，可采用同一个客户端的多次请求被转发至一个固定的pod中。

HeadLiness类：

        主要作用就是开发人员可以自己控制负载均衡策略，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。只需要在ClustetrIP类的yaml文件中将clusterIP的值修改为None即可(注意：是修改成clusterIP: None)，即可转变成HeadLiness。

NodePort类：

        前两种的service都只能在集群内部访问，而通过NodePort可以将对应端口号暴露到集群外部，也就是可以将service的端口映射到Node的一个端口上，而后可通过NodeIp:NodePort来访问service。

LoadBalancer类：

        和NodePort类似，都是向外暴露一个端口，但是他会在集群的外部再来做一个负载均衡设备，这个设备外部环境支持，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

ExternalName类：

        前几种都是将内部服务给暴露出去，这个是将外部的服务给引进集群当中，从而在集群中可以访问到外部的服务了。