Cloud Native Computing Foundation
·
构建Gloo和kgateway七年的五个经验教训
💡
原文英文，约1500词，阅读约需6分钟。
📝
内容提要
Gloo开源项目自2018年启动，2019年达成GA，现已拥有众多付费客户和开源用户。我们将Gloo Gateway捐赠给CNCF，分享七年的经验教训，强调简化配置和提高可扩展性。
🎯
关键要点
- Gloo开源项目于2018年启动，2019年达成GA，现已拥有众多付费客户和开源用户。
- Gloo Gateway被捐赠给CNCF，旨在丰富云原生API网关生态系统。
- 未能更早将Gloo捐赠给CNCF是一个遗憾，早期捐赠可能会加速项目发展。
- 最初尝试覆盖所有用例，结果发现用户更倾向于简化配置而非复杂选项。
- 设计Gloo时，Proxy资源过于庞大，导致性能问题，决定在kgateway中将其保持为内部资源。
- 重新思考控制平面的可扩展性，避免了低效的快照结构。
- Envoy过滤器的用户自定义可能导致升级时的破坏性变化，因此在kgateway中不支持用户配置的Envoy过滤器。
- 在CRD设计中，确保需要事务一致性的资源在同一CRD中，以避免系统不一致。
- 标签选择的扩展性问题通过预定义标签路由委托来优化，避免了O(N^2)的复杂度。
- 探索使用Istio控制平面管理Gloo网关代理，但由于缺乏必要功能，最终选择了更灵活的设计。
- 使用krt框架简化了依赖跟踪和索引，提升了可扩展性。
- 欢迎社区参与kgateway项目，提供技术内容和协作机会。
❓
延伸问答
Gloo项目的启动时间和GA达成时间是什么？
Gloo项目于2018年启动，2019年达成GA。
Gloo Gateway被捐赠给哪个组织？
Gloo Gateway被捐赠给CNCF。
在Gloo的开发过程中，遇到了哪些主要的性能问题？
Proxy资源过于庞大导致性能问题，影响了序列化和反序列化。
Gloo在设计时如何处理用户自定义的Envoy过滤器？
在kgateway中不支持用户配置的Envoy过滤器，以避免升级时的破坏性变化。
Gloo在CRD设计中如何确保事务一致性？
确保需要事务一致性的资源在同一CRD中，以避免系统不一致。
Gloo如何优化标签选择的扩展性问题？
通过预定义标签路由委托来优化，避免了O(N^2)的复杂度。
➡️
