请有人向我解释（或直接转到详细资源）为什么kubernetes使用此包装器（pod）处理容器。我遇到的每个资源都引用相同的词-“它是k8s中最小的单位”。从工程角度来看，我正在寻找它的原因。我确实知道它为内部容器的存储和联网提供了名称空间，但是最佳实践是始终将单个容器保持在Pod中。
docker-compose在熟悉k8之前，我已经花了很多时间，并且很难理解围绕非常简单的实体，容器这一额外层（包装）的需求。
做出此决定的原因仅仅是因为Pod可能包含多个容器，而它们在做不同的事情。
首先，吊舱可能具有一个初始化容器，该容器负责执行一些启动操作以确保一个或多个主容器正常工作。我可以让一个初始化容器加载一些配置并为主应用程序准备它，或者执行一些基本操作，例如还原备份或类似的东西。
在启动主应用程序之前，我基本上可以注入一系列要执行的操作，而无需再次构建主应用程序容器映像。
其次，即使大多数应用程序非常好，只有一个容器用于Pod，在几种情况下，同一Pod中不止一个容器也可能有用。
一个示例可能是运行主应用程序，然后是在主应用程序前面做代理的侧车容器，它可能负责检查JWT令牌。或者另一个示例可能是辅助应用程序从主应用程序提取指标应用程序或类似的东西。
最后，让我引用Kubernetes文档（https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/）
Pods可以具有多个容器的主要原因是为了支持辅助主应用程序的助手应用程序。辅助应用程序的典型示例是数据提取器，数据推送器和代理。帮助程序和主应用程序经常需要相互通信。通常，这是通过共享文件系统（如本练习所示）或通过回送网络接口localhost来完成的。这种模式的一个示例是Web服务器以及帮助程序，该程序轮询Git存储库以获取新更新。
更新资料
就像您说的那样，不必一定要使用init容器或同一Pod中的多个容器，我列出的所有功能也可以通过其他方式获得，例如en入口点或两个相互通信的Pod而不是两个容器在同一个Pod中。
使用这些功能有很多好处，让我再次引用Kubernetes文档（https://kubernetes.io/docs/concepts/workloads/pods/init-containers/）
由于初始化容器具有与应用程序容器不同的图像，因此它们在启动相关代码方面具有一些优势：
初始化容器可以包含应用程序映像中不存在的实用程序或用于设置的自定义代码。例如，无需在安装过程中仅使用sed，awk，python或dig之类的工具从另一张图像制作图像。
应用程序映像构建器和部署者角色可以独立工作，而无需共同构建单个应用程序映像。
初始化容器可以使用与同一Pod中的应用程序容器不同的文件系统视图运行。因此，可以授予他们访问应用程序容器无法访问的秘密的权限。
由于init容器在任何应用程序容器启动之前便已运行完毕，因此init容器提供了一种机制来阻止或延迟应用程序容器的启动，直到满足一系列前提条件为止。满足先决条件后，即可并行启动Pod中的所有应用程序容器。
初始化容器可以安全地运行实用程序或自定义代码，否则它们会使应用程序容器映像的安全性降低。通过分离不必要的工具，可以限制应用程序容器映像的攻击面
这同样适用于在同一Pod中运行的多个容器，它们可以彼此安全地通信，而不会将该通信暴露给集群中的其他容器，因为它们将其保持在本地。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句