Kubernetes 部署 VS 状态集

我对 Kubernetes 做了很多调查我很喜欢我所看到的！有一件事我一直无法弄清楚，那就是 Deployment 和 StatuseSet 资源之间的确切区别，以及在哪些场景中可以使用这两种资源(或者一种通常优于另一种)。

110868 次浏览
小开
最佳答案

部署和 ReplicationController 用于无状态使用，并且相当轻量级。必须保持状态时使用 状态集。因此，后者对持久卷使用 volumeClaimTemplates/声明，以确保它们能够在组件重启时保持状态。

因此，如果您的应用程序是有状态的，或者如果您想在 Kubernetes 上部署有状态存储，请使用一个状态集。

如果您的应用程序是无状态的，或者在启动时可以从后端系统构建状态，那么请使用 Deployments。

有关运行有状态应用程序的详细信息可以在 2016年库伯内特关于有状态应用程序的博客条目中找到

小开

一切就绪

在有状态分布式应用程序中使用“状态集”，它要求每个节点都有一个 持续状态。状态集提供了通过配置(plicas = N)为有状态应用程序/组件配置任意数量的节点的能力。

有两种有状态分布式应用程序: 主-主和主-从。主-主配置中的所有节点和主-从配置中的从节点都可以使用状态集。
例子:
Hadoop 集群中的 Master-Slave-> Datanode (Slaves)
Cassandra 集群中的 Master-Master-> Database 节点(Master-Master) < br/>

状态集中的每个 Pod (复制/节点)都有一个惟一且稳定的网络标识。例如，在一个名为“ Cassandra”、副本节点数为 N 的 Cassandra StatuseSet 中，每个 Cassandra pod (节点)都有:

  • 每个荚的序数指数: 0,1，... ，N-1
  • 稳定网络 ID: Cassandra-0 Cassandra-1... Cassandra-N-1
  • 每个豆荚对应的单独持久体积 卷声明模板，即每个 pod (节点)的单独存储
  • 豆荚按0到 N-1的顺序创建，并按 N-1到0的相反顺序终止

参考: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

部署

另一方面，“部署”适用于节点不需要任何特殊标识的 无国籍应用程序/服务。负载均衡器可以到达它选择的任何节点。所有节点相等。部署对于通过配置(plicas = N)创建任意数量的节点非常有用。

小开

  • 部署-指定一个共享的 持续数量索赔 所有的豆荚复制品。换句话说，共享体积。

    后备存储器显然必须有 读写网或 如果您有多个副本 pod，请访问模式

  • 状态集-您指定一个 声明模板，以便每个副本吊舱获得一个唯一的 持续数量索赔相关联 换句话说，没有共享的卷。

    在这里，后台存储可以使用 读写网访问模式。

    StatueSet 对于在集群中运行非常有用，例如 Hadoop 每个节点都有自己的存储空间。

小开

DR

部署是部署无状态应用程序的资源，如果使用 PVC，所有副本将使用相同的卷，而且没有一个副本具有自己的状态。

Persistence in Deployment with Replicas

状态集用于有状态应用程序，每个荚的副本将有自己的状态，并将使用自己的卷。

Persistence in StatefulSets with Replicas

DaemonSet 是一个类似于 ReplicaSet 的控制器，它确保 pod 在集群的所有节点上运行。如果从集群中添加/删除节点，DaemonSet 会自动添加/删除 pod。

Persistence in Daemonsets

我已经详细介绍了 Deployments、 StatueSet 和 Daemonsets 之间的区别，以及如何使用这些参考资料 K8s: 部署 vs 状态集 vs 守护集部署示例应用程序。

小开

状态集和部署之间的区别

状态集相当于一个特殊的部署。StatuseSet 中的每个 pod 都有一个稳定的、唯一的网络标识符，可用于发现集群中的其他成员。如果状态集的名字是卡夫卡，那么第一个荚被称为卡夫卡 -0，第二个荚被称为卡夫卡 -1，以此类推; 由状态集控制的荚复制的开始和停止顺序被控制。当第 N 个吊舱运行时，第一个 N-1吊舱已经运行并准备就绪状态良好; StatuseSet 中的吊舱使用稳定的持久存储容量，通过 PV 或 PVC 实现。当删除 pod 时，默认情况下不会删除(为了数据安全起见)与 StatuseSet 关联的存储卷; StatuseSet 必须绑定到 PV 卷。用于存储吊舱状态数据，也与无头服务一起使用，声明为属于该无头服务;

小开

状态集与复制集的比较

Feature StatefulSets Deployment
国务院 全权负责 无国籍
定义 有状态应用程序: 有状态应用程序通常涉及一些数据库，如 Cassandra、 MongoDB 或 MySQL，并对其进行读和/或写操作。 通常，前端组件与后端有完全不同的伸缩需求，所以我们倾向于单独伸缩它们。更不用说像数据库这样的后端通常比(无状态的)前端 Web 服务器更难扩展。是的，术语“无状态”意味着在创建新容器时不存储过去的数据或状态，或者不需要持久化
行为 当一个有状态 pod 实例死亡(或者它所运行的节点失败)时，pod 实例需要在另一个节点上重新启动，新实例获得与它所替换的节点相同的名称、网络标识和状态。 Pod 副本由 Deployment 管理; 它们大多是无状态的，可以随时用一个全新的 Pod 副本替换它们。
吊舱机制 StatificSet 创建的 Pods 并不是彼此的精确复制品。每个卷都可以有自己的卷集ーー换句话说，就是存储(以及持久状态)ーー这使它与其它卷有所不同。 当一个 Deployment 替换了一个 pod 时，新 pod 是一个全新的 pod，有一个新的主机名和 IP
小开

什么是状态集？

它是专门用于有状态应用程序的 Kubernetes 组件。

什么是有状态应用程序？

任何存储数据以跟踪其状态的应用程序。或者我们可以说，通过在某些存储中保存信息来跟踪状态的应用程序。

有状态应用程序的例子是所有类型的数据库

  • MongoDB
  • MySQL
  • 弹性搜寻

部署 = = 无国籍

什么是无状态应用程序？

那些不需要保存以前请求和交互记录的应用程序将根据随之而来的信息作为完全新的和独立的应用程序进行处理。

部署有状态和无状态应用程序 有状态应用程序使用 Kubernetes 的 庄严肃穆组件进行部署。

无状态应用程序用于使用 部署组件 Kubernetes 进行部署。

  • 就像部署状态集使得复制应用程序吊舱或运行它的多个副本成为可能。

  • 您还可以使用相同的方式同等地配置这两种存储方式。

那么，Statefulset 和 Deployment 之间有什么区别，或者为什么我们应该对每种类型的应用程序使用不同的版本

状态集 vs 部署

  • 复制有状态应用程序更加困难，并且有一些无状态应用程序不具备的要求。

我们来讨论一个例子

假设我们有一个 MongoDB pod，它可以处理来自 NodeJs 应用 pod 的请求，这些请求是使用部署部署的。假设我们将 NodeJs 应用程序 pod 从1扩展到3，这样它们可以处理更多的客户端请求，并行地，您扩展 MongoDB pod，这样它们可以处理更多的 NodeJs 请求。

扩展是您的 NodeJs 应用程序是非常简单的，pods 将是相同的和可互换的，因此扩展部署是非常容易的。部署将以任意随机顺序创建 pods，并且它们将在 pods 名称 NodeApp-f5cdee、 NodeApp-fasx34、 NodeApp-ax7jds的末尾获得随机散列。

部署将获得一个 svc，它可以帮助任何请求的任何吊舱实现负载平衡。

当您删除或缩小部署时，他们将同时以任意顺序删除它们。

如果我们谈论的 MongoDB pod 副本部署使用状态集不能创建和删除同时在任何顺序和不能随机地址。这背后的原因是，状态集的复制豆荚并不完全相同，因为它们每个都有自己的附加身份。

注意: 为每个 pod 提供其所需的标识可以区分有状态和部署

状态集为每个豆荚维护一个粘性标识，因此 它们是根据相同的规范创建的，但是不能互换！

它在任何重新调度过程中都有一个持久的标识符，这意味着当一个吊舱死亡时，它将被一个新的吊舱替换，并保持相同的标识。

但是为什么这个身份是必要的呢？

如果我们讨论一个 MongoDB pod，它过去同时读写数据，但是如果你添加 MongoDB 的第二个 pod，它的作用就不一样了，因为如果我们允许 MongoDB 的实例更改数据，那么最终会导致数据不一致。

因此，有一种机制决定只允许 pod 写入或更改数据，这些数据被多个 MongoDB 实例共享用于读取，所以允许更改数据的 pod 被称为 师父，其他的被称为 奴隶。

注意: 主存储器和从存储器不使用相同的物理存储器，即使它们使用相同的数据。

分离舱身份

  • 在有状态模式下，每个 pod 都有自己的标识符，并获得固定顺序的名称，但在部署的情况下并不相同。

  • 如果我们创建一个3的饱和集副本，那么它将创建像 MongoDB-0，MongoDB-1，MongoDB-2这里的第一个是主人在下一个是奴隶。

注意: 状态集将不会在前一个 pod 的副本中创建下一个 pod，因为它还没有运行，并且删除的顺序也是相同的，但是顺序是相反的。

分离舱端点

  • 状态集中的每个 pod 都从服务获得自己的 DNS 端点。

所以最后我们可以说 Statefetset 应用程序有2个字符

  1. 可预测的豆荚名称
  2. 固定个人 DNS 名称

当吊舱重新启动时，IP 地址将发生变化，但名称和端点仍然相同。


提交答案