インストール
MicroShift クラスターのインストールと設定
概要
第1章 RPM パッケージからの MicroShift のインストール
Red Hat Enterprise Linux (RHEL) 9.2 を搭載したマシンに RPM パッケージから MicroShift をインストールできます。
MicroShift はテクノロジープレビューのみです。このテクノロジープレビューソフトウェアは、Red Hat 製品サービスレベルアグリーメント (SLA) ではサポートされておらず、機能的に完全ではない可能性があります。Red Hat は、本番環境で MicroShift を使用することを推奨していません。テクノロジープレビューは、近々発表予定の製品機能をリリースに先駆けてご提供します。これにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat は、テクノロジープレビューバージョンから新しいバージョンの MicroShift への更新パスをサポートしていません。新規インストールが必要です。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
1.1. MicroShift をインストールするためのシステム要件
MicroShift をインストールする前に、次の条件を満たす必要があります。
- RHEL 9.2
- 2 CPU コア
- MicroShift の場合は 2 GB RAM、ネットワークベースの HTTP または FTP インストールの場合は RHEL で必要な 3 GB RAM
- 10 GB のストレージ
- Red Hat アカウントに有効な MicroShift サブスクリプションがある。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
- MicroShift RPM を含むサブスクリプションがある。
- ワークロードの永続ボリューム (PV) に十分な容量を持つ論理ボリュームマネージャー (LVM) ボリュームグループ (VG) がある。
1.2. RPM パッケージからの MicroShift のインストール
MicroShift は、永続ボリューム (PV) にストレージを提供するために、論理ボリュームマネージャーストレージ (LVMS) Container Storage Interface (CSI) プラグインを使用します。LVMS は、Linux 論理ボリュームマネージャー (LVM) を利用して、PV のバッキング論理ボリューム (LV) を動的に管理します。このため、マシンには、LVMS がワークロードの PV 用の LV を作成できる未使用スペースのある LVM ボリュームグループ (VG) が必要です。
LVMS がワークロードの PV 用の LV を作成できるようにボリュームグループ (VG) を設定するには、RHEL のインストール中にルートボリュームの 希望サイズ を小さくします。ルートボリュームのサイズを下げると、実行時に LVMS によって作成される追加の LV 用の未割り当て領域がディスク上に確保されます。
1.3. RPM パッケージから MicroShift をインストールする準備
ワークロードの永続ボリューム (PV) に十分な容量を持つ論理ボリュームマネージャー (LVM) ボリュームグループ (VG) を持つように RHEL マシンを設定します。
前提条件
- MicroShift をインストールするためのシステム要件が満たされている。
- マシンへの root ユーザーアクセス権がある。
- ワークロードの PV に必要な容量を使用して LVM VG を設定している。
手順
- Storage Configuration サブセクションの Installation Destination の下にあるグラフィカルインストーラーで、Custom → Done を選択して、パーティションとボリュームを設定するためのダイアログを開きます。手動パーティショニングウィンドウが表示されます。
- New Red Hat Enterprise Linux 9.x Installation で、Click here to create them automatically を選択します。
- ルートパーティション / を選択し、PV 用に十分な容量が VG に指定されるように 必要な容量 を減らし、Update Settings をクリックします。
インストールを完了します。
注記パーティション設定のその他のオプションは、手動パーティション設定の追加情報セクションにリンクされているガイドを参照してください。
root ユーザーとして、次のコマンドを実行して、システムで使用可能な VG 容量を確認します。
$ sudo vgs
出力例:
VG #PV #LV #SN Attr VSize VFree rhel 1 2 0 wz--n- <127.00g 54.94g
関連情報
- Red Hat Hybrid Cloud Console から プルシークレット をダウンロードします。
- MicroShift の設定
- パーティション設定のその他のオプションは、手動パーティショニングの設定 を参照してください。
- 既存の LV のサイズを変更して VG の容量を解放する方法の詳細は、LVM ボリュームグループの管理 を参照してください。
- VG および PV の作成に関する詳細は、論理ボリューム管理の概要 を参照してください。
1.4. RPM パッケージからの MicroShift のインストール
以下の手順を使用して、RPM パッケージから MicroShift をインストールします。
前提条件
- MicroShift をインストールするためのシステム要件が満たされている。
- RPM パッケージから MicroShift をインストールするための準備の手順を完了している。
手順
root ユーザーとして、次のコマンドを実行して MicroShift リポジトリーを有効にします。
$ sudo subscription-manager repos \ --enable rhocp-4.13-for-rhel-9-$(uname -m)-rpms \ --enable fast-datapath-for-rhel-9-$(uname -m)-rpms
次のコマンドを実行して MicroShift をインストールします。
$ sudo dnf install -y microshift
オプション: 次のコマンドを実行して、MicroShift の greenboot をインストールします。
$ sudo dnf install -y microshift-greenboot
-
インストールのプルシークレットを Red Hat Hybrid Cloud Console から
$HOME/openshift-pull-secret
などの一時フォルダーにダウンロードします。このプルシークレットを使用すると、MicroShift で使用されるコンテナーイメージを提供するコンテナーレジストリーで認証できます。 次のコマンドを実行して、プルシークレットを RHEL マシンの
/etc/crio
フォルダーにコピーします。$ sudo cp $HOME/openshift-pull-secret /etc/crio/openshift-pull-secret
以下のコマンドを実行して、root ユーザーを
/etc/crio/openshift-pull-secret
ファイルの所有者にします。$ sudo chown root:root /etc/crio/openshift-pull-secret
以下のコマンドを実行して、root ユーザーのみが
/etc/crio/openshift-pull-secret
ファイルを読み取りおよび書き込み可能にします。$ sudo chmod 600 /etc/crio/openshift-pull-secret
RHEL マシンでファイアウォールが有効になっている場合は、必須のファイアウォールルールをいくつか設定する必要があります。
firewalld
の場合は、次のコマンドを実行します。$ sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
$ sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1
$ sudo firewall-cmd --reload
MicroShift 用に準備したボリュームグループ (VG) がデフォルト名 rhel
を使用した場合、それ以上の設定は必要ありません。別の名前を使用した場合、またはその他の設定を変更する場合は、MicroShift の設定セクションを参照してください。
1.5. MicroShift サービスの開始
次の手順を使用して、MicroShift サービスを開始します。
前提条件
- RPM パッケージから MicroShift をインストールしている。
手順
root ユーザーとして、次のコマンドを入力して MicroShift サービスを開始します。
$ sudo systemctl start microshift
オプション: マシンの起動時に MicroShift を開始するように RHEL マシンを設定するには、次のコマンドを入力します。
$ sudo systemctl enable microshift
オプション: マシンの起動時に MicroShift が自動的に起動しないようにするには、次のコマンドを入力します。
$ sudo systemctl disable microshift
注記MicroShift サービスが初めて開始されると、MicroShift のコンテナーイメージがダウンロードされて初期化されます。その結果、サービスの初回デプロイ時には MicroShift が起動されるまでに数分かかる場合があります。それ以降は、MicroShift サービスの起動時間が短縮されます。
1.6. MicroShift サービスの停止
次の手順を使用して、MicroShift サービスを停止します。
前提条件
- MicroShift サービスが実行されている。
手順
次のコマンドを入力して、MicroShift サービスを停止します。
$ sudo systemctl stop microshift
MicroShift にデプロイされたワークロードは、MicroShift サービスが停止した後も引き続き実行されます。次のコマンドを入力して、実行中のワークロードを表示します。
$ sudo crictl ps -a
次のコマンドを入力して、デプロイされたワークロードを停止します。
$ sudo systemctl stop kubepods.slice
1.7. MicroShift クラスターへのアクセス方法
このセクションの手順を使用して、MicroShift サービスを実行している同じマシンから、またはワークステーションからリモートで、MicroShift クラスターにアクセスします。このアクセス権を使用して、ワークロードを監視および管理できます。これらの手順を使用する場合は、接続するホスト名または IP アドレスが含まれる kubeconfig
ファイルを選択し、関連するディレクトリーに配置します。各手順にリストされているように、クラスターアクティビティーには OpenShift Container Platform CLI ツール (oc
) を使用します。
1.7.1. MicroShift クラスターへのローカルアクセス
以下の手順に従って、kubeconfig
ファイルを使用して MicroShift クラスターをローカルでアクセスします。
前提条件
-
oc
バイナリーがインストールされている。
手順
オプション: RHEL マシンに
~/.kube/
フォルダーがない場合に作成するには、次のコマンドを実行します。$ mkdir -p ~/.kube/
次のコマンドを実行して、生成されたローカルアクセス
kubeconfig
ファイルを~/.kube/
ディレクトリーにコピーします。$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
次のコマンドを実行して、
~/.kube/config
ファイルの権限を更新します。$ chmod go-r ~/.kube/config
検証
次のコマンドを入力して、MicroShift が実行されていることを確認します。
$ oc get all -A
1.7.2. MicroShift クラスターへのリモートアクセス用にファイアウォールを開く
リモートユーザーが MicroShift クラスターにアクセスできるように、次の手順を使用してファイアウォールを開きます。この手順は、ワークステーションユーザーがリモートでクラスターにアクセスする前に完了する必要があります。
この手順では、user@microshift
は、MicroShift ホストマシン上のユーザーであり、別のワークステーション上のリモートユーザーがアクセスできるようにそのマシンをセットアップする責任があります。
前提条件
-
oc
バイナリーがインストールされている。 - クラスター管理者の権限がある。
手順
MicroShift ホストの
user@microshift
として、次のコマンドを実行して、Kubernetes API サーバー (6443/tcp
) のファイアウォールポートを開きます。[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
検証
user@microshift
として次のコマンドを実行して、MicroShift が入力されていることを確認します。[user@microshift]$ oc get all -A
1.7.3. MicroShift クラスターへのリモートアクセス
以下の手順に従って、kubeconfig
ファイルを使用してリモートワークステーションから MicroShift クラスターにアクセスします。
user@workstation
ログインは、ホストマシンにリモートからアクセスするのに使用されます。手順の <user>
値は、user@workstation
が MicroShift ホストにログインするユーザーの名前になります。
前提条件
-
oc
バイナリーがインストールされている。 -
@user@microshift
は、ローカルホストからファイアウォールを開いている。
手順
RHEL マシンに
~/.kube/
フォルダーがない場合は、user@workstation
として、次のコマンドを実行してフォルダーを作成します。[user@workstation]$ mkdir -p ~/.kube/
user@workstation
として、次のコマンドを実行して、MicroShift ホストのホスト名の変数を設定します。[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
user@workstation
として、次のコマンドを実行して、MicroShift を実行している RHEL マシンからローカルマシンに接続するホスト名または IP アドレスを含む生成されたkubeconfig
ファイルをコピーします。[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
user@workstation
として、次のコマンドを実行して~/.kube/config
ファイルのパーミッションを更新します。$ chmod go-r ~/.kube/config
検証
user@workstation
として、次のコマンドを入力して、MicroShift が実行されていることを確認します。[user@workstation]$ oc get all -A
第2章 RHEL for Edge イメージへの MicroShift の埋め込み
MicroShift を Red Hat Enterprise Linux (RHEL) for Edge 9.2 イメージに埋め込むことができます。このガイドを使用して、MicroShift を含む RHEL イメージを構築します。
MicroShift はテクノロジープレビューのみです。このテクノロジープレビューソフトウェアは、Red Hat 製品サービスレベルアグリーメント (SLA) ではサポートされておらず、機能的に完全ではない可能性があります。Red Hat は、本番環境で MicroShift を使用することを推奨していません。テクノロジープレビューは、近々発表予定の製品機能をリリースに先駆けてご提供します。これにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat は、テクノロジープレビューバージョンから新しいバージョンの MicroShift への更新パスをサポートしていません。新規インストールが必要です。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
2.1. イメージ構築の準備
RHEL for Edge イメージの作成、インストール、および管理 を参照してください。
MicroShift 4.13 のデプロイメントは、Red Hat Enterprise Linux (RHEL) for Edge 9.2 でのみテストされています。他のバージョンの RHEL はサポートされていません。
特定の CPU アーキテクチャー用の Edge 9.2 イメージ用の Red Hat Enterprise Linux (RHEL) をビルドするには、Image Builder のシステム要件 を満たす、同じ CPU アーキテクチャーの RHEL 9.2 ビルドホストが必要です。
Image Builder のインストール の手順に従って、Image Builder と composer-cli
ツールをインストールします。
2.2. Image Builder への MicroShift リポジトリーの追加
次の手順を使用して、ビルドホスト上の Image Builder に MicroShift リポジトリーを追加します。
前提条件
- ビルドホストが Image Builder のシステム要件を満たしている。
-
Image Builder と
composer-cli
ツールをインストールしてセットアップしている。 - ビルドホストへの root ユーザーアクセス権がある。
手順
次のコマンドを実行して、MicroShift の RPM をプルするために必要な
rhocp-4.17
RPM リポジトリーソースを追加するための Image Builder 設定ファイルを作成します。$ cat > rhocp-4.13.toml <<EOF id = "rhocp-4.13" name = "Red Hat OpenShift Container Platform 4.13 for RHEL 9" type = "yum-baseurl" url = "https://cdn.redhat.com/content/dist/layered/rhel9/$(uname -m)/rhocp/4.13/os" check_gpg = true check_ssl = true system = false rhsm = true EOF
次のコマンドを実行して、
fast-datapath
RPM リポジトリーを追加するための Image Builder 設定ファイルを作成します。$ cat > fast-datapath.toml <<EOF id = "fast-datapath" name = "Fast Datapath for RHEL 9" type = "yum-baseurl" url = "https://cdn.redhat.com/content/dist/layered/rhel9/$(uname -m)/fast-datapath/os" check_gpg = true check_ssl = true system = false rhsm = true EOF
次のコマンドを実行して、Image Builder にソースを追加します。
$ sudo composer-cli sources add rhocp-4.13.toml
$ sudo composer-cli sources add fast-datapath.toml
検証
以下のコマンドを実行して、ソースが適切に追加されたことを確認します。
$ sudo composer-cli sources list
出力例
appstream baseos fast-datapath rhocp-4.13
2.3. ブループリントへの MicroShift サービスの追加する
MicroShift RPM パッケージを Image Builder ブループリントに追加すると、MicroShift が埋め込まれた RHEL for Edge イメージをビルドできるようになります。
手順
次の例を使用して、ブループリントを作成します。
Image Builder のブループリントの例
$ cat > minimal-microshift.toml <<EOF name = "minimal-microshift" description = "" version = "0.0.1" modules = [] groups = [] [[packages]] name = "microshift" version = "*" [[packages]] name = "microshift-greenboot" 1 version = "*" [customizations.services] enabled = ["microshift"] EOF
- 1
- オプションの
microshift-greenboot
RPM。詳細は、「アプリケーションの実行」セクションの「Greenboot ヘルスチェック」ガイドを参照してください。
注記コマンドのワイルドカード
*
は、最新の MicroShift RPM を使用します。特定のバージョンが必要な場合は、ワイルドカードを必要なバージョンに置き換えます。たとえば、MicroShift 4.16.0 RPM をダウンロードするには、4.16.0 を挿入します。次のコマンドを実行して、Image Builder にブループリントを追加します。
$ sudo composer-cli blueprints push minimal-microshift.toml
検証
次のコマンドを実行して、MicroShift パッケージのみをリストした Image Builder 設定を確認します。
$ sudo composer-cli blueprints depsolve minimal-microshift | grep microshift
出力例
blueprint: minimal-microshift v0.0.1 microshift-greenboot-4.13.1-202305250827.p0.g4105d3b.assembly.4.13.1.el9.noarch microshift-networking-4.13.1-202305250827.p0.g4105d3b.assembly.4.13.1.el9.x86_64 microshift-release-info-4.13.1-202305250827.p0.g4105d3b.assembly.4.13.1.el9.noarch microshift-4.13.1-202305250827.p0.g4105d3b.assembly.4.13.1.el9.x86_64 microshift-selinux-4.13.1-202305250827.p0.g4105d3b.assembly.4.13.1.el9.noarch
オプション: 次のコマンドを実行して、インストールするすべてのコンポーネントをリストした Image Builder 設定を確認します。
$ sudo composer-cli blueprints depsolve minimal-microshift
2.4. Red Hat Enterprise Linux (RHEL) for Edge イメージの作成
ISO を作成するには、以下の手順を使用します。RHEL for Edge Installer イメージは、実行中のコンテナーからコミットをプルし、組み込みの OSTree コミットを使用するように設定されたキックスタートファイルを持つ、インストール可能なブート ISO を作成します。
前提条件
- ビルドホストが Image Builder のシステム要件を満たしている。
-
Image Builder と
composer-cli
ツールをインストールしてセットアップしている。 - ビルドホストへの root ユーザーアクセス権がある。
-
podman
ツールがある。
手順
以下のコマンドを実行して
ostree
コンテナーイメージビルドを開始します。$ BUILDID=$(sudo composer-cli compose start-ostree --ref "rhel/9/$(uname -m)/edge" minimal-microshift edge-container | awk '{print $2}')
このコマンドは、監視対象のビルドの ID (ID) も返します。
次のコマンドを実行して、ビルドのステータスを定期的に確認できます。
$ sudo composer-cli compose status
実行中のビルドの出力例
ID Status Time Blueprint Version Type Size cc3377ec-4643-4483-b0e7-6b0ad0ae6332 RUNNING Wed Jun 7 12:26:23 2023 minimal-microshift 0.0.1 edge-container
完了したビルドの出力例
ID Status Time Blueprint Version Type Size cc3377ec-4643-4483-b0e7-6b0ad0ae6332 FINISHED Wed Jun 7 12:32:37 2023 minimal-microshift 0.0.1 edge-container
注記起動および停止方法を理解している場合は、
watch
コマンドを使用してビルドを監視できます。ID を使用してコンテナーイメージをダウンロードし、次のコマンドを実行して、使用可能なイメージを取得します。
$ sudo composer-cli compose image ${BUILDID}
次のコマンドを実行して、ダウンロードしたコンテナーイメージの所有権を現在のユーザーに変更します。
$ sudo chown $(whoami). ${BUILDID}-container.tar
次のコマンドを実行して、現在のユーザーの読み取り権限をイメージに追加します。
$ sudo chmod a+r ${BUILDID}-container.tar
以下の手順を実行して、
ostree
コンテナーイメージが ISO ビルドで使用されるようにポート 8085 でサーバーをブートストラップします。次のコマンドを実行して、
IMAGEID
変数の結果を取得します。$ IMAGEID=$(cat < "./${BUILDID}-container.tar" | sudo podman load | grep -o -P '(?<=sha256[@:])[a-z0-9]*')
IMAGEID
変数の結果をもとに、以下のコマンドを実行して podman コマンドを実行します。$ sudo podman run -d --name=minimal-microshift-server -p 8085:8080 ${IMAGEID}
このコマンドは、監視用に
IMAGEID
変数に保存されているコンテナーの ID も返します。
次のコマンドを実行して、インストーラーブループリントファイルを生成します。
$ cat > microshift-installer.toml <<EOF name = "microshift-installer" description = "" version = "0.0.0" modules = [] groups = [] packages = [] EOF
2.5. Image Builder へのブループリントの追加および ISO の構築
次のコマンドを実行して、Image Builder にブループリントを追加します。
$ sudo composer-cli blueprints push microshift-installer.toml
以下のコマンドを実行して
ostree
ISO ビルドを開始します。$ BUILDID=$(sudo composer-cli compose start-ostree --url http://localhost:8085/repo/ --ref "rhel/9/$(uname -m)/edge" microshift-installer edge-installer | awk '{print $2}')
このコマンドは、監視対象のビルドの ID (ID) も返します。
次のコマンドを実行して、ビルドのステータスを定期的に確認できます。
$ sudo composer-cli compose status
実行中のビルドの出力例
ID Status Time Blueprint Version Type Size c793c24f-ca2c-4c79-b5b7-ba36f5078e8d RUNNING Wed Jun 7 13:22:20 2023 microshift-installer 0.0.0 edge-installer
完了したビルドの出力例
ID Status Time Blueprint Version Type Size c793c24f-ca2c-4c79-b5b7-ba36f5078e8d FINISHED Wed Jun 7 13:34:49 2023 microshift-installer 0.0.0 edge-installer
2.6. ISO のダウンロードおよび使用準備
以下のコマンドを実行して、ID を使用して ISO をダウンロードします。
$ sudo composer-cli compose image ${BUILDID}
次のコマンドを実行して、ダウンロードしたコンテナーイメージの所有権を現在のユーザーに変更します。
$ sudo chown $(whoami). ${BUILDID}-installer.iso
次のコマンドを実行して、現在のユーザーの読み取り権限をイメージに追加します。
$ sudo chmod a+r ${BUILDID}-installer.iso
2.7. MicroShift 用のマシンのプロビジョニング
RHEL for Edge ドキュメントの手順を使用して、RHEL for Edge イメージでマシンをプロビジョニングします。
MicroShift を使用するには、次の要件を満たすようにシステムをプロビジョニングする必要があります。
- プロビジョニングするマシンは、MicroShift をインストールするためのシステム要件を満たしている必要があります。
- ファイルシステムに、ワークロードの永続ボリューム (PV) に十分な容量を持つ論理ボリュームマネージャー (LVM) ボリュームグループ (VG) がある。
-
Red Hat Hybrid Cloud Console からのプルシークレットが
/etc/crio/openshift-pull-secret
として存在し、root ユーザーのみの読み取り/書き込みパーミッションがある。 - ファイアウォールは、MicroShift の必要なファイアウォール設定で設定している。
RHEL for Edge Installer (ISO) イメージなどのキックスタートを使用している場合は、上記の要件を満たすようにキックスタートファイルを更新できます。
前提条件
RHEL for Edge Commit を含む RHEL for Edge インストーラー (ISO) イメージを MicroShift で作成している。
- この要件には、RFE コンテナーイメージの作成、RFE インストーラブループリントの作成、RFE コンテナーの起動、および RFE インストーライメージの作成の手順が含まれます。
キックスタートファイルを作成しているか、既存のファイルを使用している。キックスタートファイルには、以下を含める必要があります。
- ユーザーの作成方法に関する詳細な手順
- RHEL for Edge イメージをフェッチしてデプロイする方法
詳細は、関連情報を参照してください。
手順
キックスタートファイルのメインセクションで、システムルートに少なくとも 10GB が指定されている
rhel
という名前の LVM ボリュームグループが含まれるように、ファイルシステムのセットアップを更新します。LVMS CSI ドライバーがワークロードのデータを格納するために使用する空き領域を残します。ファイルシステムを設定するためのキックスタートスニペットの例
# Partition disk such that it contains an LVM volume group called `rhel` with a # 10GB+ system root but leaving free space for the LVMS CSI driver for storing data. # # For example, a 20GB disk would be partitioned in the following way: # # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sda 8:0 0 20G 0 disk # ├─sda1 8:1 0 200M 0 part /boot/efi # ├─sda1 8:1 0 800M 0 part /boot # └─sda2 8:2 0 19G 0 part # └─rhel-root 253:0 0 10G 0 lvm /sysroot # ostreesetup --nogpg --osname=rhel --remote=edge \ --url=file:///run/install/repo/ostree/repo --ref=rhel/<RHEL VERSION NUMBER>/x86_64/edge zerombr clearpart --all --initlabel part /boot/efi --fstype=efi --size=200 part /boot --fstype=xfs --asprimary --size=800 # Uncomment this line to add a SWAP partition of the recommended size #part swap --fstype=swap --recommended part pv.01 --grow volgroup rhel pv.01 logvol / --vgname=rhel --fstype=xfs --size=10000 --name=root # To add users, use a line such as the following user --name=<YOUR_USER_NAME> \ --password=<YOUR_HASHED_PASSWORD> \ --iscrypted --groups=<YOUR_USER_GROUPS>
キックスタートファイルの
%post
セクションで、プルシークレットと必須のファイアウォールルールを追加します。プルシークレットとファイアウォールルールを追加するためのキックスタートスニペットの例
%post --log=/var/log/anaconda/post-install.log --erroronfail # Add the pull secret to CRI-O and set root user-only read/write permissions cat > /etc/crio/openshift-pull-secret << EOF YOUR_OPENSHIFT_PULL_SECRET_HERE EOF chmod 600 /etc/crio/openshift-pull-secret # Configure the firewall with the mandatory rules for MicroShift firewall-offline-cmd --zone=trusted --add-source=10.42.0.0/16 firewall-offline-cmd --zone=trusted --add-source=169.254.169.1 %end
次のコマンドを実行して、
mkksiso
ツールをインストールします。$ sudo yum install -y lorax
次のコマンドを実行して、ISO のキックスタートファイルを新しいキックスタートファイルで更新します。
$ sudo mkksiso <your_kickstart>.ks <your_installer>.iso <updated_installer>.iso
2.8. MicroShift クラスターへのアクセス方法
このセクションの手順を使用して、MicroShift サービスを実行している同じマシンから、またはワークステーションからリモートで、MicroShift クラスターにアクセスします。このアクセス権を使用して、ワークロードを監視および管理できます。これらの手順を使用する場合は、接続するホスト名または IP アドレスが含まれる kubeconfig
ファイルを選択し、関連するディレクトリーに配置します。各手順にリストされているように、クラスターアクティビティーには OpenShift Container Platform CLI ツール (oc
) を使用します。
2.8.1. MicroShift クラスターへのローカルアクセス
以下の手順に従って、kubeconfig
ファイルを使用して MicroShift クラスターをローカルでアクセスします。
前提条件
-
oc
バイナリーがインストールされている。
手順
オプション: RHEL マシンに
~/.kube/
フォルダーがない場合に作成するには、次のコマンドを実行します。$ mkdir -p ~/.kube/
次のコマンドを実行して、生成されたローカルアクセス
kubeconfig
ファイルを~/.kube/
ディレクトリーにコピーします。$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
次のコマンドを実行して、
~/.kube/config
ファイルの権限を更新します。$ chmod go-r ~/.kube/config
検証
次のコマンドを入力して、MicroShift が実行されていることを確認します。
$ oc get all -A
2.8.2. MicroShift クラスターへのリモートアクセス用にファイアウォールを開く
リモートユーザーが MicroShift クラスターにアクセスできるように、次の手順を使用してファイアウォールを開きます。この手順は、ワークステーションユーザーがリモートでクラスターにアクセスする前に完了する必要があります。
この手順では、user@microshift
は、MicroShift ホストマシン上のユーザーであり、別のワークステーション上のリモートユーザーがアクセスできるようにそのマシンをセットアップする責任があります。
前提条件
-
oc
バイナリーがインストールされている。 - クラスター管理者の権限がある。
手順
MicroShift ホストの
user@microshift
として、次のコマンドを実行して、Kubernetes API サーバー (6443/tcp
) のファイアウォールポートを開きます。[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
検証
user@microshift
として次のコマンドを実行して、MicroShift が入力されていることを確認します。[user@microshift]$ oc get all -A
2.8.3. MicroShift クラスターへのリモートアクセス
以下の手順に従って、kubeconfig
ファイルを使用してリモートワークステーションから MicroShift クラスターにアクセスします。
user@workstation
ログインは、ホストマシンにリモートからアクセスするのに使用されます。手順の <user>
値は、user@workstation
が MicroShift ホストにログインするユーザーの名前になります。
前提条件
-
oc
バイナリーがインストールされている。 -
@user@microshift
は、ローカルホストからファイアウォールを開いている。
手順
RHEL マシンに
~/.kube/
フォルダーがない場合は、user@workstation
として、次のコマンドを実行してフォルダーを作成します。[user@workstation]$ mkdir -p ~/.kube/
user@workstation
として、次のコマンドを実行して、MicroShift ホストのホスト名の変数を設定します。[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
user@workstation
として、次のコマンドを実行して、MicroShift を実行している RHEL マシンからローカルマシンに接続するホスト名または IP アドレスを含む生成されたkubeconfig
ファイルをコピーします。[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
user@workstation
として、次のコマンドを実行して~/.kube/config
ファイルのパーミッションを更新します。$ chmod go-r ~/.kube/config
検証
user@workstation
として、次のコマンドを入力して、MicroShift が実行されていることを確認します。[user@workstation]$ oc get all -A
第3章 Greenboot ヘルスチェック
Greenboot は、RPM-OSTree ベースのシステム上の systemd
サービスの一般的なヘルスチェックフレームワークです。microshift-greenboot
RPM と greenboot-default-health-checks
は、インストールできるオプションの RPM パッケージです。greenboot は、システムの状態を評価し、ソフトウェアに問題が発生した場合に最後の正常な状態へのロールバックを自動化するために使用されます。
このヘルスチェックフレームワークは、ソフトウェアの問題をチェックし、直接的なサービスが制限されているか存在しないエッジデバイスでシステムロールバックを実行する必要がある場合に特に役立ちます。ヘルスチェックスクリプトをインストールして設定すると、システムが起動するたびにヘルスチェックが実行します。
greenboot を使用すると、更新中にエッジデバイスからロックアウトされるリスクを軽減し、更新が失敗した場合にサービスが大幅に中断されるのを防ぐことができます。障害が検出されると、システムは rpm-ostree
ロールバック機能を使用して、最後に認識された動作設定で起動します。
MicroShift ヘルスチェックスクリプトは、microshift-greenboot
RPM に含まれています。greenboot-default-health-checks
RPM には、DNS および ostree
サービスにアクセスできることを確認するヘルスチェックスクリプトが含まれています。実行中のワークロードに基づいて、独自のヘルスチェックスクリプトを作成することもできます。たとえば、アプリケーションが開始したことを確認するものを作成できます。
OSTree を使用していないシステムで更新に失敗した場合、ロールバックはできません。これは、ヘルスチェックが実行される場合にも当てはまります。
3.1. greenboot がディレクトリーを使用してスクリプトを実行する方法
ヘルスチェックスクリプトは、4 つの /etc/greenboot
ディレクトリーから実行します。これらのスクリプトはアルファベット順に実行します。ワークロードのスクリプトを設定するときは、このことに留意してください。
システムが起動すると、greenboot は、required.d
および wanted.d
ディレクトリーでスクリプトを実行します。これらのスクリプトの結果に応じて、greenboot は起動を続行するか、次のようにロールバックを試みます。
-
システムが想定どおりの場合:
required.d
ディレクトリー内のすべてのスクリプトが成功すると、greenboot は/etc/greenboot/green.d
ディレクトリーにあるすべてのスクリプトを実行します。 -
システムに問題が発生している場合:
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
ヘルスチェックスクリプトは、このディレクトリーにインストールされます。
-
スクリプトが失敗すると、greenboot はデフォルトでスクリプトを 3 回再試行します。
/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 のクリーンアップを実行して、システムが以前のバージョンにロールバックされた後の潜在的な競合を回避します。
3.2. MicroShift ヘルススクリプト
40_microshift_running_check.sh
ヘルスチェックスクリプトは、コア MicroShift サービスの検証のみを実行します。カスタマイズしたワークロード検証スクリプトを greenboot ディレクトリーにインストールして、システムの更新後にアプリケーションが正常に動作するようにします。スクリプトはアルファベット順に実行されます。
次の表に、MicroShift ヘルスチェックを示します。
検証 | Pass | Fail |
---|---|---|
スクリプトが | 次の手順 |
|
| 次の手順 |
|
| 次の手順 |
|
Kubernetes API ヘルスエンドポイントが機能し、トラフィックを受信するまで待つ | 次の手順 |
|
任意の Pod が開始するのを待つ | 次の手順 |
|
コア namespace ごとに、イメージがプルされるのを待つ | 次の手順 |
|
コア namespace ごとに、Pod の準備が整うまで待つ | 次の手順 |
|
コア namespace ごとに、Pod が再起動していないかどうかを確認する |
|
|
3.2.1. 検証待機期間
各検証の待機時間は、デフォルトで 5 分です。待機期間の後、検証が成功しなかった場合は、失敗が宣言されます。この待機期間は、検証ループで起動するたびに基本待機期間だけ増加します。
-
/etc/greenboot/greenboot.conf
設定ファイルでMICROSHIFT_WAIT_TIMEOUT_SEC
環境変数を設定することにより、基本時間の待機期間をオーバーライドできます。たとえば、MICROSHIFT_WAIT_TIMEOUT_SEC=180
のように値を 180 秒にリセットすることで、待機時間を 3 分に変更できます。
3.3. systemd ジャーナルサービスデータの永続性を有効にする
systemd
ジャーナルサービスのデフォルト設定では、揮発性の /run/log/journal
ディレクトリーにデータが保存されます。システムの起動と再起動をまたがってシステムログを永続化するには、ログの永続化を有効にし、ジャーナルデータの最大サイズに制限を設定する必要があります。
手順
次のコマンドを実行してディレクトリーを作成します。
$ sudo mkdir -p /etc/systemd/journald.conf.d
次のコマンドを実行して、設定ファイルを作成します。
cat <<EOF | sudo tee /etc/systemd/journald.conf.d/microshift.conf &>/dev/null [Journal] Storage=persistent SystemMaxUse=1G RuntimeMaxUse=1G EOF
- サイズ要件に合わせて設定ファイルの値を編集します。
関連情報
3.4. 更新とサードパーティーのワークロード
ヘルスチェックは、更新後に特に役立ちます。Greenboot ヘルスチェックの出力を調べて、更新が有効であると宣言されたかどうかを判断できます。このヘルスチェックは、システムが正常に動作しているかどうかを判断するのに役立ちます。
更新用のヘルスチェックスクリプトは /etc/greenboot/check/required.d
ディレクトリーにインストールされ、システムの起動時に自動的に実行します。ゼロ以外のステータスでスクリプトを終了すると、システムの起動が失敗したと宣言されます。
サードパーティーのワークロードを開始する前に、更新が有効であると宣言されるまで待ちます。ワークロードの開始後にロールバックを実行すると、データが失われる可能性があります。一部のサードパーティーのワークロードは、更新が完了する前にデバイスでデータを作成または更新します。ロールバックすると、ファイルシステムは更新前の状態に戻ります。
3.5. 更新結果の確認
起動に成功すると、Greenboot は GRUB で変数 boot_success=
を 1
に設定します。次の手順を使用して、更新後のシステムヘルスチェックの全体的なステータスをシステムログで表示できます。
手順
システムヘルスチェックの全体的なステータスにアクセスするには、次のコマンドを実行します。
$ sudo grub2-editenv - list | grep ^boot_success
システムが正常に起動した場合の出力例
boot_success=1
3.6. システムログのヘルスチェック出力へのアクセス
次の手順を使用して、システムログのヘルスチェックの出力に手動でアクセスできます。
手順
ヘルスチェックの結果にアクセスするには、次のコマンドを実行します。
$ sudo journalctl -o cat -u greenboot-healthcheck.service
失敗したヘルスチェックの出力例
... ... 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 ... ...
3.7. システムログのプレロールバックヘルスチェック出力へのアクセス
システムログのヘルスチェックスクリプトの出力にアクセスできます。たとえば、次の手順でプレロールバックスクリプトの結果を確認します。
手順
プレロールバックスクリプトの結果にアクセスするには、次のコマンドを実行します。
$ sudo journalctl -o cat -u redboot-task-runner.service
プレロールバックスクリプトの出力例
... ... 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.
3.8. ヘルススクリプトを使用した更新の確認
次の手順を使用して、更新後にシステムログ内のヘルスチェックスクリプトの出力にアクセスします。
手順
更新チェックの結果にアクセスするには、次のコマンドを実行します。
$ sudo grub2-editenv - list | grep ^boot_success
更新が成功した場合の出力例
boot_success=1
コマンドが boot_success=0
を返す場合は、greenboot ヘルスチェックがまだ実行しているか、更新が失敗しています。