在这篇博文中,我们将研究与 Kubernetes 初始化容器、边车、配置映射和探测器相关的某些高级概念。我们将向您展示如何在您自己的集群中实现这些概念,但更重要的是如何将这些概念应用到您的项目中Release既有趣又有利可图。

我们将从简要介绍 Kubernetes 中的 pod 和容器开始,然后展示上面列出的每个项目的具体示例。您将在下面找到这些示例的绘图,以在我们颠簸的旅程中保持自己的方向。

关键 Kubernetes Pod 概念

在开始之前,让我们简要概述一些关键概念。

集装箱

在 Docker 中,容器是捆绑分层文件系统的映像,可以将其部署为可运行的捆绑包。该容器通常使用 Dockerfile 构建,并具有启动二进制文件或可执行命令。

边车集装箱

sidecar 容器只是一个与 pod 中的其他容器一起运行的容器。边车概念没有官方定义。将容器与 sidecar 容器区分开来的唯一一点是,您认为它是主容器的辅助或次要容器。运行多个 sidecar 容器不能很好地扩展,但确实具有能够重用配置文件和容器映像的额外优势。 Sidecar 不能很好地扩展的原因是,基于主应用程序容器的性能,它们可能会被过度使用或浪费。但是,在遗留应用程序或向真正的云原生设计迁移期间,这种权衡是有意义的。

初始化容器

一个初始化容器只是一个在 pod 中的任何其他容器之前运行的容器。您可以有多个按顺序运行的 init 容器。随着每个容器完成并正确退出(零!),下一个容器将启动。如果 init 容器因错误退出或未完全完成,则 pod 可能会进入可怕的 CrashLoopBackoff。所有容器共享一个文件系统,因此这里的好处是您可以使用或重用容器映像来处理、编译或生成文件或文档,这些文件或文档可以稍后被其他容器拾取。

探头

尽管“探针”这个词可能会激起人们对用于发现和调查人类的外星工具的幻想,但不要害怕。这些探针只会让您的服务运行得更好! Kubernetes 有多个探测器用于定义 pod 内容器的健康状况。启动探测允许调度程序容忍慢启动容器中的延迟。活性探针允许 Kubernetes 重新启动故障或停止的容器。准备就绪探测允许容器仅在准备好接收流量时接收流量。

吊舱

你可能对“豆荚人”或植物克隆心存一些恐惧,这些植物克隆是为了用无意识的僵尸来猎杀和毁灭人类来取代人类。但是,在 Kubernetes 中,最小的托管单元是 pod。但是一个 pod 可以由多个容器组成,这些容器在单个进程空间和文件系统中运行。 pod 通常由一个容器组成,该容器将单个进程作为服务运行。但是,我们将介绍几个高级使用示例,它们运行多个容器以扩展选项和用例。

节点

Kubernetes 节点最终是一个物理机器(可以有多个虚拟化层),它运行一个或多个 pod,提供关键的 CPU、内存、磁盘和网络资源。多个 pod 可以分布在多个节点上,但单个 pod 包含在单个节点上。

卷

卷只是可以安装在容器内的文件系统的抽象。您不能重叠或嵌套卷安装。但是,有几种挂载类型可能对您的用例非常有用。

配置映射

configMap是所谓的信息“blob”,可以作为文件安装在容器中。请记住,这不是一个邪恶的、具有破坏性的团块来吞噬我们的星球!它是一批被无定形处理的文本,就像一个......嗯...... blob。这里通常的用例是配置文件或秘密挂载。

空目录

emptyDir是一个空文件系统,可以写入 pod 内的容器并供其使用。这里通常的用例是用于临时存储或可以共享的初始化文件。

主机路径

hostPath是直接存在于 Kubernetes 节点上的文件系统,可以在 pod 中的容器之间共享。这里通常的用例是存储缓存文件,如果可用,这些文件可以从以前的部署中启动。

持久卷声明 (PVC)

持久卷声明是一个文件系统,它在命名空间内的节点和 pod 之间持续存在。 PVC 中的数据不会在 pod 被移除时被删除或销毁,只有在命名空间被移除时。 PVC 有多种底层存储方式,具体取决于您的云提供商和基础架构架构。

命名空间

Kubernetes 命名空间是一组资源,它们组合在一起并且通常可以相互访问。多个 pod、部署和卷声明(仅列出几个)将一起运行,可能跨多个节点。

边车和初始化容器

我们将介绍的第一个用例涉及在单个 pod 中运行多个容器。再一次,这里的 pod 是指在 Kubernetes 中组合在一起的一个或多个容器,而不是出于邪恶原因种植的植物人类克隆。在以下场景中,我们将研究多个容器如何共享单个进程空间、文件系统和网络堆栈。

请记住,大多数 docker 和 Kubernetes 纯粹主义者会告诉您,在一个容器中运行多个进程,或者在一个 pod 中拥有多个容器不是一个好的设计,并且不可避免地会导致可扩展性和架构问题。这些担忧通常是有根据的。但是,仔细应用以下受支持和推荐的模式将使您在从遗留堆栈过渡到 Kubernetes 期间或在集群中成功运行应用程序后茁壮成长。

我们与客户遇到的一个特殊用例是他们的应用程序有一个后端容器,该容器需要像 Nginx 这样的反向代理来执行路由、静态文件服务等。实现此目标的最佳方法是使用 Nginx(例如)创建一个单独的 pod,并在单个命名空间中运行两个服务 pod。这使我们可以灵活地根据需要分别扩展后端 pod 和 Nginx pod。但是,通常后端服务或应用程序还需要提供位于容器文件系统内且无法跨 pod 边界使用的静态文件。我们同意这不是首选模式,但它在我们看到的遗留应用程序中很常见。

在这种情况下,我们经常推荐运行 Nginx 的 sidecar 容器,可以直接从 Docker Hub 中拉取,也可以创建自定义镜像。我们还建议客户将其后端应用程序容器重新用作以自定义命令启动的 init 容器,以创建任何初始化或其他需要在应用程序本身启动之前完成的启动任务。

这种多容器设置的一个特点是 Nginx 容器可以使用“localhost”环回与后端服务进行通信。当然,sidecar 容器可能是一个日志或监控代理,但原理是一样的:容器可以通过私有网络相互通信,该私有网络可能在 pod 之外不可用,除非您使其可用。在我们的 Nginx 示例中,可以隔离后端,以便所有入站到服务容器的通信流量都必须路由到 Nginx 代理。

此配置的另一个不错的功能是容器都共享一个公共文件系统,以便 Nginx 容器可以访问由后端服务容器生成(或存储在)上的静态文件。

这是我们文档的链接,该链接显示了在 Release 上运行sidecar和init容器的示例。

探头

正如我们所指出的,探测器不仅适用于外星人! Kubernetes 使用它们来测试您的应用程序堆栈并报告其运行状况。 Kubernetes 也会根据这些探测采取行动,就像外星人一样。 Kubernetes 原生支持多种探针。我们为客户支持的主要用例是 liveness probe 和 readiness probe。

liveness probe 是一种测试容器是否“活着”的方法,如果探测失败,Kubernetes 会重启容器。我们通常建议您的应用程序不要冻结或出现内存泄漏等问题,这样就不需要进行活性探测。这种“重启你的应用程序来解决问题”的理念通常不被认为是好的做法。然而,完美的代码是不可能的,当服务在生产容器环境中运行时,我们知道几乎任何事情都可能(并且将会)发生。

就绪探测是一种测试容器是否能够服务流量的方法,如果探测失败,则服务端口将从入口控制器中删除。与我们对活性探测的立场相反,我们强烈鼓励并建议客户对任何接收入站流量的服务实施就绪探测。从某种意义上说,我们认为您的生产服务必须进行就绪探测。

这是我们文档的链接,该链接显示了使用liveness and readiness probe来运行在 Release 中的服务的示例。

卷

这部分有点技术性和棘手。当然,实际的客户堆栈不会使用本文中列出的每种类型的卷、容器和探测器。但我们确实希望这个概述能展示所有可能的功能。您应该仔细考虑下面介绍的用例,并选择最适合您的用例的用例。

这是我们文档的链接,其中显示了我们的存储卷类型的选项。

configMap(即时文件挂载)

configMap(特意拼写为camelCase)本身并不是 Kubernetes 中的卷。严格来说,configMap 只是一个文本块,可以存储在etcd 键值数据存储区中。但是,Release 支持的一个方便的用例是创建一个容器存储卷,该卷作为文件安装在容器内,其内容是存储在 etcd 中的文本 blob。在发布时,我们将此客户帮助函数称为Just in Time File Mount。发布时 configMap 的常见用例是能够上传包含配置详细信息的文件。例如,在我们之前涉及 Nginx Sidecar 的示例中,nginx.conf文件可以作为即时文件挂载上传。 “我们想要什么?文件装载!我们什么时候想要它们?及时!”

emptyDir (Scratch Volume)

emptyDir 卷是原生 Kubernetes 构造 Release 支持 pod 中的容器共享可以在本地挂载的空白空间。一旦 pod 结束其生命周期,此卷就会被擦除,并且一开始它是空白的。因此,最常见的用例是在临时位置或临时位置存储仅需要在 pod 生命周期内存储的文件。

hostPath(Pod内缓存或共享卷)

下一个示例是一个原生 Kubernetes 结构,Release 支持 pod 中的容器共享保留在节点上的文件系统路径。 hostPath 卷最常见的用例是存储缓存或构建数据,这些数据可以根据需要在 pod 内生成和重新生成。与只持续与 pod 一样长的 emptyDir 卷不同,hostPath 可以持续与部署 pod 的应用程序一样长。因此,容器可以生成(或计算)文件、资产或数据,这些文件、资产或数据可以在同一节点上的下一个 pod 部署中重复使用或增量更新。 Release 会自动设置正确的权限,并确保每个命名空间都有唯一的文件,这样数据就不会在客户之间泄露。

PVC(长期持久存储)

Release 提供的卷挂载的最后一个示例是将数据存储在持久存储上的能力,该持久存储可跨命名空间中的节点和 pod 使用。这种长期存储是持久的,不会在 pod 或节点生命周期中消失。 Release 使用 Amazon Web Services (AWS) 弹性文件系统 (EFS),这是他们的网络文件系统 (NFSv4) 存储云产品。这允许客户存储将在部署、可用区 (AZ) 和节点故障之间持续存在的长期数据,并且可以在多个 Pod 之间共享。这种类型的持久存储最常见的用例是用于需要在部署之间长期存储的预生产数据库。

结论

在本文中,我们为您概述了其他任何地方都找不到的 Kubernetes pod 的关键高级概念。如果您对在 Kubernetes 部署中使用这些示例充满信心并练习过,那么您可以认为自己是精英从业者俱乐部的成员之一。这种好处不仅仅伴随着一个显赫的头衔或说明您的资格的论文:它还可以在您的 DevOps 职业生涯中取得巨大的成功和成就。

照片由Wynand Uys 拍摄onUnsplash