一、上集回顾
1、Service 3种模型：userspace，iptables,ipvs
2、Service类型
ClusterIP，NodePort
NodePort:client -> NodeIP:NodePort -> ClusterIP:ServicePort -> PodIP:containerPort
LoadBalancer
ExternelName
No ClusterIP: Hedless Service
serviceName -> PodIP
二、ingress
1、在客户端访问我们k8s服务时，四层调度器本身是没有办法解除ssl会话的，这就意味着客户端必须与后端服务器（pod）之间直接建立ssl会话，这里还有个显著的问题在于如果调度器在ssl会话建立以后的下一个请求被调度到第二台服务器上那么这个ssl还要重新建立，因此我们只要认为内部网络是安全的那么我们可以把会话在前端调度器上卸载，但是四层调度是不能卸载的，因此我们需要七层的负载均衡机制。因此如果他们是http服务我们又期望构建https，那么我们只需要他在互联网上这个不安全的网络中传输实现https，内网中使用http，因此我们需要使用卸载器，但是我们Service调度时，无论是iptables还是ipvs都只是四层调度，因此也就意味着如果你想要在k8s上运行一个应用基于https提供服务，我们就必须得在后端每一个pod上配置https，因为只有这样他们才会建立起https联系，所以我们现在也期望在接入那一层上就能够卸载ssl，向内部调度时就不再是ssl了。对这种需求，k8s采用一种很独特的方式来实现，我们在整个集群中，在进行调度时后端被代理的pod资源是不配置https的，就是明文的http，但是我使用一个独特的调度器（运行在pod中），对于此pod来讲，其是一个运行在七层（用户空间）的正常的应用程序，比如nginx,haproxy等，当用户试图访问某一服务时，我们不让他先去到达前端的service，而是先到这个pod，然后pod与pod之间不需要service而是直接通信来完成反向代理，我们用一个pod来反代至后端我们真正提供服务的pod，此前我们用service代理的，现在用pod，而这个pod如果需要被访问到那么还是需要经过service，因此客户端经过此pod的service调度以后，与我们专门配置了https的此pod进行交互，这里的service我们定义成nodePort，依然没有什么问题，依然老路径还是存在的，但是等到达这个pod以后由此pod直接代理至两个明文的pod，因此此pod就成为https的会话卸载器了。如果这种方式进行调度那么调度方式如下： client --> LB --> nodePort --> service -->会话卸载器pod --> 后端pod 这种方式性能肯定会非常非常差，如图。
2、其实我们还可以这样干，可以让我们pod直接共享我们节点的网络名称空间，于是，上述中的会话卸载器pod我们可以直接让他共享节点网络名称空间，这就意味着其监听着宿主机的地址，这样我们客户端的请求就可以之间到达这个pod，然后再由他进行调度。