Kubernetes 第八章 Pod 控制器

Deployment

简述

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。

 

Deployment 概念解析
Deployment 是什么？
Deployment 为 Pod 和 Replica Set（下一代 Replication Controller）提供声明式更新。
你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。
一个典型的用例如下：
使用 Deployment 来创建 ReplicaSet。ReplicaSet 在后台创建 pod。检查启动状态，看它是成功还是失败。
然后，通过更新 Deployment 的 PodTemplateSpec 字段来声明 Pod 的新状态。这会创建一个新的 ReplicaSet，Deployment 会按照控制的速率将 pod 从旧的 ReplicaSet 移动到新的 ReplicaSet 中。
如果当前状态不稳定，回滚到之前的 Deployment revision。每次回滚都会更新 Deployment 的 revision。
扩容 Deployment 以满足更高的负载。
暂停 Deployment 来应用 PodTemplateSpec 的多个修复，然后恢复上线。
根据 Deployment 的状态判断上线是否 hang 住了。
清除旧的不必要的 ReplicaSet。

　　

ReplicaSet

ReplicaSet的目的是在任何给定时间维护一组稳定的副本Pod。因此，它通常用于保证指定数量的相同Pod的可用性。

ReplicaSet的工作原理
ReplicaSet是使用字段定义的，包括指定如何识别它可以获取的Pod的选择器，指示它应该维护多少Pod的多个副本，以及一个pod模板，用于指定它应该创建的新Pod的数据以满足该数量复制品标准。然后，ReplicaSet通过根据需要创建和删除Pod来达到其目的，以达到所需的数量。当ReplicaSet需要创建新Pod时，它使用其Pod模板。

ReplicaSet与其Pods的链接是通过Pods的metadata.ownerReferences 字段，该字段指定当前对象所拥有的资源。ReplicaSet获取的所有Pod在其ownerReferences字段中拥有其拥有的ReplicaSet标识信息。通过此链接，ReplicaSet知道它正在维护的Pod的状态并相应地进行计划。

ReplicaSet使用其选择器标识要获取的新Pod。如果Pod没有OwnerReference或者OwnerReference不是控制器并且它与ReplicaSet的选择器匹配，则它将立即由所述ReplicaSet获取。

何时使用ReplicaSet
ReplicaSet确保在任何给定时间运行指定数量的pod副本。但是，部署是一个更高级别的概念，它管理ReplicaSet并为Pod提供声明性更新以及许多其他有用的功能。因此，除非您需要自定义更新编排或根本不需要更新，否则我们建议使用部署而不是直接使用ReplicaSet。

这实际上意味着您可能永远不需要操作ReplicaSet对象：改为使用Deployment，并在spec部分中定义您的应用程序。

　　

DaemonSet

aemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：
日志收集，比如 fluentd，logstash 等
系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

　

Job

Job 类型

Kubernetes 支持以下几种 Job：

• 非并行 Job：通常创建一个 Pod 直至其成功结束
• 固定结束次数的 Job：设置 .spec.completions，创建多个 Pod，直到 .spec.completions 个 Pod 成功结束
• 带有工作队列的并行 Job：设置 .spec.Parallelism 但不设置 .spec.completions，当所有 Pod 结束并且至少一个成功时，Job 就认为是成功

根据 .spec.completions 和 .spec.Parallelism 的设置，可以将 Job 划分为以下几种 pattern：

Job 类型	使用示例	行为	completions	Parallelism
一次性 Job	数据库迁移	创建一个 Pod 直至其成功结束	1	1
固定结束次数的 Job	处理工作队列的 Pod	依次创建一个 Pod 运行直至 completions 个成功结束	2+	1
固定结束次数的并行 Job	多个 Pod 同时处理工作队列	依次创建多个 Pod 运行直至 completions 个成功结束	2+	2+
并行 Job	多个 Pod 同时处理工作队列	创建一个或多个 Pod 直至有一个成功结束	1	2+

Job Controller

Job Controller 负责根据 Job Spec 创建 Pod，并持续监控 Pod 的状态，直至其成功结束。如果失败，则根据 restartPolicy（只支持 OnFailure 和 Never，不支持 Always）决定是否创建新的 Pod 再次重试任务。

StatefulSet

StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括
稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依序进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
有序收缩，有序删除（即从 N-1 到 0）
从上面的应用场景可以发现，StatefulSet 由以下几个部分组成：
用于定义网络标志（DNS domain）的 Headless Service
用于创建 PersistentVolumes 的 volumeClaimTemplates
定义具体应用的 StatefulSet