Agent-based Installer の platform: none でクラスタを作る手順です。platform: none ではクラスタが API と Ingress の仮想 IP（VIP）を持たないため、外部のロード バランサー（ここでは踏み台の HAProxy）と DNS を自分で用意します。手順の大部分は platform: baremetal の記事と同じなので、違うところを中心に書きます。
この記事の前提
- 踏み台サーバーの構築が終わっていること（DNS の okdnone のレコード、HAProxy）
- 参照: OKD Documentation（Installing an on-premise cluster with the Agent-based Installer）
platform: baremetal と none の違い
| 項目 | platform: baremetal | platform: none |
|---|---|---|
| API の入口 | クラスタが keepalived で持つ VIP（install-config の apiVIPs） | 外部のロード バランサー（API 6443・Machine Config Server 22623） |
| Ingress（*.apps）の入口 | クラスタが持つ VIP（ingressVIPs） | 外部のロード バランサー（80・443） |
| DNS の api・api-int・*.apps | VIP の IP アドレス | ロード バランサーの IP アドレス |
| VIP 用の条件 | ノードと同じ L2 のネットワークに、未使用の IP アドレスが 2 つ | 不要 |
| クラスタ内の部品 | keepalived・haproxy・coredns（静的 Pod）がノードで動く | 動かない（その分シンプル） |
| ノードの管理 | BMC があれば電源・プロビジョニングを管理できる（Metal3、baremetal オペレーター） | クラスタは基盤を管理しない |
| ロード バランサーの冗長化 | クラスタ内で完結（VIP がノード間を移る） | ロード バランサー自体を冗長化する必要がある（2 台＋keepalived など） |
| 向いている場面 | 専用のロード バランサーを用意しない、小さな構成・エッジ | 既存のロード バランサーを使う、VIP 用の L2 を用意できない、ノードが複数のサブネットにまたがる |
この連載では、踏み台の HAProxy は 1 台です。本番では、ロード バランサーが止まると API と Ingress が使えなくなるため、2 台にして keepalived などで冗長化するか、既存の冗長化されたロード バランサーを使います。
構成
| 項目 | 値 |
|---|---|
| クラスタ名 | okdnone |
| ノード | master-1〜3（192.168.1.191〜193）。baremetal の記事と同じ仮想マシン・NIC・ディスク |
| API ／ Ingress | 踏み台の HAProxy（192.168.1.190）。DNS の api・api-int・*.apps.okdnone.hvdoc.lab は 192.168.1.190 |
install-config.yaml の違い
platform の部分だけが違います。apiVIPs・ingressVIPs は書きません。
実行する場所：踏み台サーバー（root）
# mkdir -p /root/okd/okdnone && cd /root/okd/okdnone
# cat > install-config.yaml <<EOF
apiVersion: v1
baseDomain: hvdoc.lab
metadata:
name: okdnone
compute:
- name: worker
replicas: 0
controlPlane:
name: master
replicas: 3
networking:
networkType: OVNKubernetes
machineNetwork:
- cidr: 192.168.1.0/24
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
pullSecret: '{"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}'
sshKey: '$(cat /root/.ssh/id_ed25519.pub)'
EOFagent-config.yaml は baremetal の記事と同じです（metadata.name だけ okdnone にします）。ISO の作成、ノードの起動、完了待ちも同じ手順です。
# openshift-install agent create image --dir /root/okd/okdnone
# openshift-install agent wait-for bootstrap-complete --dir /root/okd/okdnone
# openshift-install agent wait-for install-complete --dir /root/okd/okdnoneplatform: none でも、rendezvousIP のノードは最初のコントロール プレーンとして動きます。インストール中、API は HAProxy 経由でランデブー ホストに届きます（HAProxy の api の振り分け先は、最初は master-1 だけが UP）。
ロード バランサーの状態の確認
HAProxy の統計ページ（http://192.168.1.190:9000/stats）で、振り分け先の状態を確認します。
(1) インストールが終わると、api と machine-config の振り分け先が 3 台とも UP（緑）になります。
(2) Ingress（80・443）は、router の Pod（既定で 2 つ）が動いているノードだけが UP になります。動いていないノード（ここでは master-1）は DOWN（赤）ですが、正常です。
| バックエンド | 振り分け先が UP になる条件 |
|---|---|
| api（6443） | そのノードの kube-apiserver が /readyz に 200 を返す |
| machine-config（22623） | そのノードの Machine Config Server が動いている |
| ingress-http ／ ingress-https | そのノードで router の Pod が動いている（3 台構成では 3 台中 2 台） |
確認
# export KUBECONFIG=/root/okd/okdnone/auth/kubeconfig
# oc get nodes
# oc get clusterversion
# oc get infrastructure cluster -o jsonpath='{.status.platformStatus.type}{"\n"}'期待する出力（抜粋）：
NAME STATUS ROLES AGE VERSION
master-1 Ready control-plane,master,worker 6m20s v1.36.3
master-2 Ready control-plane,master,worker 25m v1.36.3
master-3 Ready control-plane,master,worker 24m v1.36.3
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 5.0.0-okd-scos.3 True False 7m27s Cluster version is 5.0.0-okd-scos.3
NoneWeb コンソール（https://console-openshift-console.apps.okdnone.hvdoc.lab）にも、HAProxy 経由で同じようにログインできます。
