点赞
评论
收藏
分享
举报
NGINX Ingress Controller for Kubernetes
发表于2020-12-30 14:24

浏览 4.3k

在 Kubernetes 上实现高速应用交付

运行于 Kubernetes 之上的应用需要一个经过验证的生产级应用交付解决方案。NGINX Ingress Controller将值得信赖的 NGINX Open Source 和 NGINX Plus 软件负载均衡器与基于标准 Kubernetes Ingress 或自定义 NGINX Ingress 资源的简化配置结合在一起,可确保 Kubernetes 集群中的应用可靠、安全且高速地交付。


为何使用 NGINX Ingress Controller for Kubernetes?

• 降低复杂性 – 使用标准 Kubernetes Ingress 资源配置 NGINX 或 NGINX Plus,或利用新的 NGINX Ingress 资源,而非编写原生 NGINX 配置。

• 高级负载均衡 – 通过 NGINX Ingress 资源的高级负载均衡和请求路由特性支持蓝绿部署、Canary 发布、A/B 测试和熔断器。

• 多协议支持 – 交付 HTTP、HTTP/2、gRPC、TCP 和 UDP 应用。

• 可观察性 – 利用跟踪支持(通过 OpenTracing)、详细记录功能和原生 Prometheus 集成,以及有关应用流量的大量实时统计信息(支持 NGINX Plus)。

• 安全性 – 通过可配置的加密(包括通配符证书)优化 SSL/TLS 终止性能,并使用 JWT 身份验证(支持 NGINX Plus)保护应用安全。

• 自助服务和多租户 – 利用 NGINX Ingress 资源的 RBAC 和跨命名空间功能,跨不同团队明确划分和委派应用交付组件管理。

• 生产就绪型 – 稳定、可靠的 Ingress Controller通过了 NGINX 测试,并为 NGINX Plus 客户提供 24x7 全天候支持,让您安心无忧。

关键功能

高级请求路由

较之标准 Kubernetes Ingress 资源,自定义 NGINX Ingress 资源(VirtualServer 和 VirtualServerRoute)能够为您提供更高的流量分类和路由决策控制能力。NGINX Ingress 资源支持:

• 基于请求 URI、标头、cookie 和方法执行请求路由

• 根据权重在多个应用版本之间进行流量分流

upstreams:

  • - name: webapp-v1 service: webapp-svc-v1 port: 80
  • - name: webapp-v2 service: webapp-svc-v2 port: 80

routes:

  • - path: / splits:
    • - weight: 90 action:

pass: webapp-v1

  • - weight: 10 action:

pass: webapp-v2

使用 NGINX Ingress 资源进行流量分流


upstreams:

  • - name: webapp-v1 service: webapp-svc-v1 port: 80
  • - name: webapp-v2 service: webapp-svc-v2 port: 80

routes:

  • - path: / matches:

- conditions:

- cookie: debug value: true

action:

pass: webapp-v2 action:

pass: webapp-v1

基于 NGINX Ingress 资源中的 cookie 执行请求路由


RBAC 和多租户

NGINX Ingress 资源允许将各种流量配置组件委派给不同的团队,同时仍支持对所有公开的服务执行全局配置。例如,这支持安全运营团队对某资源 (VirtualServer) 上的所有公开服务执行 TLS 设置,同时通过将相应资源 (VirtualServerRoute) 部署至单独的 Kubernetes 命名空间而将上游配置委派给一个或多个应用所有者。此类委派将使用 Kubernetes 的原生 RBAC 机制执行。

apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata:

name: api-fe namespace: frontend-ns

spec:

host: api.example.com tls:

secret: api-ssl-secret routes:

  • - path: /games/api

route: games-ns/games-route

  • - path: /stats/api

route: stats-ns/stats-route

VirtualServer 定义主机的 TLS 设置,并将路由定义委派给引用的VirtualServerRoute 资源


apiVersion: k8s.nginx.org/v1 kind: VirtualServerRoute metadata:

name: games-route namespace: games-ns

spec:

host: api.example.com upstreams:

  • - name: games service: games-svc port: 80

subroutes:

  • - path: /games/api action:

pass: games

VirtualServerRoute 定义路由,但无法覆盖全局主机 TLS 设置

已修改于2023-03-06 02:27
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
335
文章
21
问答
201
粉丝
相关文章
编程是门手艺,NGINX社区的经验分享一文提过,专业的程序员擅长整体设计和细节处理能力。本文探讨整体设计,尤其是模块化这个技能。 全能天才,FabriceBellardFFmpeg,最强大的流媒体库QEMU,硬件虚拟化的虚拟机TCC,迷你CC编译器QuickJS,100%支持JS语法的C引擎等等,以上皆出自一人之手,法国天才。去年QuickJS曾一度刷爆技术圈,NGINX社区的哥们第一时间推荐给我看,并以天才称他。这软件开拓了我的视野。本文以它为引子探讨我认为非常重要的技能:如何组织代码。 NJS,实现语言引擎真难私下问过FabriceBellard(给QJS提过patch)开发QJS的历程,答案令人惊叹,他只用了两年的业余时间。参与NJS这几年,才深知实现语言引擎有多复杂。NJS从17年开始,现在差不多完成40%。但基础已经非常良好,后续功能开发会快速很多。而且常用功能都已经支持,其中我支持了模块化,箭头函数,等常用的。语言解析引入了LL(k)。看似做了些不错的工作。然而跟QJS比,以台球打个比方。一个长距离很准的选手,90%的球都能打进,看似很厉害。但对一个发力非常厉害的
点赞 7
浏览 5.9k
来自16日ASGI应用,使用多线程应用请求处理,并在配置中使用正则表达式!接下来,让我们按惯例回顾下第一个重大升级是异步服务器网关接口WSGI的继任者。但是,与ASGI与协议无关。例如,它支持ASGI,并开始支持NGINXUnit指向JSON相同。对于有两个可调用对象的传统WSGI、protocol选项来暗示预期结果,该方法在应用因使用某些复杂的接下来,我们不会深入探讨 JSON数组,返回响应代码的asyncioPython标准库的一部分,而后者则在前者的基础上提供异步NGINXUnit,看看会发生什么:到目前为止,一切都很顺利。下面是测试运行代码:ASGI规范提供了有关WebSocket-over-ASGI方法。现在,我们使用即使省去所有无关内容,仍说来话长,因此我们就简单介绍下它的功能: JavaScript/HTML代码。 ASGI连接范围:websocket。当您通过 WebSocket连接,并运行各种消息传递事件循环,显示其从服务器接收到的更新。 最后,我们来看一下情况如何:Java、Rub
点赞 0
浏览 3.2k
如果部署和配置得当,Ingress controller 能够从根本上简化 Kubernetes 集群的操作,同时增强安全防护并提高性能和弹性,可成为您软件栈中的强大工具。‌访问 NGINX 中文官方开源社区(nginx.org.cn)了解详情。
点赞 0
浏览 5.4k