Kubic:更新与重启

跳转到：导航，搜索

openSUSE Kubic 和 openSUSE MicroOS 的更新与重启

软件包格式

openSUSE Kubic 和 openSUSE MicroOS 使用 RPM 软件包。

对于最小系统或事务性更新，绝对没有理由切换到另一种软件包格式。RPM 作为一种软件包格式是众所周知的，因为它被几个主要发行版使用。从构建 RPM 到将结果包交付给用户的工具链已经过验证。此外，许多用户已经拥有用于 RPM 更新的策略和工具链。

其他 RPM 优势包括

  • 已签名，易于验证
  • 可以验证已安装的系统
  • Delta-RPM 以节省带宽

因此，为 openSUSE Kubic 交付的所有更新都基于 RPM，这允许您继续使用用于镜像和验证的工具。唯一的例外是，我们不会使用 zypper 来更新 RPM，而是使用 transactional-update。

更新与重启策略

出于安全和稳定性的原因，操作系统和应用程序堆栈应始终保持最新。虽然这对于可以手动运行命令来应用所有更新的单台机器来说不是问题，但对于大型集群来说，这可能会成为一个真正的负担。因此，我们认为自动更新是正确的做法。

为了完全自动更新系统，使用了事务性更新。自动更新过程可以禁用，或者可以配置维护窗口，在此期间将执行服务器的更新和（如果需要）重启。更新使用标准的 RPM，并且以与 openSUSE Tumbleweed 相同的方式交付。如果需要，可以使用 SMT 或 RMT 作为本地代理。

事务性更新

为了限制您机器的风险，更新作为事务性更新应用。这意味着

  • 它们是原子的
    • 要么完全应用，要么根本不应用。因此，在更新的任何时候，您可以关闭机器，并在下次启动时，要么启动旧的、未修改的安装，要么启动新的安装，而不会出现混合情况。这也意味着旧快照不会被销毁（就像您使用两个分区并在它们之间切换时会发生的那样），并且如果需要，您仍然可以回滚。
    • 更新不会影响您正在运行的系统。这意味着正在运行的进程看不到正在发生更新，并且它们不会被重新启动。这将会毫无用处，因为重新启动正在运行的守护进程只会启动旧的二进制文件，只有在重启后才能使用新的二进制文件。
  • 可以回滚
    • 如果更新失败或更新不兼容，您可以快速恢复到更新之前的状态。
  • 需要重启系统才能激活更改

这部分由 transactional-update(8) 负责。它由 systemd.timer 每天调用一次。可以通过创建文件 /etc/systemd/system/transactional-update.timer.d/timer.conf 来配置此设置，内容如下

 [Timer]
 #the first entry is to delete existing timer, else only a new one is added additional
 OnCalendar=
 OnCalendar=date/time

有关可以配置的选项和可能的值的更多信息，请参阅 systemd.unit(5) 和 systemd.time(5)。

应确保并非所有机器同时启动更新。根据网络基础设施和机器数量，这可能会产生非常高的（过高）负载。

此脚本首先检查是否有可用的更新。如果有，则创建根文件系统的新快照并使用 zypper dup 进行更新。因此，在该时间点发布的所有 RPM 且尚未安装的 RPM 都将被应用。之后，快照被标记为活动状态，并且仅在下次重启后使用。因此，脚本可以自行重启机器，或者通知另一个服务来执行重启。

在下次重启后，系统会验证自身，如果强制守护程序未正确启动，则会自动回滚到上次已知的正常快照。

清理旧快照

由于每次更新都会创建一个新的快照，因此使用 snapper 清理策略和规则来删除不再需要的快照

  • 配置数量的快照保留，其余将被删除
  • 不重要的快照将被首先删除

负责此操作的命令是 transactional-update cleanup。

  • 由 systemd.timer 定期运行。
  • 过去使用的快照将被标记为重要，并且可以删除。
  • 过去未使用的快照将被标记为可以删除，但不是重要的。因此，它们将被优先删除。

禁用自动更新

可以使用以下命令禁用自动更新

 systemctl --now disable transactional-update.timer

重启

有几种方法可以在更新后重启系统

应在 transactional-update.conf(5) 中配置使用哪种方法来重启机器。默认情况下，使用 rebootmgr，如果 rebootmgr 未运行，则使用 systemctl reboot。

rebootmgr

rebootmgr 是一个守护程序，可以配置为根据特定策略重启机器。它可以通过 rebootmgrctl(1) 进行控制。rebootmgr 不会排空任何 kubernetes 节点，它会在配置的时间进行硬重启。因此，它更适合 openSUSE MicroOS（作为容器主机操作系统），而不是 kubernetes 集群。

重启策略选项

rebootmgr 支持不同的策略，何时应该进行重启

  • instantly - 当收到信号时，其他服务将被告知我们计划重启，并且无需等待维护窗口即可进行重启。
  • maint-window - 仅在指定的维护窗口期间重启。如果没有指定窗口，则立即重启。
  • best-effort - 这是默认设置。如果指定了维护窗口，则使用 maint-window。如果没有指定维护窗口，则立即重启（instantly）。
  • off - rebootmgr 将继续运行，但忽略所有重启信号。将策略设置为 `off` 不会清除维护窗口。如果重新启用 rebootmgr，它将继续使用旧的指定维护窗口。

可以通过 /etc/rebootmgr.conf 配置重启策略，并在运行时通过 rebootmgrctl 进行调整。这些更改将被写入配置文件并在下次重启后保留。默认配置文件将是

 [rebootmgr]
 window-start=03:30
 window-duration=1h30m
 strategy=best-effort

这意味着机器仅允许在晚上 3:30 到 5:00 之间重启。window-start 的格式与 systemd.time(7) 中描述的相同。window-duration 的格式为 [XXh][YYm]

禁用 Rebootmgr

可以使用以下命令禁用 rebootmgr

 systemctl --now disable rebootmgr

或

 rebootmgrctl set-strategy off

Kubernetes 重启守护程序

Kubernetes Reboot Daemon kured 是一个 Kubernetes daemonset，当底层操作系统的软件包管理系统指示需要这样做时，它会执行安全的自动节点重启。它在每个节点上的容器内运行。因此，此选项仅适用于具有 kubeadm 系统角色的 openSUSE Kubic。

要启用此方法，请告诉 kubernetes 在所有节点上运行容器

 kubectl apply -f /usr/share/kured/kured-<version>.yaml

使用 kubectl get pods --namespace=kube-system 可以验证容器是否在所有节点上运行。

之后，配置每个节点上的 transactional-update 以使用 kured。如果 /etc/transactional-update.conf 不存在（默认情况下）

 echo "REBOOT_METHOD=kured" > /etc/transactional-update.conf

否则将此条目添加到配置文件中。

从 "https://en.opensuse.net.cn/index.php?title=Kubic:Update_and_Reboot&oldid=173480" 检索