做网页怎么在网站播放视频,成立公司需要几个股东,销售类网站开发架构,网站的布局方式有哪些方面1 Why need Deployment?
K8S中Pod是用户管理工作负载的基本单位#xff0c;Pod通常通过Service进行暴露#xff0c;因此#xff0c;通常需要管理一组Pod#xff0c;RC和RS主要就实现了一组Pod的管理工作#xff0c;其中#xff0c;RC和RS的区别在于#xff0c;RS提供更…1 Why need Deployment?
K8S中Pod是用户管理工作负载的基本单位Pod通常通过Service进行暴露因此通常需要管理一组PodRC和RS主要就实现了一组Pod的管理工作其中RC和RS的区别在于RS提供更加高级的选择器(RS支持基于集合的选择符)。
在实际生产环境中应用在初次部署完成后当测试正常才会对外提供服务之后就都是升级操作而升级过程中意味着删除老的Pod并创建新的Pod。对于RS而言如果需要升级Pod的镜像可以使用kubectl edit修改RS中的Pod的镜像或者直接修改RS的资源文件然后执行kubectl apply但是这样做的话会使得服务在短期内的不可用。虽然Service可以保证请求只路由到ready的Pod并且RS会按照一定的策略删除老的Pod然后再创建新的Pod但是在删除和创建的过程中可能无法保证服务的正常无法保证永远有Pod在ready状态无法保证有一定数量的Pod在处理请求。
为了解决服务更新的问题K8S在RS的基础上提供了Deployment它最大的特点是提供了滚动升级的能力并且可以控制升级的速率使得升级过程中可以正常提供服务因此通常都是使用Deployment而不是RC或者RS。
2 Problem of ReplicaSet
设想一下在只有RS的情况下如何进行滚动升级当然在设计滚动升级流程之前必须要明确几个目标
升级过程中有固定数量的Pod提供服务为了保证服务不发生抖动给定灰度的时间可以减缓升级的速率如果升级过程中发现请求处理异常可以及时回退
为了实现这些目标在只有RS的情况下你可能会这么做(假设RS的replicas为3)
用新的Pod的template创建新的RS然后在RS的selector中新增标签假设为A并且RS的replicas设置为0在原来的RS的selector和Pod中都加一个标签假设为B这样的话这些Pod就只被老的RS管理并通过Service对外暴露将老的RS的replicas减1新的RS的replicas加1现在old_replicas2new_replicas1并且由于A、B的存在新老RS只管理各自的Pod互不干扰而这些Pod都可以被Service选择此时Service的Pod同时有新老两个版本这时候就可以通过监控查看成功率如果没有问题等待一段时间(相当于灰度时间)确认新的Pod没有问题继续升级老的RS的replicas继续减1新的RS的replicas继续加1现在old_replicas1new_replicas2继续关注监控指标继续升级old_replicas0new_replicas3此时所有的Pod都升级到了新版本
升级过程中总是有3个Pod提供服务如果升级过程发现异常可以直接修改old_replicas进行回退同时为了持续观察新的Pod的情况在新的Pod创建完成后不是立刻就对外提供服务而是会等待一段时间用于观察请求成功率从而决定是否继续进行升级。
上面的过程比较复杂而且灰度期间如果有问题需要人工回滚为了解决滚动更新的问题K8S提供了Deployment相比于ReplicaSet它最大的优势就是滚动更新。
3 What is Deployment
从基础字段上看Deployment跟ReplicaSet没有任何区别都是在Pod的基础上增加replicas字段保证副本的数量Deployment的主要功能也是保证副本的数量。但是为了保证服务的可用性相比于ReplicaSetDeployment提供了滚动更新的能力。
Deployment提供的滚动更新跟上面的人工更新过程类似也是创建额外的RS然后修改新老RS的replicas值然后再添加一些策略例如是全部一起更新还是一个接一个的更新。
4 How to use Deployment
由于Deployment要创建多个Pod的副本因此Deployment中十分重要的字段就是PodTemplate和副本数deployment.spec.template、deployment.spec.replicas。
剩下的字段基本都跟升级相关
deployment.spec.progressDeadlineSeconds当Deployment在一段时间内还没有升级成功则会在deployment.status.conditions中的Progressing设置为Falsedeployment.spec.revisionHistoryLimit保存用于回滚的历史版本数量默认是10deployment.spec.strategy升级策略这里有两种策略Recreate、RollingUpdate。当deployment.spec.strategy.typeRollingUpdate时表示滚动更新并且可以设置deployment.spec.strategy.rollingUpdate.maxSurge最大峰值升级过程中可以创建出的超过预期pod数量的pod个数和deployment.spec.strategy.rollingUpdate.maxUnavailable最大不可用升级过程中不可用的pod的数量可以使用数字和百分比。当deployment.spec.strategy.typeRecreate时会干掉所有pod当所有pod被干掉后再创建新的pod。
kubectl create deployment --imagenginx my-nginx上述语句创建了一个nginx的deployment副本数和升级策略都是用的默认值replcas1maxSurge25%maxUnavailable25%。
4.1 Deployment相关资源和字段解释
kubectl get deploy my-nginx上述命令可与查看该deployment输出的结果中有三个重要字段
READY就绪的pod数量UP-TO-DATEpod的定义与deployment中的Pod模板相同的pod的个数AVAILABLE可用的pod数量
4.2 Deployment的升级
Deployment通常通过更新镜像进行升级
kubectl set image deploy my-nginx nginxnginx:1.9.1
kubectl annotate deploy my-nginx kubernetes.io/change-causeset nginx to 1.9.1上述语句先更新my-nginx这个Deployment的nginx容器的镜像再使用annotate设置变更的原因最后可以使用kubectl rollout status deploy my-nginx查看更新状态。
执行kubectl describe deploy my-nginx可以查看更新过程 同时可以查看历史版本 这里的CHANGE-CAUSE就是上面设置的annotate另外这里需要注意的是这里只会保存不重复的版本如果用两个镜像交替更新这里只会保存两个版本。
4.3 Deployment的回滚
当升级过程中出现问题如果是升级过程就卡主了例如pod没起来或者拉取镜像失败老的pod不会被干掉此时也不会有啥问题。如果是程序的bug造成的问题通过监控或者其他方式验证发现了问题可以对Deployment进行回滚。
kubectl rollout undo deploy my-nginx此时deployment会回到上个版本并且在rollout history中可以看到之前的版本换到了最新版本版本号加1 当然也可以回滚到指定版本
kubectl rollout undo deploy my-nginx --to-revision34.4 Deployment的手动缩放
当pod数量不够或者过多时可以手动修改Deployment的replicas配置
kubectl scale deploy my-nginx --replicas3收到将Deployment的副本数设置为3。
5 小结
Deployment作为k8s中无状态部署的最常用的资源所有的业务逻辑层的高可用和负载均衡都会用它来部署。当Deployment资源已经创建后可以通过kubectl set image和kubectl scale更新镜像和副本数还能够使用kubectl rollout undo进行回滚同时可以使用kubectl rollout history查看历史版本。
