Kubernetes - 服务网格是必须的吗？

Question

最近我在一个带有 Nginx 入口 Controller 的 k8s 集群中构建了几个微服务，它们工作正常。
在处理微服务之间的通信时，我尝试了 gRPC 并且它奏效了。然后我发现当微服务 A -> gRPC -> 微服务 B 时，所有请求都只发生在微服务 B 的 1 个 Pod 上(例如，微服务 B 总共有 10 个可用的 Pod)。为了对微服务 B 的所有 pod 的请求进行负载平衡，我尝试了 linkerd 并且它起作用了。但是，我意识到 gRPC 有时会产生内部错误(例如 100 个请求中有 1 个错误)，这让我改用 k8s DNS 方式(例如 my-svc.my-namespace.svc.cluster-domain.example)。然后，请求永远不会失败。我开始支持 gRPC 和 linkerd。
后来对istio产生了兴趣。我成功地将它部署到集群中。但是，我观察到它总是创建自己的负载均衡器，这与现有的 Nginx 入口 Controller 不太匹配。
此外，我尝试了 prometheus 和 grafana，以及 k9s。这些工具让我更好地了解 pod 的 CPU 和内存使用情况。
在这里，我有几个我想了解的问题:-

如果我需要监控集群资源，我们有 prometheus、grafana 和 k9s。它们是否扮演与服务网格相同的监控角色(例如 linkerd、istio)？

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

如果在没有服务网格的情况下使用 k8s，是否落后于正常做法？

其实我也想每天使用服务网格。

Answer 1

简单的答案是

Service mesh for a kubernetes server is not necessary

现在回答你的问题

If I need to monitor cluster resources, we have prometheus, grafana and k9s. Are they doing the same monitoring role as service mesh (e.g. linkerd, istio)?

K9s 是一个 cli 工具，它只是 kubectl 的替代品cli工具。它不是监控工具。 Prometheus 和 grafana 是监控工具，它们需要使用应用程序(pod)提供的数据并构建可以可视化为图表、图形等的时间序列数据。但是应用程序必须将监控数据提供给 Prometheus。服务网格可以使用 sidecar 并提供一些对监控有用的默认指标，例如 number of requests handled in a second .您的应用程序不需要了解或实现指标。因此服务网格是可选的，它卸载了诸如监控或授权之类的常见事情。

if k8s DNS can already achieve load balancing, do we still need service mesh?

负载平衡不需要服务网格。当您在集群中运行多个服务并希望对所有服务使用单个入口点以简化维护并节省成本时，可以使用 Nginx、Traefik、HAProxy 等 Ingress Controller 。此外，诸如 Istio 之类的服务网格带有自己的入口 Controller 。

if using k8s without service mesh, is it lag behind the normal practice?

不，今天可能有些集群没有服务网格，但仍在使用 Kubernetes。
future ，Kubernetes 可能会从服务网格中带来一些功能。