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

# はじめに
この記事では、Power Systems Virtual Server(以下PowerVS)へのOpenShift 4.7の導入作業を実施します。事前準備については、[ネットワーク構成](https://qiita.com/y-akio/items/4dda34a293a6fd6dc7e4)と[bastionノード等の構成](https://qiita.com/y-akio/items/e196554b2fd7f881102c)を参照ください。残る作業はignitionファイルを作成・配置してmaster/worker/bootstrapノードをbootp起動するのみです。導入完了後にイメージレジストリのストレージとしてCloud Object Storageを設定します。
![01_custom.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/60c4dea1-7135-6d15-1b06-75bac6d7ce0b.png)

# 1. ignitionファイル作成と配置
## 1.1. OpenShift pull secret入手
[cloud.redhat.com](https://cloud.redhat.com/openshift/install)へログインしpull secretを入手します。
**(1)DatacenterタブでBare Metalを選択**
![secret01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/33da924d-b641-4524-7d67-a3a4d9e3d37a.png)
**(2) User-provisioned infrastructureを選択**
![secret02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/fe722d26-579a-7336-baaf-eb7e503ac670.png)
**(3) pull secretをダウンロード**
![secret03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/60434bd2-b48e-e54f-b2a5-271f08c83fd5.png)

## 1.2. ignitionファイルの作成と配置
ignitionファイルには有効期限がある点に注意します。

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

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/installing/installing-on-bare-metal#installation-user-infra-generate-k8s-manifest-ignition_installing-bare-metal

```bash: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: <公開鍵文字列>
```

```bash: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メニューに入ります。
![sms00.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/c6b20eeb-061d-23c6-35b0-f5fb3aef1923.png)
ibmcloud CLIを利用してコンソールのURLを取得し再始動することもできます。

```bash: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
![sms13.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/55f655a9-a417-0574-2c5c-b7863df03767.png)
※上記は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でポート状況から進度を確認することができます。

```bash: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の完了を待機します。

```bash: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回承認します。

```bash: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状態になるのでインストール完了を待機します。

```bash: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/

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


![console.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/ffaf2da1-eff9-f6b3-861f-a5ed287a7461.png)






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

```bash:classicノード
ibmcloud pi instance-delete bootstrap
```

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


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

```bash: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の資格情報の抜粋です。
![hmac.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/c2e5c992-4fac-96fd-4d87-0e5e29a20f61.png)

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/scalability_and_performance/recommended-configurable-storage-technology_persistent-storage

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/registry/setting-up-and-configuring-the-registry#configuring-registry-storage-aws-user-infrastructure


# 5. リソース状況
## 5.1. ノード一覧
OpenShiftコンソールでノード一覧を確認しました。
![ノード状態(ppc64le)_2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/f951dfa2-3f24-2b02-f9e0-4480f06ebbbf.png)

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

|  ノード  | cpu<br>requests | memory<br>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<br>(100-%idle)<br>/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 <br>- 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