# 先讲述一个k8s重要概念，我觉得这个概念是整个k8s集群实现微服务的最核心的概念
# Service
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是kubernetes最核心的概念，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求进行负载分发到后端的各个容器应用上。至于如何负载分发，我们不用去担心，k8s自己搞定。 简单来说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相当于微服务，各个服务之间灵活通信。
废话不多说，咱们直接实操演示 创建副本控制资源名为nginx-deployment，运行两个pod，每个pod运行一个nginx容器，容器端口开放80.
[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
创建Service 池化刚才的两个nginx pod
[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方式，修改nginx-svc.yml文件，也就是刚才前面创建的Service文件，相信细心的同学会发现在之前截图的时候已经做好了NodePort，因为我的环境已经配置好了所以这样就不在截图了，配置很简单，可以网上看下截图，就是添加一个type：NodePort，然后重新创建下nginx-svc，命令的话和创建的命令一样，我们来看看创建完事的结果。
如果刚开始你没有设置NodePort这个type的时候在端口那只会显示一个8080端口，而设置了之后会看到多了一个端口也就是37884，那8080就是是cluster-ip监听的端口，那37844就是在node节点上新起的一个端口(K8s会从30000~32767中分配一个可用的端口)，只用于端口转发，转发到service的端口。 <用户访问服务，每个节点都会监听这个端口，并转发给Service，service负载均衡调度后端pod,也就是防止说一个节点挂了影响访问>。 说的再通俗一点，集群内部可以直接通过service的ip+端口访问，而nodeport就是为了外网访问服务，给node开了一个端口，转发到service的ip+端口。 可能有人会问了，说这里的Service可不可以固定？当时可以了，可以在Service nginx-svc.yml文件里面添加一个nodeport。
当然，这个访问依然是负载均衡的！
# 外部访问Kubernetes中的Pod
前面几节讲到如何访问kubneretes集群，本文主要讲解访问kubenretes中的Pod和Serivce的几种方式，包括如下几种：
- hostNetwork
- hostPort
- NodePort
- LoadBalancer *Ingress 说是暴露Pod其实跟暴露Service是一回事，因为Pod就是Service的backend。
# hostNetwork: true
这是一种直接定义Pod网络的方式。
如果在Pod中使用hostNotwork:true配置的话，在这种pod中运行的应用程序可以直接看到pod启动的主机的网络接口。在主机的所有网络接口上都可以访问到该应用程序。以下是使用主机网络的pod的示例定义：
apiVersion: v1 kind: Pod metadata: name: influxdb spec: hostNetwork: true containers: - name: influxdb image: influxdb 部署该Pod：
$ kubectl create -f influxdb-hostnetwork.yml 访问该pod所在主机的8086端口：
curl -v http://$POD_IP:8086/ping 将看到204 No Content的204返回码，说明可以正常访问。
注意每次启动这个Pod的时候都可能被调度到不同的节点上，所有外部访问Pod的IP也是变化的，而且调度Pod的时候还需要考虑是否与宿主机上的端口冲突，因此一般情况下除非您知道需要某个特定应用占用特定宿主机上的特定端口时才使用hostNetwork: true的方式。
这种Pod的网络模式有一个用处就是可以将网络插件包装在Pod中然后部署在每个宿主机上，这样该Pod就可以控制该宿主机上的所有网络。
# hostPort
这是一种直接定义Pod网络的方式。
hostPort是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上来访问Pod了，如:。
apiVersion: v1 kind: Pod metadata: name: influxdb spec: containers: - name: influxdb image: influxdb ports: - containerPort: 8086 hostPort: 8086 这样做有个缺点，因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动，这样就变化了，用户必须自己维护一个Pod与所在宿主机的对应关系。
这种网络方式可以用来做 nginx ingress controller。外部流量都需要通过kubenretes node节点的80和443端口。
# NodePort
NodePort在kubenretes里是一个广泛应用的服务暴露方式。Kubernetes中的service默认情况下都是使用的ClusterIP这种类型，这样的service会产生一个ClusterIP，这个IP只能在集群内部访问，要想让外部能够直接访问service，需要将service type修改为 nodePort。
apiVersion: v1 kind: Pod metadata: name: influxdb labels: name: influxdb spec: containers: - name: influxdb image: influxdb ports: - containerPort: 8086 同时还可以给service指定一个nodePort值，范围是30000-32767，这个值在API server的配置文件中，用--service-node-port-range定义。
kind: Service apiVersion: v1 metadata: name: influxdb spec: type: NodePort ports: - port: 8086 nodePort: 30000 selector: name: influxdb 集群外就可以使用kubernetes任意一个节点的IP加上30000端口访问该服务了。kube-proxy会自动将流量以round-robin的方式转发给该service的每一个pod。
这种服务暴露方式，无法让你指定自己想要的应用常用端口，不过可以在集群上再部署一个反向代理作为流量入口。
# LoadBalancer
LoadBalancer 只能在service上定义。这是公有云提供的负载均衡器，如AWS、Azure、CloudStack、GCE等。
kind: Service apiVersion: v1 metadata: name: influxdb spec: type: LoadBalancer ports: - port: 8086 selector: name: influxdb 查看服务：
$ kubectl get svc influxdb NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE influxdb 10.97.121.42 10.13.242.236 8086:30051/TCP 39s 内部可以使用ClusterIP加端口来访问服务，如19.97.121.42:8086。
外部可以用以下两种方式访问该服务：
使用任一节点的IP加30051端口访问该服务 使用EXTERNAL-IP来访问，这是一个VIP，是云供应商提供的负载均衡器IP，如10.13.242.236:8086。 Ingress Ingress是自kubernetes1.1版本后引入的资源类型。必须要部署 Ingress controller 才能创建Ingress资源，Ingress controller是以一种插件的形式提供。Ingress controller 是部署在Kubernetes之上的Docker容器。它的Docker镜像包含一个像nginx或HAProxy的负载均衡器和一个控制器守护进程。控制器守护程序从Kubernetes接收所需的Ingress配置。它会生成一个nginx或HAProxy配置文件，并重新启动负载平衡器进程以使更改生效。换句话说，Ingress controller是由Kubernetes管理的负载均衡器。
Kubernetes Ingress提供了负载平衡器的典型特性：HTTP路由，粘性会话，SSL终止，SSL直通，TCP和UDP负载平衡等。目前并不是所有的Ingress controller都实现了这些功能，需要查看具体的Ingress controller文档。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: influxdb spec: rules: - host: influxdb.kube.example.com http: paths: - backend: serviceName: influxdb servicePort: 8086 外部访问URL http://influxdb.kube.example.com/ping 访问该服务，入口就是80端口，然后Ingress controller直接将流量转发给后端Pod，不需再经过kube-proxy的转发，比LoadBalancer方式更高效。
# 总结
总的来说Ingress是一个非常灵活和越来越得到厂商支持的服务暴露方式，包括Nginx、HAProxy、Traefik，还有各种Service Mesh，而其它服务暴露方式可以更适用于服务调试、特殊应用的部署。
# 参考
Accessing Kubernetes Pods from Outside of the Cluster - alesnosek.com