kubernetes学习之路（十三）service（一）

Service 概念

  service 是一种可以访问一组 pod 的访问策略，通过 Label Selector 标签匹配后端 pod，这样无论后端 pod 是增加还是减少，都可以通过 svc 访问到，例如 nginx 指定 svc 地址，那么就相当于代理后端 pod，而不会以为增加 pod 而修改 nginx 配置。

  轮询方式只有 rr ，只提供了4层负载能力，也就是不能通过域名或主机名的方式进行负载。

 

Service 类型

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

NodePort：在ClusterIP基础上为Service在每台node节点上绑定一个端口，这样可以通过 NodeIP:Port 的方式来访问后端Pod，这种方法比较常见，nginx可以通过这种方式进行代理。

LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部负载均衡器，并将请求转发到 NodeIP:Port ，这种方式一般是通过云服务商的 LB 实现，也就是收费模式。

ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，需要1.7或更高版本的kube-dns才支持。简单来说，当前集群内的pod需要访问外部一个服务，如果外部服务更改了ip地址，那么pod的配置就需要更改，而使用此方法相当于定义了一个svc，指定外部ip地址，如果外部ip地址发生变化，只需要更新svc即可。

图中含义：

  客户端访问svc实际上是访问的iptables规则从而访问到后端pod，iptables的规则是通过kube-proxy写入的，apiserver通过监控kube-proxy实现服务和端点信息的发现，kube-proxy通过pod的标签判断信息是否写入到apiserver的Endpoints中

kubernetes 1.14 版本开始默认使用 ipvs 取代 iptables

注意：ipvs 模式假定在运行 kube-proxy 之前在节点上已经安装好了 IPVS 内核模块。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 IPVS 模块，如果未安装，则 kube-proxy 将回退到 iptables 代理模式。

 

 

未完