近日，KubeSphere 社区子项目面向物理机环境的负载均衡器 Porter 正式进入 CNCF Landscape。CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择，Porter 进入 CNCF Landscape，意味着 Porter 正式成为了 CNCF 认可的构建云原生最佳实践中的一环。
云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。在每年的 CNCF 年度报告中都会提及 CNCF Landscape，CNCF Landscape 是 CNCF 中的一个重要项目，帮助企业和开发人员快速了解云原生体系的全貌，同时，也受到广大开发者和使用者对该项目的关注和重视。CNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持。
新晋 CNCF Landscape 的 Porter，解决什么问题？
在 Kubernetes 集群中可以使用 “LoadBalancer” 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 LoadBalancer 插件，但这需要将集群部署在特定 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 是最方便的暴露服务的方式，缺点也很明显：
- 基于 SNAT 进行访问，Pod 无法看到真正的 IP。
- NodePort 是将集群中的一个主机作为跳板访问后端服务，所有的流量都会经过跳板机，很容易造成性能瓶颈和单点故障，难以用于生产环境。
- 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 的方式控制服务对外暴露的方式。其原理如下图：
快速部署和体验 Porter
完全开源
Porter 的所有代码和文档已在 Github 开源，欢迎大家关注 (Star) 和贡献：https://github.com/kubesphere...
快速部署
Porter 目前已在如下三种环境下进行过部署和测试，并将部署测试与使用步骤的详细文档记录在 GitHub，可以通过以下链接查看和部署实践：
- 使用 Helm Chart 在 Kubernetes 部署 Porter：https://github.com/kubesphere...
- 在物理机部署的 Kubernetes 部署 Porter：https://github.com/kubesphere...\_baremetal.md
- 在云平台用模拟路由器的方式测试：https://github.com/kubesphere...\_with\_bird.md
最新动态
Porter 将在本月中旬发布新版本 v0.3.0，新版本由青云QingCloud、本来生活和北京吉恒科技三家公司联合开发，由社区定义与贡献，非常感谢非青云的社区贡献者 @k0ngk0ng 和 @chinazj。新版本的主要功能已在文中 Porter 介绍中标注，欢迎大家安装体验！
延伸阅读
- Porter-面向物理机环境的 Kubernetes 开源负载均衡器：https://kubesphere.com.cn/con...
- Porter 如何帮助本来生活在 K8s 物理环境暴露集群服务：https://mp.weixin.qq.com/s/Us6DZbf\_GhRT69-dL1GD4g
- Porter 官网：https://porterlb.io/
关于 KubeSphere
KubeSphere 是在 Kubernetes 之上构建的以应用为中心的开源容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。
KubeSphere 已被 Aqara 智能家居、本来生活、中国人保寿险、新浪、北京银行、华夏银行、浦发硅谷银行、四川航空、国药集团、微众银行、VNG Corporation、Radore 等海内外数千家企业采用。KubeSphere 提供了运维友好的向导式操作界面和丰富的企业级功能，包括 Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。
KubeSphere 官网：https://kubesphere.io/
KubeSphere GitHub：https://github.com/kubesphere...
欢迎关注我们的微信公众号：
