可以通过Service来解决如上所遇到的问题，那么什么是Service呢？
Service是kubernetes最核心的概念，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求进行负载分发到后端的各个容器应用上。
在创建Service之前先看看我们在部署应用的时候创建的nginx.yml
刚在有提到，就是说哪些Pod被Service池化是根据Label标签来的，那么可以看到图上所标识的nginx字样，后面我们创建Service会用到。
下面来创建个Service看看解释下这个yml文件哈，其意思就是说呢V1是api的版本，然后Kind表示当前资源类型为Service，selector选择之前Label标签为nginx的Pod作为Service池化的对象，最后说的是把Service的8080端口映射到Pod的80端口。
执行kubectl apply创建Servie nginx-svc1 kubcetl apply –f nginx-svc.yml
创建完成之后nginx-svc会分配到一个cluster-ip，可以通过该ip访问后端nginx业务。
创建完之后可以查看service详情查看后端都包含哪些pod
1 kubectl describe service nginx-svc
那它是怎么实现的呢？答案是通过iptables实现的地址转换和端口转换，可以用iptables-save查看。
那这时候有人说了，还是不能外网访问啊，别急下面我们来进行外网地址访问设置。在实际生产环境中，对Service的访问可能会有两种来源：Kubernetes集群内部的程序（Pod）和Kubernetes集群外部，为了满足上述的场景，Kubernetes service有以下三种类型：1.ClusterIP：提供一个集群内部的虚拟IP（与Pod不在同一网段)，以供集群内部的pod之间通信使用。
2.NodePort：在每个Node上打开一个随机端口并且每个Node的端口都是一样的，通过<NodeIP>:NodePort的方式Kubernetes集群外部的程序可以访问Service。
3.LoadBalancer：利用Cloud Provider特有的Load Balancer对外提供服务，Cloud Provider负责将Load Balancer的流量导向Service。
本篇文章我们着重讲下第二种方式，也就是NodePort方式，修改nginx-svc.yml文件，也就是刚才前面创建的Service文件，相信细心的同学会发现在之前截图的时候已经做好了NodePort，因为我的环境已经配置好了所以这样就不在截图了，配置很简单，可以网上看下截图，就是添加一个type：NodePort，然后重新创建下nginx-svc，命令的话和创建的命令一样，我们来看看创建完事的结果。
如果刚开始你没有设置NodePort这个type的时候在端口那只会显示一个8080端口，而设置了之后会看到多了一个端口也就是31337，那8080大家斗志是cluster-ip监听的端口，那31337就是在节点上新起的一个端口，Kubernetes会从30000~32767中分配一个可用的端口，每个节点都会监听这个端口，并转发给Service，也就是防止说一个节点挂了影响访问。可能有人会问了，说这里的Service可不可以固定？当时可以了，可以在Service nginx-svc.yml文件里面添加一个nodeport。
最后我们可以验证下，我这里就不截图了，太长了。
curl x.x.x.x:31337那OK可能会有人说这个访问是随机的还是负载均衡的？答案是负载均衡的，依旧是采用iptables实现的，感兴趣的可以自己研究下iptables里面做的那些规则，这里就不再赘述了。
本文转自DockOne-深入玩转K8S之外网如何访问业务应用