有三种常见的设计模式和用例，用于将多个容器组合到一个容器中。我们将逐步介绍边车模式，适配器模式和大使模式。
1.边车模式 Sidecar
边车模式由一个主应用程序（即Web应用程序）以及一个辅助容器组成，该容器对您的应用程序是必不可少的，但不一定是应用程序本身的一部分。
最常见的Sidecar容器是日志记录实用程序，同步服务，观察程序和监视代理。在应用程序本身不运行时运行日志记录容器是没有意义的，因此我们创建了一个包含主应用程序和sidecar容器的pod。进行日志记录工作的另一个好处是，如果日志记录代码有错误，则错误将被隔离到该容器中-非必需的日志记录代码中引发的异常不会导致主应用程序崩溃。
2.适配器模式 Adapter
适配器模式用于标准化和规范化应用程序输出或监视数据以进行聚合。
作为一个简单的示例，我们有一个跟踪响应时间的集群级监视代理。假设我们的集群中有一个Ruby应用程序，它以格式写入请求计时[DATE] - [HOST] - [DURATION]，而另一个Node.js应用程序以写入相同的信息[HOST] - [START_DATE] - [END_DATE]。
监视代理只能接受格式为的输出[RUBY|NODE] - [HOST] - [DATE] - [DURATION]。我们可以强制应用程序以所需的格式编写输出，但这会给应用程序开发人员带来负担，并且取决于此格式，可能还有其他事情。更好的替代方法是提供将输出调整为所需格式的适配器容器。然后，应用程序开发人员可以简单地更新pod定义以添加适配器容器，并且他们可以免费获得此监视。
3.大使模式 Ambassador
大使模式是将容器与外界连接的一种有用方法。大使容器本质上是一种代理，它允许其他容器连接到本地主机上的端口，而大使容器则可以根据群集的需要将这些连接代理到不同的环境。
大使模式的最佳用例之一是提供对数据库的访问。在本地进行开发时，您可能希望使用本地数据库，而测试和生产部署又需要不同的数据库。
管理连接到哪个数据库可以通过环境变量来完成，但这将意味着您的应用程序根据环境更改连接URL。更好的解决方案是使应用程序始终连接到localhost，并将映射到正确数据库的连接的责任落在大使容器上。或者，大使可以将请求发送到数据库的不同分片-应用程序本身无需担心。
