问题描述
最近我在一个带有 Nginx 入口控制器的 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 入口控制器不太匹配。
此外，我尝试了 prometheus 和 grafana，以及 k9s。这些工具让我更好地了解 Pod 的 cpu 和内存使用情况。
这里有几个我想了解的问题：-
- 如果我需要监控集群资源，我们有 prometheus、grafana 和 k9s。它们是否扮演与服务网格相同的监控角色（例如 linkerd、istio）？
- 如果 k8s DNS 已经可以实现负载均衡，我们还需要服务网格吗？
- 如果在没有服务网格的情况下使用 k8s，是否会落后于常规做法？
其实我也想每天使用服务网格。
解决方法
简单的答案是
不需要 Kubernetes 服务器的服务网格
现在回答您的问题
如果我需要监控集群资源，我们有prometheus、grafana和k9s。它们是否扮演与服务网格相同的监控角色（例如 linkerd、istio）？
K9s 是一个 cli 工具，它只是 kubectl cli 工具的替代品。它不是监控工具。 Prometheus 和 grafana 是监控工具，它们需要使用应用程序（pod）提供的数据并构建可以可视化为图表、图形等的时间序列数据。但是应用程序必须将监控数据提供给 Prometheus。服务网格可以使用 sidecar 并提供一些对监控有用的默认指标，例如 number of requests handled in a second。您的应用程序不需要了解或实施指标。因此，服务网格是可选的，它卸载了诸如监控或授权之类的常见事情。
如果 k8s DNS 已经可以实现负载均衡，我们还需要服务网格吗？
负载平衡不需要服务网格。当您在集群中运行多个服务并希望对所有服务使用单个入口点以简化维护并节省成本时，可以使用 Nginx、Traefik、HAProxy 等 Ingress 控制器。此外，诸如 Istio 之类的服务网格带有自己的入口控制器。
如果在没有服务网格的情况下使用 k8s，是否落后于正常做法？
不，现在可能有些集群没有服务网格，但仍在使用 Kubernetes。
未来，Kubernetes 可能会从服务网格中带来一些功能。
,服务网格不是灵丹妙药，它并不适合所有用例。服务网格不会为你做所有的事情，它也有错误和有限的功能。
- 您可以在没有 Istio 的情况下使用 Prometheus 并拥有非常好的应用程序监控。 Service Mesh 可以为你简化一些监控任务，但这并不意味着你不能自己做。
- 请不要将 DNS 视为负载平衡解决方案。 Kubernetes 有服务和入口来做负载平衡。今天的 Nginx Ingress 非常强大，并且拥有许多高级功能。
- 这在很大程度上取决于您的用例。