Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。只需要将一组跑同一服务的pod池化成一个service，k8s集群会自动给这个service分配整个集群唯一ip和端口号（这个端口号自己在yaml文件中定义），一个service定义了访问pod的方式，就像单个固定的IP地址和与其相对应的DNS名之间的关系。
Service其实就是我们经常提起的微服务架构中的一个"微服务"，每个微服务后端负载均衡多个业务pod，由版本控制（deployment）控制pod数量，保证服务的高可靠性与冗余性。最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP（k8s集群分配的整个集群唯一的）进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布式能力、弹性扩展能力、容错能力；
理解service这个概念之后，我们跑去service后端看看具体是怎么实现的？
需求：有一个问题就是现在我的业务分配在多个Pod上，那么如果我某个Pod死掉岂不是业务完蛋了，当然也会有人说Pod死掉没问题啊，K8S自身机制Deployment和Controller会动态的创建和销毁Pod来保证应用的整体稳定性，那这时候还会有问题，那就是每个Pod产生的IP都是动态的，那所以说重新启动了我对外访问的IP岂不是要变了，别急，下面我们来解决下这个问题。
可以通过Service来解决如上所遇到的问题
简单来说Service就是一个把所有Pod统一成一个组，然后对外提供固定一个IP，具体是哪些Pod，可以通过之前介绍到的Label标签来进行设置，假设一个pod死掉，副本控制器在生成一个pod,这是pod ip肯定会变，但是我们不去关心你pod ip是多少，我们只知道service ip 没变就好了，因为新的pod 早就加入到我的service中了，各个服务之间通信是通过service 唯一ip来通信的。
上述所有操作，为什么实现了所谓的“”微服务”，举个大家都懂的例子；
一套简单的架构，nginx做反向代理，后端web为8个tomcat实例，在k8s集群中怎么实现呢，我只需要跑8个pod,每个pod运行tomcat容器，service池化这8个pod,而且副本控制会自动动态控制pod数量，少于8个他会创建到8个，多余8个会自动删除到8个。而且我们访问service ip，k8s中的kube-proxy会自动负载均衡后端的8个pod,这一套服务集群内部访问，只需要一个service ip 和端口号就可以；同理，redis集群，同样可以这样实现，每个service相当于微服务，各个服务之间灵活通信。
[root@master yaml]# cat nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx 就是说哪些Pod被Service池化是根据Label标签来的，此行nginx字样，后面我们创建Service会用到
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
kubectl create -f nginx.yaml
deployment.apps/nginx-deployment created 
[root@master yaml]# cat nginx-svc.yml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: NodePort
selector:
app: nginx
ports:
- protocol: TCP
port: 8080 这个资源(svc)开放的端口
targetPort: 80
selector选择之前Label标签为nginx的Pod作为Service池化的对象，
最后说的是把Service的8080端口映射到Pod的80端口。
kubectl apply -f nginx-svc.yml
service/nginx-svc created 
创建完成之后nginx-svc会分配到一个cluster-ip，可以通过该ip访问后端nginx业务。
那它是怎么实现的呢？答案是通过iptables实现的地址转换和端口转换，自己可以去研究
那这时候有人说了，还是不能外网访问啊，别急下面我们来进行外网地址访问设置。在实际生产环境中，对Service的访问可能会有两种来源：Kubernetes集群内部的程序（Pod）和Kubernetes集群外部，为了满足上述的场景，Kubernetes service有以下三种类型：
1.ClusterIP：提供一个集群内部的虚拟IP（与Pod不在同一网段)，以供集群内部的pod之间通信使用。
2.NodePort：在每个Node上打开一个随机端口并且每个Node的端口都是一样的，通过:NodePort的方式Kubernetes集群外部的程序可以访问Service。
3.LoadBalancer：利用Cloud Provider特有的Load Balancer对外提供服务，Cloud Provider负责将Load Balancer的流量导向Service
本篇文章我着重讲下第二种方式，也就是NodePort方式，修改nginx-svc.yml文件，也就是刚才前面创建的Service文件，相信细心的同学会发现在之前截图的时候已经做好了NodePort，因为我的环境已经配置好了所以这样就不在截图了，配置很简单，可以网上看下截图，就是添加一个type：NodePort，然后重新创建下nginx-svc，命令的话和创建的命令一样，我们来看看创建完事的结果。
