Cloud Native Computing Foundation
·
构建Gloo和kgateway七年的五个经验教训
内容提要
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项目，提供技术内容和协作机会。
延伸解读
捐赠CNCF的时机
Gloo团队反思未能早期将项目捐赠给CNCF的决定，认为如果能更早进行捐赠，可能会加速项目的发展并吸引更多贡献者。这提醒我们在开源项目中，及时的社区参与和支持是至关重要的，能够为项目带来更大的发展潜力。
简化配置的重要性
Gloo的经验表明，用户更倾向于简化的配置而非复杂的选项。过多的配置选项不仅会导致用户困惑，还可能影响项目的可用性。这一教训适用于所有开源项目，强调了在设计时应优先考虑用户体验，避免过度设计。
控制平面的可扩展性
在设计kgateway时，团队重新思考了控制平面的可扩展性，避免了低效的快照结构。通过优化资源处理方式，确保了系统在面对变化时的高效性。这一策略对于希望提升系统性能的开发者具有重要的借鉴意义。
Envoy过滤器的挑战
Gloo团队发现，用户自定义的Envoy过滤器可能在升级时引发破坏性变化，因此在kgateway中不支持用户配置的Envoy过滤器。这一决策强调了在设计可扩展系统时，必须平衡灵活性与稳定性，以避免潜在的性能瓶颈和兼容性问题。
延伸问答
Gloo项目的启动时间和GA达成时间是什么？
Gloo项目于2018年启动，2019年达成GA。
Gloo Gateway被捐赠给哪个组织？
Gloo Gateway被捐赠给CNCF。
在Gloo的开发过程中，遇到了哪些主要的性能问题？
Proxy资源过于庞大导致性能问题，影响了序列化和反序列化。
Gloo在设计时如何处理用户自定义的Envoy过滤器？
在kgateway中不支持用户配置的Envoy过滤器，以避免升级时的破坏性变化。
Gloo在CRD设计中如何确保事务一致性？
确保需要事务一致性的资源在同一CRD中，以避免系统不一致。
Gloo如何优化标签选择的扩展性问题？
通过预定义标签路由委托来优化，避免了O(N^2)的复杂度。
