扫盲Kubernetes负载均衡 - 从Ingress聊到LB

概述

在之前有一个系列提到了扩展proxier，但可能细心的同学注意到，作为一个外部的LB，市场上存在一些开源的为kubernetes集群提供的LB，这不是舍近求远吗？而 Google工程师 Adam Dunstan 的 文章 ^[1] 对比了这些LB的区别（中文翻译备份 ^[2] ），例如：

• MetalLB：最流行的 负载均衡控制器
• PureLB：新产品 (文章作者 Adam Dunstan 参与了 PureLB的开发工作)
• OpenELB：相对较新的产品，最初该LB仅关注路由方向

文章提出了一个LB实现的基本目标为：必要的简单网络组件，与可扩展的集群操作

• 启动受控的集群service/应用的外部访问
• 外部资源的预配置
• 易于整合自动化的工作流程（CI/CD）

那么这些LB与 kube-proxy 甚至于 IPVS/IPTables 有什么区别呢？

这些LB的核心是为集群service提供一个外部IP，而service功能本身还是由 kube-proxy,IPVS 提供，在这点 MetalLB 介绍中提到了这个问题

In layer 2 mode, all traffic for a service IP goes to one node. From there, kube-proxy spreads the traffic to all the service’s pods. ^[3]

After the packets arrive at the node, kube-proxy is responsible for the final hop of traffic routing, to get the packets to one specific pod in the service. ^[4]

通过kubernetes service 资源方向表示，是为EXTERNAL-IP部分分配一个IP地址，而从来不是说内部的LB

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   192.168.0.1     <none>        443/TCP   196d

关于MetalLb的使用可以参考视频：Set up MetalLB Load Balancing for Bare Metal Kubernetes

正如注解所说，工作与L2的模式下，流量会到达一个Node,接下来通过kube-proxy广播至所有的Pod，这种模式下是否可以做到HA，还有待测试。

接下来提到 Proixer，Proixer是对于集群（内）正常工作的一个保证，最基础的一点则是Kubernetes service 需要每个Pod可以访问到，所以 kube-proxy 则完全不同于 kubernetes LB

总结

Kubernetes LB是Kubernetes的扩展功能，主要特点体现在下列方面：

• LB 是要作用是为service提供一个外部IP
• 通常情况下，LB支持的都是 L2, L3 网络，而非传统的L4, L7 LB
• kube-proxy并不可以被这类LB所替代，因为这类LB的端点是到service
• 目前开源的 kube-proxy repleacement 应该只有 eBPF

Reference

^[1] Kubernetes Ingress 架构说明

^[2] 「译文」比较开源 k8s LoadBalancer-MetalLB vs PureLB vs OpenELB

^[3] METALLB IN LAYER 2 MODE

^[4] METALLB IN BGP MODE