7.3. ブートストラップ仮想マシンの問題
OpenShift Container Platform インストールプログラムは、OpenShift Container Platform クラスターノードのプロビジョニングを処理するブートストラップノードの仮想マシンを起動します。
手順
インストールプログラムをトリガー後の約 10 分から 15 分後に、
virsh
コマンドを使用してブートストラップ仮想マシンが機能していることを確認します。$ sudo virsh list
Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
注記ブートストラップ仮想マシンの名前は常にクラスター名で始まり、その後にランダムな文字セットが続き、bootstrap という単語で終わります。
ブートストラップ仮想マシンが 10 - 15 分後に実行されていない場合は、実行されない理由についてトラブルシューティングします。発生する可能性のある問題には以下が含まれます。
libvirtd
がシステムで実行されていることを確認します。$ systemctl status libvirtd
● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-03-03 21:21:07 UTC; 3 weeks 5 days ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 9850 (libvirtd) Tasks: 20 (limit: 32768) Memory: 74.8M CGroup: /system.slice/libvirtd.service ├─ 9850 /usr/sbin/libvirtd
ブートストラップ仮想マシンが動作している場合は、これにログインします。
virsh console
コマンドを使用して、ブートストラップ仮想マシンの IP アドレスを見つけます。$ sudo virsh console example.com
Connected to domain example.com Escape character is ^] Red Hat Enterprise Linux CoreOS 43.81.202001142154.0 (Ootpa) 4.3 SSH host key: SHA256:BRWJktXZgQQRY5zjuAV0IKZ4WM7i4TiUyMVanqu9Pqg (ED25519) SSH host key: SHA256:7+iKGA7VtG5szmk2jB5gl/5EZ+SNcJ3a2g23o0lnIio (ECDSA) SSH host key: SHA256:DH5VWhvhvagOTaLsYiVNse9ca+ZSW/30OOMed8rIGOc (RSA) ens3: fd35:919d:4042:2:c7ed:9a9f:a9ec:7 ens4: 172.22.0.2 fe80::1d05:e52e:be5d:263f localhost login:
重要provisioning
ネットワークなしで OpenShift Container Platform クラスターをデプロイする場合、172.22.0.2
などのプライベート IP アドレスではなく、パブリック IP アドレスを使用する必要があります。IP アドレスを取得したら、
ssh
コマンドを使用してブートストラップ仮想マシンにログインします。注記直前の手順のコンソール出力では、
ens3
で提供される IPv6 IP アドレスまたはens4
で提供される IPv4 IP を使用できます。$ ssh core@172.22.0.2
ブートストラップ仮想マシンへのログインに成功しない場合は、以下いずれかのシナリオが発生した可能性があります。
-
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
コンテナーログを確認するには、以下を実行します。
[core@localhost ~]$ sudo podman logs -f <container_name>
<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
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
coreos-downloader
コンテナーは、Web サーバーまたは外部の quay.io レジストリー (install-config.yaml
設定ファイルで指定されている方) からリソースをダウンロードします。coreos-downloader
コンテナーが稼働していることを確認し、必要に応じて、そのログを調べます。
手順
ブートストラップ仮想マシンにログインします。
$ ssh core@172.22.0.2
次のコマンドを実行して、ブートストラップ VM 内の
coreos-downloader
コンテナーのステータスを確認します。[core@localhost ~]$ sudo podman logs -f coreos-downloader
ブートストラップ仮想マシンがイメージへの URL にアクセスできない場合、
curl
コマンドを使用して、仮想マシンがイメージにアクセスできることを確認します。すべてのコンテナーがデプロイメントフェーズで起動されているかどうかを示す
bootkube
ログを検査するには、以下を実行します。[core@localhost ~]$ journalctl -xe
[core@localhost ~]$ journalctl -b -f -u bootkube.service
dnsmasq
、mariadb
、httpd
、およびironic
を含むすべての Pod が実行中であることを確認します。[core@localhost ~]$ sudo podman ps
Pod に問題がある場合には、問題のあるコンテナーのログを確認します。
ironic
サービスのログを確認するには、次のコマンドを実行します。[core@localhost ~]$ sudo podman logs ironic