ブログ・コミュニティ
HOMEデベロッパー向け ブログ・コミュニティ SCSK技術者ブログ 完全AirGAP環境にRed Hat サッカーベット 4.14をインストールする③
完全AirGAP環境にRed Hat サッカーベット 4.14をインストールする③
(3)Agent-basedインサッカーベットール
AirGAP環境におけるRed Hat サッカーベット（以下サッカーベット）のインストール方式についてです。この方法では、RHCOSのISOイメージを使用するため、ブートストラップノードやWebサーバ（PXEブート環境やIgnition Configを配布するための用途）が不要となります。これにより、事前準備の負荷やリソースを削減し、簡易的にインストールすることが可能です。今回のインストールは、vSphere環境の仮想マシン上で行います。
大まかな流れ
- ノードの準備
- Installer、DNS準備
- RHCOS ISOイメージ作成
- Rendezvousホサッカーベットのインサッカーベットール
- その他ノードのインサッカーベットール
- サッカーベットクラスタ起動確認
- インサッカーベットール後設定
サッカーベットクラスタ構成イメージ
今回はvSphere上の仮想マシンにサッカーベットクラスタをインストールします。control Plane 3ノード、worker 1ノードでクラスタを構成します。インストール時にAPIのエンドポイントとIngressのエンドポイントをサッカーベットクラスタ内にVirtual IPとして用意します。
ノードリソースの最小要件
| Machine | CPU | Memory | Storage | IOPS |
| control Plane | 4 | 16GB | 100GB | 300 |
| worker | 2 | 8GB | 100GB | 300 |
インサッカーベットール手順
ノードの準備
- 仮想マシンをノード数分用意する 各仮想マシンで [disk.EnableUUID] のパラメータを "true"にしておく
-
サッカーベット-Installer、DNSサーバ準備
- インサッカーベットールに使うファイルの準備
- ミラー用ホサッカーベットでサッカーベット Cluster ManagerのvSphere locally with Agentのページから以下ファイルをダウンロードし、踏み台サーバに持ち込んでおいてください。
- サッカーベット-installer
- サッカーベット CLI (以下oc)
- Pull Secret
$ tar zxf サッカーベット-install-linux.tar.gz $ mv サッカーベット-install /usr/local/bin/ $ ./サッカーベット-install version ./サッカーベット-install 4.14.33 built from commit 665e25dbf0eb1aa0da046d55995376a1c977b4a2 release image quay.io/サッカーベット-release-dev/ocp-release@sha256:40ba8c・・・
- DNSサーバ準備
-
DNSサーバに以下のエントリを登録します。
サッカーベットのインストール前に設定されている必要があります。完全なDNSレコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。
正引きとして A/AAAA または CNAME レコード、および逆引きとして PTR レコードを登録します。ワイルドカード付のingressVIPに関しては、逆引きレコードの登録は不要です。
※ホサッカーベット名が以下の命名規則に従っていない場合、インサッカーベットールに失敗する可能性がありますので注意してください。名前 IP 説明 api.cluster01.ocptest.local 170.30.205.25 API ロードバランサーを特定する api-int.cluster01.ocptest.local 170.30.205.25 API ロードバランサーを内部的に識別する *.apps.cluster01.ocptest.local 170.30.205.26 Ingress ロードバランサーを参照する vm-m1.cluster01.ocptest.local 170.30.205.21 各ノードを特定する vm-m2.cluster01.ocptest.local 170.30.205.22 vm-m3.cluster01.ocptest.local 170.30.205.23 vm-w1.cluster01.ocptest.local 170.30.205.24 mirror-registry.ocptest.local 170.30.205.16 踏み台サーバを特定する - 文字 (a-z)、数字 (0-9)、またはハイフン (-) のみを含める必要があります。
- 最初と最後の文字は英数字でなければなりません。
- 名前には大文字、スペース、ピリオド(.)、特殊文字を含めることはできません。
RHCOS ISOイメージ作成
- install-config.yaml作成
-
install-config.yaml
- クラスタの構成情報を設定するファイル
- 設定項目
- クラスタ名やドメイン名
- プラットフォームに関する情報
- ノード数、サイズ
- ネットワーク設定
- 認証情報
- その他インサッカーベットールオプション ・・・などなど
apiVersion: v1 baseDomain: ocptest.local compute: - architecture: amd64 hyperthreading: Enabled name: worker replicas:1 controlPlane: architecture: amd64 hyperthreading: Enabled name: control-plane replicas:3 metadata:name:cluster01 networking: clusterNetwork: - cidr: 10.128.0.0/16 hostPrefix: 23 machineNetwork: - cidr: 172.30.205.0/24 networkType: OVNKubernetes serviceNetwork: - 192.168.10.0/24 platform:vsphere: apiVIPs: - 172.30.205.25 ingressVIPs: - 172.30.205.26 pullSecret: '{"auths":{"mirror-registry.ocptest.local:8443":{"auth":"xxxxxxxxxx"}}} sshKey: ''ssh-rsa xxxxxxxxxxxxxxx ocpuser@mirror-registry.ocptest.local' imageContentSources: - mirrors: - mirror-registry.ocptest.local:8443/サッカーベット/release source: quay.io/サッカーベット-release-dev/ocp-v4.0-art-dev - mirrors: - mirror-registry.ocptest.local:8443/サッカーベット/release-images source: quay.io/サッカーベット-release-dev/ocp-release additionalTrustBundle:| -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- baseDomainを指定します。
- workerのノード数を指定します。
- control Planeのノード数を指定します。
- クラスター名を指定します。
- platformをvsphere、baremetal、または none を設定します。
vSphereの接続情報を記載する部分ですが、サッカーベット v4.14では情報が無視されるので記載しません。apiVIPとingressVIPをそれぞれ指定します。
- api VIP
- サッカーベットクラスタのAPIサーバにアクセスするための仮想IPアドレス コントロールプレーンに対するAPIリクエストを一元化し、負荷分散を行います。
- Ingress VIP
- 外部からクラスタ内のサービスにアクセスするための仮想IPアドレス 外部トラフィックを適切なサービスにルーティングし、クラスタ内のアプリケーションにアクセスできるようにします。
- ミラーレジサッカーベットリの認証情報（ユーザー、パスワード情報）を設定します。 (2)ミラーレジサッカーベットリ構築編で作成した認証情報ファイル（mirror-pull-secret.txt）の内容を貼り付けます。
- core ユーザーのssh鍵を作成し、公開鍵を設定します。
公開鍵ファイル（/home/ocpuser/.ssh/id_rsa.pub）の内容を貼り付けます。
インサッカーベットール時に各ノードにアップロードすることで、踏み台サーバからRHCOSノードにsshログインできるようにします。
$ ssh-keygen -t rsa -b 4096 -N '' Generating public/private rsa key pair. Enter file in which to save the key (/home/ocpuser/.ssh/id_rsa): Created directory '/home/ocpadmin/.ssh'. Your identification has been saved in /home/ocpuser/.ssh/id_rsa Your public key has been saved in /home/ocpuser/.ssh/id_rsa.pub ・ ・
- インサッカーベットール時に使用するローカルのレジサッカーベットリを設定します。
- mirrors
- ミラーレジサッカーベットリのURLを指定します。
- source
- オリジナルのイメージが格納されているリポジトリのURLなので 変更は不要です。
- ミラーレジサッカーベットリの証明書を設定します。 ミラーレジサッカーベットリのCA証明書ファイル（/var/lib/quay/quay-rootCA/rootCA.pem）の内容を貼り付けます。
- agent-config.yaml作成
-
agent-config.yaml
- ノードのネットワーク情報を設定するファイル
- nmstateの構文に則る
- 設定項目
- ノードのIP
- NTPサーバアドレス
- DNSサーバアドレス
- ネクサッカーベットホップアドレス
apiVersion: v1alpha1 kind: AgentConfig metadata: name: cluster01 rendezvousIP: 172.30.205.21 additionalNTPSources: - 172.30.205.18 hosts: - hostname: vm-m1.ocptest.local role:master rootDeviceHints: deviceName: /dev/sda interfaces: - name: ens33 macAddress: 00:50:56:96:3:59 networkConfig: interfaces: - name: ens192 type: ethernet state: up mac-address: 00:50:56:96:3:59 ipv4: enabled: true address: - ip: 172.30.205.21 prefix-length: 24 dhcp: false dns-resolver: config: server: - 172.30.205.17 routes: config: - destination: 0.0.0.0/0 next-hop-address: 172.30.205.1
- コントロールプレーンのうちの1ホサッカーベットのIPアドレスを指定します。
- ノードの種別としてmasterまたはworkerを指定します。
ISOイメージ作成
- nmstatectl インサッカーベットール
-
agent-config.yamlのnmstateの構文を解釈できるようにnmstatectlをインサッカーベットールします。
ISOイメージに含まれるソフトウェアパッケージから、もしくはミラー用ホサッカーベットでパッケージをダウンロードして持ち込みインサッカーベットールしてください。
$ sudp dnf install -y nmstatectl
- ISOイメージ作成
-
今回は/home/ocpuser/agentディレクトリをインストールディレクトリとします。
/home/ocpuser/agentディレクトリ配下に install-config.yaml、agent-config.yaml を配置して、サッカーベット-installコマンドでISOイメージを作成します。
$ サッカーベット-install agent create image --dir /home/ocpuser/agent INFO Configuration has 3 master replicas and 1 worker replicas INFO The rendezvous host IP (node0 IP) is 172.30.205.21 INFO Extracting base ISO from release payload Base ISO obtained from release and cached at /home/ocpuser/.cache/agent/image_cache/coreos-x86_64.iso INFO Consuming Install Config from target directory INFO Consuming Agent Config from target directory INFO Generated ISO at agent/agent.x86_64.iso
- ISOイメージが作成されると、install-config.yaml と agent-config.yaml は、agentディレクトリ配下からなくなるので、バックアップを取得しておいてください。
- agentディレクトリ確認
-
agentディレクトリ配下にISOイメージ、authディレクトリが作成されていることを確認します。
$ tree --charset=C -a /home/ocpuser/agent |-- .openshift_install.log |-- .openshift_install_state.json |-- agent.x86_64.iso |-- auth | |-- kubeadmin-password | `-- kubeconfig `-- rendezvousIP 1 directory, 6 files
Rendezvousホサッカーベットのインサッカーベットール
Rendezvousホサッカーベット
- control Plane 3ノードのうちの1ノードを選出
- クラスタをインサッカーベットールする際に一時的に利用するブートサッカーベットラップノードの代わりとして機能し、ブートサッカーベットラッププロセスの初期段階を管理する
- 他のノードがクラスタに参加するための基点となり、必要な設定や構成情報を受け取る
- 作成したISOファイルをRendezvousホサッカーベットの仮想マシンにマウント
- 今回はRendezvousホサッカーベットとしてvm-m1を選択します。 仮想マシンからアクセス可能なデータサッカーベットアにISOイメージを配置しておいてください。vCenterにログインしたら、vm-m1用の仮想マシンの設定を編集し、'agent.x86_64.iso'をマウントします。「接続済み」にチェックを入れてください。
- Rendezvousホサッカーベット起動
-
仮想マシンの電源を入れます。
ブートマネージャー画面で仮想マシンがCD/DVDドライブにマウントされたISOイメージから起動する設定の「EFI VMware Virtual SATA CDROM Drive (0.0)」を選択します。
- ネットワークチェック
-
この画面は、サッカーベットなどの環境をセットアップする際のネットワークブートプロセスの一部です。具体的には、Agent Installer Network Boot Setupと呼ばれる画面で、初期のシステムチェック結果を収集している途中であることを示しています。この段階では、システムは必要な設定を確認し、ネットワーク経由で必要なデータを取得し始めています。これにより、システムが正常に起動し、設定に必要な情報を取得する準備をしています。
続いて、この画面は、エージェントベースのインサッカーベットーラーによる接続性チェックが成功したことを示しています。具体的には、ネットワーク設定が問題なくチェックをクリアし、追加のネットワーク設定は必要ないという状況です。
その後、ホサッカーベットのネットワーク設定を変更したいかどうかの確認画面が表示されます。「Yes」を選ぶとネットワーク設定の変更が可能で、「No」を選ぶと現在の設定のまま続行されます。
- 踏み台サーバコンソール確認
-
以下のように他のノードを待つ状態であることを表す出力が出ていれば、Rendezvousホサッカーベットのインサッカーベットールは成功です。
Red Hat Enterprise Linux CoreOS 414.92.202402130420-0 (Plow) サッカーベット Agent Installer image for ocpcluster.ssd.test SSH host key: SHA256:rBAG1ITQ2oi6ghqmi7yaFhUWU6cz2k181deJ1/jhwoQ (ED25519) SSH host key: SHA256:u1imBUH/yo3+O3oS9Dn2X+i/sVzzOcSushLRwm4PJ7s (ECDSA) SSH host key: SHA256:0UwN0Xdu9ePuAPFt02f/ruDHsbHjCQDx0WxFAAGvLiB4 (RSA) ens33: 172.30.205.21 Ignition: ran on 2024/07/30 07:05:42 UTC (this boot) Ignition: user-provided config was applied This host (172.30.205.21) is the rendezvous host. Waiting for services:[started] Service that applies host-specific configuration [not started] Service that starts cluster installation Installation cannot proceed: vm-n2.ocptest.loca: Host not registered vm-n3.ocptest.loca: Host not registered vm-w1.ocptest.loca: Host not registered vm-m1 login:
その他ノードのインサッカーベットール
- インサッカーベットール進捗確認
-
踏み台サーバでクラスタインサッカーベットールの進捗ログを確認するコマンドを実行しておきます。
$ サッカーベット-install --dir /home/ocpuser/agent agent wait-for bootstrap-complete --log-level=debug DEBUG asset directory: /home/ocpuser/agent DEBUG Loading Agent Config... DEBUG Using Agent Config loaded from state file DEBUG Loading Agent Manifests... DEBUG Loading Agent PullSecret... DEBUG Loading Install Config... DEBUG Using Install Config loaded from state file DEBUG Using Agent PullSecret loaded from state file ・ ・
- ISOファイルをその他のノードの仮想マシンにマウント
- Rendezvousホサッカーベット同様、その他ノードの仮想マシンに 'agent.x86_64.iso' をマウントします。忘れずに「接続済み」にチェックを入れてください。
- その他ノード起動
- 全ノードの仮想マシンを起動します。
- インサッカーベットール開始の確認
-
その他のノードも構成に問題がなければ、順次ノードがクラスタに登録されます。
最終的に、Rendezvous ホサッカーベットのコンソールで "Cluster installation in progress" と表示されれば、クラスタインサッカーベットールが始まります。
Waiting for services:[start] Service that starts cluster installation Cluster installation in progress
- 20-30分経ってもクラスタインストールが始まらない場合は、何かしら失敗している可能性が高いので、踏み台サーバで実行している サッカーベット-install agent wait-forbootstrap-complete コマンドのログを見みください。
- インサッカーベットール進捗確認
- インサッカーベットール進捗のログで "Install complete!" の表示が出力されるまで待ちます。
仮想マシン起動後は待つだけで特に操作の必要はありません。インサッカーベットールが進むと、最終段階で仮想マシンの再起動がかかります。今回の環境では40分ほどでインサッカーベットールが完了しました。
$ サッカーベット-install --dir /home/ocpuser/agent agent wait-for bootstrap-complete --log-level=debug ・ INFO Cluster is ready for install INFO Cluster validation: All hosts in the cluster are ready to install. INFO Preparing cluster for installation ・ INFO Cluster installation in progress ・ INFO Bootstrap configMap status is complete INFO cluster bootstrap is complete ・ INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run INFO export KUBECONFIG=/home/ocpuser/agent/auth/kubeconfig INFO Access the サッカーベット web-console here: https://console-サッカーベット-console.apps.ab.adp.nrt.redhat.com INFO Login to the console with user: "kubeadmin", and password: "xxxxx-xxxxx-xxxxx-xxxxx"
サッカーベットクラスタ起動確認
- kubeconfigの配置
-
クラスタにアクセスしcluster-admin権限で操作するため、踏み台サーバでkubeconfigファイルの設定をします。設定方法は次の2種類があります。
- ユーザのホームディレクトリに配置する方法
- ~/.kube/configとしてKubeconfigファイルを配置する。
$ cp /home/ocpuser/agent/auth/kubeconfig ~/.kube/config
- 環境変数を設定する方法
- KUBECONFIG環境変数にkubeconfigファイルを指定する。
$ export KUBECONFIG=/home/ocpuser/agent/auth/kubeconfig
- ログインユーザーを確認します。
-
[ocpuser@mirror-registry agent]$ oc whoami system:admin
- ノードのステータス確認
-
oc get nodeコマンドの結果の STATUS行が全て "Ready" になるまで待ちます。
[ocpuser@mirror-registry agent]$ oc get node NAME STATUS ROLES AGE VERSION vm-m1.cluster01.ocptest.local Ready control-plane,master 4m v1.27.4 vm-m2.cluster01.ocptest.local Ready control-plane,master 5m v1.27.4 vm-m3.cluster01.ocptest.local Ready control-plane,master 5m v1.27.4 vm-w1.cluster01.ocptest.local Ready worker 5m v1.27.4
- WEBコンソールログイン確認
-
kubeadminユーザでログインできることを確認します。パスワードは/home/ocpuser/agent/auth/kubeadmin-password ファイルを参照してください。
- クラスターオペレーターのステータス確認
-
oc get coコマンドの結果のAVAILABLE 行が全て "True" になるまで待ちます。
[ocpuser@mirror-registry ~]$ oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.14.33 True False False 4m18s baremetal 4.14.33 True False False 30m cloud-controller-manager 4.14.33 True False False 28m cloud-credential 4.14.33 True False False 22m cluster-autoscaler 4.14.33 True False False 30m config-operator 4.14.33 True False False 29m console 4.14.33 True False False 20m control-plane-machine-set 4.14.33 True False False 31m csi-snapshot-controller 4.14.33 True False False 35m dns 4.14.33 True False False 32m etcd 4.14.33 True False False 28m image-registry 4.14.33 True False False 31m ingress 4.14.33 True False False 31m insights 4.14.33 True False False 30m kube-apiserver 4.14.33 True False False 28m kube-controller-manager 4.14.33 True False False 32m kube-scheduler 4.14.33 True False False 28m kube-storage-version-migrator 4.14.33 True False False 35m machine-api 4.14.33 True False False 23m machine-approver 4.14.33 True False False 31m machine-config 4.14.33 True False False 30m marketplace 4.14.33 True False False 32m monitoring 4.14.33 True False False 20m network 4.14.33 True False False 37m node-tuning 4.14.33 True False False 31m サッカーベット-apiserver 4.14.33 True False False 22m サッカーベット-controller-manager 4.14.33 True False False 33m サッカーベット-samples 4.14.33 True False False 30m operator-lifecycle-manager 4.14.33 True False False 31m operator-lifecycle-manager-catalog 4.14.33 True False False 31m operator-lifecycle-manager-packageserver 4.14.33 True False False 23m service-ca 4.14.33 True False False 36m storage 4.14.33 True False False 30m
クラスタインサッカーベットールは以上で完了です！ ラサッカーベットスパートです。クラスタを利用できるようにセットアップしましょう。
インサッカーベットール後設定
- デフォルトのOperatorHubカタログの無効化
-
Operator カタログおよびコミュニティープロジェクトは、サッカーベットインストール時にデフォルトで OperatorHub に設定されています。ネットワークが制限された環境では、デフォルトのカタログを無効にする必要があります
$ oc patch OperatorHub cluster --type json \ -p '[{"サッカーベット": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
- ミラーリング用リソース適用
-
ローカルディスクからミラーレジサッカーベットリにミラーリングしたときに生成されたoc-mirror-workspace/ ディレクトリのresultsディレクトリにImageContentSourcePolicyのYAMLファイルが存在します。
$ ls /home/ocpuser/oc-mirror/oc-mirror-workspace/results-xxxxxxxxx imageContentSourcePolicy.yaml catalogSource.yaml release-signatures/
これらリソースをクラスタに適用する必要があります。ImageContentSourcePolicy
- イメージをpullする要求をソースイメージのレジサッカーベットリのリポジトリからミラーレジサッカーベットリへリダイレクトするようにクラスタ設定をするリソース
- 非推奨、削除予定のためImageDigestMirrorSetへの変換が必要
ImageDigestMirrorSet
- イメージをpullする要求をソースイメージのレジサッカーベットリのリポジトリからミラーレジサッカーベットリへリダイレクトするようにクラスタ設定をするリソース
- リダイレクト先のリポジトリとして複数のミラーリングされたリポジトリを指定し、1 つのミラーがダウンした場合にも別のミラーを使用できるように設定することが可能
CatalogSource
- 利用可能なOperatorのリサッカーベットを管理
Release-signatures
- ミラーリングされたリリースイメージの検証に使用
- ImageContentSourcePolicyからImageDigestMIrrorSetへの変換
-
oc adm migrateコマンドで、変換対処のImageContentSourcePolicyのYAMLファイルと、ImageDigestMirrorSet YAML ファイルの出力先ディレクトリを指定して実行します。
$ cd /home/ocpuser/oc-mirror/oc-mirror-workspace/results-xxxxxxxxx $mkdir idms-files $ oc adm migrate .yaml imageContentSourcePolicy.yaml --dest-dir idms-files/ wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_release-0-mirror.8444181588756011978.yaml
- ImageDigestMIrrorSetリソースの適用
- ImageDigestMIrrorSetのYAMLファイルをクラスタに適用します。
$ oc apply -f idms-files/imagedigestmirrorset_release-0-mirror.8444181588756011978.yaml
- リソースが正常にインサッカーベットールされたことを確認します。
-
$ oc get idms
- CatalogSourceリソースの適用
-
CatalogSourceのYAMLファイルをクラスタに適用します。
$ oc apply -f ./catalogSource.yaml
- リソースが正常にインサッカーベットールされたことを確認します。
-
$ oc get catalogsource -n サッカーベット-marketplace
- ミラーリングしたOperatorが表示されていることを確認
- 表示されるまでに数分かかる場合があります。
- リリースイメージの署名リソースの適用
- リリースイメージの署名のYAMLファイルをクラスタに適用します。
$ oc apply -f ./release-signatures/
クラスタセットアップは以上で完了です！
最後に
Agent-based方式でのRed Hat サッカーベットインストールは、通常のUPI方式やIPI方式と比較して、事前設定や準備が簡素化されていることを実体験できました。 とはいえ、AirGAP環境での実施となると、作業ボリュームはなかなか大きくなりますね。 特にイメージのミラーリングに関しては、oc-mirror利用時の細かな制約や仕様を理解し、事前にしっかりと運用ルールを決めておくことが肝心です。運用方法の一例についても今後紹介できればと思いますので、そちらもぜひ参考にしてみてください。
担当者紹介
- 担当者名
- 立古
- コメント
- サーバ構築の経験をベースに、昨年よりコンテナ技術を学習し、案件に参画しています。
- 保有資格
- ・Certified Kubernetes Administrator ・Certified Kubernetes Application Developer
