临时卷在 Kubernetes 中的用途是什么？答案

【问题标题】：What purpose to ephemeral volumes serve in Kubernetes?临时卷在 Kubernetes 中的用途是什么？
【发布时间】：2020-10-30 18:33:34
【问题描述】：

我最近开始学习 Kubernetes，我注意到在网上的各种教程中几乎没有提到 Volumes。教程涵盖 Pod、ReplicaSet、部署和服务——但它们通常以使用这四者的组合构建的一些示例微服务应用程序结束。当涉及到数据库时，他们只需使用“mongo”映像部署一个 pod，给它一个名称和一个服务，以便其他 pod 可以看到它，然后将其保留。没有讨论如何将数据写入磁盘。

因此，我只能假设在没有额外配置的情况下，容器可以将文件写入磁盘。我不相信这意味着文件在容器重新启动时是持久的，但是如果我像这样编写一个简单的 NodeJS 应用程序：

const fs = require("fs");
fs.writeFileSync("test.txt", "blah");
const value = fs.readFileSync("test.txt", "utf8");
console.log(value);

我怀疑这会正确输出“blah”并且不会由于无法写入磁盘而崩溃（请注意，我没有对此进行测试，因为我还在学习 Kubernetes，所以我还没有明白这一点我知道如何将我自己的自定义图像放在我的集群中——到目前为止，我只在 Docker Hub 上加载了图像）

然而，在阅读Kubernetes Volumes 时，我发现了Ephemeral Volume——一本书：

get[s] 与 Pod 一起创建和删除

临时卷的存在使我得出以下两个结论之一：

容器不能在没有被授予权限（通过卷）的情况下写入磁盘，所以到目前为止我看到的每个教程都是废话，因为 mongo 会崩溃当您尝试存储数据时
临时卷没有意义，因为您可以已经在没有它们的情况下写入磁盘，那么它们有什么用途？

那么这些东西是怎么回事？为什么有人会创建一个临时卷？

【问题讨论】：

标签： docker kubernetes

【解决方案1】：

容器进程始终可以写入容器本地文件系统（Unix 权限允许）；但是一旦 pod 被删除，那里的任何内容都会丢失。 Pod 可以被相当常规地删除（例如，如果您需要升级映像）或超出您的控制范围（如果它所在的节点已终止）。

在文档中，types of ephemeral volumes 突出显示了两个主要内容：

emptyDirvolumes，通常用于在单个 pod 中的容器之间共享内容（更具体的是将数据从 init 容器发布到主容器）；和
从configMap、downward API 或其他可能完全人为的数据源注入数据

在这两种情况下，数据“就像一个卷”：您指定它的来源和安装位置，它会隐藏底层映像中的任何内容。如果 pod 被删除并重新创建，底层存储恰好不是持久的，这与持久卷不同。

通常预打包的数据库版本（如 Helm 图表）将包含一个持久卷声明（或在有状态集中为每个副本创建一个），以便数据确实得到持久化，即使 pod被破坏了。

【讨论】：

【解决方案2】：

那么这些东西是怎么回事？为什么有人会创建一个临时卷？

临时卷更多是概念性的东西。这个概念的主要需求来自微服务和编排流程，也受到12 factor app 的指导。但为什么呢？

因为，一个主要用例是当您使用容器在集群中的多台机器上部署多个微服务（及其副本）时，您不希望容器依赖于自己的存储。如果容器依赖于它们的存储，那么关闭它们并启动新的容器会影响您的应用程序的行为方式，这是每个人都希望避免的事情。每个人都希望能够随时启动和停止容器，因为这样可以轻松扩展、更新等。

当您实际需要具有持久数据的服务（如 DB）时，您需要一种特殊类型的配置，尤其是当您在机器集群上运行时。如果您在一台机器上运行，则可以使用已安装的卷，以确保即使在容器停止后您的数据仍将保留。但是，如果您只想在数百个 无状态 API 服务之间实现负载平衡，那么临时容器就是您真正想要的。

【讨论】：