k8s内部的服务注册主要是依靠几个组件

coreDns,service和pod的标签选择器。

服务注册的流程

pod创建完以后，一般我们都会打算一组标签，标签是key/value形式的,如下
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test    #这里给这个pod打上标签
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    envir: live  #这里其实也是标签选择，选择匹配的node节点上部署pod
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  type: NodePort      #这里代表是NodePort类型的
  ports:
  - port: 80          #这里的端口和clusterIP(10.97.114.36)对应，即        10.97.114.36:80,供内部访问。
    targetPort: 80  #端口一定要和container暴露出来的端口对应，nodejs暴露出来的端口是8081，所以这里也应是80
    protocol: TCP
    nodePort: 32143   # 所有的节点都会开放此端口，此端口供外部调用。
  selector:
    env: test   # 这里就是通过标签选择器，把对应的pod对外暴露成服务
这里会生成一个Pod，对应有一个docker ip，当然可以给pod多个副本，pod就有多个
ip，service也有会有一个ip，叫cluster-ip，cluster-ip就是这一组pod对外提供服务的接
口ip，你可以在k8s内部通过cluster-ip访问服务，k8s通过iptables轮询访问cluster-ip对
应的pod服务。
    当然因为pod可能会down机，k8s会重新生成一个新的Pod，ip也会变，但是对应的
cluster-ip不会变，所以新的访问请求过来还是会打到新的pod上，在就是微服务在
K8S里的注册流程。

k8s内的服务间的调用
我们可以通过前面的cluster-ip进行服务间的调用，但是有个问题，一般ip都比较难记
而且如果我们的service也重启的话，也会生成一个新的cluster-ip
所以这里又增加了一个新的组件 coreDNS
coreDNS的作用就是相对于K8s里的一个域名解析服务器
比如我的服务名叫nginx，我的cluster-ip是10.0.96.10，
这样我在k8s内部ping nginx 就相当于ping 10.0.96.10
他会把 nginx和10.0.96.10进行域名绑定，
当你的新的service重启生成新的ip后，coreDNS会将域名和IP重新绑定
所以当你程序里通过http://nginx:8080调用其服务的时候，
首先回去coreDNS将nginx解析成10.0.96.10,在调用其服务