k8s 理解Service工作原理

什么是service？

Service是将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

简单来说K8s提供了service对象来访问pod。我们在《k8s网络模型与集群通信》中也说过k8s集群中的每一个Pod（最小调度单位）都有自己的IP地址，都有IP了访问起来还不简单？

其实不然，一是k8s中pod不是持久性的，摧毁重建将获得新的IP，客户端通过变更IP来访问显然不合理。二是需要多个副本间的负载均衡。所以此时Service就冒出来了。

那么今天我们就来学习一下service，看看它是如何工作的。

Service与endpoints、pod

当我们通过API创建/修改service对象时，endpoints控制器的informer机制 Listen到service对象，然后根据service的配置的选择器创建一个endpoints对象，此对象将pod的IP、容器端口做记录并存储到etcd，这样service只要看一下自己名下的endpoints就可以知道所对应pod信息了。

且看下图：

我们在实例来看一下，先稀疏平常创建一个Deployment

#deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-demo
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mirrorgooglecontainers/serve_hostname
        ports:
        - containerPort: 9376
          protocol: TCP

serve_hostname是k8s官方提供的debug镜像，一个返回hostname的web server。这样我们创建出了标签为app=nginx的三个pod，当我们访问pod的9376时会返回hostname。

接着是service清单，我们在service中指定了选择器为app=nginx

#service.yaml
apiVersion: v1
kind: Service
metadata:
  name: service-demo
spec:
  selector:
    app: nginx
  ports:
  - name: default
    protocol: TCP
    #service port
    port: 80
    #container port
    targetPort: 9376

这样我们获得不变的CLUSTER-IP 10.96.148.206的service

如果pod启动成功，则自动创建和service同名的endpoints记录下了三个pod的数据

service中选择器未指定标签时endpoints需要手动创建映射到service的网络地址如下：

apiVersion: v1
kind: Endpoints
metadata:
  name: service
subsets:
  - addresses:
      - ip: 10.96.148.206
    ports:
      - port: 9376

此时当我们不断访问service的CLUSTER-IP时：

# curl 10.96.148.206:80
deployment-demo-7d94cbb55f-8mmxb
# curl 10.96.148.206:80
deployment-demo-7d94cbb55f-674ns
# curl 10.96.148.206:80
deployment-demo-7d94cbb55f-lfrm8
# curl 10.96.148.206:80
deployment-demo-7d94cbb55f-8mmxb

可以看到此时请求已被路由到后端pod，返回hostname，并且负载均衡方式是Round Robin即轮询模式。

通过上面介绍我们好像摸到了Service其中的门道，接下来是流量到底如何通过service进入pod的？