您可以使用服务公开您的应用程序，您可以使用一些类型的服务：

• ClusterIP：在集群内部IP上公开服务。选择此值将使服务只能从集群内部访问。这是默认的ServiceType。
• NodePort：在每个节点的IP上的静态端口（NodePort）上公开服务。NodePort服务路由到的ClusterIP服务将自动创建。您将能够通过请求<NodeIP>:<NodePort>从群集外部联系NodePort服务。
• LoadBalancer：使用云提供商的负载均衡器将服务公开到外部。外部负载均衡器路由到的NodePort和ClusterIP服务将自动创建。
• ExternalName：通过返回CNAME记录，将服务Map到externalName字段的内容（例如foo.bar.example.com）
  内部通信可以使用服务类型ClusterIP，您可以为您的应用配置服务dns而不是IP，即：称为X1 M16 N1 X的服务可以使用DNSX 1 M17 N1 X或使用FQDN X1 M18 N1 X在内部到达。
  对外通讯可以使用NodePort或LoadBalancer。

NodePort在你有几个节点并且知道所有节点的ip时是很好的。是的，通过服务文档，你可以指定一个特定的端口号：
如果你想要一个特定的端口号，你可以在nodePort字段中指定一个值。控制平面将为你分配该端口或报告API事务失败。这意味着你需要自己处理可能的端口冲突。你还必须使用一个有效的端口号，一个在为NodePort使用配置的范围内的端口号。
LoadBalancer给予了你更多的灵活性，因为你不需要知道所有的节点ip，你只需要知道服务的IP和端口。但是LoadBalancer只在云提供商中支持，如果你想在裸机集群中实现，我建议你看看MetalLB。
最后，还有一个选择是使用ingress，在我看来是对外公开HTTP应用程序的最佳方式，因为你可以通过路径和主机创建规则，它给你比服务更大的灵活性。但是只支持HTTP/HTTPS，如果你需要TCP，请转到服务。
我建议你看看这些链接，深入了解服务和入口是如何工作的：
Kubernetes Services
Kubernetes Ingress
NGINX Ingress

您的设计非常接近Istio Multicluster示例。
按照Istio多群集实验中的步骤操作，您将获得两个群集，每个群集使用一个Istio控制平面，可平衡位于两个独立Kubernetes群集中的两个ClusterIP服务之间的流量。
实验室的配置监视流量负载，但重写控制器Pod代码，您可以将其配置为如果Cluster One的服务没有端点（特定类型的所有Pod未处于就绪状态），则将流量切换到第二个群集。
这只是一个例子，你可以改变istiowatcher.go代码来实现任何你想要的逻辑。
有more advanced solution使用Admiral作为Istio多集群管理自动化工具。
Admiral为跨多个集群的Istio网格提供自动配置，使其基于唯一的服务标识符作为单个网格工作，该服务标识符将多个集群上运行的工作负载关联到服务。它还提供跨集群的Istio配置的自动配置和同步。这消除了开发人员和网格操作员的负担，有助于扩展到几个集群之外。
该解决方案解决了现代Kubernetes基础设施的这些关键要求：

• 创建与命名空间解耦的服务DNS条目，如多网格部署的功能中所述。
• 跨多个群集的服务发现。
• 支持主动-主动和HA/DR部署。我们还必须支持这些关键的弹性模式，将服务部署在跨离散集群的全局唯一命名空间中。

该解决方案在全尺寸中可能变得非常有用。

使用ingress进行群集间通信，使用群集ip类型服务进行两个微服务之间的群集内通信。