k8s上service是用来解决Pod访问问题，它是通过kube-proxy在每个节点上创建iptables规则或ipvs规则，在用户请求某个pod时，用户的请求会被其service规则所捕获，从而实现访问对应pod。
对于service来讲，用户请求直接在传输层就被捕获转发，效率很高效，但这同时也引入了一个新问题：比如我们运行的pod对外客户端访问需要https通信，如果使用service这种4层调度，那就意味着每个pod上我们要配置证书，这很显然不是我们想要做的；那有没有什么办法做到在用户访问pod对应的service时使用https，而对应pod里又不用https协议呢？答案是有的：比如我们可以使用nginx来做https会话卸载器；我们只需要在代理上配置证书即可；又比如我们在k8s上运行了各种各样的pod，这些pod的功能每个都不一样，有的是专门处理用户认证的，有的是专门处理站点主页的，有的专门处理支付的等等，而这些pod对外都是提供一个独有的url，那么这些pod需要怎么才能被集群外部访问到呢？
我们知道对于一个站点来讲，如果后端有多个server同时提供一种服务，我们可以把这些同功能的server定义成一个组，然后使用nginx代理将不同功能url的访问代理到不同组上即可；这样一来就解决了后端多server被负载访问的问题；那么对于k8s上这种同功能的pod怎么归并成一个组呢？用户访问不同url怎么调度到不同的组上呢？很显然要想实现这些功能，在k8s上应该有一个类似nginx一样的代理存在，这个代理就叫做ingress 控制器。
ingress 控制器和k8s上的其他控制不一样，ingress控制器并不能直接运行为kube-controller-manager的一部分，它类似k8s集群上的coredns，需要在集群上单独部署，本质上就是一个pod，我们可以使用k8s上的ds或deploy控制器来创建它；ingress controller pod的作用主要是引入集群外部流量，并实时监控着apiserver上ingress资源的变动，并将其ingress中定义的规则转化为对应ingress控制器对应应用程序的专有配置，然后动态的重载或重启对应守护进程来使其配置文件生效；在k8s上ingress是一种标准资源，它本质上就是我们定义的基于dns名称（host）或url路径把请求转发至指定service资源的规则；简单讲ingress就是我们用来定义代理的配置所创建的资源；ingress控制器就是把对应ingress规则转换为对应ingress控制器中应用程序的专有配置，然后重启或重载对应配置文件使其生效的组件。
ingress和ingress controller pod的关系
提示：如上图所示，ingress就是ingress 控制器pod的代理规则；用户请求某个后端pod所提供的服务时，首先会通过ingress controller pod把流量引入到集群内部，然后ingress controller pod根据ingress定义的规则，把对应ingress规则转化为对应ingress controller pod实现的对应应用的配置（ingress controller 可以由任何具有七层反向代理功能的服务实现，比如nginx,haproxy等等）然后再适配用户请求，把对应请求反代到对应service上；而对于pod的选择上，ingress控制器可以基于对应service中的标签选择器，直接同pod直接通信，无须通过service对象api的再次转发，从而省去了用户请求到kube-proxy实现的代理开销（本质上ingress controller 也是运行为一个pod，和其他pod在同一网段中）。