Pod和Deployment都是Kubernetes API中成熟的对象。部署通过ReplicaSets管理创建pod。归结起来，部署将使用模板中的规格创建Pods。您不太可能需要直接为生产用例创建pod。

Radek的回答非常好，但我想从我的经验中提出，你几乎永远不会使用带有这种豆荚的对象，因为这在实践中没有任何意义。

因为你需要一个部署对象——或者其他Kubernetes API对象，比如复制控制器或复制集——来保持副本(pod)的活动(这就是使用Kubernetes的意义)。

在一个典型的应用程序中，您将使用的是:

部署对象(你将在其中指定你的应用程序容器/容器)，它将承载你的应用程序的容器与一些其他规格。 服务对象(类似于分组对象，并为具有特定标签的pods提供所谓的虚拟IP(集群IP) -这些pods基本上是您与前一个部署对象一起部署的应用程序容器)。

您需要有service对象，因为部署对象中的pod可以被杀死、扩展和缩小，而且您不能依赖于它们的IP地址，因为它们不是持久的。

所以你需要一个像服务这样的对象，给这些pod一个稳定的IP。

只是想给你一些关于pod的背景知识，这样你就知道它们是如何一起工作的。

希望这为你澄清了一些事情，不久以前我也是你的处境:)

尽量避免使用Pods，而是使用deployment来管理容器，因为在节点故障或Pod终止时，Pod将不会被重调度(或自修复)。

部署通常更可取，因为它定义了一个ReplicaSet，以确保所需数量的pod始终可用，并指定了替换pod的策略，例如RollingUpdate。

在kubernetes中，pod是最小的可部署单元。每次当我们创建一个kubernetes对象，比如deployment, replica-sets, statefulsets, daemonsets，它都会创建pod。

如上所述，部署根据部署对象中提到的所需状态创建pod。例如，你需要一个应用程序的5个副本，你在部署清单中提到了副本:5。现在，部署控制器负责为给定的应用程序创建5个相同的副本(不少也不多)，其中包含所有元数据，如RBAC策略、网络策略、标签、注释、健康检查、资源配额、污染/容差等，并与它创建的每个pod关联。

在某些情况下，当你想要创建pod时，例如，如果你正在运行一个测试sidecar，你不需要永远运行应用程序，你不需要多个副本，当你想在pod适合的情况下执行时，你就运行应用程序。例如helm test，这是一个pod定义，它指定了一个包含要运行的给定命令的容器。

Pod是容器实例。

这是副本的输出:3

设想一个部署可以有许多正在运行的实例(副本)。

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Kubernetes有三种你应该知道的对象类型:

pod -运行一个或多个紧密相关的容器 服务——在Kubernetes集群中建立网络 部署——维护一组相同的pod，确保它们具有正确的配置，并且存在正确的数量。

豆荚:

运行一组容器 适合一次性开发目的 很少直接用于生产

部署:

运行一组相同的豆荚 监视每个pod的状态，必要时进行更新 对开发者有利 有利于生产

我同意其他的答案，忘掉Pods，使用Deployment。为什么?看看第二个要点，它监视每个pod的状态，并根据需要进行更新。

因此，与其纠结于这样的错误消息:

禁止:pod更新不能改变spec.containers[*].image以外的字段

因此，只需重构或完全重新创建您的Pod到一个部署，创建一个Pod来做您需要做的事情。使用Deployment，您可以更改任何您想更改的配置部分，并且不必担心看到错误消息。

Pod是Kuberntes的容器集合和基本对象。pod的所有容器位于同一节点上。

不适合生产 没有滚动更新

部署是Kubernetes中的一种控制器。

控制器使用您提供的Pod模板来创建它负责的Pod。

部署创建了一个ReplicaSet，它反过来确保， CurrentReplicas始终与desired dreplicas相同。

优点:

可以使用部署推出和回滚更改 监视每个豆荚的状态 最适合生产 支持滚动更新

我想从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

我也是k8s的初学者，如果我错了请纠正我。

我们知道在创建部署时创建了一个pod。我观察到的是，如果看到部署的YAML文件，就可以看到它的类型:deployment。但是如果您看到pod的YAML文件，则会看到它的类型:pod。

在Kubernetes中，我们可以使用不同类型的API对象来部署我们的工作负载，比如Pods、Deployment、ReplicaSet、ReplicationController和StatefulSets。

这些pod是Kubernetes中最小的可部署单元。任何在Kubernetes中运行的工作负载/应用程序都必须在Pod的容器部分中运行。Pod可以在其中运行多个容器(即多个应用程序)。Pod是一个或多个运行容器之上的包装器。使用Pod, kubernetes可以控制、监控和操作容器。

Now using stand alone Pods we can't do lot of things. We can't change configurations, volumes inside Pods. We can't restart the Pod if one is down. So there is another API Object called Deployment comes into picture which maintains the desired state (how many instances, how much compute resource application uses) of the application. The Deployment maintaines multiple instances of same application by running multiple Pods. Deployments unlike Pods are mutable. Deployments uses another API Object called ReplicaSet to maintain the desired state. Deployments through ReplicaSet spawns another Pod if one is down.

所以Pod在容器中运行应用程序。部署运行Pods并维护应用程序所需的状态。