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

近日，KubeSphere 社区子项目裸金属环境中的负载均衡器Porter（https://porterlb.io）正式进入 CNCF Landscape。

CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择，Porter 的进入，意味着 Porter 正式成为了 CNCF 认可的构建云原生最佳实践中的一环。

云原生计算基金会（CNCF,Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。

每年的 CNCF 年度报告中都会提及 CNCF Landscape，CNC FLandscape 是 CNCF 中的一个重要项目。

CNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持，受到广大开发者和使用者对该项目的关注和重视。

CNCF Landscape 全景图

新晋 CNCFLandscape 的 Porter
解决什么问题？

在 Kubernetes 集群中可以使用 Load Balancer 类型的服务将后端工作负载暴露在外部。

云厂商通常为 Kubernetes 提供云上的 Load Balancer 插件，但这需要将集群部署在特定 IaaS 平台上。

现实情况中，许多企业用户通常都将 Kubernetes 集群部署在物理机上，尤其是用于生产环境或数据敏感的环境。

然而，对于本地物理机集群，Kubernetes 不提供 Load Balancer 实施。

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

Porter 主要特性

面向裸金属环境的Kubernetes开源负载均衡器Porter主要特性有：

• 基于路由器 ECMP 的负载均衡

• 基于 Layer 2 的负载均衡

• 基于 BGP 路由动态配置

• 支持 VIP 管理

• 支持在 Kubernetes Service 中指定 Load Balancer IP

• 支持通过 Helm Chart 安装

• 支持通过 CRD 动态配置 BGP 服务端

• 支持通过 CRD 动态配置 BGP 邻居

与 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 中服务对象的变化，通过管理 ip tables 来实现网络的转发。

用户可以创建多种形式的 Service，比如基于 LabelSelector 、Head less 或者 External Name 的Service，kube-proxy 会为 Service 创建一个虚拟的 IP（即ClusterIP），用于集群内部访问服务。

暴露服务的三种方式

如果需要从集群外部访问服务，即将服务暴露给用户使用， Kubernetes Service 本身提供了两种方式：

另外 Ingress 也是一种常用的暴露服务的方式。

Node Port

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

Node Port 是最方便的暴露服务的方式，缺点也很明显：

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

Load Balancer

Load Balancer 是 Kubernetes 提倡的将服务暴露给外部的一种方式。但是这种方式需要借助于云厂商提供的负载均衡器才能实现，这也要求了 Kubernetes 集群必须在云厂商上部署。

在物理机部署的 Kubernetes 环境则需要 Porter 来解决服务暴露的问题。

Load Balancer 的原理如下：

Load Balancer 通过云厂商的 LB 插件实现，LB 插件基于Kubernetes.io/cloud-provider 这个包实现，这个包会自动选择合适的后端暴露给 LB 插件，然后 LB 插件由此创建对应的负载均衡器，网络流量在云服务端就会被分流，就能够避免 Node Port 方式的单点故障和性能瓶颈。

Load Balancer 是 Kubernetes 设计的对外暴露服务的推荐方式，但是这种方式仅仅限于云厂商提供的 Kubernetes 服务上，对于物理部署或者非云环境下部署的 Kubernetes 集群，这一机制就存在局限性而无法使用。

Ingress 

Ingress 并不是 Kubernetes 服务本身提供的暴露方式，而是借助于软件实现的同时暴露多个服务的一种类似路由器的插件。

Ingress 通过域名来区分不同服务，并且通过 annotation 的方式控制服务对外暴露的方式。其原理如下图：

相比于 Node Port 和 Load Balancer，Ingress 在企业业务场景中应该是使用的最多的，原因有：

但是在实际场景中，Ingress也需要解决下面的一些问题：

第一个问题，Ingress 也可以用于 L4，但是对于 L4 的应用，Ingress 配置过于复杂，最好的实现就是直接用 LB 暴露出去。

第二个问题，测试环境可以用 NodePort 将Ingress Controller 暴露出去或者直接 host network，但也不可避免有单点故障和性能瓶颈，也无法很好的使用 Ingress-controller 的 HA 特性。

KubeSphere 开源实践

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

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

快速部署和体验Porter

完全开源

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

快速部署

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

• 使用 Helm Chart 在 Kubernetes 部署 Porter：https://github.com/kubesphere/porter/blob/master/doc/zh/porter-chart.md

• 在物理机部署的 Kubernetes 部署 Porter：https://github.com/kubesphere/porter/blob/master/doc/zh/deploy_baremetal.md

• 在云平台用模拟路由器的方式测试：https://github.com/kubesphere/porter/blob/master/doc/zh/simulate_with_bird.md

接下来，Porter 将在本月中旬发布新版本 v0.3.0，新版本由青云QingCloud、本来生活和北京吉恒科技三家公司联合开发，由社区定义与贡献，欢迎大家安装体验！

延伸阅读

• Porter-面向裸金属环境的 Kubernetes 开源负载均衡器：https://kubesphere.com.cn/conferences/porter/

• Porter 如何帮助本来生活在 K8s 物理环境暴露集群服务：https://mp.weixin.qq.com/s/Us6DZbf_GhRT69-dL1GD4g

• Porter 官网：https://porterlb.io/

- FIN -