我一直在用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部署以及。
Radek的回答非常好，但我想从我的经验中提出，你几乎永远不会使用带有这种豆荚的对象，因为这在实践中没有任何意义。
因为你需要一个部署对象——或者其他Kubernetes API对象，比如复制控制器或复制集——来保持副本(pod)的活动(这就是使用Kubernetes的意义)。
在一个典型的应用程序中，您将使用的是:
部署对象(你将在其中指定你的应用程序容器/容器)，它将承载你的应用程序的容器与一些其他规格。
服务对象(类似于分组对象，并为具有特定标签的pods提供所谓的虚拟IP(集群IP) -这些pods基本上是您与前一个部署对象一起部署的应用程序容器)。
您需要有service对象，因为部署对象中的pod可以被杀死、扩展和缩小，而且您不能依赖于它们的IP地址，因为它们不是持久的。
所以你需要一个像服务这样的对象，给这些pod一个稳定的IP。
只是想给你一些关于pod的背景知识，这样你就知道它们是如何一起工作的。
希望这为你澄清了一些事情，不久以前我也是你的处境:)
在kubernetes中，pod是最小的可部署单元。每次当我们创建一个kubernetes对象，比如deployment, replica-sets, statefulsets, daemonsets，它都会创建pod。
如上所述，部署根据部署对象中提到的所需状态创建pod。例如，你需要一个应用程序的5个副本，你在部署清单中提到了副本:5。现在，部署控制器负责为给定的应用程序创建5个相同的副本(不少也不多)，其中包含所有元数据，如RBAC策略、网络策略、标签、注释、健康检查、资源配额、污染/容差等，并与它创建的每个pod关联。
在某些情况下，当你想要创建pod时，例如，如果你正在运行一个测试sidecar，你不需要永远运行应用程序，你不需要多个副本，当你想在pod适合的情况下执行时，你就运行应用程序。例如helm test，这是一个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一书。
也许这个例子对初学者会有帮助!!
1)列出PODs
controlplane $ kubectl -n my-namespace get pods
NAME READY STATUS RESTARTS AGE
mysql 1/1 Running 0 92s
webapp-mysql-75dfdf859f-9c54j 1/1 Running 0 92s
2)删除web-app pode -这是使用部署创建
controlplane $ kubectl -n my-namespace delete pod webapp-mysql-75dfdf859f-9c54j
pod "webapp-mysql-75dfdf859f-9c54j" deleted
3)列出PODs(你可以看到，它是自动重新创建的)
controlplane $ kubectl -n my-namespace get pods
NAME READY STATUS RESTARTS AGE
mysql 1/1 Running 0 2m42s
webapp-mysql-75dfdf859f-mqrcx 1/1 Running 0 45s
4)删除直接创建的mysql POD(无需部署)
controlplane $ kubectl -n my-namespace delete pod mysql
pod "mysql" deleted
5)列出POD(你可以看到mysql POD永远丢失了)
controlplane $ kubectl -n my-namespace get pods
NAME READY STATUS RESTARTS AGE
webapp-mysql-75dfdf859f-mqrcx 1/1 Running 0 76s
