多容器设计考虑
但是Kubernetes管理员总是选择单一容器Pod而不是多容器Pod。每个Pod采用一个容器是行业中的一人不成文做法。以下了解多容器Pod可以提供什么优势。
Pod有一个IP，而一个Pod中的所有容器可以共享相同的IP。如果为Pod创建了任何卷，则作为Pod一部分的所有容器都可以安装该卷。因此，容器可以共享存储空间，它们还可以通过本地主机相互通信。
在这种情况下，为什么仍然首选单一容器Pod。以具有用户界面(UI)、后端、数据库和消息传递层的Web应用程序为例。将所有四个层部署为单个Pod中的四个容器。所有四个容器的资源、配置、操作要求都不同。后端和前端是面向客户的。如果需要将这些扩展到不同的层次，则不能单独完成，由于不能扩展容器，只能扩展Pod。因此，如果扩展Pod，也会创建数据库和消息层的多个实例，尽管这不是必需的。
因此，最好将它们分开部署，因为像单独的一个Pod一样管理和扩展它们会更好。
在什么情况下，可以在同一个Pod中使用多个容器?
情况1–如果容器的生命周期相同。
情况2–如果两个容器高度耦合。
情况3–如果需要使应用程序无需任何代码更改即可部署到Kubernetes。在这种情况下，应用程序代码缺乏利用Kubernetes功能的东西。在这种情况下，可以在应用程序容器中引入一个辅助容器，这将打破这种障碍。
多容器设计模式
1.适配器模式
如今的家庭通常采用的是交流电，而人们使用的笔记本电脑使用的是直流电。在这种情况下，使用交流适配器从插座获取电源，然后将其转换为直流电并为笔记本电脑供电。在不改变供电模式的情况下，可以借助适配器为笔记本电脑充电。
那么如何将这种模式与Kubernetes有什么联系?例如，如果在Kubernetes集群中安装了一个集中监控工具，它需要将所有应用日志以“应用程序(APP)-名称(NAME)-主机名称(HOSTNAME)-日期(DATE)-严重程度(SEVERITY)”格式打印。但是集群可以有许多应用程序以多种语言编写，并以多种格式打印日志。在这种情况下，所有应用程序都更改其日志记录格式是不明智的，就好像该工具将来会更改并且格式可能再次更改一样。为了解决这个问题，可以生成第二个容器来读取主要应用程序容器的日志，并将其处理成监控工具所需的格式。这样可以解决不匹配的问题。
2.大使模式
大使是各国派驻他国的特使。这种模式如何在Kubernetes Pod提供帮助?
例如，如果有一个遗留应用程序，其中DB URL在应用程序内被硬编码为localhost。更改遗留应用程序很困难，因为它会在许多其他地方带来更改。如果必须使其可在Kubernetes集群中部署，则需要更改代码。可以使用大使模式在不更改代码的情况下做到这一点。大使容器将应用程序容器共置在同一个Pod中。它是一个代理，根据开发、质量保证(QA)或Stage环境连接到正确的数据库。
主应用程序可以通过大使容器连接到诸如localhost之类的外部URL。大使模式找到正确的URL，并将其提供给位于localhost的应用程序容器。主应用程序容器不需要担心正确的URL。这将被分配给大使容器。
3.边车模式
边车(Sidecar)的原理与挎斗摩托车类似，挎斗摩托车只是增加了一个座位，而没有对其主要部署进行任何更改，虽然这个座位不是摩托车的组成部分，但增强了性能。Sidecar容器也采用同样的工作方式。边车增强了与它一起部署的主容器的能力，而无需对主容器进行任何更改。例如，应用程序在某个文件夹中生成日志文件。
如果在Kubernetes集群中采用应用程序监控工具，需要将所有部署到集群的应用程序的日志存储在某个外部存储空间中，那么在应用程序级别根本无法完成。相反，可以使用一个边车容器，它可以轻松地将日志文件存储在所需的存储空间中，而无需在主应用程序级别进行任何代码更改。
结论
所有这些模式对于在不更改主要应用程序的情况下执行横切作业非常有用。它们为主容器提供支持，并且必须作为辅助容器进行部署。这些工作负载必须以可以在不同Pod中重用的方式编写。
为了解释这种方法，使用适配器模式，必须将主容器的输出转换或处理为某种标准格式;大使模式用于提供网络代理;边车模式用于向主容器提供帮助程序/实用程序服务。
而人们尝试使用这些模式可以充分利用Kubernetes集群。
原文连接：Multi-Container Pod Design Patterns in Kubernetes，作者：Aditya Bhuyan
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
