网站js聊天代码,如何把网站做成软件,科技公司起名大全免费,hexo导入wordpress目录 一、常见的发布方式 二、详解kubectl陈述式方式做灰度发布#xff08;金丝雀发布#xff09; 步骤一#xff1a;先基于deployment控制器创建pod#xff0c;然后发布 步骤二#xff1a;基于命令行灰度发布 步骤三#xff1a;测试等到版本稳定以后#xff0c;再完…目录 一、常见的发布方式 二、详解kubectl陈述式方式做灰度发布金丝雀发布 步骤一先基于deployment控制器创建pod然后发布 步骤二基于命令行灰度发布 步骤三测试等到版本稳定以后再完成继续发布 三、滚动发布详解 一、常见的发布方式 蓝绿发布:两套环境交替升级旧版本保留一定时间便于回滚 特点对用户无感是最安全的发布方式需要两套系统对资源要求比较高成本高 灰度发布:根据比例将老版本升级例如80%用户访问是老版本20%用户访问是新版本 特点对自动要求比较高对比起来系统更加稳定发布如果遇到问题可以减少影响范围 滚动发布:按批次停止老版本实例启动新版本实例。 特点节约资源用户无感但是部署和回滚的速度慢 三种方式均可以做到平滑式升级在升级过程中服务仍然保持服务的连续性升级对外界是无感知的。那生产上选择哪种部署方法最合适呢?这取决于哪种方法最适合你的业务和技术需求。 如果你们运维自动化能力储备不够肯定是越简单越好建议蓝绿发布如果业务对用户依赖很强建议灰度发布。如果是K8S平台滚动更新是现成的方案建议先直接使用。 二、详解kubectl陈述式方式做灰度发布金丝雀发布 金丝雀发布Canary Release Deployment控制器支持自定义控制更新过程中的滚动节奏如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程此时仅存在一部分新版本的应用主体部分还是旧的版本。然后再筛选一小部分的用户请求路由到新版本的Pod应用继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新否则立即回滚更新操作。这就是所谓的金丝雀发布。 步骤一先基于deployment控制器创建pod然后发布 kubectl -n testapp create deployment deploy-nginx --imagesoscscs/myapp:v1 --port80 --replicas3 //创建podkubectl -n testapp expose deployment deploy-nginx --name svc-nginx --type NodePort --port9090 --target-port80 //首次发布curl 10.96.241.117:9090 //基于clusterip访问curl 192.168.20.15:32295 //基于nodeip:nodeport访问 步骤二基于命令行灰度发布 kubectl -n testapp set image deployment deploy-nginx myappsoscscs/myapp:v2 kubectl -n testapp rollout pause deployment deploy-nginx //灰度发布更新版本为v2然后停止回滚 //因为deployment的默认回滚策略是滚动更新那么停止就会在第一波更新的时候 停止回滚//监控更新的过程可以看到已经新增了一个资源但是并未按照预期的状态去删除一个旧的资源就是因为使用了pause暂停命令 kubectl -n testapp get pod -o wide -w 步骤三测试等到版本稳定以后再完成继续发布 kubectl -n testapp expose pod deploy-nginx-7cb95f9469-x8rp2 --name svc-nginx-v2 //基于更新的pod创建一个默认的clusterip类型的svckubectl -n testapp expose pod deploy-nginx-7cb95f9469-x8rp2 --name svc-nginx-nodeport-v2 --type NodePort --port7070 --target-port80 //基于更新的pod创建一个默认的nodeport类型的svc//查看最后的更新情况 kubectl -n testapp get pod -o wide -w kubectl -n testapp rollout resume deployment deploy-nginx //等待版本稳定的时候 继续更新 三、滚动发布详解 关于滚动发布的参数 deployment控制器更新Pod的方式是 RollingUpdate滚动更新 RollingUpdateStrategy滚动更新策略:  25% max unavailable, 25% max surge Replicas: 3 desired       控制器的期望副本数25% max surge             滚动更新时允许创建的最大副本数或比例向上取整。值调的越大副本更新速度越快。25% max unavailable       滚动更新时允许销毁的最大副本数或比例向下取整。值越小越能保证服务稳定更新越平滑 图解 滚动发布的过程  假设期望副本数是3那么滚动更新时能够创建的副本数是 3 * 25% 0.75  再向上取整为 1能够销毁的副本数向下取整为 0                     假设期望副本数是1010 * 25% 2.5  向上取整为 3     向上取整为 2 整个滚动更新过程中Pod副本数始终处在 10-2 Pod副本数 103之间