服务发现
本节介绍 kuma 如何处理 service mesh 中的服务发现问题，包括数据平面代理和控制平面之间的通信，控制平面代理间的通信。
数据平面代理和控制平面之间的通信
当数据平面代理连接到控制平面时，它会启动到控制平面的 gRPC 流连接（xDS）。它从控制平面检索最新的策略配置并向控制平面发送诊断信息。
- 在独立部署下，kuma-dp 直接连接到 kuma-cp 实例。
- 在多区域部署下，kuma-dp 连接到 zone kuma-cp，zone kuma-cp 将通过 KDS 的 xDS API 扩展连接到 global kuma-cp。在多区域模式下，数据平面代理永远不会连接到全局控制平面，而仅连接到区域控制平面。
数据平面和控制平面之间的连接不在服务请求的执行路径上，这意味着如果数据平面暂时失去与控制平面的连接，服务流量不会受到影响。
数据平面代理间的通信
数据平面会通报每一个服务的 IP 地址：
- 在 Kubernetes 环境中，IP 地址为 Pod 的地址。
- 在 Universal 环境中，IP地址会检索 inbound listeners（用于配置控制平面代理的入站监听地址）。
数据平面会通报 IP 地址到控制平面，这意味着在任何时间 kuma-cp 都知道每一个服务的每个副本关联的所有 IP 地址是什么。
Kuma 数据平面代理间的通信，在独立部署和多区域部署使用自己的 DNS：
- 在独立部署模式下，直接使用 IP 地址进行通信。
- 在多区域部署模式下，Kuma 将自动解析域名，可以连接到在同一区域中运行的数据平面代理，或者通过 Egress（如果存在）和 另一个区域中的 Ingress 的地址 来实现跨区域连接。这意味着多区域部署模式下，服务之间可以跨集群（不管是 Kubernetes 还是 VM）连接。
DNS
对于每一份服务，都会生成一个以 .mesh 结尾的域名：
对于一个 Kubernetes Service 和关联的 Pod，Kuma 控制面会自动的生成一个注解
kuma.io/service: <name>_<namespace>_svc_<port>，其中 name 和 namespace 还有 port 均来自 Service 信息。某些情况下 Pods 不属于任何的 Service，仅仅是单纯的一个 Pod（或者在 Universal 下）。在这种情况下，Kuma 会自动生成的注解为
kuma.io/service: <name>_<namespace>_svc，其中 name 和 namespace 来自于 Pod 资源。
服务的域名被定义为 <kuma.io/service的值>.mesh，默认端口为 80。
非 mesh 流量
传入流量
启用 mTLS 后，来自网格外部的客户端无法访问网格内部的应用程序。如果想允许外部客户端使用服务网格，可以使用 Permissive mTLS 模式（宽松的 mTLS，即允许 mTLS，也允许明文请求）。
所有域名查找均由数据平面代理在本地处理，而不是由控制平面处理。这种方法允许更稳健地处理名称解析，例如，当控制平面关闭时，数据平面代理仍然可以解析 DNS。
数据平面代理 DNS 包括：
- Envoy DNS 过滤器提供来自网格的 DNS 记录响应。
- CoreDNS 用于 Envoy DNS 过滤器和原始主机 DNS 之间发送请求
- iptable 规则将原始 DNS 流量重定向到本地 CoreDNS 实例。
穿出流量
在默认设置中，Kuma 允许任何非网状流量通过 Envoy，而无需应用任何策略。当 networking.outbound.passthrough 为 false 时，任何非网格资源的流量都不能离开网格。
使用 ProxyTemplate，可以设置非 mesh 流量的配置。如断路器，超时。