当我阅读有关负载均衡器和容器的文章时，寻求对负载均衡器中的服务网格的清晰理解以及它在容器中如何使用。
答案1
考虑服务网格时，我想到的是 istio，以及 envoy 代理。
https://istio.io/docs/concepts/what-is-istio/ https://www.envoyproxy.io/
这是怎么回事？这里要回答的问题太多了，但这是一篇很好的文章，其中有几个实际的例子，说明 istio 可以提供哪些功能：
https://developers.redhat.com/blog/2018/03/06/introduction-istio-makes-mesh-things/
答案2
Istio 正因这一点而广为人知。它以“sidecar”容器的形式运行，这意味着它是同一个 pod 中的另一个容器，因此将与另一个容器共存，并可以影响该容器的网络流量。
简而言之，服务网格实际上是代理的集合（通常用于微服务架构），但在某种程度上与具有负载平衡虚拟服务器的传统 HA 方法相反。
例如：假设容器应用程序 A 想要与服务 S 通信；S 不是负载均衡器（例如 haproxy），而是可能有多个 S 实例。A 将有一个 sidecar，其属性是当 A 想要连接到 S 时，sidecar 会将流量路由到其中一个 S。
想象一下整个微服务架构中的流量差异；由于您有效地为每个客户端配备了一个负载均衡器，因此您减少了瓶颈数量。
现在考虑一下你还能用这种东西做什么；想要以标准方式验证服务，而不必在容器应用中实现这一点？也许 sidecar 容器可以为你做到这一点。
想要一些好的断路器逻辑来帮助防止超时并提供优雅的故障处理吗？Sidecar！
那么功能标志支持怎么样，这样您就可以优雅地执行诸如暗启动或故障退出功能之类的操作来应对负载。Sidecar！
如何帮助监控、可视化和分析您建筑内的交通？单轨！单轨！……边车！
我想说的是，你可以让你的应用程序像一只讲 http 的绿色独角兽一样简单，而让其他东西来关心基础设施和开发人员通常讨厌考虑的事情（ssl、负载平衡等）
或者至少我希望这就是服务网格承诺的意义所在。