【OKD 5.0】 オンライン環境:Agent-based Installer+platform: baremetal で 3 ノード クラスタを作る手順

Agent-based Installer で、3 台のノード(コントロール プレーンと仮想マシンの実行を兼ねる構成)の OKD 5.0 クラスタを作る手順です。platform: baremetal を使い、API と Ingress の仮想 IP(VIP)はクラスタ自身が持つため、外部のロード バランサーは使いません。ノードはインターネットに出られる(オンライン)前提です。

目次

この記事の前提

Agent-based Installer の流れ

  1. 踏み台で、クラスタの設定(install-config.yaml)とノードの設定(agent-config.yaml)を書く
  2. openshift-install agent create image で、設定を埋め込んだ起動用の ISO を作る
  3. 3 台のノードをその ISO で起動する。agent-config.yaml の rendezvousIP のノード(ランデブー ホスト)が、一時的にインストールの司令塔(ブートストラップ)になる
  4. ほかの 2 台がディスクに OS を書き込んでクラスタを作り、最後にランデブー ホストも書き込んで参加する
  5. 踏み台で openshift-install agent wait-for を使い、完了を待つ

BMC(iLO などの遠隔管理)や PXE サーバー、外部のロード バランサーは要りません。

構成

項目値
OKD5.0.0-okd-scos.3(Kubernetes 1.36、CentOS Stream CoreOS 10)
クラスタ名・ベース ドメインokdbm・hvdoc.lab
ノードmaster-1〜3(192.168.1.191〜193)。各 8 vCPU・24 GB・ディスク 120 GB(OS)+100 GB
NICens18:LAN(管理・API・仮想マシン)/ens19・ens20:iSCSI の 2 系統(10.40.81.x・10.40.82.x)
API VIP / Ingress VIP192.168.1.194 / 192.168.1.195

コントロール プレーンのノードは、要件として 4 vCPU・16 GB 以上が必要です。仮想マシンも動かすため、ここでは 24 GB にしています。

install-config.yaml

実行する場所:踏み台サーバー(root)

# mkdir -p /root/okd/okdbm && cd /root/okd/okdbm
# cat > install-config.yaml <<EOF
apiVersion: v1
baseDomain: hvdoc.lab
metadata:
  name: okdbm
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:
  baremetal:
    apiVIPs:
    - 192.168.1.194
    ingressVIPs:
    - 192.168.1.195
pullSecret: '{"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}'
sshKey: '$(cat /root/.ssh/id_ed25519.pub)'
EOF
項目説明設定値
compute.replicasワーカー専用ノードの台数。0 にすると、コントロール プレーンのノードがアプリケーション(仮想マシン)も動かす0
controlPlane.replicasコントロール プレーンのノードの台数3
machineNetworkノードの IP アドレスの範囲192.168.1.0/24
clusterNetwork / serviceNetworkPod と Service の内部ネットワーク。ノードのネットワークと重ならない範囲にする既定値
platform.baremetal.apiVIPs / ingressVIPsクラスタが keepalived で持つ API と Ingress の VIP。machineNetwork の中の未使用の IP アドレス192.168.1.194 / 192.168.1.195
pullSecretOKD はイメージの取得に認証が要らないため、ダミーの値でよい(上記のとおり)
sshKeyノードの core ユーザーに登録する公開鍵踏み台の鍵

agent-config.yaml

ノードごとに、ホスト名、NIC(MAC アドレス)、固定 IP、インストール先のディスクを書きます。ネットワークの設定は nmstate の形式です。

# cat > agent-config.yaml <<'EOF'
apiVersion: v1beta1
kind: AgentConfig
metadata:
  name: okdbm
rendezvousIP: 192.168.1.191
hosts:
  - hostname: master-1
    role: master
    rootDeviceHints:
      deviceName: /dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0
    interfaces:
    - name: ens18
      macAddress: BC:24:11:0D:01:11
    - name: ens19
      macAddress: BC:24:11:0D:02:11
    - name: ens20
      macAddress: BC:24:11:0D:03:11
    networkConfig:
      interfaces:
      - name: ens18
        type: ethernet
        state: up
        identifier: mac-address
        mac-address: BC:24:11:0D:01:11
        ipv4:
          enabled: true
          dhcp: false
          address:
          - ip: 192.168.1.191
            prefix-length: 24
        ipv6:
          enabled: false
      - name: ens19
        type: ethernet
        state: up
        identifier: mac-address
        mac-address: BC:24:11:0D:02:11
        ipv4:
          enabled: true
          dhcp: false
          address:
          - ip: 10.40.81.11
            prefix-length: 24
        ipv6:
          enabled: false
      - name: ens20
        type: ethernet
        state: up
        identifier: mac-address
        mac-address: BC:24:11:0D:03:11
        ipv4:
          enabled: true
          dhcp: false
          address:
          - ip: 10.40.82.11
            prefix-length: 24
        ipv6:
          enabled: false
      dns-resolver:
        config:
          server:
          - 192.168.1.190
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.1.1
          next-hop-interface: ens18
  # master-2・master-3 も同じ形で、MAC アドレス(…:12・…:13)と IP アドレス(.192・.193、10.40.81.12・.13、10.40.82.12・.13)を変えて続けて書く
EOF
項目説明
rendezvousIPインストールの司令塔になるノードの IP アドレス(最初のノード)
rootDeviceHints.deviceNameOS を書き込むディスク。/dev/sda ではなく /dev/disk/by-path/… で指定する(下の注意を参照)
interfacesノードの NIC と MAC アドレス。この MAC アドレスでノードを見分ける
networkConfignmstate 形式のネットワーク設定。identifier: mac-address で、NIC の名前ではなく MAC アドレスで設定先を決める
dns-resolver / routesDNS サーバー(踏み台)とデフォルト ゲートウェイ

インストール先のディスクは by-path で指定します。 この検証では最初 deviceName: /dev/sda にしたところ、3 台のうち 1 台だけ、2 本目のディスク(100 GB)が /dev/sda になり、そちらに OS が書き込まれました。起動順は 1 本目のディスクが先のため、そのノードは ISO から起動し直してしまい、ランデブー ホストのコンソールに「Installation cannot proceed: Cluster status: installing-pending-user-action」と表示されて止まりました。/dev/sdX の順番は起動ごとに入れ替わることがあるため、by-path(接続先の位置)や WWN、シリアル番号で指定します。

ISO の作成

# openshift-install agent create image --dir /root/okd/okdbm

期待する出力(抜粋):

level=info msg=Configuration has 3 master replicas, 0 arbiter replicas, and 0 worker replicas
level=info msg=The rendezvous host IP (node0 IP) is 192.168.1.191
level=info msg=Extracting base ISO from release payload
level=warning msg=Failed to extract base ISO from release payload - check registry configuration
level=info msg=Downloading base ISO
level=info msg=Generated ISO at agent.x86_64.iso.

「Failed to extract base ISO from release payload」の警告は、ダミーのプル シークレットのためです。続けて基になる ISO をダウンロードして作るので、問題ありません。作業ディレクトリーの install-config.yaml と agent-config.yaml は ISO の作成で消費(削除)されるため、必要なら先に別の場所へコピーしておきます。

ノードの起動

作った agent.x86_64.iso を 3 台のノードに入れ(仮想マシンなら CD-ROM に設定)、起動順を「1 本目のディスク → CD-ROM」にして起動します。ディスクが空の最初の起動は CD-ROM から、OS の書き込み後はディスクから起動します。

(1) 各ノードは起動すると接続確認(レジストリーへの到達など)を行います。問題がなければ「Agent-based installer connectivity checks passed」と表示され、数秒で自動的に先へ進みます(ネットワークを直すときだけ Yes を選びます)。

接続確認

(2) ランデブー ホスト(master-1)のコンソールに「Cluster installation in progress」と表示され、インストールが進みます。ほかの 2 台はディスクへの書き込みと再起動を行い、ランデブー ホストは最後に書き込んで再起動します。

インストール中

完了待ち

実行する場所:踏み台サーバー(root)。踏み台自身が自分の DNS で API の名前を引けることが必要です(踏み台の記事)。

# cd /root/okd/okdbm
# openshift-install agent wait-for bootstrap-complete --dir .
# openshift-install agent wait-for install-complete --dir .

期待する出力(抜粋):

level=info msg=Bootstrap is complete
level=info msg=cluster bootstrap is complete
level=info msg=All cluster operators have completed progressing
level=info msg=Install complete!
level=info msg=    export KUBECONFIG=/root/okd/okdbm/auth/kubeconfig
level=info msg=Access the OpenShift web-console here: https://console-openshift-console.apps.okdbm.hvdoc.lab
level=info msg=Login to the console with user: "kubeadmin", and password: "xxxxx-xxxxx-xxxxx-xxxxx"

この環境では、ノードの起動から完了まで約 1 時間でした。

確認

# export KUBECONFIG=/root/okd/okdbm/auth/kubeconfig
# oc get nodes
# oc get clusterversion
# oc get co

期待する出力(抜粋):

NAME       STATUS   ROLES                         AGE   VERSION
master-1   Ready    control-plane,master,worker   13m   v1.36.3
master-2   Ready    control-plane,master,worker   37m   v1.36.3
master-3   Ready    control-plane,master,worker   27m   v1.36.3
NAME      VERSION            AVAILABLE   PROGRESSING   SINCE   STATUS
version   5.0.0-okd-scos.3   True        False         10m     Cluster version is 5.0.0-okd-scos.3

oc get co では、すべての ClusterOperator が AVAILABLE=True、PROGRESSING=False、DEGRADED=False になっていることを確認します(この版では 34 個)。

Web コンソールへのログイン

(1) ブラウザーで https://console-openshift-console.apps.okdbm.hvdoc.lab を開きます(ブラウザーの PC も、hvdoc.lab を踏み台の DNS で引ける必要があります)。証明書の警告は、console と oauth-openshift の 2 回表示されます。ユーザー名 kubeadmin と、完了待ちで表示されたパスワード(/root/okd/okdbm/auth/kubeadmin-password)でログインします。

ログイン

(2) [Overview] が表示されます。kubeadmin は一時的な管理者のため、運用では ID プロバイダー(HTPasswd や LDAP など)を設定してユーザーを作ります。

Overview

(3) [Compute] → [Nodes] で、3 台が Ready になっていることを確認します。

ノード

platform: baremetal と none の違い

項目baremetalnone
API・Ingress の VIPクラスタが keepalived で持つ(install-config に apiVIPs・ingressVIPs を書く)持たない。外部のロード バランサー(HAProxy など)を用意し、DNS の api・*.apps をロード バランサーに向ける
外部のロード バランサー不要必要(API 6443・Machine Config Server 22623・Ingress 80/443)
ノードの増減BMC があれば、クラスタから電源・プロビジョニングを管理できる(Metal3)クラスタは基盤を管理しない(手動で ISO を作って起動する)
向いている場面専用の LB を用意しない、小さな構成やエッジ既存の LB を使いたい、VIP 用の L2 のネットワークを用意できない

platform: none の手順は次の記事です。

次の手順

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次