K8S Ingress

  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在同一网段中)。

 

posted @ 2021-08-12 17:19  林锅  阅读(516)  评论(0编辑  收藏  举报