k3s功能拓展——Service LB Controller
发布网友
发布时间:2022-11-26 04:12
我来回答
共1个回答
热心网友
时间:2023-10-10 13:21
Service LB Controller借用类型为 LoadBalancer 的 Service API,工作原理如下
1、svc-controller watch到service类型为LoadBalancer时,自动创建一个Daemonset;
2、默认Daemonset会部署到每个节点,如果任意Node设定了label svccontroller.k3s.cattle.io/enablelb=true,则只在拥有这个label的node上创建DS的pod;
3、对于某个部署的节点,一个LB port只会对应一个POD, 端口不能重复使用;
4、若创建失败或无可用端口时,service的状态为Pending
下面通过实操来理解Service LB Controller(以grafana为例)
基础环境:
k3s-server:172.27.137.56
k3s-agent:172.27.137.232
grafana service类型为ClusterIP
修改grafana的类型为LoadBalancer,并且为了保证port唯一,从80修改为9090。自动生成EXTERNAL-IP
在EXTERNAL-IP通过netstat -lntp看不到对9090的监听,因为EXTERNAL-IP所在node对9090端口是转发,所以只能通过iptables -t nat -nL | grep 9090中查看对所有9090端口的访问流量经过DNAT后的目标IP
目标IP为新创建的daemonsets在k3s-service的pod
进入pod查看流量的下一步转发,目标IP正是grafana的cluster-ip,自此流量顺利进入
另外,k3s-agent上同样也有对9090端口的DNAT转发,转发至daemonsets在k3s-agent的pod,最终转发至grafana的cluster-ip。所以实际上grafana对应的EXTERNAL-IP应该是有两个,一个是k3s-server的IP,另一个是k3s-agent的IP
总结:
每产生一个类型为 LoadBalancer 的 Service,则会自动部署daemonsets(根据node的lable选择部署节点),每个node的iptables会增加对port的DNAT转发,转发至本节点上的svclb pod,再由此pod转发至目标Service Cluster-IP
另外,Service LB Controller会为每个LoadBalancer 创建Daemonsets,所以若对外提供大量Service访问,会自动创建对应数量的pod,但由于svclb的镜像rancher/klipper-lb是个很小的镜像,主要作用就是提供iptables转发流量至集群内部,所以对性能负担影响不大,但在管理上会增加更多的pod管理