Understanding ReplicaSet vs. StatefulSet vs. DaemonSet vs. Deployments

了解 ReplicaSet、StatefulSet、DaemonSet 与 Deployments

转载来源：https://semaphoreci.com/blog/replicaset-statefulset-daemonset-deployments

When you begin learning about Kubernetes, you hear about the different types of sets it supports and start wondering about their differences. 当您开始学习 Kubernetes 时，您会听说它支持的不同类型的集，并开始想知道它们的差异。

Understanding the nuances and distinctions between these key concepts becomes crucial as you navigate the complex — yet rewarding — waters of container orchestration. 当您在复杂但有益的容器编排领域中航行时，了解这些关键概念之间的细微差别和区别变得至关重要。

In this blog, I am going to go over each type and explain the differences between them, so that you can understand how exactly we use each set, how they differ from each other, and the purpose that each serves. 在这篇博客中，我将详细介绍每种类型并解释它们之间的差异，以便您可以了解我们如何准确地使用每种类型、它们之间有何不同以及每种类型的用途。

Prerequisites: A beginner-level familiarity with Kubernetes and its purpose will be enough to understand the details of this blog. This blog’s audience is both expert professionals and beginners. Have fun reading 😄. 先决条件：初学者熟悉 Kubernetes 及其用途就足以理解本博客的详细信息。该博客的受众既有专业人士，也有初学者。祝阅读愉快。

Kubernetes Controllers Kubernetes 控制器

Each of these sets is what’s called a Kubernetes object. More specifically, they’re called Kubernetes controllers. A controller’s job is to monitor the current state of a resource such as pods or services and take action to ensure that the desired state is achieved. 这些集合中的每一个都是所谓的 Kubernetes 对象。更具体地说，它们被称为 Kubernetes 控制器。控制器的工作是监视 Pod 或服务等资源的当前状态，并采取措施确保达到所需的状态。 Each controller manages a specific type of Kubernetes resource. 每个控制器管理特定类型的 Kubernetes 资源。

Controllers use the Kubernetes API to monitor the state of a particular resource and then perform actions such as scaling, updating, or deleting resources. They are implemented as a loop that monitors for changes in the resource and makes changes if necessary. 控制器使用 Kubernetes API 监视特定资源的状态，然后执行扩展、更新或删除资源等操作。它们被实现为一个循环，监视资源的变化并在必要时进行更改。

The controllers mentioned in this article are built into the Kubernetes system with the difference between them being that each of these solves a unique use case. Let’s start with the first one: the ReplicaSet. 本文中提到的控制器内置于 Kubernetes 系统中，它们之间的区别在于每个控制器都解决一个独特的用例。让我们从第一个开始：ReplicaSet。

ReplicaSets 副本集

Introduction 介绍

The simplest unit in Kubernetes is the pod. We run our containers inside the pod. Say you’ve deployed your app inside a pod and you’re now getting huge traffic. So much that your single pod instance can’t handle it. How do you take care of that? Enter ReplicaSet. Kubernetes 中最简单的单元是 Pod。我们在 Pod 内运行容器。假设您已将应用程序部署在 Pod 内，并且现在获得了巨大的流量。以至于您的单个 Pod 实例无法处理它。你怎么处理这个？输入副本集。 A ReplicaSet helps manage traffic by scaling your application to have multiple instances of the same pod. This helps reduce traffic to one particular instance and also helps in load-balancing traffic between each of these instances. ReplicaSet 通过扩展应用程序以拥有同一 Pod 的多个实例来帮助管理流量。这有助于减少某个特定实例的流量，还有助于在每个实例之间实现负载平衡流量。

Sample manifest 舱单样本

Based on your application’s needs you get to scale the number of instances for your pods easily. Let’s look at what a sample manifest file would look like: 根据您的应用程序的需求，您可以轻松扩展 Pod 的实例数量。让我们看看示例清单文件是什么样子的：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

This manifest defines a ReplicaSet for an application callednginx, with three replicas. The pod template specifies a container named nginx using the nginx:1.14.2 image, listening on port 80. The ReplicaSet ensures that there are always three replicas of the pod running and available, labeled with app: nginx. 此清单为名为 nginx 的应用程序定义了一个具有三个副本的 ReplicaSet。 Pod 模板使用 nginx:1.14.2 镜像指定一个名为 nginx 的容器，监听端口 80 。 ReplicaSet 确保 pod 始终有三个副本正在运行且可用，并标记为 app: nginx 。

Let’s look at the spec field inside. 我们来看看里面的spec字段。

• .spec.replicas denotes the number of replicas – the number of instances of the pod you would be running. This number would depend on how much you’d want to scale the pod. .spec.replicas 表示副本数 – 您将运行的 pod 实例数。这个数字取决于您想要扩展 Pod 的程度。

• .spec.selector contains the matchLabels field among others which contains a map of key-value pairs used to match labels on pods. The ReplicaSet will then identify and manage any pods whose labels match the ones specified under this field. .spec.selector 包含 matchLabels 字段等，其中包含用于匹配 Pod 上标签的键值对映射。然后，ReplicaSet 将识别并管理其标签与此字段下指定的标签匹配的所有 pod。

•   .spec.template

  contains the pod template that is used to create the replicas. These replicas are then managed by the ReplicaSet.

  .spec.template 包含用于创建副本的 Pod 模板。然后，这些副本由 ReplicaSet 管理。

  • .spec.template.metadata contains labels which need to match those under the .spec.selector.matchLabels field for the ReplicaSet to identify said pod. .spec.template.metadata 包含需要与 ReplicaSet 的 .spec.selector.matchLabels 字段下的标签匹配的标签来识别所述 pod。
  • .spec.template.spec contains information for creating the desired pod. It has the container definition, and configuration options such as the volume needed, security context and more. .spec.template.spec 包含用于创建所需 Pod 的信息。它具有容器定义和配置选项，例如所需的卷、安全上下文等。

Here, you can see the output and see that there are 3 different pods under kubectl get pods, denoting the 3 replicas. 在这里，您可以看到输出，并看到 kubectl get pods 下有 3 个不同的 pod，表示 3 个副本。

In a production-level setting, we wouldn’t be using ReplicaSets. Instead, we would be using something called Deployments. 在生产级别设置中，我们不会使用 ReplicaSet。相反，我们将使用称为部署的东西。 Deployments are preferred in production as they provide more advanced features such as rolling updates, rollbacks and more which allow for easier scaling and management of the application. 部署在生产中是首选，因为它们提供了更高级的功能，例如滚动更新、回滚等，可以更轻松地扩展和管理应用程序。 This makes Deployments help streamline the deployment process and ensure that the deployed application is running smoothly and efficiently. 这使得部署有助于简化部署过程并确保部署的应用程序平稳高效地运行。

Deployments 部署

A Deployment is the preferred way to deploy an application inside a pod. It is a higher-level abstraction built on top of ReplicaSets that uses ReplicaSets internally to manage applications. 部署是在 Pod 内部署应用程序的首选方式。它是构建在 ReplicaSet 之上的更高级别的抽象，在内部使用 ReplicaSet 来管理应用程序。 In addition to the work carried out by a ReplicaSet, it provides added functionality such as: 除了 ReplicaSet 执行的工作之外，它还提供附加功能，例如：

• Rolling Updates: Rolling updates ensure that an application is updated gradually, one replica at a time, while ensuring that the overall availability of the application is not impacted. In comparison, ReplicaSets only support scaling and managing replicas. 滚动更新：滚动更新可确保应用程序逐步更新，一次更新一个副本，同时确保应用程序的整体可用性不受影响。相比之下，ReplicaSet 仅支持扩展和管理副本。
• Rollback: Deployments automatically rollback to a previous version of an application if an update fails. For ReplicaSets, this process would need to be manually performed. 回滚：如果更新失败，部署会自动回滚到应用程序的先前版本。对于 ReplicaSet，此过程需要手动执行。
• Version Control: Similar to the previous feature, Deployments implement version control, hence allowing for the ability to rollback to a previous specific version. 版本控制：与之前的功能类似，部署实现版本控制，因此允许回滚到以前的特定版本。

Hence for such reasons, Deployments are the preferred way to go as they take care of a lot of the update and rollback functionality without any downtime and ensure that your application stays available and up to date. 因此，出于这些原因，部署是首选方式，因为它们可以处理大量更新和回滚功能，而不会造成任何停机，并确保您的应用程序保持可用且最新。 If you’d like to instead set up custom update functionality, then you could work with ReplicaSets. 如果您想设置自定义更新功能，那么您可以使用 ReplicaSets。

Sample manifest 舱单样本

Let’s look at a sample Deployment manifest: 让我们看一下示例部署清单：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

This manifest defines a Deployment for the nginx application. It specifies that there should be three replicas of the Deployment and that each pod should be labeled with app: nginx. The .spec section is similar to the ReplicaSet’s, defining the pod template for each replica. 此清单定义了 nginx 应用程序的部署。它指定 Deployment 应该有三个副本，并且每个 pod 都应该标记为 app: nginx 。 .spec 部分与 ReplicaSet 类似，定义每个副本的 pod 模板。

The differences in this manifest are: 此清单中的差异是：

• Using kind: Deployment to state the resource type. 使用 kind: Deployment 来声明资源类型。
• The .metadata.name field. .metadata.name 字段。

Additional fields in .speccan be used such as minReadySeconds, paused and more. Kubernetes docs talk more about it. 可以使用 .spec中的其他字段，例如 minReadySeconds 、 paused 等。 Kubernetes 文档对此进行了更多讨论。

Here you can see how the Deployment itself runs a ReplicaSet that then runs 3 pods. 在这里您可以看到 Deployment 本身如何运行一个 ReplicaSet，然后运行 ​​3 个 Pod。

💡Check out Kubernetes Deployments: The Ultimate Guide to understand more about how Deployments and ReplicaSets are used in a production setting. 💡查看 Kubernetes 部署：终极指南，了解有关如何在生产环境中使用 Deployments 和 ReplicaSet 的更多信息。

StatefulSet 状态集

Now let’s talk about StatefulSets. What are StatefulSets and why are they needed? 现在我们来谈谈 StatefulSet。什么是 StatefulSet？为什么需要它们？

StatefulSet is the controller that manages the deployment and scaling of a set of Stateful pods. A stateful pod in Kubernetes is a pod that requires persistent storage and a stable network identity to maintain its state all the time, even during pod restarts or rescheduling. StatefulSet 是管理一组 Stateful Pod 的部署和扩展的控制器。 Kubernetes 中的有状态 Pod 是需要持久存储和稳定的网络身份来始终保持其状态的 Pod，即使在 Pod 重新启动或重新调度期间也是如此。 These pods are commonly used for stateful applications such as databases or distributed file systems as these require a stable identity and persistent storage to maintain data consistency. 这些 Pod 通常用于有状态应用程序，例如数据库或分布式文件系统，因为这些应用程序需要稳定的身份和持久存储来保持数据一致性。

A StatefulSet helps manage these pods by providing some key unique features: StatefulSet 通过提供一些关键的独特功能来帮助管理这些 Pod：

• Unique Identity: StatefulSets assign each pod a unique index, which provides a consistent and unique identity even if pods are deleted or recreated. 唯一标识：StatefulSet 为每个 Pod 分配一个唯一索引，即使 Pod 被删除或重新创建，该索引也能提供一致且唯一的标识。 This is important for stateful applications that rely on a stable identity to maintain the application state or communicate with other nodes in the cluster. 这对于依赖稳定身份来维护应用程序状态或与集群中其他节点通信的有状态应用程序非常重要。
• Persistent Network Identity: StatefulSets provide each pod with a persistent network identity in the form of a stable hostname based on its ordinal index. 持久网络身份：StatefulSet 为每个 pod 提供基于其序数索引的稳定主机名形式的持久网络身份。 This hostname is used for DNS resolution within the cluster, making it easy for other services to discover and communicate with the pods in the StatefulSet, even if they are deleted or recreated. 该主机名用于集群内的 DNS 解析，使其他服务可以轻松发现 StatefulSet 中的 Pod 并与其通信，即使它们被删除或重新创建也是如此。
• Persistent Storage: StatefulSets provide persistent storage to their pods through Kubernetes PersistentVolumes, which can be dynamically provisioned and attached to pods as needed. 持久存储：StatefulSet 通过 Kubernetes PersistentVolume 为其 pod 提供持久存储，可以根据需要动态配置并附加到 pod。 This allows stateful applications to store their data reliably across pod restarts and rescheduling, which is important for applications that need to maintain stateful data, such as databases or distributed file systems. 这允许有状态应用程序在 Pod 重新启动和重新调度期间可靠地存储其数据，这对于需要维护有状态数据的应用程序（例如数据库或分布式文件系统）非常重要。

Hence, in comparison to ReplicaSets or Deployments, which are useful for managing general-purpose tools, StatefulSets are used in managing stateful pods that require a unique identity and stable network identity to maintain their state. 因此，与可用于管理通用工具的 ReplicaSet 或 Deployment 相比，StatefulSet 用于管理需要唯一身份和稳定网络身份来维护其状态的有状态 Pod。 Take, for example, a database that requires persistent storage. The database’s nodes would maintain their state so that a new node could take over the previous node’s hostname (unique identity) and network identity and hence make sure that data is consistent. 以需要持久存储的数据库为例。数据库的节点将维护其状态，以便新节点可以接管前一个节点的主机名（唯一身份）和网络身份，从而确保数据一致。

Sample manifest 舱单样本

Let’s look at a StatefulSet manifest: 让我们看一下 StatefulSet 清单：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-data
          mountPath: /var/www/html
  serviceName: nginx
  volumeClaimTemplates:
  - metadata:
      name: nginx-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

This is a StatefulSet manifest that manages three nginx pods. The StatefulSet ensures that each pod has a unique identity, a persistent network identity, and a stable hostname. There seem to be additional fields in here. Let’s talk about them: 这是管理三个 nginx pod 的 Stat e fulSet 清单。 StatefulSet 确保每个 Pod 具有唯一的身份、持久的网络身份和稳定的主机名。这里似乎还有其他字段。我们来谈谈它们：

• Inside the pod template (

  .spec.template.spec

  ):

  在 Pod 模板 ( .spec.template.spec ) 内：

  • terminationGracePeriodSeconds field is used to specify the amount of time after which Kubernetes should be allowed to forcefully terminate a Pod. This allows time for any cleanup task. terminationGracePeriodSeconds 字段用于指定允许 Kubernetes 强制终止 Pod 的时间长度。这为任何清理任务留出了时间。
  • volumeMounts field specifies which volumes should be mounted inside the container and where in the container they should be mounted. Volumes allow containers to share or persist data between restarts. The volumeMounts field is defined inside the containers field and includes the name of the volume and the path for the volume. volumeMounts 字段指定哪些卷应安装在容器内以及它们应安装在容器中的何处。卷允许容器在重新启动之间共享或保留数据。 volumeMounts 字段在 containers 字段内定义，包括卷的名称和卷的路径。

• .spec.serviceName is used to specify the name for the service that the StatefulSet will manage. This is used to give each pod in the StatefulSet a stable network identity and allows for load-balancing of traffic to these pods. .spec.serviceName 用于指定 StatefulSet 将管理的服务的名称。这用于为 StatefulSet 中的每个 Pod 提供稳定的网络身份，并允许对这些 Pod 的流量进行负载平衡。

• .spec.volumeClaimTemplates is used to define a persistent volume claim that is used by each pod in the StatefulSet, hence providing each pod with its persistent storage. Here, it requests 1GB of storage and uses the ReadWriteOnce access mode. .spec.volumeClaimTemplates 用于定义 StatefulSet 中每个 Pod 使用的持久卷声明，从而为每个 Pod 提供其持久存储。此处，它请求 1GB 存储空间并使用 ReadWriteOnce 访问模式。

You can see here the nginx StatefulSet running along with its 3 pods. You can also run the kubectl get pv command to display information about persistent volumes or the kubectl get pvc command to display information about persistent volume claims. 您可以在这里看到 nginx StatefulSet 及其 3 个 pod 一起运行。您还可以运行 kubectl get pv 命令来显示有关持久卷的信息，或运行 kubectl get pvc 命令来显示有关持久卷声明的信息。

The official Kubernetes documentation page contains more about the different types of fields inside a StatefulSet spec. 官方 Kubernetes 文档页面包含有关 StatefulSet 规范中不同类型字段的更多信息。

DaemonSet 守护进程集

Let’s talk about our final set type: a DaemonSet. A DaemonSet ensures that a single instance of a pod is running on each node in a cluster. While the earlier controller types ensure that a specific number of replicas are running across the cluster, DaemonSets are intended to run exactly one pod per node. 让我们来谈谈我们的最终集合类型：DaemonSet。 DaemonSet 可确保集群中的每个节点上运行单个 pod 实例。虽然早期的控制器类型可确保在集群中运行特定数量的副本，但 DaemonSet 旨在为每个节点运行一个 pod。 This is particularly useful for running pods as system daemons or background processes that need to run on every node in the cluster. Due to this, DeamonSets can be used for collecting logs, monitoring system performance, and managing network traffic across the entire cluster. 这对于将 Pod 作为需要在集群中每个节点上运行的系统守护进程或后台进程运行特别有用。因此，DeamonSets 可用于收集日志、监控系统性能以及管理整个集群的网络流量。

Let’s talk about a few points about DaemonSets and their difference as compared to the other controller types : 让我们谈谈 DaemonSet 的几点以及它们与其他控制器类型相比的区别：

• Pod Scheduling: DaemonSets are designed to run one instance of a pod on each node in a cluster. If you need multiple instances, then the other controller types would be more useful. Pod 调度：DaemonSet 旨在在集群中的每个节点上运行一个 pod 实例。如果您需要多个实例，那么其他控制器类型会更有用。
• Pod Identity: similar to StatefulSets, a DaemonSet runs a unique pod on each node as compared to having unique identities for every pod on each node. Pod 身份：与 StatefulSet 类似，DaemonSet 在每个节点上运行唯一的 pod，而每个节点上的每个 pod 都具有唯一的身份。
• Rollout Strategy: since other controller types have multiple instances of a pod, rollouts are done one pod at a time to prevent downtime but as a DaemonSet needs to run a single pod on every node, the rollout process is done one node at a time instead. 推出策略：由于其他控制器类型具有 pod 的多个实例，因此一次推出一个 pod 以防止停机，但由于 DaemonSet 需要在每个节点上运行一个 pod，因此推出过程一次完成一个节点。

Sample manifest 舱单样本

Now that we’ve talked about how DaemonSets differ from the previous set types, let’s take a look at a sample DaemonSet manifest. 现在我们已经讨论了 DaemonSet 与之前的集合类型有何不同，让我们看一下 DaemonSet 清单示例。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.7.4-1.0
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

This manifest runs a single pod of a Fluentd log collector on each node of the cluster. It has a selector to match the label app: fluentd and uses the Fluentd container image. 此清单在集群的每个节点上运行 Fluentd 日志收集器的单个 pod。它有一个选择器来匹配标签 app: fluentd 并使用 Fluentd 容器映像。

This manifest should be similar to the ones that we’ve come across. I’ll go over the details in this one: 该清单应该与我们遇到的清单类似。我将详细介绍这一点：

• The labels under.spec.selector.matchLabels and .spec.template.metadata.labels should be matching for the DaemonSet to select the fluentd pod. .spec.selector.matchLabels 和 下的标签。 spec.template.metadata.labels 应与 DaemonSet 匹配以选择 fluidd pod。

•   .spec.template.spec

  field specifies the pod template for the pod to be created.

  .spec.template.spec 字段指定要创建的 Pod 的 Pod 模板。

  • containers specifies the image to be run along with the volume name and its corresponding mountPath. mountPath specifies where in the container would the volume be mounted whereas the type of volume is specified in the volumes field, later. 容器指定要与卷名称一起运行的映像，其相应的 mountPath. mountPath 指定卷在容器中的安装位置，而卷的类型在 volumes 字段中指定，之后。
  • terminationGracePeriodSeconds mentions the time allowed for graceful termination terminationGracePeriodSeconds 提到允许优雅终止的时间
  • volumes defines the hostPath volume type with the name: varlog. The path field shows the path on the host system which will be mounted on the container. Volumes 使用 name: varlog 定义 hostPath 卷类型。 path 字段显示将安装在容器上的主机系统上的路径。

Here, you can see the DaemonSet running with its single pod instance. This is due to the absence of the replicas field, which signifies a single instance of the pod being run – in our case, running a logging agent. 在这里，您可以看到 DaemonSet 正在以其单个 Pod 实例运行。这是由于缺少 replicas 字段，该字段表示正在运行的 pod 的单个实例 – 在我们的例子中，运行一个日志代理。

Conclusion 结论

In conclusion, Kubernetes controllers are used to monitor the current state of a resource and ensure that the desired state is achieved. 总之，Kubernetes 控制器用于监视资源的当前状态并确保达到所需的状态。 The controllers mentioned in this article, ReplicaSets, Deployments, StatefulSets and DaemonSets, are built into the Kubernetes system and each solves a unique use case. 本文提到的控制器 ReplicaSets、Deployments、StatefulSets 和 DaemonSets 均内置于 Kubernetes 系统中，每个控制器都解决一个独特的用例。 ReplicaSets help manage traffic by scaling your application to have multiple instances of the same pod, while Deployments provide added functionality such as rolling updates, rollback, and version control. ReplicaSet 通过扩展应用程序以拥有同一 Pod 的多个实例来帮助管理流量，而 Deployment 则提供滚动更新、回滚和版本控制等附加功能。 StatefulSets are used to manage stateful applications and DaemonSets ensure that all (or a subset of) nodes run a copy of a pod. Understanding the difference between each set type is useful to understand which one to use in which scenario. StatefulSet 用于管理有状态应用程序，而 DaemonSet 可确保所有（或部分）节点运行 pod 的副本。了解每种集合类型之间的差异有助于了解在哪种情况下使用哪种集合类型。