Kibotos

从 v0.1.x 升级到 v0.2.0

本页说明从 v0.1.x 升级到 v0.2.0 时,在通用的跨版本升级步骤之外要做的事。文中的「第 N 步」指跨版本升级的步骤表。

v0.2.0 只读 v0.1.x 留下的状态。第 5 步的检查把下面这些对象列为阻塞项,按表处理后再替换文件:

对象处理
版本早于 v0.1.x 的 ctrl 数据库先完整升级到最新的 v0.1.x,再升级到 v0.2.0
在 v0.0.3、v0.1.0-rc.1 或 v0.1.0-rc.2 下启动、此后一直没有停止的 Workspace用当前版本正常停止一次。它的 runtime 超出目标版本的驱动范围,本地记录也可能是目标版本读不了的格式;下次启动时换到目标版本的 runtime
报告为 has version 7, this build reads [8 9] 的已结束 Instance 记录停止 node 后,把这个文件移到 storage.root 之外留档
池里的 volumes/metadata-v1/ 与 retained-layers/metadata-v2/删除这两个目录。它们是从 v0.0.3 升级时留下的 metadata 备份,目标版本不再读取
报告为 node Instance <id> is active or requires cleanup、所属 Workspace 是 FAILED 的 Instance用当前版本 kibo workspace stop --force 这个 Workspace,让 node 清理它的 Instance。窗口开始前先处理掉全部 FAILED 的 Workspace,免得在停机期间临时起回原版本
报告为 Workspace command <id>: the command is still processing、所属 Volume 已经删除的命令在 ctrl 停止时,按下文把它结束为 aborted

移走已结束 Instance 的记录之后,这个 Workspace 的启动、停止与删除不受影响,清理状态里与这个 Instance 有关的几项显示为未知。

升级之后,ctrl 让 node 逐批删除已结束 Instance 的已有记录,kibotos_node_instances{state="stopped"} 与 {state="destroyed"} 随之下降。没有对应 Allocation 的记录 ctrl 不认识,留在原处。

v0.1.x 删除一个 Volume 时,不会结束它上面结果未知的扩容、创建或删除命令。这样的命令一直处于处理中,重发也结束不了,目标版本的检查把它列为未完成的生命周期操作。确认报告里的命令属于一个已删除的 Volume 后,以 ctrl 的数据库账户执行:

UPDATE kibotos_ctrl_commands
SET status = 'completed', error_code = 10, updated_at = now()
WHERE command_id = '<命令 ID>'
  AND status = 'processing'
  AND volume_id IN (SELECT volume_id FROM kibotos_ctrl_volumes WHERE volume_state = 5);

结果为 UPDATE 1 才算处理完;UPDATE 0 说明它不是这种命令,按ctrl 的升级检查处理。error_code = 10 是 aborted,volume_state = 5 是 DELETED,与目标版本删除 Volume 时结束这类命令的结果相同。

替换文件之前,还要按下表核对配置与权限:

项要做什么不处理的后果
KiboVM node 的 [runtime].socket_root不超过 39 字节,超长时换一个更短的目录。新 runtime 的 socket 比原来深一层node 启动时报错
node 配置的 [[storage.pool]]删掉 capacity,见升级到由 ctrl 设置池容量check-upgrade 与 node 启动失败
ctrl 的 database.max_connections默认值从 2.5 × execution_concurrency + 32 改为 3 × execution_concurrency + 32,并发数为 16 时从 72 变为 80。没写的,确认 PostgreSQL 容得下多出的连接;写了的,不能小于 3 × execution_concurrency + 16。见数据库连接数ctrl 拒绝启动,并给出所需的最小值
ctrl 的 database.dsn 指向的地址必须是 PostgreSQL 主库,不能是云数据库的代理地址、读写分离地址或连接池。见数据库的连接方式数据库会话被代理替换时,同一 Workspace 的两条命令可能同时执行
ctrl 的 database.dsn 与 dsn_file连接串按 libpq 的规则解析:URI 里的用户名与密码按百分号编码,@ 写成 %40;IPv6 地址写在方括号里。用同一个连接串执行 psql "$DSN" -c 'select 1',能连上就不用改ctrl 连不上数据库
ctrl 对 artifact store 的权限能按前缀列举 kibotos-transfer/v1/<namespace>/,见准备 bucket 与权限删除 Transfer 返回 unavailable,失败与过期的归档留在 store 里,ctrl 日志有 transfer archive cleanup did not finish
日志采集按单元名选择 Kibotos 日志的,加上 kibotos-dataplane.slice 里的单元;参考的 Vector 配置已经加上。见数据面进程收不到数据面进程的日志

KiboVM 后端的 v0.2.0 换了 VMM runtime,v0.1.x 的 node 启动不了本版本的 KiboVM Platform。这一点与跨版本升级注意中「先发布 Platform 再升级 node」相反:第 7 步完成后、第 8 步恢复写入之前,发布并 approve 本版本的 KiboVM Platform。新 node 只用新 runtime 启动 VM,不运行旧 Platform;正在运行的 Workspace 照常被接管,不受影响。

v0.1.x 启动的 Workspace 在下次启动之前仍运行原来的 runtime 与 Platform:

  • 正常停止照常进行,但磁盘只写到宿主的页缓存,与 v0.1.x 相同;node 日志对每次这样的停止记一条 stop did not confirm the host flush,原因是 the VMM's runtime release does not flush on stop。
  • 下次启动时换到本版本 KiboVM Platform 的默认,guest 协议与 rootfs 契约相同即可,kernel series 可以不同。

v0.1.x 发布的 KiboVM Platform 留在目录里。本版本没有发布同一 kernel series 的 Platform 时,那条 series 的旧默认仍显示为默认,也不能撤回。node 不再提供它要求的 runtime,新 Workspace 与再次启动的 Workspace 都不会选中它,不需要处理。

升级到 v0.2.0 之后不能回退到 v0.1.x:v0.1.x 的 ctrl 拒绝迁移后的数据库,v0.1.x 的 node 也读不了 v0.2.0 写下的本地记录与池里的元数据。替换文件之前,用第 5 步的检查处理完全部阻塞项;检查不通过、尚未替换文件时,照常启动原版本,见回退。替换之后出现的问题在 v0.2.x 上修复。

升级到由 ctrl 设置池容量

目标版本的池容量是 ctrl 上池的属性,node 配置不再声明它。替换文件之前,从每个 node 配置的每个 [[storage.pool]] 删掉 capacity。配置没改时,第 5 步的 check-upgrade 在加载配置这一步失败,并提示改用 kibo storage-pool set-capacity。

第 6 步的 kibotos-ctrl migrate 按升级前 ctrl 记下的声明回填每个池的容量,放置用的数不变:

升级前的声明升级后的池容量
有 node 把池报告为可用这些 node 声明的值中最小的一个
声明它的 node 都报告不可用全部声明中最小的一个
没有 node 声明容量不设,池不接收新对象

升级完成后,用 kibo storage-pool list 核对每个池的 CAPACITY,显示 - 或需要调整时用 kibo storage-pool set-capacity 设置,见池容量。

本页内容