5.3. ブートストラップ仮想マシンの問題のトラブルシューティング
OpenShift Container Platform インストールプログラムは、OpenShift Container Platform クラスターノードのプロビジョニングを処理するブートストラップノードの仮想マシンを起動します。
手順
インストールプログラムをトリガー後の約 10 分から 15 分後に、
virsh
コマンドを使用してブートストラップ仮想マシンが機能していることを確認します。sudo virsh list
$ sudo virsh list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ブートストラップ仮想マシンの名前は常にクラスター名で始まり、その後にランダムな文字セットが続き、"bootstrap" という単語で終わります。
10 - 15 分経ってもブートストラップ仮想マシンが実行されない場合は、次のコマンドを実行して、システム上で
libvirtd
が実行されていることを確認します。systemctl status libvirtd
$ systemctl status libvirtd
Copy 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.com
Copy 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.2
Copy 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
ファイル内で設定されていることを確認します。
5.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.2
Copy 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 から起動しないという問題が発生した場合は、ironic
Pod を確認してください。ironic
Pod は、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
5.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.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ブートストラップ VM 内の
coreos-downloader
コンテナーのステータスを確認します。sudo podman logs -f coreos-downloader
[core@localhost ~]$ sudo podman logs -f coreos-downloader
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンがイメージへの URL にアクセスできない場合、
curl
コマンドを使用して、仮想マシンがイメージにアクセスできることを確認します。すべてのコンテナーがデプロイメントフェーズで起動されているかどうかを示す
bootkube
ログを検査するには、以下を実行します。journalctl -xe
[core@localhost ~]$ journalctl -xe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow journalctl -b -f -u bootkube.service
[core@localhost ~]$ journalctl -b -f -u bootkube.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dnsmasq
、mariadb
、httpd
、およびironic
を含むすべての Pod が実行中であることを確認します。sudo podman ps
[core@localhost ~]$ sudo podman ps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod に問題がある場合には、問題のあるコンテナーのログを確認します。
ironic
サービスのログを確認するには、次のコマンドを実行します。sudo podman logs ironic
[core@localhost ~]$ sudo podman logs ironic
Copy to Clipboard Copied! Toggle word wrap Toggle overflow