Kubernetes - 内部负载平衡安全

Question

我们正在扩展我们的微服务群应用程序，我正在研究Kubernetes以满足我们的需求。在我深入了解现代编排之前，我正在考虑以下列方式进行服务发现：

• 群集是使用某种分布式服务注册表（在我们的案例中为Consul）
引导的
• 每个服务都以某种方式传递的服务注册表端点启动
• 每个服务都在注册表中自行注册
• 每当服务需要其他服务地址时，它都会从注册表
获取联系点

在这种情况下，如果任何服务失败或发生某种网络中断，客户端服务可以继续下一个联系点并最终成功（如果它没有完全切断）。据我所知，kubernetes使用完全不同的模型：

• 所有pod都在kubernetes中自行注册
• Kubernetes提供单一负载均衡器实例以将流量传递到服务
• 可以通过环境变量或DNS查询发现负载均衡器本身（这可能会导致令人毛骨悚然的事情，例如从DNS记录中获取端口或只是陈旧的环境变量）

这让我感到困惑。如果我是正确的（随意告诉我，如果不是这样的话），这基本上会将负载均衡器变成SPOF，可能会在整个应用程序死亡时停止。我对吗？ Kubernetes是否保证这种情况不会发生或将在＆lt; N＆gt;中解决。 ＆lt;时间单位＆gt;？

Answer 1

Kubernetes（kube-proxy）中的群集内负载均衡器分布在所有群集节点中。它将所有服务端点同步到节点上的iptables规则。 Kube-proxy由kubelet进行健康检查，如果它不健康30秒将重新启动（我认为这是可配置的）。实际流量不通过kube-proxy二进制文件，因此如果kube-proxy确实卡住了，最糟糕的事情就是你对服务端点的看法变得陈旧。有关kube-proxy的更多详细信息，请查看此kubernetes网络平台的文档和服务文档的Virtual IPs section，Services FAQs和slides 46-61。

对于服务发现，可以通过kube-dns按名称访问每个服务。 Pod在搜索路径中有kube-dns，因此不需要环境变量魔法。同一套牌的Slides 68-83有完整的DNS-＆gt; Virtual IP-＆gt; Pod流量。

因此，负载均衡器实际上不是SPOF。它应该主要与在同一节点上运行的工作负载共享命运。 Kube-dns可以作为服务发现的SPOF，但无论你喜欢多少，它都可以被复制。