Pod和部署之间有什么区别？

我一直在创建Pod，type:deployment但是我看到一些文档使用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文档说：

create命令可用于直接创建容器，也可以通过部署创建一个或多个容器。强烈建议您使用展开来创建Pod。它会监视出现故障的Pod，并将根据需要启动新的Pod以维持指定的数量。如果您不希望部署监视您的Pod（例如，您的Pod正在写入无法持久重启的非持久数据，或者您的Pod寿命很短），则可以直接使用以下方法创建Pod创建命令。

注意：我们建议使用展开来创建容器。仅当您不想创建展开时，才应使用以下说明。

但这提出了一个kind:pod有益的问题？您能以某种方式引用部署中的Pod吗？我没找到办法。似乎您从Pod中获得的是一些额外的元数据，但是没有部署选项，例如replica重启策略。不保留数据，在重启后仍然存活的Pod有什么好处？我想我也可以通过部署创建一个多容器吊舱。

Pod和Deployment都是Kubernetes API中的成熟对象。部署通过副本集管理创建Pod。归结为，Deployment将使用从模板中获取的规范创建Pod。您不太可能需要直接为生产用例创建Pod。

拉狄克的答案是很不错的，但我想在球场从我的经验，你将几乎从来不使用的对象与种类 吊舱，因为这并不在实践中任何意义。

因为您需要一个部署对象-或其他Kubernetes API对象（例如复制控制器或副本集） -需要使副本（容器）保持活动状态（这就是使用kubernetes的重点）。

在实践中，您将对典型应用程序使用的是：

1. 部署对象（您将在其中指定应用程序容器的容器），它将托管您的应用程序容器以及其他一些规范。

2. 服务对象（就像一个分组对象，并为它提供所谓的虚拟IP（群集IP），该对象pods具有一定的标签-这些pods基本上是您与前一个部署对象一起部署的应用程序容器）。

您需要服务对象，因为pods部署对象中的from可以被杀死，放大和缩小，并且您不能依赖于它们的IP地址，因为它们不会持久。

因此，您需要像service这样的对象，该对象可以为这些对象提供pods稳定的IP。

只是想为您提供一些背景信息pods，因此您知道事情是如何协同工作的。

希望不久之后我就可以穿上鞋子了：)

Kubernetes具有三种您应该了解的对象类型：

• 荚 -运行一个或多个密切相关的容器
• 服务 -在Kubernetes集群中设置网络
• 部署 -维护一组相同的Pod，确保它们具有正确的配置并存在正确的数目。

豆荚：

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

部署：

• 运行一组相同的Pod
• 监视每个吊舱的状态，并根据需要进行更新
• 对开发人员有好处
• 适合生产

我会同意其他答案，而无需考虑Pods，只需使用Deployment。为什么？查看第二个要点，它监视每个pod的状态，并根据需要进行更新。

因此，而不是像这样的错误消息而苦苦挣扎：

禁止：广告连播更新不得更改除以下字段以外的其他字段 spec.containers[*].image

因此，只需将Pod重构或完全重新创建到Deployment中即可创建一个Pod来完成您需要完成的工作。通过部署，您可以更改所需的任何配置，而不必担心看到该错误消息。

Pod是容器实例。

那是输出 replicas: 3

想一想deployment可以有很多正在运行的实例（副本）。

//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

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

• 不适合生产
• 没有滚动更新

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

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

部署创建一个ReplicaSet，该副本集又确保CurrentReplicas始终与期望的Replicas相同。

优点 ：

• 您可以使用部署来回滚和回滚更改
• 监控每个吊舱的状态
• 最适合生产
• 支持滚动更新

我想从Kubernetes In Action书中添加一些信息，以便您可以看到所有图片并连接Kubernetes资源（例如Pod，Deployment和ReplicationController（ReplicaSet））之间的关系

豆荚

是Kubernetes中的基本可部署单元。但是在实际的用例中，您希望您的部署能够自动保持运行状态并保持健康，而无需任何手动干预。为此，建议的方法是使用Deployment，在内部创建一个ReplicaSet。

一个ReplicaSet，顾名思义，是一组与他们保持副本（荚）的修订历史。

（ReplicaSet扩展了一个名为ReplicationController的旧对象，该对象完全相同，但没有修订历史记录。）

ReplicaSet会持续监视正在运行的容器的列表，并确保与特定规格匹配的容器的运行数目始终与所需数目匹配。

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资源（最终会创建更多资源）。 ReplicaSets也可以复制和管理Pod。使用Deployment时，实际的Pod是由Deployment的ReplicaSets创建和管理的，而不是由Deployment直接 创建和管理的。

让我们考虑发生了什么。通过更改部署资源中的Pod模板，您可以通过更改单个字段将应用程序更新为较新的版本！

最后，使用“部署”资源可以轻松地将“部署” 回滚到以前的版本或任何较早的版本。

这些图像也来自Kubernetes In Action书中。

尝试避免使用Pod并实施Deployments来管理容器，因为在节点故障或pod终止的情况下，Pod类型的对象不会重新安排（或自我修复）。

通常最好使用Deployment，因为它定义了ReplicaSet以确保所需数量的Pod始终可用，并指定了替换Pod的策略，例如RollingUpdate。

在kubernetes中，Pod是最小的可部署单元。每当我们创建一个Kubernetes对象（如Deployments，副本集，statefulsets，daemonsets）时，它都会创建pod。

如上所述，部署根据部署对象中提到的所需状态创建容器。因此，例如，您需要一个应用程序的5个副本，您replicas: 5在部署清单中提到了该副本。现在，部署控制器负责为给定应用程序创建5个相同的副本（不少于更多），其中包含所有元数据，如RBAC策略，网络策略，标签，注释，运行状况检查，资源配额，污点/容忍度等，并与每个pod关联它创建。

在某些情况下，您想创建pod，例如，如果您正在运行测试边车，则不需要永远运行应用程序，不需要多个副本，并且可以在其中执行应用程序时运行案例豆荚是合适的。例如helm test，这是一个pod定义，用于指定要运行给定命令的容器。