记一次意想不到的Istio调用配置
想要使用Istio的前提,就是在服务的namespace上开启sidecar自动注入kubectl label namespace xxx istio-injection=enabled --overwrite之后我们再在K8s集群中部署服务时,就会发现Deployment下的pod内会多了一个sidecar(istio-proxy)和一个初始化容器istio-init,但是最近...
想要使用Istio的前提,就是在服务的namespace上开启sidecar自动注入
kubectl label namespace xxx istio-injection=enabled --overwrite
之后我们再在K8s集群中部署服务时,就会发现Deployment下的pod内会多了一个sidecar(istio-proxy)和一个初始化容器istio-init,
但是最近运维新建了个K8s的namespace,并且该namespace没有开启Istio sidecar的自动注入,就是说在此namespace下的应用pod内并没有Istio的sidecar(istio-proxy)容器,奇怪的是,运维为此namespace下的服务配置了Isito的路由配置(Gateway,VirtualService,DestinationRule),但是竟然神奇的生效了,我就懵圈了;
后来理清思路发现,该namespace的服务调用链路如下:
(1)浏览器->web前端
(2)浏览器->应用网关
(3)应用网关->具体应用
首先浏览器->web前端、应用网关,都是从集群外部进入istio-ingressgateway,然后从istio-ingressgateway再进入到具体应用(web前端、应用网关),该段调用之所以好用,可以简单理解为istio-ingressgateway本身就是一个sidecar,它会动态加载Istio的所有路由信息,即使具体应用的pod中没有sidecar,但是istio-ingressgateway本身作为一个sidecar且拥有所有Isito集群路由信息,即通过istio-ingressgateway也能找到具体应用;
再者应用网关->具体应用,都是通过K8s服务的serviceName.namespace进行相互调用,并没有Isito的特殊路由配置(例如match、rewrite等),所以即便应用网关、具体应用都没有Istio sidecar,但是2者间仍可通过K8s服务进行调用;
更多推荐
所有评论(0)