Kubernetes 是一个开源容器编排引擎,用于自动化容器化应用程序的部署、扩展和管理。Pod 是 kubernetes 应用程序的基本构建模块。Kubernetes 管理着 Pod,Pod 封装着容器。一个 Pod 可能包含一个或多个容器、存储、IP 地址,并控制着容器运行。包含一个容器的 Pod 称为单容器 Pod,这是最常见的 kubernetes 用例。

包含多个相互关联容器的 Pod 指多容器 Pod。Pod 运行于不同的复杂环境,一些独特的容器设计模式可以帮助适应环境,本文就介绍了几种常见的容器设计模式。

Init(初始化)容器

Init 容器是在容器中启动主容器之前应运行并完成的容器。它为初始化提供了单独的生命周期,因此可以分离应用程序中的关注点。例如,当我们需要安装一些特定的软件后才能运行应用程序时,可以在 Pod 的 Init 容器中进行该安装。

我们可以为 Init 容器定义 n 个容器,并且只有在成功终止所有 Init 容器之后,主容器才会启动。所有 Init 容器将被顺序执行,如果 Init 容器中有错误,Pod 将重新启动,所有 Init 容器也将再次执行,因此最好将 Init 容器设计得简单、快速。在某些情况下,我们可以使用此模式:

  • 在应用程序或主容器需要一些先决条件(例如在启动之前安装一些软件、数据库设置、文件系统的权限)。
  • 希望延迟主容器启动。

Sidecar(边车)容器

Sidecar 容器是与 Pod 中的主容器一起运行的容器。Sidecar 模式可以在不更改的情况下扩展并增强当前容器的功能。

当带有单容器 Pod 正常运行时,我们想在不接触、不更改的情况下向当前容器添加或扩展一些功能,这种情况下,Sidecar 容器模式可以提供帮助。

我们可以为 Sidecar 容器定义任意数量的容器,并且能与主容器协同工作。所有容器并行执行,并且仅当两种类型的容器都成功运行时,整个功能才起作用。在大多数情况下,Sidecar 容器既简单又小巧,比主容器消耗更少的资源。在某些情况下,我们可以使用此模式:

  • 希望扩展或增强现有单个容器 Pod 的功能但不想更改现有容器 Pod 功能。
  • 想将主容器代码与 git 服务器请求同步。
  • 将日志事件发送到外部服务器。
  • 用于与网络相关的任务时。

Adapter(适配器)容器

本质上,很多应用程序是异构的,这意味着它们没有相同的接口,或者与其他系统是不一致的。

想象一下,一个容器 Pod 正在运行,但是它与其他系统没有相同的接口,因为无法集成或使用它。如何使该容器具有标准化格式的统一接口,以便其他系统可以连接到容器?Adapter 容器模式可以在这种情况下起到作用。

我们可以为 Adapter 容器定义任意数量的容器,并且主容器可以与其一起使用。

Ambassador(外交官)容器

Ambassador 容器是一种特殊的 Sidecar 容器,可以简化 Pod 外部服务。在 kubernetes 上运行应用程序时,可能会有外部服务访问数据。Ambassador 容器隐藏了复杂性,并提供了统一的接口来访问这些外部服务。

当我们需要访问外部服务时,外部服务可能会是动态的、会返回不同的格式,或者由于其他一些原因,我们不想在主容器中处理这种复杂性,Ambassador 容器就能处理此类情况。

在某些情况下,我们可以使用此模式:

  • 希望隐藏主容器的复杂性,例如服务发现(service discovery)。
  • 当容器化服务想要与外部服务对话时,我们可以使用此模式来处理这些服务的请求和响应。
  • 每当需要转换或标准化外部服务响应的格式时。

原文链接:https://medium.com/bb-tutorials-and-thoughts/kubernetes-learn-init-container-pattern-7a757742de6b