为什么 kubernetes 不直接与容器一起工作

Question

请有人向我解释一下（或直接访问详细资源）为什么 kubernetes 使用此包装器 (pod) 来处理容器。我遇到的每个资源都只是引用相同的词——“它是 k8s 中的最小单元”。我正在寻找的是从工程角度来看的原因。我确实知道它为内部容器的存储和网络提供了命名空间，但最佳实践是在 Pod 中保留单个容器。

在熟悉 k8s 之前，我已经使用过docker-compose很多东西，并且很难理解围绕非常简单的实体（容器）的这个附加层（包装器）的需要。

Answer 1

做出这一决定的原因很简单，一个 Pod 可能包含多个容器，执行不同的操作。

首先，一个pod可能有一个init-container，它负责做一些启动操作，以确保主容器正常工作。我可以让初始化容器加载一些配置并为主应用程序做好准备，或者执行一些基本操作，例如恢复备份或类似的操作。

我基本上可以在启动主应用程序之前注入一系列操作来执行，而无需再次构建主应用程序容器映像。

其次，即使大多数应用程序只有一个 Pod 容器就可以了，但在某些情况下，同一个 Pod 中的多个容器可能会有用。

一个示例可能是让主应用程序运行，然后一个 sidecar 容器在主应用程序前面执行代理，可能负责检查 JWT 令牌。或者另一个示例可能是辅助应用程序从主应用程序中提取指标应用程序或类似的东西。

最后，让我引用 Kubernetes 文档（https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/）

Pod 可以拥有多个容器的主要原因是为了支持辅助主应用程序的辅助应用程序。帮助器应用程序的典型示例是数据拉取器、数据推送器和代理。辅助应用程序和主应用程序通常需要相互通信。通常，这是通过共享文件系统（如本练习中所示）或通过环回网络接口 localhost 完成的。此模式的一个示例是 Web 服务器以及帮助程序，该程序轮询 Git 存储库以获取新更新。

更新

就像你说的，init 容器.. 或同一个 Pod 中的多个容器不是必须的，我列出的所有功能也可以通过其他方式获得，例如 en 入口点或两个独立的 Pod 相互通信而不是两个容器在同一个 Pod 中。

使用这些功能有几个好处，让我再次引用 Kubernetes 文档（https://kubernetes.io/docs/concepts/workloads/pods/init-containers/）

由于 init 容器具有与应用程序容器不同的映像，因此它们对于启动相关代码有一些优势：

初始化容器可以包含应用程序映像中不存在的用于设置的实用程序或自定义代码。例如，无需在安装过程中仅使用 sed、awk、python 或 dig 等工具来从另一个映像创建映像。

应用程序映像构建者和部署者角色可以独立工作，无需共同构建单个应用程序映像。

Init 容器可以使用与同一 Pod 中的应用程序容器不同的文件系统视图运行。因此，他们可以访问应用程序容器无法访问的 Secret。

由于 init 容器在任何应用程序容器启动之前运行完成，因此 init 容器提供了一种机制来阻止或延迟应用程序容器启动，直到满足一组先决条件。一旦满足先决条件，Pod 中的所有应用程序容器就可以并行启动。

Init 容器可以安全地运行实用程序或自定义代码，否则这些实用程序或自定义代码会降低应用程序容器映像的安全性。通过将不必要的工具分开，您可以限制应用程序容器映像的攻击面

这同样适用于在同一个 Pod 中运行的多个容器，它们可以安全地相互通信，而不会将该通信暴露给集群上的其他容器，因为它们将其保留在本地。