Kubernetes里的Service到底是什么？为什么我需要定义Service？难道光有Pod还不够吗？

在Kubernetes里有一个资源（resource）叫做Service。很多同学第一次看到Service这个资源的时候就会开始思考Service与Pod之间的差别在哪里？既然我们已经定义了deployment，并且Kubernetes会根据deployment来生成管理Pod，为什么我们还需要再定义一个Service呢？

首先我们要先理解Pod的特性。在Kubernetes的眼里，Pod是可以随时被删除并且被新创建的Pod给取代的。让我们来看看下面这个场景。

假设我们现在有一个后台服务叫做Discount，这个后台服务Discount通过从前端接收的用户信息来计算可以提供给用户的最大折扣，然后再将计算得到的折扣幅度返回给前端。我们通过Kubernetes将该Discount服务部署到我们的集群（Cluster）上面。此时的情况如下图所示。

我们可以看到当前端用户向Discount服务发送请求时，Gateway知道到哪里寻找Discount服务的Pod。注意此时的Pod IP为 112.1.1.0。然而，如果此时Pod A里面的Discount服务因为某些因素崩溃了，从而导致Pod A不再返回折扣幅度，Kubernetes并不会尝试重启Pod A，而是会将Pod A删除，并创建一个新的Pod来取代Pod A。在这里，我们称该新创建出来取代Pod A的新Pod为Pod B，如下图所示。

值得注意的是，新创建出来的Pod B的IP地址与原本Pod A的IP地址不同，此时所产生的问题就是Gateway无法确定取代Pod A的新Pod在哪里，因为Gateway并不知道Pod B的IP地址。为了解决这个问题，Kubernetes使用了Service的概念。

Service可以理解成一组提供特定服务的Pods。比如说，我们现在有Discount这个服务，如果我们希望知道有哪些Pods在提供Discount的服务，我们就定义一个Service，然后让我们定义的Service把拥有特定标签（label）的Pod给包括起来。下面是定义Service的一个例子。

apiVersion: v1
kind: Service
metadata:
  name: discount-service
spec:
  selector:
    app: DiscountApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

在spec.selector.app这个地方，我们让Kubernetes知道说只要Pod含有DiscountApp的Label，这个Pod就属于discount-service。如此一来，无论DiscountApp的Pod如何被新Pod给取代，或是当scaling发生时有新的Pod被创建，只要通过我们定义的discount-service便能知道有多少以及具体哪些Pod在提供Discount的服务。此时的情况变成如下图所示。

值得注意的一点是，我们定义的Service会有自己的IP地址，前端程序只需要访问Service的IP地址，Service的代理（Proxy）便会自动将Request转移至合适的Pod上面。下面这里我附上Kubernetes官方的Service架构图供大家参考。

Kubernetes Service 官方结构图