Kubernetes-服务网状结构是必须的吗？ [英] Kubernetes - is Service Mesh a must?

问题描述

最近我用Nginx入口控制器在K8S集群内搭建了几个微服务，运行正常。

在处理微服务之间的通信时，我尝试了GRPC，它起作用了。然后我发现，当微服务A->GRPC->微服务B时，所有请求只发生在微服务B的1个Pod上(例如，总共有10个Pod可用于微服务B)。为了将请求负载均衡到微服务B的所有Pod，我尝试了linkerd，它起作用了。然而，我意识到GRPC有时会产生内部错误(例如，100%的请求中有1个错误)，这使得我改用K8SDNS方式(例如my-svc.my-namespace.svc.cluster-domain.example).这样，请求就永远不会失败。我开始拿起GRPC和Linkerd。

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

此外，我尝试了普罗米修斯(Prometheus)和格拉法纳(Grafana)，以及K9。这些工具让我更好地了解Pod的CPU和内存使用情况。

这里有几个我希望了解的问题：-

1. 如果我需要监控集群资源，我们有普罗米修斯、Grafana和K9。他们是否扮演与服务网状网相同的监控角色(例如linkerd、istio)？
2. 如果K8s DNS已经可以实现负载均衡，还需要服务Mesh吗？
3. 如果使用无服务网状网的K8，是否落后于正常操作？

其实我也想每天都用Service Mesh。

推荐答案

简单的答案是

Kubernetes服务器的Service Mesh不是必需的

现在回答您的问题

如果我需要监控集群资源，我们有普罗米修斯、grafana和K9。他们是否扮演与服务网状网相同的监控角色(例如linkerd、istio)？

K9S是一个CLI工具，只是CLI工具的替代工具。它不是监控工具。普罗米修斯(Prometheus)和格拉凡纳(Grafana)都是监测工具，它们需要使用应用程序(Pod)提供的数据来构建时间序列数据，这些数据可以可视化为图表、图形等。但是，应用程序必须向普罗米修斯提供监测数据。服务网格可以使用侧车，并提供一些用于监视的默认度量，例如number of requests handled in a second。您的应用程序不需要具有任何指标知识或实现。因此，服务网格是可选的，它可以卸载监控或授权等常见事务。

如果K8s DNS已经可以实现负载均衡，还需要服务Mesh吗？

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

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

不可以，可能存在当前没有服务网状网但仍在使用Kubernetes的群集。

未来Kubernetes可能会带来一些服务网的功能。

这篇关于Kubernetes-服务网状结构是必须的吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！