隆重推出 NGINX Gateway Fabric 1.0 版本-低调大师

隆重推出 NGINX Gateway Fabric 1.0 版本

2024-07-03 316

原文作者：Ilya Krutov - F5 NGINX 产品营销经理

原文链接：隆重推出 NGINX Gateway Fabric 1.0 版本

转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

今天，我们迎来了一个重要的里程碑 — NGINX Gateway Fabric 的首个主要版本 — 1.0 版本正式发布！

NGINX Gateway Fabric 借助 Gateway API 规范和全球使用最广泛的数据平面之一 NGINX 提供快速、可靠和安全的 Kubernetes 应用互联。

借助 NGINX Gateway Fabric，我们为 Kubernetes 创建了一个新的工具类别 — 一种统一的应用交付结构，旨在简化 Kubernetes 中的应用、服务和 API 互联，从而降低复杂性，提高可用性，并提供大规模的安全防护和可见性。

作为 Kubernetes 互联套件的一部分，NGINX Gateway Fabric 是我们基于经过验证的 NGINX 数据平面构建的 Gateway API 的一致性实现。Gateway API 是一个跨厂商的开源项目，旨在规范并改进 Kubernetes 中的应用和服务网络。NGINX 一直积极参与其中。

Gateway API 是由 Kubernetes Ingress API 演变而来，可解决在生产环境中使用 Ingress 对象的限制，包括配置高级用例和在同一基础设施中支持多租户团队时的复杂性和易错性。此外，Gateway API 还建立了 GAMMA（Gateway API for Mesh Management and Administration）子组，用于研究和定义适合 service mesh（服务网格）用例的 Gateway API 规范的功能和资源。

展望未来，NGINX 希望利用 Gateway API 实现 Kubernetes 集群内外应用和 API 的统一互联，而 NGINX Gateway Fabric 就承载了我们这一愿景。它能够支持南北向和东西向 Kubernetes 应用与服务互联用例，有效地将 Ingress controller 和 service mesh 功能集成到一套统一工具中，以便利用同一控制平面和数据平面跨任何 Kubernetes 环境进行集中管理。

在 1.0 版本中，我们重点关注 Kubernetes 集群边缘的高级互联用例，例如蓝绿部署、TLS 卸载和 SNI 路由。在未来路线图中，我们计划通过更多的安全防护和可观测性特性来扩展这些功能，包括解决 service 到 service 通信用例。

什么是 NGINX Gateway Fabric？

NGINX Gateway Fabric 具有对高级用例的内置支持、基于角色的 API 模型及出色的可扩展性，可释放 NGINX 的强大潜力，满足未来 Kubernetes 集群内外应用和服务的互联需求。

NGINX Gateway Fabric 通过将基于角色的访问控制（RBAC）映射到相关角色（基础设施提供人员、集群运维人员和应用开发人员），对三个主要的 Gateway API 资源（GatewayClass、Gateway 和 Route）进行了标准化。

明确定义并划分不同角色的职责范围有助于简化管理。具体来说，基础设施提供人员负责为 Kubernetes 集群定义 GatewayClasses，集群运维人员则负责在集群中部署和配置 Gateway（包括策略），而应用开发人员可以自由地将 Route 附加到 Gateway，以对外暴露应用，同时共享同一底层基础设施。当客户端连接到其应用时，NGINX Gateway Fabric 会将这些请求路由到相应的应用。

如欲详细了解 NGINX Gateway Fabric 如何处理复杂路由规则，请阅读我们的博文《NGINX Gateway Fabric 如何实现复杂的路由规则》。

NGINX Gateway Fabric 的优势

NGINX Gateway Fabric 有助于延长从边缘到云端的 Kubernetes 环境的正常运行时间并降低其复杂性，可简化运维，解锁高级功能，并为 Kubernetes 环境提供无缝互操作性，从而满足未来 Kubernetes 应用和服务的更高互联需求。

NGINX Gateway Fabric 的优势包括：

数据平面 – NGINX Gateway Fabric 基于全球最受欢迎的数据平面之一而构建，可确保快速、可靠和安全的 Kubernetes 应用互联。它通过在混合多云 Kubernetes 环境中利用相同的数据平面和控制平面，简化了 Kubernetes 平台部署和管理，有助于降低复杂性并减少工具蔓延。
可扩展性 – 与 Kubernetes Ingress 资源不同，NGINX Gateway Fabric 不仅提供了许多现成的高级用例，包括蓝绿部署和灰度部署、A/B 测试及请求/响应操作，而且还定义了一个带有扩展点和策略附加的无注释可扩展性模型，可解锁 API 本身不支持的高级 NGINX 数据平面功能。
互操作性 – NGINX Gateway Fabric 是 Gateway API 的专用且一致的实现，具有高级配置兼容性和可移植性，便于更轻松地跨不同实现迁移。其 Kubernetes 原生设计能够确保与 Prometheus 和 Grafana 等其他 Kubernetes 平台工具与流程的无缝生态系统集成。
治理功能 – NGINX Gateway Fabric 采用基于角色的原生 API 模型，可实现自助治理功能，以便在多租户团队之间共享基础设施。作为一个开源项目，它遵循既定的社区治理程序，在其开发流程、功能路线图和贡献方面保持完全透明。
一致性 – 根据标准化一致性测试，NGINX Gateway Fabric 已经测试和验证，符合 Gateway API 规范，可确保 API 运维体验的一致性。

NGINX Gateway Fabric 架构

我们并未将 Gateway API 功能强加到 NGINX Ingress Controller 中，而是作为一个完全独立的项目，创建了 NGINX Gateway Fabric 来实现 Kubernetes Gateway API。如欲了解其背后的原因，请阅读我们的博文《为何我们决定从零开始创建 NGINX Gateway Fabric》。

NGINX Gateway Fabric pod 由两个容器组成：

nginx 容器 – 提供数据平面，由 NGINX 主进程和 NGINX worker 进程组成。主进程控制着 worker 进程，后者负责处理客户端流量，并将流量负载均衡到后端应用。
nginx-gateway 容器 – 提供控制平面，监控 Kubernetes 对象（Service、Endpoint、Secrets 及 Gateway API CRD），并配置 NGINX。

有关 NGINX Gateway Fabric 的设计、架构及组件交互的详细说明，请参阅项目文档。

NGINX Gateway Fabric 入门

如果您希望了解 NGINX 的 Gateway API 实现，请访问 GitHub 上的 NGINX Gateway Fabric 项目。您可通过以下方式参与其中：

以贡献者的身份加入项目
在实验室中试用实现
执行测试并提供反馈

NGINX 唯一中文官方社区，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：开源社区官网 | 微信公众号

微信关注我们

原文链接：https://my.oschina.net/u/5246775/blog/11318462

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

从PDF到OFD，国产化浪潮下多种文档格式导出的完美解决方案

前言近年来，中国在信息技术领域持续追求自主创新和供应链安全，伴随信创上升为国家战略，一些行业也开始明确要求文件导出的格式必须为 OFD 格式。OFD 格式目前在政府、金融、税务、教育、医疗等需要文件开放、共享和长期保存的行业中广泛应用。这种趋势在未来几年内将进一步增强。相较于 PDF，OFD 在以下方面展现了明显的优势，具体体现在：开放性 PDF 是 Adobe 公司开发的专有格式，虽然也被广泛应用，但受制于 Adobe 公司的软件和许可。OFD 则是基于国际开放标准制定的开放式文档格式，任何人或组织都可以自由使用和开发相关软件。功能特性 PDF 主要用于文档展示和打印，功能较为单一。OFD 在文档展示、打印、编辑等方面都有更强大的功能支持。文件大小 PDF 文件通常会略大于 OFD 文件，因为 PDF 包含更多的元数据和功能，OFD 文件在保持良好的视觉效果的前提下,通常体积更小。兼容性 PDF 虽然跨平台性强,但在不同软件和系统中的表现可能会有差异，OFD 则具有更好的跨平台一致性。安全性 PDF 文件可能包含隐藏的功能和潜在的安全隐患，OFD 则更加透明，安全性更高...

2024-07-03

304

编者按：大模型的上下文理解能力直接影响到 LLMs 在复杂任务和长对话中的表现。本期内容聚焦于两种主流技术：长上下文(Large Context Windows)和检索增强生成(RAG)。这两种技术各有何优势？在实际应用中，我们又该如何权衡选择？文章不仅详细阐述了这两种技术的工作原理，还深入分析了它们在效率、准确性和实施成本等方面的差异。文章特别提到了在执行重复性任务时使用 Context Caching 优化长上下文的优势，然而，缓存策略的效果很大程度上取决于提示词的可预测性。如果用户输入变化无常，缓存的效果可能会大打折扣。本文可供各位读者进行技术选型时参考，期待未来看到更多提升 LLMs 上下文理解能力的创新方案。作者 | Priyanka Vergadia 编译 | 岳扬大语言模型（Large Language Models ，LLMs）技术正飞速发展，尤其是模型在生成文本时能够处理的上下文信息量极速提升。尽管 LLMs 在文本的处理和生成等方面表现出色，但它们却面临一个固有的挑战：难以捕捉信息背景全貌，尤其是在应对冗长对话或涉及多重细节的复杂任务时。为了解决这一问题，研...

2024-07-03

338

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。