乐趣区

关于云计算:CNStack-20云原生的技术中台

jiezi

在进入千禧年后，随着计算机技术的倒退和业务翻新的不断涌现，许多大公司内的 IT 计算中心也在酝酿着改革。一方面，各部门绝对独立的 IT 治理平台曾经难以满足日益增长和一直变动的计算治理需要；另一方面，IT 计算中心也越来越多的成为业务翻新的发源地，从一个老本核心向营收起源倒退。相应的，一种围绕着资源和负载治理平台的技术畛域逐步称为学术界和产业界的热点。它在不同的倒退阶段和不同的利用场景有着不同的名字，从最早的集群（Cluster），网格（Grid），到起初的数据中心操作系统（DCOS），云计算（Cloud Computing）。同时，在资源管理和负载治理这两大方面也一直的拓展着本身的边界。

目前，以 Kubernetes 为外围代表的云原生技术逐步称为这一畛域的支流。它所带来的不可变基础设施，以资源为治理对象，描述性的 API，最终一致性等等理念，不仅扭转了平台使用者的习惯，可能更好的在资源弹性变动的环境中放弃业务拜访的连续性；更扭转了服务和利用研发人员的思维模式，逐步以这种云原生的形式来设计和开发，进步翻新效率。

阿里云有“公共云”、“专有云”两种产品状态，应用同样基于飞天操作系统的技术路线，为用户提供从服务器开始一整套资源和负载的治理能力，以及运行在下面的各种服务。与此同时，也有很多客户因为种种原因无奈齐全应用私有云服务，也无奈洽购和部署一整套大专。在基于云原生的产品畛域中，这些客户或者接触了 Kubernetes 等开源我的项目，或者试用过红帽，Rancher 等厂商提供的 Openshift，Rancher 等平台产品，甚至体验了围绕这些产品形成的整个产品家族生态，如 IBM Cloud Pak 等。他们惊喜与这些云原生技术带来的麻利，凋谢，韧性等特点。同时，也心愿在此基础上取得反对不同业务场景的丰盛服务，以便疾速晋升创新能力。

应答这种需要，云原生 PaaS 团队通过长时间的技术和教训积攒，历时近半年的研发，创立了 CNStack 2.0 云原生技术中台产品。在接下来的内容里，将分享在 CNStack 2.0 产品，架构，研发中次要的设计思维和心得体会。

产品指标

阿里云应用云原生技术在资源和负载治理这一畛域的摸索曾经有一段历史了。在长期与解决方案团队，产品团队，内部客户的沟通单干中，发现使用者对云原生技术带来的以下特点最为关注。

麻利

麻利并不简略的等同于轻量，它更多的代表灵活性和因而而带来的效率的晋升。

用户心愿平台和服务可能随着不同的利用场景和规模，提供不同的部署配置选项。既可能治理三五台服务器，提供一两种服务或者公共负载类型，也可能治理百台服务器，满足几个业务团队的不同诉求，甚至治理数千上万台服务器，逾越多个地区，反对不同行业线的简单服务。

针对这些场景和规模的差别，用户须要的只是做好资源布局，在部署平台和服务时，抉择不同的配置选项。无论场景和规模的差别，平台都会提供统一的应用体验。同时，所需的治理资源开销最好可能随着规模的增大和性能的减少，对数或者线性级别的增长。此外，用户也能够很不便的获取产品，不须要简单的硬件资源就能够部署和试用，例如私有云申请的服务器上，甚至是本人的笔记本电脑上。

麻利还体现在产品性能的组合和降级，能够依据须要，减少和缩小性能和服务，以响应一直变动的翻新诉求。

凋谢

用户心愿能爱护已有的技术投资，也心愿能不便，疾速的补充开源社区或者其余厂商的技术创新。这就须要产品具备凋谢的特点。这里的凋谢次要是指采纳具备开源社区生命力的技术框架和规范的协定标准，产品本身也领有丰盛的扩大机制。

一个凋谢的产品，能够让用户

  • 不便的获取技术材料和试用环境，升高学习门槛
  • 通过规范的协定标准和扩大机制，集成其余厂商的产品或者被其余厂商产品集成，爱护技术投资
  • 反对更多的基础设施类型和工作负载类型
  • 与开源社区一起一直倒退，放弃技术先进性

生态

技术中台作为业务翻新的外围，须要反对多种业务类型，涵盖业务翻新的生命周期。从微服务框架，中间件，到 AI，数据处理；从研发设计，制品治理，到利用公布，容灾高可用；从本地数据中心，到边缘，私有云。

为了反对如此丰盛的能力，须要围绕技术中台构建产品生态，创立云服务，云组件的标准规范和反对标准规范的工具链。

  • 云服务：通过服务的模式在平台提供能力扩大，能够应用平台提供的用户，租户，鉴权，审计，许可证，多集群部署，UI 框架等根底能力，与平台既有能力或其余服务无缝的合作。和整个平台的运维一样，云服务的生命周期治理由管理员负责。
  • 云组件：通过部署申明的形式为平台用户提供软件的部署和运维，所部署的软件能够和用户自研软件一起编排实现业务流程。和用户自研软件一样，云组件的生命周期治理由具体的使用者负责。

上述是 CNStack 2.0 以后所反对的云服务一览。这些云服务与平台本身的公布齐全解耦，阿里云研发团队或者合作伙伴能够不便的针对业务场景扩大技术中台能力，独立公布云服务。须要重点强调的是，CNStack 平台本身也是以云服务形式开发，运维，治理的。

CNStack 2.0 为云服务和云组件的集成，测试和公布提供了一整套标准的工具链，它就是阿里云云原生利用交付平台（Application Delivery Platform，简称 ADP）[1]。CNStack 2.0 本身也是应用 ADP 开发和公布的。

在 ADP 平台上，开发者能够将形成云服务的组件以 helm charts 的模式上传。平台依据研发标准扫描查看后，以自有组件的模式进行版本治理。尔后，开发者能够把这些自有组件和 ADP 平台上提供的公共研发中间件，如数据库，音讯，微服务框架等一起编排为云服务，并在指定的私有云环境创立验证环境，部署 CNStack 2.0（也被称为底座）一起实现功能测试和一系列验证，如高可用等，最终打包为云服务（或者云组件）。云服务（云组件）的公布包标准遵循云原生 PaaS 团队奉献给社区的 CNCF Sealer 开源我的项目。交付时，在用户环境部署的 CNStack 2.0 平台上，管理员将云服务（云组件）公布包导入能力核心。在能力核心，管理员能够实现云服务的部署，降级，变配等一系列生命周期治理。

平安合规

随着隐衷和资产爱护重要性的日益晋升，平安合规越来越成为业务翻新中必须要解决的问题。作为在企业环境部署的产品，CNStack 2.0 须要满足严格的平安和合规标准。包含但不限于以下方面：

  • 管制治理服务在网络的裸露面，尽量收敛为一个端口，反对合乎平安规范的网络隔离布局
  • 提供用户治理能力或与现有的用户管理系统的集成
  • 提供多租户的隔离能力和灵便的权限治理
  • 提供与域名相干的证书，密钥治理或与现有的证书，密钥管理系统集成
  • 确保加密的网络传输和敏感数据的加密存储提供审计能力，反对合规查看
  • 为在平台运行的服务和利用提供动态和动静的平安合规扫描

架构设计

为了满足上述产品指标，研发团队制订了以下设计准则

面向 API 开发

与面向 API 开发绝对应的是面向 UI 开发。之前，对于产品性能的实现形式常常会听到相似“白屏”，“黑屏”的称呼。白屏就是在 UI 实现性能操作，而黑屏指通过命令行实现性能操作。因为性能逻辑通常在 UI 组件实现，就造成了通过命令行实现的性能，不足残缺能力或者平安合规的要求，所以“黑屏”通常被认为是 hack 的实现。相似这种面向 UI 开发的办法还有很多弊病，无奈满足前文提到的产品指标。

  • 产品设计以 UI 驱动，UI 的调整对性能实现影响大
  • 难以被其余产品或工具链集成，局限于页面嵌套，难以反对开放性要求
  • 难以建设云服务，云组件的标准，提供方便的平台能力集成接入
  • 性能的实现逻辑扩散，调用链长，难以保护，排查谬误
  • 认证，鉴权，审计等公共能力无奈集中控制，难以保障平安合规

与此相反，在面向 API 开发的架构中，UI 只是 API 能力的一种展现模式，UI 模块的前端或者间接调用治理服务 API，或者由 UI 的后端服务封装一个或多个治理服务 API。然而 UI 的后端服务本身并不实现任何运行期对象的治理能力，只是一个或多个 API 调用流程的封装，以及输出和输入数据的整顿。

在面向 API 开发的架构中，还有一项重要的设计准则就是：“没有暗藏的外部 API”（No Hidden Internal API）。这就要求治理服务组件之间的调用接口，也是用户对服务拜访的调用接口。只有保障 API 的一致性，服务的组件能够容易的替换，确保产品具备麻利，凋谢的能力。此外，它还打消了安全隐患，对所有 API 的调用应用统一的认证，鉴权，审计等平安合规能力。

所有治理对象都是资源

以 RESTful API 为代表，围绕资源进行治理的编程模型不仅带来了应用体验的晋升，也扭转了治理组件的实现形式。它将治理对象都作为资源，通过创立和扭转资源的申明来实现治理性能，查问资源的状态来理解治理后果。Kubernetes 更是为这种编程模型提供了最佳实际，带来了具体的实现办法。

在 CNStack 2.0 的架构设计中，采纳“所有治理对象都是资源”的编程模型，具备以下技术特点和劣势：

  • 申明式的 API 让调用者无需继续关注和解决治理动作收回后的执行阶段，治理服务须要确保治理对象的状态和资源申明最终保持一致
  • 申明式的 API 让调用者无需继续关注和解决治理动作收回后的执行阶段，治理服务须要确保治理对象的状态和资源申明最终保持一致
  • 创立和扭转治理对象的 API 都是异步的，API 的执行者只须要确保长久化资源的最新申明后就能够让 API 返回，简化 API 的解决，进步响应率
  • 因为一切都是资源，所以 API 执行者的解决能够共同化，不便实现对立的认证，鉴权，审计，筛选，分页等能力，也易于扩大，满足高可用和韧性的要求
  • 因为一切都是资源，所以 API 客户端的解决也能够共同化，无论在 UI 还是 CLI 上都是创立和扭转治理对象的资源申明，展现治理对象的资源状态。
  • 解决资源状态和申明一致性（reconcile）的控制器能够独立实现，与 API 的执行者解耦，便于降级，扩大和治理。同时，它的故障不会影响 API 本身的解决，具备可扩大，高可用，韧性，麻利，凋谢的特点。

将 Kubernetes 作为编程框架

Kubernetes 为“所有治理对象都是资源”的编程模型提供了最佳实际，带来了具体的实现办法。Kubernetes 的 operator 模式，自定义资源（Customized Resource Definition）等能力让开发者能够不便，快捷的扩大性能，由此看来，Kubernetes 不仅仅是一个治理容器化工作负载和服务的编排平台，更是一个可扩大的编程框架。

在 CNStack 2.0 的架构设计中，Kubernetes 作为编程框架的价值还体现在更多的方面

  • 租户治理

在共享基础设施的环境下，治理对象的拜访隔离是一个重要的能力。Kubernetes 提供了“命名空间”的概念，用户资源与命名空间关联，实现拜访隔离和配额，策略等管理控制。然而，Kubernetes 中的命名空间并不反对层级关系，基于 Hierarchical Namespace Controller (HNC) [2] 开源我的项目，CNStack 2.0 将 Kubernetes 的命名空间扩大至多级。CNStack 2.0 的治理对象大都以 Kubernetes 的资源形式治理，利用层级化的命名空间实现租户治理。

  • 权限治理

Kubernetes 提供了基于角色的访问控制（RBAC）。其中，角色定义了对 API group，资源和操作的容许范畴。角色能够通过聚合形式灵便的组合。通过将角色和用户，用户组，服务账号以及租户关联，能够管制用户和服务对资源的访问控制。对于不以 K8s 资源管理的对象，一样能够通过在角色中映射治理对象 API 的相干信息，定义拜访策略，甚至对于无奈以资源管理的执行命令，RBAC 也反对 nonresourceurls 的模式。CNStack 2.0 以 Kubernetes 作为权限管制引擎，将各种治理对象的权限点（permission）定义为 Kubernetes 的角色，通过 Kubernetes 角色的聚合实现灵便的自定义拜访策略，最终调用 SubjectAccessReview API 获取策略执行后果，断定指定用户或服务对 API 的拜访许可。

  • API 治理

在“面向 API 开发”的设计准则下，API 是 CNStack 2.0 的外围。Kubernetes 提供了 API 的扩大能力，基于自定义资源（Customized Resource Definition）和整套研发框架。开发者只须要专一于自定义资源的运行期治理逻辑，通过 Kubernnetes API 获取自定义资源的申明和以后状态，解决资源申明和以后状态的差别，让它们最终达成统一。同时，将 API 对象申明的解决，长久化等工作齐全交给 Kubernetes 组件。这样不仅极大的进步了研发效率，也让整个架构具备麻利，凋谢，可扩大，韧性的特点。

无论是以 Kubernetes 自定义资源形式实现的 API，还是以其余形式实现的 API，CNStack 2.0 基于 CNCF 的 Emissary-Ingress[3] 我的项目，创立了治理 API 网关，实现了管控 API 对立的路由，认证，鉴权，审计等能力。管控 API 网关收敛所有管控 API 对外裸露的拜访点为一个端口，容许治理服务，或者云服务（云组件）开发人员以 Kubernetes 自定义资源申明的形式形容 API 的路由，认证，鉴权和审计要求。这种办法大幅升高产品的被攻击面，也升高了治理服务，云服务（云组件）的研发累赘。

  • 证书治理

X.509 证书被利用于数字平安的方方面面，例如 HTTPS 平安通信。和域名一样，证书有标准的颁布机制，例如实用于 PoC 或公有范畴应用的自颁发；抑或是基于用户从认证的颁布机构获取的根证书（BYOK：Bring You Own Key），甚至是用户有本人的证书治理平台，如 Vault。Kubernetes 有内置的证书资源，能够基于本身的根证书依据用户申请创立证书。CNCF 的 cert-manager [4] 我的项目，以 Kubernetes 自定义资源的形式，提供了更全面的证书治理能力，反对上述多种场景。CNStack 2.0 基于 cert-manager，建设了证书治理服务。创立的证书能够主动的利用与治理服务和用户自建服务的平安通信。

  • 灾备复原治理

因为“所有治理对象都是资源”，所以治理对象的长久化都以资源的模式存储在 Kubernetes 中。基于开源我的项目 Velero[5]，CNStack 2.0 建设了备份复原服务，容许管理人员以 Kubernetes 自定义资源申明的形式阐明备份策略，如周期，资源类型，范畴，备份源等，以及复原策略。

  • 多集群治理

CNStack 2.0 天生就须要反对多集群，以满足用户对不同场景的诉求，例如资源和负载的物理隔离，多地区部署，容灾多活等。基于 Kubernetes，云原生 PaaS 团队和红帽等技术搭档开源了 CNCF Open Cluster Management（OCM）[6] 我的项目。基于 OCM，CNStack 2.0 建设了多集群的创立，纳管等生命周期治理服务，作为“多集群服务”这一云服务。它容许用户以 Kubernetes 自定义资源申明的形式形容须要创立或者纳管的集群。在“多集群服务”的帮忙下，云服务（云组件）也反对多集群下的部署和治理，辨别治理面和数据面组件，并申明部署的集群抉择条件。同时，对租户的资源管制，配额，管理策略等也扩大至少集群。

平安无处不在

平安合规是产品需要的一个重要方面，它体现在架构设计的方方面面。

  • 管控 API 对立收敛到治理 API 网关，最小化攻击面，所有的 API 拜访都须要实现认证，鉴权，审计，没有后盾 API
  • 管控 API 对立收敛到治理 API 网关，最小化攻击面，所有的 API 拜访都须要实现认证，鉴权，审计，没有后盾 API
  • 服务依据拜访需要设置领有最小化拜访权限的角色
  • 所有的网络通信都是加密的，平安通信证书对立治理，实现主动的更替
  • 所有的敏感数据都以 secret 形式加密保留
  • 所有治理和输入组件都须要通过 ADP 组件上架规范流程，实现镜像和运行期扫描查看
  • 节点和集群的纳管以零信赖为前提，实现治理和被治理对象的双向认证

CNStack 2.0 架构

CNStack 2.0 围绕 Kubernetes 为编程框架，它的管控组件大都以 Kubernetes 控制器的形式实现，以 Kuberentes API 扩大作为管控 API。其中，次要的组件如下

  • ACK Distro

ACK Distro 是云原生 PaaS 团队和私有云 ACK 团队一起公布的阿里云 Kubernetes 发行版。它以 Sealer 为公布和部署工具，反对在泛滥异构环境中部署和运维 Kubernetes 集群。其中 Kubernetes 外围组件和私有云 ACK 上的 Kubernetes 外围组件统一，经验了严格的安全检查和调优。所蕴含的网络（Hybridnet[7]），存储（Open-Local[8]）组件也是云原生 PaaS 团队和其余阿里云，蚂蚁基础设施团队独特研发的开源我的项目，经验了外部长时间的验证。ACK Distro 形成了 CNStack 2.0 的 Kubernetes 根底。

  • cn-app-operator

cn-app-operator 是云服务，云组件生命周期的管理者。在外部，它基于 OAM 的设计思维，反对 helm 作为 Kubernetes 资源的渲染引擎，围绕云服务和云组件的公布包，实例，自运维策略，告警治理创立了一系列 Kubernetes 自定义资源实现治理能力。它也是后续云原生 PaaS 团队打算开源的一个我的项目。

  • Account Mgr

Account Mgr 实现用户的账号治理或者对接反对标准协议，如 LDAP，AD 等的用户管理系统集成。它也负责用户和云服务的认证，创立拜访凭证。Accout Mgr 蕴含开源我的项目 KeyCloak[9] 实现用户的账号治理。

  • UI Backend

UI Backend 是 UI 拜访的后盾服务，它只是 Kubernetes API 或者其余治理服务 API 的封装。在外部拜访其余治理服务 API 时一样通过 Management Gateway 调用。

  • 审计 / 日志 / 监控 / 告警

审计 / 日志 / 监控 / 告警组件对平台治理组件，云服务 / 云组件，基础设施提供审计，日志，监控，告警服务。它基于 Loki [10] 和 Victoria Metrics[11]，Grafana[12] 实现日志和监控指标的采集，存储，查问和展现。其中，审计信息来自 Management Gateway 上对 API 的剖析解决。

  • 治理组件

CNStack 2.0 的泛滥治理组件都是以 Kubernetes Controller 的形式实现，通过 Kubernetes 自定义资源的形式提供 API。

  • Management Gateway

Management Gateway 是 CNStack 2.0 的一个外围组件，它负责所有管控 API 的路由，认证，鉴权，审计，加密传输等能力。Management Gateway 基于 Emissary-Ingress[13]，并在之上实现了认证，鉴权等一系列 filter 插件。

  • Ingress

Ingress 在 CNStack 2.0 中负责解决数据浏览，例如日志，监控指标在多集群间的收集。也负责云服务在管控集群部署的治理面组件和在被治理集群上部署的数据面组件之间的数据传输。

CNStack 2.0 的网络通信设计以裸露面最小化为准则，所有管控 API 收敛在 Management Gateway，数据拜访收敛在 Ingress。在多集群环境下，对被治理集群的拜访通过云原生 PaaS 团队开源的 Cluster Gateway [14] 我的项目实现，具备路由通明，权限统一，通信安全的能力。管控集群对被治理集群 ingress 的拜访，以及被治理集群对管控集群 Management Gateway 和 Ingress 的拜访都通过 Kuberetes Headless Service 实现路由，屏蔽网络联通的复杂性。

CNStack 2.0 还蕴含泛滥的云服务，例如提供微服务利用公布，监控，运维，高可用等能力的利用治理服务；提供共享存储服务的 VCNS-OSS；提供虚拟机类型工作负载治理的虚拟化服务；提供边缘场景资源，设施和工作负载治理的云边协同服务；提供云原生服务网格能力的服务网格服务，等等。它们的能力和架构设计会在后续专文介绍。

03 研发提效

CNStack 2.0 是一个蕴含多个云服务的产品汇合。一个无效的研发流程以及相干的集成，测试工具链很大水平上影响着产品的研发效率和品质，并最终左右产品在市场上的口碑和体现。不存在一个完满的研发流程和相干工具，而是依据人员，环境和产品需要一直演进和迭代的。在 CNStack 2.0 的开发过程中，研发团队播种了以下教训。

论每日构建的重要性

每日构建是指在每天晚上或者早上的时候，将产品的各个组件编排为残缺产品，在模仿环境实现部署和验证，并创立可公布的版本。是否能实现每日构建是产品研发效率和品质的一个比拟好的衡量标准，从肯定水平上也阐明了产品部署的灵便和易用性。每日构建在研发过程中具备很重要的价值，包含

  • 及时获取最新的稳固产品公布包，为相干云服务的集成，测试创立工作根底
  • 及时发现组件集成或者服务集成的问题，这些在组件或者服务本身的开发过程中是难以发现的
  • 模仿产品交付的理论场景，让演练成为日常工作

上图是 CNStack 2.0 云服务每日构建的概念流程，其中组件的研发人员在日常开发中将镜像和部署配置，例如 helm charts 等，提交到 git repo 或者外部镜像仓库。当每日构建触发时，建设镜像和部署配置的快照，编排为产品并主动部署和测试，测试通过后实现产品公布。

ADP 平台提供了产品编排，验证环境创立，产品部署等能力。如上图所示，云原生 PaaS 团队基于 ADP 和 Chorus 构建了从开发，集成到测试，公布一整套流水线机制。

  1. 每日构建触发时，Chorus Job 记录以后配置仓库的 commit-id，并将组件上传至 ADP 平台，更新 latest 标识的产品版本，实现产品集成。
  2. 尔后，调用 ADP API 在私有云创立测试环境，并部署产品。通过产品内置的测试 Job 实现自动化测试，并收集测试报告，发送到指定的 IM 平台（如钉钉，邮件群等）实现产品测试。
  3. 产品公布负责人依据测试报告，断定本次构建是否满足公布要求。如果满足，在 ADP 平台依据 Semantic Version 标准，实现产品公布。在日常能够以日期作为公布版本的 Patch Version，在产品预公布阶段能够以 RC 作为 Patch Version。

每日构建触发时，Chorus Job 记录以后配置仓库的 commit-id，并将组件上传至 ADP 平台，更新 latest 标识的产品版本，实现产品集成。

吃本人的狗粮

阿里云 ADP 平台作为 CNStack 2.0 的一部分，不仅负责云服务 / 云组件的编排和公布，同时也负责云服务 / 云组件的集成和测试。CNStack 2.0 根底平台本身也是由 ADP 实现编排，公布和集成，测试的。另一方面，ADP 也基于 CNStack 2.0 根底平台为云服务 / 云组件创立测试环境，组装公布包。在服务第三方云服务 / 云组件研发团队的同时，也在服务本身，吃本人的狗粮。

“吃本人的狗粮”让 CNStack 2.0 产研团队可能和使用者感同身受，切身体会到产品在易用性和性能上的差距。在产品研发的过程中，很多需要和问题的发现都来自产研团队本身。

为本人的研发效率负责

研发提效关系到每个研发，测试工程师本身的工作幸福感。以云原生技术驱动的 CNStack 2.0 和相干的工具链提供了丰盛的 API 和可扩大能力。云原生社区也有一系列可供集成应用的开源我的项目。在云原生技术风行的时代，工程师须要放弃一直学习的精力，开掘和创立可能晋升本身工作效率的办法和工具，为本人的研发效率负责。

相干材料

CNStack 产品官网：https://www.aliyun.com/activi…
CNStack 社区版（收费下载应用）：https://github.com/alibaba/CN…
ADP 产品官网：https://help.aliyun.com/produ…
ACK Distro：https://github.com/AliyunCont…
CNCF Sealer 我的项目：https://github.com/sealerio/s…
CNCF OCM 我的项目：https://open-cluster-manageme…

相干链接

[1] 阿里云云原生利用交付平台（Application Delivery Platform，简称 ADP）https://www.aliyun.com/produc…
[2] Hierarchical Namespace Controller (HNC)https://github.com/kubernetes…
[3] Emissary-Ingresshttps://www.cncf.io/projects/…
[4] cert-managerhttps://www.cncf.io/projects/…
[5] Velerohttps://velero.io/
[6] Open Cluster Management（OCM）https://open-cluster-manageme…
[7] Hybridnethttps://github.com/alibaba/hy…
[8] Open-Localhttps://github.com/alibaba/op…
[9] KeyCloakhttps://github.com/keycloak/k…
[10] Lokihttps://github.com/grafana/loki
[11] Victoria Metricshttps://github.com/VictoriaMe…
[12] Grafanahttps://github.com/grafana/gr…
[13] Emissary-Ingresshttps://www.cncf.io/projects/…
[14] Cluster Gatewayhttps://github.com/oam-dev/cl…

原文链接

本文为阿里云原创内容，未经容许不得转载。

退出移动版