作者回复: 可能我没说清楚。DR是定义子集的,VS是定义路由的,如果在VS里定义的路由要把请求指向不同的子集,就需要和DR关联起来,那么关联的点就是: VS里的route.destination.host -> DR的host。具体仔细看看文档的说明。 https://istio.io/latest/docs/reference/config/networking/virtual-service/#Destination 另外,如果要给一个Gateway关联一个VS,那它们的关联点就是: gateway.servers.hosts -> VS.spec.hosts (可以一个和多个)。真实的生产环境一般这样配,gw里的hosts是多个(如多个二级域名对应不同的子系统),而每一个域名对应一个VS(根据path把请求打到不同的api)。
作者回复: 可以,但是你就丧失了对pod的流控能力了。istio流控的核心依赖就是service
作者回复: 默认应该是LoadBalancer类型,NodePort是你自己改的?另外这个ip 1.65.15.140是哪里来的我没看到。 2 个方法,进入kiali去验证下配置有什么问题; 进入对应pod的envoy(istio-proxy)查看一下浏览器的请求log是什么
作者回复: VS、DR里不需要设置selector,我理解你说的应该是gateway这个crd里的selector,它对应的是一个叫ingressgateway,本质上是一个LoadBalancer类型的service。
作者回复: 针对整个网格,如果你的集群都由网格覆盖,那2者一致。 你可以简单的把它理解为和K8s 的Ingress没什么区别
作者回复: 1. 不敢下绝对的结论。但多个实践表明并没有性能问题 2. 是的
作者回复: kubectl get gw,vs -o yaml 查看一下gateway和virtualservice的配置,贴出来看看,感觉没配置好。
作者回复: 是的,你可以通过 k get svc -n istio-system 查看到这个ingressgateway就是一个LoadBalancer类型的service,只不过k8s里你是用ingress-nginx,它这个用的是envoy。
作者回复: Kong做ingress gateway管理入流量,istio管理mesh内部流量,我觉得是比较合理的方案。目前没看到业界有相关的实践,你可以参考下着两篇文章: https://konghq.com/blog/kong-ingress-controller-0-6-released-istio-support-admission-controller-support/ https://kubernetes.io/blog/2020/03/18/kong-ingress-controller-and-istio-service-mesh/
作者回复: “显示给用户看的网页内容” - 我理解你说的是前端的页面吧?这要看你这个页面所获取的数据来自于哪个服务,那么通常它就应该属于这个服务。