0

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

Ingress + 控制器似乎是最受青睐的一种 - 由于虚拟主机和 HAProxy 实现，它很有趣。但我感到困惑的是如何设置 Kubernetes 服务：

我们没有太多选择——ClusterIP 不足以将其暴露给外部或 NodePort。LoadBalancer 似乎是在网络区域之间切换的一种更简单、更精简的方式——尽管有 OnPrem 解决方案 (metalLB)，但似乎远远面向云解决方案。

但是如果我坚持使用 NodePort，那么我进入网络的方式将是一个非标准端口号，我希望它超过标准端口；特别是如果在非 kube 上运行该服务的一定比例的流量，其余的在 kubernetes 上运行（出于测试目的，我想在一段时间内监控流量，然后再硬着头皮将 100% 的流量转移到给 Kubernetes 的给定微服务）。在这种情况下，这些服务可以在同一个端口上使用会更好（几乎总是 80，因为它们是标准的 REST 微服务）。不仅如此，如果我出于某种原因必须重新创建服务，我很确定端口会发生变化，然后所有流量都无法进入 Kubernetes 集群，这是一个可怕的提议。

处理现有本地和 Kubernetes 集群（也在本地，不同的 IP/子网）之间的通信的建议方法是什么？无论如何，在不更改网络参数（B 类的相应网络已打开）的情况下获得流量，并且不会被迫使用 NodePort？

4

1 回答 1

0

NodePort 服务类型可能适用于 stage 或 dev 环境。但我建议您使用 LoadBalancer 类型的服务（Nginx 入口控制器就是其中之一）。与其他服务类型相比，它的优势是

  1. 您可以使用标准端口（由您的 kubernetes 生成的随机节点端口）。
  2. 您的服务是负载平衡的。（负载平衡将由入口控制器负责）。
  3. 固定端口（除非您修改入口对象中的某些内容，否则它不会改变）。
于 2019-11-14T06:53:33.790 回答