KubeSphere 社区开源负载均衡器 Porter** **进入 CNCF 云原生全景图



  • KubeSphere 社区开源负载均衡器 Porter** **进入 CNCF 云原生全景图

    正文:

    近日,KubeSphere 社区子项目面向物理机环境中的负载均衡器 Porter (https://porterlb.io) 正式进入 CNCF Landscape。CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择,Porter 进入 CNCF Landscape,意味着 Porter 正式成为了 CNCF 认可的构建云原生最佳实践中的一环。

    替代文字

    云原生计算基金会(CNCF ,Cloud Native Computing Foundation)致力于云原生技术的普及和可持续发展。在每年的 CNCF 年度报告中都会提及 CNCF Landscape,CNCF Landscape 是 CNCF 中的一个重要项目,帮助企业和开发人员快速了解云原生体系的全貌,同时,也受到广大开发者和使用者对该项目的关注和重视。CNCF Landscape 意图从云原生的层次结构,以及不同的功能组成上,让用户了解云原生体系的全貌,并帮助用户在不同组件层次去选择恰当的软件和工具进行支持(https://landscape.cncf.io/)。


    CNCF Landscape 全景图

    新晋 CNCF Landscape 的 Porter,解决什么问题?

    在 Kubernetes 集群中可以使用 Load Balancer 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 Load Balancer 插件,但这需要将集群部署在特定 IaaS 平台上。

    然而,许多企业用户通常都将 Kubernetes 集群部署在物理机上,尤其是用于生产环境或数据敏感的环境。而且对于本地物理机集群,Kubernetes 不提供 LoadBalancer 的解决方案。

    Porter 是 KubeSphere 社区开源的专为物理机 Kubernetes 集群暴露服务而设计的开源的负载均衡器,为用户提供在物理环境暴露服务和在云上暴露服务一致性体验的插件。

    Porter 主要特性

    面向物理机环境的 Kubernetes 开源负载均衡器 Porter 主要特性有:

    • 基于路由器 ECMP 的负载均衡
    • 基于 Layer 2 的负载均衡
    • 基于 BGP 路由动态配置
    • 支持 VIP 管理
    • 支持在 Kubernetes Service 中指定 LoadBalancerIP (v0.3.0)
    • 支持通过 Helm Chart 安装(v0.3.0)
    • 支持通过 CRD 动态配置 BGP 服务端(v0.3.0)
    • 支持通过 CRD 动态配置 BGP 对等体(v0.3.0)

    与 MetalLB 的区别

    优点

    • 对 Kubernetes 用户友好。基于 CRD-Controller 模式,使用 kubectl 控制 Porter 的一切
    • 配置文件动态更新,无需重启,自动更新BGP配置。根据网络环境灵活配置BGP,动态启用各种BGP特性
    • 更友好的处理与Calico的冲突,提供Passive模式和端口转发模式

    缺点

    • 无法跨平台,仅支持 Linux

    Kubernetes 服务

    在 Kubernetes 集群中,网络是非常重要的基础设施。对于大规模的节点和容器来说,要保证网络的连通性、网络转发的高效,同时能做的 IP 和 Port 自动化分配和管理,并提供给用户非常直观和简单的方式来访问需要的应用,这是非常复杂且细致的设计。

    Kubernetes 本身在这方面下了很大的功夫,它通过 CNI、Service、DNS、Ingress 等一系列概念,解决了服务发现、负载均衡的问题,也大大简化了用户的使用和配置。其中的 Service 是 Kubernetes 微服务的基础,Kubernetes 是通过 kube-proxy 这个组件来实现服务的。kube-proxy 运行在每个节点上,监听 API Server 中服务对象的变化,通过管理 iptables 来实现网络的转发。用户可以创建多种形式的 Service,比如基于 Label Selector 、Headless 或者 ExternalName 的 Service,kube-proxy 会为 Service 创建一个虚拟的 IP(即 Cluster IP),用于集群内部访问服务。

    暴露服务的三种方式

    如果需要从集群外部访问服务,即将服务暴露给用户使用,Kubernetes Service 本身提供了两种方式,一种是 NodePort,另外一种是 LoadBalancer。另外 Ingress 也是一种常用的暴露服务的方式。

    NodePort

    如果将服务的类型设置为 NodePort,kube-proxy 就会为这个服务申请一个 30000 以上的端口号(默认情况下),然后在集群所有主机上配置 IPtables 规则,这样用户就能通过集群中的任意节点加上这个分配的端口号访问服务了,如下图

    NodePort 是最方便的暴露服务的方式,缺点也很明显:

    1. 基于 SNAT 进行访问,Pod 无法看到真正的 IP。
    2. NodePort 是将集群中的一个主机作为跳板访问后端服务,所有的流量都会经过跳板机,很容易造成性能瓶颈和单点故障,难以用于生产环境。
    3. NodePort 端口号一般都是用大端口,不容易记忆。

    NodePort 设计之初就不是用于生产环境暴露服务的方式,所以默认端口都是一些大端口。

    LoadBalancer

    LoadBalancer 是 Kubernetes 提倡的将服务暴露给外部的一种方式。但是这种方式需要借助于云厂商提供的负载均衡器才能实现,这也要求了 Kubernetes 集群必须在云厂商上部署。在物理机部署的 Kubernetes 环境则需要 Porter 来解决服务暴露的问题。

    LoadBalancer 的原理如下:

    LoadBalancer 通过云厂商的 LB 插件实现,LB 插件基于 Kubernetes.io/cloud-provider 这个包实现,这个包会自动选择合适的后端暴露给 LB 插件,然后 LB 插件由此创建对应的负载均衡器,网络流量在云服务端就会被分流,就能够避免 NodePort 方式的单点故障和性能瓶颈。LoadBalancer 是 Kubernetes 设计的对外暴露服务的推荐方式,但是这种方式仅仅限于云厂商提供的 Kubernetes 服务上,对于物理部署或者非云环境下部署的 Kubernetes 集群,这一机制就存在局限性而无法使用。

    Ingress

    Ingress 并不是 Kubernetes 服务本身提供的暴露方式,而是借助于软件实现的同时暴露多个服务的一种类似路由器的插件。Ingress 通过域名来区分不同服务,并且通过 annotation 的方式控制服务对外暴露的方式。其原理如下图:

    KubeSphere 开源实践

    作为云原生领域的生态平台,KubeSphere 坚持完全开源和开放的迭代思路,联合国内、国际企业与开源社区,共同打造了以 KubeSphere 容器平台为核心的开源项目。

    除了将 Porter 贡献到 CNCF 云原生全景图之外,KubeSphere 还开源了 OpenPitrix 多云应用管理、KubeKey 安装向导包、Kube-events、Fluent-bit Operator、Notification Manager、CSI 插件等 80 余个开源项目。

    快速部署和体验 Porter

    完全开源

    Porter 的所有代码和文档已在 Github 开源,欢迎大家关注 (Star) 和贡献:https://github.com/kubesphere/porter

    快速部署

    Porter 目前已在如下三种环境下进行过部署和测试,并将部署测试与使用步骤的详细文档记录在 GitHub,可以通过以下链接查看和部署实践:

    最新动态

    Porter 将在本月中旬发布新版本 v0.3.0,新版本由青云QingCloud、本来生活和北京吉恒科技三家公司联合开发,由社区定义与贡献,新版本的主要功能已在文中 Porter 介绍中标注,欢迎大家安装体验!

    延伸阅读


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待