我是微服务的新手，并且想了解在Kubernetes上部署的微服务中实现以下行为的最佳方法是什么：
有2个不同的K8s集群。微服务B部署在两个集群上。
现在，如果微服务A呼叫微服务B，并且集群1中B的Pod不可用，则该呼叫应转到集群2的B。
我原本可以想象通过使用Netflix OSS来实现此功能，但是在这里我没有使用它。
此外，将集群间通信搁置一秒钟，我应该如何在微服务之间进行通信？
我知道的一种方法是为每个微服务创建NodePort类型的Kubernetes服务，并在调用微服务中使用IP和nodePort。
问题：如果有人删除目标微服务的K8s服务怎么办？在重新创建K8s服务时，新的nodePort将由K8s随机分配，然后我将再次回到调用微服务并更改目标微服务的nodePort。如何与nodePort分离？
我对kubedns进行了研究，但似乎只在集群中有效。
我对Istio和Kubernetes Ingress的了解非常有限。这些中的任何一个是否提供我想要的东西？
很长的问题很抱歉。任何形式的指导都将非常有帮助。
答案 0 :(得分：4)
您可以使用服务来公开应用程序，可以使用某些服务：
ClusterIP：在群集内部IP上公开服务。选择此值将使服务仅可从群集内访问。这是默认的ServiceType。
NodePort：通过静态端口（NodePort）在每个节点的IP上公开服务。ClusterIP服务路由到的NodePort服务是自动创建的。您可以通过请求NodePort从群集外部与<NodeIP>:<NodePort>服务联系。
LoadBalancer：使用云提供商的负载平衡器在外部公开服务。自动创建外部负载均衡器路由到的NodePort和ClusterIP服务。ExternalName：通过返回externalName记录，将服务映射到foo.bar.example.com字段的内容（例如CNAME）
对于内部通信，您使用使用服务类型ClusterIP，并且可以为应用程序配置服务dns而不是IP。
即：可以使用dns my-app-1或fqdn http://my-app-1内部访问名为http://my-app-1.<namespace>.svc.cluster.local的服务。
对于外部交流，您可以使用NodePort或LoadBalancer。
NodePort非常有用，因为您只有很少的节点并且知道所有节点的ip。是的，通过service docs，您可以指定一个特定的端口号：
如果需要特定的端口号，可以在
nodePort字段中指定一个值。控制平面将为您分配该端口或报告API事务失败。这意味着您需要自己注意可能发生的端口冲突。您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。
LoadBalancer为您提供了更大的灵活性，因为您无需了解所有节点ip，只需知道服务IP和端口即可。但是LoadBalancer仅在云提供商中受支持，如果您想在裸机集群中实现，我建议您在MetalLB中看看。
最后，还有一个使用ingress的选项，在我看来，这是在外部公开HTTP应用程序的最佳方法，因为您可以按路径和主机创建规则，并且为您提供了更大的灵活性比服务。但是仅支持HTTP / HTTPS，如果您需要TCP，请转到服务
我建议您查看以下链接，以深入了解服务和入口的工作原理：
答案 1 :(得分：1)
将入口用于集群间通信，将集群ip类型服务用于两个微服务之间的集群内通信。
答案 2 :(得分：0)
您的设计非常接近 Istio Multicluster 示例。
按照Istio multicluster lab中的步骤进行操作，您将获得两个具有一个Istio控制平面的集群，它们平衡位于两个独立Kubernetes集群中的两个ClusterIP服务之间的流量。
实验室的configuration监视流量负载，但是如果Cluster One的服务没有端点（某种类型的所有Pod都没有），则可以重写Controller Pod代码，将其配置为将流量切换到Second Cluster。处于就绪状态）。
这只是一个示例，您可以更改istiowatcher.go code以实现所需的任何逻辑。
more advanced solution使用 Admiral 作为Istio Multicluster管理自动化工具。
Admiral基于一个独特的服务标识符为跨多个群集的Istio网格提供自动配置，使其作为单个网格工作，该标识符将多个群集上运行的工作负载与服务相关联。它还提供跨群集的Istio配置的自动配置和同步。这样就减轻了开发人员和网格运算符的负担，有助于扩展到几个集群之外。
此解决方案解决了现代Kubernetes基础架构的以下关键要求：
此解决方案可能会在全面方面变得非常有用。