Power Systems Virtual ServerへのOpenShift 4.7導入(3): UPIインストール

はじめに

この記事では、Power Systems Virtual Server(以下PowerVS)へのOpenShift 4.7の導入作業を実施します。事前準備については、ネットワーク構成とbastionノード等の構成を参照ください。残る作業はignitionファイルを作成・配置してmaster/worker/bootstrapノードをbootp起動するのみです。導入完了後にイメージレジストリのストレージとしてCloud Object Storageを設定します。

1. ignitionファイル作成と配置

1.1. OpenShift pull secret入手

cloud.redhat.comへログインしpull secretを入手します。
(1)DatacenterタブでBare Metalを選択

(2) User-provisioned infrastructureを選択

(3) pull secretをダウンロード

1.2. ignitionファイルの作成と配置

ignitionファイルには有効期限がある点に注意します。

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターが再起動すると、クラスターは期限切れの証明書を自動的に復元します。

bastionノード

cd /root/ocp/install
vi install-config.yaml
apiVersion: v1
baseDomain: powervs
compute:
- hyperthreading: Enabled
  name: worker
  replicas: 2
controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3
metadata:
  name: ocp
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {}
fips: false
pullSecret: <pullシークレット>
sshKey: <公開鍵文字列>

bastionノード

mkdir bare-metal
cp -p install-config.yaml bare-metal/
./openshift-install create ignition-configs --dir=bare-metal
cp -p bare-metal/*ign /var/www/html/
chmod 644 /var/www/html/*.ign
ls -l /var/www/html/*.ign
### 標準出力↓
-rw-r--r-- 1 root root    290172  5月  4 09:48 bootstrap.ign
-rw-r--r-- 1 root root      1713  5月  4 09:48 master.ign
-rw-r--r-- 1 root root      1713  5月  4 09:48 worker.ign

2. master/worker/bootstrapノードのbootp起動

各ノードのコンソールを開いた後、ノードを再始動しSMSメニューに入ります。

ibmcloud CLIを利用してコンソールのURLを取得し再始動することもできます。

classicノード

ibmcloud pi instance-get-console <インスタンス名>
ibmcloud pi instance-reset-state <インスタンス名>

2.1. IPアドレス設定

下記の順序でSMSメニューを進みIPアドレスを設定します。
2.Setup Remote IPL (Initial Program Load)
1.Interpartition Logical LAN
1.IPv4 - Address Format 123.231.111.222
1.BOOTP
1.IP Parameters

※上記はbootstrapノードのIPアドレス設定例です。master/worker/bootstrapノードすべてで設定します。

2.2. bootp起動

『M』ボタン押下で初期画面に戻り、下記の順序でSMSメニューを進みbootpで起動します。
5.Select Boot Options
1.Select Install/Boot Device
4.Network
1.BOOTP
1.Interpartition Logical LAN
2.Normal Mode Boot
1.Yes

dnsmasqとhttpdのログからbootstrapノードのbootp起動に関連するログを抜粋します。

/var/log/dnsmasq.log

May  4 09:51:02 dnsmasq-tftp[28269]: sent /var/lib/tftpboot/boot/grub2/powerpc-ieee1275/core.elf to 192.168.25.120
･･･
May  4 09:51:12 dnsmasq-tftp[28269]: sent /var/lib/tftpboot/boot/grub2/powerpc-ieee1275/grub.cfg-01-fa-55-2f-73-75-20 to 192.168.25.120
May  4 09:51:19 dnsmasq-tftp[28269]: sent /var/lib/tftpboot/rhcos-4.7.7-ppc64le-live-kernel-ppc64le to 192.168.25.120
May  4 09:51:33 dnsmasq-tftp[28269]: sent /var/lib/tftpboot/rhcos-4.7.7-ppc64le-live-initramfs.ppc64le.img to 192.168.25.120

/var/log/httpd/access.log

192.168.25.120 - - [04/May/2021:09:51:43 +0900] "GET /rhcos-4.7.7-ppc64le-live-rootfs.ppc64le.img HTTP/1.1" 200 831403520 "-" "curl/7.61.1"
192.168.25.120 - - [04/May/2021:09:52:23 +0900] "GET /bootstrap.ign HTTP/1.1" 200 290172 "-" "-"

2.3. UPIインストール完了待機

概ね下記の順序でインストールは進みます。
(1) bootstrapノード準備、22623番ポートと6443番ポートオープン
(2) masterノード準備、22623番ポートと6443番ポートオープン
～ bootstrap完了 ～
(3) workerノード準備、80番ポートと443番ポートオープン
(4) Cluster Operator準備
～ インストール完了 ～

haproxyでポート状況から進度を確認することができます。

bastionノード

echo "show stat" | socat stdio /var/lib/haproxy/stats | awk -F, '{print $1,$2,$18}'
### 標準出力↓
# pxname svname status
K8s-api FRONTEND OPEN
Machine-config FRONTEND OPEN
Ingress-http FRONTEND OPEN
Ingress-https FRONTEND OPEN
api-6443 bootstrap DOWN
api-6443 master-0 UP
api-6443 master-1 UP
api-6443 master-2 UP
api-6443 BACKEND UP
config-22623 bootstrap DOWN
config-22623 master-0 UP
config-22623 master-1 UP
config-22623 master-2 UP
config-22623 BACKEND UP
http-80 worker-0 UP
http-80 worker-1 UP
http-80 BACKEND UP
https-443 worker-0 UP
https-443 worker-1 UP
https-443 BACKEND UP

下記コマンドを実行しbootstrapの完了を待機します。

bastionノード

./openshift-install wait-for bootstrap-complete --dir=bare-metal
### 標準出力↓
INFO Waiting up to 20m0s for the Kubernetes API at https://api.ocp.powervs:6443...
INFO API v1.20.0+c8905da up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources
INFO Time elapsed: 20m45s

bootstrap完了後しばらくすると、workerノードのCSRがPendingで認識されるので2回承認します。

bastionノード

■ 1回目
export KUBECONFG=/root/ocp/install/bare-metal/auth/kubeconfig
oc get csr | grep "Pending"
### 標準出力↓
csr-2mrhn   42s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-pz5fs   11m   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending

oc get csr | grep "Pending" | awk '{print $1}' | xargs oc adm certificate approve
### 標準出力↓
certificatesigningrequest.certificates.k8s.io/csr-2mrhn approved
certificatesigningrequest.certificates.k8s.io/csr-pz5fs approved

■ 2回目
oc get csr | grep "Pending"
### 標準出力↓
csr-dt759   2s    kubernetes.io/kubelet-serving                 system:node:worker-0.ocp.powervs                                            Pending
csr-qctdg   6s    kubernetes.io/kubelet-serving                 system:node:worker-1.ocp.powervs                                            Pending

oc get csr | grep "Pending" | awk '{print $1}' | xargs oc adm certificate approve
### 標準出力↓
certificatesigningrequest.certificates.k8s.io/csr-dt759 approved
certificatesigningrequest.certificates.k8s.io/csr-qctdg approved

CSR承認後しばらくすると、workerノードがReady状態になるのでインストール完了を待機します。

bastionノード

oc get nodes
### 標準出力↓
NAME                   STATUS   ROLES    AGE   VERSION
master-0.ocp.powervs   Ready    master   1h    v1.20.0+c8905da
master-1.ocp.powervs   Ready    master   1h    v1.20.0+c8905da
master-2.ocp.powervs   Ready    master   1h    v1.20.0+c8905da
worker-0.ocp.powervs   Ready    worker   1h    v1.20.0+c8905da
worker-1.ocp.powervs   Ready    worker   1h    v1.20.0+c8905da

./openshift-install wait-for install-complete --dir=bare-metal
### 標準出力↓
INFO Waiting up to 40m0s for the cluster at https://api.ocp.powervs:6443 to initialize... 
INFO Waiting up to 10m0s for the openshift-console route to be created... 
INFO Install complete!                            
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/root/ocp/install/bare-metal/auth/kubeconfig' 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.ocp.powervs 
INFO Login to the console with user: "kubeadmin", and password: "<パスワード>" 
INFO Time elapsed: 2m37s   

作業端末のブラウザにプロキシを設定(10.192.36.132:3128)すれば、下記URLでOpenShiftコンソールへアクセスできます。作業端末はIBM CloudにSSL VPN接続しているため、classcノードのプライベートアドレスに接続しています。
https://console-openshift-console.apps.ocp.powervs/

アクセス経路

作業端末 → classicノード(squidフォワードプロキシ:3128)
        → bastionノード(haproxyリバースプロキシ:80/443)
        → OpenShiftルーターPod → OpenshiftコンソールPod

3. bootstrapノード削除

不要になったbootstrapノードを削除します。

classicノード

ibmcloud pi instance-delete bootstrap

4. イメージレジストリーの設定

OpenShift導入直後は、コンテナイメージを格納するレジストリのストレージ設定がされておらず、コンテナイメージを作成し格納することができません。Red Hatのマニュアルには、イメージレジストリーにオブジェクトストレージが推奨されること、AWS S3を利用可能であることが記述されています。Cloud Object StorageはAWS S3互換なのでイメージレジストリに設定します。

■ 前提
・Cloud Object Storageにバケット「openshift-image-registry」作成済
・HMACを含む資格情報を作成済

bastionノード

oc create secret generic image-registry-private-configuration-user \
  --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=<access_key_id>     \
  --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=<secret_access_key> \
  -n openshift-image-registry
oc patch configs.imageregistry.operator.openshift.io cluster \
  --type merge                                               \
  --patch '{"spec":{"storage":{"s3":{"bucket":"openshift-image-registry","regionEndpoint":"s3.private.jp-tok.cloud-object-storage.appdomain.cloud","region":"dummy"}}}}'
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'

oc get pod -n openshift-image-registry
### 標準出力(image-registryが作成される)
NAME                                               READY   STATUS      RESTARTS   AGE
cluster-image-registry-operator-66bccc9494-2r5mc   1/1     Running     1          23h
image-pruner-1620172800-rhb46                      0/1     Completed   0          54m
image-registry-7bc967bc8d-wclzg                    1/1     Running     0          117s
node-ca-6vbfc                                      1/1     Running     0          23h
node-ca-8bnng                                      1/1     Running     0          23h
node-ca-tbvd6                                      1/1     Running     0          23h
node-ca-tzsch                                      1/1     Running     0          23h
node-ca-vpq6c                                      1/1     Running     0          23h

下図はCloud Object Storageの資格情報の抜粋です。

5. リソース状況

5.1. ノード一覧

OpenShiftコンソールでノード一覧を確認しました。

5.2. リソースリクエスト

定常状態のリソースリクエストを「oc describe nodes」で確認したところ下表のようになっていました。

ノード	cpu requests	memory requests
master-0	1564m	7175Mi
master-1	1581m	7300Mi
master-2	1664m	7240Mi
worker-0	476m	4633Mi
worker-1	553m	3979Mi

5.3. 物理コア使用状況

定常状態の物理コア使用状況をlparstatコマンドで確認したところ下表のようになっていました。%idleは割り当てている物理コア(physc)のうち使用されていない割合を表します。つまり、used列分のコアが使用されていることになります。

masterノード、workerノードともに仮想サーバー・インスタンスを0.5コア上限なし(共有)で作成しています。「lparstat -i」コマンドの出力がMinimum Capacity=0.25、Maximum Capacity=4.00だったので、物理コアは負荷に応じて0.25～4.00の範囲で割り当てられることになります。また、SMT8になっていました。

ノード	%idle	physc	used (100-%idle) /100*physc
master-0	91.63	0.59	0.05
master-1	89.86	0.63	0.06
master-2	90.03	0.67	0.07
worker-0	92.59	0.41	0.03
worker-1	94.04	0.34	0.02

5.4. メモリー使用状況

定常状態のメモリー使用状況をfreeコマンドで確認したところ下表のようになっていました。単位はGBです。

ノード	total	used	available	total - available
master-0	15.88	10.14	4.90	10.99
master-1	15.88	10.96	4.07	11.81
master-2	15.88	11.51	3.52	12.37
worker-0	15.88	9.87	5.86	10.03
worker-1	15.88	8.47	6.95	8.94