K8S中service的分类以及各种使用场景详解_k8s service类型

前言

前面两个章节讲解了K8S的总体入门准备以及全局配置管理的相关内容，正常来说接下来应该将将存储或者组件，但是由于那两部分内容过多且相对偏重细节，所以这一篇先把K8S中的Service先讲解下，帮助大家先理清K8S的整体架构，后续再讲解细节内容的时候可以快速上手，便于理解。

正文

Service是什么？

在说明Service是什么之前先了解下Service的使用场景：

• 当客户端想要访问K8S集群中的pod时，需要知道pod的ip以及端口，那K8S中如何在不知道pod的地址信息的情况下进行pod服务的快速连接？

• 若某一node上的pod发生故障，K8S最大的特点就是能够给感知和重启该pod，但是pod重启后ip会发生变化，那么客户端如何感知并保持对pod的访问？

• 如果多个pod组合在一起形成pod组，如何在被访问时达到负载均衡的效果？

针对上面三种需求，K8S提出了Service的概念，意在解决上述三个问题和场景，下面俩看看Service的定义：

Kubernetes Service是为了管理具有相同功能的一组Pod而定义的一种对象，Service具体的作用和场景如下：

• 通过Pod的Label Selector访问Pod组。

• Service的IP保持不变(Headless Servcie除外，下面会单独讲)，保证了访问接口的稳定性，屏蔽了Pod的IP地址变化带来的影响，进而实现解耦合。虽然这样，还是建议使用ServiceName进行访问。

• Service通过kube-proxy借助iptables/ipvs提供负载均衡的能力，实现反向代理，将请求转发到合适的Pod上。

Service的工作机制

首先根据我对整个Service工作流程的理解，画了这张图，下面就围绕这张图进行展开来说明下：

1. master上的kube-apiserver会处理service的创建，以及Service与通过label匹配与Pod绑定而产生的endpoints对象，并将这些元数据内容存储到etcd中。

2. node上的kube-proxy通过实时监听kube-apiserver上service以及endpoints的变化情况来感知相关事件并更新本地的service和endpoint的映射关系；同时node上的kubedns/coredns服务也会同时将service的域名信息与IP的对应关系存储起来供dns解析之用。

3. kube-proxy将从apiserver获取到的service和endpoint的映射关系保存在本地的iptables/ipvs中供后续查询使用

4. client发起对服务的访问，首先kubedns/coredns将服务名称解析成一个虚拟IP（ClusterIP）

5. 然后使用这个IP去iptables/ipvs中去找service和endpoint的映射关系

6. 找到映射关系后，通过iptables/ipvs的负载均衡算法（典型也是最简单的就是roundrobin算法）匹配到一个合适的Pod进行访问即可。

下面看一个例子：

上图就是一个service的详细信息，先对照上面的流程找一下对应关系：

• service和endpoint的映射关系：everisk-receiver（10.233.3.127）=> 10.233.68.41:6280,10.233.68.43:6280，这些数据会存储到iptables/ipvs中

• service的域名信息与IP的对应关系：everisk-receiver => 10.233.3.127,这些数据会存储到kubedns/coredns中

• 负载均衡反向代理：10.233.68.41:6280,10.233.68.43:6280这两个Pod就是需要进行负载均衡以及反向代理的两个Pod,iptables/ipvs会根据自身的负载均衡算法来完成此过程

• 整体的数据访问流程即everisk-receiver => 10.233.3.127 => 10.233.68.41:6280

Service的类型

K8S中Service分为四类，分别是ClusterIP，NodePort，LoadBalancer以及ExternalName。下面一张图描述了他们之间的关系以及服务类型：

其中绿色的代表从外向内的访问模式；蓝色的代表从内向外的访问模式，黄色代表集群内部的访问模式。可以看到，除了ExternalName类型之外，其余三种类型都是逐层封装而来的。下面就分类讲一讲这四种类型：

ClusterIP

这是K8S默认的服务类型，只能在K8S中进行服务通信。在ClientIP中，K8S会在Service创建完毕后提供一个内部IP作为ClientIP属性，K8S内部服务可以通过ClientIP或者ServiceName来访问该服务。

创建该类型Service的yaml例子如下：

apiVersion: v1
kind: Service
metadata:
  name: service-clusterip
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
  # clusterIP: 10.233.3.127    ##可配可不配，不配的话系统会分配一个随机的IP并保持不变
  selector:
    app: pod-clusterip
  type: ClusterIP        ##type可以不配，不配的话默认就是ClusterIP类型

NodePort

NodePort则是Service type是Nodeport的实现，NodePort通过配置nodePort属性，外部用户可以通过NodeIP:NodePort的方式单独访问每个Node上的服务。

创建该类型Service的yaml例子如下：

apiVersion: v1
kind: Service
metadata:
  name: service-nodeport
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080    ##可配可不配，不配的话系统会分配一个随机的端口并保持不变
  selector:
    app: pod-nodeport
  type: NodePort

LoadBalancer

LoadBalancer类型的service 是可以实现集群外部访问服务的另外一种解决方案。不过并不是所有的k8s集群都会支持，大多是在公有云托管集群中会支持该类型。负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过Service的status.loadBalancer字段被发布出去。

另外据说LoadBalancer需要一些本地资源如F5的支持，而且据说要额外收费，作者不是很了解这里不做过多介绍了。

创建该类型Service的yaml例子如下：

apiVersion: v1
kind: Service
metadata:
  name: service-loadbalancer
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080
  selector:
    run: pod-loadbalancer
  type: LoadBalancer

ExternalName

Service的ExternalName方式实现，即设置Service的type为ExternalName。这样做的好处就是内部服务访问外部服务的时候是通过别名来访问的，屏蔽了外部服务的真实信息，外部服务对内部服务透明，外部服务的修改基本上不会影响到内部服务的访问，做到了内部服务和外部服务解耦合。

创建该类型Service的yaml例子如下：

kind: Service
apiVersion: v1
metadata:
  name: service-externalname
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
  type: ExternalName
  externalName: remote.server.url.com

Headless Service

上面我们讲解了service的使用方法和实现逻辑，主要就是代理一组pod容器提供负载均衡以及反向代理服务。但是有时候我们不需要这种负载均衡，比如下面的两个场景：

• K8S部署某个kafka集群，此时就不需要service来负载均衡，客户端需要的是一组pod所有ip的列表。

• 客户端自己处理负载均衡的逻辑，比如K8S部署两个mysql，客户端自己处理负载请求，或者根本不处理这种负载，就要两套mysql然后手动控制读写请求。

基于上面的两个场景，K8S提供了headless serivce功能，字面意思是无头service，其实就是该service不显式的对外提供IP。

创建该类型Service的yaml例子如下：

apiVersion: v1
kind: Service
metadata:
  name: service-headless
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080    
    clusterIP: None        ##如此配置即开启了headless serivce
  selector:
    app: pod-headless
  type: NodePort

最后说一嘴，headless service一般结合StatefulSet来部署有状态的应用，比如大数据组件或者nosql数据库等，这种分布式的系统需要headless service来获取所有节点ip的列表供业务场景使用。

总结

上面讲述了K8S Service的使用方法以及部分原理，希望能帮助大家掌握Service的相关知识。

而Service作为外部系统与K8S解耦合的关键组件，对外能够简化外系统调用K8S服务的复杂度，屏蔽K8S内部的实现细节；对内提供K8S内部的复杂均衡以及反向代理，是K8S的核心内容，需要重点且优先掌握。

另外，笔者长期关注大数据通用技术，通用原理以及NOSQL数据库的技术架构以及使用。如果想一起入门学习K8S的小伙伴，欢迎大家多多点赞和分享转发，也许你的朋友也喜欢。

最后挂个公众号二维码，公众号的文章是最新的，CSDN的会有些滞后，想追更的朋友欢迎大家关注公众号，谢谢大家支持。