产品/底座升级

升级场景

1. 只升级底座版本：需要使用更强的运维管控能力、或者是为了对K8s版本做升级

2. 只升级产品版本：产品有更新，需要进行增量升级，但是无需升级底座版本

3. 底座版本和产品版本都升级：此种场景需要先进行底座升级逻辑，再进行产品升级

产品版本升级

升级风险

产品的增量升级，逻辑与Helm Upgrade相同，会通过滚动升级的方式更新Pod，是否会对业务产生影响，取决于业务逻辑。

升级流程

首先在产品编排中完成新版本的编排及发布，然后在局点管理页通过变更交付内容，配置要升级到哪一个目标版本，生成增量产品部署包，具体操作如下：

1. 点击交付内容变更，选择目标升级版本；支持在已有的交付内容里添加多个新的待交付产品

2. 生成增量产品部署包

   

3. 通过远程部署/离线部署，完成增量升级

• 远程部署：在远程部署页面选择已经生成好的部署包，进行远程部署即可（适用于在线环境，并且已经配置好了部署通道，如跳板机/VPC）

• 离线部署：对于已生成的增量部署包，点击“离线部署”按钮。而后根据提示的步骤进行操作（提示：需要严格按照提示步骤进行操作，否则可能产生License授权失效等情况）。

底座版本升级

升级风险

对业务的影响

• 底座的增量升级，依靠升级脚本完成，对于K8s版本不发生变化的底座版本升级，不会对业务产生影响，如果涉及K8s版本的变化，会因为CoreDNS的重启，导致几十秒的容器网络中断。（提示：1.2.x及以下版本底座使用的K8s版本为1.16，1.3.x及以上版本底座使用的K8s版本为1.20）

对端口的影响

• 本地运维控制台（adp-local）在从v1.2.x/v1.3.x的底座版本到v1.4.x的底座版本升级后，NodePort服务暴露端口会从31001~31002变更为31000，请配置好环境内的网络策略，避免升级后本地运维控制台无法访问。

对数据的影响

• 从v1.4.3及以下版本升级到v1.4.4及以上版本会导致通过白屏自定义的监控指标/告警策略丢失，升级完成后需要重新导入。

升级流程

1. 底座升级过程中可能涉及k8s的升级，正式升级前需要先人工检查下局点环境中集群核心组件的默认配置是否被更新过：

   1. 检查calico是否有手动更新：执行kubectl -n kube-system get cm calico-config -ojsonpath='{.data.veth_mtu}' 命令，结果如果为""或者1440，则表示没有手动更新，否则请联系ADP底座团队；执行kubectl -n kube-system get ds calico-node -oyaml |grep "can-reach=8.8.8.8$" ，如果有值，则表示没有手动更新，否则请联系ADP底座团队

   2. 检查coredns是否有手动更新： 执行kubectl -n kube-system get cm coredns -oyaml ，如果有自定义的域名解析，请联系ADP底座团队

2. 局点管理页通过变更交付内容，选择目标升级底座版本

2. 生成增量底座部署包，而后根据提示的步骤进行操作（提示：需要严格按照提示步骤进行操作，否则可能产生License授权失效等情况）。

底座升级补充说明

• 底座升级过程中如果遇到类似apply only support init/scale cluster, but your .spec.pkgURL has changed的错误，可以通过先执行./hopctl upgrade -c -p `pwd`再执行./hopctl install -p `pwd` --skip-actions install_cluster解决。