はじめに
はやいもので、2023年もあと1ヶ月。恒例のアドベントカレンダーの季節がやってきました！
今回は、セルフマネージド（マネージドサービスの対義語として）OpenShiftの環境構築において、もっとも汎用性の高いインストール方法である Anyplatform Install の実際の流れを最新リリースのOCP4.14を対象として追いかけてみたいと思います。
OpenShiftの環境構築に興味がある方は、詳しくは製品ドキュメントを見ていただきたいのですが、OpenShiftのインストールには、大きく、フルオートメーション、セミオートメーション、手動に大別することができます。
インストール方法の概要
| 名前 | 特徴 | 注意点など |
|---|---|---|
| IPI | インストーラプログラムによってクラウド環境のマシン払出も含めて全自動で構築される | インストーラーがパブリッククラウドや仮想化基盤といったプラットフォームに対応済である必要がある。 プラットフォームに対して比較的強い権限が必要 |
| UPI | サーバの払出や、ネットワーク構築はユーザが手動で行い、インストール作業はインストーラが行う（＝セミオートメーション）。 IPIより柔軟な構成をとることが可能。 |
注意点は、IPIと同じ |
| Anyplatform | 必要なインフラリソースを全てユーザーが手動で用意する。 インストールプロセスにも度々、手動の操作が必要。IPI/UPIのように導入先となるプラットフォームの制限は無いため、最も汎用性が高い。 必要な権限が利用できないオンプレ仮想環境や、ベアメタルマシンへ導入する場合は、ほぼこのパターンとなる。 |
最も汎用性が高い方法ではあるものの、導入できないケースはある。（eg.導入先のマシンスペックが弱い...etc) マシンに対するOSインストールや電源ON/OFFといった操作は必要。 |
個人的には、インストレーションについては、ドキュメントの情報が充実しているため、詳しくはやはりそちらを参照してもらうのがベストですが、いずれのインストール方法も、オプションが多いため、最短パスでのインストールとなると、ドキュメントを読み解くのにある程度の知識が必要と感じます。
特に、オプション（というか、インストールに付帯する作業）が最も多いAnyplatformのインストール方法をまとめることによって、より取っ掛かりやすくできたらなという思いでこちらの記事を書きました！
環境
今回は、下図にある3 Master , 2 Worker 構成のOpenShift環境を構築します。
導入するOpenShiftのバージョンは、 4.14.4 (2023/12/1時点の最新)となります。
Anyplatform インストールの場合、環境構成にはいくつかオプションがあります。今回は、もっとも補助系の機能が少ない構成としています。
補助系の機能に関しては、可用性や運用性の観点から、冗長化や、Network Bootの仕組みの導入などを適宜検討する必要があります。
各マシンの役割
| 分類 | マシン名称 | 台数 | 役割 |
|---|---|---|---|
| OpenShift | bootstrap | 1 | 初期インストール時のみ必要となるノード |
| master | 3 | OpenShiftのコントロールプレーン | |
| worker | 2 | アプリケーションPODが可動するノード | |
| 補助 | bastion | 1 | 管理者がコマンドライン操作を行ういわゆる踏み台マシン。openshift-install , oc といったバイナリファイルを配置する。 |
| utility(*) | 1 | Loadbalanser , DNS , httpd(ignitionファイルの配布用）といったOpenShift に必要な外部機能を混載する。 |
(*) 各種機能は、アプライアンス製品や他サービスで代替できます。また、実践的な利用にむけては、冗長化など可用性を考慮した構成とすることを推奨します。
マシンスペック
| マシン名称 | CPU | RAM | System Disk | 使用したOS(*) |
|---|---|---|---|---|
| bootstrap | 4 VCPU | 16 GB | 120 GB | RHCOS |
| master | 4 VCPU | 16 GB | 120 GB | RHCOS |
| worker | 4 VCPU | 16 GB | 120 GB | RHCOS |
| bastion | 1 VCPU | 4 GB | 40 GB | RHEL 9 |
| utility | 2 VCPU | 8 GB | 100 GB | RHEL 9 |
(*) RHCOS = Red Hat Core OS , RHEL 9 = Red Hat Enterprise Linux 9
用意するもの
- マシン (物理マシン / VMゲストを問わない）
- インターネットアクセスが可能なネットワーク環境（１セグメント）
- Red Hat ID ※アカウントの状態によって評価版を申し込む必要あり。
-
カスタマーポータルより入手
- RHEL ISO ファイル
- RHCOS ISO ファイル
-
Red Hat Hybrid Consoleより入手
- openshift-installer
- oc コマンド
- pull-secret
-
カスタマーポータルより入手
インストール
大まかな作業の流れ
事前：補助系マシンの整備
- bastionマシンのOSインストール
- utilityマシンのOSインストール
- セットアップ
- dnsmasq
- haproxy
- httpd
- セットアップ
- RHCOS ISOイメージのマウント用意
OpenShiftインストール
- openshift-install , oc コマンドの配置
- ノードへのアクセス時に使用するSSHキーの生成
- install-config.yamlの作成
- クラスターの Kubernetes マニフェストの生成
- ignitionファイルの生成
- ignitionファイル配布の準備
- bootstrap ノードのブート
- master ノードのブート
- bootstrapプロセス完了の待機
- worker ノードのブート
- CSRの承認
- インストールプロセス完了の待機
- 確認
bastion & utility マシンのOSインストール
この点はさらっと記載します。
- RHELのISOメディア（または、仮想イメージ）を使用
- ソフトウェアの選択：『最小限のインストール』
- ネットワークへの接続 ( IPアドレス, Gateway , DNS )
- DNSについては、暫定のものを指定します。subscription-managerやdnfコマンドを実行するのに必要です。内部のdnsサーバがセットアップできた後、参照先を変更します。
- タイムゾーンの選択と時刻同期ON
- ホスト名の設定 ( bastion , utility )
- ディスク構成は任意。
- カスタマイズ時に "/home" を提案される場合は、"/" へ振りなおす
- rootアカウントのパスワード設定
- OSログイン用のユーザアカウントの追加 ( このユーザーを管理者アカウントにするをチェック）
- インストール後、subscription-manager コマンドを使用して、register と、attach を行う。
- OSの最新化 ( $ sudo dnf update -y )
utilityマシン ( dns , loadbalancer , httpd の設定）
dnsmasq
OpenShiftクラスターに関連する名前解決をできる必要があります。この手順では、dnsmasq を使用しました。
このDNSレコードは、OpenShiftを構成するマシン群および、OpenShiftのコンソールアクセス、OpenShift上で可動するアプリケーションへアクセスに使用するクライアントマシンが参照します。
尚、要件を満たす限りは異なるソフトウェアやアプライアンス、サービスで代替することが可能です。
パッケージのインストール
$ sudo dnf install -y dnsmasq
レコードの設定
ドキュメントにある要件を参考に、DNSレコードを追加します。
今回は、クラスター名を"cluser-ocp" ,base domain を、"myhome.lab" としました。
このため、主要なレコードは下記の様になります。
| 名前 | IPアドレス |
|---|---|
| api.cluster-ocp.myhome.lab | 192.168.3.129 |
| api-int.cluster-ocp.myhome.lab | 192.168.3.129 |
| *.apps.cluster-ocp.myhome.lab | 192.168.3.129 |
| bootstrap.cluster-ocp.myhome.lab | 192.168.3.191 |
| master01.cluster-ocp.myhome.lab | 192.168.3.193 |
| master02.cluster-ocp.myhome.lab | 192.168.3.194 |
| master03.cluster-ocp.myhome.lab | 192.168.3.195 |
| worker01.cluster-ocp.myhome.lab | 192.168.3.196 |
| worker02.cluster-ocp.myhome.lab | 192.168.3.197 |
参考"/etc/hosts"ファイル
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.3.128 bastion bastion.cluster-ocp.myhome.lab
192.168.3.129 api.cluster-ocp.myhome.lab api-int.cluster-ocp.myhome.lab lb01.myhome.lab lb01
192.168.3.191 bootstrap bootstrap.cluster-ocp.myhome.lab
192.168.3.193 master01 master01.cluster-ocp.myhome.lab
192.168.3.194 master02 master02.cluster-ocp.myhome.lab
192.168.3.195 master03 master03.cluster-ocp.myhome.lab
192.168.3.196 worker01 worker01.cluster-ocp.myhome.lab
192.168.3.197 worker02 worker02.cluster-ocp.myhome.lab
抜粋 "/etc/dnsmasq.conf"ファイル
ワイルドカードレコードの登録
...抜粋
# Add domains which you want to force to an IP address here.
# The example below send any host in double-click.net to a local
# web-server.
#address=/double-click.net/127.0.0.1
address=/apps.cluster-ocp.myhome.lab/192.168.3.129
...抜粋ここまで
デーモンの起動と自動起動設定
$ sudo systemctl enable dnsmasq
$ sudo systemctl start dnsmasq
firewalld のポート開け
dns のポートを開ける
$ sudo firewall-cmd --add-service dns --zone public --permanent
$ sudo firewall-cmd --reload
テスト
下記のように応答が返ってくることを確認する。
# 順引き
$ dig hoge.apps.cluster-ocp.myhome.lab
; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8 <<>> hoge.apps.cluster-ocp.myhome.lab
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6996
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;hoge.apps.cluster-ocp.myhome.lab. IN A
;; ANSWER SECTION:
hoge.apps.cluster-ocp.myhome.lab. 0 IN A 192.168.3.129
;; Query time: 0 msec
;; SERVER: 192.168.3.130#53(192.168.3.130)
;; WHEN: Thu Nov 30 19:06:04 JST 2023
;; MSG SIZE rcvd: 66
$
# 逆引き
$ dig -x 192.168.3.129
; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8 <<>> -x 192.168.3.129
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24418
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;129.3.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
129.3.168.192.in-addr.arpa. 0 IN PTR api.cluster-ocp.myhome.lab.
;; Query time: 0 msec
;; SERVER: 192.168.3.130#53(192.168.3.130)
;; WHEN: Thu Nov 30 19:08:11 JST 2023
;; MSG SIZE rcvd: 95
$
haproxy
3 master , n worker 構成のOpenShiftは、API や、ingressを経由したアプリケーションへのアクセスをロードバランサーでマスカレードする必要があります。
今回は、haproxy を使用して、外部ロードバランサー機能を実現しました。
尚、Layer 4 の負荷分散が可能であれば、ことなるアプライアンスやサービスで代替することが可能です。
パッケージのインストール
$ sudo dnf install -y haproxy
Pool の設定
ドキュメントの要件を参考に、負荷分散のグループを設定します。
| 名前 | ポート | プールメンバー |
|---|---|---|
| api-server | 6443 | bootstrap & master |
| machine-config-server | 22623 | bootstrap & master |
| ingress-router | 443 | worker |
| ingress-router | 80 | worker |
参考："/etc/haproxy/haproxy.cfg"
global
log 127.0.0.1 local2
pidfile /var/run/haproxy.pid
maxconn 4000
daemon
defaults
mode http
log global
option dontlognull
option http-server-close
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
frontend stats
bind *:9000
mode http
log global
maxconn 10
stats enable
stats hide-version
stats refresh 30s
stats show-node
stats show-desc Stats for ocp4 cluster
#stats auth admin:ocp4
stats uri /stats
listen api-server-6443
bind *:6443
mode tcp
server bootstrap bootstrap.cluster-ocp.myhome.lab:6443 check inter 1s backup
server master01 master01.cluster-ocp.myhome.lab:6443 check inter 1s
server master02 master02.cluster-ocp.myhome.lab:6443 check inter 1s
server master03 master03.cluster-ocp.myhome.lab:6443 check inter 1s
listen machine-config-server-22623
bind *:22623
mode tcp
server bootstrap bootstrap.cluster-ocp.myhome.lab:22623 check inter 1s backup
server master01 master01.cluster-ocp.myhome.lab:22623 check inter 1s
server master02 master02.cluster-ocp.myhome.lab:22623 check inter 1s
server master03 master03.cluster-ocp.myhome.lab:22623 check inter 1s
listen ingress-router-443
bind *:443
mode tcp
balance source
server worker01 worker01.cluster-ocp.myhome.lab:443 check inter 1s
server worker02 worker02.cluster-ocp.myhome.lab:443 check inter 1s
listen ingress-router-80
bind *:80
mode tcp
balance source
server worker01 worker01.cluster-ocp.myhome.lab:80 check inter 1s
server worker02 worker02.cluster-ocp.myhome.lab:80 check inter 1s
デーモンの起動と自動起動設定
$ sudo systemctl enable haproxy
$ sudo systemctl start haproxy
firewalld のポート開け
80,443,6443,22623 のポートを開放する
$ sudo firewall-cmd --add-service https --zone public --permanent
$ sudo firewall-cmd --add-service https --zone public --permanent
$ sudo firewall-cmd --add-service=kube-apiserver --zone=public --permanent
$ sudo firewall-cmd --permanent --new-service machine-config
$ sudo firewall-cmd --permanent --service=machine-config --set-description="OpenShift machine config access"
$ sudo firewall-cmd --service=machine-config --add-port=22623/tcp --permanent
$ sudo firewall-cmd --add-service=machine-config --zone=public --permanent
$ sudo firewall-cmd --add-port 9000/tcp --zone public --permanent
$ sudo firewall-cmd --reload
テスト
lbマシンの9090ポートにWebブラウザでアクセスし、ステータスページが表示されることを確認する。(この段階だと、全てのプールメンバーは起動していない為、全てがダウンステータスで表示されます。）
httpd
OpenShift のインストール時に、各coreos に設定ファイルとしてignitionを配布します。その配布用のサーバとして、httpd を構築しました。
今回は、utilityマシンにhaproxy ( 80 ポートをマスカレード）と混載しているため、ポートをデフォルトの80から8003 へ変更しています。haproxy と、ignition配布用のhttpd は、アクセスする用途が大きく異なる為、セキュリティや管理性を考慮し、マシンを異なるものとすべきかを検討する必要があります。
尚、OpenShiftを構成するマシン群からhttpにてアクセス可能であれば、異なるソフトウェアやアプライアンス、サービスに代替することが可能です。
パッケージのインストール
$ sudo dnf install -y httpd
httpd の設定
前述のとおり、リッスンポートを80から8003 へ変更する必要があるため、httpd.conf を変更します。
参考："/etc/httpd/conf/httpd.conf"
...抜粋
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 8003
...抜粋ここまで
デーモンの起動と自動起動設定
$ sudo systemctl enable httpd
$ sudo systemctl start httpd
firewalld のポート開け
8003 ポートを開ける
$ sudo firewall-cmd --add-port 8003/tcp --zone public --permanent
$ sudo firewall-cmd --reload
テスト
curlコマンドやWebブラウザーで http://lb01:8003 へアクセスし、レスポンスがあることを確認する。
$ curl http://lb01:8003
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>
... 省略
</div>
</body>
</html>
$
RHCOS ISOイメージのマウント用意
RHCOS のISOイメージを、カスタマーポータルから入手します。
入手したISOイメージを環境に合わせて、使用できるようにします。今回の環境は、KVM上に構築していますので、KVMホストのイメージストアにアップロートし、ゲストVMへアタッチしました。（下図は、virt-managerで表示したbootstrapノードの設定です。）
-
ISOイメージのアタッチ
-
bootデバイスの設定
OSのインストールメディアをアタッチするのと同じ操作となるので、仮想化環境が異なる場合は、環境にあわせて、同様の操作を行ってください。また、ベアメタルマシンの場合は、入手したISOイメージファイルをbootメディアとして用意します。（手順の上では、bootメディアは一つで大丈夫です。）
事前準備は完了となります。
OpenShift インストール
openshift-install , oc コマンドの入手と、bastionマシンへの配置
console.redhat.com()から、openshift-install およびoc コマンドを入手します。こちらのサイトから入手できるバイナリーは、公開済みの最新バージョンとなります。
() ログインするには、Red Hat ID が必要です。
尚、インストール方法を問わず、構築を行う際に使用するopenshift-install コマンドのバージョンが、その時点で選択できる最新のバージョンとなります。ターゲットとするOpenShiftバージョンより新しいopenshift-installを入手して使用するようにしてください。
console.redhat.comでの画面操作順を以下に示します。
- console.redhat.comログイン後のトップページ
- OpenShiftオーバービューの画面
- Cluster Typeの選択画面
- Cluster Type @ Datacenter の画面
- Cluster Type @ Datacenter = Platform agnostic
- 各種ファイルのダウンロード
※このページは、後の手順で、"pull secret"の取得時にもアクセスします。
入手したファイルは、適宜bastionマシンのOSログインユーザのディレクトリに配置します。また、各ダウンロードボタンからリンク先のURLを取得して、bastionマシンからcurl コマンドで入手することも可能です。
# ファイルの取得
$ curl -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-install-linux.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 410M 100 410M 0 0 7385k 0 0:00:56 0:00:56 --:--:-- 4294k
$ curl -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 60.9M 100 60.9M 0 0 7418k 0 0:00:08 0:00:08 --:--:-- 9004k
$ ls -l
total 483136
-rw-rw-r--. 1 toaraki toaraki 63934993 Dec 1 14:45 openshift-client-linux.tar.gz
-rw-rw-r--. 1 toaraki toaraki 430791889 Dec 1 14:44 openshift-install-linux.tar.gz
# tar.gz ファイルの展開と、/usr/local/binへの配置
$ sudo tar xzf openshift-client-linux.tar.gz -C /usr/local/bin
$ sudo tar xzf openshift-install-linux.tar.gz -C /usr/local/bin
# Pathとバージョンの確認
$ which oc
/usr/local/bin/oc
$ which openshift-install
/usr/local/bin/openshift-install
$ openshift-install version
openshift-install 4.14.3
built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
release image quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55
release architecture amd64
$ oc version
Client Version: 4.14.3
Kustomize Version: v5.0.1
$
ノードへのアクセス時に使用するSSHキーの生成
インストール時に各ノードへインジェクションされるSSHキーを生成します。
$ ssh-keygen -t ed25519 -N '' -f ~/.ssh/cluster-ocp
Generating public/private ed25519 key pair.
Your identification has been saved in
... << ommited >>
| o . ...E .. |
| . .o. |
| . |
| |
+----[SHA256]-----+
$
install-config.yamlの作成
openshift-installコマンドに渡すパラメータを、install-config.yaml ファイルに記述します。
今回作成したinstall-config.yaml を以下に示します。
install-config.yaml
apiVersion: v1
# base domainの指定
baseDomain: myhome.lab
compute:
- hyperthreading: Enabled
name: worker
# replicas は、台数を指定するが、Anyplatformインストールの場合は、"0" 一択
replicas: 0
controlPlane:
hyperthreading: Enabled
name: master
replicas: 3
metadata:
# クラスターの名称を指定する。
name: cluster-ocp
networking:
# -- マニュアルより引用 --
# Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の
# 物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用
# されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサー
# およびルーターを、トラフィックを管理するように設定する必要があります。
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
networkType: OVNKubernetes
# -- マニュアルより引用 --
# サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみ
# を入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネット
# ワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、
# トラフィックを管理するように設定します。
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
fips: false
pullSecret: '{"auths": ...}'
# 後述するconsole.openshift.com で取得する、'pull secret'の値を "..." 箇所に記入する。
sshKey: 'ssh-ed25519 AAAA...'
# 前手順で生成した SSH鍵を指定する。
- 'pull secret'の取得方法
インストール構成を管理するディレクトリ(通例では、クラスター名を指定）作成し、作成したinstall-config.yaml を配置します。尚、install-config.yamlは、以降の操作でファイルが消失してしまう仕様のため、再インストール時に備えてコピーを取得しておくことをおすすめします。
$ mkdir cluster-ocp
$ mv install-config.yaml cluster-ocp/.
$ mkdir cluster-ocp-config-bk
$ cp cluster-ocp/install-config.yaml cluster-ocp-config-bk/.
$
クラスターの Kubernetes マニフェストの生成
openshift-installコマンドを使用して、kubernetesマニフェスト（インストールの構成ファイル）を生成します。
$ openshift-install create manifests --dir ~/cluster-ocp
INFO Consuming Install Config from target directory
WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
INFO Manifests created in: /home/toaraki/cluster-ocp/manifests and /home/toaraki/cluster-ocp/openshift
$
生成されたマニフェストファイルから、コントロールプレーンへのPODスケジューリングに関するパラメータを確認します。(下記、マニュアルから引用）
<installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェスト
ファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。
この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。
i. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
ii. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
iii .ファイルを保存し、終了します。
実際に生成されたままのファイルはこちら。
cluster-scheduler-02-config.yml
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
creationTimestamp: null
name: cluster
spec:
mastersSchedulable: true
policy:
name: ""
status: {}
7行目の'mastersSchedulable'が、'true' になっているので、これをfalse に変更します。（今回の構成では、master ノードにユーザアプリケーションをデプロイさせないようにしたいため。）
編集後のファイルはこちら
cluster-scheduler-02-config.yml
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
creationTimestamp: null
name: cluster
spec:
mastersSchedulable: false
policy:
name: ""
status: {}
ignitionファイルの生成
インストール処理においてRHCOSに設定を行うinigitionファイルを生成＆変更済みのクラスターkubernetesマニフェストファイルから生成します。
$ openshift-install create ignition-configs --dir ~/cluster-ocp
INFO Consuming Openshift Manifests from target directory
INFO Consuming Worker Machines from target directory
INFO Consuming Master Machines from target directory
INFO Consuming Common Manifests from target directory
INFO Consuming OpenShift Install (Manifests) from target directory
INFO Ignition-Configs created in: /home/toaraki/cluster-ocp and /home/toaraki/cluster-ocp/auth
$ ls -l ~/cluster-ocp
total 288
drwxr-x---. 2 toaraki toaraki 50 Dec 1 17:22 auth
-rw-r-----. 1 toaraki toaraki 282434 Dec 1 17:22 bootstrap.ign
-rw-r-----. 1 toaraki toaraki 1724 Dec 1 17:22 master.ign
-rw-r-----. 1 toaraki toaraki 110 Dec 1 17:22 metadata.json
-rw-r-----. 1 toaraki toaraki 1724 Dec 1 17:22 worker.ign
$
ignitionファイル配布の準備
各ノードをセットアップする際は、前段で生成したignitionファイルを使用します。これを、準備のステップで構築したhttpd経由で取得できるように、ignitionファイルをwebサーバへ配置します。
SHA512ダイジェストの確認と記録
RHCOSのインストールセットアッププロセスの途中で、取得したignitionファイルが、適切なものであることのチェックがあるため、SHA512ダイジェストを取得して、メモを記録します。
今回使用する手順では、RHCOS上でコマンドライン入力で操作をおこいますが、この時にダイジェストの値を手で入力するには、あまりに大変なので、ここで収集した情報を元に、RHCOS上で実行するコマンドをワンショットのシェルスクリプトに書き起こしておくと、楽になります。
## SHA512ダイジェストの確認
$ sha512sum ~/cluster-ocp/*.ign
d431589e4f7f57f2451ee945f497b5fa8ecdb09962b24490274dc766694b0e692a99ac78f3e85612740a258fd7935ab2c8a926cabb84fb9506370f879e2edb3c /home/toaraki/cluster-ocp/bootstrap.ign
3f5c52f46cb918289bbbf594cb574061388d4168246cea504d957032a7ac23ebcf5c53dd7cec7dce9f16b6a0d895608adaff4f8552575eac4546cf7c4390dda5 /home/toaraki/cluster-ocp/master.ign
1231669a24a03bc4e390d457aac22f04436fbc1ecd7be73dffdc5f5512c82077bb3c72df0f5e16996ab968eddebfe0f4d859e51bf006f6f3c3121b10652eb9b5 /home/toaraki/cluster-ocp/worker.ign
$
bootstrap , master , worker のRHCOSインストールコマンドシェルスクリプトの準備
- (参考)作成したbootstrapノード用のシェルスクリプト
coreos_setup_bootstrap.sh
#/bin/sh
## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=bootstrap.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=d431589e4f7f57f2451ee945f497b5fa8ecdb09962b24490274dc766694b0e692a99ac78f3e85612740a258fd7935ab2c8a926cabb84fb9506370f879e2edb3c
## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network
- (参考)作成したmasterノード用のシェルスクリプト
coreos_setup_master.sh
#!/bin/sh
## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=master.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=3f5c52f46cb918289bbbf594cb574061388d4168246cea504d957032a7ac23ebcf5c53dd7cec7dce9f16b6a0d895608adaff4f8552575eac4546cf7c4390dda5
## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network
- (参考)作成したworkerノード用のシェルスクリプト
coreos_setup_worker.sh
#!/bin/sh
## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=worker.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=1231669a24a03bc4e390d457aac22f04436fbc1ecd7be73dffdc5f5512c82077bb3c72df0f5e16996ab968eddebfe0f4d859e51bf006f6f3c3121b10652eb9b5
## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network
ignitionファイルをWebサーバへ配置
$ cd ~/cluster-ocp
$ ls
auth bootstrap.ign master.ign metadata.json worker.ign
$ scp *.ign root@lb01:/var/www/html/.
root@lb01's password:
bootstrap.ign 100% 276KB 49.8MB/s 00:00
master.ign 100% 1724 723.7KB/s 00:00
worker.ign 100% 1724 640.0KB/s 00:00
## @springred 様より必要の旨コメントあり（実機確認中）
## lb01へ、*.ign ファイルをアップロードした後で、lb01上で
## "chmod 755 -R /var/www/html" を行わないと、403エラー
## となる。
## （ここまで）
$ curl -I lb01:8003/bootstrap.ign
HTTP/1.1 200 OK
Date: Sat, 02 Dec 2023 08:42:24 GMT
Server: Apache/2.4.37 (Red Hat Enterprise Linux)
Last-Modified: Sat, 02 Dec 2023 08:37:08 GMT
ETag: "44f42-60b82ca50c67d"
Accept-Ranges: bytes
Content-Length: 282434
Content-Type: application/vnd.coreos.ignition+json
$
Webサーバへinigitionファイルをアップロードしたら、いよいよノードのセットアップとなります。
bootstrapノードのブート
準備のセクションで設定したとおり、RHCOSのISOメディアからブートする設定としたうえで、boostrap用のノードの電源をONにします。
起動が完了すると、コマンドプロンプトが表示されます。
今回の方法だと、起動したRHCOSにはIPアドレス等が一切付与されない状態で起動してきますのでネットワークの設定を手動で投入します。
このスクリーンショットでは、nmcliコマンドでOS起動時に作成される'Wired connection 1'を削除（名前が扱いにくいため）たうえで、新しいコネクションプロファイルを作成し、IPアドレス・ネットマスクを付与します（他マシンと通信するための最低限の設定）。
その後、手元にあったシェルスクリプト(niccnf.sh ...コマンドを羅列しただけの物なので説明しません)をscp し、ネットワークの設定を流し込みました。
シェルスクリプトで設定しているリストは以下のとおりです。
- ipv4.address ... IPアドレスとネットマスク
- ipv4.method ... Auto(DHCP)/Manual/無視/無効の切り替え
- connection.autoconnect ... OS起動時に自動活性するかどうか
- ipv4.dns ... 参照先DNSサーバ（=このシナリオでは、utiltyマシンのIPアドレスを指定しています）※画像との整合性を要修正
- ipv4.gateway ... デフォルトゲートウェイ
- ipv6.method ... ipv6 のAuto/Manual/無視/無効の切り替え
続いて、前の手順で作成したcoreos_setup_bootstrap.sh を入手し、実行します。
RHCOSのイメージコピーおよびネットワーク設定の引き継ぎが行われるので、完了したらOSをリブートします。
再起動後、boostrapノードのOpenShiftに関連するセットアップが自動的に実行されます。
画面は再起動が完了し、裏で自動的にセットアップが行われている様子となります。
masterノードのブート
bootstrapノードとほぼ同じ内容で、masterノードもブートしていきます。
操作内容の相違点は、
- 各ノードに割り当てるIPアドレス
- masterノードの用のcoreos-installer コマンドのシェルスクリプトを使用する
- リブートのタイミングは3台はなるべく同じタイミングで実施
- 根拠はないですが、内部で処理させるetcdクラスタリングの処理等を想像すると、あまり離れたタイミングではない方がいいのではないかと思っています。。。
boostrapプロセス完了の待機
masterノード3台のリブートが完了したら、bootstrapプロセスが完了するまで待機します。
待機には、openshift-installコマンドのwait-for オプションを使用します。
以下に実際に実行した時の出力を示します。
$ openshift-install --dir cluster-ocp wait-for bootstrap-complete --log-level=debug
DEBUG OpenShift Installer 4.14.3
DEBUG Built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
INFO Waiting up to 20m0s (until 9:23PM JST) for the Kubernetes API at https://api.cluster-ocp.myhome.lab:6443...
DEBUG Loading Agent Config...
INFO API v1.27.6+b49f9d1 up 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 Networking...
DEBUG Loading Platform...
DEBUG Loading Pull Secret...
DEBUG Loading Platform...
DEBUG Using Install Config loaded from state file
INFO Waiting up to 30m0s (until 9:33PM JST) for bootstrapping to complete...
DEBUG Bootstrap status: complete
INFO It is now safe to remove the bootstrap resources
DEBUG Time elapsed per stage:
DEBUG Bootstrap Complete: 31s
INFO Time elapsed: 31s
$
workerノードのブート
bootstrapノード , masterノードと同様の内容で、workerノードをブートしていきます。
操作内容の相違点は、
- 各ノードに割り当てるIPアドレス
- masterノードの用のcoreos-installer コマンドのシェルスクリプトを使用する
- coreos-installer コマンドの後、OSをリブート
CSR(Certificate Signing Requests)の承認
workerノードのセットアッププロセス中に、クラスターへジョインするタイミングで、CSRが発行されます。この要求が特に問題がない（今回は、インストールを意図しているため問題はない。）場合、CSRを承認します。
$ oc get csr | grep -i pending
csr-8kjrg 103s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper <none> Pending
csr-b8gbf 114s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper <none> Pending
csr-jwnzb 2m20s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper <none> Pending
csr-xdjp6 2m10s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper <none> Pending
[toaraki@bastion ~]$
※oc コマンドを実行する際に、認証が必要な旨のメッセージが表示される場合は、KUBECONFIG環境変数を設定します。
oc get csr
error: Missing or incomplete configuration info. Please point to an existing, complete config file:
1. Via the command-line flag --kubeconfig
2. Via the KUBECONFIG environment variable
3. In your home directory as ~/.kube/config
To view or setup config directly use the 'config' command.
$ export KUBECONFIG=~/cluster-ocp/auth/kubeconfig
$ oc whoami
system:admin
$
次のワンライナーコマンドで、Pending 状態のCSRを一括で承認できます。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
certificatesigningrequest.certificates.k8s.io/csr-8kjrg approved
certificatesigningrequest.certificates.k8s.io/csr-b8gbf approved
certificatesigningrequest.certificates.k8s.io/csr-jwnzb approved
certificatesigningrequest.certificates.k8s.io/csr-xdjp6 approved
[toaraki@bastion ~]$
続けて、'kubernetes.io/kubelet-serving' が要求されますので、同様に承認します。
$ oc get csr | grep -i pending
csr-qzf8l 77s kubernetes.io/kubelet-serving system:node:worker02.cluster-myhome.lab <none> Pending
csr-xh4vk 75s kubernetes.io/kubelet-serving system:node:worker01.cluster-myhome.lab <none> Pending
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
certificatesigningrequest.certificates.k8s.io/csr-qzf8l approved
certificatesigningrequest.certificates.k8s.io/csr-xh4vk approved
$
この操作が完了すると、worker ノードのクラスターへの参加が完了し、後続の処理が継続されます。
[toaraki@bastion ~]$ oc get node
NAME STATUS ROLES AGE VERSION
master01.cluster-myhome.lab Ready control-plane,master 58m v1.27.6+b49f9d1
master02.cluster-myhome.lab Ready control-plane,master 57m v1.27.6+b49f9d1
master03.cluster-myhome.lab Ready control-plane,master 58m v1.27.6+b49f9d1
worker01.cluster-myhome.lab NotReady worker 3m32s v1.27.6+b49f9d1
worker02.cluster-myhome.lab NotReady worker 3m34s v1.27.6+b49f9d1
[toaraki@bastion ~]$
インストールプロセス完了の待機
再び、openshift-install のwait-for オプションを指定して、インストールプロセスが完了するのを待ちます。
$ openshift-install --dir cluster-ocp wait-for install-complete --log-level=debug
DEBUG OpenShift Installer 4.14.3
DEBUG Built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
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 Networking...
DEBUG Loading Platform...
DEBUG Loading Pull Secret...
DEBUG Loading Platform...
DEBUG Using Install Config loaded from state file
DEBUG Loading Agent Config...
INFO Waiting up to 40m0s (until 10:18PM JST) for the cluster at https://api.cluster-ocp.myhome.lab:6443 to initialize...
DEBUG Still waiting for the cluster to initialize: Cluster operators authentication, console, ingress, monitoring are not available
DEBUG Still waiting for the cluster to initialize: Cluster operators authentication, console, monitoring are not available
...ommited
DEBUG Cluster is initialized
INFO Checking to see if there is a route at openshift-console/console...
DEBUG Route found in openshift-console namespace: console
DEBUG OpenShift console route is admitted
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/toaraki/cluster-ocp/auth/kube
config'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.cluster-ocp.myhome.lab
INFO Login to the console with user: "kubeadmin", and password: "xxxxxxxxxxxxxx"
DEBUG Time elapsed per stage:
DEBUG Cluster Operators: 10m41s
INFO Time elapsed: 10m41s
$
コマンドが完了するとk、下記の様にクラスターの認証情報が表示されます。
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/toaraki/cluster-ocp/auth/kube
config'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.cluster-ocp.myhome.lab
INFO Login to the console with user: "kubeadmin", and password: "xxxxxxxxxxxxxx"
確認
実際に環境へアクセスして、OpenShiftが稼働していることを確認します。
cluster-operator の確認
$ export KUBECONFIG=~/cluster-ocp/auth/kubeconfig
$ oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.14.3 True False False 12m
baremetal 4.14.3 True False False 64m
cloud-controller-manager 4.14.3 True False False 78m
cloud-credential 4.14.3 True False False 86m
cluster-autoscaler 4.14.3 True False False 63m
config-operator 4.14.3 True False False 68m
console 4.14.3 True False False 17m
control-plane-machine-set 4.14.3 True False False 63m
csi-snapshot-controller 4.14.3 True False False 66m
dns 4.14.3 True False False 63m
etcd 4.14.3 True False False 65m
image-registry 4.14.3 True False False 52m
ingress 4.14.3 True False False 20m
insights 4.14.3 True False False 61m
kube-apiserver 4.14.3 True False False 51m
kube-controller-manager 4.14.3 True False False 58m
kube-scheduler 4.14.3 True False False 60m
kube-storage-version-migrator 4.14.3 True False False 54m
machine-api 4.14.3 True False False 59m
machine-approver 4.14.3 True False False 66m
machine-config 4.14.3 True False False 64m
marketplace 4.14.3 True False False 63m
monitoring 4.14.3 True False False 18m
network 4.14.3 True False False 68m
node-tuning 4.14.3 True False False 66m
openshift-apiserver 4.14.3 True False False 54m
openshift-controller-manager 4.14.3 True False False 54m
openshift-samples 4.14.3 True False False 53m
operator-lifecycle-manager 4.14.3 True False False 65m
operator-lifecycle-manager-catalog 4.14.3 True False False 65m
operator-lifecycle-manager-packageserver 4.14.3 True False False 54m
service-ca 4.14.3 True False False 68m
storage 4.14.3 True False False 68m
$
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.14.3 True False 13m Cluster version is 4.14.3
$
Webブラウザーでのアクセス
openshift-install --dir cluster-ocp wait-for install-completeの最終段階で出力された認証情報を使用してログインします。
ログインに成功すると、ダッシュボードが表示されます。
以上
ここまでで、Anyplatform InstallationによるOpenShiftクラスター master 3 , worker 2 構成のインストールが完了となります！
おつかれさまでした〜