4

最近我用 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 和内存使用情况。

在这里，我有几个问题想了解：-

  1. 如果我需要监控集群资源，我们有prometheus、grafana和k9s。它们是否与服务网格（例如 linkerd、istio）具有相同的监控作用？
  2. 如果 k8s DNS 已经可以实现负载均衡，那我们还需要 Service Mesh 吗？
  3. 如果使用没有服务网格的 k8s，是否落后于正常做法？

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

4

2 回答 2

4

简单的答案是

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

现在回答你的问题

如果我需要监控集群资源，我们有prometheus、grafana和k9s。它们是否与服务网格（例如 linkerd、istio）具有相同的监控作用？

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

如果 k8s DNS 已经可以实现负载均衡，那我们还需要 Service Mesh 吗？

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

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

不，现在可能有没有服务网格的集群仍然使用 Kubernetes。

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

于 2021-01-27T06:06:55.593 回答
0

服务网格不是灵丹妙药，它并不适合每个用例。服务网格不会为您做所有事情，它也有错误和有限的功能。

  1. 你可以在没有 Istio 的情况下使用 Prometheus，并拥有一个非常好的应用程序监控。Service Mesh 可以为你简化一些监控任务，但这并不意味着你不能自己做。
  2. 请不要将 DNS 视为负载平衡解决方案。Kubernetes 有服务和入口来做负载平衡。今天的 Nginx Ingress 非常强大，并具有许多高级功能。
  3. 这在很大程度上取决于您的用例。
于 2021-01-27T07:12:23.337 回答