第一步，先了解一次http请求从外部到K8S集群后的分发过程：
1、http请求根据域名解析到达对应的主机（途中Nginx-ingress-controller所在机器）
2、该主机Nginx-ingress-controller是主机网络部署（yaml中hostnetwork=true），监听80
3、Nginx收到请求后，通过ingress-controller过滤K8S集群中的ingress，根据ingress配置的rule查询是否匹配
4、如果匹配则转发请求到对应ingress配置的服务（在K8S集群内）
5、如果未匹配则直接转发至back-end（Nginx-ingress-controller的daemonSet yaml中配置）
问题1：Ingress的配置如何更新
ingress-controller会定期通过k8s api server更新当前已有的ingress（不用重启服务的情况下修改路由规则）
问题2：Nginx-ingress-controller和ingress、nginx、ingress-controller啥关系
较早版本中ingress、nginx、ingress-controller是分离的，nginx接收请求，ingress-controller负责更新ingress，ingress配置独立的路由规则，后来版本将nginx和ingress-controller合并为Nginx-ingress-controller
问题3：转发请求的时候，如何实现LB
请求转发发生在识别到ingress或通过back-end转发，这两部分配置的均为K8S的Service（简称svc），LB通过svc到pod来实现（后续详细说）
================================================================================================
分割线
以上，简单描述了一个http请求如何到达k8s内的pod提供的服务，但是在一个完整的http请求中，kube-proxy/kube-dns/iptables/eureka在哪个环节分别发生什么作用，并未解释清楚，下面先描述第一种情况：
不考虑springCloud相关配件，集群内外的调用流程、LB是如何实现的。
在不考虑springCloud套件的情况下，几个主要需要搞清楚的问题是：
1、服务发现怎么做
2、请求流转有哪些环节
3、网关在哪里
4、LB怎么实现
服务发现：
kube-dns是一中svc，内部运行4个container，数据在etcd持久化，通过定期查询k8s api server，更新当前所有的svc名称以及对应的cluster ip，因此，当集群内部通过一个服务名称（svc的名称）访问接口时，如何通过服务名找到对应的svc的cluster ip，这个就是kube-dns来做的（/etc/resolv.conf中配置DNS地址），例如：集群内的podA访问svcB，可以直接通过svcB的名字直接访问，则请求发出后首先会访问pod本地的kube-dns服务，该服务即会返回svcB的cluster IP，所以请求就找到了svcB的ip地址
网关：
域名节点的80端口就是所有请求的总入口，在该节点上的主机网络模式的nginx-ingress-controller就是总入口，通过对nginx-ingress-controller的back-end配置或rule的配置，可以实现流量的网关过滤功能（定向到一个svc）
请求流转环节：
第一种，集群外访问集群内的情况：
1、请求通过主机网络直接进入nginx-ingress-controller，并转发向一个网关服务svc
2、请求通过kube-dns解析，获得svc对应的cluster ip
3、cluster ip + 端口号作为输入，经过iptables，最终执行一个pod的ip +端口号
4、请求由服务端pod处理
第二种，集群内访问集群内的情况：
1、请求由一个pod发出，请求地址url中包含一个svc的名称
2、请求通过kube-dns解析（此时没有通过ribbon+eureka），获得svc对应的cluster ip
3、cluster ip + 端口号作为输入，经过iptables，最终执行一个pod的ip +端口号
4、请求由服务端pod处理
LB实现：
接着上面的例子来讲，k8s内的LB最终的落点都是pod，因此是通过svc这一层来实现的，通过kube-dns找到了svcB的cluster IP，svcB要怎么做LB？svc只是一个逻辑服务对象，无任何LB能力，请求从物理层面来看也不会转发到svcB，但是在svcB中定义了endpoint，endpoint代表了一组svc到pod的定义，当pod发生重启/驱离导致ip发生改变时，endpoint不变，endpoint的指向ip会更新，因此endpints对于svc来说是稳定的存在，在此基础上，LB是通过iptables来实现的，在K8S集群内，所有节点的iptables内都记录了从svc映射到对应pod的关系，因此，向svcB的cluster IP发送的请求都会转向iptables中配置的pod对象的ip，LB发生在这里（iptables本身的LB不做详细描述），由此可见，K8S集群内部的LB是通过iptables来实现，iptables规则的更新则是通过kube-proxy来实现，kube-proxy的更新数据来源则是通过k8s api server查询获得（service/endpoints信息）
可以总结为几点：
1、LB是通过iptables实现
2、iptables更新是通过kube-proxy实现
3、更新数据来源是svc+endpoints
4、根据svc名称找到对应svc的cluster ip是通过kube-dns实现
5、每个node上都部署了kube-dns、kube-proxy，作用就是集群内域名解析、节点的iptables更新
6、kube-dns的数据来源也是通过k8s api server获得（service的名称和对应的cluster ip）
7、外部服务也可以通过手工修改endpoints + 去掉label selecter的方法加入集群
PS：网上看到的很多文章，有一点没有重点提到，就是svc、endpoints、kube-proxy在一次请求的运行态过程中其实没有直接参与，都是通过iptables进行实际请求转发的；而kube-dns在一次请求的运行态过程中是直接参与的（根据svc名称找到svc的cluster ip）
K8S相关的流程基本如上，还少了一部分weave的内容，后续再做补充。
这里再补充一张图，说明集群内部调用的关系。
差不多涉及到的概念以及一次请求涉及的对象如下：
================================================================================================
分割线
和K8S服务发现、LB类似的是springCloud，很容易和K8S的这要流程混淆，其实是两条分支。
从功能上讲，K8S的LB、服务发现与springCloud的eureka、ribbon非常类似，功能基本一样，但是在实际使用过程中，由于netflix这一套东西基于spring，开发起来很简单，比去理解K8S这一套成本要低，开发效率要高，很多功能通过注解就可以实现，从开发角度易用性来看比K8S这套要好一些，因此springCloud的服务发现、LB是基于在K8S上运行一套服务治理套件，还是从一次http请求来分解看。
图就不单独画了，上面的图中有。
来自集群外部的请求：
不涉及，集群外部的请求都是通过DNS到主机，再到主机上监听端口的进程来实现的，这部分用的就是主机网络的pod
来自集群内部的请求：
这部分就是eureka、ribbon、zuul等套件生效的地方，分为两步：
1、服务启动时，依赖的eureka-client-start会注册到集群内的eureka-server上
a.eureka server作为一个svc在k8s运行
b.服务启动后，通过svc的名称找到eureka，从而完成注册，这一过程又是通过上述的k8s的dns流程实现的
c.注册完成后，定期会通过心跳上报和更新全量eureka的副本集
2、服务使用@loadbalance的resttemplete对象发送http请求
a.resttemplete通过本地存储的eureka server上的副本集，找到对应的instance
b.如果一个instance查询出了多个实例，此时会通过ribbon做LB，找到一个对应的副本
c.对应副本中可以注册ip和端口或者服务名称，通过ip和端口进行访问，此时的请求是直接到pod的，不通过k8s的svc，也就是说直接通过iptables进行转发到pod的ip地址；如果副本注册是按照服务名注册，则要通过dns找到对应的svc的cluster ip，再到endpoint，最终指向pod
PS：loadbalance本身也是netflix家族一部分，和ribbon是可以天然集成的，ribbon应该被理解为一个本地用以计算LB结果的组件。
