OpenShift 4.6 のベアメタル IPI インストールを試す

はじめに

OpenShift 4 では、そのクラスタの構成方法に IPI（Installer-Provisioned Infrastructure）と UPI（User-Provisioned Infrastructure）の二種類があります。

これまで、IPI をサポートするプラットフォームは AWS や Azure、GCP、RHV、vSphere などのパブリッククラウドやオンプレミスの仮想化基盤に限定されていましたが、どうやら先月末にリリースされた OpenShift 4.6 で、ベアメタル環境への IPI インストールが公式にサポートされたようです。

In 4.6, the full stack automation installation of OpenShift on bare metal is generally available.
Red Hat OpenShift 4.6 Is Now Available

これまでも、GitHub 上ではベアメタル IPI の情報は公開されており、以前も VirtualBMC for vSphere のユースケースとしても実際に 4.5 で動作を確認済みでした。

とはいえ、せっかく公式手順に仲間入りしたので、このエントリでは、OpenShift 4.6 で公式にサポートされたベアメタル IPI インストールの方法を、改めて紹介します。ただし、BMC を積んだ物理サーバが潤沢にあるわけではないので、物理サーバは VirtualBMC for vSphere を使った vSphere 環境の仮想マシンで代替します。

なお、今回紹介する手順は OKD でなく OpenShift のものです。インストールすると Red Hat OpenShift Cluster Manager に登録され、60 日間の評価期間 が始まります。

手順の概要

公式の手順を参考に進めます。IPI インストールといえどクラスタ外に本当に何も要らないわけではなく、外部との接続点になるルータ、DHCP サーバ、DNS サーバは必要です。また、物理サーバを自動制御するため、各物理サーバの BMC へも到達できる必要があります。

Overview – Deploying installer-provisioned clusters on bare metal | Installing | OpenShift Container Platform 4.6

インストールの流れ

インストールの中では、最初にブートストラップ VM が構成されて起動されます。この後、コントロールプレーンノードの BMC が制御され、ブートストラップ VM を使って PXE ブートと OS の導入、初期構成が行われます。この段階で一時的にブートストラップ VM が Kubernetes のコントロールプレーンとして振舞うようになり、これを使ってコントロールプレーンノード上にマネジメントクラスタが構成されます。

Overview – Deploying installer-provisioned clusters on bare metal | Installing | OpenShift Container Platform 4.6

この後、ブートストラップ VM からコントロールプレーンの機能がマネジメントクラスタに移譲され、ブートストラップ VM は削除されます。後続のワーカノードのプロビジョニングはマネジメントクラスタを使って行われます。

Overview – Deploying installer-provisioned clusters on bare metal | Installing | OpenShift Container Platform 4.6

ブートストラップクラスタを用いて Kubernetes のクラスタそれ自体をプロビジョニングしていく流れは、Kubernetes の Cluster API のそれとよく似ていますね。

今回の構成

さて、公式には前述の通りの構成ですが、今回はラボ向けに簡略化して次の図の通りに構成します。といっても、きちんとマルチノードには構成します。

ポイントは次の三点です。

クラスタ外に必要なルータ、DHCP サーバ、DNS サーバの機能は、仮想マシン（図中のユーティリティ VM）にサービスさせる
プロビジョニングノード、マスタノード、ワーカノードはすべて vSphere 環境の仮想マシンとして用意する
vSphere 環境の仮想マシンを物理サーバとして振舞わせるため、ユーティリティ VM に VirtualBMC for vSphere を導入し、仮想マシンごとに仮想 BMC を構成する

準備

インストールの前提として、物理サーバ（に相当する仮想マシン）や周辺環境を用意します。

物理サーバに相当する仮想マシンの作成

構成先となる物理サーバに相当するモノとして、vSphere 環境上に仮想マシンを用意します。

役割	vCPU	メモリ	ディスク	NIC #1	NIC #2
マスタノード #1	4	16 GB	128 GB	Provisioning	Baremetal
マスタノード #2	4	16 GB	128 GB	Provisioning	Baremetal
マスタノード #3	4	16 GB	128 GB	Provisioning	Baremetal
ワーカノード #1	4	16 GB	128 GB	Provisioning	Baremetal
ワーカノード #2	4	16 GB	128 GB	Provisioning	Baremetal
プロビジョニング	4	16 GB	128 GB	Provisioning	Baremetal

上記の仮想マシンは、ファームウェアに BIOS を指定しておきます。これは VirtualBMC for vSphere の都合なので、ホントに物理サーバで実施するときにはこの必要はありません。ドキュメントからはプロビジョニングネットワークに IPv6 を使う場合は UEFI でないとダメなように読み取れますが、今回は IPv4 を利用するのでヨシとします。

また、プロビジョニング用 VM では、後続の手順で libvirt を動作させるため、ハードウェア仮想化をゲストに公開する構成にしておきます。

なお、プロビジョニング用 VM を除き、各ノードの OS は IPI インストールの手順の中で自動でインストールされるため、手動での導入は不要です。プロビジョニング用 VM の OS インストールは後続の手順で行います。

仮想マシンができたら、全台で各 NIC（二つ）の MAC アドレスを確認しておきます。後続の手順で追って必要になります。確認には PowerCLI が便利です。

> get-vm ocp-* | get-networkadapter | select parent, networkname, macaddress | where {$_.networkname -eq "vlan11-int-ocp-baremetal"} | sort parent

Parent          NetworkName              MacAddress
------          -----------              ----------
ocp-master0     vlan11-int-ocp-baremetal 00:50:56:86:b1:1a
ocp-master1     vlan11-int-ocp-baremetal 00:50:56:86:ad:2a
ocp-master2     vlan11-int-ocp-baremetal 00:50:56:86:76:93
ocp-provisioner vlan11-int-ocp-baremetal 00:50:56:86:25:d6
ocp-worker0     vlan11-int-ocp-baremetal 00:50:56:86:12:86
ocp-worker1     vlan11-int-ocp-baremetal 00:50:56:86:22:0b

> get-vm ocp-* | get-networkadapter | select parent, networkname, macaddress | where {$_.networkname -eq "vlan10-int-ocp-provision"} | sort parent

Parent          NetworkName              MacAddress
------          -----------              ----------
ocp-master0     vlan10-int-ocp-provision 00:50:56:86:32:ec
ocp-master1     vlan10-int-ocp-provision 00:50:56:86:52:17
ocp-master2     vlan10-int-ocp-provision 00:50:56:86:dc:65
ocp-provisioner vlan10-int-ocp-provision 00:50:56:86:c6:e0
ocp-worker0     vlan10-int-ocp-provision 00:50:56:86:10:5b
ocp-worker1     vlan10-int-ocp-provision 00:50:56:86:d0:a0

ユーティリティ VM の構成

図中のベアメタルネットワーク上にルータや DHCP サーバ、DNS サーバが必要なので、これを用意します。が、物理的なモノは用意できないので、今回は仮想マシン上で構成します。大した機能は動かさないので、スペックは最小限で大丈夫です。

役割	vCPU	メモリ	ディスク	NIC #1	NIC #2
ユーティリティ	1	2 GB	16 GB	Home	Baremetal

OS は最新の RHEL 8.3 を導入しました。最小限の構成でインストールした後、ルータや DHCP サーバ、DNS サーバを作成していきます。

初期設定

IP アドレスとホスト名などを構成します。

localectl set-keymap jp106
hostnamectl set-hostname util.ocp.kuro.lab
nmcli con mod ens192 connection.autoconnect yes ipv4.method manual ipv4.addresses 192.168.0.240/24 ipv4.gateway 192.168.0.1 ipv4.dns 192.168.0.1
nmcli con mod ens224 connection.autoconnect yes ipv4.method manual ipv4.addresses 10.0.0.254/24
reboot

ルータとしての設定

ルータといいつつ単に IP マスカレードを使うようにするだけです。今回は、ベアメタルネットワークとホームネットワークの間で双方向に NAPT させます。firewalld で事前定義されているゾーンのうち、external は masquarade がデフォルトで yes なので、手動での変更は、ゾーンの切り替えと internal の IP マスカレードの有効化だけです。

nmcli con mod ens192 connection.zone external
nmcli con mod ens224 connection.zone internal
firewall-cmd --add-masquerade --zone=internal --permanent
firewall-cmd --reload

DNS サーバの構成

ドキュメントの Network requirements にはあまり情報が書いていませんが、クラスタで利用するノードや仮想 IP アドレス類を外部から名前解決できるようにします。

ここでは、dnsmasq を利用します。基本、/etc/hosts と同じ書式のファイルを読ませるだけですが、それではワイルドカードの名前解決は表現できないので、*.apps 相当のエントリのみ設定ファイルに address 行でベタ書きしています。

dnf install -y dnsmasq
systemctl enable dnsmasq
systemctl start dnsmasq

cat << EOF > /etc/hosts.dnsmasq
10.0.0.10 openshift-master-0
10.0.0.11 openshift-master-1
10.0.0.12 openshift-master-2
10.0.0.20 openshift-worker-0
10.0.0.21 openshift-worker-1
10.0.0.50 api
10.0.0.253 provisioner
EOF

cat << EOF > /etc/dnsmasq.d/dns.dns
domain-needed
bind-dynamic
bogus-priv
domain=ocp.kuro.lab
interface=ens224
no-hosts
addn-hosts=/etc/hosts.dnsmasq
expand-hosts
address=/.apps.ocp.kuro.lab/10.0.0.52
EOF

systemctl restart dnsmasq

firewall-cmd --add-service=dns --zone=internal --permanent
firewall-cmd --reload

DHCP サーバの構成

これもドキュメントの Network requirements にはあまり細かく書いていませんが、静的 DHCP エントリを作成して、DHCP クライアントの MAC アドレスに応じて IP アドレスとホスト名が自動で応答されるようにします。

これにも、dnsmasq を利用します。

cat << EOF > /etc/dnsmasq.d/dhcp.dns
domain-needed
bind-dynamic
bogus-priv
domain=ocp.kuro.lab
dhcp-range=10.0.0.10,10.0.0.49
dhcp-option=3,10.0.0.254
resolv-file=/etc/resolv.conf.upstream
interface=ens224
server=10.0.0.254
dhcp-host=00:50:56:86:25:d6,provisioner.ocp.kuro.lab,10.0.0.253
dhcp-host=00:50:56:86:b1:1a,openshift-master-0.ocp.kuro.lab,10.0.0.10
dhcp-host=00:50:56:86:ad:2a,openshift-master-1.ocp.kuro.lab,10.0.0.11
dhcp-host=00:50:56:86:76:93,openshift-master-2.ocp.kuro.lab,10.0.0.12
dhcp-host=00:50:56:86:12:86,openshift-worker-0.ocp.kuro.lab,10.0.0.20
dhcp-host=00:50:56:86:22:0b,openshift-worker-1.ocp.kuro.lab,10.0.0.21
EOF

cat << EOF > /etc/resolv.conf.upstream
nameserver 192.168.0.1
EOF

systemctl restart dnsmasq

firewall-cmd --add-service=dhcp --zone=internal --permanent
firewall-cmd --reload

記述する MAC アドレスは、各ノードのベアメタルネットワーク側の NIC のものです。

VirtualBMC for vSphere の構成

インストール先のノードは本来は物理サーバで用意しますが、今回は vSphere 環境の仮想マシンで代替します。しかしながら、IPI インストールでは物理サーバの BMC を使う要件があり、単に仮想マシンを立てただけでは不十分です。

そこで、vSphere 環境の仮想マシンに仮想 BMC インタフェイスを提供できる VirtualBMC for vSphere を使って、仮想マシンを IPMI で制御できるようにします。

dnf install -y python38
python3 -m pip install -U pip
python3 -m pip install vbmc4vsphere

vbmcd

vbmc add ocp-master0 --port 6230 --viserver kuro-vcs01.krkb.lab --viserver-username vbmc@vsphere.local --viserver-password ********
vbmc add ocp-master1 --port 6231 --viserver kuro-vcs01.krkb.lab --viserver-username vbmc@vsphere.local --viserver-password ********
vbmc add ocp-master2 --port 6232 --viserver kuro-vcs01.krkb.lab --viserver-username vbmc@vsphere.local --viserver-password ********
vbmc add ocp-worker0 --port 6233 --viserver kuro-vcs01.krkb.lab --viserver-username vbmc@vsphere.local --viserver-password ********
vbmc add ocp-worker1 --port 6234 --viserver kuro-vcs01.krkb.lab --viserver-username vbmc@vsphere.local --viserver-password ********

vbmc start ocp-master0
vbmc start ocp-master1
vbmc start ocp-master2
vbmc start ocp-worker0
vbmc start ocp-worker1

firewall-cmd --add-port=6230-6234/udp --zone=internal --permanent
firewall-cmd --reload

プロビジョニング VM の構成

前の手順で作成したプロビジョニング VM に、RHEL 8.3 を最小限の構成で導入して構成していきます。

OS インストールの手順自体は割愛しますが、前述の DHCP サーバや DNS サーバ、ルータの機能が正しく機能していれば、何もしなくても MAC アドレスを基に静的な IP アドレスとホスト名が正しく取得されるほか、インタネットに名前解決を含めて出られるようになっているはずです。また、ホームネットワーク内の端末で 10.0.0.0/24 宛のルートをユーティリティ VM に向けて構成すれば、そこから直接プロビジョニング VM に SSH できるようになるはずです。

OS のインストールができたら、ここからは愚直にドキュメントに従っていきます。

Setting up the environment for an OpenShift installation – Deploying installer-provisioned clusters on bare metal | Installing | OpenShift Container Platform 4.6

設定ファイルの作成まで

ところどころ変なところがあるので、注記が必要なところだけピックアップします。

Preparing the provisioner node for OpenShift Container Platform installation

途中、sudo nohup bash -c で nmcli を流し込む手順がありますが、クォートがシングルなので環境変数が展開されずに期待通りに構成されません（#27579）。また、IPv4 の場合は provisioning には IPv4 の IP アドレスを振ります。よって、次のようにします。

[kni@provisioner ~]$ export PUB_CONN=<baremetal_nic_name>
[kni@provisioner ~]$ export PROV_CONN=<prov_nic_name>
[kni@provisioner ~]$ sudo -E nohup bash -c '
    nmcli con down "$PROV_CONN"
    nmcli con down "$PUB_CONN"
    nmcli con delete "$PROV_CONN"
    nmcli con delete "$PUB_CONN"
    # RHEL 8.1 appends the word "System" in front of the connection, delete in case it exists
    nmcli con down "System $PUB_CONN"
    nmcli con delete "System $PUB_CONN"
    nmcli connection add ifname provisioning type bridge con-name provisioning
    nmcli con add type bridge-slave ifname "$PROV_CONN" master provisioning
    nmcli connection add ifname baremetal type bridge con-name baremetal
    nmcli con add type bridge-slave ifname "$PUB_CONN" master baremetal
    pkill dhclient; dhclient baremetal
    nmcli connection modify provisioning ipv4.addresses 172.22.0.1/24 ipv4.method manual
    nmcli con down provisioning
    nmcli con up provisioning
'

Extracting the OpenShift Container Platform installer

curl で oc のバイナリをダウンロードしますが、引数で与えている URL が 404 になって失敗します（#27495）。ファイル名に -$VERSION は不要なので、次のようにします。

[kni@provisioner ~]$ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc

Creating an RHCOS images cache (optional)

firewall-cmd で 8080/tcp を追加しますが、その後リロードしていないので実際には通信できないままになってしまいます（#27585）。リロードします。

[kni@provisioner ~]$ sudo firewall-cmd --reload

インストーラから Commit ID を取得する手順では、バイナリの位置が違っているので失敗します（#27583）。カレントディレクトリのバイナリを使ってもよいですが、どちらかというとバイナリの /usr/local/bin へのコピーが抜けている感触なので、そのようにします。

[kni@provisioner ~]$ sudo cp ./openshift-baremetal-install /usr/local/bin
[kni@provisioner ~]$ export COMMIT_ID=$(/usr/local/bin/openshift-baremetal-install version | grep '^built from commit' | awk '{print $4}')

curl でイメージをダウンロードする手順では、-o でディレクトリ名を与えているので失敗します（#27584）。-o にファイル名を加えて回避します。

[kni@provisioner ~]$ curl -L ${RHCOS_PATH}${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_URI}
[kni@provisioner ~]$ curl -L ${RHCOS_PATH}${RHCOS_OPENSTACK_URI} -o /home/kni/rhcos_image_cache/${RHCOS_OPENSTACK_URI}

設定ファイルの作成

いちばん大事なファイルです。サンプルを参考に install-config.yaml を作成します。

apiVersion: v1
baseDomain: kuro.lab
metadata:
  name: ocp
networking:
  machineCIDR: 10.0.0.0/24
  networkType: OVNKubernetes
compute:
- name: worker
  replicas: 2
controlPlane:
  name: master
  replicas: 3
  platform:
    baremetal: {}
platform:
  baremetal:
    apiVIP: 10.0.0.50
    ingressVIP: 10.0.0.52
    provisioningBridge: provisioning
    provisioningNetworkInterface: ens192
    provisioningNetworkCIDR: 172.22.0.0/24
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: ipmi://10.0.0.254:6230
          username: admin
          password: password
        bootMACAddress: 00:50:56:86:32:ec
      - name: openshift-master-1
        role: master
        bmc:
          address: ipmi://10.0.0.254:6231
          username: admin
          password: password
        bootMACAddress: 00:50:56:86:52:17
      - name: openshift-master-2
        role: master
        bmc:
          address: ipmi://10.0.0.254:6232
          username: admin
          password: password
        bootMACAddress: 00:50:56:86:dc:65
      - name: openshift-worker-0
        role: worker
        bmc:
          address: ipmi://10.0.0.254:6233
          username: admin
          password: password
        bootMACAddress: 00:50:56:86:10:5b
      - name: openshift-worker-1
        role: worker
        bmc:
          address: ipmi://10.0.0.254:6234
          username: admin
          password: password
        bootMACAddress: 00:50:56:86:d0:a0
    bootstrapOSImage: http://provisioner.ocp.kuro.lab:8080/rhcos-46.82.202010011740-0-qemu.x86_64.qcow2.gz?sha256=cbaf2e5548af2d1d1153d9a1beca118042e770725166de427792c33a875137cc
    clusterOSImage: http://provisioner.ocp.kuro.lab:8080/rhcos-46.82.202010011740-0-openstack.x86_64.qcow2.gz?sha256=9d88edcacbdf31db9cb9418ee3721c74a3f5bbfc4904db9e383e674a86335bd1
pullSecret: '{"auths":{...}}'
sshKey: 'ssh-rsa ... kni@provisioner'

ポイントは以下です。

platform.baremetal.provisioningNetworkInterface
- ドキュメントに記載はありませんが、無いと次のメッセージで怒られました
- FATAL failed to fetch Cluster: failed to fetch dependency of "Cluster": failed to generate asset "Platform Provisioning Check": platform.baremetal.provisioningNetworkInterface: Invalid value: "": no provisioning network interface is configured, please set this value to be the interface on the provisioning network on your cluster's baremetal hosts
platform.baremetal.hosts[*].bmc
- 物理サーバのごとの BMC の IP アドレスと認証情報です
- 今回の例では、行き先は VirtualBMC です。ノードごとに対応する IP アドレスとポート番号と認証情報を入れています
platform.baremetal.hosts[*].bootMACAddress
- ノードごとのプロビジョニングネットワーク側の NIC の MAC アドレスです
- ノードが PXE ブートする際、ブートストラップ VM 内で動作する DHCP サーバが対象のノードを判断するときに使われます
platform.baremetal.bootstrapOSImage、platform.baremetal.clusterOSImage
- 今回はオプショナルの手順を実行して、 RHCOS のイメージキャッシュをプロビジョニング VM 上に取得し、HTTP で公開しています。インストーラの中でそのキャッシュを利用するため、URL を指定しています
- URL にはファイル名とハッシュ値を含める必要がありますが、必要な情報は前段の手順で環境変数に保存済みで、それぞれ次のコマンドで得られます
  - echo ${RHCOS_QEMU_URI}?sha256=${RHCOS_QEMU_SHA_UNCOMPRESSED}
  - echo ${RHCOS_OPENSTACK_URI}?sha256=${RHCOS_OPENSTACK_SHA_COMPRESSED}
pullSecret
- 前段の手順で作成した pull-secret.txt の中身をそのまま記入します
sshKey
- 前段の手順で作成した /home/kni/.ssh/id_rsa.pub の中身をそのまま記入します。

ファイルができたら、インストール用のマニフェストを作成します。

mkdir ~/clusterconfigs
cp install-config.yaml ~/clusterconfigs
./openshift-baremetal-install --dir ~/clusterconfigs create manifests

インストール

ここまでできたら、インストーラを走らせて待つだけです。

実行

./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster

進捗は画面にも出ますが、ログファイルとしても出力されます。

tail -f ~/clusterconfigs/.openshift_install.log

観察

何も起きなければ放置するだけですが、興味があれば、構成の途中では、プロビジョニング VM 上で動作するブートストラップ VM の様子をみたり、

$ sudo virsh list
 Id   Name                  State
-------------------------------------
 1    ocp-6vw5v-bootstrap   running

ブートストラップ VM のコンソール出力を確認したり、

$ sudo virsh console ocp-6vw5v-bootstrap
Connected to domain ocp-6vw5v-bootstrap
Escape character is ^]
[***   ] A start job is running for Ignition (fetch-offline) (47s / no limit)
...

その IP アドレスを確認して SSH したり、

$ sudo virsh console ocp-6vw5v-bootstrap
Connected to domain ocp-6vw5v-bootstrap
Escape character is ^]
Red Hat Enterprise Linux CoreOS 46.82.202010011740-0 (Ootpa) 4.6
...
ens3: 10.0.0.30 fe80::5054:ff:fe42:654d
ens4: 172.22.0.2 fe80::5607:c92e:39f2:add1
localhost login:

$ ssh core@172.22.0.2
...
[core@localhost ~]$

さらにその中で Podman の様子を見たり、

[core@localhost ~]$ sudo podman ps -a
CONTAINER ID  IMAGE                                                                                                                   COMMAND               CREATED         STATUS                     PORTS  NAMES
...
7d77a65def19  quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:796617722a915d79b478c9623b1d152a397478a7f6ba7ec71d39b9df2668cc80                        35 seconds ago  Up 32 seconds ago                 httpd
051f0c4e27d2  quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:796617722a915d79b478c9623b1d152a397478a7f6ba7ec71d39b9df2668cc80                        35 seconds ago  Up 35 seconds ago                 mariadb
ebed2f88723f  quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:796617722a915d79b478c9623b1d152a397478a7f6ba7ec71d39b9df2668cc80                        35 seconds ago  Up 35 seconds ago                 dnsmasq

[core@localhost ~]$ sudo podman logs -f ironic-conductor
...

他にも、仮想マシンが PXE ブートしたり、勝手にブートデバイスが切り替わりながら再起動していく様子を眺めたりするとおもしろいですね。手を一切触れずにごりごりインストールが進むのは気持ちがよいものです。

ログ抜粋

最終的には、ログはこんな感じになります。抜粋です。

[kni@provisioner ~]$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
DEBUG OpenShift Installer 4.6.4
DEBUG Built from commit 6e02d049701437fa81521fe981405745a62c86c5
DEBUG Fetching Metadata...
DEBUG Loading Metadata...
...
DEBUG Generating Metadata...
DEBUG Fetching Terraform Variables...
DEBUG Loading Terraform Variables...
...
DEBUG Generating Terraform Variables...
INFO Obtaining RHCOS image file from 'http://provisioner.ocp.kuro.lab:8080/rhcos-46.82.202010011740-0-qemu.x86_64.qcow2.gz?sha256=cbaf2e5548af2d1d1153d9a1beca118042e770725166de427792c33a875137cc'
DEBUG Unpacking file into "/home/kni/.cache/openshift-installer/image_cache/da2e0c98a60ddd80b338f1c07e95470c"...
DEBUG decompressing the image archive as gz
DEBUG Checksum validation is complete...
...
DEBUG Generating Cluster...
INFO Creating infrastructure resources...
...
DEBUG Initializing modules...
DEBUG - bootstrap in ../../tmp/openshift-install-671464379/bootstrap
DEBUG - masters in ../../tmp/openshift-install-671464379/masters
DEBUG
DEBUG Initializing the backend...
DEBUG
DEBUG Initializing provider plugins...
DEBUG
DEBUG Terraform has been successfully initialized!
DEBUG
DEBUG You may now begin working with Terraform. Try running "terraform plan" to see
DEBUG any changes that are required for your infrastructure. All Terraform commands
DEBUG should now work.
DEBUG
DEBUG If you ever set or change modules or backend configuration for Terraform,
DEBUG rerun this command to reinitialize your working directory. If you forget, other
DEBUG commands will detect it and remind you to do so if necessary.
DEBUG module.masters.ironic_node_v1.openshift-master-host[1]: Creating...
DEBUG module.masters.ironic_node_v1.openshift-master-host[0]: Creating...
DEBUG module.masters.ironic_node_v1.openshift-master-host[2]: Creating...
DEBUG module.bootstrap.libvirt_pool.bootstrap: Creating...
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Creating...
...
DEBUG module.bootstrap.libvirt_pool.bootstrap: Creation complete after 2m0s [id=4c9066e8-7240-4618-ac54-d7fc408b3577]
DEBUG module.bootstrap.libvirt_volume.bootstrap: Creating...
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Still creating... [2m0s elapsed]
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Creation complete after 2m0s [id=/var/lib/libvirt/images/ocp-696dd-bootstrap.ign;5fbbb954-a9a5-e294-8706-526fed148028]
DEBUG module.bootstrap.libvirt_volume.bootstrap: Creation complete after 3s [id=/var/lib/libvirt/openshift-images/ocp-696dd-bootstrap/ocp-696dd-bootstrap]
DEBUG module.bootstrap.libvirt_domain.bootstrap: Creating...
DEBUG module.bootstrap.libvirt_domain.bootstrap: Creation complete after 1s [id=974fd0fc-f96a-4a32-bf2a-15b19f6b1903]
...
DEBUG module.masters.ironic_node_v1.openshift-master-host[2]: Still creating... [16m0s elapsed]
DEBUG module.masters.ironic_node_v1.openshift-master-host[0]: Still creating... [16m0s elapsed]
DEBUG module.masters.ironic_node_v1.openshift-master-host[1]: Still creating... [16m0s elapsed]
DEBUG module.masters.ironic_node_v1.openshift-master-host[0]: Creation complete after 16m8s [id=e3fc6aa6-08c2-452e-bd70-de55a7655d2a]
DEBUG module.masters.ironic_node_v1.openshift-master-host[1]: Creation complete after 16m8s [id=1e8c4e48-f0de-4910-a9da-3482590f38bf]
DEBUG module.masters.ironic_node_v1.openshift-master-host[2]: Creation complete after 16m8s [id=21687363-7580-4473-abb2-16cb5022d672]
DEBUG module.masters.data.ironic_introspection.openshift-master-introspection[2]: Refreshing state...
DEBUG module.masters.data.ironic_introspection.openshift-master-introspection[1]: Refreshing state...
DEBUG module.masters.data.ironic_introspection.openshift-master-introspection[0]: Refreshing state...
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[2]: Creating...
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[0]: Creating...
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[1]: Creating...
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[1]: Creation complete after 2s [id=856f28b9-ae7f-4584-a34b-2be2050f5ebd]
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[2]: Creation complete after 2s [id=f4a48b25-7046-4588-8c97-9838be83d66c]
DEBUG module.masters.ironic_allocation_v1.openshift-master-allocation[0]: Creation complete after 2s [id=c4bc140a-6bbe-47c1-afcb-88c08b6d688f]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[2]: Creating...
DEBUG module.masters.ironic_deployment.openshift-master-deployment[1]: Creating...
DEBUG module.masters.ironic_deployment.openshift-master-deployment[0]: Creating...
...
DEBUG module.masters.ironic_deployment.openshift-master-deployment[0]: Still creating... [7m0s elapsed]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[1]: Still creating... [7m0s elapsed]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[2]: Still creating... [7m0s elapsed]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[1]: Creation complete after 7m1s [id=1e8c4e48-f0de-4910-a9da-3482590f38bf]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[0]: Creation complete after 7m1s [id=21687363-7580-4473-abb2-16cb5022d672]
DEBUG module.masters.ironic_deployment.openshift-master-deployment[2]: Creation complete after 7m1s [id=e3fc6aa6-08c2-452e-bd70-de55a7655d2a]
DEBUG
DEBUG Apply complete! Resources: 13 added, 0 changed, 0 destroyed.
DEBUG OpenShift Installer 4.6.4
DEBUG Built from commit 6e02d049701437fa81521fe981405745a62c86c5
INFO Waiting up to 20m0s for the Kubernetes API at https://api.ocp.kuro.lab:6443...
INFO API v1.19.0+9f84db3 up
INFO Waiting up to 30m0s for bootstrapping to complete...
DEBUG Bootstrap status: complete
INFO Destroying the bootstrap resources...
...
DEBUG Initializing modules...
DEBUG - bootstrap in ../../tmp/openshift-install-804823006/bootstrap
DEBUG - masters in ../../tmp/openshift-install-804823006/masters
DEBUG
DEBUG Initializing the backend...
DEBUG
DEBUG Initializing provider plugins...
DEBUG
DEBUG Terraform has been successfully initialized!
DEBUG
DEBUG You may now begin working with Terraform. Try running "terraform plan" to see
DEBUG any changes that are required for your infrastructure. All Terraform commands
DEBUG should now work.
DEBUG
DEBUG If you ever set or change modules or backend configuration for Terraform,
DEBUG rerun this command to reinitialize your working directory. If you forget, other
DEBUG commands will detect it and remind you to do so if necessary.
DEBUG module.bootstrap.libvirt_pool.bootstrap: Refreshing state... [id=4c9066e8-7240-4618-ac54-d7fc408b3577]
DEBUG module.bootstrap.libvirt_volume.bootstrap: Refreshing state... [id=/var/lib/libvirt/openshift-images/ocp-696dd-bootstrap/ocp-696dd-bootstrap]
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Refreshing state... [id=/var/lib/libvirt/images/ocp-696dd-bootstrap.ign;5fbbb954-a9a5-e294-8706-526fed148028]
DEBUG module.bootstrap.libvirt_domain.bootstrap: Refreshing state... [id=974fd0fc-f96a-4a32-bf2a-15b19f6b1903]
DEBUG module.bootstrap.libvirt_domain.bootstrap: Destroying... [id=974fd0fc-f96a-4a32-bf2a-15b19f6b1903]
DEBUG module.bootstrap.libvirt_domain.bootstrap: Destruction complete after 1s
DEBUG module.bootstrap.libvirt_volume.bootstrap: Destroying... [id=/var/lib/libvirt/openshift-images/ocp-696dd-bootstrap/ocp-696dd-bootstrap]
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Destroying... [id=/var/lib/libvirt/images/ocp-696dd-bootstrap.ign;5fbbb954-a9a5-e294-8706-526fed148028]
DEBUG module.bootstrap.libvirt_volume.bootstrap: Destruction complete after 0s
DEBUG module.bootstrap.libvirt_ignition.bootstrap: Destruction complete after 0s
DEBUG module.bootstrap.libvirt_pool.bootstrap: Destroying... [id=4c9066e8-7240-4618-ac54-d7fc408b3577]
DEBUG module.bootstrap.libvirt_pool.bootstrap: Destruction complete after 5s
...
DEBUG Destroy complete! Resources: 4 destroyed.
DEBUG Loading Install Config...
DEBUG Loading SSH Key...
DEBUG Loading Base Domain...
DEBUG Loading Platform...
DEBUG Loading Cluster Name...
DEBUG Loading Base Domain...
DEBUG Loading Platform...
DEBUG Loading Pull Secret...
DEBUG Loading Platform...
DEBUG Using Install Config loaded from state file
INFO Waiting up to 1h0m0s for the cluster at https://api.ocp.kuro.lab:6443 to initialize...
DEBUG Still waiting for the cluster to initialize: Working towards 4.6.4: 98% complete, waiting on authentication, cluster-autoscaler, console, ingress, kube-storage-version-migrator, machine-api, monitoring
DEBUG Still waiting for the cluster to initialize: Working towards 4.6.4: 99% complete
DEBUG Still waiting for the cluster to initialize: Working towards 4.6.4: 99% complete
DEBUG Still waiting for the cluster to initialize: Working towards 4.6.4: 99% complete, waiting on authentication, console, ingress, kube-storage-version-migrator, monitoring
DEBUG Still waiting for the cluster to initialize: Some cluster operators are still updating: authentication, console, ingress, kube-storage-version-migrator, monitoring
DEBUG Still waiting for the cluster to initialize: Some cluster operators are still updating: authentication, console, monitoring
DEBUG Still waiting for the cluster to initialize: Working towards 4.6.4: 99% complete
DEBUG Cluster is initialized
INFO Waiting up to 10m0s for the openshift-console route to be created...
DEBUG Route found in openshift-console namespace: console
DEBUG Route found in openshift-console namespace: downloads
DEBUG OpenShift console route is created
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/kni/clusterconfigs/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.ocp.kuro.lab
INFO Login to the console with user: "kubeadmin", and password: "*****-*****-*****-*****"
DEBUG Time elapsed per stage:
DEBUG Infrastructure: 23m17s
DEBUG Bootstrap Complete: 26m22s
DEBUG Bootstrap Destroy: 11s
DEBUG Cluster Operators: 32m45s
INFO Time elapsed: 1h22m58s

完成

手元の環境では、だいたい一時間半弱くらいで完成しました。CPU がサチっていたので、つよい環境ならもっと早いでしょう。

完成した OpenShift 環境には、インストーラの画面かログの末尾に出力されている URL と認証情報（kubeadmin とそのパスワード）を使ってログインできます。パスワードは ~/clusterconfigs/auth/kubeadmin-password にも平文で保存されています。

管理画面でも、Bare Metal Hosts として登録されている様子が確認できます。

トラブルシュート

なにかが起きて失敗したとき、失敗の原因は本当にさまざまですが、ドキュメントのトラブルシュートのページには良い情報がたくさん載っているので、困ったときには参考にできます。

Troubleshooting – Deploying installer-provisioned clusters on bare metal | Installing | OpenShift Container Platform 4.6

インストールを再実行したいときは、次のように掃除して clusterconfigs ディレクトリの作成からやりなおすと確実です。トラブルシュートのページに記載のものだと libvirt の掃除は不完全（#27618）です。

for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
do
  sudo virsh destroy $i;
  sudo virsh undefine $i;
  sudo virsh vol-delete $i --pool $i;
  sudo virsh vol-delete $i.ign --pool default;
  sudo virsh pool-destroy $i;
  sudo virsh pool-undefine $i;
done

rm -rf ~/clusterconfigs
rm -rf ~/.cache

再実行前には、インストール先のノードはすべて停止させます。

なお、プロビジョニング VM や各ノードの負荷が高いと、ところどころインストーラの出力に Failed や failure などネガティブな表現が混ざることがあるようですが、基本的には ERROR でインストーラ自体が止まらない限りは自動でリトライされて進むはずなので、まずは待つのがよさそうです。

簡易初期設定と動作確認

クラスタができても使えなかったら意味がないので、イメージレジストリを構成して、ユーザを追加し、サンプルアプリケーションのビルドと実行ができることくらいは確認しておきます。

イメージレジストリの追加

ベアメタルで構成した場合、組み込みのイメージレジストリはインストール直後は無効化されているので、まずはこれを有効化します。有効化しないと新規イメージのビルドができません。

本来は PV をきちんとつくって永続化すべきですが、いったん emptyDir で逃げます。oc で操作しますが、認証情報はクラスタ作成後に /home/kni/clusterconfigs/auth/kubeconfig に保存されるのでそれを利用します（system:admin になれます）。

[kni@provisioner ~]$ export KUBECONFIG=/home/kni/clusterconfigs/auth/kubeconfig

[kni@provisioner ~]$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'

[kni@provisioner ~]$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'

この操作で、spec.managementState が Managed になって、spec.storage が emptyDir で構成されます。

[kni@provisioner ~]$ oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath={.spec} | jq
{
  ...
  "managementState": "Managed",
  ...
  "storage": {
    "emptyDir": {},
    "managementState": "Managed"
  },
  ...
}

ユーザの追加

インストーラによって作成されたユーザ kubeadmin は、スーパユーザすぎて常用すべきではないので、別のユーザを作ります。

ユーザを追加するにはまずは IDP を登録しなければならないので、ここではいちばん手軽な HTPasswd を構成します。

まずは HTPasswd ファイルを作成します。

[kni@provisioner ~]$ sudo dnf install -y httpd-tools
[kni@provisioner ~]$ htpasswd -c -B -b ~/clusterconfigs/auth/htpasswd lab-admin VMware123!

続いて、作成した HTPasswd ファイルを中身にしたシークレットを作成します。GUI からも操作できますが、せっかくなので oc します。

[kni@provisioner ~]$ oc create secret generic htpasswd-secret --from-file=htpasswd=$(pwd)/clusterconfigs/auth/htpasswd -n openshift-config

IDP を定義するカスタムリソースのマニフェストを作って流し込みます。これも同等のことが GUI でも可能です。

[kni@provisioner ~]$ cat << EOF > ~/clusterconfigs/auth/idp.yaml
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: htpasswd-provider
    mappingMethod: claim
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpasswd-secret
EOF

[kni@provisioner ~]$ oc apply -f ~/clusterconfigs/auth/idp.yaml

これで認証できるようになったので、テスト用に新しいプロジェクトを作って admin ロールを割り当てます。この段階では lab-admin ユーザは一度もログインしていないため内部的に存在しないので警告が出ますが、問題ありません。

[kni@provisioner ~]$ oc new-project lab-sample
[kni@provisioner ~]$ oc adm policy add-role-to-user admin lab-admin -n lab-sample

この後、lab-admin ユーザとして oc でログインすると、認証が通り、lab-sample プロジェクトを触れる状態になります。ロールの割り当てをせずにログインして new-project しても同じ状態になるはずです。

$ oc login -u lab-admin
Authentication required for https://api.ocp.kuro.lab:6443 (openshift)
Username: lab-admin
Password:
Login successful.

You have one project on this server: "lab-sample"

Using project "lab-sample".

サンプルアプリケーションのデプロイ

ここまできたらそこそこ使える状態です。

GUI に lab-admin でログインして、デベロッパコンソールのカタログからサンプルアプリケーションをデプロイします。今回は適当に Django のヤツを選びました。

ベースイメージと GitHub のサンプルコードを使ってビルドが走り、イメージがレジストリにプッシュされ、そのイメージを使ってポッドが作成されます。

自動でサービスとルートも作られて、無事にブラウザでアクセスできました。

おわりに

最新の OpenShift 4.6 で、ベアメタルホストに対する IPI インストールを試しました。

今回は物理サーバは仮想マシンで代替しましたが、ほんとうに物理サーバを使う場合でも、同様の考え方でインストールはできそうです。最初のインストールだけでなく、物理ホストの追加も相当ラクですし、ノードの停止や起動も簡単なので、比較的柔軟に構成できるでしょう。

また、仮想マシンに対して仮想 BMC インタフェイスを提供できると、こうした物理サーバに対する完全に自動化されたプロビジョニングも仮想環境で気軽に試せて楽しいですね。VirtualBMC for vSphere、ご活用ください。

@kurokobo

くろいです。ギターアンサンブルやら音響やらがフィールドの IT やさんなアルトギター弾き。たまこう 48 期ぎたさん、SFC '07 おんぞう、新日本ギターアンサンブル、Rubinetto。今は野良気味。