Kubernetes“仅限内部”入口控制器？答案

【问题标题】：Kubernetes "internal only" ingress controller?Kubernetes“仅限内部”入口控制器？
【发布时间】：2020-10-31 01:44:15
【问题描述】：

我对 k8s 还很陌生，我正在尝试组装一个内部 api 基础设施——这意味着它只在 k8s 中可用。例如，我希望能够以入口控制器的方式映射 api 端点。

命名空间“X”中的服务“A”映射到 internal://sales
命名空间“Y”中的服务“B”映射到 internal://sales/reports

有没有办法在不使用入口控制器或使用不暴露在外部的入口控制器的情况下做到这一点？

【问题讨论】：

您想在内部使用入口的根本原因是什么？除了使用入口之外，也许还有其他解决方案？
首先，我想为所有环境使用相同的内部服务/路径名。这将减少每次部署的环境配置并加快（一点）错误分类，因为开发人员可以遍历其应用程序的逻辑层而不管环境如何。从桌面到生产。
此外，我们正在构建一个随着时间的推移会变得相当大的 api 基础设施。我希望开发人员能够离散地构建微服务，然后随着时间的推移将它们“插入”到 api 的 url 结构中。此 api 仅供内部使用，因此不需要暴露于外部世界。
最后，这个 api 基础设施有点像 Tennant 模型。除了我们的管理系统需要平等地访问所有租户。想象一个像 //admin/{::clientId}/users、//admin/{::clientId}/resourceUsage 等这样的 api。 {::clientId} 之后的所有路径都是仅与该客户端相关的微服务 - 作为一个单元构建和部署。这些服务在定制化和资源使用方面可能会有所不同。他们是易变的。一旦 clientId 过期（可以是一个月，也可以是几年），它的服务就会被删除。
好的。明白了。这种具有隔离/定制工作负载的多租户设置很特别。如果你以后想利用 NetworkPolicies 之类的东西，使用 ingress-controller 或 nginx 代理的设置可能会妨碍你。在这里，使用直接访问和利用命名空间可能会有所帮助。每个租户都有一个命名空间和一个客户的大多数服务在内部交谈，您可以使用短 dns 名称。管理员可以向 service14.customer123/resourceUsage 发出调用，而 customer123 的另一个应用程序只是从同一命名空间调用 service14...

标签： kubernetes kubernetes-ingress

【解决方案1】：

与部署到集群的其他工作负载/服务相比，入口控制器并不是真正的特殊工作负载。将外部流量映射到集群是因为入口控制器的Service 使用type: LoadBalancer 暴露在外部（在大多数情况下），这会触发云基础设施提供公共 IP 和映射到集群虚拟机（在服务公开的端口上）。

没有人阻止您不将该服务类型设置为LoadBalancer，从而有效地使您的入口控制器内部化。如果您想使用自定义域名，这将需要一些 DNS CNAME 记录指向您的集群本地入口控制器的服务名称，但这绝对是可能的。

请确保您选择的入口控制器是如何正确部署的。有些人出于性能原因使用DaemonSets 和HostPorts，这意味着您需要特别注意防火墙设置。

尽管如此，您应该考虑是否真的想在这里使用入口控制器，就像在内部运行您的真实服务一样，您已经有了可以使用的稳定 DNS 名称。使用入口控制器会引入额外的数据包跃点，因为请求首先到达入口控制器实例（可能在不同的节点上运行），然后转发到真正的目标工作负载。

如果您有一组固定的工作负载，您还可以使用 nginx 部署来处理 url 和路径的代理/重写。检查the nginx docs 以获得一些示例配置。从网络的角度来看，这与入口控制器设置并没有真正的不同，并且还引入了额外的跃点。

【讨论】：

重申你的意思，我可以使用入口控制器 - 将入口服务（在我的情况下为 nginx）更改为客户端 IP，以防止外部暴露。 - 使用 nginx url/path 重写指向实际安装的服务。这样做的主要缺点是额外的跃点（以及我认为的资源消耗）。我说对了吗？
是的。并且通过引入这样的代理层（入口控制器或 nginx），您将失去使用 NetworkPolicies 的能力，因为您的请求源将始终是代理 pod，而不是真正的源。我建议评估非代理设置并在服务之间使用 DNS 名称。也请参阅我对这个问题的评论......