在专用内部部署网络和kubernetes之间切换的最佳方式

我已经设置了一个本地Kubernetes集群，我想确保我的服务不在Kubernetes中，但存在于单独的类B上，能够使用迁移到Kubernetes的那些服务。对于所有的客户来说，有很多方法可以做到这一点，我正在寻找最简单的方法

Ingress+controller似乎是最受欢迎的一款——它很有趣，因为它有虚拟主机和HAProxy实现。但我感到困惑的是如何设置Kubernetes服务：

我们没有太多的选择-ClusterIP将不足以将其暴露于外部，或NodePort。LoadBalancer似乎是在网络区域之间切换的一种更简单、更省钱的方式——尽管有OnPrem解决方案（metalLB），但它似乎更倾向于云解决方案

但是如果我坚持使用NodePort，那么我进入网络的端口号将是非标准端口号，我更希望它超过标准端口号；特别是，如果在非kube上运行该服务的一定百分比的流量，而在kubernetes上运行其余的流量（出于测试目的，我希望在咬紧牙关并将给定微服务的100%流量移动到kubernetes之前，先监视一段时间的流量）。在这种情况下，在同一个端口上提供这些服务会更好（几乎总是80，因为它们是标准的REST微服务）。更重要的是，如果出于任何原因我必须重新创建服务，我非常确定端口将发生变化，然后所有流量将无法进入Kubernetes集群，这是一个可怕的提议

建议如何处理现有的prem和Kubernetes群集（也在prem上，不同的IP/子网）之间的通信？

---

在不改变网络参数的情况下（各个网络都在B类网络上），并且不被迫使用NodePort，是否仍然可以获得流量

节点端口服务类型在阶段或开发环境中可能很好。但我建议您使用LoadBalancer类型的服务（Nginx ingress controller就是其中之一）。与其他服务类型相比，此服务的优势是

您可以使用标准端口（而不是由kubernetes生成的随机节点端口）

您的服务是负载平衡的。（负载平衡将由入口控制器负责）

固定端口（除非修改ingress对象中的某些内容，否则不会更改）

---

请记住，这是一种内部设置，您仍然推荐LoadBalancer吗？我的理解是，根据入口控制器的不同，负载平衡将在任何情况下发生-例如：HaproxingRessController，他的工作是为HAProxy实例设置配置，然后该实例将直接路由到pods并绕过服务，因此不需要服务的负载平衡器部分，还是我找错了方向了？关于：“LoadBalancer类型的服务（Nginx ingress controller就是其中之一）”，我不想显得有争议，但Nginx IngressController是IngressController的一个示例，我们需要为它创建一个ingress实例。它不是一个服务的例子，简单地说，它是一个端点的抽象，而不仅仅是一个例子——尽管ClusterIP之外的后续服务定义是之前定义的超集。