Kubernetes - Service Mesh 是必须的吗？
Kubernetes - is Service Mesh a must?
最近用Nginx ingress controller在k8s集群中搭建了几个微服务，运行正常。
在处理微服务之间的通信时，我尝试了 gRPC，它成功了。然后我发现当微服务 A -> gRPC -> 微服务 B 时，所有请求仅发生在微服务 B 的 1 个 pod 中（例如微服务 B 总共有 10 pods 个可用）。为了平衡对微服务 B 的所有 pods 的请求，我尝试了 linkerd，它成功了。然而，我意识到 gRPC 有时会产生内部错误（例如 100 个请求中有 1 个错误），让我改为使用 k8s DNS 方式（例如 my-svc.my-namespace.svc.cluster-domain.example ).然后，请求永远不会失败。我开始顶起gRPC和linkerd
后来对istio产生了兴趣。我成功地将它部署到集群中。但是，我观察到它总是创建自己的负载均衡器，这与现有的 Nginx ingress 控制器不太匹配。
此外，我尝试了prometheus和grafana，还有k9s。这些工具让我更好地了解 cpu 和 pods.
的内存使用情况
这里有几个问题想了解一下：-
- 如果我需要监控集群资源，我们有prometheus、grafana和k9s。他们是否扮演与服务网格（例如 linkerd、istio）相同的监控角色？
- 如果k8s DNS已经可以实现负载均衡，还需要service mesh吗？
- 如果在没有service mesh的情况下使用k8s，是否落后于正常做法？
其实我也想天天用service mesh
简单的答案是
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 是监控工具，需要使用应用程序提供的数据（pods）并构建时间序列数据，这些数据可以可视化为图表、图形等。但是应用程序必须向 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 控制器。此外，Istio 等服务网格带有自己的入口控制器。
if using k8s without service mesh, is it lag behind the normal practice?
不，今天可能会有没有服务网格但仍在使用 Kubernetes 的集群。
未来，Kubernetes 可能会从服务网格中引入一些功能。
服务网格不是灵丹妙药，它并不适合所有用例。服务网格不会为你做所有事情，它也有错误和有限的功能。
- 你可以在没有 Istio 的情况下使用 Prometheus，并且有一个非常好的应用程序监控。 Service Mesh可以为你简化一些监控工作，但不代表你不能自己做。
- 请不要将 DNS 视为负载平衡解决方案。 Kubernetes 有 Services 和 Ingresses 来做负载均衡。今天的 Nginx Ingress 非常强大，有很多高级功能。
- 这在很大程度上取决于您的用例。
最近用Nginx ingress controller在k8s集群中搭建了几个微服务，运行正常。
在处理微服务之间的通信时，我尝试了 gRPC，它成功了。然后我发现当微服务 A -> gRPC -> 微服务 B 时，所有请求仅发生在微服务 B 的 1 个 pod 中（例如微服务 B 总共有 10 pods 个可用）。为了平衡对微服务 B 的所有 pods 的请求，我尝试了 linkerd，它成功了。然而，我意识到 gRPC 有时会产生内部错误（例如 100 个请求中有 1 个错误），让我改为使用 k8s DNS 方式（例如 my-svc.my-namespace.svc.cluster-domain.example ).然后，请求永远不会失败。我开始顶起gRPC和linkerd
后来对istio产生了兴趣。我成功地将它部署到集群中。但是，我观察到它总是创建自己的负载均衡器，这与现有的 Nginx ingress 控制器不太匹配。
此外，我尝试了prometheus和grafana，还有k9s。这些工具让我更好地了解 cpu 和 pods.
的内存使用情况这里有几个问题想了解一下：-
- 如果我需要监控集群资源，我们有prometheus、grafana和k9s。他们是否扮演与服务网格（例如 linkerd、istio）相同的监控角色？
- 如果k8s DNS已经可以实现负载均衡，还需要service mesh吗？
- 如果在没有service mesh的情况下使用k8s，是否落后于正常做法？
其实我也想天天用service mesh
简单的答案是
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 是监控工具，需要使用应用程序提供的数据（pods）并构建时间序列数据，这些数据可以可视化为图表、图形等。但是应用程序必须向 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 控制器。此外，Istio 等服务网格带有自己的入口控制器。
if using k8s without service mesh, is it lag behind the normal practice?
不，今天可能会有没有服务网格但仍在使用 Kubernetes 的集群。
未来，Kubernetes 可能会从服务网格中引入一些功能。
服务网格不是灵丹妙药，它并不适合所有用例。服务网格不会为你做所有事情，它也有错误和有限的功能。
- 你可以在没有 Istio 的情况下使用 Prometheus，并且有一个非常好的应用程序监控。 Service Mesh可以为你简化一些监控工作，但不代表你不能自己做。
- 请不要将 DNS 视为负载平衡解决方案。 Kubernetes 有 Services 和 Ingresses 来做负载均衡。今天的 Nginx Ingress 非常强大，有很多高级功能。
- 这在很大程度上取决于您的用例。