乐趣区

关于云计算:OpenELB-进入-CNCF-Sandbox让私有化环境对外暴露服务更简单

11 月 10 日,云原生计算基金会 (CNCF) 发表由青云科技 KubeSphere 团队开源的负载均衡器插件 OpenELB 正式进入 CNCF 沙箱(Sandbox)托管。

OpenELB 我的项目在此前命名为 PorterLB,是为物理机(Bare-metal)、边缘(Edge)和私有化环境设计的负载均衡器插件,可作为 Kubernetes、K3s、KubeSphere 的 LB 插件对集群外裸露“LoadBalancer”类型的服务,外围性能包含:

  • 基于 BGP 与 Layer 2 模式的负载平衡
  • 基于路由器 ECMP 的负载平衡
  • IP 地址池治理治理
  • 应用 CRD 进行 BGP 配置

为什么发动 OpenELB

咱们起初在 KubeSphere 社区做了一项针对宽广社区用户装置部署 Kubernetes 所应用环境的调研,从 5000 多份 KubeSphere 用户调研数据中发现有近 36% 的用户抉择在物理机装置部署 Kubernetes,占比高居第一位。并且还有大量客户是在离线的数据中心或边缘设施装置和应用 Kubernetes 或 K3s,导致用户在公有环境对外裸露 LoadBalancer 服务比拟艰难。

咱们晓得,在 Kubernetes 集群中能够应用“LoadBalancer”类型的服务将后端工作负载裸露在内部。云厂商通常为 Kubernetes 提供云上的 LB 插件,但这须要将集群部署在特定 IaaS 平台上。然而,许多企业用户通常都将 Kubernetes 集群部署在裸机上,尤其是用于生产环境时。而且对于私有化环境特地是物理机或边缘集群,Kubernetes 并不提供 LoadBalancer 计划。

OpenELB 解决了在非公有云环境的 Kubernetes 集群下对外裸露 LoadBalancer 服务的问题,为私有化环境的用户提供了易用的 EIP 与 IP Pool 治理能力。

社区状况

目前 OpenELB 已具备生产可用的个性,已有来自 原本生存、苏州电视台、视源股份、云智天下、Jollychic、QingCloud、百旺、Rocketbyte 等国内外多家企业采纳,早在 2019 年底 OpenELB 的晚期版本中就曾经在原本生存的生产环境应用,可参考👉OpenELB 如何帮忙原本生存在 K8s 物理环境裸露集群服务理解详情。OpenELB 我的项目目前有 13 位贡献者,100 多位社区成员。

与 MetalLB 的比照

MetalLB 在近期也退出了 CNCF Sandbox,该我的项目在 2017 年底发动,通过 4 年的倒退曾经在社区被宽泛采纳。OpenELB 作为后起之秀,采纳了更加 Kubernetes-native 的实现形式,尽管起步更晚但得益于社区的帮忙,曾经迭代了 8 个版本并反对了多种路由形式。很多用户关注 MetalLB 与 OpenELB 的差异性,以下简略介绍两者比照。

云原生架构

在 OpenELB 中,不论是地址治理,还是 BGP 配置管理,你都能够应用 CRD 来配置。对于习惯 Kubectl 的用户应用 OpenELB 将十分敌对,对于想定制 OpenELB 的高级用户,也能够间接调用 Kubernetes API 进行二次开发。在 MetalLB 中,需通过 ConfigMap 来配置,感知它们的状态须要通过查看监控或者日志。

灵便的地址治理

在 OpenELB 中,通过 EIP CRD 来治理地址,它定义子资源 Status 来存储地址调配状态,这样就不会存在调配地址时各正本发生冲突,编程时逻辑也会简略。

应用 gobgp 公布路由

不同于 MetalLB 本人实现 BGP 协定,OpenELB 采纳规范的 gobgp 来公布路由,这样做的益处如下:

  • 开发成本低,且有 gobgp 社区反对
  • 能够利用 gobgp 丰盛个性
  • 通过 BgpConf/BgpPeer CRD 动静配置 gobgp
  • gobgp 作为 lib 应用时,社区提供了基于 protobuf 的 API,OpenELB 在实现 BgpConf/BgpPeer CRD 时也是参照该 API,并放弃兼容。

同时,OpenELB 也提供 status 用于查看 BGP neighbor 配置,状态信息丰盛。

架构简略,资源占用少

OpenELB 目前只用部署 Deployment 即可,通过多正本实现高可用,只有不是全副正本 Crash,个别不会影响失常已建设的连贯。

BGP 模式下,Deployment 不同正本都会与路由器建设连贯用于公布等价路由,所以失常状况下咱们部署两个正本即可。在 Layer 2 模式下,不同正本之间通过 Kubernetes 提供的 Leader Election 机制选举 Leader,进而应答 ARP/NDP。

OpenELB 装置与应用

目前 OpenELB 可反对部署在任意规范的 Kubernetes、K3s 以及其发行版,通过 Yaml 文件或 Helm Chart 一条命令实现部署。同时,在 KubeSphere 容器平台的利用商店和利用仓库也能够通过界面一键部署,可参考文档 进行部署。

将来布局

得益于 CNCF 为我的项目提供了开源和中立的背书,OpenELB 也将真正变成一个由 100% 社区驱动的开源我的项目。接下来,OpenELB 将开发与实现如下性能,欢送给社区提交需要与反馈:

  • 基于 Keepalived 实现 VIP 模式的高可用
  • 实现 kube-apiserver 的 LoadBalancer
  • 反对 BGP 策略与配置
  • 反对 VIP Group
  • 反对 IPv6
  • 提供独立的界面治理与配置 EIP 与 IP Pool
  • 集成至 KubeSphere Console;提供 Prometheus metrics

OpenELB 还将重点发展社区经营并推出一系列社区活动,心愿借助更多开发者和用户的力量,解决用户在公有环境下的服务裸露与 IP 治理问题,为利用在 Kubernetes 上关上一扇大门,使服务对外裸露与治理变得更加轻松。

本文由博客一文多发平台 OpenWrite 公布!

退出移动版