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 这类方法性状确定会非常非常差，如图。1、在客户端拜访我们k8s服务时，四层调度器本身是没有方法消除ssl会话的
