应用升级属性变更规则
应用市场的应用可以进行升级, 升级时每个属性都会按一定的规则进行变更. 本文将会介绍应用升级时, 各属性的变更规则.
属性变更规则概览
属性 | 级别 | 规则 |
---|---|---|
组件 | 应用 | 新增, 更新 |
插件 | 应用 | 新增 |
配置组 | 应用 | 新增 |
K8s 资源 | 应用 | 新增 |
镜像 | 组件 | 更新 |
启动命令 | 组件 | 更新 |
环境变量 | 组件 | 新增 |
组件连接信息 | 组件 | 新增 |
端口 | 组件 | 新增, 更新 |
存储 | 组件 | 新增 |
配置文件 | 组件 | 新增, 更新 |
健康检测探针 | 组件 | 新增, 更新, 删除 |
监控图表 | 组件 | 新增, 更新 |
监控点 | 组件 | 新增, 更新 |
HTTP 访问策略 | 组件 | 新增 |
标签 | 组件 | 新增 |
插件 | 组件 | 新增 |
组件依赖关系 | 组件 | 新增, 删除 |
存储依赖关系 | 组件 | 新增, 删除 |
Kubernetes 属性 | 组件 | 新增, 更新 |
上表为整个应用升级属性变更的概览, 每个属性的详细说明, 请看下文:
应用级属性
组件
组件
的变更规则是: 增加, 更新
.
源应用新增了组件, 升级时也会创建新的组件. 源应用修改了组件属性, 升级时会更新对应的属性. 但是, 源应用删除
了组件, 升级时不会删除对应的组件.
插件
插件
的变更规则是: 新增
. 当源应用新增了一个插件, 而当前应用所在团队无对应类型的插件时, 升级过程会在团队中新增该插件. 不会更新或删除插件.
配置组
配置组
由配置组
, 配置项
和生效组件
组成. 它们的规则是新增
.
源应用新增了配置组, 升级时也会新增
对应配置组. 但是, 源应用更新
或删除
了配置组, 那么升级时配置组不会发生变化, 即不会更新或删除已有配置组.
K8s 资源
K8s 资源
为用户自行通过 Yaml 文件创建的集群资源. 它们的规则是新增
.
源应用新增了 K8s 资源, 升级时也会新增
对应K8s 资源. 但是, 源应用更新
或删除
了 K8s 资源, 那么升级时 K8s 资源不会发生变化, 即不会更新或删除已有K8s 资源.
组件级属性
镜像
镜像
的变更规则是: 更新
. 每次升级时, 如果源组件镜像有变化, 升级时会更新
当前组件的镜像.
启动命令
启动命令
的变更规则是: 更新
. 每次升级时, 如果源组件启动命令有变化, 升级时会`更新当前组件的启动命令.
环境变量
环境变量
的变更规则是: 新增
. 源组件新增了环境变量, 升级时会新增对应的环境变量. 但是, 源组件更新
或删除
了组件的环境变量, 升级时不会更新或删除对应的环境变量.
组件连接信息
组件连接信息
的变更规则是: 新增
. 源组件新增了组件连接信息, 升级时会新增对应的组件连接信息. 但是, 源组件更新
或删除
了组件连接信息, 升级时不会更新或删除对应的组件连接信息.
特别地, 如果组件连接信息是根据组件端口生成, 即 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` 的存储依赖关系.
Kubernetes 属性
Kubernetes 属性
的变更规则是: 新增, 更新
. 源组件新增 Kubernetes 属性, 升级时会为组件新增对应 Kubernetes 属性. 源组件更新 Kubernetes 属性, 升级时会为组件更新对应 Kubernetes 属性. 不会删除 Kubernetes 属性.