升级指南
💡 升级之前
开始升级之前，请确保完成了以下两点事项。
备份集群中的重要数据。
将瑞数信息提供的新版镜像上传到镜像仓库（请参考 部署指南 > 附录 1 如何将镜像上传到华为云SWR 或 部署指南 > 附录 2 如何将镜像上传到私有仓库 的内容）。
💡 提示：
私有化部署所需相关文件包，请通过左侧导航栏中的 联系方式 向瑞数信息进行咨询。
CCE环境中的升级
按照 部署指南 > 1.2.1 上传模板文件包 的方法，将新版模板文件包上传到华为云部署环境。
上传完成后，在页面中单击 模板实例 标签，然后在需要升级的实例的右方单击 升级，如下图所示。
在右侧弹出的窗口中，单击 选择版本 下拉菜单，选择新版本的版本号，如下图所示（配置文件留空即可）。
然后还需要对窗口内的 原始数据 （即老版本配置数据）和 当前数据 （即新版本配置数据）的几个配置项进行比对，确保 当前数据中的下列配置项 与 原始数据 一致。其他配置项保持原样即可。
image > repository 配置
各个服务的 internal > password 配置
smtp 服务配置
各个服务的 external 配置
💡 提示：
仅针对采用了自有服务的场景，同时请勿忘记将新版文件中自有服务配置项下的 type 修改为 external 。没有自有服务时请忽略该配置。关于自有服务的概念，请参考 部署指南 > 2.2.1 配置服务参数并执行部署 小节中 步骤 2 的相关内容。
修改完成后，单击窗口右下角的 升级。升级过程需要持续 5 分钟左右或更长时间（取决于网络速度），请耐心等待。期间您可以单击窗口左侧导航栏中的 工作负载，查看当前各个负载的升级情况，如下图所示。
当 工作负载 页面的 状态 一栏中，所有负载都显示为 运行中 时，找到名为 console 的负载，单击该负载对应的操作栏中的 更多 > 重新部署，如下图所示。
💡 提示：
该步骤仅适用于从 1.5.4 升级到更高版本的场景。从 1.5.5 开始升级的用户请忽略该步骤。
等待 console 进入 运行中 状态，即完成了升级操作。
私有K8s环境中的升级
💡 注意：
请首先阅读 附录 1 特殊版本升级注意事项 的内容，确定当前的基础版本是否需要按照附录内容进行操作。
准备一台安装了 Helm v3.10.0 或更高版本、以及 Kubernetes 命令行工具的 PC（安装方法请参考 Helm 官方文档 和 Kubernetes 命令行工具官方文档），并确保两个工具能够与集群通信。
💡 提示：
如果 Helm 安装文件的官方下载地址速度太慢，可以尝试以下命令来下载文件：
curl https://labfileapp.oss-cn-hangzhou.aliyuncs.com/helm-v3.9.0-linux-amd64.tar.gz -o helm-v3.9.0-linux-amd64.tar.gz
将瑞数信息提供的模板文件包（名称类似 revol-1.5.5-.tgz ）保存到该 PC 上，并执行以下命令解压文件。解压后得到一个 revol 目录。
# 请根据实际文件名修改以下命令中的文件名称
tar -zvxf revol-1.5.5-.tgz进入解压后生成的 revol 目录，然后修改该目录下的 values.yaml 文件。
这里需要比对上一个版本的 values.yaml 文件，确保新版本文件中的以下配置项与旧版本的对应配置项相同。
image > repository 配置
各个服务的 internal > password 配置
smtp 服务配置
各个服务的 external 配置
💡 提示：
仅针对采用了自有服务的场景，同时请勿忘记将新版文件中自有服务配置项下的 type 修改为 external 。没有自有服务时刻忽略该配置。关于自有服务的概念，请参考 部署指南 > 2.2.1 配置服务参数并执行部署 小节中 步骤 2 的相关内容。
在当前 PC 上执行以下命令，开始升级。
helm upgrade --install -n 命名空间 发布名称 模板文件解压后的路径 -f values.yaml参数解释：
命名空间：您部署旧版本时所指定的命名空间，即 namespace 名称。
💡 提示：
执行 helm list -A，可以查看当前所有模板文件对应的命名空间。
发布名称：您部署旧版本时所指定的发布名称。
💡 提示：
请参考 部署指南 > 2.2.1 配置服务参数并执行部署 小节中 步骤 4 的相关内容。
模板文件解压后的路径：解压模板压缩文件后生成目录 revol，这里可以指定相对路径，即当前执行命令所在的位置相对于该目录所在位置的路径、或者直接指定绝对路径。
💡 提示：
对于相对路径来说，假设当前处于 revol 路径的相同父目录下，则相对路径为 ./revol。以此类推。
升级过程需要持续 5 分钟左右或更长时间（取决于网络速度），请耐心等待。期间您可以不断执行以下命令查看升级情况。
kubectl get deployment,statefulset -n 命名空间返回信息中显示如下图所示的组件状态，说明部署进程已完成。
后执行以下命令重启 console 负载。
💡 提示：
该步骤仅适用于从 1.5.4 升级到更高版本的场景。从 1.5.5 开始升级的用户请忽略该步骤。
kubectl -n 命名空间 rollout restart deployment console重启过程中，同样可以不断执行以下命令查看 console 重启情况。
kubectl get deployment,statefulset -n 命名空间当返回信息中 console 的 READLY 一栏中显示 1/1，即完成了升级操作。
附录 1 特殊版本升级注意事项
从 1.5.4-ca6686e 升级时，如果需要保留历史数据，请首先执行以下操作。
从该版本升级到 1.5.4 的其他子版本，需要首先执行以下命令安装补丁。
kubectl patch configmap clickhouse-config -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch configmap redis-config -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch statefulsets clickhouse -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch statefulsets kafka -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch statefulsets minio -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch statefulsets postgresql -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch statefulsets redis -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch service clickhouse -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch service kafka -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch service minio -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch service postgresql -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'
kubectl patch service redis -p '{"metadata":{"annotations":{"helm.sh/resource-policy":"keep"}}}'然后确保新版模板文件中的 values.yaml 文件内，以下服务的 type 为 external。
minio:
type: external
redis:
type: external
postgresql:
type: external
kafka:
type: external
clickhouse:
type: external从该版本升级到 1.5.5 版本，除了上面的补丁安装和 type 修改，还需要执行以下操作。
将新版模板文件解压后，revol/initdb.d/clickhouse/format_schemas 目录下的所有文件，复制到自建的 clickhouse 服务的 format_schemas 路径下。
从 1.5.4 其他子版本升级到任意版本，且 clickhouse 服务采用 external 部署方式，则仅需要执行以下操作。
💡 提示：
clickhouse 服务采用 internal 部署方式时，请忽略该操作。
将新版模板文件解压后，revol/initdb.d/clickhouse/format_schemas 目录下的所有文件，复制到自建的 clickhouse 服务的 format_schema 路径下。
按照当前的基础版本完成以上相应的操作后，再遵循前面的升级步骤依次执行即可。
附录 2 手动上传情报库
💡 仅针对符合以下前提的用户：
当前部署环境无法通过访问公网来更新情报库。
当前部署的服务中，minio 服务采用 internal 的部署方式，即该服务 并非 您自行创建的服务。关于自有服务的概念，请参考 部署指南 > 2.2.1 配置服务参数并执行部署 小节中 步骤 2 的相关内容。
在一台 PC 上解压瑞数信息提供的 离线情报库上传.zip 文件，解压后的目录内包含路径 backup，该路径下即保存了将要上传的情报库数据。
获取 minio 服务的 access-key 和 secret-key。
针对华为 CCE 部署环境
登录后进入 CCE 集群界面，然后按照下图所示，依次单击 配置项与密钥 > 密钥 > minio，将弹出窗口中的 access-key 和 secret-key 记录下来。
针对自有 K8s 部署环境
在安装了 kubectl 工具的 PC 上执行以下命令（注意指定命令空间）。
kubectl get secrets minio -o json -n 部署的命名空间 | jq -r '.data["access-key"]' | base64 -d
kubectl get secrets minio -o json -n 部署的命名空间 | jq -r '.data["secret-key"]' | base64 -d第一条命令将返回 access-key，第二条命令将返回 secret-key。将它们记录下来。
在命令行界面中执行命令创建 minio console 服务。
针对华为 CCE 部署环境
登录后进入 CCE 集群界面，然后在页面顶部的集群名称旁边，单击如下图所示的图标，打开 CloudShell 命令行界面。
针对自有 K8s 部署环境
在安装了 kubectl 工具的 PC 上进入终端命令行界面。
在命令界面中，执行以下命令。
💡 注意：
以下命令为单条命令，并非多条命令。请一次性复制所有的行，并指定命名空间，然后粘贴到命令行界面中执行。
kubectl apply -f -<<EOF
apiVersion: v1
kind: Service
metadata:
name: minio-console
namespace: 部署的命名空间
spec:
ports:
- name: console
port: 9001
protocol: TCP
targetPort: 9001
selector:
app: minio
type: NodePort
EOF执行成功将返回 service/minio-console created。
在命令行界面中执行以下命令获取 minio console 服务的端口号，并记录下来。
kubectl get services minio-console -n 部署的命名空间
在命令行界面中执行以下命令获取节点 IP。
执行以下命令获取节点名称。
kubectl get nodes然后将返回的任意节点的名称放入以下命令并执行。
kubectl describe nodes 节点名称在返回信息中，找到 InternalIP 或 ExternalIP，并记录下来。如下图所示。
💡 提示：
如果返回信息中没有包含 ExternalIP，是由于集群未配置公网 IP 映射，这时可以选择 InternalIP，即内网私有 IP 在后续步骤中使用。
在之前解压情报库文件的 PC 上通过浏览器访问 InternalIP + minio console 端口 或 ExternalIP + minio console 端口，打开以下登录页面。
💡 注意：
请确保 PC 能够访问其中一个 IP 地址。
在 Username 文本框输入之前记录的 access-key，在 Password 文本框中输入 secret-key，然后单击 login。
登录后，在页面中单击 credit-bucket，如下图所示。
然后选择右方的 Upload > Upload Folder，指定情报库文件解压目录内的文件夹 backup，开始上传。
上传完成后，在安装了 kubectl 工具的 PC 上（或华为云 CloudShell 命令行界面中）执行以下命令重启 intelligence 服务。
kubectl rollout restart deployment intelligence-worker -n 部署的命名空间重启完成后即可生效。