在kubernetes中,pod和部署之间有什么区别？

Question

我一直在创建pods,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,也可以通过Deployment创建pod或pod.强烈建议您使用部署来创建pod.它会监视失败的pod,并根据需要启动新的pod以维持指定的数量.如果您不希望部署监视您的pod(例如,您的pod正在编写无法重新启动的非持久性数据,或者您的pod非常短暂),则可以直接创建一个pod create命令.

注意:我们建议使用"部署"来创建窗格.仅当您不想创建部署时,才应使用以下说明.

但这提出了什么kind:pod是有益的问题？你能以某种方式参考部署中的pod吗？我没有看到办法.看起来你使用pod获得的是一些额外的元数据,但没有任何部署选项,例如replica重启策略.没有持久数据的pod有什么用,可以在重启后幸存下来？我想我也可以创建一个带有部署的多容器pod.

Answer 1

拉德克的回答非常好,但是我想从我的经验中汲取教训,你几乎从不使用带有这种吊舱的物体,因为这在实践中没有任何意义.

因为您需要一个部署对象 - 或其他Kubernetes API对象,如复制控制器或复制集 - 需要保持副本(pod)活着(这是使用kubernetes的一种方式).

您将在实践中用于典型应用的是:

1. 部署对象(您将指定您的应用程序容器/容器),它将托管您的应用程序容器以及其他一些规范.

2. 服务对象(就像分组对象一样,为pods具有特定标签的虚拟IP(集群IP)提供所谓的虚拟IP(集群IP)- 这些pods基本上就是您使用前部署对象部署的应用程序容器).

您需要拥有服务对象,因为pods部署对象可以被杀死,扩展和缩小,并且您不能依赖它们的IP地址,因为它们不会持久化.

所以你需要一个像服务这样的对象来为那些人pods提供稳定的IP.

只想给你一些背景知识pods,让你知道事情是如何协同工作的.

希望能为你清除一些东西,不久前我还在你的鞋子里:)

Answer 2

Pod和Deployment都是Kubernetes API中的完整对象.部署通过ReplicaSet管理创建Pod.它归结为部署将使用模板中的规范创建Pod.您不太可能需要直接为生产用例创建Pod.

Answer 3

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

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

豆荚：

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

部署：

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

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

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

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

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

Answer 4

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

Answer 5

I want to add some informations from Kubernetes In Action book, so you can see all picture and connect relation between Kubernetes resources like Pod, Deployment and ReplicationController(ReplicaSet)

Pods

are the basic deployable unit in Kubernetes. But in real-world use cases, you want your deployments to stay up and running automatically and remain healthy without any manual intervention. For this the recommended approach is to use a Deployment, which under the hood create a ReplicaSet.

A ReplicaSet, as the name implies, is a set of replicas (Pods) maintained with their Revision history.

(ReplicaSet extends an older object called ReplicationController -- which is exactly the same but without the Revision history.)

A ReplicaSet constantly monitors the list of running pods and makes sure the running number of pods matching a certain specification always matches the desired number.

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.

A Deployment

is a higher-level resource meant for deploying applications and updating them declaratively.

When you create a Deployment, a ReplicaSet resource is created underneath (eventually more of them). ReplicaSets replicate and manage pods, as well. When using a Deployment, the actual pods are created and managed by the Deployment’s ReplicaSets, not by the Deployment directly

Let’s think about what has happened. By changing the pod template in your Deployment resource, you’ve updated your app to a newer version—by changing a single field!

Finally, Roll back a Deployment either to the previous revision or to any earlier revision so easy with Deployment resource.

These images are from Kubernetes In Action book, too.

Answer 6

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

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

现在使用独立的 Pod，我们无法做很多事情。我们无法更改 Pod 内的配置和卷。如果 Pod 宕机，我们无法重新启动。因此，出现了另一个称为Deployment的 API 对象，它可以维护所需的状态（有多少实例、应用程序使用了多少计算资源）。Deployment 通过运行多个 Pod 来维护同一应用程序的多个实例。与 Pod 不同，部署是可变的。部署使用另一个名为 ReplicaSet 的 API 对象来维护所需的状态。如果一个 Pod 宕机，通过 ReplicaSet 进行的部署会生成另一个 Pod。

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

Answer 7

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

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

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

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

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

好处 ：

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