库伯内特斯-服务网格是必须的吗？

Question

最近，我用Nginx Ingres控制器在k8s集群中构建了几个微服务，它们工作正常。

在处理微服务之间的通信时，我尝试了gRPC并成功了。然后我发现当微服务A-

后来，我对istio产生了兴趣。我已成功将其部署到群集。但是，我观察到它总是创建自己的负载均衡器，这与现有的Nginx入口控制器不匹配。

此外，我尝试了prometheus和grafana以及k9s。这些工具让我对pod的cpu和内存使用有了更好的理解。

在这里，我有几个问题希望了解：

< li >如果我需要监控群集资源，我们有prometheus、grafana和k9s。他们是否扮演与服务网格相同的监控角色(例如，linkerd、istio)？ < li >如果k8s DNS已经可以实现负载均衡，我们还需要服务网格吗？ < li >如果在没有服务网格的情况下使用k8s，是否落后于常规做法？

实际上我也想每天使用Service Mesh。

Answer 1

服务网格不是灵丹妙药，也不适合所有使用情形。服务网格不会为你做所有的事情，它也有缺陷和有限的功能。

1. 您可以在没有Istio的情况下使用Prometheus，并拥有非常不错的应用程序监控。Service Mesh可以为您简化一些监控任务，但这并不意味着您不能自己完成。
2. 请不要将DNS视为负载平衡解决方案。库伯内特斯有服务和入口来进行负载平衡。今天的Nginx入口非常强大，具有许多高级功能。
3. 这在很大程度上取决于您的用例。

Answer 2

简单的答案是：

不需要kubernetes服务器的服务网格

现在回答你的问题

如果我需要监视集群资源，我们有prometheus，grafana和k9s。他们是否执行与服务网格相同的监视角色（例如 linkerd、istio）？

K9s是一个cli工具，只是kubectl cli工具的替代品。它不是监视工具。Prometheus和grafana是监控工具，需要使用应用程序（pod）提供的数据，并构建可以可视化为图表，图形等的时间序列数据。但是，应用程序必须向Prometheus提供监视数据。服务网格可以使用 sidecar，并提供一些对监视有用的默认指标，例如一秒钟内处理的请求数。您的应用程序不需要对指标有任何了解或实现。因此，服务网格是可选的，它卸载了监视或授权等常见内容。

如果k8s DNS已经可以实现负载均衡，我们还需要服务网格吗？

负载均衡不需要服务网格。当您在集群中运行多个服务，并希望对所有服务使用单个入口点以简化维护并节省成本时，将使用入口控制器，例如Nginx，Traefik，HAProxy。此外，像 Istio 这样的服务网格也带有自己的入口控制器。

如果使用k8s而不使用服务网格，它是否落后于正常做法？

不，可能有现在没有服务网格的集群仍然使用库伯内特斯。

未来，Kubernetes可能会从服务网格中带来一些功能。