linuxea:kubernetes Ingress Controller (15)


无论service还是ipvs都是四层调度,四层调度工作在七层模型的第四层,如果用户访问https,那么四层是无法解析https回话,如果要使用https便只能在后端pod配置https来使用https,这样一来,那便意味着客户端与后端服务器之间直接建立ssl会话(图1),此刻,如果下一个请求被调度到第二个pod,那么这个会话需要重新建立(2)

倘若后端到调度器之间的网络上安全的,https会话可以在前端负载卸载,就需要七层负载均衡机制。那么在互联网到七层负载之间使用https,在7层负载到pod之间使用http,如下图3

在service调度中,clusterIP使用的是ipvs和iptables,无论哪种方式都是四层,且无法卸载会话

I. 引入

在集群中调度时,后端被调度的pod是http的,使用一个独特的七层调度器(pod),如nginx,haproxy

当用户访问某一个服务时,先请求到集群外部的Loadbalanocer(假如你有的话),而后到各个Node IP:nodePort,而后转发到service ClusterIP,由ClusterIP DNAT到7层调度的pod。而后才会到后端pod(每台node中都会有一个flannel网卡桥接到pod网段中,那便意味着node能够和pod进行通讯)。由调度的pod(nginx,配置的https服务)反代到后端提供服务的http pod。如下:

如上图:由此一来,调度便三次以上,性能过于损耗。可直接共享节点网络名称空间,监听宿主机IP地址。这样一来集群外部直接访问宿主机IP(nodeip:port)和端口(此前的hostNetwork)就能直接处理请求了。如下图:

但是,这样一来,访问就只能访问一个固定的单节点(和service不同,7层Proxy pod要监听节点的网络名称空间,并且请求也是通过网络名称空间直达此pod)。

II. DaemonSet

DaemonSet控制器可以在每个节点上都运行一个pod,且每个节点只运行一个,每一个pod都能实现负载均衡。并且任何一个节点宕机,只要调度器能够做健康状态检测仍然不受影响。DaemonSet可配置

一旦确定节点数量,则可以使用标签选择器打标,并且打上污点(将不会被调度),DaemonSet并且可以容忍这些污点,每个节点只运行这一个反代pod用来接入流量,这类pod在kubernetes中称为Ingress Controller

III. Ingress Controller

Ingress Controller和之前的DaemonSet等都不一样,在kubernetes中有4个重要组件分别是api server,ectd,scheduler,controller-manager。其中DaemonSet,ReplicaSet,Deployment等是作为controoler-manager的一部分存在的。但是Ingress Controller却是独立运行的一组pod资源,通常就是一组应用程序,并且拥有七成代理和调度的应用程序。

由此有4种选择,Haproxy,Nginx,Envoy,Traefik可作为调度手段

倘若在调度的过程中不止要调度一个服务,可做URL映射,分别使用不同的URL路径来映射到对应的pod中。但是我们之前介绍过,pod是存在生命周期,可能随时都会挂掉,随时也都会被替换成新的pod,然而每个新的pod地址会随之发生变化。并且pod集群的大小会随着业务动态伸缩而发生改变。

在之前的service中是通过service标签选择器关联标签,service始终关注api server中的api,只要资源发生变化就会通知这个service,service立即做出改变。service通过labels始终关联着对应labels适配的后端pod

假如这个pod调度器(Ingress Controller)运行的是nginx,配置文件也是在pod内部,且后端服务pod(被代理资源)时常会发生变动,那么nginx(Ingress Controller)如何得知后端pod变动的资源信息呢?如下:

Ingress Controller本身是无法做到后端被代理资源信息的收集,收集这些信息便是service。每一个upstream组对应一个service资源,每一个service资源关联到相应的pod上。尤为注意的是这里的这个service并不是当作代理节点,仅仅作为分类(将pod和service信息进行分组,协助调度,调度并不经过service),分类后得到的并不是service的ip,而是pod的ip。如果pod资源发生改变,这些信息通过ingress资源反应到Ingress Controller pod中的nginx配置文件(动态注入到配置文件)中。也就是说如果后端被代理节点发生改变,信息反应到ingress(信息包括IP地址等),ingress会及时的将这些信息注入到Ingress Controller pod(nginx upstream)中,并且触发主容器进程重载配置文件。这是动态的修改,如上图。当然,nginx并不能天生做到配置文件变动重载,需要借助其他工具。而Envoy,Traefik则可以!

0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-10-01分类: kubernetes

标签: kubernetes

发表评论