标签：beta suspend fail 进程 兼容 fluentd 将不 and 18C
一 概述自主POD调度绑定至节点若主程序崩溃则节点kubelet能够自动重启容器，但若是非主进程崩溃类的容器kubelet无从感知。这便需要依赖于POD对象定义的存活探测，以便kubelet能够探知到此类故障，但若pod被删除或者工作节点自身发生故障（工作节点上都有kubelet，kubelet不可用，因此其健康状态便无法保证），则便需要控制器来处理相应的容器重启和配置。
POD 控制器有master 的 kube-controller-manager组件提供，其类型有：
1 replicationcontroller
2 replicaset
3 deployment
4 daemonset
5 statefulset
6 job
7 cronjob
kubernetes的核心之一是确保各资源对象的当前状态以匹配用户期望的状态，使当前状态不断向期望状态靠近的方式来完成容器应用和管理。
控制器通过api server 提供的接口持续监控相关资源对象的当前状态，并在因故障灯导致系统发生变化时，尝试让资源向期望状态迁移和逼近。
list-watch ： kubernetes 的核心机制之一，其在资源状态发生变化时，由API server 负责写入etcd并通过水平触发机制主动通知给相关客户端程序企鹅包不会错过事件，控制器通过api server 的watch 接口实时监控目标资源对象的变动和执行趋近操作，并不会与其他控制器进行交互。
pod 控制器通过（list-watch）监控集群中y运行着的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，因此不具备第二个选项。
kubernetes 中replicaset是取代早期的replicationcontroller，其replicationcontroller将被废弃，但其功能和replicaset基本类似。
replicaset 用于保证其管理的POD对象副本数量在任意时刻都能精确满足期望数量，其原理是：控制器资源在启动后会查找集群中欧匹配其标签选择器的POD资源对象，当前活动对象的数量与期望数量不吻合时，则删除或创建POD。
replicaset能够实现的功能
1 确保POD资源独享的数值精确反应期望值
2 确保POD健康运行：探测到期POD对象因工作节点故障而不可用时，会自动由调度器调度至其他节点创建缺失的POD副本。
3 弹性伸缩：可通过replicaset控制器动态调整相关POD资源对象数量，必要时还可以通过HPA 控制器实现POD资源规模的自动伸缩。
replicas： 用于定义当前期望副本数量
selector： 用于选择和计数当前POD的数量
template：用于定义POD资源信息
minreadysecond： 用于定义POD启动后多长时间为可用状态
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部署
kubectl apply -f replicaset1.yaml 查看
删除对应pod后新的POD已经被创建，副本数仍然是两个
kubectl label pods replicaset-demo-lbvl4 app= release= --overwrite查看其POD副本数已上升至3个，因其中一个标签不符合要求
kubectl run nginx10 --image=nginx:1.14 -l app=replicaset1,release=test查看
删除了其余的pod（replicaset-demo开头的）
1 查看控制器
kubectl get replicaset
2 查看控制器中POD变化信息
kubectl describe replicaset replicaset-demo
事实上，replicaset控制器能够对POD对象数目的异常进行响应是因为其向API server注册监听了watch 相关资源及列表的变动信息，于是API server会在变动发生时立即通知给相关的监听客户端。
其更新主要是replicas 和template 字段进行的，毕竟对标签的带动是很少的，修改template就是更新POD，修改replicas就是扩容或缩容。
replicas 控制器的POD template 的变更只会影响新建的POD对象，对于已经存在的副本没有影响，因此，若更新版本，则在修改了template.spec.containers.image 之后，还需要删除之前版本对应的副本或按一定方式进行更新。
修改配置文件中image
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.12 #修改了镜像
ports:
- name: httpd
containerPort: 80部署
kubectl replace -f replicaset1.yaml查看相关镜像
kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image
删除对应的POD
kubectl delete pods -l app=replicaset1,release=test查看POD
kubectl get pods -l app=replicaset1,release=test -o custom-columns=Name:metadata.name,Image:spec.containers[0].image
更新方式
1 一次性删除控制器相关的所有POD副本或更改相关标签
2 分批删除就有的POD副本或更新其标签，滚动更替，更替期间新旧版本共存。
改动replicaset控制器对象配置中期望的POD副本数量会由控制器实时响应，从而实现应用规模的水平伸缩，kubelet提供了专用的子命令scale 用于实现应用规模的伸缩，它支持从资源清单文件中获取新的目标副本数量，也可直接在命令中获取"--replicas"选项进行读取
扩容
kubectl scale replicasets replicaset-demo --replicas=5查看
缩容
kubectl scale replicasets replicaset-demo --replicas=1查看
配置文件扩容
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: replicaset-demo
namespace: default
spec:
replicas: 3 # 定义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部署
kubectl apply -f replicaset1.yaml 查看 
使用kubectl delete命令删除replicaset对象时默认会一并删除其管控的各POD对象，有时，考虑到这些POD未必尤其创建，或者即使尤其创建却也并非其自身的组成部分，故而可以为命令使用"--cascade=false"取消级联，删除相关POD对象，
查看replicaset创建的POD 
删除POD
kubectl delete replicasets replicaset-demo --cascade=false查看
deployment 是kubernetes控制器的另一种实现，其构建与replicaset控制器之上，可为POD和replicaset资源提供声明式更新。
deployment控制器资源的主要职责是为了保证POD资源的健康运行，其不同于replicaset的功能：
1 事件和状态查看：必要时可以查看deployment对象升级的详细进度和状态
2 回滚：升级操作完成后发现问题，支持使用回滚机制将应用程序返回到前一个由用户指定的历史记录版本中
3 版本记录：对deployment 对象的每一次升级操作都予以保存，以供后续可能的回滚操作
4 暂停和启动：对于每一次更新，都能够随时暂停和启动
5 多种自动更新方案： 一个是recreate，及重建机制，全面停止、删除旧有的POD后用心版本替代，另一种是rollingupdate，及滚动升级机制，逐步替换旧有的POD到新版本。
其核心资源和replicaset相似
apiVersion: extensions/v1beta1
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查看：
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"选项。
修改POD模板相关的配置参数以便完成deployment控制器资源的更新，由于是声明式配置，因此对deployment控制器的修改使用apply 和patch 命令进行，若仅是修改镜像，则可使用set image 即可
修改副本数量
kubectl patch deployment deployment-demo -p ‘{"spec":{"replicas":4}}‘查看配置 
修改更新等待时间
kubectl patch deployment deployment-demo -p ‘{"spec":{"minReadySeconds":4}}‘查看
注： 修改deployment控制器的minreadyseconds，replicas 和 strategy 等字段值并不会触发POD资源更新操作，因为其不属于模板的内嵌字段，对现存的POD对象不会产生任何影响
实例
之前版本 
更新操作
kubectl edit deployment deployment-demo修改镜像
查看 
使用kubectl set image 更新镜像
kubectl set image deployment deployment-demo deploy-demo=nginx:1.12其中deployment-demo 是deployment的名称， deploy-demo 是其控制器中containers.name的名称
查看其版本
deployment 控制器还支持金丝雀发布，及随时展厅或继续更新操作，通过 maxsurge 和 maxunavailable属性还能实现更为精巧的控制过程，其采用先添加再删除的方式，且可用POD资源对象总数不低于期望值的方式进行，配置如下：
kubectl patch deployments deployment-demo -p ‘{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}‘在修改相应容器的镜像版本后立即暂停更新进度，其会在启动第一批新版本POD对象后转为暂停，这里之所以能暂停，是因为第一步设置了其maxReadySeconds属性时长，因此用户要在更新命令启动后此时长指定的时间范围内启动暂停操作。
kubectl set image deployment deployment-demo deploy-demo=nginx:1.14 && kubectl rollout pause deployment deployment-demo查看 
查看更新情况
kubectl rollout status deployment deployment-demo
旧版本的4个因为不超出5个，上述定义的是1个
全部更新
kubectl rollout resume deployment deployment-demo查看 
若上述升级失败，则需要即可执行回滚操作，或者回滚到之前用户指定的历史版本，回滚到此前版本
kubectl rollout undo deployment deployment-demo查看 
查看历史版本
kubectl rollout history deployment deployment-demo
回滚到指定版本
kubectl rollout undo deployment deployment-demo --to-revision=4查看
回滚操作中，其revision记录的信息会发生变动，回滚操作会被当做一次滚动更新追加进历史记录中，而被滚动的条目则会被删除。
通过修改spec.replicas 即可修改deployment控制器中的POD资源副本的数量，其将实时作用控制器直接生效，deployment控制器是声明式皮遏制，replicas属性的值可直接修改资源配置文件，然后使用"kubectl apply"进行更新，也可使用kubctl edit 进行实时修改，其kubectl scale 是专用扩展POD，包括deployment和job。
相关配置
将POD减少为2个
kubectl patch deployment deployment-demo -p ‘{"spec":{"replicas":2}}‘将POD增加为3个
kubectl scale deployment deployment-demo --replicas=3将POD增加为4个
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: deployment-demo
namespace: default
spec:
replicas: 4 # 定义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 将其减少为1个
kubectl edit deployment deployment-demo修改 
并保存
查看
daemonset 用于在集群中的全部节点上同时运行一份指定的Pod资源副本，后续新加入集群的节点也会自动创建一个相关的Pod对象，当从集群中移除节点时，此类Pod对象也将被自动回收而无需重建，管理员可使用节点标签进行定义节点相关属性，然后使用节点标签选择器在特定节点上运行Pod对象
1 运行集群存储的守护进程，如各节点上运行glusterd或ceph
2 在各节点上运行日志收集守护进程，如fluentd和logstash
3 各个节点上运行监控系统的代理程序。
daemonset 与上述控制器的spec字段使用相同的selector、template、minreadySeconds，其用法相同，但其不支持replicas，因为毕竟不能通过期望值来确定POD资源的数量，而是基于节点。
相关配置
apiVersion: extensions/v1beta1
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部署
kubectl apply -f daemonsey.yaml 查看 
注： 自kubernetes1.8开始，daemonset也必须使用selector来匹配Pod模板中指定的标签，并且也支持matchlabels和matchexpressions 两种标签选择器
kubectl get pods -l app=daem -o custom-columns=NAME:metadata.name,NODE:spec.nodeName查看POD部署位置 
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 kubectl set image daemonset daem-demo daem-demo=nginx:1.14默认的滚动更新策略是一次删除一个工作节点上的POD资源，等其新版本POD重建完成后再开始操作另一个工作节点上的POD资源
daemonset控制器的滚动更新机制可以借助minreadyseconds 字段控制节奏，必要时可以执行和暂停继续操作。其也可进行回滚
job 控制器用户调配Pod对象执行一次性任务，容器中的进程完成任务后容器不会进行重启，而是将其置于completed（完成）状态，若容器中的进程因错误而终止，则需要依据重启策略判断是否需要重启，未运行完成的Pod若节点故障，则其会被调度至其他节点进行处理。
1 单工作队列的串行式Job，及以多次一次性的作业方式串行执行多次作业，直至满足期望的次数。
2 多工作队列的并行式Job: 这种方式可以设置工作队列数，每个队列仅负责运行一个作业，也可以使用有限队列运行较多作业，即队列数小于总作业数，相当于多个串行队列一起运行
job中内嵌的必选资源为template，其使用方式与deployment等控制相同，job 会为其POD对象自动添加 job-name 和 controller-uid 标签，并使用标签选择器完成与controller-uid标签的关联，配置清单如下:
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
spec:
template:
spec:
containers:
- name: job-demo
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，发生错误，不进行重启部署
kubectl apply -f job.yaml查看状态
查看其标签选择器和标签 
job.spec.parallelism ： 并行度量，及队列的数量
job.spec.completions： 作业数量，其总数量
创建5个作业的串行job,每个job60s后自动关闭
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo1
spec:
completions: 3
template:
spec:
containers:
- name: job-demo1
image: nginx:1.14
command: ["/bin/bash","-c","sleep 60"]
restartPolicy: Never #重启策略，不进行重启查看
目前已经有一个JOB执行完成了，正在执行第二个JOB
创建5个job的并行为3的并行作业
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo2
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.yaml 查看
因为其队列为3，因此同时可创建3个POD进行作业，总共5个，需要2分钟完成
job 控制器的.spec.parallelism 定义的并行度表示同时运行Pod对象数，此属性值支持运行时调整从而改变队列总数，实现扩容和缩容，其必须是前面的JOB 未运行完，若运行完成的job，则其无相关效果
删除job2并修改
kubectl delete -f job2.yaml 修改其队列数值为1
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo2
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.yaml 查看当前POD
一个POD
修改至3个
kubectl scale jobs job-demo2 --replicas=3
同时运行三个job
job 控制器待其POD资源运行完成后，将不再占用系统资源，用户可以按需保留或使用资源删除命令删除。但若某些资源无法正常结束，且其重启策略是restartPolicy是 Always，则其会一致重启，但job 提供了两个属性用于抑制这种情况发生：
job.spec.activeDeadlineSeconds ： 用于定义其最大活动时间长度，若超出则被终止
job.spec.backoffLimit： 用于设置其失败状态之前重试次数，默认为6次
cronjob 控制器用于管理Job控制器资源的运行时间，job控制器定义的作业做任务在执行控制器资源创建之后便会立即执行，但cronjob可以以类似Linux系统的周期性任务计划的方式控制器运行的时间点击重复运行的方式，具体如下：
1 在未来某一时间运行作业一次
2 在指定的时间点重复运行作业crpnjob控制器在指定的时间点时，"" 和 "*"意义相同，都表示任何可用的有效值。
cronjob 可嵌套的核心字段 cronjob.spec
jobTemplate ： job 控制器模板，用于为cronjob控制器生成job对象，必选字段。
schedule： cron格式的调度作业，必选字段
concurrencyPolicy：并发执行策略，有allow，forbid和replace，用于定义前一次作业运行尚未完成时是否以及如何运行后一次作业。
failedJobsHistoryLimit： 为失败的历史构建保留次数，默认为1
successfulJobsHistoryLimit： 为成功的任务执行保留的历史记录数，默认是3
startingDeadlineSeconds：因各种原因缺乏执行作业的时间点所导致的启动作业错误的超时时长，会被记录入错误历史记录。
suspend： 是否挂起后续的执行任务，默认为false。
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cronjob-demo
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.yaml 查看
schedule 是其调度时间点，suspend 表示后续任务是否处于挂起状态，及暂停任务调度和运行，active表示活动状态的job对象的数量，而last schedule则表示上次调度运行至此时刻的时长。
cronjob 控制器是一个更高级别的资源，其以job控制器资源为其管控对象，并借助它管理Pod资源对象。因此，要使用类似的命令来查看某cronjob控制器创建的job对象，其只会在相关Job对象被执行时能够看到此类现象，可列出的job对象的数量取决于cronjob资源的cronjob.spec.successfulJobsHistoryLimit的属性值，默认是3
如果作业重复执行时指定的时间点较接近，而执行时长跨过了其两次执行的时间长度，则会出现两个job对象同时存在的情形，有些job对象可能会存在无法或者不能同时运行的情况，这时候则需要"cronjob.spec.concurrencyPolicy"属性控制作业的并存机制，其默认为allow，及允许前后job，甚至属于同一个cronjob的更多job同时运行，forbid用于禁止前后两个job同时运行，若上一个尚未结束，则不允许启动后一个，replace 用于让后一个job取代前一个，及终止前一个并启动后一个。
标签：beta suspend fail 进程 兼容 fluentd 将不 and 18C
原文地址：https://blog.51cto.com/11233559/2370233
