作者回复: 抱歉带给您不好的学习体验，前面都是比较基础的篇理论讲述，从11课开始会对这一课综述的具体的功能逐一进行实践，同时也会围绕相关概念举例说明。 感谢你的意见，后续的课程我会更加努力。

作者回复: 不一样的东西。k8s的svc是真实服务的抽象，是外界访问真实服务的入口； 虚拟服务本质上是路由规则，就是外界访问服务时虚拟服务会做进一步的路由。 比如原来的访问类似 client -> service -> pods；加了虚拟服务类似于 client -> service -> virtualservice -> subset pods（满足路由规则的pod子集)

作者回复: 落地实践不多，除了大厂自研以外，基本上都是基于以前的版本，集中在1.1 -1.4 之间。

作者回复: 可以通过镜像，也可以用采用率记，把部分请求路由到负责记录的实例。

作者回复: 绝大部分流控能力都是靠envoy实现的，Istio只是整合了envoy，添加了控制面而已

作者回复: 由k8s负责调用到node上。安装选项中有一个参数global.defaultNodeSelector，可以选择特定节点："Default node selector to be applied to all deployments so that all pods can be constrained to run a particular nodes. Each component can overwrite these default values by adding its node selector block in the relevant section below and setting the desired values." ingress就在istio-system 命名空间中。至于流量大小我觉得不是决定使用外部还是默认网关的考虑点，如果你指的是性能，ingress本身也需要附着一个Envoy进行路由，Envoy的性能是没有问题的。

作者回复: 你说的是这个例子吗？https://istio.io/latest/docs/tasks/policy-enforcement/rate-limit/#global-rate-limit “怎么配置自定义的返回body，和剩余请求量怎么放在response header.里面”——这句话我没看懂，回答你第二个问题，global ratelimit是服务级别的，local的是pod级别的，也就是说，所有访问productpage这个服务的流量，受到global的控制；而流量到了productpage的某个pod（其实就是endpoint）后，受local的控制。