博云自成立以来，云原生十年实践历程，技术创新不断突破，市场份额稳居中国容器市场前五。十年征程，博云容器云已逐步从单一容器平台发展成为以应用为中心，以容器为底座，面向多种应用类型支撑的容器云产品族，是实现应用统一管理的云原生解决方案。

5 月 23 日，博云“容耀新生，大器所成—容器云产品族线上发布会”，诚挚邀请您参加。

Carina 是由博云主导并发起的云原生本地存储项目（GitHub 地址为：https://github.com/carina-io/carina），目前已经进入 CNCF 全景图。

Carina 旨在为云原生环境中的有状态应用提供高性能、免运维的本地存储解决方案，具体存储卷生命周期管理、本地设备管理、智能调度等能力。Carina 作为博云容器云平台的组件之一，已经在多个金融机构的生产环境中稳定运行多年。

---

重大喜讯！！！重大喜讯 ！！！重大喜讯！！！

Carina 项目组于 4 月 28 日发布了 V0.10.0 版本。该版本实现了诸多升级迭代，笔者将通过本篇文章给大家初步介绍 Carina 的全新版本。

版本重要变更

Carina V0.10.0 版本对如下内容进行了改动或升级：

• 支持将裸盘挂载到容器内直接使用

• velero 备份存储卷支持

• 新增 CRD 资源 NodeStorageResource 替代原将磁盘设备注册到 Node 节点

• 变更 sc 及 pod 中自定义字段

• 使用 job 生成 webhook 证书，替代原有脚本生成证书方式

• 移除代码内置 csi.proto 文件并升级 CSI_VERSION=1.5

• 增加更多的英文文档，Carina 支持中英双文档

版本详细介绍

完整的参数介绍请见：https://github.com/carina-io/carina/blob/main/docs/manual_zh/configrations.md

下表是本次更新中的参数变更：

• 新增 CRD 资源 NodeStorageResource，该功能为节点注册的替代功能，该资源反应了对应节点上的磁盘及 LVM 卷等信息，该资源对于用户来说为只读资源。

• 用 velero 备份存储卷，详细信息参考文档

裸盘支持

• 裸盘设计文档请见：https://github.com/carina-io/carina/blob/main/docs/design/design-raw-manger.md

• 裸盘测试文档请见：https://github.com/carina-io/carina/blob/main/docs/manual_zh/raw-manager.md

• 定义配置文件，规定某些磁盘作为裸盘提供服务

• 简单演示

前言

Rainbond 是一个云原生应用管理平台，使用简单，不需要懂容器、Kubernetes和底层复杂技术，支持管理多个Kubernetes集群，和管理企业应用全生命周期。但是随着云原生时代的一点点进步，层出不穷的网络容器安全事件的出现，也是让大家对于容器安全，网络安全的重要性，有了更进一步的想法，Rainbond 为了保证用户在使用的过程中不出现类似的容器安全事件，特别适配整合了 NeuVector。

NeuVector 是业界首个端到端的开源容器安全平台，为容器化工作负载提供企业级零信任安全的解决方案。NeuVector 可以提供实时深入的容器网络可视化、东西向容器网络监控、主动隔离和保护、容器主机安全以及容器内部安全，容器管理平台无缝集成并且实现应用级容器安全的自动化，适用于各种云环境、跨云或者本地部署等容器生产环境。

本文主要表述，基于 Rainbond 安装部署 NeuVector 容器安全平台的步骤，以及配合 Rainbond 实现生产环境中的最佳实践。

部署 NeuVector

NeuVector 有多种部署安装形式，为了更加简化安装，选用 helm 的形式进行安装，Rainbond 也是支持 helm 商店的形式，只需要在应用市场，添加一个新的商店，把 helm商店的URL 填写上即可。

准备工作

「创建团队」

NeuVector 通常是安装在 neuvector 命名空间里面的，而在 Rainbond ，团队的概念则是对应 kubernetes 里命名空间，所以通过 helm 安装的时候，首先需要创建出来对应的团队，团队的英文名对应的则是该团队在集群中的命名空间，此处填写 neuvector，选择对应集群即可。

「对接 helm 商店」

Rainbond支持基于helm直接部署应用，所以接下来对接 neuvector 官方helm仓库，后续基于Helm商店部署 neuvector 即可， 在应用市场页面，点击添加商店，选择helm商店，输入相关信息即可完成对接。

helm 商店地址：https://neuvector.github.io/neuvector-helm/

安装

在 helm 仓库找到 core 点击安装到 neuvector 团队里即可

修改默认的 key 以及 value

values 配置项：

键	值
registry	docker.io
tag	5.0.0-preview.1
controller.image.repository	neuvector/controller.preview
enforcer.image.repository	neuvector/enforcer.preview
manager.image.repository	neuvector/manager.preview
cve.scanner.image.repository	neuvector/scanner.preview
cve.updater.image.repository	neuvector/updater.preview
manager.svc.type	ClusterIP

安装完成以后，确认 pod 的状态为 Running

neuvector 提供了可视化操作的界面，安装过程将自动创建Service，通过Rainbond平台第三方组件的形式可将 neuvector 的访问端口暴露出来。

以下为需要进行配置的选项

组件名称	neuvector-web
组件英文名称	neuvector
组件注册方式	kubernetes
Namespace	neuvector
Service	neuvector-service-webui

添加完成以后，需要添加并打开对外访问的端口（8443），默认用户名以及密码均为 admin/admin

注意：访问的时候，需要通过 https 的形式进行访问，至此 neuvector 安装完毕

NeuVector 最佳实践

网络流量监视治理

NeuVector 提供的网络活动，可以清楚的查看每一个 pod 之间的网络流量动向。以及对应的端口，规则，更加清晰明了的查看走向。

蓝色线代表正常的流向是记录在学习模式里的。

黄色的流向则是记录在监视模式下，需要我们手动进行审阅规则，决定是否通过这个流量。

红色则代表是记录在保护模式下，被拒绝的动向，也可通过规则进行避免。

学习模式，监视模式，保护模式的使用

NeuVector 的组支持 3 种模式：学习模式、监控模式和保护模式；各个模式实现作用如下：

「学习模式」

学习和记录容器、主机间网络连接情况和进程执行信息。

自动构建网络规则白名单，保护应用网络正常行为。

为每个服务的容器中运行的进程设定安全基线，并创建进程配置文件规则白名单。

「监控模式」

NeuVector 监视容器和主机的网络和进程运行情况，遇到非学习模式下记录的行为将在 NeuVector 安全事件中进行告警。

「保护模式」

NeuVector 监视容器和主机的网络和进程运行情况，遇到非学习模式下记录的行为直接拒绝。

针对于以上三种模式，可以总结出来适于生产环境的最佳实践，当新的业务准备上线的时候，可以先默认是学习模式，经过一段时间的学习，记录容器的以及主机的规则，然后转换成监控模式，运行一段时间，监控是否有特殊的网络流量以及主机进程，帮助我们把特殊的网络动向记录下来，并进行告警确认是否放行，最后转换成监控模式，避免一些恶意的操作对我们的环境造成不必要的危险。

基于集群的镜像仓库做漏洞检查

kubernetes 集群部署业务的最小单元是 pod 但是pod 的组成部分最重要的其实是镜像， NeuVector 也是可以基于镜像进行漏洞检查，避免在镜像被注入特殊的漏洞机制

对接 Rainbond 时，在不使用外部的镜像仓库的情况下，Rainbond 会提供一个默认的用于存储镜像的仓库 goodrain.me ，它是用来存储通过 Rainbond 构建的所有业务的镜像，所以通过检查里面的镜像，可以清楚的看出业务所依赖的镜像都存在那些漏洞，已避免因为镜像漏洞问题所造成的影响。

如果在对接 Rainbond 时使用了外部的镜像仓库，且域名可以被解析到的情况，可以直接填写域名即可，因为 goodrain.me 本身是不能被 NeuVector 解析的，所以需要通过集群的 coredns 手动添加对应的解析，来确保 NeuVector 可以连接上。

编辑coredns

kubectl edit cm coredns -n kube-system  

获取 goodrain.me 解析的 IP

kubectl get rainbondcluster -n rbd-system -oyaml | egrep -v [A-Za-z{}]

在指定位置添加以下内容，注意修改 IP

hosts {
  192.168.0.1 goodrain.me
  fallthrough
}

在 NeuVector web界面左侧选择 资产 > 镜像库 添加仓库

goodrain.me 默认用户为 admin，密码通过以下命令获取

 kubectl get rainbondcluster -n rbd-system -oyaml | grep password | sed "1d"

镜像扫描结束以后，镜像的信息会在下面进行呈现，点击想要查看的镜像名称，即可查看详细信息，以下供参考

写在最后

通过本文，希望大家可以基于 Rainbond 成功把 NeuVector 容器安全平台部署起来，并且可以根据最佳实践，做好相对应的操作，当然NeuVector 的功能远远不止于此，还是需要大家不断的探索，不断的实践。

本文描述如何通过云原生应用管理平台 Rainbond 一键安装高可用 EMQX 集群。这种方式适合不太了解 Kubernetes、容器化等复杂技术的用户使用，降低了在 Kubernetes 中部署 EMQX 的门槛。

一、背景信息

1.1 Rainbond 与 EMQX 的结合

Rainbond 是一款易于使用的开源云原生应用管理平台。借助于它，用户可以在图形化界面中完成微服务的部署与运维。借助 Kubernetes 和容器化技术的能力，将故障自愈、弹性伸缩等自动化运维能力赋能给用户的业务。

这类用户不必再关心如何部署 EMQX 集群，通过开源应用商店一键安装 EMQX 高可用集群，这种安装方式极大的降低了用户使用 EMQX 集群的部署负担，目前支持最新版本 4.4.3。

1.2 关于应用模版

应用模版是面向 Rainbond 云原生应用管理平台的安装包，用户可以基于它一键安装业务系统到自己的 Rainbond 中去。无论这个业务系统多么复杂，应用模版都会将其抽象成为一个应用，裹挟着应用内所有组件的镜像、配置信息以及所有组件之间的关联关系一并安装起来。

二、前提条件

• 部署好的 Rainbond 云原生应用管理平台：例如 快速体验版本，可以在个人 PC 环境中以启动一个容器的代价运行。
• 可以连接到互联网。

三、快速开始

3.1 访问内置的开源应用商店

选择左侧的 「应用市场」 标签页，在页面中切换到 「开源应用商店」 标签页，搜索关键词 「EMQX」 即可找到 EMQX 应用。

3.2 一键安装

点击 EMQX 右侧的 「安装」 可以进入安装页面，填写简单的信息之后，点击 「确定」 即可开始安装，页面自动跳转到拓扑视图。

参数说明：

选择项	说明
团队名称	用户自建的工作空间，以命名空间隔离
集群名称	选择 EMQX 被部署到哪一个 K8s 集群
选择应用	选择 EMQX 被部署到哪一个应用，应用中包含有若干有关联的组件
应用版本	选择 EMQX 的版本，目前可选版本为 4.4.3

等待几分钟后，EMQX 集群就会安装完成，并运行起来。

3.3 验证 EMQX 集群

• 通过 Dashboard 验证查看集群节点。访问组件 EMQX_Cluster-4.4.3 的 18083 端口的对外服务域名，即可登录 EMQX Dashboard，在首页 Nodes 展示所有节点都处于 Running 状态。

  ❝默认账户密码: admin/public ，可通过环境变量修改 EMQX_DASHBOARD__DEFAULT_USERNAME EMQX_DASHBOARD__DEFAULT_PASSWORD

  ❞

• 通过命令行查看集群节点，进入组件 EMQX_Cluster-4.4.3 的Web终端，选择任意一个实例，执行以下命令：

emqx_ctl cluster status

信创，即信息技术应用创新产业，其是数据安全、网络安全的基础，也是新基建的重要组成部分。作为国内信创先行者、践行者，谐云是信息技术应用创新工作委员会的会员单位，也是金融信创生态实验室的紧密合作单位，并积极参与实验室中基于金融业务场景的技术和相关标准制定等工作。

在不同业务场景适配验证、技术攻关、信创解决方案和实施路径拓展等方面，谐云一直在持续贡献着强劲的力量。旗下容器云产品还于近期通过金融信创生态实验室的适配验证，以及工信部的产品质量测试。

据相关数据显示，2020年我国信创市场规模为1.05万亿，未来随着国家政策的倾斜，行业市场规模将越来越大，2025年市场规模将稳步增长至1.3万亿。可见，以云计算为代表的IT基础设施，国计民生行业自主创新全面加速，信创市场拥有巨大的发展潜力与空间。

与此同时，信创产业也面临着巨大的挑战：

• “一云多芯”，即多种芯片统一共建

  因国产芯片技术架构不同，且未来发展趋势不明，为避免风险，需采用多种芯片建设，要求能实现一云多芯管理 ；

• 多云并存管理难客户有存量云平台，新增信创云的情况下，多云孤岛、分散管理，增大了运维难度且不利于资源有效管理；
• 应用迁移困境应用迁移涉及应用的重构与重编译，工作量大，相关工具不成熟。

｜谐云信创工作｜

谐云拥有十余年行业落地和实施经验及领先的底层代码能力，掌握云原生核心技术，完全可以实现自主可控。同时，谐云产品已全面适配国产化服务器、国产化芯片、国产化操作系统、国产化中间件等，在银行、证券、信创、政务领域均有信创试点项目，助力信创行业试点和规模化覆盖。

01

谐云信创核心科技

2020年5月29日，2020年8月13日，美国HashiCorp公司和Docker更新网站服务协议，禁止禁运国家和被列入美国“实体清单”等多个清单的组织和个人使用遵循该服务协议的商业产品。

为了避免未来被HashiCorp和Docker等国外公司技术封锁，谐云针对不同的业务场景，自研可适配多种容器的100%国产自主可控软件及方案。

02

谐云信创成果

谐云早于 2019 年加入工信部信创工委会，2021年成为浙江省信息技术应用创新联盟的理事单位，通过了工信部严格的产品质量测试报告及央行金融信创生态实验室的质量及新能测试报告，入选成为工信部重点实验室“软件融合应用与测试验证工信部重点实验室”的成员单位，2022 年通过了华为鲲鹏 Validated 认证，与鲲鹏生态系良好融合。

此外，谐云自2020年起，先后参与金融行业首批信创试点建设、第二批试点建设、以及正在进行中的第三批试点建设，多方展开信创试点合作。信创合作单位包括某交易所、某国有大行科技部门、某省级商业银行、某头部券商、某运营商等等。并参与多项信创国家标准编写工作。

目前，谐云围绕容器云 PaaS 平台为核心的信创产品，已经实现同类产品的国产化替代。并已全面适配鲲鹏、海光、飞腾等主流国产化处理器，麒麟软件、统信软件等国产化操作系统，获得华为鲲鹏、中科可控、海思曙光、天翼云、中国电科等国产生态兼容性认证，为通信、能源、金融、互联网等众多行业的头部企业客户提供性能服务。

｜谐云信创云原生解决方案｜

谐云结合容器与底层资源松耦合特性，打造出基于容器与容器云的“一云多芯”信创云方案。通过容器云PaaS平台实现多芯片多架构资源的统一管理，在原有业务集群基础上新增工作节点就可以完成业务的平滑迁移适配。

同时，方案引入创新的容器云技术实现上层业务与底层基础设施环境的松耦合，使得业务可以在双架构层面（X86/ARM）灵活迁移自由调度，真正实现一云多芯，多云多芯，甚至单集群多芯环境。且业务应用采用标准的容器化打包技术，结合谐云容器云PaaS平台的统一纳管技术，屏蔽底层基础设施差异，业务迁移与流量割接平滑完成。

服务方案一

国产化容器运行时 – Pouch富容器：国产化容器运行时 – PouchContainer；新一代国产虚拟化 – PouchVM；可以替换Docker或Containerd。

服务方案二

国产化容器管理平台、DevOps平台、微服务平台、云监控平台等信创云原生解决方案：国产化容器云平台，完美适配一云多芯，X86/ARM双平面无缝切换，打造自底向上全面的国产虚拟化新基建（底层运行时选取可根据用户敏感程度，灵活选择 pouch或docker）。
服务方案三

XC试点高分辅导：基于多个试点项目的XC验收经验，提供一站式高分辅导、产品适配、业务迁移服务，确保用户在试点验收结果中获得较好成绩。

01

信创试点与建设思路图

02

谐云信创云原生建设架构选型——多架构方案可选

技术方案1：（多集群部署）—全栈技术架构调研情况：当前市场占比70%-80%

▲（多集群部署）—全栈技术架构

技术方案2：（单集群部署）优化—全栈技术架构（master节点信创）

调研情况：当前市场占比20%-30%

▲（单集群部署）优化—全栈技术架构

03

谐云信创云原生建设方案对比分析

关于具体项目落地，建议结合具体使用场景、使用习惯和资源采购的难易程度等综合考量后，联系谐云售前、销售或者架构师协助进行选择。

｜谐云信创云原生相关案例｜

01

信创试点案例 — 某交易所信创高分验收

为落实人民银行等有关部门关于进一步推进信息创新技术在金融领域的应用要求，以实现“功能和业务要求不变、系统架构不变、性能指标不降、最大程度实现信息创新”为目标，谐云助力某交易所，创新式的采用容器化+国产化相结合的模式，完成试点业务应用平滑迁移至信息创新基础环境的目标。

为客户打造的收益包括快速实现试点业务系统的应用平滑迁移；顺利完成第一批信创试点要求，并拿到优秀的名次；创新性地构建容器化+国产化的迁移模式，为规模化推广构建平台能力支撑。

解决方案如下：

基础环境：鲲鹏 + 统信UOS；信创试点系统：50+，包含OA，消息中心，用户中心，某交易所移动APP等。

02

信创试点案例 — 某大型商业银行全栈信创云落地

谐云助力客户全面完成国产化支撑，实现全栈国产化。

解决方案如下：

03

信创落地案例 — 某运营商ARM集群大规模投产

项目规模：

• 数据中心A：测试ARM通用集群：5
• 数据中心A：测试ARM高性能集群：9
• 数据中心A：ARM通用集群：91
• 数据中心A：ARM高性能集群：38
• ………….

投产经验：

• 镜像仓库跨平台交付：谐云支持ARM服务器和X86服务器环境下共用一套镜像仓库；
• 镜像仓库异构平台构建：谐云基于Manifest list特性，关联镜像仓库中不同架构的同一镜像，实现单仓库异构环境镜像存储和拉取，支撑ARM服务器集群；
• 管理平台统一纳管：谐云支持管理平台统一调度管理；
• ARM集群主机调优：谐云对容器云ARM服务器主机进行参数优化配置，使集群性能最高、稳定性最强。

解决方案如下：

信创作为数据安全、网络安全的基础，以及我国新基建的重要内容，对于我国产业数字化以及信息安全都具有重大意义。谐云基于自主创新的内在基因，始终坚持拓展从底层基础硬件到上层应用系统的国产化道路。未来也将继续以点带面构建信创生态版图，不断为政府、交通、金融、能源等各行业用户提供安全、稳定、高效的产品服务与技术解决方案，为我国创新驱动战略主引擎贡献自身力量。

4月13-15日，欧拉开发者大会（OpenEuler Developer Day 2022）成功举行，博云作为首批入选欧拉技术测评方案代表厂商受邀出席认证发布仪式。

本次大会是欧拉捐赠之后社区发起的首次大会，旨在推动 OpenEuler 在服务器、云计算、边缘计算和嵌入式四大场景的技术探索和创新，与合作伙伴携手共建极具创新力的开源社区，打造全球首选的数字基础设施开源操作系统。

OpenEuler 前身是华为基于开放的企业级 Linux 打造的服务器操作系统软件，已经超过十年的技术积累，具备的高安全性、高可扩展性、高性能等技术特性，能够满足企业全云化、多场景业务、智能化弹性部署等一系列 ICT 产业变革需求。截至目前，欧拉社区汇聚了三百三十家合作伙伴，覆盖了全产业链，包括芯片厂商，硬件厂商，整机厂商等，服务范围包括政府运营商，金融，能源，交通，互联网等行业。

欧拉生态服务平台已正式上线。目前，首批 13 家伙伴、15 个产品和解决方案通过验证。博云是首批合作伙伴中唯一的容器云和云管理平台提供商。

博云基于欧拉操作系统的容器云解决方案，是以容器云为核心基础，提供敏捷灵活、自主可控、稳定可靠的基础设施。为企业构建以应用为中心的资源虚拟化、应用容器化、服务治理化等为特征的新型 IT 架构。助力提升企业应用快速部署、环境标准化、业务弹性扩缩容、资源利用率等能力，促进 Devops 的落地，加速企业软件资产积累，为实现市场化、精细化、智能化的现代企业技术提供基础底座。

博云基于欧拉操作系统的多云管理解决方案，是以云管理平台为核心基础，提供易用、精细、高效、自主可控的基础设施。为用户提供一致性的资源服务、资源运维、资源运营体验；为企业 IT 基础设施持续云化，信创落地保驾护航。

作为云原生操作系统的头部创新企业，博云一直注重科技创新，坚持核心代码自主研发，专注为客户提供自主可控的国产软件基础设施产品和技术服务。同时，伴随信创产业的蓬勃发展，博云积极拓展信创生态布局，信创容器云平台、信创云管理平台等核心产品，支持“一云多芯”信创架构部署，及自主可控的需求。

博云较早加入了信息技术应用创新工作委员会，核心产品容器云和云管理平台通过了工信部严格的产品质量测试，以及央行金融信创生态实验室的质量及性能测试，信创产品功能和性能测试 100% 通过验证。

在信创生态建设方面，博云核心信创产品已顺利与芯片厂商鲲鹏、飞腾、海光、兆芯、龙芯中科；与操作系统厂商统信、麒麟、中科方德，与服务器厂商华为、宝德、中科可控、曙光、长城；与数据库厂商达梦数据库，与中间件厂商东方通，与虚拟化软件厂商云宏，完成了产品兼容性认证，进一步加深了国产化兼容、适配程度。

在信创落地实践方面，博云核心信创产品已形成了众多信创标杆案例。以证券行业为例，博云为头部证券机构搭建的信创云管理平台，通过运行在信创环境下的云管平台，实现了核心组件国产化的信创云管平台集中管理基础设施中心的云网资源，包括传统 VMware，公有云，信创云资源，网络，存储资源等。

数字化转型浪潮下，信创产业发展是实现科技自立的必然要求。博云将坚定不移走自主研发之路，以开放心态与合作伙伴共建安全稳定的信创生态体系，推动信创产业良性发展。

❝Envoy 可以作为 Sevice Mesh 微服务框架中的代理实现方案，Rainbond 内置的微服务框架同样基于 Envoy 实现。本文所描述的全局限速实践也是基于 Envoy 已有的方案所实现。

❞

Envoy 全局限速

尽管分布式熔断器在大多数情况下控制分布式系统中的吞吐量非常有效，但有时它的效果并不是很好，这时候便需要全局限速。最常见的情况是当大量主机转发到少量主机并且平均请求延迟很短时（例如，发送给数据库服务器的连接/请求）。若目标主机成为备机，则下游主机将压垮上游集群。在这种情况下，很难对每个下游主机配置足够严格的熔断器，使得系统可以平稳运行，同时，当系统开始出现故障时，仍然可以防止级联故障。对于这种情况，全局限速是一个很好的解决方案。

Envoy 全局限速方案需要基于一个全局 RLS（rate limit service）服务实现，RLS 被设计为一种为不同类型应用提供不同限速场景的 Go/gRPC 服务。

构建全局限速服务

一种开箱即用的全局限速服务已经被纳入 Rainbond 内置的开源应用商店中，用户可以基于以下操作一键安装速率限制服务。

• 「访问内置的开源应用商店」

❝选择左侧的 「应用市场」 标签页，在页面中切换到 「开源应用商店」 标签页，搜索关键词 「速率限制」 即可找速率限制服务。

❞

• 「一键安装」

❝点击速率限制服务右侧的 「安装」 可以进入安装页面，填写简单的信息之后，点击 「确定」 即可开始安装，页面自动跳转到拓扑视图。

❞

参数说明：

选择项	说明
团队名称	用户自建的工作空间，以命名空间隔离
集群名称	选择速率限制服务被部署到哪一个 K8s 集群
选择应用	选择速率限制服务被部署到哪一个应用，应用中包含有若干有关联的组件
应用版本	选择速率限制服务的版本，目前版本为 1.4.0

等待几分钟后，速率限制服务就会安装完成，并运行起来。

全局限速配置

通过在 Rate-limit-service 组件中编辑配置文件 /data/ratelimit/config/config.yaml，可以配置全局限速标准。

默认配置内容如下：

domain: limit.common
descriptors:
  - key: remote_address
    rate_limit:
      unit: second
      requests_per_unit: 10

  # Black list IP
  - key: remote_address
    value: 50.0.0.5
    rate_limit:
      unit: second
      requests_per_unit: 0

在这一段配置中，定义了面向域名 domain 实现每秒允许 10 个请求通过的限速配置。

面向客户端 IP 为 50.0.0.5 的情况，则实现每秒允许 0 个请求通过的限速配置，用户可以理解为黑名单配置。

更多配置示例可以参见 1.GitHub – envoyproxy/ratelimit: Go/gRPC service designed to enable generic rate limit scenarios from different types of applications.

引用全局限速服务

需要被限速的服务组件需要满足以下条件：

• 安装并配置 「服务综合网络治理插件」

• 依赖 Rate-limit-service

Rainbond 通过插件机制扩展业务的运维能力，通过安装 「服务综合网络治理插件」 ，可以在被限速业务的网络入口处扩展治理能力。「服务综合网络治理插件」 本质上扩展了 Envoy 能力，通过调用 Rate-limit-service ，实现全局限速功能。

确保 OPEN_LIMIT(是否开启限流) 选项为 YES， LIMIT_DOMAIN(对应限流规则的域名) 与上文中全局限流配置中的 domian 一致。至此，完成了被限速服务一侧的配置。

验证

为了验证限速是否生效，引入 Locust 压力测试工具，向被限速业务不断生成访问请求。

应用默认全局限速策略后，被限速业务在 40 RPS 的情况下限制了 74% 左右的总访问数。

被拒绝的访问，得到了 429 返回码，并提示 Too Many Requests，这是服务限速的标准返回模式。

被限速业务所安装的 「服务综合网络治理插件」 支持动态配置。这意味着在不停止服务的情况下，只需要将 OPEN_LIMIT(是否开启限流) 选项为 NO 并更新配置 ，即可关闭服务限速，访问错误数将下降至 0。

全局限速生效于被限速业务的网络入口，这意味着无论请求来自 Rainbond 部署的其他微服务组件，还是来自网关以外的外部访问，其请求都会被限速。

总结

全局限速是一种在突发流量激增场景中保护微服务的有效手段，Rainbond 内置的微服务框架支持符合 RLS 规范的 Envoy 服务限速方案。配置起来很简单，并且支持动态变更，本文中的示例力争以直观的方式为大家展现了全局限速在 Rainbond 体系中的配置实践。

Carina 是由博云主导并发起的云原生本地存储项目（GitHub 地址为：https://github.com/carina-io/carina），目前已经进入 CNCF 全景图。

Carina 旨在为云原生环境中的有状态应用提供高性能、免运维的本地存储解决方案，具体存储卷生命周期管理、本地设备管理、智能调度等能力。Carina 作为博云容器云平台的组件之一，已经在多个金融机构的生产环境中稳定运行多年。

---

一、Carina 系列文章 – 前言

本篇是 Carina 系列文章的开篇，在该系列文章中我们将全面地展示本地存储 Carina 项目的功能设计、功能使用及其实现细节等内容。在 Carina 系列文章中将包含如下章节功能（排名不分先后）：Carina整体功能介绍、Carina存储卷创建及扩容、Carina存储卷挂载与扩容 、设备注册与节点资源管理、基于K8S的调度器扩展、Carina自动管理Raid使用及原理分析、Carina结合velero实现存储备份恢复、smart感知使用及原理、基于cgroup v1和cgroup v2的设备限速、基于磁盘IO的调度等等。

Carina 是基于 K8S CSI 实现的一个本地存储插件，在本篇文章中我们将首先简要介绍一下 Carina 项目的根基容器存储接口（CSI），以及为什么我们需要本地存储本地存储诞生的契机，在之后我们将展示 Carina 项目架构设计等内容。

二、容器存储接口（CSI）

 

1. CSI 是什么

CSI 是Container Storage Interface（容器存储接口）的简写，CSI 存在的目的便是定义存储行业标准，使供应商（SP）能够开发一个符合 CSI 标准的插件，在多容器编排系统中方便的提供存储。

Kubernetes 将通过 CSI 接口与云存储厂商进行通信，进行卷的创建、挂载等管理操作，从而实现容器使用持久存储卷的需求。

2. 为什么要有 CSI

在没有 CSI 之前 Kubernetes 已经内置了强大的存储插件系统，但是这样的存储插件是 Kubernetes 代码的一部分，要跟随 Kubernetes 的发布而更新，这样就存在一些问题，如果云存储厂商发现有些问题需要修复或者优化，云存储厂商无法及时修复而单独发布版本其必须与 Kubernetes 一块发布，这样对于 K8S 和云存储厂商而言形成了相互依赖相互制约的关系，不利于双方快速迭代，另外云存储厂商的代码与 Kubernetes 代码高度耦合在一起，还会引起安全性、可靠性问题，这增加了 Kubernetes 代码的复杂度以及后续的维护成本等。

基于以上问题 Kubernetes 将存储系统抽象出了一组外部存储接口即 CSI，Kubernetes 通过 Grpc 接口与云存储厂商的 CSI 驱动服务进行通信，这样一来对于云存储厂商来说，可以单独发布和部署自己的存储插件，正常的迭代开发，无需接触 Kubernetes 核心代码，降低了开发的复杂度；同时对于 Kubernetes 来说，这样不仅降低了维护成本，还能为用户提供更多的存储选项。

3. CSI 系统架构

这是一张简要的 CSI 系统架构图：

首先 Kubernetes 官方为 CSI 提供了一些辅助服务 external-provisioner、external-attacher、external-resizer、external-snapshotter、node-driver-register、livenessprobe等，通过这些辅助组件 CSI 驱动开发者只需通过实现 CSI 接口和云厂商存储服务通信的内容，便可以方便的开发一个 K8S 存储插件。

三、本地存储诞生的契机

 

1. 中间件上云的困境

Kubernetes CSI 插件机制日趋成熟，各个分布式存储服务分别开源了自己的存储插件比如：ceph-csi、nfs-csi。这些网络存储插件极大地扩展了 Kubernetes 的能力，在过去几年的 K8S 发展中起着至关重要的作用，分布式网络存储系统在可扩展性、数据安全等方面有着巨大的优势，在通用存储领域发挥了很大的作用。但是，对于极高的 IOPS、极低延迟的数据库等中间件领域，网络存储有其天然的劣势。因此，推出一款延迟极低的开源 CSI 对数据库类服务就至关重要。

Kubernetes 已经稳定运行数年之久，主要应用场景一直是无状态服务以及对磁盘 IO 不敏感的业务服务，随着客户对云平台深入使用，希望一些中间件服务也能搬迁到云上，对于中间件服务来说有各种开源的 operator 促使其在 K8S 中稳定运行，但是中间件服务对磁盘 IO 具有非常高的要求，网络存储服务受到很大的挑战。

Kubernetes 集群运行节点主要使用了 CPU、Memory 等资源，对本地磁盘并未有精细的使用，在一定程度上造成了本地资源的浪费。

对于网络存储来说多个副本是一种基本功能，但是在中间件场景下，比如 Mysql 本身主从三副本，在网络存储下就变成了九份副本，也造成了存储资源的冗余。

2. 本地存储需求

由上可知，我们迫切地需要一款本地存储产品能解决上述困境，我们对该项目的需求如下，

1) 能够提供基于本地磁盘的高性能存储设备。

2) 符合 CSI 规范，与其他网络存储插件使用方式完全一致。

3) 能够十分简易的部署，自动管理本地磁盘，使用户几乎无需进行维护。

4) 提供丰富的文档资料及运行日志，能十分轻易的进行功能使用及异常问题排查。

5) 能够支持存储卷的备份恢复，支持 RAID 管理、磁盘寿命监控等。

四、本地存储 Carina 设计

 

1. 基本的 CSI 功能

该列表展示的是一个 CSI 存储插件的基本功能，在早期设计中 Carina 需要实现的基本功能，当然经过多轮迭代的 Carina 已经有了更丰富多元的功能：

2. 整体架构图

共有三个组件：

Carina Controller：负责监听 pvc 的创建，并且通知 Carina Node 创建存储卷。

Carina Node：负责维护本地设备，并且执行创建存储卷命令、挂载卷到容器命令等。

Carina Scheduler：K8S 调度器的扩展，增加基于本地存储的调度插件。

3. 节点服务

该图描述了 Carina Node 的工作过程，自动维护本地磁盘设备并组建存储卷组，将节点容量信息注册到 Kubernetes Node，Kubelet 通过 grpc 调用将存储卷挂载到指定目录。

4. 整体运行流程

五、过去、现在与未来

 

笔者在书写这篇文章时，Carina 项目自 2020 年启动，并于 2021 年 10 月份开源，目前已经过数轮迭代。本篇文章从标准的容器接口 CSI、谈到本地存储需求的诞生以及早期 Carina 的设计，在早期的设计中除了基本的 CSI 功能外，我们期望它能够做到简易部署、免运维、占用极低的资源量等。

现在的 Carina 项目实际功能已经经过多轮版本迭代，增加了更加丰富多元的功能，比如设备多级缓存、设备限速等功能，随着版本迭代我们也使用可配置的存储卷代替了自动组建 SSD/HDD 卷组的功能、使用 NodeStorageResource 代替了节点注册功能、当然还有其他更多特性开发中。

在接下来的文章中，我们将首先罗列现有的 Carina 功能，正在开发中的、已经加入开发计划中的功能，然后再在展开逐个功能点进行详细的使用介绍及原理分析等。

近日，根据 CNCF 最新版本的云原生全景图（Cloud Native Landscape），Carina 本地存储项目已被纳入云原生存储（Cloud Native Storage）板块。

图 1：CNCF 全景图（截取）

更多全景图信息，请见：https://landscape.cncf.io
（更多…）

近日，博云 BeyondCMP 云管理平台 5.6 版本发布正式发布。为了满足不同行业客户对云管理平台的多样化需求，在资源纳管、资源运维、平台综合展示、易用性友好性等方面进行了全面提升。

点击立即申请云管理平台在线演示

---

新版本针对如下方面进行了全面提升，让我们来一起看看！

1. 资源纳管和云服务能力扩展

资源纳管能力扩展，包括：生命周期管理、服务订购、计量计费、性能监控等，包括：

• 新增对超融合平台 SmartX 平台的纳管；

• 新增对华为虚拟化平台 FusionSphere 平台纳管；

• 新增对 EasyStack 6.0 平台纳管。

通过 Veeam 备份系统对接，提供对云环境下的虚拟机备份功能。

2. 资源纳管功能增强

• 资源接入功能按资源类型分类展示和管理；

• 存量资源分配功能增强：进一步细化对存量资源归属管理：云主机、云硬盘、VPC；

• IP 地址池展示：通过图形化展示 IP 地址使用状态（预占、空闲、已锁定、已使用）

• vCenter 功能增强：优化控制台访问、增加 vCenter 平台任务同步任务、增加云主机批量克隆。

3. 平台易用性、友好性优化

• 自定义配置首页概览，用户可按需配置展示信息；优化监控概览、作业概览，扩展平台数据展示范围，提高数据时效性；云主机详情展示优化，提高信息展示友好性；

• 新版本中增加了平台使用指引、操作向导等帮助功能，初次使用平台用户也可快速上手，重点提升平台的易用性、友好性；

点击立即申请云管理平台在线演示

4. 资源运维功能增强

• 资源运维能力全面增强，增加运维资源统一管理入口；

• 提供对资源的巡检管理、合规管理、补丁管理等运维管理场景。

5. 平台服务模块化、插件化

根据使用场景进行平台服务模块化拆分，用户可根据实际需求灵活配置平台服务，各服务模块可根据使用场景灵活快速扩展，同时也可由客户及合作伙伴根据业务场景进行二次开发。

---

关于 BeyondCMP 云管理平台

BeyondCMP 云管理平台针对多云和混合云环境的云基础设施等资源管理，提供“云纳管 + 云服务 + 云运营 + 云运维”四位一体的中立云管理服务，以统一化方式帮助企业用户实现多云资源的调配和管理，自动化和自助化的服务交付，精细化和可视化的成本运营分析，帮助企业从传统环境平滑迁移到多云环境，保持企业云架构系统的持续优化。

点击立即申请云管理平台在线演示