静态挂载模式 ingressgateway的deployment中默认将名为istio-ingressgateway-certs的secret mount到/etc/istio/ingressgateway-certs下 ，然后在gateway中指明对应的crt及key的文件路径 pod volume来源： [crayon-6475b71f63084692319219/] mount到目录： [crayon-6475b71f6308a654109826/] gateway中指定： [crayon-6475b71f6…
istio 1.6.3 Gateway资源中定义的port和协议定义了在ingressgateway（envoy）中的listener port及协议处理。 但是，Gateway中的port可以填写为 ingressgateway 对应svc中的定义的port或者targetPort，最终在envoy里配置的是targetPort。 例如，Gateway中定义port为443: [crayon-6475b71f63879333321456/] 而实际envoy中产生的配置是8443： [crayon-6475b71…
安装NGINX官方helm repo 安装过程演示
Envoy，使者，使节，代表！就像其单词含义本身一样，带着一种权威感，一种全代理的神圣感。结合其本身用途与角色，真是“人如其名”，不禁为Lyft点赞，不知是得到了哪位大师的指点来起这个名字。在当前火热的微服务时代下，Envoy是个绝对的明星，用众人皆知来形容可以说一点也不为过。曾有人问我如何看Envoy以及在云原生时代下是否Enovy将取代F5取代NGINX，作为一个经历了两次应用交付技术领域更迭浪潮的老兵，在本文中我将来浅谈一下Envoy，以及试图从个人角度来理解与回答一下这个问题。为什么说浅谈一下，这真的不是谦…
Istio注入的iptables Istio通过向业务pod中注入init容器以及envoy proxy容器实现流量的劫持与处理，init 容器运行后将在对应的linux namespace里产生以下iptables的NAT表规则 Outbound 流量控制 当业务容器将请求发往外部的时候比如productpage到reviews:9080端口访问，这个连接会被iptables进行redirect到127.0.0.1:15001端口上，进而被envoy处理 REDIRECT This target is only …
设置如下策略熔断策略 测试结果显示大约38%左右被熔断 envoy上的配置，熔断是在cluster里
超时控制 对应的envoy配置 延迟控制设置策略 对应的envoy配置
在Istio体系下，为了保证策略协调与体验的统一性，用户会考虑使用Istio自身的Ingressgateway作为南北流量的入口， ingressgateway一般是通过deployment方式部署多个pods，分散在集群的多个node上，取决于具体的暴露type，特别是在on-prem部署下，仍然需要在k8s集群外部部署相关负载均衡器来对这些ingressgateway进行负载均衡，一方面可以避免多个入口带来的访问困难与运维难度，另一方面通过高性能高可靠的F5 BIGIP可为k8s集群入口流量提供更多功能控制和安…
下发如下virtualservice策略，header中包含end-user：jason的请求发reviews的v2版本，其它的请求 50%发往v1，50%发往v2
配置以下VirtualService资源定义。如果http header里包含end-user且其值为jason则路由到v2版本reviews，否则访问v1版本reviews 施加virtualservice定义之后的envoy route配置
对bookinfo所有服务施加版本1的VirtualService之前,cluster里无版本号 施加版本v1的VirtualService后, 可以看到cluster中指定了版本号
listener，VSIP:port定义，关联相关route "routeConfigName": "9411"。 并施加相关协议等filter（类似F5 vs profile等）： Routes通过端口归类不同的route： Zipkin Routes，domain匹配策略，充实策略，path匹配策略，L7路由策略。 所有path路由到 "cluster": "outbound|9411||zipkin.istio-system.svc.cluster.local" ： 指向的cluster，并采用eds发现cl…
包含了k8s集群中的所有svc在这里的自动配置
配置简单的bookinfo productpage gateway和virtualservices之后的配置输出 (包含了所有其它namespace里的svc)
前面两篇（1 ，2），我们讲述了NGINX在authorization code模式下的能力，可以简单总结为NGINX既可以作为第三方应用（client）的验证代理，也可以作为Resource server角色对token进行验证或使用。在implicit模式下，NGINX能做什么呢？首先来看implicit模式的工作机制（最近太惨了，前两篇文章的画图ppt给不小心删除了，还清空了垃圾箱。。一般不没什么习惯清空垃圾箱的。。。就不重新画了，google一张图吧。。。） 在这个图里，把user想象你为，把client想…
最近评论
纳米 发布于 7 个月前（10月31日）
纳米 发布于 7 个月前（10月31日）
TomCruz 发布于 8 个月前（10月11日）
lili 发布于 8 个月前（09月26日）
lili 发布于 8 个月前（09月26日）
