应用市场的应用可以进行升级, 升级时每个属性都会按一定的规则进行变更. 本文将会介绍应用升级时, 各属性的变更规则.

属性变更规则概览

上表为整个应用升级属性变更的概览, 每个属性的详细说明, 请看下文:

应用级属性

组件

组件的变更规则是: 增加, 更新.

源应用新增了组件, 升级时也会创建新的组件. 源应用修改了组件属性, 升级时会更新对应的属性. 但是, 源应用删除了组件, 升级时不会删除对应的组件.

插件

插件的变更规则是: 新增. 当源应用新增了一个插件, 而当前应用所在团队无对应类型的插件时, 升级过程会在团队中新增该插件. 不会更新或删除插件.

配置组

配置组由配置组, 配置项和生效组件组成. 它们的规则是新增.

源应用新增了配置组, 升级时也会新增对应配置组. 但是, 源应用更新或删除了配置组, 那么升级时配置组不会发生变化, 即不会更新或删除已有配置组.

组件级属性

镜像

镜像的变更规则是: 更新. 每次升级时, 如果源组件镜像有变化, 升级时会更新当前组件的镜像.

启动命令

启动命令的变更规则是: 更新. 每次升级时, 如果源组件启动命令有变化, 升级时会`更新当前组件的启动命令.

环境变量

环境变量的变更规则是: 新增. 源组件新增了环境变量, 升级时会新增对应的环境变量. 但是, 源组件更新或删除了组件的环境变量, 升级时不会更新或删除对应的环境变量.

组件连接信息

组件连接信息的变更规则是: 新增. 源组件新增了组件连接信息, 升级时会新增对应的组件连接信息. 但是, 源组件更新或删除了组件连接信息, 升级时不会更新或删除对应的组件连接信息.

特别地, 如果组件连接信息是根据组件端口生成, 即 XXX_HOST 和 XXX_PORT, 那么该连接信息会根据应用的治理模式, 端口别名和内部域名重新生成.

如果端口别名是 mysql, 生会生成连接信息为 MYSQL_HOST 和 MYSQL_PORT

如果治理模式是内置 ServiceMesh 模式, 则 XXX_HOST 的值为 127.0.0.1. 如果治理模式是Kubernetes 原生 Service 模式, 则 XXX_HOST 的值为 内部域名.

端口

端口的变更规则是: 新增, 更新. 源组件新增了端口, 升级时也会为组件新增对应端口. 源组件更新了端口, 升级时也会更新组件对应的端口; 但是, 只会更新端口的 协议, 端口别名, 打开端口. 也就是说, 不会更新端口的内部域名, 端口号, 也不会关闭已打开的端口. 另外, 如果源组件删除了端口, 升级时不会删除组件对应的端口.

存储

端口的变更规则是: 新增. 源组件新增了存储, 升级时也会为组件新增对应存储. 不会更新或删除存储.

如果存储所需的存储驱动不存在于当前集群, 那么会用默认的共享存储去替换源存储驱动.

配置文件

配置文件的变更规则是: 新增, 更新. 源组件新增了配置文件, 升级时也会为组件新增对应配置文件. 源组件更新了某个配置文件的内容, 升级时会更新组件对应的配置文件内容; 但是不会更新配置文件的名称和路径, 只更新内容. 也不会删除配置文件.

健康检测探针

健康检测探针的变更规则是: 新增, 更新, 删除. 源组件新增健康检测探针, 升级时会为组件新增对应探针. 源组件更新健康检测探针, 升级时会为组件更新对应探针. 源组件删除健康检测探针, 升级时会为组件删除对应探针.

监控图表

监控图表的变更规则是: 新增, 更新. 源组件新增监控图表, 升级时会为组件新增对应监控图表. 源组件更新监控图表, 升级时会为组件更新对应监控图表的查询语句. 不会删除监控图表.

监控点

监控点的变更规则是: 新增, 更新. 源组件新增监控点, 升级时会为组件新增对应监控点. 源组件更新监控点, 升级时会为组件更新对应监控点. 不会删除监控点.

HTTP 访问策略

HTTP 访问策略的变更规则是: 新增. 源组件新增 HTTP 访问策略, 升级时会为组件新增对应 HTTP 访问策略. 不会更新或删除 HTTP 访问策略.

标签

标签的变更规则是: 新增. 源组件新增标签, 升级时会为组件新增对应标签. 不会更新或删除标签.

插件

插件的变更规则是: 新增. 源组件新增插件, 升级时会为组件新增对应插件. 不会更新或删除插件.

组件依赖关系

组件依赖关系的变更规则是: 新增, 删除. 组件依赖关系只有新增和删除, 没有更新, 所以不需要考虑升级时更新问题. 源组件新增依赖关系, 升级时会为组件新增对应依赖关系. 源组件删除依赖关系, 升级时会为组件删除对应依赖关系.

新增组件依赖关系时, 组件依赖关系需要依赖组件和被依赖组件同时存在, 考虑以下几种情况:

• A 组件依赖 B 组件, B 组件是新增组件; 升级应用时, 如果没有选择 B 组件, 相当于被依赖组件 B 不存在, 那么不会建立 A 到 B 的依赖关系.
• A 组件依赖 B 组件, B 组件是已存在组件; 升级应用时, 无论是否选择升级 B 组件, 都会建立 A 到 B 的依赖关系, 因为被依赖组件 B 是存在的.
• 源应用中, 新增了 A 到 B 的依赖, 但是发布时只发布了 A 组件, 没有发布 B 组件; 那么它们的依赖关系不会被发布出去, 在进行升级时, 不会建立 A 到 B 的依赖关系.

删除组件依赖关系时, 只会删除来源于同一个应用市场应用的组件之间的组件依赖关系, 不会删除组件对非同源组件的组件依赖关系. 也不会删除对未选择组件的依赖. 考虑一下几种情况:

• A, B 组件来源于同一个应用市场应用, A 依赖于 B. C 是通过镜像创建的组件, 与 A, B 非同源, A 依赖于 C. 源应用删除了 A 到 B 的组件依赖关系, 升级时, 会删除 A 到 B 的依赖关系, 不会删除 A 到 C 依赖关系.
• 源应用新增了 A 到 B 的组件依赖关系, 升级时, 只选择升级 A, 没有选择 B 组件, 那么不会删除 A 到 B 的依赖.

存储依赖关系

存储依赖关系的变更规则是: 新增, 删除.

新增存储依赖关系时, 存储依赖关系需要依赖存储和被依赖存储同时存在, 考虑以下几种情况:

• A` 存储依赖 B` 存储, B` 存储所在组件是 B, B 是新增存储组件; 升级应用时, 如果没有选择 B 组件, 相当于被依赖存储 B` 不存在, 那么不会建立 A` 到 B` 的依赖关系.
• A` 存储依赖 B` 存储, B` 存储所在组件是 B, B 是已存在的组件; 升级应用时, 无论是否选择升级 B 组件, 都会建立 A` 到 B` 的依赖, 因为被依赖存储 B` 是存在的.
• 源应用中, 新增了存储 A` 到 B` 的依赖, 但是发布时只发布了 A 组件, 没有发布 B 组件; 那么它们的 A` 到 B` 的依赖关系不会被发布出去, 在进行升级时, 不会建立 A` 到 B` 的依赖关系.

删除存储依赖关系时, 只会删除来源于同一个应用市场应用的组件之间的存储依赖关系, 不会删除组件对非同源组件的存储依赖关系. 也不会删除对未选择组件的存储依赖关系. 考虑一下几种情况:

• A`, B` 存储来源于同一个应用市场应用, A` 依赖于 B`. C` 是通过镜像创建的组件 C 的存储, 与 A`, B` 非同源, A` 依赖于 C`. 源应用删除了 A` 到 B` 的存储依赖关系, 升级时, 会删除 A` 到 B` 的依赖关系, 不会删除 A` 到 C` 的存储依赖关系.
• 源应用新增了 A` 到 B` 的存储依赖关系, 升级时, 只选择升级 A 组件, 没有选择 B 组件, 那么不会删除 A` 到 B` 的存储依赖关系.