k8s Service定义

k8s Service定义

Service的概念

kubernetes Service定义了一种抽象：一个pod的逻辑分组，一种可以访问他们的策略   --通常称为微服务。这一组pod能够被Service访问到，通常是通过Label Selector（标签选择器）

举个例子：比如架构如nginx+php，当创建一个nginx-deployment，会生成3个php容器，当其中一个容器崩溃deployment会删除并重新创建一个，如果这时ip变化了，nginx的upstaream的ip就需要更新，当然用脚本也可以实现，k8s也提供了可以解决此类问题，那就是Service。Service在pod之上，pod的信息更新的话会同步到service，然后service再将更新信息同步给nginx

​Service只能提供4层负载均衡能力，而没有7层功能，所以也就是只能基于ip和port来转发

Service在k8s中有以下四种类型：

ClusterIp：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP

NodePort：在ClusterIp基础上为Service在每台机器上绑定一个端口，这样就可以通过:NodePort来访问该服务

LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部负载均衡器，并将请求转发到:NodePort

ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有k8s1.7或更高版本kube-dns才支持（例如：集群内部新建一个针对访问外部的svc，如果外部的ip地址更新的话只需要更新svc即可）

VIP和Service代理

在k8s集群中，每个node运行一个kube-proxy集成。kube-proxy负责为Service实现了一种VIP的形式，而不是ExternalName的形式。在k8s1.0笨笨，代理完全在userspace，在k8sv1.1版本，新增了iptables代理，但并不是默认的运行模式。从k8sv1.2起默认就是iptables代理。在k8sv1.8.0添加了ipvs代理

在k8s1.14版本开始默认使用ipvs代理

在k8s1.0版本，Service是4层（TCP/UDP over IP）概念。在k8s1.1版本新增了ingress API（beta版），用来表示7层（DNS？（主要dns存在缓存）

​

代理模式的分类：

1、userspace代理模式

clientpod如果想要访问serverpod的话，首先clientpod先访问到iptables，然后iptables访问kube-proxy，再到serverpod1。（kube-proxy，kube-apiserver压力较大）

2、iptables代理模式

clientpod会通过iptables然后再到serverpod1，不需要再到kube-proxy

3、ipvs代理模式

和上图一样将iptables改成了ipvs

这种模式，kube-proxy会监视kubernetes Service对象和endpoints，调用netlink接口以相应的创建ipvs规则并定期与kubernetes Service对象和endpoints同步ipvs规则，则以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod

与iptables类似，ipvs于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快的重定向流量，并且在同步代理时具有更好的性能。此外ipvs为负载均衡算法提供了更多选项，例如：

rr：轮询调度

lc：最小连接数

dh：目标哈希

sh：源哈希

sed：最短期望延迟

nq：不排队调度

<！--注意：ipvs模式必须要安装ipvs内核模块，如果未安装kube-proxy将会以iptables代理模式>

主要需要以下几个组件的协同工作：

apiserver用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中。然后kube-proxy监控采集etcd的数据信息写到ipvs或iptables中。iptables或ipvs使用nat等技术将vip的流量转至endpoint中

Headless Service

有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定Cluster IP（spec.clusterIP）的值为None来创建Headless Service。这类Service并不会分配ClusterIP，kube-proxy不会处理他们，而且平台也不会为他们进行负载均衡和路由

解决hostname和podname，可以通过访问域名

NodePort

nodePort的原理在于node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步给到对应的pod

LoadBalancer

loadBalancer和nodeport其实是同一种方式。区别在于loadbalancer比nodeport多了一步，就是可以调用cloudprovider去创建LB来向节点导流

ExternalName

这种类型的service通过返回cname和它的值，可以将服务映射到externalname字段的内容（例如：hub.harbor.com）。externalname Service是Service的特例，它没有selector，也没有定义任何的端口和endpoint，相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

当查询主机my-service.default.svc.cluster.local(SVC_NAME.NAMESPACE.svc.cluster.local)时，集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发

Service Ingress（7层）

Store以一种协程的pod方式和apiserver建立连接监听状态，如果发生一些写入会写进循环队列updateChannel，NginxController会去监听updateChannel里的事件，发生一个事件会写进同步队列syncQueue，等待被协程去更改配置文件。有一些事件也会直接通过Store到协程，这时协程会有个判断是否需要后面，，，，，

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。