吊舱和部署的区别是什么?

我一直在用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，您可以更改任何您想更改的配置部分，并且不必担心看到错误消息。

2019-03-21 12:44:53

其他回答

我想从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一书。

2020-03-06 19:35:41

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

2019-03-14 10:40:30