我目前正在研究分布式系统，并且已经看到许多企业依赖 Sidecar 代理模式来提供服务。例如，我知道一家公司使用 nginx 代理对其服务、角色和权限进行身份验证，而不是在其服务中包含此业务逻辑。
另一个使用 GKE 上的 cloud-sql-proxy 来使用谷歌云上的 Cloud SQL 产品。因此，除了将它们的服务部署在运行在 pod 中的容器中之外，它们还只是用于与数据库通信的代理。
还有 istio，它是一种服务网格解决方案，可以部署为 pod 中的边车代理。
我很确定还有其他常见的使用这种模式的用例，但在某些时候，过多的边车代理有多少？运行它的 pod 有多重？在服务容器顶部使用 2、3 甚至 4 个 side car 代理会带来什么复杂性？
【问题讨论】：
标签： kubernetes proxy containers cloud distributed-system
我建议你定义你真正需要什么，并以此为基础继续你的研究，因为这个话题太宽泛，没有一个正确的答案。
因此，我决定发布一个社区 wiki 答案。随意扩展它。
在一个 pod 中运行一些容器可能有多种原因。根据Kubernetes documentation：
一个 Pod 可以封装一个由多个并置的应用组成的应用 紧密耦合并需要共享资源的容器。这些 位于同一地点的容器形成了一个单一的有凝聚力的服务单元——用于 例如，一个容器将存储在共享卷中的数据提供给 公共，而单独的 sidecar 容器刷新或更新 那些文件。 Pod 包装了这些容器、存储资源和一个 短暂的网络身份作为一个整体。
以最简单的形式，sidecar 容器可用于向主应用程序添加功能，否则这些功能可能难以改进。
使用边车容器的优势
有关使用边车容器的注意事项
考虑制作一个不消耗太多资源的小型边车容器。 Sidecar 容器的优势在于它们体积小且可插拔。如果 sidecar 容器逻辑变得越来越复杂和/或与主应用程序容器的耦合越来越紧密，则最好将其与主应用程序的代码集成。
为了确保任意数量的 sidecar 容器可以成功地与主应用程序一起工作，有必要在为 pod 定义资源限制时汇总所有资源/请求限制，因为所有容器将并行运行。整个功能只有在两种类型的容器都成功运行时才能工作，而且大多数情况下，这些边车容器既简单又小，消耗的资源比主容器少。
【讨论】：