インストール
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
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-secretRHEL マシンでファイアウォールが有効になっている場合は、必須のファイアウォールルールをいくつか設定する必要があります。
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 microshiftMicroShift にデプロイされたワークロードは、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/configuser@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.17RPM リポジトリーソースを追加するための 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-datapathRPM リポジトリーを追加するための 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-greenbootRPM。詳細は、「アプリケーションの実行」セクションの「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以下のコマンドを実行して
ostreeISO ビルドを開始します。$ 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/configuser@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 ヘルスチェックがまだ実行しているか、更新が失敗しています。