Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

MicroShift をインストールする準備

Red Hat build of MicroShift 4.18

MicroShift のインストールを計画し、重要な設定について学習する

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、MicroShift のインストール計画に関する情報を提供し、重要な設定プロセスの詳細を説明します。

第1章 MicroShift をインストールする準備
リンクのコピー

Red Hat Enterprise Linux (RHEL) のインストールタイプと MicroShift 設定を検討し、Red Hat Device Edge のプランニングを行います。

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 のストレージ。
  • Red Hat アカウントに有効な MicroShift サブスクリプションがある。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
  • ワークロードに永続ボリューム (PV) が必要な場合は、ワークロードに十分な空き容量を持つ論理ボリュームマネージャー (LVM) ボリュームグループ (VG) がある。
重要

これらの要件は、MicroShift および Red Hat Enterprise Linux (RHEL) の最小システム要件です。実行予定のワークロードのシステム要件を追加します。

たとえば、IoT ゲートウェイソリューションが 4 GB の RAM を必要とする場合、システムには Red Hat Enterprise Linux (RHEL) と MicroShift 用に少なくとも 2 GB が必要で、ワークロード用にさらに 4 GB が必要です。合計で 6 GB の RAM が必要になります。

リモートロケーションに物理デバイスをデプロイする場合は、今後のニーズに備えて余裕を持たせることを推奨します。必要な RAM が不明な場合で、予算的に可能な場合は、デバイスがサポートできる最大 RAM 容量を使用します。

重要

それに応じて管理できるように、システムへの安全なアクセスを設定するようにしてください。詳細は、2 台のシステム間で OpenSSH を使用した安全な通信の使用 を参照してください。

1.2. 互換性に関する表
リンクのコピー

次の互換性に関する表を参照して、サポート対象のバージョンの RHEL for Edge と使用する予定の MicroShift バージョンの組み合わせを検討してください。

Red Hat Device Edge リリースの互換性に関する表

Red Hat Enterprise Linux (RHEL) と MicroShift は、device-edge コンピューティング向けの単一のソリューションとして連携します。各コンポーネントを個別に更新できますが、製品バージョンの互換性を確保する必要があります。次の表に示すように、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

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

9.2、9.3

4.14

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

1.3. MicroShift インストールツール
リンクのコピー

MicroShift を使用するには、RHEL タイプ (ベアメタル上に、またはプロビジョンする仮想マシンとして) をすでに持っている、またはインストールする予定である必要があります。各ユースケースの詳細は異なりますが、Red Hat Device Edge の各インストールでは、RHEL ツールと OpenShift CLI (oc) が使用されます。

RPM を使用して、既存の RHEL マシンに MicroShift をインストールできます。詳細は、RPM パッケージからのインストール を参照してください。イメージベースの RHEL システムまたは仮想マシンを同時にインストールする場合を除き、他のツールは必要ありません。

1.4. RHEL インストールタイプ
リンクのコピー

クラスターをどこで実行するか、およびアプリケーションが何を実行するかにより、選択する RHEL インストールタイプが決まります。インストールターゲットごとに、オペレーティングシステムと MicroShift の両方を設定する必要があります。アプリケーションストレージのニーズ、クラスターアクセスまたはアプリケーションアクセスに使用するネットワーク、認証とセキュリティーの要件を考慮してください。

それぞれのサポート範囲や使用されるツールなど、RHEL インストールタイプ間の違いを理解する必要があります。

1.4.1. RPM またはパッケージベースのインストールを使用する
リンクのコピー

このシンプルなインストールタイプでは、基本的なコマンドを使用して、既存の RHEL マシンに MicroShift をインストールします。詳細は、RPM パッケージからのインストール を参照してください。RHEL システムまたは仮想マシンを同時にインストールする場合を除き、他のツールは必要ありません。

1.4.2. RHEL イメージベースのインストール
リンクのコピー

イメージベースのインストールタイプでは、エッジデプロイメントに最適化された、rpm-ostree ベースのイミュータブルなバージョンの RHEL が作成されます。

  • RHEL for Edge は、実稼働環境のエッジにデプロイできます。このインストールタイプは、ネットワーク接続が存在する場合でも、完全にオフラインの場合でも、ローカル環境に応じて使用できます。
  • Image Mode for RHEL は、テクノロジープレビューのサポート範囲内で利用できます。このイメージベースのインストールタイプは、OCI コンテナーイメージと起動可能なコンテナーに基づいています。bootc テクノロジーの概要は、bootc: 起動可能なコンテナーのスタートガイド を参照してください。

イメージベースのインストールを選択する場合は、インストールターゲットの接続状態 (オフライン状態またはネットワーク接続状態)、システムイメージをビルドする場所、Red Hat Device Edge のロード方法を考慮してください。一般的なガイダンスとして次のシナリオを使用できます。

  • 完全に自己完結型の RHEL for Edge または非接続環境外の Image Mode for RHEL ISO をビルドし、その ISO をエッジデバイスにローカルにインストールする場合、RPM リポジトリーまたはミラーレジストリーは必要ない可能性があります。
  • コンテナーイメージを含まず、RPM のみで構成される ISO を非接続環境外にビルドする場合は、非接続環境内にミラーレジストリーが必要です。ミラーレジストリーは、コンテナーイメージをプルするために使用します。
  • 非接続環境内にイメージをビルドする場合、またはインストールにパッケージモードを使用する場合は、ミラーレジストリーとローカル RPM ミラーリポジトリーの両方が必要です。高度なユースケースでは、RHEL reposync ユーティリティーまたは Red Hat Satellite のいずれかを使用できます。詳細は、How to create a local mirror of the latest update for Red Hat Enterprise Linux 8 and 9 without using Satellite Server および Red Hat Satellite を参照してください。

1.5. RHEL インストールツールと概念
リンクのコピー

次の RHEL ツールと概念を理解する必要があります。

1.6. Red Hat Device Edge のインストール手順
リンクのコピー

ほとんどのインストールタイプでは、次の手順も実行する必要があります。

  • Red Hat Hybrid Cloud Console から プルシークレット をダウンロードします。
  • MicroShift YAML 設定ファイルにパラメーターと値を追加して、MicroShift を設定する準備をします。詳細は、MicroShift 設定ファイルの使用 を参照してください。

  • MicroShift クラスターで使用しているアプリケーションとタスクのストレージを設定する必要があるかどうかを判断します。もしくは、MicroShift ストレージプラグインを完全に無効にします。

  • MicroShift クラスターとアプリケーションで予想されるアクセスニーズに応じて、ネットワーク設定を行います。シングルスタックネットワークとデュアルスタックネットワークのどちらを使用するか、ファイアウォールを設定するか、ルートを設定するかを検討します。

  • クラスターにアクセスするには、OpenShift CLI (oc) をインストールします。詳細は OpenShift CLI スタートガイド を参照してください。
注記

Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) は、予測可能なレイテンシーが重要な場合に使用できます。低レイテンシーのアプリケーションでは、ワークロードのパーティショニングも必要です。低レイテンシーとリアルタイムカーネルの詳細は、低レイテンシーの設定 を参照してください。

第2章 MicroShift での FIPS モードの使用
リンクのコピー

Red Hat Enterprise Linux (RHEL) 9 への MicroShift の RPM ベースのインストールで FIPS モードを使用できます。

  • MicroShift コンテナーで FIPS モードを有効にするには、マシンが起動する前に、ワーカーマシンカーネルが FIPS モードで実行できるようにする必要があります。
  • Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージでの FIPS の使用はサポートされていません。
  • FIPS with Image Mode for RHEL の使用はサポートされていません。

2.1. RHEL RPM ベースのインストールでの FIPS モード
リンクのコピー

MicroShift で FIPS を使用するには、Red Hat Enterprise Linux (RHEL) インストールで暗号化モジュールのセルフチェックを有効にする必要があります。ホストオペレーティングシステムが FIPS モジュールで起動するように設定されると、MicroShift コンテナーは FIPS モードで実行できるように自動的に有効になります。

  • RHEL が FIPS モードで起動されると、MicroShift コアコンポーネントは、x86_64 アーキテクチャーのみでの FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

  • ワーカーマシンとして使用する予定のマシンに RHEL 9 をインストールする場合は、FIPS モードを有効にする必要があります。

    重要

    クラスターが使用するオペレーティングシステムの初回起動時の前に FIPS を有効にする必要があるため、クラスターのデプロイ後に FIPS を有効にすることはできません。

  • MicroShift は、FIPS 互換の Golang コンパイラーを使用します。
  • FIPS は CRI-O コンテナーランタイムでサポートされています。

2.1.1. 制限
リンクのコピー

  • TLS 実装 FIPS サポートは完全ではありません。
  • FIPS 実装は、ハッシュ関数を計算し、そのハッシュに基づくキーを検証する単一の機能を提供しません。この制限は、今後の MicroShift リリースでの改善のために引き続き評価されます。

第3章 Greenboot ヘルスチェックフレームワーク
リンクのコピー

Greenboot は、rpm-ostree システム (Red Hat Enterprise Linux for Edge (RHEL for Edge) など) の systemd サービスの汎用ヘルスチェックフレームワークです。このフレームワークは、microshift-greenboot および greenboot-default-health-checks RPM パッケージとともに MicroShift インストールに組み込まれています。

Greenboot ヘルスチェックはさまざまなタイミングで実行され、システムの健全性を評価し、ソフトウェアの問題が発生した場合に rpm-ostree システムを最後の正常な状態に自動的にロールバックします。次に例を示します。

  • デフォルトのヘルスチェックスクリプトは、システムが起動するたびに実行されます。
  • デフォルトのヘルスチェックに加えて、システムが起動するたびに実行されるようにアプリケーションヘルスチェックスクリプトを作成、インストール、設定することもできます。
  • Greenboot を使用すると、更新中にエッジデバイスからロックアウトされるリスクを軽減し、更新が失敗した場合にサービスが大幅に中断されるのを防ぐことができます。
  • 障害が検出されると、システムは rpm-ostree ロールバック機能を使用して、最後に認識された動作設定で起動します。この機能は、直接的な保守機能が制限されているか存在しないエッジデバイスに特に役立つ自動化機能です。

MicroShift アプリケーションのヘルスチェックスクリプトは、microshift-greenboot RPM に含まれています。greenboot-default-health-checks RPM には、DNS および ostree サービスにアクセスできることを確認するヘルスチェックスクリプトが含まれています。実行しているワークロード用に独自のヘルスチェックスクリプトを作成できます。たとえば、アプリケーションが開始したことを確認するものを作成できます。

3.1. greenboot がディレクトリーを使用してスクリプトを実行する方法
リンクのコピー

ヘルスチェックスクリプトは、4 つの /etc/greenboot ディレクトリーから実行します。これらのスクリプトはアルファベット順に実行します。ワークロードのスクリプトを設定するときは、このことに留意してください。

システムが起動すると、greenboot は、required.d および wanted.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 はデフォルトでスクリプトを 3 回再試行します。/etc/greenboot/greenboot.conf ファイルで再試行回数を設定するには、GREENBOOT_MAX_BOOTS パラメーターを目的の再試行回数に設定します。
    • すべての再試行が失敗すると、ロールバックが利用可能であれば greenboot が自動的に開始します。ロールバックが利用できない場合、システムログ出力は手動介入が必要であることを示します。
    • MicroShift の 40_microshift_running_check.sh ヘルスチェックスクリプトは、このディレクトリーにインストールされます。

  • /etc/greenboot/check/wanted.d には、システムをロールバックさせずに失敗できるヘルススクリプトが含まれています。

    • これらのスクリプトのいずれかが失敗すると、greenboot は失敗を記録しますが、ロールバックを開始しません。
  • /etc/greenboot/green.d には、greenboot が起動の成功を宣言した後に実行されるスクリプトが含まれています。
  • /etc/greenboot/red.d には、40_microshift_pre_rollback.sh プレロールバックスクリプトなど、greenboot が起動の失敗を宣言した後に実行するスクリプトが含まれています。このスクリプトは、システムロールバックの直前に実行されます。このスクリプトは、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

コア namespace ごとに、イメージがプルされるのを待つ

次の手順

exit 1

コア namespace ごとに、Pod の準備が整うまで待つ

次の手順

exit 1

コア namespace ごとに、Pod が再起動していないかどうかを確認する

exit 0

exit 1

3.2.1. 検証待機期間
リンクのコピー

各検証の待機期間はデフォルトで 10 分です。待機期間の後、検証が成功しなかった場合は、失敗が宣言されます。この待機期間は、検証ループで起動するたびに基本待機期間だけ増加します。

  • /etc/greenboot/greenboot.conf 設定ファイルで MICROSHIFT_WAIT_TIMEOUT_SEC 環境変数を設定することにより、基本時間の待機期間をオーバーライドできます。たとえば、MICROSHIFT_WAIT_TIMEOUT_SEC=300 のように値を 300 秒にリセットすることで、待機時間を 5 分に変更できます。

3.3. systemd ジャーナルサービスデータの永続性の有効化
リンクのコピー

systemd ジャーナルサービスのデフォルト設定では、揮発性の /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 600s for MicroShift service to be active and not failed
FAILURE
...
...
Copy to Clipboard Toggle word wrap

3.7. システムログのプレロールバックヘルスチェック出力へのアクセス
リンクのコピー

システムログのヘルスチェックスクリプトの出力にアクセスできます。たとえば、次の手順でプレロールバックスクリプトの結果を確認します。

手順

  • プレロールバックスクリプトの結果にアクセスするには、次のコマンドを実行します。 

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

プレロールバックスクリプトの出力例

...
...
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 © 2025 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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat