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

我一直在用type:deployment创建pod，但我看到一些文档使用type: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。它会观察失败 并根据需要启动新的吊舱，以维护指定的吊舱 号码。如果你不想让Deployment监视你的pod(例如你的 Pod正在写入重启后无法保存的非持久数据，或者 您的豆荚的寿命非常短)，您可以创建一个豆荚

注意:我们建议使用Deployment来创建pods。你应该使用

.

.

.

但这就提出了一个问题:kind:pod有什么用?你能在部署中引用pod吗?我不知道该怎么办。看起来你从pods中得到的是一些额外的元数据，但没有部署选项，如replica或重启策略。一个不保存数据的吊舱在重启后还能存活，这有什么用呢?我认为我能够创建一个多容器pod部署以及。

110756 次浏览
小开
最佳答案

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

小开

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

因为你需要一个部署对象-或其他Kubernetes API对象，如复制控制器或replicaset -需要保持副本 (pods)存活(这是使用Kubernetes的意义)。

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

  1. 部署对象(你将指定你的应用程序容器/容器)，它将承载你的应用程序的容器与一些其他规格。

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

你需要有服务对象，因为部署对象中的pods可以被杀死、放大或缩小，而且你不能依赖它们的IP地址，因为它们不是持久的。

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

只是想给你一些关于pods的上下文，这样你就知道它们是如何一起工作的。

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

小开

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

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

小开

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

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

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

小开

Pod是容器实例。

enter image description here

这是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
小开

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

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

豆荚:

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

部署:

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

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

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

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

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

小开

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

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

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

控制器使用您提供的Pod模板来创建它负责的Pod。 < /代码> < / p >

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

优点:

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

我想从Kubernetes在行动书中添加一些信息，这样你就可以看到所有的图片和Kubernetes资源之间的连接关系，如Pod, Deployment和ReplicationController(ReplicaSet)

豆荚

是Kubernetes的基本可部署单位。但在实际用例中，您希望部署能够自动运行，并且在没有任何手动干预的情况下保持健康。为此，推荐的方法是使用部署，它在底层创建ReplicaSet。

ReplicaSet，顾名思义，是一组用它们的修订历史维护的副本(Pods)。

(ReplicaSet扩展了一个名为ReplicationController的旧对象——它完全相同，但没有Revision历史记录。)

ReplicaSet不断监视正在运行的pod列表，并确保与特定规格匹配的pod的运行数量始终与所需的数量相匹配。

enter image description here

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.

一个部署

是用于部署应用程序并以声明方式更新它们的高级资源。

当你创建一个部署时，会在下面创建一个ReplicaSet资源(最终会有更多)。ReplicaSets复制和管理pods，以及。当使用Deployment时，实际的pods由部署的ReplicaSets创建和管理，而不是直接由部署创建和管理 enter image description here < / p >

让我们想想发生了什么。通过更改部署资源中的pod模板，您已经将应用程序更新到一个新版本—通过更改单个字段!

enter image description here

最后，回滚部署可以转换为以前的修订版，也可以转换为任何更早的修订版。

这些图片也来自Kubernetes在行动书。

小开

也许这个例子对初学者会有帮助!!

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文件，你可以看到它的:部署。但是如果你看到pod的YAML文件，你会看到它的:豆荚。

小开

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

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

现在使用独立舱，我们不能做很多事情。我们不能改变舱内的配置和体积。如果有一个坏了，我们无法重启花苞。 因此，有另一个名为部署的API对象出现，它维护应用程序的期望状态(有多少实例，应用程序使用多少计算资源)。部署通过运行多个pod来维护同一个应用程序的多个实例。与Pods不同，部署是可变的。部署使用另一个称为ReplicaSet的API对象来维护所需的状态。

.通过ReplicaSet进行部署，如果其中一个Pod关闭，则会生成另一个Pod

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


提交答案