mirror of
https://github.com/labring/sealos.git
synced 2026-08-30 17:58:09 +08:00
docs: Add new blog (#4500)
Signed-off-by: Carson Yang <yangchuansheng33@gmail.com>
This commit is contained in:
Carson Yang
@@ -46,17 +46,17 @@ Sealos['siːləs] is a cloud operating system distribution based on the Kubernet
|
||||
* [Running the Uptime Kuma dial test system on Sealos](https://docs.sealos.io/docs/examples/dial-testing-system/install-uptime-kuma)
|
||||
* [Running a low-code platform on Sealos](https://docs.sealos.io/docs/category/low-code-platform)
|
||||
|
||||
|
||||
|
||||
|
||||
🔍 Some Screen Shots of Sealos:
|
||||
|
||||
<div align="center">
|
||||
|
||||
| Terminal | App Launchpad |
|
||||
| Templates | App Launchpad |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|  |  |
|
||||
| Database | Serverless |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|
||||
</div>
|
||||
|
||||
@@ -67,7 +67,7 @@ Sealos['siːləs] is a cloud operating system distribution based on the Kubernet
|
||||
|
||||
## 💡 Core features
|
||||
|
||||
- 🚀 **Application Management**: Easy management and quick release of publicly accessible distributed applications in the app store.
|
||||
- 🚀 **Application Management**: Easy management and quick release of publicly accessible distributed applications in the templates marketplace.
|
||||
- 🗄️ **Database Management**: Create high-availability databases in seconds, offering support for MySQL, PostgreSQL, MongoDB, and Redis.
|
||||
- 🌥️ **Cloud Universality**: Equally effective in both public and private cloud, enabling a seamless transition of traditional applications to the cloud.
|
||||
|
||||
|
||||
+5
-5
@@ -48,23 +48,23 @@ Sealos 是一款以 Kubernetes 为内核的**云操作系统发行版**。它以
|
||||
* [在 Sealos 上 运行低代码平台](https://sealos.run/docs/category/low-code-platform)
|
||||
* [在 Sealos 上 运行搭建聊天应用](https://sealos.run/docs/examples/social-communication/install-tailchat)
|
||||
|
||||
|
||||
|
||||
|
||||
🔍 您可以通过以下的屏幕截图进一步了解 Sealos，关于 Sealos 更为详细的介绍与说明，请参阅 [什么是 Sealos](https://sealos.run/docs/Intro)。
|
||||
|
||||
<div align="center">
|
||||
|
||||
| 终端 | 应用管理 |
|
||||
| 模板市场 | 应用管理 |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|  |  |
|
||||
| 数据库管理 | 函数计算 |
|
||||
|  |  |
|
||||
|  |  |
|
||||
|
||||
</div>
|
||||
|
||||
## 💡 核心功能
|
||||
|
||||
- 🚀 **应用管理**：在应用商店中轻松管理并快速发布可公网访问的分布式应用。
|
||||
- 🚀 **应用管理**：在模板市场中轻松管理并快速发布可公网访问的分布式应用。
|
||||
- 🗄️ **数据库管理**：秒级创建高可用数据库，支持 MySQL、PostgreSQL、MongoDB 和 Redis。
|
||||
- 🌥️ **公私一致**：即是公有云也是私有云，支持传统应用无缝迁移到云环境。
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 134 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 151 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 128 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 144 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 149 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 122 KiB After Width: | Height: | Size: 156 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 148 KiB After Width: | Height: | Size: 158 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 197 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 178 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
+127
@@ -0,0 +1,127 @@
|
||||
---
|
||||
slug: how-sealos-cloud-mastered-multi-tenancy-with-the-right-gateway-choice
|
||||
title: How Sealos Cloud Mastered Multi-Tenancy with the Right Gateway Choice
|
||||
description: Explore how Sealos Cloud optimizes its gateway selection amidst handling hundreds of thousands of Ingress rules and strict multi-tenancy requirements. From the limitations of Nginx Ingress to the eventual choice of Higress, this article delves deep into the performance, stability, and security of various gateway options, offering valuable insights for gateway selection in multi-tenant scenarios in public network environments.
|
||||
authors: [fanux]
|
||||
tags: [Kubernetes, Sealos, Gateway]
|
||||
keywords: [Cloud Operating System, Sealos, K8s, Cloud Native, Gateway, Envoy, Ingress]
|
||||
image: images/feature.jpg
|
||||
date: 2024-01-20T10:00
|
||||
---
|
||||
|
||||
[Sealos](https://sealos.io) Cloud has stretched the capabilities of nearly all the leading open-source gateways to their limits. This article aims to serve as a practical guide, helping to navigate common challenges and offering advice for choosing the right gateway.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Complex Challenges in Sealos Cloud
|
||||
|
||||
Ever since the launch of [Sealos Cloud](https://cloud.sealos.io), the platform has seen a meteoric rise in user numbers, currently standing at **87,000 registered users**. Each of these users creates applications, and each application demands its individual access point, leading to an extraordinarily large number of routing entries across the entire cluster. **This necessitates support for ingress capabilities on the scale of hundreds of thousands.**
|
||||
|
||||
Furthermore, offering shared cluster services on the public internet places stringent demands on multi-tenancy. It's crucial that user routes are completely isolated from one another to ensure optimal route integrity, demanding high-quality isolation and sophisticated traffic control measures.
|
||||
|
||||
The exposure to potential cyber threats is extensive in public clouds. Hackers not only target applications running on the cloud but also aim at the platform's outbound network infrastructure, thereby intensifying the security challenges.
|
||||
|
||||
The demands on controller performance and stability are substantial. Many controllers, when faced with an increasing number of routing entries, consume extensive resources, which can sometimes lead to Out of Memory (OOM) issues, ultimately causing gateway failures.
|
||||
|
||||
## Nginx Ingress
|
||||
|
||||
Our initial choice was Nginx Ingress, but we eventually faced several critical issues that proved to be deal-breakers:
|
||||
|
||||
* **Reload dilemma**: Every ingress modification results in brief disconnections. In a cluster bustling with users, the high frequency of ingress adjustments leads to consistent network instability.
|
||||
* **Unreliable long connections**: Due to the dynamic nature of adjustments, long-term connections are prone to frequent disruptions.
|
||||
* **Suboptimal performance:** The gateway's responsiveness is sluggish, and it's relatively resource-hungry.
|
||||
|
||||
These significant concerns have led us to move away from gateways rooted in Nginx architecture. Our empirical testing revealed that Envoy-based gateways significantly outperform others, showing minimal performance overhead in both the control and data planes.
|
||||
|
||||
Here's a glimpse of Envoy's performance:
|
||||
|
||||
|
||||
|
||||
In contrast, here's what we observed with Nginx's performance:
|
||||
|
||||
|
||||
|
||||
The disparity is pronounced, leading us to decisively set aside options based on Nginx and fully embrace the robust capabilities of Envoy.
|
||||
|
||||
## APISIX
|
||||
|
||||
[APISIX](https://github.com/apache/apisix) is a commendable project, particularly in addressing Nginx reload issues. At [Laf](https://github.com/labring/laf), we initially embraced APISIX. However, we encountered instability with its Ingress Controller, leading to frequent major disruptions and controller OOM issues. Despite our preference for APISIX, these persistent issues necessitated a switch to an alternative gateway. The APISIX community is actively working on these challenges, and we look forward to its continued improvement.
|
||||
|
||||
In summary, while APISIX demonstrates excellent stability, its controller still requires significant optimization and stability enhancements. The community provides robust support, but **due to our immediate operational challenges, we had to transition to a different gateway solution.**
|
||||
|
||||
## Cilium Gateway
|
||||
|
||||
Having switched our [CNI](https://sealos.io/docs/self-hosting/lifecycle-management/quick-start/deploy-kubernetes#install-kubernetes-cluster) to Cilium early on, we recognized its potential and contemplated using the Cilium Gateway. However, reality presented its challenges.
|
||||
|
||||
[Cilium Gateway](https://cilium.io/use-cases/gateway-api/) exclusively supports LB mode, creating a dependency on cloud provider LBs. Given our need for private deployment scenarios, this dependence was undesirable. In terms of stability, the Ingress activation delay in scenarios with numerous routes was significantly prolonged, taking minutes instead of the preferable 5 seconds. **Therefore, we concluded that it's necessary to wait for further development in this aspect.**
|
||||
|
||||
## Envoy Gateway
|
||||
|
||||
In the realm of Kubernetes (K8s) standards, there is a noticeable shift from the traditional Ingress to the Gateway standard. Our foundational preference for Envoy leads us to consider the implementation of the [Envoy Gateway](https://github.com/envoyproxy/gateway) as a promising option. Our exploration of the Envoy Gateway revealed that it is still in a preliminary phase, plagued by several instability issues like memory overflows, path policies not being effective, and certain functionalities not working in the merge gateway mode. We are actively engaged in resolving these issues and are contributing to the upstream community with constructive feedback and improvements. Our aim is to nurture the Envoy Gateway to a level where it becomes fully viable for production environments.
|
||||
|
||||
## The High-Prestige but Less Practical Gateway Standard
|
||||
|
||||
The Gateway standard finds itself in a tricky situation. It appears the designers may not have thoroughly explored multi-tenant environments in practice. When a cluster is shared among multiple tenants, it is crucial to clearly define and separate the rights and responsibilities of administrators and users. Gateway's initial design overlooked this aspect. For instance:
|
||||
|
||||
```yaml
|
||||
apiVersion: gateway.networking.k8s.io/v1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: eg
|
||||
spec:
|
||||
gatewayClassName: eg
|
||||
listeners:
|
||||
- name: http
|
||||
port: 80
|
||||
protocol: HTTP
|
||||
# hostname: "*.example.com"
|
||||
- name: https
|
||||
port: 443
|
||||
protocol: HTTPS
|
||||
# hostname: "*.example.com"
|
||||
tls:
|
||||
mode: Terminate
|
||||
certificateRefs:
|
||||
- kind: Secret
|
||||
name: example-com
|
||||
```
|
||||
|
||||
Settings like listening ports should ideally be managed by cluster administrators rather than ordinary users. On the other hand, configuring TLS certificates should be more user-centric, although administrators might still need some control. However, in this setup, the delineation of permissions is unclear. Consequently, users are also given the ability to configure the Gateway, leading to the necessity for intricate permission control in the controller, such as managing port whitelists and detecting conflicts.
|
||||
|
||||
A more sophisticated design approach might involve relocating tenant-level fields to HTTPRoute or establishing a separate CRD, thereby clarifying the distinction between regular users and super administrators. The current approach is functional, but it tends to be somewhat muddled and less efficient.
|
||||
|
||||
## Higress: The Clear Winner
|
||||
|
||||
Beyond the key projects we focused on, numerous others were evaluated but are not listed here. Ultimately, Sealos chose [Higress](https://github.com/alibaba/higress) for its gateway needs.
|
||||
|
||||
Our criteria for gateway selection were straightforward: we sought a solution that was not only functionally adequate but also highly stable. Higress emerged as our choice, essentially by process of elimination.
|
||||
|
||||
**Stability was our primary concern. Among the contenders, Higress was the only one meeting our production standards**, although some challenges arose. Thankfully, the proactive Higress community swiftly resolved these issues. Notable challenges included:
|
||||
|
||||
1. **Ingress Activation Speed** – Initially, it took over two minutes for new routes to activate when dealing with many entries. This was optimized by the community to about 3 seconds, a remarkable improvement that eliminated the need for further optimization, as it now outpaces the container Ready time. Higress's use of an incremental configuration loading approach ensures exceptional performance, even with a high volume of routing entries.
|
||||
2. **Controller OOM** – Previously, the controller faced memory issues due to high resource consumption without dynamic loading. These issues have been effectively addressed.
|
||||
3. **Timeout Issues** – In one of our primary clusters, we encountered sporadic request timeouts related to the onDemandRDS configuration. We've temporarily disabled this feature and are investigating further. This problem was not present in our other clusters.
|
||||
|
||||
From a security standpoint, many issues we faced were linked to performance bottlenecks, such as traffic surges overwhelming the gateway. This underscores the vital importance of gateway performance. In our tests, Envoy demonstrated remarkable robustness, and the design of the controller proved to be a critical factor in operational success. Higress has shown exceptional performance in this regard:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Given our extensive routing and high-volume traffic, Higress stands out for its remarkably low resource demand.
|
||||
|
||||
Higress also boasts compatibility with Nginx Ingress syntax, mainly in annotations. Our prior reliance on Ingress meant there was almost no need for code migration, allowing for a swift upgrade process within minutes.
|
||||
|
||||
To further encourage community development, we also have recommendations for Higress:
|
||||
|
||||
* Enhanced support for the Gateway standard is needed. Although it already supports the v1 version, it lacks full compatibility with the features available on Ingress.
|
||||
* We suggest the introduction of more sophisticated functionalities, especially in areas like security and circuit breaking. We are open to paying for these features, but as our platform evolves, stronger functionalities become necessary.
|
||||
* We advise developing additional peripheral features through a plugin mechanism, aiming to make the core features more cohesive, simpler, and more reliable.
|
||||
|
||||
## Summary
|
||||
|
||||
Gateways are a fundamental component for cloud services and applications. As our scale grows, we face an array of new challenges. Our aim is to build strong collaborations with the broader community, enhancing the development of open-source gateways and benefiting a larger pool of developers.
|
||||
|
||||
The gateways mentioned are all of high quality. Sealos not utilizing them is not a commentary on their effectiveness but a reflection of our unique and stringent scenarios. Gateways that support multi-tenancy in public internet environments are few. Therefore, it's crucial for decision-makers to consider their specific scenarios. Our choices should serve as a guideline, and Sealos is dedicated to maintaining an open approach in monitoring the evolution of various gateways.
|
||||
|
||||
We are immensely grateful to the Higress open-source community for their substantial support and to the Alibaba Cloud Native Team for contributing such a valuable project to the community.
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
slug: how-sealos-cloud-mastered-multi-tenancy-with-the-right-gateway-choice
|
||||
title: Sealos 网关选型血泪史：云原生网关哪家强
|
||||
description: 探索 Sealos Cloud 如何在面对数十万条 Ingress 规则和严格的多租户要求中优化其网关选择。从 Nginx Ingress 的局限性到最终选择 Higress，这篇文章深入分析了各种网关选项的性能、稳定性和安全性，为公网环境中支持多租户场景的网关选型提供了宝贵的洞见。
|
||||
authors: [fanux]
|
||||
tags: [Kubernetes, Sealos, 网关]
|
||||
keywords: [云操作系统, Sealos, K8s, 云原生, 网关, Envoy, Ingress]
|
||||
image: images/feature.jpg
|
||||
date: 2024-01-20T10:00
|
||||
---
|
||||
|
||||
[Sealos](https://sealos.run) 公有云几乎打爆了市面上所有主流的开源网关，本文可以给大家很好的避坑，在网关选型方面做一些参考。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Sealos Cloud 的复杂场景
|
||||
|
||||
[Sealos 公有云](https://cloud.sealos.io)上线以来，用户呈爆发式增长，目前总共注册用户 8.7w，每个用户都去创建应用，每个应用都需要有自己的访问入口，就导致整个集群路由条目非常巨大，需要有支撑数十万条 ingress 的能力。
|
||||
|
||||
另外，在公网提供共享集群的服务，对多租户要求极为苛刻，用户之间的路由必须不能相互影响，需要非常好的隔离性，以及流量控制能力。
|
||||
|
||||
公有云的受攻击面是很大的，黑客会攻击云上跑的用户应用，也会直接攻击平台的出口网络，安全性上也有非常大的挑战。
|
||||
|
||||
对控制器的性能和稳定要求都比较高，很多控制器路由条目一多时消耗资源会非常大，甚至 OOM 导致网关奔溃。
|
||||
|
||||
## 排除 Nginx Ingress
|
||||
|
||||
我们最早用的就是 Nginx Ingress, 最后发现有几个核心问题无法解决：
|
||||
|
||||
* reload 问题，每次有 ingress 变更会导致断连一小会，而一个集群用户一多的时候，ingress 的创建变更会是个频繁事件，就会导致网络经常不稳定。
|
||||
* 长链接不稳定，也是因为变更，在用的长链接会经常断。
|
||||
* 性能不行，生效时间慢，消耗资源多。
|
||||
|
||||
所以几乎排除掉了很多底层用 Nginx 实现的网关。我们实测下来基于 Envoy 实现的网关性能彪悍太多，几乎控制面和数据面都不怎么消耗性能。
|
||||
|
||||
这是 Envoy 的：
|
||||
|
||||
|
||||
|
||||
这是 Nginx 的：
|
||||
|
||||
|
||||
|
||||
差距非常之大，所以我们就可以排除掉 Nginx 系列选项了。彻底拥抱 Envoy。
|
||||
|
||||
## 关于 APISIX
|
||||
|
||||
APISIX 本身是个优秀项目，解决了 Nginx reload 的一些问题，所以我们 [Laf](https://laf.run) 早期也用了 APISIX，但是很不幸 APISIX 的 Ingress Controller 并不是很稳定，控制面奔溃给造成了我们好几次大的故障，还出现过控制器 OOM 等问题，我们本来真的很想用，但是最终还是因为故障问题被强制劝退，当然 APISIX 社区也在一直跟进这些问题，希望能越做越好。
|
||||
|
||||
总结一下就是: APISIX 本身稳定性很好，但是控制器需要优化的东西还很多，稳定性也有待提高。社区支持力度也很大，无奈我们线上问题火烧眉毛没法按照社区的节奏慢慢迭代，只能先切成别的网关了。
|
||||
|
||||
## Cilium Gateway
|
||||
|
||||
[Sealos 的 CNI](https://sealos.run/docs/self-hosting/lifecycle-management/quick-start/deploy-kubernetes#%E5%AE%89%E8%A3%85-k8s-%E9%9B%86%E7%BE%A4-1) 很早就切换成 Cilium 了，确实很强，所以我们想着网关也统一用 Cilium 得了，但是现实很骨感。
|
||||
|
||||
Cilium Gateway 只支持 LB 模式，这样就强依赖云厂商的 LB，而我们也有一些私有化的场景，所以不希望耦合，稳定性方面也遇到了路由非常多的时候 Ingress 生效特别慢的问题，需要分钟级生效，这样用户的体验就很差了，我们能接受的是 5s 内路由生效。所以结论就是只能再等等。
|
||||
|
||||
## Envoy Gateway
|
||||
|
||||
K8s 标准的发展来看，会逐渐从 Ingress 迁移到 Gateway 的标准，而我们底层又更倾向使用 Envoy，那 Envoy Gateway 的实现似乎是一个很好的选择，所以我们调研了 Envoy Gateway, 但是这个项目还是太过于早期，遇到了一些不稳定的 bug，比如会 OOM，pathpolicy 不生效，有些特性在 merge gateway 模式下不生效等问题，在持续解决中，我们也在不断帮助上游社区提改进意见和贡献，希望未来可以能达到生产可用的状态。
|
||||
|
||||
## 逼格很高但不那么实用的 Gateway 标准
|
||||
|
||||
Gateway 的处境很尬感，我的感觉是设计者并没有真的实践过多租户场景，当多租户共享一个集群时，就要明确区分管理者和使用者的权限问题，Gateway 设计之初就没完全考虑清楚，举个例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: gateway.networking.k8s.io/v1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: eg
|
||||
spec:
|
||||
gatewayClassName: eg
|
||||
listeners:
|
||||
- name: http
|
||||
port: 80
|
||||
protocol: HTTP
|
||||
# hostname: "*.example.com"
|
||||
- name: https
|
||||
port: 443
|
||||
protocol: HTTPS
|
||||
# hostname: "*.example.com"
|
||||
tls:
|
||||
mode: Terminate
|
||||
certificateRefs:
|
||||
- kind: Secret
|
||||
name: example-com
|
||||
```
|
||||
这里监听端口这类的配置应该是给集群管理员而不是普通用户，而 TLS 证书的配置属于某个应用，管理员可以有权限配置，主要还是每个用户去配置自己的，所以这里面权限就没有分开。 那就只能让用户也有权限配置 Gateway，所以这里就又需要在控制器里实现很多的权限控制的细节问题，如端口号白名单，冲突检测等。
|
||||
|
||||
个人觉得更优雅的设计是把其中租户级别的字段下沉到 HTTPRoute 中实现，或者一个单独的 CRD,这样用户态和超级管理员就可以分开的更清楚。 现有的方式也能做，就是有点混杂。
|
||||
|
||||
## 最终 Higress 胜出
|
||||
|
||||
除了以上重点的项目我们还测试了很多其他项目，我这里就不一一列举了。 Sealos 最终选了 Higress。
|
||||
|
||||
我们目前选择网关的逻辑很简单，主要就是在满足我们功能的前提下足够稳定，最终选择 Higress 几乎是排除法得出来的。
|
||||
|
||||
稳定性是排在第一位的，在我们的场景里面能够达到生产可用的目前只有 Higress，不过实践过程中也出现过一些问题，好在 Higress 社区的支持力度很大，很快速的解决了，主要有几个：
|
||||
|
||||
1. ingress 生效速度慢，路由条目多时 2min 多新建路由才能生效，社区最后优化到了 3s 左右，这已经到极致了，也没有再优化的必要了，因为已经比容器 Ready 时间还短了, Higress 使用了一种增量加载配置的机制，让海量路由条目时也能有夸张的性能。
|
||||
2. 控制器 OOM,在无动态加载时资源消耗比较大，出现过 OOM 的情况，目前三高问题都解决掉了。
|
||||
3. 超时问题，有一个进一步优化加载延时的参数配置 onDemandRDS 在我们一个主集群会偶发请求超时，目前是把该配置关闭了，还在进一步查看原因，而在其它集群中未发现这个问题。
|
||||
|
||||
安全性方面，我们很多时候的故障问题都是性能问题造成的，流量过大，打爆网关比较常见，所以网关的性能变得至关重要，实测下来 Envoy 要彪悍很多，控制器写的好不好也生死攸关，这个方面 Higress 表现出众：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在我们已经海量路由，超高并发的情况下，需要的资源少的可怜。
|
||||
|
||||
Higress 还兼容 Nginx Ingress 语法，主要是一些 annotations，我们之前的代码都是用的 Ingress，所以几乎没有任何迁移成本，直接几分钟的升级就可以搞定。
|
||||
|
||||
同样为了促进社区更好的发展我们也给 Higress 一些意见：
|
||||
|
||||
* 能对 Gateway 的标准有更好的支持，目前虽然已经支持了 v1 版本，但还没有完全兼容 ingress 上的能力。
|
||||
* 能开放出一些大杀器的功能，比如安全和熔断方面的能力。让开源和商业结合的更紧密一些，我们倒是不排斥付费，但是随着平台发展，需要更强的一些功能。
|
||||
* 周边功能建议更多通过插件机制扩展，让核心功能更内聚一些，简单可依赖。
|
||||
|
||||
## 总结
|
||||
|
||||
网关对于云和应用而言是个非常非常核心的组件，随着我们规模的不断扩大也会出现很多新的挑战，我们希望能和上下游社区建立紧密的合作，让开源网关能得到更好的发展，让更多开发者受益。
|
||||
|
||||
以上列举的很多网关都很优秀，Sealos 没用不代表项目不厉害，只是我们的场景苛刻且奇葩，真的在公网环境能支持多租户的网关并不多，所以各位看官还是要从自己的场景出发，我们的选型仅作参考，同样 Sealos 本身也会以一个开放心态来继续跟进其他网关的发展。
|
||||
|
||||
最后非常感谢 Higress 开源社区的大力支持，感谢阿里云云原生团队开源了这么优秀的项目，造福广大社区用户。
|
||||
@@ -228,11 +228,11 @@ const config = {
|
||||
},
|
||||
scripts: [
|
||||
{
|
||||
src: "/wow.min.js",
|
||||
src: "wow.min.js",
|
||||
async: false,
|
||||
},
|
||||
{
|
||||
src: "/global.js",
|
||||
src: "global.js",
|
||||
async: true,
|
||||
}
|
||||
],
|
||||
|
||||
Reference in New Issue
Block a user