Multi-container POD设计模式

在设计多容器 POD 时，有 3 种常见模式。第一个也是我们刚在日志服务示例中看到的，称为 side car 模式。其他的是 adapter 和 ambassador 模式。

img

Sidecar模式

Sidecar容器与主容器一起工作。当主容器和需要为其完成的任何辅助任务之间存在明显差异时，最好使用此模式。

例如，需要解析日志并将其转发到日志存储（次要任务）的 Web 服务容器（主应用程序）可以使用负责日志转发的 sidecar 容器。这个同一个 sidecar 容器还可以用在其他位置，为其他 Web 服务甚至其他应用转发日志。

sidecar-pattern.png

收集pod日志常用Sidecar模式：

image-20200316222728544

Ambassador/Proxy模式

Ambassador模式是与主应用程序容器一起运行附加服务的另一种方式，但它是通过代理来实现的。Ambassador容器的主要目标是简化主应用程序对外部服务的访问，其中Ambassador容器充当服务发现层。外部服务的所有配置都位于Ambassador容器中，主应用程序使用本地主机上的服务。Ambassador容器负责连接到服务以保持连接打开、在发生意外情况时重新连接以及更新配置。 使用这种模式，开发人员只需要考虑他们的应用程序连接到本地主机上的单个服务器。

这种模式对于容器来说是独一无二的，因为在同一台机器上运行的所有 Pod 将共享本地主机网络接口。

ambassador-pattern.png

Adapter模式

适配器模式通常将主容器的输出转换为符合应用程序标准的输出。例如，Adapter容器可以向应用程序公开标准化的监视接口，即使应用程序没有以标准方式实现它。Adapter容器负责将输出转换为集群级别可接受的内容。

adaptor-pattern.png

示例：在将日志发送到日志服务器之前，我们希望将日志转换为通用格式。为此，我们部署一个适配器容器。适配器容器在将日志发送日志服务器之前对其进行处理。

image-20200322205917388

强烈建议阅读：https://www.weave.works/blog/container-design-patterns-for-kubernetes/