本文发布于Cylon的收藏册,转载请著名原文链接~

概述

在之前有一个系列提到了扩展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

1
2
3
$ 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

本文发布于Cylon的收藏册,转载请著名原文链接~

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

版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」 许可协议进行许可。