欧赛网站建设,那块做微信平台网站,本地建设网站,百度竞价排名广告定价鲜花当集群中的某个服务需要升级时#xff0c;我们需要停止目前与该服务相关的所有pod#xff0c;然后下载新版本镜像并创建新的pod。如果集群规模比较大#xff0c;则这个工作变成了一个挑战#xff0c;而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。kubernet…当集群中的某个服务需要升级时我们需要停止目前与该服务相关的所有pod然后下载新版本镜像并创建新的pod。如果集群规模比较大则这个工作变成了一个挑战而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。kubernetes提供了滚动升级功能来解决上述问题。如果pod是通过Deployment创建的则用户可以在运行时修改Deployment的pod定义(spec.template)或镜像名称并应用到Deployment对象上系统即可完成Deployment的rollout动作rollout可被视为Deployment的自动更新或者自动部署动作如果在更新过程中发生了错误则还可以通过回滚操作恢复pod的版本二、Deployment升级 下面以nginx的deployment为例apiversion: apps/v1kind: Deploymentmetadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 3 template: metadata: labels: app: nginx spec containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80可以看到已运行的副本数有3个那么如果想升级nginx的版本为1.9.1该如何操作呢1. 升级方式方式一set image命令可以通过kubectl set image命令为Deployment设置新的镜像名称:方式一edit命令另一种更新的方法是使用kubectl edit命令修改Deployment的配置将 spec.template.spec.containers[0].image从nginx: 1.7.9更改为nginx:1.9.1:2. 查看过程镜像名或pod定义一旦发生了修改则将触发系统完成Deployment所有运行pod的滚动升级操作。可以使用 kubectl rollout status 命令查看Deployment的更新过程查看当前运行的pod名称已经更新了查看pod使用的镜像已经更新为Nginx:1.9.1了3. 升级原理Deployment升级pod的流程如下step1初始创建Deployment时系统创建了一个ReplicaSet nginx--deployment-4o87004473并按用户的需求创建了3个Pod副本step2更新Deployment时系统创建了一个新的ReplicaSetnginx-deployment- 3599678771)并将其副本数量扩展到1然后将旧的ReplicaSet缩减为2step3之后,系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整step4最后新的ReplicaSet运行了3个新版本的Pod副本旧的ReplicaSet副本数量则缩减为0我们可以使用kubectl describe deployments/nginx-deployment命令仔细观察Deployment的更新过程运行kubectl get rs命令,查看两个ReplicaSet的最终状态:在整个升级过程中系统会保证至少有两个pod可用并且最多同时运行4个pod这是Deployment通过复杂的算法完成的。Deployment需要确保在整个更新 过程中只有一定数量的pod可能处于不可用状态。在默认情况下Deployment确保可用的pod总数量至少为所需的副本数量(DESIRED)减1也就是最多1个不可用(maxUnavailables1)。Deploymenti还需要确保在整个更新过程中pod的总数量不会超过所需的副本数量太多。在默认情况下Deployment确保pod的总数量最多比所需的pod数量多1个也就是最多1个浪涌值maxSurge-1)。Kubernetes从1.6版本开始maxUnavailable和maxSurgef的默认值将从1、1更新为 所需副本数量的25%、25%。这样在升级过程中Deployment就能够保证服务不中断并且副本数量始终维持为用户指定的数量(DESIRED)。三、Deployment回滚 如果在Deployment升级过程中出现意外比如写错新镜像的名称、新镜像还没被放入镜像仓库里、新镜像的配置文件发生不兼容性改变、新镜像的启动参数不对以及因可能更复杂的依赖关系而导致升级失败等就需要回退到之前的旧版本这时就可以用到Deploymentl的回滚功能了。1. 回滚方式我们将Deployment回滚到之前的版本时只有Deployment的pod模板部分会被修改在默认情况下所有Deployment的发布历史记录都被保留在系统中可以配置历史记录数量)以便于我们随时进行回滚操作。注意在创建Deployment时使用-record参数就可以在CHANGE-CAUSE列看到每个版本使用的命令了如果需要查看特定版本的详细信息则可以加上-revision-参数现在我们决定撤销本次发布并回滚到上一个部署版本kubectl rollout undo deployment/nginx-deployment deployment nginx-deployment rolled back这样该Deployment就回滚到之前的稳定版本了可以从Deployment的事件信息中查看到回滚到版本2的操作过程四、其它 1. 暂停和恢复Deployment的部署操作通过kubectl rollout pause命令暂停Deployment的更新操作:kubectl rollout pause deployment/nginx-deployment deployment nginx-deployment paused然后修改Deployment的镜像信息:kubectl set image deploy/nginx-deployment nginxnginx:1.9.1deployment nginx-deploymentimage updated查看Deployment的历史记录发现并没有触发新的Deployment部署操作最后恢复这个Deployment的部署操作$ kubectl rollout resume deploy nginx-deployment deployment nginx-deploymentresumed可以看到一个新的ReplicaSet被创建出来了2.DaemonSet的更新策略目前DaemonSet的升级策略updateStrategy)包括两种升级策略描述OnDeleteDaemonSet的默认升级策略与1.5及之前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时在创建好新的DaemonSeti配置之后新的Pod并不会被自动创建直到用户手动删除旧版本的Pod才触发新建操作即只有手工删除了DaemonSet创建的Pod副本新的Pod 副本才会被创建出来。如果不设置updateStrategy的值则在Kubernetes 1.6之后的版本中会被作为updateStrategyl的默认设置RollingUpdate从Kubernetes1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSeti进行更新时旧版本的Pod将被自动杀 掉然后自动创建新版本的DaemonSet Pod。整个过程与普通Deployment的滚动升级一样是可控的。不过有两点不同于普通Pod的滚动升级一是目前Kubernetes还不支持查看和管理DaemonSetl的更新历史记录二是DaemonSet的 回滚(Rollback)并不能如同Deployment一样直接通过kubectl rollback命令来实现必须通过再次提交旧版本配置的方式实现下面是DaemonSet采用RollingUpdate升级策略的YAML定义:apiversion: apps/v1kind: DaemonSetmetadata: name: goldpingerspec:updatestrategy:type: RollingUpdate3.StatefulSet的更新策略StatefulSet实现了RollingUpdate、OnDelete和Partitioned这几种策略以保证StatefulSet中各Pod有序地、逐个地更新并且能够保留更新历史也能回滚到某个历史版本如果用户未设置updateStrategy字段则系统默认使用RollingUpdate策略:策略描述RollingUpdateStatefulSet Controller会删除并创建StatefulSet相关的每个Pod对象其处理顺序与StatefulSet终止Pod的顺序一致即从序号最大的Pod开始重建每次更新一个PodOrderedReady可能在更新过程中发生一些意外从而导致StatefulSet陷入奔溃状态此时需要用户手动修 复OnDeleteStatefulSet Controller并不会自动更新StatefulSet中的Pod实例而是需要用户手动删除这些Pod并触发StatefulSet Controller创建新的Pod实例来弥补因此这其实是一种手动升级模式Partitioned在这种模式下 用户指定一个序号StatefulSet中序号大于等于此序号的Pod实例会全部被升级 小于此序号的Pod实例则保留旧版本不变即使这些Pod被删除、重建也仍然保 持原来的旧版本。这种分区升级策略通常用于按计划分步骤的系统升级过程中。
