控制器分类
POD控制器由master的kube-controller-manager 组件提供,其类型：
1、Replication controller
2、Replicaset controller
3、deployment controller
4、daemonset controller
5、statefulset controller
6、job controller
7、cronjob controller
控制器概述
Kubernetes的核心之一是确保各资源对象的当前状态匹配用户期望的状态,使当前状态不断向期望状态靠近的方式来完成容器应用和管理
控制器是通过API Server 提供的接口持续监控相关资源对象的状态,并在因故障灯导致系统发生变化是,尝试让资源向期望状态迁移和逼近。
List-watch: kubernetes的核心机制之一,其在资源状态发生变化是,由API Server负责写入etcd并通过水平出发机制主动通知给相关客户端程序,控制器通过API Server的watch 接口实时监控目标资源对象的变动和执行趋势近操作,并不会与其他控制器进行交互。
POD和POD控制器
Pod控制器通过(List-watch) 监控集中运行做POD资源对象确保其受管控的资源严格符合用户期望状态,通常POD控制器包含的基本组成部分:
1、标签选择器: 匹配相关的POD,来确保POD的数量（kubectl explain deployment.spec.selector）
2、期望副本数: 期望在集群中与运行着的POD资源对象数量（kubectl explain deployment.spec.replicas）
3、POD模板: 用于新建POD资源对象的POD模板资源（kubectl explain deployment.spec.template）
注:demonset 用于确保每个工作（node）节点上都运行着一个POD，因此不具备第二个选项
二、ReplicaSet 控制器
1、概述
Kubernetes 中Replicaset 是取代早期的Relication controller,其Replication controller 将被废弃,但其功能和Replicaset 基本类似
Replicaset 用于保证其管理的POD对象副本数量在任意时刻都能精确满足期望数量，其原理是: 控制器资源在启动后悔查找集中匹配器标签选择器的POD资源对象,当前活动对象的数据量于期望数量不吻合时，则删除或创建的POD
Replicaset 实现的功能:
1、确保POD资源独享的数值精确反应期望值
2、确保POD健康运行: 探测到期的POD对象因工作节点故障而不可用时,会自动由调度器调度至其他节点创建确实的POD副本
3、弹性伸缩: 可通过Replicaset控制器动态调整相关POD资源对象数量，必要时还可以通过HPA控制器实现POD资源规模的自动伸缩
2 创建Replicaset 资源进
1、核心字段
Replicas: 用于定义当前 期望副本数量
selector: 用于选择和计数当前的POD的数量
template： 用于定义POD资源信息
minreadysecond： 用于定义POD启动后多久时间为可用状态
2、创建资源
#cat replicaset1.yaml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: replicaset-demo
namespace: default
spec:
replicas: 2 # 定义POD副本数量
selector:
matchLabels:
app: replicaset1
release: test
minReadySeconds: 5 #定期启动后多久认为正常
template: # 定义POD资源
metadata:
name: replicaset-demo
namespace: default
labels: #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
app: replicaset1
release: test
spec:
containers:
- name: replicaset-demo
image: nginx:1.14
ports:
- name: httpd
containerPort: 80
3、查看创建的资源
[root@K8S-MASTER-001]# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 97d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 97d
replicaset-demo-d7mdv 1/1 Running 0 12m
replicaset-demo-llwb6 1/1 Running 0 12m
4、删除指定标签的POD
[root@K8S-MASTER-001]# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 97d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 97d
replicaset-demo-d7mdv 1/1 Running 0 12m
replicaset-demo-llwb6 1/1 Running 0 12m
[root@K8S-MASTER-001]#kubectl delete pods replicaset-demo-d7mdv -n default
pod "replicaset-demo-d7mdv" deleted
[root@K8S-MASTER-001]# kubectl get pods -n defaultNAME READY STATUS RESTARTS AGE
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 97d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 97d
replicaset-demo-g7wdr 1/1 Running 0 9s
replicaset-demo-llwb6 1/1 Running 0 15m
5、强制清除对应POD的标签
[root@K8S-MASTER-001]# kubectl get pods -n defaultNAME READY STATUS RESTARTS AGE
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 97d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 97d
replicaset-demo-g7wdr 1/1 Running 0 2m20s
replicaset-demo-llwb6 1/1 Running 0 17m
[root@K8S-MASTER-001]# kubectl label pods replicaset-demo-llwb6 app= release= --overwrite -n default
pod/replicaset-demo-llwb6 labeled
###查看其POD副本数已上升至3个，因其中一个标签不符合要求
[root@K8S-MASTER-001]# kubectl get pods -n defaultNAME READY STATUS RESTARTS AGE
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 97d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 97d
replicaset-demo-8pz88 1/1 Running 0 5s
replicaset-demo-g7wdr 1/1 Running 0 2m35s
replicaset-demo-llwb6 1/1 Running 0 17m
6、 增加POD 用于匹配对应标签
[root@K8S-MASTER-001]# kubectl run nginx10 --image=nginx:1.14 -l app=replicaset1,release=test -n default
pod/nginx10 created
7、查看控制器POD变化信息
[root@K8S-MASTER-001]# kubectl describe replicaset replicaset-demo -n default
Name: replicaset-demo
Namespace: default
Selector: app=replicaset1,release=test
Labels: <none>
Annotations: Replicas: 2 current / 2 desired
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=replicaset1
release=test
Containers:
replicaset-demo:
Image: nginx:1.14
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulDelete 104s (x2 over 4h51m) replicaset-controller Deleted pod: nginx10
replicaset控制器能够对POD对象数目的异常进行响应是因为其向API server注册监听了watch 相关资源及列表的变动信息，于是API server会在变动发生时立即通知给相关的监听客户端。
3、更新Replicaset 控制器
其更新主要是replicas 和template 字段进行的，毕竟对标签的带动是很少的，修改template就是更新POD，修改replicas就是扩容或缩容。
1、升级应用
replicas 控制器的POD template 的变更只会影响新建的POD对象，对于已经存在的副本没有影响，因此，若更新版本，则在修改了template.spec.containers.image 之后，还需要删除之前版本对应的副本或按一定方式进行更新。
#cat replicaset1.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: replicaset-demo
namespace: default
spec:
replicas: 2 # 定义POD副本数量
selector:
matchLabels:
app: replicaset1
release: test
minReadySeconds: 5 #定期启动后多久认为正常
template: # 定义POD资源
metadata:
name: replicaset-demo
namespace: default
labels: #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
app: replicaset1
release: test
spec:
containers:
- name: replicaset-demo
image: nginx:1.12
ports:
- name: httpd
containerPort: 80
#部署并查看相关镜像
[root@K8S-MASTER-001]# kubectl replace -f replicaset1.yml
replicaset.apps/replicaset-demo replaced
[root@K8S-MASTER-001]# kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
replicaset-demo-8pz88 nginx:1.14
replicaset-demo-g7wdr nginx:1.14
2、删除对应POD 并查看POD
[root@K8S-MASTER-001]# kubectl delete pods -l app=replicaset1,release=test -n default
pod "replicaset-demo-8pz88" deleted
pod "replicaset-demo-g7wdr" deleted
[root@K8S-MASTER-001]# kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
replicaset-demo-fxfjb nginx:1.12
replicaset-demo-sxpnc nginx:1.12
3、更新方式
1 一次性删除控制器相关的所有POD副本或更改相关标签
2 分批删除就有的POD副本或更新其标签，滚动更替，更替期间新旧版本共存。
4、扩容和缩容
改动replicaset控制器对象配置中期望的POD副本数量会由控制器实时响应，从而实现应用规模的水平伸缩，kubelet提供了专用的子命令scale 用于实现应用规模的伸缩，它支持从资源清单文件中获取新的目标副本数量，也可直接在命令中获取"–replicas"选项进行读取
#扩容
[root@K8S-MASTER-001]# kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
replicaset-demo-65bhn nginx:1.12
replicaset-demo-65s44 nginx:1.12
replicaset-demo-fxfjb nginx:1.12
replicaset-demo-pnq2w nginx:1.12
replicaset-demo-sxpnc nginx:1.12
#缩容
[root@K8S-MASTER-001]# kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
replicaset-demo-fxfjb nginx:1.12
5、删除replicaset 控制器资源
使用kubectl delete命令删除replicaset对象时默认会一并删除其管控的各POD对象，有时，考虑到这些POD未必尤其创建，或者即使尤其创建却也并非其自身的组成部分，故而可以为命令使用"–cascade=false"取消级联，删除相关POD对象，
[root@K8S-MASTER-001]# kubectl get replicasets -n default
三、Deployment 控制器
概述
deployment 是kubernetes控制器的另一种实现，其构建于replicaset控制器之上，可为POD和replicaset资源提供声明式更新。
deployment控制器资源的主要职责是为了保证POD资源的健康运行，其不同于replicaset的功能：
1 事件和状态查看：必要时可以查看deployment对象升级的详细进度和状态
2 回滚：升级操作完成后发现问题，支持使用回滚机制将应用程序返回到前一个由用户指定的历史记录版本中
3 版本记录：对deployment 对象的每一次升级操作都予以保存，以供后续可能的回滚操作
4 暂停和启动：对于每一次更新，都能够随时暂停和启动
5 多种自动更新方案： 一个是recreate，及重建机制，全面停止、删除旧有的POD后用心版本替代，另一种是rollingupdate，及滚动升级机制，逐步替换旧有的POD到新版本。
创建deployment
# cat deploy.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-demo
namespace: default
spec:
replicas: 3 # 定义POD副本数量
selector:
matchLabels:
app: deploy
release: test
minReadySeconds: 5 #定期启动后多久认为正常
template: # 定义POD资源
metadata:
name: replicaset-demo
namespace: default
labels: #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
app: deploy
release: test
spec:
containers:
- name: deploy-demo
image: nginx:1.12
ports:
- name: httpd
containerPort: 80
#kubectl apply -f deploy.yaml
# kubectl get pod -l app=deploy,release=test -n default
NAME READY STATUS RESTARTS AGE
deployment-demo-7d69b575c8-lgphx 1/1 Running 0 13m
deployment-demo-7d69b575c8-m7l4m 1/1 Running 0 13m
deployment-demo-7d69b575c8-s6w6z 1/1 Running 0 13m
# kubectl get deployment deployment-demo -n default
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-demo 3/3 3 3 14m
deployment控制器会自动管理至replicaset控制器资源，其名称是 deployement 名称+ hash 。其中hash 是由deployment随机生成，
更新策略
Replicaset 控制器应用更新需要手动非常多步并以特定的次序进行,过程复杂，而deployment只需要用户指定POD模板中要改动的内容,余下的步骤是操作系统自动完成,其副本数量也是相同
deployment 支持滚动更新和重建更新,其默认是滚动更新,重建更新和之前的Replicaset相同,首先删除所有的POD,而后由控制器基于新模板重新创建新版资源对象，此情况仅用于新旧版本不兼容的情况。
滚动升级是默认的更新策略,它在删除一部分旧版本POD资源的同时,补充创建一部分新版本的POD对象进行应用升级,其优势是升级期间，服务不会中断,但更新期间,不同客户端得到的相应的内容可能会来自不同的版本的应用.
deployment的滚动更新是将新旧版本用在不同的Replicaset控制对象下,删除旧的POD的同事增加新的POD，新的POD对象不断增加,直到旧的控制器不在拥有的POD对象,而新的控制器的副本数量变得完全符合期望值为止。
滚动更新,应用升级期间需要确保POD对象数量不低于某个阀值以确保可以持续处理客户端的服务请求，变动的方式和POD对象数量范围通过kubectl explain deployment.spec.strategy.rollingUpdate.maxSurge 和 kubectl explain deployment.spec.strategy.rollingUpdate.maxUnavailable 两个属性协同进行定义，其功能如下：
1 maxSurge: 指定升级期间存在的总POD对象数量最多可超出期望的个数,其值可以是0或者正整数，也可以是期望值的百分比,比如期望值是3,maxsurge是1,则表示POD对象的总数不能超过4个
2 maxUnavailable: 升级期间正常可用的POD副本数最多不能低于期望数据的个数,可以是整数或者0，也可以是一个期望值百分比,默认是1,则表示若期望值是3,则升级期间至少要两个POD对象处于正常运行状态
注: maxsuarge和maxunavailable 属性至不可同时为0，否则POD对象的副本数量在符合用户期望数量后无法做出合理变动以进行滚动更新。
用户可以通过spec.minReadySeconds 属性来控制应用程序升级速度，新旧更替过程中，新创建的POD对象一旦成果相应就绪探测及被视为可用，而后便开始新一轮的替换操作，而deployment.spec.minReadySeconds 定义在新的POD创建后至少等待多久才视为就绪，此期间，更新操作被被阻塞。
deployment 的历史版本保留数量由deployment.spec.revisionHistoryLimit 属性进行定义，只有保存与revision历史中的replicaset版本可用于回滚。
注： 为了保存版本升级的历史，需要在创建deployment对象时在命令中使用"–record"选项。
升级deployment
修改POD模板相关的配置参数以便完成deployment控制器资源的更新，由于是声明式配置，因此对deployment控制器的修改使用apply 和patch 命令进行，若仅是修改镜像，则可使用set image 即可
修改副本数量:
]# kubectl patch deployment deployment-demo -p '{"spec":{"replicas":4}}' -n default
deployment.apps/deployment-demo patched
修改等待时间:
# kubectl patch deployment deployment-demo -p '{"spec":{"minReadySeconds":4}}' -n default
# kubectl describe deployment deployment-demo -n default |grep MinReadySeconds
MinReadySeconds: 4
注： 修改deployment控制器的minreadyseconds，replicas 和 strategy 等字段值并不会触发POD资源更新操作，因为其不属于模板的内嵌字段，对现存的POD对象不会产生任何影响
调整镜像
#现有版本
# kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-7d69b575c8-lgphx nginx:1.12
deployment-demo-7d69b575c8-m7l4m nginx:1.12
deployment-demo-7d69b575c8-mrq82 nginx:1.12
deployment-demo-7d69b575c8-s6w6z nginx:1.12
#调整镜像
#kubectl edit deployment deployment-demo -n default
Image: nginx:1.12 调整为: Images: nginx：1.14
#更新镜像
# kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-8947496fb-5xwql nginx:1.14
deployment-demo-8947496fb-bngkg nginx:1.14
deployment-demo-8947496fb-qzrlc nginx:1.14
deployment-demo-8947496fb-z7mc4 nginx:1.14
#使用kubectl set image 更新镜像
# kubectl set image deployment deployment-demo deploy-demo=nginx:1.12 -n default
deployment.apps/deployment-demo image updated
金丝雀发布
deployment 控制器还支持金丝雀发布，及随时展厅或继续更新操作，通过 maxsurge 和 maxunavailable属性还能实现更为精巧的控制过程，其采用先添加再删除的方式，且可用POD资源对象总数不低于期望值的方式进行，
1添加其总数多于期望值一个
# kubectl patch deployments deployment-demo -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}' -n default
deployment.apps/deployment-demo patched
启动更新过程
# kubectl set image deployment deployment-demo deploy-demo=nginx:1.14 -n default && kubectl rollout pause deployment deployment-demo -n default
deployment.apps/deployment-demo image updated
deployment.apps/deployment-demo paused
[root@sh-hadoop-journalnode-001 test]# kubectl get deployment -n default
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-demo 5/4 1 5 77m
myapp-deploy1 1/1 1 1 100d
myapp-deploy2 1/1 1 1 100d
[root@sh-hadoop-journalnode-001 test]# kubectl get deployment -n default
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-demo 5/4 1 5 77m
myapp-deploy1 1/1 1 1 100d
myapp-deploy2 1/1 1 1 100d
[root@sh-hadoop-journalnode-001 test]# kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n defaultName Image
deployment-demo-7d69b575c8-8jl5b nginx:1.12
deployment-demo-7d69b575c8-gzltd nginx:1.12
deployment-demo-7d69b575c8-nn9df nginx:1.12
deployment-demo-7d69b575c8-t9gtc nginx:1.12
deployment-demo-8947496fb-gj68v nginx:1.14
# kubectl rollout status deployment deployment-demo -n default
Waiting for deployment "deployment-demo" rollout to finish: 1 out of 4 new replicas have been updated...
# kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-8947496fb-425fw nginx:1.14
deployment-demo-8947496fb-c7fw6 nginx:1.14
deployment-demo-8947496fb-gj68v nginx:1.14
deployment-demo-8947496fb-rxk2k nginx:1.14
回滚deployment 控制器下的应用发布
若上述升级失败，则需要即可执行回滚操作，或者回滚到之前用户指定的历史版本，回滚到此前版本
#kubectl rollout undo deployment deployment-demo -n default
## kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-7d69b575c8-9xcwx nginx:1.12
deployment-demo-7d69b575c8-hqzk8 nginx:1.12
deployment-demo-8947496fb-425fw nginx:1.14
deployment-demo-8947496fb-c7fw6 nginx:1.14
deployment-demo-8947496fb-gj68v nginx:1.14
deployment-demo-8947496fb-rxk2k nginx:1.14
## kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-7d69b575c8-9xcwx nginx:1.12
deployment-demo-7d69b575c8-cv79h nginx:1.12
deployment-demo-7d69b575c8-gz6pv nginx:1.12
deployment-demo-7d69b575c8-hqzk8 nginx:1.12
#回滚到指定版本
# kubectl rollout undo deployment deployment-demo --to-revision=4 -n default
deployment.apps/deployment-demo rolled back
[root@sh-hadoop-journalnode-001 test]# kubectl get pods -l app=deploy,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image -n default
Name Image
deployment-demo-7d69b575c8-9xcwx nginx:1.12
deployment-demo-7d69b575c8-cv79h nginx:1.12
deployment-demo-7d69b575c8-gz6pv nginx:1.12
deployment-demo-7d69b575c8-hqzk8 nginx:1.12
deployment-demo-8947496fb-hdrlf nginx:1.14
#回滚操作中，其revision记录的信息会发生变动，回滚操作会被当做一次滚动更新追加进历史记录中，而被滚动的条目则会被删除。
扩容和缩容
通过修改spec.replicas 即可修改deployment控制器中的POD资源副本的数量，其将实时作用控制器直接生效，deployment控制器是声明式皮遏制，replicas属性的值可直接修改资源配置文件，然后使用"kubectl apply"进行更新，也可使用kubctl edit 进行实时修改，其kubectl scale 是专用扩展POD，包括deployment和job。
缩容
# kubectl patch deployment deployment-demo -p '{"spec":{"replicas":2}}' -n default
deployment.apps/deployment-demo patched
[root@sh-hadoop-journalnode-001 ~]# kubectl get pods -l app=deploy,release=test -n default
NAME READY STATUS RESTARTS AGE
deployment-demo-8947496fb-hdrlf 1/1 Running 0 5h8m
deployment-demo-8947496fb-mljbw 1/1 Running 0 5h8m
扩容POD
#kubectl scale deployment deployment-demo --replicas=3 -n default
调整demployment 文件POD增加至5个
#cat apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-demo
namespace: default
spec:
replicas: 5 # 定义POD副本数量
selector:
matchLabels:
app: deploy
release: test
minReadySeconds: 5 #定期启动后多久认为正常
template: # 定义POD资源
metadata:
name: replicaset-demo
namespace: default
labels: #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
app: deploy
release: test
spec:
containers:
- name: deploy-demo
image: nginx:1.12
ports:
- name: httpd
containerPort: 80
# kubectl apply -f deploy.yml
缩容POD 至1个
# kubectl edit deployment deployment-demo -n default
# kubectl get pods -l app=deploy,release=test -n default
NAME READY STATUS RESTARTS AGE
deployment-demo-7d69b575c8-xcz8s 1/1 Running 0 3m51s
Daemonset 控制器
概述
Daemonset 用于在集群中的全部节点上同时运行一份指定的Pod资源副本，后续新加入集群的节点也会自动创建一个相关的Pod对象，当从集群中移除节点时，此类Pod对象也将被自动回收而无需重建，管理员可使用节点标签进行定义节点相关属性，然后使用节点标签选择器在特定节点上运行Pod对象
应用场景
1 运行集群存储的守护进程，如各节点上运行glusterd或ceph
2 在各节点上运行日志收集守护进程，如fluentd和logstash
3 各个节点上运行监控系统的代理程序
创建资源对象
daemonset 与上述控制器的spec字段使用相同的selector、template、minreadySeconds，其用法相同，但其不支持replicas，因为毕竟不能通过期望值来确定POD资源的数量，而是基于节点。
#cat daemon.yml
# cat daemon.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daem-demo
namespace: default
spec:
minReadySeconds: 5
selector:
matchLabels:
app: daem
template:
metadata:
name: daem-demo
namespace: default
labels:
app: daem
spec:
containers:
- name: daem-demo
image: nginx:1.12
ports:
- name: httpd
containerPort: 80
# kubect apply -f daemon.yml
# kubectl get pods -o wide -n default
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
daem-demo-5mwkp 1/1 Running 0 82s 10.80.27.5 sh-bw-005 <none> <none>
daem-demo-mj8qp 1/1 Running 0 82s 10.80.58.8 sh-bw-004 <none> <none>
注： 自kubernetes1.8开始，daemonset也必须使用selector来匹配Pod模板中指定的标签，并且也支持matchlabels和matchexpressions 两种标签选择器
# kubectl get pods -l app=daem -o custom-columns=NAME:metadata.name,NODE:spec.nodeName -n default
NAME NODE
daem-demo-5mwkp sh-bw-005
daem-demo-mj8qp sh-bw-004
更新daemonset对象
daemonset自1.6版本来时支持更新机制，相关配置嵌套在daemonset.spec.updateStrategy中，其支持滚动更新(RollingUpdate)和删除时更新(OnDelete)两种更新策略，滚动更新为默认的更新策略，其仅支持maxUnavailabe属性定义不可用Pod资源副本数，默认为1，而删除更新则是在删除节点POD资源后重新更新为新版本。
滚动更新
#查看资源
## kubectl get pods -l app=daem -o custom-columns=NAME:metadata.name,NODE:spec.nodeName,Image:spec.containers[0].image -n default
NAME NODE Image
daem-demo-5mwkp sh-bw-005 nginx:1.12
daem-demo-mj8qp sh-bw-004 nginx:1.12
##更新
# kubectl set image daemonset daem-demo daem-demo=nginx:1.14 -n default
daemonset.apps/daem-demo image updated
默认的滚动更新策略是一次删除一个工作节点上的POD资源，等其新版本POD重建完成后再开始操作另一个工作节点上的POD资源
daemonset控制器的滚动更新机制可以借助minreadyseconds 字段控制节奏，必要时可以执行和暂停继续操作。其也可进行回滚
job控制器
概述
job 控制器用户调配Pod对象执行一次性任务，容器中的进程完成任务后容器不会进行重启，而是将其置于completed（完成）状态，若容器中的进程因错误而终止，则需要依据重启策略判断是否需要重启，未运行完成的Pod若节点故障，则其会被调度至其他节点进行处理。
运行方式
1 单工作队列的串行式Job，及以多次一次性的作业方式串行执行多次作业，直至满足期望的次数。
2 多工作队列的并行式Job: 这种方式可以设置工作队列数，每个队列仅负责运行一个作业，也可以使用有限队列运行较多作业，即队列数小于总作业数，相当于多个串行队列一起运行
创建串行JOB
job中内嵌的必选资源为template，其使用方式与deployment等控制相同，job 会为其POD对象自动添加 job-name 和 controller-uid 标签，并使用标签选择器完成与controller-uid标签的关联，配置清单如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-demo
namespace: default
spec:
replicas: 5 # 定义POD副本数量
selector:
matchLabels:
app: deploy
release: test
minReadySeconds: 5 #定期启动后多久认为正常
template: # 定义POD资源
metadata:
name: replicaset-demo
namespace: default
labels: #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
app: deploy
release: test
spec:
containers:
- name: deploy-demo
image: nginx:1.12
ports:
- name: httpd
containerPort: 80
# kubectl apply -f job.yml
job.batch/job-demo created
# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
daem-demo-jtglt 1/1 Running 0 2d11h
daem-demo-trsvc 1/1 Running 0 2d11h
job-demo-jvpx8 1/1 Running 0 12s
myapp-deploy1-577fbb58c6-6g9tg 1/1 Running 0 103d
myapp-deploy2-9db6fcf98-dxfpq 1/1 Running 0 103d
replicaset-demo-llwb6 1/1 Running 0 5d23h
[root@sh-hadoop-journalnode-001 test]# kubectl describe job -n default
Name: job-demo
Namespace: default
Selector: controller-uid=fd784116-1b41-4a3c-8f2e-c19552bc1b7c
Labels: controller-uid=fd784116-1b41-4a3c-8f2e-c19552bc1b7c
job-name=job-demo
Annotations: Parallelism: 1
Completions: 1
Start Time: Wed, 23 Jun 2021 11:05:42 +0800
Pods Statuses: 1 Running / 0 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=fd784116-1b41-4a3c-8f2e-c19552bc1b7c
job-name=job-demo
Containers:
job-demo:
Image: nginx:1.14
Port: <none>
Host Port: <none>
Command:
/bin/bash
-c
sleep 60
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 30s job-controller Created pod: job-demo-jvpx8
创建并行JOB
job.spec.parallelism ： 并行度量，及队列的数量
job.spec.completions： 作业数量，其总数量
创建5个作业的串行job,每个job60s后自动关闭
# cat job1.yml
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo1
namespace: default
spec:
completions: 3
template:
spec:
containers:
- name: job-demo1
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，不进行重启
# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
job-demo1-4zzcm 0/1 Completed 0 2m3s
job-demo1-82n67 0/1 Completed 0 4m7s
job-demo1-k2vtz 0/1 Completed 0 3m5s
创建5个job的并行为3的并行作业
# cat job2.yml
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo2
namespace: default
spec:
completions: 5
parallelism: 3
template:
spec:
containers:
- name: job-demo2
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，不进行重启
## kubectl apply -f job2.yml
# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
job-demo1-4zzcm 0/1 Completed 0 5m23s
job-demo1-82n67 0/1 Completed 0 7m27s
job-demo1-k2vtz 0/1 Completed 0 6m25s
job-demo2-h7f94 1/1 Running 0 6s
job-demo2-hpbxf 1/1 Running 0 6s
job-demo2-xw9c6 1/1 Running 0 6s
JOB 扩容
job 控制器的.spec.parallelism 定义的并行度表示同时运行Pod对象数，此属性值支持运行时调整从而改变队列总数，实现扩容和缩容，其必须是前面的JOB 未运行完，若运行完成的job，则其无相关效果
删除JOB
# kubectl delete -f job2.yml
job.batch "job-demo2" deleted
# cat job2.yml
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo2
namespace: default
spec:
completions: 5
parallelism: 1
template:
spec:
containers:
- name: job-demo2
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，不进行重启
# kubectl apply -f job2.yml
# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
job-demo1-4zzcm 0/1 Completed 0 37m
job-demo1-82n67 0/1 Completed 0 39m
job-demo1-k2vtz 0/1 Completed 0 38m
job-demo2-tzw48 1/1 Running 0 14s
POD数量扩容至3个
# kubectl get jobs -n default
NAME COMPLETIONS DURATION AGE
job-demo1 3/3 3m6s 42m
job-demo2 3/5 3m12s 3m12s
# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
job-demo1-4zzcm 0/1 Completed 0 39m
job-demo1-82n67 0/1 Completed 0 41m
job-demo1-k2vtz 0/1 Completed 0 40m
job-demo2-fd2kd 0/1 Completed 0 89s
job-demo2-km2p6 1/1 Running 0 27s
删除
job 控制器待其POD资源运行完成后，将不再占用系统资源，用户可以按需保留或使用资源删除命令删除。但若某些资源无法正常结束，且其重启策略是restartPolicy是 Always，则其会一致重启，但job 提供了两个属性用于抑制这种情况发生：
job.spec.activeDeadlineSeconds ： 用于定义其最大活动时间长度，若超出则被终止
job.spec.backoffLimit： 用于设置其失败状态之前重试次数，默认为6次
CronJob 控制器
概述
cronjob 控制器用于管理Job控制器资源的运行时间，job控制器定义的作业做任务在执行控制器资源创建之后便会立即执行，但cronjob可以以类似Linux系统的周期性任务计划的方式控制器运行的时间点击重复运行的方式，具体如下：
1 在未来某一时间运行作业一次
2 在指定的时间点重复运行作业
crpnjob控制器在指定的时间点时，“” 和 "*"意义相同，都表示任何可用的有效值。
创建CronJob对象
cronjob 可嵌套的核心字段 cronjob.spec
jobTemplate ： job 控制器模板，用于为cronjob控制器生成job对象，必选字段。
schedule： cron格式的调度作业，必选字段
concurrencyPolicy：并发执行策略，有allow，forbid和replace，用于定义前一次作业运行尚未完成时是否以及如何运行后一次作业。
failedJobsHistoryLimit： 为失败的历史构建保留次数，默认为1
successfulJobsHistoryLimit： 为成功的任务执行保留的历史记录数，默认是3
startingDeadlineSeconds：因各种原因缺乏执行作业的时间点所导致的启动作业错误的超时时长，会被记录入错误历史记录。
suspend： 是否挂起后续的执行任务，默认为false。
# cat cronjob.yml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cronjob-demo
namespace: default
spec:
schedule: "*/1 * * * *" #1分钟运行一次
jobTemplate:
spec:
parallelism: 2 # 每次运行两个
template:
spec:
containers:
- name: cronjob-demo
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，不进行重启
#kubectl apply -f cronjob.yml
#kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
cronjob-demo-1624429020-46tlc 1/1 Running 0 28s
cronjob-demo-1624429020-psgx9 1/1 Running 0 28s
# kubectl get cronjob -n default
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob-demo */1 * * * * False 0 <none> 54s
schedule 是其调度时间点，suspend 表示后续任务是否处于挂起状态，及暂停任务调度和运行，active表示活动状态的job对象的数量，而last schedule则表示上次调度运行至此时刻的时长。
cronjob控制机制
cronjob 控制器是一个更高级别的资源，其以job控制器资源为其管控对象，并借助它管理Pod资源对象。因此，要使用类似的命令来查看某cronjob控制器创建的job对象，其只会在相关Job对象被执行时能够看到此类现象，可列出的job对象的数量取决于cronjob资源的cronjob.spec.successfulJobsHistoryLimit的属性值，默认是3
## kubectl get jobs -n default
NAME COMPLETIONS DURATION AGE
cronjob-demo-1624429080 2/1 of 2 62s 3m48s
cronjob-demo-1624429140 2/1 of 2 63s 2m57s
cronjob-demo-1624429200 2/1 of 2 63s 117s
cronjob-demo-1624429260 0/1 of 2 57s 57s
如果作业重复执行时指定的时间点较接近，而执行时长跨过了其两次执行的时间长度，则会出现两个job对象同时存在的情形，有些job对象可能会存在无法或者不能同时运行的情况，这时候则需要"cronjob.spec.concurrencyPolicy"属性控制作业的并存机制，其默认为allow，及允许前后job，甚至属于同一个cronjob的更多job同时运行，forbid用于禁止前后两个job同时运行，若上一个尚未结束，则不允许启动后一个，replace 用于让后一个job取代前一个，及终止前一个并启动后一个。
