Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

准备好安装 MicroShift

Red Hat build of MicroShift 4.18

计划 MicroShift 安装并了解重要的配置

Red Hat OpenShift Documentation Team

摘要

本文档提供有关规划 MicroShift 安装的信息，并提供有关重要配置流程的详细信息。

第 1 章 准备好安装 MicroShift
复制链接

规划 MicroShift 安装并根据需要完成主机配置步骤。

1.1. 安装 MicroShift 的系统要求
复制链接

在安装 MicroShift 之前必须满足以下条件：

  • 兼容的 Red Hat Enterprise Linux (RHEL)版本。如需更多信息，请参阅 兼容性表。
  • AArch64 或 x86_64 系统架构。
  • 2 个 CPU 内核。
  • 2 GB RAM。从网络(UEFI HTTP 或 PXE 引导)安装需要 RHEL 3 GB RAM。
  • 10 GB 存储。
  • 在您的红帽帐户上有一个活跃的 MicroShift 订阅。如果您没有相关订阅，请联络您的销售代表以获得更多信息。
  • 如果您的工作负载需要持久性卷(PV)，则代表您有一个有足够可用工作负载的逻辑卷管理器(LVM)卷组(VG)。
重要

这些要求是 MicroShift 和 Red Hat Enterprise Linux (RHEL)的最低系统要求。为计划运行的工作负载添加系统要求。

例如，如果 IoT 网关解决方案需要 4 GB RAM，则您的系统至少需要 2 GB 用于 Red Hat Enterprise Linux (RHEL)和 MicroShift，再加上 4 GB 工作负载。总共需要 6 GB RAM。

如果要在远程位置部署物理设备，建议允许额外的容量来满足将来的需要。如果您不确定所需的 RAM，如果预算允许，请使用设备可以支持的最大 RAM 容量。

重要

确保配置对系统的安全访问，以便相应地管理它。如需更多信息，请参阅使用 OpenSSH 的两个系统间使用安全通信。

1.2. 兼容性表
复制链接

计划使用 MicroShift 版本对受支持的 RHEL for Edge 版本配对，如以下兼容性表所述：

Red Hat Device Edge 发行版本兼容性列表

Red Hat Enterprise Linux (RHEL)和 MicroShift 作为一个设备边缘计算的单一解决方案一起工作。您可以单独更新每个组件，但产品版本必须兼容。支持的 Red Hat Device Edge 配置会为每个版本一起使用验证的版本，如下表所示：

Expand
RHEL 版本MicroShift 版本支持的 MicroShift 版本 → 版本更新

9.4

4.18

4.18.0 → 4.18.z

9.4

4.17

4.17.1 → 4.17.z, 4.17 → 4.18

9.4

4.16

4.16.0 → 4.16.z, 4.16 → 4.17, 4.16 → 4.18

9.2, 9.3

4.15

4.15.0 → 4.15.z, 4.15 → 4.16 on RHEL 9.4

9.2, 9.3

4.14

4.14.0 → 4.14.z, 4.14 → 4.15, 4.14 → 4.16 on RHEL 9.4

第 2 章 在 MicroShift 中使用 FIPS 模式
复制链接

您可以在 Red Hat Enterprise Linux (RHEL) 9 上基于 RPM 的 MicroShift 安装中使用 FIPS 模式。

  • 要在 MicroShift 容器中启用 FIPS 模式，必须在机器启动前启用 worker 机器内核以 FIPS 模式运行。
  • 不支持在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中使用 FIPS。
  • 不支持将 FIPS 与 RHEL 镜像模式一起使用。

2.1. 基于 RHEL RPM 的安装的 FIPS 模式
复制链接

将 FIPS 与 MicroShift 搭配使用需要在 Red Hat Enterprise Linux (RHEL)安装中启用加密模块自我检查。在将主机操作系统配置为使用 FIPS 模块后，MicroShift 容器会自动启用来以 FIPS 模式运行。

  • 当 RHEL 以 FIPS 模式启动时，MicroShift 核心组件使用已提交到 NIST for FIPS 140-2/140-3 验证的 RHEL 加密库。

  • 当在计划用作 worker 机器的机器上安装 RHEL 9 时，您必须启用 FIPS 模式。

    重要

    因为 FIPS 必须在集群首次启动的操作系统前启用，所以您不能在部署集群后启用 FIPS。

  • MicroShift 使用 FIPS 兼容的 Golang 编译器。
  • CRI-O 容器运行时支持 FIPS。

2.1.1. 限制：
复制链接

  • TLS 实现 FIPS 支持没有完成。
  • FIPS 实现不提供单个函数来计算哈希函数并验证基于该哈希的键。在以后的 MicroShift 版本中，将继续评估这个限制以改进。

第 3 章 greenboot 健康检查框架
复制链接

Greenboot 是 rpm-ostree 系统上 systemd 服务的通用健康检查框架，如 Red Hat Enterprise Linux for Edge (RHEL for Edge)。此框架包含在带有 microshift-greenboot 和 greenboot-default-health-checks RPM 软件包的 MicroShift 安装中。

Greenboot 健康检查会在不同时间运行来评估系统健康状况，并在软件出现问题的情况下自动回滚到最后一个健康状态，例如：

  • 默认健康检查脚本会在每次系统启动时运行。
  • 除了默认的健康检查外，您还可以编写、安装和配置应用程序健康检查脚本，以便在每次系统启动时也运行。
  • Greenboot 可以降低更新期间被锁定在边缘设备的风险，并防止在更新失败时出现大量服务中断。
  • 当检测到失败时，系统使用 rpm-ostree 回滚功能引导到最后一个已知的工作配置。此功能对于直接可服务性是有限或不存在的边缘设备特别有用。

MicroShift 应用程序健康检查脚本包含在 microshift-greenboot RPM 中。greenboot-default-health-checks RPM 包括验证 DNS 和 ostree 服务是否可以访问健康检查脚本。您可以为正在运行的工作负载创建自己的健康检查脚本。您可以编写一个来验证应用程序是否已启动，例如：

3.1. Greenboot 如何使用目录运行脚本
复制链接

健康检查脚本从四个 /etc/greenboot 目录运行。这些脚本按字母顺序运行。当您为工作负载配置脚本时请注意这一点。

当系统启动时，greenboot 在 required.d 和 want .d 目录中运行脚本。根据这些脚本的结果，greenboot 会继续启动或尝试回滚，如下所示：

  1. 系统如预期：当 required.d 目录中的所有脚本都成功运行时，greenboot 会运行 /etc/greenboot/green.d 目录中存在的任何脚本。
  2. 系统问题：如果 required.d 目录中任何脚本失败，greenboot 会运行 red.d 目录中存在的任何预滚动脚本，然后重新启动系统。
注意

Greenboot 将脚本和健康检查输出重定向到系统日志。登录后，每日消息将提供整体系统健康输出。

3.1.1. Greenboot 目录详情
复制链接

从任何脚本返回非零退出代码意味着该脚本已失败。Greenboot 会在尝试回滚到以前的版本前重启系统来重试脚本。

  • /etc/greenboot/check/required.d 包含不能失败的健康检查。

    • 如果脚本失败，greenboot 默认会重试三次。您可以通过将 GREENBOOT_MAX_BOOTS 参数设置为所需的重试次数，在 /etc/greenboot/greenboot.conf 文件中配置重试次数。
    • 在所有重试失败后，如果可用，greenboot 会自动启动回滚。如果没有可用的回滚，系统日志输出显示需要手动干预。
    • MicroShift 的 40_microshift_running_check.sh 健康检查脚本安装在这个目录中。

  • /etc/greenboot/check/wanted.d 包含允许失败的健康脚本，而不会导致回滚系统。

    • 如果这些脚本失败，greenboot 会记录失败，但不会启动一个回滚。
  • /etc/greenboot/green.d 包含在 greenboot 声明开始成功后运行的脚本。
  • /etc/greenboot/red.d 包含在 greenboot 声明启动失败时运行的脚本，包括 40_microshift_pre_rollback.sh prerollback 脚本。这个脚本会在系统回滚前执行。该脚本执行 MicroShift pod 和 OVN-Kubernetes 清理，以避免在将系统回滚到以前的版本后出现潜在的冲突。
重要

如果您自定义 /etc/greenboot/greenboot.conf 文件中任何环境变量的值，则当 greenboot RPM 软件包被更新或降级时，这些更改可能会丢失。

  • 要在使用 MicroShift 构建系统镜像时保留自定义，请将 greenboot.conf 文件添加到蓝图中。
  • 要在使用 RPM 安装时保留自定义，请在安装 MicroShift 和 greenboot RPM 后对 greenboot.conf 文件应用更改。

3.2. MicroShift 健康检查脚本
复制链接

40_microshift_running_check.sh 健康检查脚本仅执行核心 MicroShift 服务的验证。在 greenboot 目录中安装自定义工作负载健康检查脚本，以确保系统更新后成功应用程序操作。脚本按字母顺序运行。

MicroShift 健康检查在下表中列出：

Expand
表 3.1. MicroShift 的验证状态和结果
验证PassFail

检查该脚本是否使用 root 权限运行

下一步

exit 0

检查 microshift.service 是否已启用

下一步

exit 0

等待 microshift.service 处于活动状态（！failed）

下一步

exit 1

等待 Kubernetes API 健康端点正常工作并接收流量

下一步

exit 1

等待任何 pod 启动

下一步

exit 1

对于每个核心命名空间，等待拉取镜像

下一步

exit 1

对于每个核心命名空间，等待 pod 就绪

下一步

exit 1

对于每个核心命名空间，检查 pod 是否没有重启

exit 0

exit 1

3.2.1. 验证等待周期
复制链接

每个验证中的等待周期默认为五分钟。在等待周期后，如果验证没有成功，则会声明它失败。每次引导验证循环后，这个等待周期会递增到基础等待周期。

  • 您可以通过在 /etc/greenboot/greenboot.conf 配置文件中设置 MICROSHIFT_WAIT_TIMEOUT_SEC 环境变量来覆盖 base-time 等待周期。例如，您可以通过将值重置为 180 秒，将等待时间更改为三分钟，如 MICROSHIFT_WAIT_TIMEOUT_SEC=180。

3.3. 启用 systemd 日志服务数据持久性
复制链接

systemd 日志服务的默认配置会将数据存储在 volatile /run/log/journal 目录中。要在系统启动和重启后查看系统日志，您必须启用日志持久性并设置对最大日志数据大小的限制。

流程

  1. 运行以下命令来创建目录： 

    $ sudo mkdir -p /etc/systemd/journald.conf.d
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令来创建配置文件： 

    cat <<EOF | sudo tee /etc/systemd/journald.conf.d/microshift.conf &>/dev/null
[Journal]
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=1G
EOF
    Copy to Clipboard Toggle word wrap
  3. 根据您的大小要求编辑配置文件值。

3.4. 更新和第三方工作负载
复制链接

更新后，健康检查特别有用。您可以检查 greenboot 健康检查的输出，并确定是否声明了更新的有效。此健康检查可帮助您确定系统是否正常工作。

更新的健康检查脚本会安装到 /etc/greenboot/check/required.d 目录中，并在每次系统启动时自动执行。退出具有非零状态的脚本意味着系统启动已被声明为失败。

重要

等待直到声明更新在启动第三方工作负载前有效。如果在工作负载启动后执行回滚，您可以丢失数据。在更新完成前，一些第三方工作负载在设备上创建或更新数据。在回滚后，文件系统会在更新前恢复到其状态。

3.5. 检查更新的结果
复制链接

成功启动后，greenboot 在 GRUB 中将变量 boot_success= 设置为 1。您可以按照以下流程在系统日志中更新后查看系统健康检查的整体状态。

流程

  • 要访问系统健康检查的整体状态，请运行以下命令： 

    $ sudo grub2-editenv - list | grep ^boot_success
    Copy to Clipboard Toggle word wrap

成功启动系统的输出示例

boot_success=1
Copy to Clipboard Toggle word wrap

3.6. 在系统日志中访问健康检查输出
复制链接

您可以按照以下流程手动访问系统日志中的健康检查输出。

流程

  • 要访问健康检查的结果，请运行以下命令： 

    $ sudo journalctl -o cat -u greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap

失败健康检查的输出示例

...
...
Running Required Health Check Scripts...
STARTED
GRUB boot variables:
boot_success=0
boot_indeterminate=0
boot_counter=2
...
...
Waiting 300s for MicroShift service to be active and not failed
FAILURE
...
...
Copy to Clipboard Toggle word wrap

3.7. 在系统日志中访问预滚动健康检查输出
复制链接

您可以在系统日志中访问健康检查脚本的输出。例如，按照以下流程检查 prerollback 脚本的结果。

流程

  • 要访问预滚动脚本的结果，请运行以下命令： 

    $ sudo journalctl -o cat -u redboot-task-runner.service
    Copy to Clipboard Toggle word wrap

prerollback 脚本的输出示例

...
...
Running Red Scripts...
STARTED
GRUB boot variables:
boot_success=0
boot_indeterminate=0
boot_counter=0
The ostree status:
* rhel c0baa75d9b585f3dd989a9cf05f647eb7ca27ee0dbd4b94fe8c93ed3a4b9e4a5.0
    Version: 9.1
    origin: <unknown origin type>
  rhel 6869c1347b0e0ba1bbf0be750cdf32da5138a1fcbc5a4c6325ab9eb647b64663.0 (rollback)
    Version: 9.1
    origin refspec: edge:rhel/9/x86_64/edge
System rollback imminent - preparing MicroShift for a clean start
Stopping MicroShift services
Removing MicroShift pods
Killing conmon, pause and OVN processes
Removing OVN configuration
Finished greenboot Failure Scripts Runner.
Cleanup succeeded
Script '40_microshift_pre_rollback.sh' SUCCESS
FINISHED
redboot-task-runner.service: Deactivated successfully.
Copy to Clipboard Toggle word wrap

3.8. 使用健康检查脚本检查更新
复制链接

使用以下步骤在更新后访问系统日志中的 greenboot 健康检查脚本的输出。

流程

  • 要访问更新检查的结果，请运行以下命令： 

    $ sudo grub2-editenv - list | grep ^boot_success
    Copy to Clipboard Toggle word wrap

成功更新的输出示例

boot_success=1
Copy to Clipboard Toggle word wrap

如果您的命令返回 boot_success=0，则 greenboot 健康检查仍然在运行，或者更新失败。

法律通告
复制链接

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat