7.3. ブートストラップ仮想マシンの問題
OpenShift Container Platform インストールプログラムは、OpenShift Container Platform クラスターノードのプロビジョニングを処理するブートストラップノードの仮想マシンを起動します。
手順
インストールプログラムをトリガー後の約 10 分から 15 分後に、
virshコマンドを使用してブートストラップ仮想マシンが機能していることを確認します。sudo virsh list
$ sudo virsh listCopy to Clipboard Copied! Toggle word wrap Toggle overflow Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap runningCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ブートストラップ仮想マシンの名前は常にクラスター名で始まり、その後にランダムな文字セットが続き、bootstrap という単語で終わります。
ブートストラップ仮想マシンが 10 - 15 分後に実行されていない場合は、実行されない理由についてトラブルシューティングします。発生する可能性のある問題には以下が含まれます。
libvirtdがシステムで実行されていることを確認します。systemctl status libvirtd
$ systemctl status libvirtdCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンが動作している場合は、これにログインします。
virsh consoleコマンドを使用して、ブートストラップ仮想マシンの IP アドレスを見つけます。sudo virsh console example.com
$ sudo virsh console example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要provisioningネットワークなしで OpenShift Container Platform クラスターをデプロイする場合、172.22.0.2などのプライベート IP アドレスではなく、パブリック IP アドレスを使用する必要があります。IP アドレスを取得したら、
sshコマンドを使用してブートストラップ仮想マシンにログインします。注記直前の手順のコンソール出力では、
ens3で提供される IPv6 IP アドレスまたはens4で提供される IPv4 IP を使用できます。ssh core@172.22.0.2
$ ssh core@172.22.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ブートストラップ仮想マシンへのログインに成功しない場合は、以下いずれかのシナリオが発生した可能性があります。
-
172.22.0.0/24ネットワークにアクセスできない。プロビジョナーとprovisioningネットワークブリッジ間のネットワーク接続を確認します。この問題は、provisioningネットワークを使用している場合に発生することがあります。 -
パブリックネットワーク経由でブートストラップ仮想マシンにアクセスできない。
baremetalネットワークで SSH を試行する際に、provisionerホストの、とくにbaremetalネットワークブリッジについて接続を確認します。 -
Permission denied (publickey,password,keyboard-interactive)が出される。ブートストラップ仮想マシンへのアクセスを試行すると、Permission deniedエラーが発生する可能性があります。仮想マシンへのログインを試行するユーザーの SSH キーがinstall-config.yamlファイル内で設定されていることを確認します。
7.3.1. ブートストラップ仮想マシンがクラスターノードを起動できない リンクのコピーリンクがクリップボードにコピーされました!
デプロイメント時に、ブートストラップ仮想マシンがクラスターノードの起動に失敗する可能性があり、これにより、仮想マシンがノードに RHCOS イメージをプロビジョニングできなくなります。このシナリオは、以下の原因で発生する可能性があります。
-
install-config.yamlファイルに関連する問題。 - ベアメタルネットワークを使用してアウトオブバンド (out-of-band) ネットワークアクセスに関する問題
この問題を確認するには、ironic に関連する 3 つのコンテナーを使用できます。
-
ironic -
ironic-inspector
手順
ブートストラップ仮想マシンにログインします。
ssh core@172.22.0.2
$ ssh core@172.22.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーログを確認するには、以下を実行します。
sudo podman logs -f <container_name>
[core@localhost ~]$ sudo podman logs -f <container_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <container_name>をironicまたはironic-inspectorのいずれかに置き換えます。コントロールプレーンノードが PXE から起動しないという問題が発生した場合は、ironicPod を確認してください。ironicPod は、IPMI 経由でノードにログインしようとするため、クラスターノードを起動しようとする試みに関する情報を含んでいます。
考えられる理由
クラスターノードは、デプロイメントの開始時に ON 状態にある可能性があります。
解決策
IPMI でのインストールを開始する前に、OpenShift Container Platform クラスターノードの電源をオフにします。
ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
$ ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
7.3.2. ログの検査 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS イメージのダウンロードまたはアクセスに問題が発生した場合には、最初に install-config.yaml 設定ファイルで URL が正しいことを確認します。
RHCOS イメージをホストする内部 Web サーバーの例
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
coreos-downloader コンテナーは、Web サーバーまたは外部の quay.io レジストリー (install-config.yaml 設定ファイルで指定されている方) からリソースをダウンロードします。coreos-downloader コンテナーが稼働していることを確認し、必要に応じて、そのログを調べます。
手順
ブートストラップ仮想マシンにログインします。
ssh core@172.22.0.2
$ ssh core@172.22.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ブートストラップ VM 内の
coreos-downloaderコンテナーのステータスを確認します。sudo podman logs -f coreos-downloader
[core@localhost ~]$ sudo podman logs -f coreos-downloaderCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンがイメージへの URL にアクセスできない場合、
curlコマンドを使用して、仮想マシンがイメージにアクセスできることを確認します。すべてのコンテナーがデプロイメントフェーズで起動されているかどうかを示す
bootkubeログを検査するには、以下を実行します。journalctl -xe
[core@localhost ~]$ journalctl -xeCopy to Clipboard Copied! Toggle word wrap Toggle overflow journalctl -b -f -u bootkube.service
[core@localhost ~]$ journalctl -b -f -u bootkube.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow dnsmasq、mariadb、httpd、およびironicを含むすべての Pod が実行中であることを確認します。sudo podman ps
[core@localhost ~]$ sudo podman psCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod に問題がある場合には、問題のあるコンテナーのログを確認します。
ironicサービスのログを確認するには、次のコマンドを実行します。sudo podman logs ironic
[core@localhost ~]$ sudo podman logs ironicCopy to Clipboard Copied! Toggle word wrap Toggle overflow