Kubernetes - 内部负载平衡安全

Question

我们正在扩大我们的微服务群应用程序，我正在考虑Kubernetes满足我们的需求。我潜入现代配器之前，我想通过以下方式服务发现：

• 集群的自举了某种分布式服务注册（在我们的例子领事）的
• 每个服务与服务注册表启动端点莫名其妙
• 通过每个服务自行注册本身在注册表
• 每当服务需要一些其他服务的地址，它将从注册表中的接触点

在这种情况下，如果有任何服务失败或某种网络中断发生，客户端服务可能会继续执行下一个联系点并最终成功（如果它未完全中断）。至于我已经明白，kubernetes使用完全不同的模式：

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

而这让我感到困惑。如果我是正确的（随时告诉我我不是，如果是这种情况），这基本上将负载平衡器转换为SPOF，可能会停止整个应用程序在它死亡的那一刻。我对吗？ Kubernetes有任何保证，这种情况不会发生或将在<N> <时间单位>解决？

Answer 1

Kubernetes（kube-proxy）中的群集内负载均衡器分布在您的所有群集节点中。它将所有服务端点同步到节点上的iptables规则。 Kube-proxy通过kubelet进行健康检查，如果30秒内健康状况不佳（可以配置，我认为），它将重新启动。实际流量不会通过kube-proxy二进制文件，因此如果kube-proxy确实卡住了，最糟糕的情况是您的服务端点视图变得过时。请参阅文档以及该kubernetes网络套件的服务文档Services FAQs和slides 46-61的Virtual IPs section以获取有关kube-proxy的更多详细信息。

对于服务发现，每个服务都可以通过kube-dns的名称访问。豆荚的搜索路径中有kube-dns，所以不需要环境变量魔术。同一套牌的Slides 68-83有DNS-> Virtual IP-> Pod流量的完整漫游。

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