Kubernetes系列之Pod控制器
前言
Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成， 是 Kubernetes 的大脑， 它通过 apiserver 监控整个集群的状态， 并确保集群处于预期的工作状态。
kube-controller-manager 由一系列的控制器组成
1 Replication Controller
2 Node Controller
3 CronJob Controller
4 DaemonSet Controller
5 Deployment Controller
6 Endpoint Controller
7 Garbage Collector
8 Namespace Controller
9 Job Controller
10 Pod AutoScaler
11 RelicaSet
12 Service Controller
13 ServiceAccount Controller
14 StatefulSet Controller
15 Volume Controller
16 Resource quota Controllercloud-controller-manager 在 Kubernetes 启用 Cloud Provider 的时候才需要， 用来配合云服务提供商的控制， 也包括一系列的控制器
1 Node Controller
2 Route Controller
3 Service Controller从v1.6开始，cloud provider已经经历了几次重大重构，以便在不修改Kubernetes核心代码的同时构建 自定义的云服务商支持。
常见Pod控制器及含义
ReplicaSet:适合无状态的服务部署
用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。 ReplicaSet主要三个组件组成： （1）用户期望的pod副本数量 （2）标签选择器，判断哪个pod归自己管理 （3）当现存的pod数量不足，会根据pod资源模板进行新建 帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是 ReplicaSet不是直接使用的控制器，而是使用Deployment。
Deployment：适合无状态的服务部署
工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
无状态服务：比如tomcat· 、nginx等等；
StatefullSet：适合有状态的服务部署
有状态服务：比如mysql等等；
后续再系统为大家讲解，敬请关注；
DaemonSet：一次部署，所有的node节点都会部署
例如一些典型的应用场景
- 运行集群存储 daemon，例如在每个Node上运行 glusterd(集群信息管理系统)、ceph(分布式存储系统)；
- 在每个Node上运行日志收集 daemon，例如 fluentd、 logstash；
- 在每个Node上运行监控 daemon，例如 Prometheus Node Exporter；
用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务 特性：服务是无状态的； 服务必须是守护进程；
Job：一次性的执行任务。只要完成就立即退出，不需要重启或重建。
Cronjob：周期性的执行任务。周期性任务控制，不需要持续后台运行。
演示
Replication Controller控制器
Replication controller简称RC，是kubernetes系统中的核心概念之一，简单来说，它其实定义了一个期望的场景，即声明某种pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包含以下部分：
- pod期待的副本数量 ；
- 用于筛选目标pod的Label Selector；
- 当pod的副本数量小于期望值时，用于创建新的pod的pod模板（template）；
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
ReplicaSet
简称RS,在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。
虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update(滚动升级)但Deployment支持）。
ReplicaSet模板
apiVersion: apps/v1 #api版本定义
kind: ReplicaSet #定义资源类型为ReplicaSet
metadata: #元数据定义
name: replicasetdemo
labels:
app: replicasetdemo
spec: #ReplicaSet的规格定义
replicas: 1 #定义副本数量为1个
template: #pod的模板定义
metadata: #pod的元数据定义
name: replicasetdemo #自定义pod的名称
labels: #定义pod的标签，需要和下面定义的标签一致
app: replicasetdemo
spec: #pod的规格定义
containers: #容器定义
- name: replicasetdemo #容器名称
image: nginx:1.17.10-alpine #容器镜像
imagePullPolicy: IfNotPresent
ports: #暴露端口
- containerPort: 80
restartPolicy: Always
selector: #标签选择器，定义匹配pod的标签
matchLabels:
app: replicasetdemo可以通过kubectl命令行方式获取更加详细信息
kubectl explain rs
kubectl explain rs.spec
kubectl explain rs.spec.template.spec
运行ReplicaSet
##运行ReplicaSet
kubectl apply -f replicasetdemo.yml
##查看rs控制器
kubectl get rs
##查看pod信息
kubectl get pod
##查看pod详细信息
kubectl describe pod replicasetdemo-2ngw6
##测试controller控制器下的pod删除、重新被controller控制器拉起
kubectl delete pod --all
kubectl get pod
##修改pod的副本数量:通过命令行方式
kubectl scale replicaset replicasetdemo --replicas=8
kubectl get rs
##修改pod的副本数量:通过资源清单方式 将replicas改为3
kubectl edit replicasets.apps replicasetdemo
kubectl get rs
##显示pod的标签
kubectl get pod --show-labels
##修改pod标签(label)
kubectl label pod replicasetdemo-652lc app=bcst --overwrite=True
##再次显示pod的标签：发现多了一个pod，原来的rs中又重新拉起一个pod，说明rs是通过label去管理pod
kubectl get pod --show-labels
##删除rs
kubectl delete rs replicasetdemo
修改pod的副本数量
pod的标签
注：官方给出的解释是RS通过labels或者一组label管理,所以上面三个pod都归这组label管理；
那如果pod的label 名称不一样呢？下面修改下：
删除rs
总结
kubectl命令行工具适用于RC的绝大部分命令同样适用于ReplicaSet，此外，我们当前很少单独使用 ReplicaSet，它主要被Deployment这个更高层的资源对象所使用，从而形成一整套Pod创建，删除， 更新的编排机制，我们在使用Deployment时无需关心它是如何维护和创建ReplicaSet的，这一切都是自动发生的；
最后，总结一下RS（ReplicaSet）的一些特性和作用：
- 在绝大多数情况下，我们通过定义一个RS实现Pod的创建及副本数量的自动控制
- 在RS里包括完整的Pod定义模板
- RS通过Label Selector机制实现对Pod副本的自动控制
- 通过改变RS里的Pod副本数量，可以实现Pod的扩容和缩容
- 通过改变RS里Pod模板中的镜像版本，可以实现滚动升级
Deployment
Deployment是kubernetes在1.2版本中引入的新概念，用于更好地解决Pod的编排问题，为此， Deployment在内部使用了ReplicaSet来实现目的，我们可以把Deployment理解为ReplicaSet的一次升级，两者的相似度超过90% 。
Deployment的使用场景：
- 创建一个Deployment对象来生成对应的ReplicaSet并完成Pod副本的创建；
- 检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到了预期的值）；
- 更新Deployment以创建新的Pod（比如镜像升级）；
- 如果当前Deployment不稳定，可以回滚到一个早先的Deployment版本；
- 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment， 进行新的发布 ；
- 扩展Deployment以应对高负载 ；
- 查看Deployment的状态，以此作为发布是否成功的标志；
- 清理不在需要的旧版本ReplicaSet ；
Deployment模板说明
可以通过kubectl命令行方式获取更加详细信息
kubectl explain deploy
kubectl explain deploy.spec
kubectl explain deploy.spec.template.spec
部署Deployment
除了API声明与Kind类型有区别，Deployment的定义与Replica Set的定义很类似。
controller/deploymentdemo.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-demo
labels:
app: deployment-demo
spec:
replicas: 3
template:
metadata:
name: deployment-demo
labels:
app: deployment-demo
spec:
containers:
- name: deployment-demo
image: nginx:1.17.10-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
restartPolicy: Always
selector:
matchLabels:
app: deployment-demo运行Deployment
kubectl apply -f deploymentdemo.yml
#查看deployment
kubectl get rs
#查看rs:deployment名称+hashcode码组成
#查看pod
kubectl get pod -o wide
总结：当我们创建一个deployment时，deployment里面是包含RS的，RS里面又包含对应的pod,DESIRED为3是表示用户期望的pod副本数。
镜像更新升级
命令行方式
#升级nginx镜像版本为1.18.0
kubectl set image deployment deployment-demo deployment-demo=nginx:1.18.0-alpine
#查看pod升级情况
kubectl get pods -w
#进去某一个pod内部，查看nginx升级版本信息
kubectl exec -it deployment-demo-5d49f86785-ht4ww sh
nginx -v
exit
yml文件方式
#升级nginx镜像版本为1.19.2-alpine
kubectl edit deployments.apps deployment-demo
#查看pod升级情况
kubectl get pods -w
#进人某一个pod内部，查看nginx升级版本信息
kubectl exec -it deploymentdemo1-584f6b54dd-4l62t sh
nginx -v
exit
Deployment扩容
命令行方式
kubectl scale deployment deployment-demo --replicas= 5
kubectl get pod -w
yml文件方式
#更新 replicas: 5
kubectl edit deployments.apps deployment-demo滚动更新
概述
微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布。
- 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。蓝绿部署无需停机，并且风险较小。
- 滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
- 灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
金丝雀发布
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用， 主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布(Canary Release)。
#更新deployment的nginx:1.18.0-alpine版本，并配置暂停deployment
kubectl set image deployment deployment-demo deployment-demo=nginx:1.18.0-alpine && kubectl rollout pause deployment deployment-demo
#观察更新状态
kubectl rollout status deployment deployment-demo
#监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是
#因为使用了pause暂停命令
kubectl get pods -l app=deployment-demo -w
#查看pod标签
kubectl get pod --show-labels
#确保更新的pod没问题了，继续更新
kubectl rollout resume deploy deployment-demo
#查看最后的更新情况
kubectl get pods -l app=deployment-demo -w
#进去某一个pod内部，查看nginx更新版本信息
kubectl exec -it deployment-demo-5d49f86785-ncv5p sh
nginx -v
Deployment版本回退
概述
默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（您可以修改 revision history limit 来更改保存的revision数）。
注意：只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如 .spec.template ）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。
其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便地手动或者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。
rollout常见命令
子命令 | 功能说明 |
|---|---|
history | 查看rollout操作历史 |
pause | 将提供的资源设定为暂停状态 |
restart | 重启某资源 |
resume | 将某资源从暂停状态恢复正常 |
status | 查看rollout操作状态 |
undo | 回滚前一rollout |
history操作
#查看历史版本信息
kubectl rollout history deployment deployment-demostatus操作
kubectl rollout status deployment deployment-demoundo操作
#回滚到上一个版本
kubectl rollout undo deployment deployment-demo
#kubectl rollout undo deployment deployment-demo --to-revision=1
#回滚到版本1，需要指定namespace，“--to-revision”是指定回滚到哪个版本
#查看pod回滚情况
kubectl get pods -w
#进入某一个pod内部，查看nginx回滚版本信息
kubectl exec -it deploymentdemo1-df6bc5d4c-flc7b sh
nginx -v
Deployment 更新策略
Deployment可以保证在升级时只有一定数量的Pod 是down 的。默认的，它会确保至少有比期望的Pod数量少
Deployment 同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望 的Pod数
Kuberentes 版本v1.17.5中，从1-1变成25%-25%
kubectl describe deployments.apps deployment-demo
#查看到属性：
RollingUpdateStrategy: 25% max unavailable, 25% max surge总结
Deployment为Pod和ReplicaSet（下一代Replication Controller）提供声明式更新。只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和 ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
Replicas（副本数量）：
.spec.replicas 是可以选字段，指定期望的pod数量，默认是1。
Selector（选择器）：
.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。
如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下， Deployment会杀掉label跟selector不同的Pod。
Pod Template（Pod模板）
.spec.template 是 .spec中唯一要求的字段。.spec.template 是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要 apiVersion 和 kind字段。
另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他 controller重复了，参考selector）和适当的重启策略。
.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。
strategy（更新策略）
.spec.strategy 指定新的Pod替换旧的Pod的策略。.spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。
Recreate： 重建式更新，就是删一个建一个。类似于ReplicaSet的更新方式，即首先删除现有的Pod对象，然后由控制器基于新模板重新创建新版本资源对象。
rollingUpdate：滚动更新，简单定义更新期间pod最多有几个等。可以指定 maxUnavailable 和 maxSurge 来控制 rolling update 进程。
maxSurge：.spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如 10%）。当 MaxUnavailable 为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。
例如，该值设置成30%，启动rolling update后新的ReplicatSet将会立即扩容，新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后，新的ReplicaSet将继续扩容，旧的ReplicaSet会进 一步缩容，确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。
maxUnavailable：.spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值（例如5）,也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。如果 .spec.strategy.rollingUpdate.maxSurge 为0时，这个值不可以为0。默认值1。
例如，该值设置成30%，启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的 70%。新的Pod ready后，随着新的ReplicaSet的扩容，旧的ReplicaSet会进一步缩容确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。
progressDeadlineSeconds
.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing——表现为resource的状态中 type=Progressing 、 Status=False 、 Reason=ProgressDeadlineExceeded 前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到 这种状态时就会自动回滚。
如果设置该参数，该值必须大于 .spec.minReadySeconds 。
paused
.spec.paused 是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有 paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。
可通过 kubectl explain deploy.spec查看模板说明
DaemonSet
DaemonSet 确保全部Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一 个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
在每一个node节点上只调度一个Pod，因此无需指定replicas的个数，比如：
- 在每个node上都运行一个日志采集程序，负责收集node节点本身和node节点之上的各个Pod所产生的日志
(ELK)
- 在每个node上都运行一个性能监控程序，采集该node的运行性能数据 (Prometheus)
DaemonSet模板说明
可以通过kubectl命令行方式获取更加详细信息
kubectl explain daemonset
kubectl explain daemonset.spec
kubectl explain daemonset.spec.template.spec部署DaemonSet
controller/daemonsetdemo.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-test-demo
labels:
app: daemonset-demo
spec:
template:
metadata:
name: daemonset-demo
labels:
app: daemonset-demo
spec:
containers:
- name: daemonset-demo
image: nginx:1.17.10-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
restartPolicy: Always
selector:
matchLabels:
app: daemonset-demo运行DaemonSet
#运行demonset
kubectl apply -f demonsetdemo.yml
kubectl get daemonset
#查看pod详细信息：只有工作节点创建pod，master节点并不会创建。
kubectl get pod -o wide
DaemonSet的滚动更新
DaemonSet有两种更新策略类型：
- OnDelete：这是向后兼容性的默认更新策略。使用OnDelete 更新策略，在更新DaemonSet模板 后，只有在手动删除旧的DaemonSet pod时才会创建新的DaemonSet pod。这与Kubernetes 1.5或更早版本中DaemonSet的行为相同。
- RollingUpdate：使用 RollingUpdate 更新策略，在更新DaemonSet模板后，旧的DaemonSet pod将被终止，并且将以受控方式自动创建新的DaemonSet pod。
可通过kubectl explain daemonset.spec.updateStrategy 查看模板说明
修改yml文件
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-test-demo
labels:
app: daemonset-demo
spec:
updateStrategy:
type: "RollingUpdate" #指定滚动更新策略
rollingUpdate:
maxUnavailable: 2 #升级过程中不可用Pod的最大数量
template:
metadata:
name: daemonset-demo
labels:
app: daemonset-demo
spec:
containers:
- name: daemonset-demo
image: nginx:1.17.10-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
restartPolicy: Always
selector:
matchLabels:
app: daemonset-demo
Job
概述
Job负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
应用场景：
- 如离线数据处理;
- 视频解码等业务
Job模板说明
kubectl explain job
kubectl explain job.spec
部署Job
controller/jobdemo.yml
apiVersion: batch/v1
kind: Job
metadata:
name: jobdemo
labels:
app: jobdemo
spec:
template:
metadata:
name: jobdemo
labels:
app: jobdemo
spec:
containers:
- name: jobdemo
image: busybox:1.32.0
imagePullPolicy: IfNotPresent
command: ["/bin/echo"]
args: ["hello", "world"]
restartPolicy: Never
activeDeadlineSeconds: 15 #设置 Pod 运行的超时时间
backoffLimit: 2 #设置 Pod 的失败重试次数
completions: 3 #Job 完成需要运行多少个 Pod，默认是 1 个
parallelism: 2 #它与 completions 相关，表示允许并发运行的 Pod 数量，避免过多占用资源activeDeadlineSeconds，设置 Pod 运行的超时时间。 backoffLimit，设置 Pod 的失败重试次数。 completions，Job 完成需要运行多少个 Pod，默认是 1 个。 parallelism，它与 completions 相关，表示允许并发运行的 Pod 数量，避免过多
运行job
kubectl apply -f jobdemo.yml
kubectl get job
#删除job
kubectl delete -f jobdemo.yml
kubectl delete job jobdemo
CronJob
CronJob就是在Job上加上了时间调度
概述
Kind是CronJob了，要注意的是.spec.schedule字段是必须填写的，用来指定任务运行的周期，另外一个字段是.spec.jobTemplate, 用来指定需要运行的任务，格式当然和Job是一致的。还有一些值得我们关注的字段.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit，表示历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job，默认没有限制，所有成功和失败的Job都会被保留。然而，当运行一个Cron Job时，Job可以很快就堆积很多，所以一般推荐设置这两个字段的值。如果设置限制的值为 0，那么相关类型的Job完成后将不会被保留。
CronJob模板说明
kubectl explain CronJob部署CronJob
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cron-jobdemo
labels:
app: cron-jobdemo
spec:
schedule: '*/1 * * * *' #1分钟执行一次
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
startingDeadlineSeconds: 60 #CronJob 控制器将测量从预期创建作业到现在之间的时间。如果差异高于该限制，它将跳过此执行。例如，如果设置为200，则它允许在实际计划后最多 200 秒内创建作业。
jobTemplate:
spec:
template:
metadata:
name: cron-jobdemo
labels:
app: cron-jobdemo
spec:
containers:
- name: cron-jobdemo
image: busybox:1.32.0
imagePullPolicy: IfNotPresent
command: ["/bin/echo"]
args: ["hello", "world"]
restartPolicy: Never
backoffLimit: 4backoffLimit说明
.spec.backoffLimit用于设置Job的容错次数，默认值为6。当Job运行的Pod失败次数到 达.spec.backoffLimit次时，Job Controller不再新建Pod，直接停止运行这个Job，将其运行结 果标记为Failure。另外，Pod运行失败后再次运行的时间间隔呈递增状态，例如10s，20s， 40s。。。
运行CronJob
kubectl apply -f cronjobdemo.yml
kubectl get CronJob
注：因为没有指定successfulJobsHistoryLimit会周期的创建pod执行任务
StatefulSet
在kubernetes系统中，Pod的管理对象RC，Deployment，DaemonSet和Job都面向无状态的服务，但 现实中有很多服务时有状态的，比如一些集群服务，例如mysql集群，集群一般都会有这四个特点：
- 每个节点都是有固定的身份ID，集群中的成员可以相互发现并通信
- 集群的规模是比较固定的，集群规模不能随意变动
- 集群中的每个节点都是有状态的，通常会持久化数据到永久存储中
- 如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损
如果你通过RC或Deployment控制Pod副本数量来实现上述有状态的集群，就会发现第一点是无法满足 的，因为Pod名称和ip是随机产生的，并且各Pod中的共享存储中的数据不能都动，因此StatefulSet在 这种情况下就派上用场了，那么StatefulSet具有以下特性：
- StatefulSet里的每个Pod都有稳定，唯一的网络标识，可以用来发现集群内的其它成员，假设， StatefulSet的名称为BCST，那么第1个Pod叫BCST-0，第2个叫BCST-1，以此类推
- StatefulSet控制的Pod副本的启停顺序是受控的，操作第N个Pod时，前N-1个Pod已经是运行且准备状态
- StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与 StatefulSet相关的存储卷（为了保证数据的安全）
StatefulSet除了要与PV卷捆绑使用以存储Pod的状态数据，还要与Headless，Service配合使用，每个 StatefulSet定义中都要声明它属于哪个Handless Service，Handless Service与普通Service的关键区别 在于，它没有Cluster IP
注：本期大家只是对StatefulSet做个了解，后期我这边再深入为大家讲解；