我一直在用type:deployment创建pod，但我看到一些文档使用type:pod，更具体地说，多容器pod的文档:
apiVersion: v1
kind: Pod
metadata:
name: ""
labels:
name: ""
namespace: ""
annotations: []
generateName: ""
spec:
? "// See 'The spec schema' for details."
: ~
但是要创建pod，我可以使用部署类型:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ""
spec:
replicas: 3
template:
metadata:
labels:
app: ""
spec:
containers:
etc
我注意到pod文档说:
The create command can be used to create a pod directly, or it can
create a pod or pods through a Deployment. It is highly recommended
that you use a Deployment to create your pods. It watches for failed
pods and will start up new pods as required to maintain the specified
number. If you don’t want a Deployment to monitor your pod (e.g. your
pod is writing non-persistent data which won’t survive a restart, or
your pod is intended to be very short-lived), you can create a pod
directly with the create command.
Note: We recommend using a Deployment to create pods. You should use
the instructions below only if you don’t want to create a Deployment.
但这就提出了一个问题:豆荚适合哪一种?你能在部署中引用pod吗?我不知道该怎么办。看起来你从pods中得到的是一些额外的元数据，但没有任何部署选项，如副本或重启策略。一个不保存数据的吊舱在重启后还能存活，这有什么用呢?我认为我能够创建一个多容器pod部署以及。
Kubernetes有三种你应该知道的对象类型:
pod -运行一个或多个紧密相关的容器
服务——在Kubernetes集群中建立网络
部署——维护一组相同的pod，确保它们具有正确的配置，并且存在正确的数量。
豆荚:
运行一组容器
适合一次性开发目的
很少直接用于生产
部署:
运行一组相同的豆荚
监视每个pod的状态，必要时进行更新
对开发者有利
有利于生产
我同意其他的答案，忘掉Pods，使用Deployment。为什么?看看第二个要点，它监视每个pod的状态，并根据需要进行更新。
因此，与其纠结于这样的错误消息:
禁止:pod更新不能改变spec.containers[*].image以外的字段
因此，只需重构或完全重新创建您的Pod到一个部署，创建一个Pod来做您需要做的事情。使用Deployment，您可以更改任何您想更改的配置部分，并且不必担心看到错误消息。
Radek的回答非常好，但我想从我的经验中提出，你几乎永远不会使用带有这种豆荚的对象，因为这在实践中没有任何意义。
因为你需要一个部署对象——或者其他Kubernetes API对象，比如复制控制器或复制集——来保持副本(pod)的活动(这就是使用Kubernetes的意义)。
在一个典型的应用程序中，您将使用的是:
部署对象(你将在其中指定你的应用程序容器/容器)，它将承载你的应用程序的容器与一些其他规格。
服务对象(类似于分组对象，并为具有特定标签的pods提供所谓的虚拟IP(集群IP) -这些pods基本上是您与前一个部署对象一起部署的应用程序容器)。
您需要有service对象，因为部署对象中的pod可以被杀死、扩展和缩小，而且您不能依赖于它们的IP地址，因为它们不是持久的。
所以你需要一个像服务这样的对象，给这些pod一个稳定的IP。
只是想给你一些关于pod的背景知识，这样你就知道它们是如何一起工作的。
希望这为你澄清了一些事情，不久以前我也是你的处境:)
我想从Kubernetes In Action book中添加一些信息，这样你就可以看到所有的图片和Kubernetes资源之间的联系，如Pod, Deployment和ReplicationController(ReplicaSet)
豆荚
是Kubernetes的基本可部署单位。但在实际用例中，您希望部署能够自动运行，并且在没有任何手动干预的情况下保持健康。为此，推荐的方法是使用Deployment，它在底层创建一个ReplicaSet。
顾名思义，ReplicaSet是一组副本(pod)，使用它们的Revision历史进行维护。
(ReplicaSet扩展了一个叫做ReplicationController的旧对象——它完全相同，但没有Revision历史。)
ReplicaSet不断监视正在运行的pod列表，并确保与特定规格匹配的pod的运行数量始终与所需的数量相匹配。
Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might
have a bug that causes your pod to start behaving badly after a specific amount
of time or a specific event.
部署
是用于部署应用程序并以声明方式更新它们的高级资源。
当您创建一个Deployment时，将在下面创建一个ReplicaSet资源(最终会创建更多的ReplicaSet资源)。ReplicaSets也可以复制和管理pod。当使用部署时，实际的pod由部署的ReplicaSets创建和管理，而不是由部署直接创建和管理
让我们想想发生了什么。通过更改部署资源中的pod模板，您已经将应用程序更新到一个新版本—通过更改单个字段!
最后，使用部署资源可以很容易地将部署回滚到以前的修订或任何早期的修订。
这些图片也来自Kubernetes In Action一书。
在kubernetes中，pod是最小的可部署单元。每次当我们创建一个kubernetes对象，比如deployment, replica-sets, statefulsets, daemonsets，它都会创建pod。
如上所述，部署根据部署对象中提到的所需状态创建pod。例如，你需要一个应用程序的5个副本，你在部署清单中提到了副本:5。现在，部署控制器负责为给定的应用程序创建5个相同的副本(不少也不多)，其中包含所有元数据，如RBAC策略、网络策略、标签、注释、健康检查、资源配额、污染/容差等，并与它创建的每个pod关联。
在某些情况下，当你想要创建pod时，例如，如果你正在运行一个测试sidecar，你不需要永远运行应用程序，你不需要多个副本，当你想在pod适合的情况下执行时，你就运行应用程序。例如helm test，这是一个pod定义，它指定了一个包含要运行的给定命令的容器。
