作者回复: 👍

作者回复: 首先确认一下非mesh的服务是否需要纳入到mesh内进行流控？如果不需要，就不用非得用ServiceEntry。 mesh服务和非mesh服务建议分namespace，方便管理，逐步迁移。

作者回复: 简单来说： 1. 如果resolution配的是DNS，没有配置endpoint，它会配合hosts字段进行解析； 2. 如果设置了endpoint为具体IP，resolution就要设置为STATIC，表示直接使用IP，不用解析； 3. 如果resolution配的是DNS，也配置了endpoint，会解析endpoint里设置的地址； 4. address这个字段是关联服务的VIP地址，对HTTP是不生效的。 可以再仔细琢磨下这个示例： apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: external-svc-mongocluster spec: hosts: - mymongodb.somedomain # not used addresses: - 192.192.192.192/24 # VIPs ports: - number: 27018 name: mongodb protocol: MONGO location: MESH_INTERNAL resolution: STATIC endpoints: - address: 2.2.2.2 - address: 3.3.3.3

作者回复: 这个不应该啊，istioctl profile diff default demo 看看是不是profile有什么问题。不行再重新安装一下

作者回复: 你说的都对，主要是看你需不需要把外部流量纳入到mesh统一管理，如果不需要，你的解决方案都ok。

作者回复: kubectl get configmap istio -n istio-system -o yaml | sed 's/mode: ALLOW_ANY/mode: ALLOW_ANYREGISTRY_ONLY/g' | kubectl replace -n istio-system -f - 先看看configmap生效没； 另外你是怎么访问的？访问外网的服务是否注入了sidecar？

作者回复: 咱们先确定一个问题：存量系统的部署环境是什么？是云上？实体机？K8s？如果不是基于k8s的，istio是没法管理的，不过可以选择托管的mesh服务，比如aws appmesh。 假设第一个问题满足要求（k8s），那么第二点：“管理底层通讯和流量” ，我理解没错的话，是有其他系统（或服务）通过ServiceEntry访问存量系统？如果是这样的话，这个访问存量系统的，是下游系统（服务），需要接入istio，存量系统不需要任何侵入。当然前提是它能提供可支持的协议（http/grpc等）