首先 Service是一种k8s集群中访问pod的策略。k8s中的pod具有生命周期，且不可复活。每个pod有着自己的IP地址，pod的销毁与创建都会创新的IP地址。Service就是用来统一管理跟踪这些pod的变化，即使pod发生变化，对于前台的调用是无感知，前台无需进行任何修改。service肩负着服务发现与负载均衡等职能。
首先创建一个pod，标签为web（后续的service是通过匹配这个标签来实现管理pod的）
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep01
spec:
selector:
matchLabels:
app: web
replicas: 2
template:
metadata:
labels:
app: web
spec:
containers:
- name: testnginx9
image: daocloud.io/library/nginx
ports:
- containerPort: 80创建出来的pod如下
再创建一个svc，这里的svc端口暴露方法有多种。集群内部访问通过8080，外部访问通过30001，流量过来时则是转发到80上
- port
- port是暴露在cluster ip上的端口，port提供了集群内部客户端访问service的一个虚拟ip。可以进入pod后用分配到的这个ip:port
- nodeport
- nodePort 提供了集群外部客户端访问 Service 的一种方式，相当于给每个pod在其对应的主机上开了个访问端口，nodePort 提供了集群外部客户端访问 Service 的端口，通过 nodeIP:nodePort 提供了外部流量访问k8s集群中service的入口。
- targetPort
- targetPort是pod的端口，从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上，最后进入容器。
- containerPort
- containerPort是pod内部容器的端口，targetPort映射到containerPort。
apiVersion: v1
kind: Service
metadata:
name: mysvc
spec:
type: NodePort
ports:
- port: 8080
nodePort: 30001
targetPort: 80
selector:
app: web创建出的svc如下：
首先查看nodepot的情况，把pod中nginx的index.html换了，看看访问30001时到底是哪个pod在提供服务,发现两者交替提供服务(刚开始发现一直是pod2在提供服务，后来想起来是nginx长连接未关闭，关闭后两者正常交替)
再看看port的情况，可以进入其中的一个pod，再去访问port分到的虚拟ip以及8080端口，结果还是两个pod交替提供服务
Ingress
ingress工作原理基本上如图，相当于一个七层全局的反向代理服务
上面的service是通过各种ip加端口的形式访问的服务，但是服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护，就有了一种以域名访问的方法，这个ingress就用于实现用域名的方式访问k8s内部应用。那么首先把ingress的包拉下来，官方下载地址国内访问慢，借助小工具下载下来。
下载完成后，还需要进入yml文件中，把image的拉取地址换成国内的，否则拉取缓慢或失败
然后用这个yml创建ingress，报错一大串，
查看错误，是”rbac.authorization.k8s.io/v1beta1″,版本没对上，我的版本是v1，改成了rbac.authorization.k8s.io/v1即可创建成功。
接下来创建两个apache和nginx进行测试
查看pod状态，两个tomcat和nginx都好了
接下来创建ingress来通过域名访问他们，
这个yml就是当访问： test.apache.ingress的时候，将由my-apache的svc处理；当访问：my-nginx时，交给my-nginx的svc来处理，看看创建的这个ingress
去浏览器访问试试，
ingress配置成功。