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管理
