包含了k8s集群中的所有svc在这里的自动配置
包含了k8s集群中的所有svc在这里的自动配置
配置简单的bookinfo productpage gateway和virtualservices之后的配置输出 (包含了所有其它namespace里的svc)
由于之前的服务商合约即将到期,续费价格对老用户太不友好,于是从某云换到了某云。 得益于之前的容器化,因此整体迁移比较顺利。重新制作了支持php7.4的镜像,并将TLS ciphers做了些调整。
前面两篇(1 ,2),我们讲述了NGINX在authorization code模式下的能力,可以简单总结为NGINX既可以作为第三方应用(client)的验证代理,也可以作为Resource server角色对token进行验证或使用。在implicit模式下,NGINX能做什么呢?首先来看implicit模式的工作机制(最近太惨了,前两篇文章的画图ppt给不小心删除了,还清空了垃圾箱。。一般不没什么习惯清空垃圾箱的。。。就不重新画了,google一张图吧。。。) 在这个图里,把user想象你为,把client想…
在上篇中,通过将NGINX作为oAuth认证授权过程中的Client角色的代理,帮助应用直接实现oAuth认证登录。在这样一个过程中,我们采取的是authorization code的oAuth流程,取的是access_token,没有采用OIDC申请格式,并需要借助一个外部oauth proxy服务,那么是否可以完全依赖NGINX实现呢? 正如前篇文章所分析,在authorization code模式中需要 client 这个角色(就是代表第三方应用的,这里实际可以理解为NGINX)需要能够做以下几个事情: 收到…
如今的互联网已经渗透了各种各样的生活与业务场景,就像人们在现实生活中从来不是一个简单的个体,我们需要有很多的复杂的关系网络。互联网的应用也是如此,如今很难看到有哪一个应用能做到完全的独立发展而不与其周边发生关系。所以在今天应用都非常讲究自己的生态,合纵连横,彼此之间需要大量的信息共享。这些复杂的关系就带来了一个非常重要的问题:身份认证、资源授权、账号维护。当然还有API的认证访问控制。 举个栗子,在你的日常生活中,你可能需要使用数十个APP, 这些APP各自拥有独立的账号密码,你就需要维护不同的这些账号与密码,你可…
2020. 5. 20 NGINX创始人Igor与您线上面对面,更有国内NGINX大咖陶辉与NGINX创始人高峰对话。 希望了解NGINX背后的故事?希望了解NGINX在云原生时代的发展趋势? 即刻注册扫码开始奔涌~~~~~~~免费注册,免费参与。 注册时候请您在邀请人处填写 cnadn。 感谢。使用cnadn作为推荐人注册的,可以免费获得本站内容下载码!注册并联系我即可(告诉我你的注册名即可)。
安装示例: v3.3版本, Centos 7.7 系统 准备工作: 系统准备,参考此文进行准备工作,包含: 替换yum repo为阿里镜像 关firewlld,selinux,swapoff 调整系统参数 安装docker v18.09.9 daemon.json可不配置,安装脚本会自动检查 系统资源,建议8C8G, 测试安装机器是4C8G,一般来说内存要给足以避免安装失败 建议将安装主机的hostname通过正式的DNS服务来解析(即安装机器的DNS要能解析),不要使用hosts等文件来解析因为服务起来后都是容器…
实际上博客的真实的年龄要大于14年,最早的博客是在我自己开发的一个多用户博客系统上写的,当时主要是为了开发那个系统,所谓多用户,现在想想应该也就三个人?我自己,碧落,还一个叫忽忽的MM(现在估计不能叫MM了)。 我不知道为什么后来就没有继续那个博客系统,可能连我自己都用不下去了吧。总之,博客内容并没有迁移过来。 14年前的博客并不是现在的wordpress,我印象中,博客经历过三次系统上的转换,最终才转到现在的wordpress。中间也曾一度想弄成静态的Hugo那样,但最终还是觉得不合适,毕竟我写其文章来比较随意。…
在上一篇文章,利用NGINX的keyval,变量map,通过API接口实现了基于服务级别维度和域名维度进行了限流的动态控制。但是在很多情况下Ingress Controller都是多实例部署,那么限流就需要以集群整体来考量而不应该以单个实例来控制,特别是在IC数量动态性的情况下以单实例来控制会导致限流的不稳定。同时,引入IC集群级别不应该带来额外的复杂性,例如应该一个API call即可实现集群的整个体性动作而无需每个IC实例去控制。 需求分析 所有IC应能够形成一个集群并共享相关限流状态 限流执行动作仅需一个AP…
在k8s中,我们经常透过Ingress resource来对外暴露服务,在实际生产中,我们可能还会需要对这些暴露的服务实现限流,这个能力一方面可以通过k8s内部的微网关来实现(比如将NGINX部署微k8s内的微网关),也可能会通过sidecar的方式实现对每个pod单元的限流(如将NGINX作为sidecar部署到业务pod内,并通过NGINX集群同步的方式实现整体限流)。 但如果我们是一个比较典型的南北流量,且内部并没有部署微网关或者sidecar,那么可以由应用自身来解决这个问题,尽管应用自己可以解决该问题,但…
场景 LTM给NGINX做LB是一种较为典型的双层负载均衡,也就是典型的L4.L7分离的双层负载均衡方案。 在这样的架构下,如果多个NGINX背后所负载的server是一致的话,并不会出现不同的NGINX所面对的server可用数量不同情况。 但是,如果LTM的pool member中的NGINX是位于不同的可用区或者不同的DC,此时LTM如仅做应用层负载均衡或仅monitor nginx本身,那么LTM是无法感知到 NGINX 背后(upstream)到底有多少可用的业务服务器。如果某个 NGINX 的upstr…
[crayon-6759aa4f11b70597775059/]
COPYRIGHT © 2023 Cloud Native 应用交付. ALL RIGHTS RESERVED.
Theme Kratos Made By Seaton Jiang