Red Hat Learning Subscription (RHLS): ④OpenShiftの起動を待つ間の暇つぶし
はじめに
OpenShiftの演習を開始するために仮想マシンを起動するのには2~3分程度の時間がかかります。さらにworkstationにログインしてターミナルでラボのstartスクリプトを入力してから数分待たされます。OpenShiftは電源を入れたままの状態で常に動作し続けることが運用の前提です。RHLSのように仮想マシンの起動から始める場合、OpenShiftクラスターの起動をしなければならないので準備に時間がかかるのは仕方ないことです。この記事ではクラスターの起動を待っている間に私が暇つぶしにやっているocコマンドをいくつか紹介します。それらのコマンドによってクラスターの起動状況を確認することができます。
OpenShiftの演習開始まで
この記事ではDO180 OCP4.14の演習環境を例にガイド付き演習を実施してみたいと思います。まず演習環境で [作成] または [開始] ボタンを押して仮想マシン一式を起動します。
![](https://assets.st-note.com/img/1711173243711-86n46r4k1u.png?width=1200)
すべての仮想マシンがアクティブになったところで、workstationの [コンソールを開く] を押してRHELの環境を開きます。
![](https://assets.st-note.com/img/1711173347756-ytxj77LWnt.png?width=1200)
worksationサーバーにstudentユーザーでログインし、ターミナルを開きます。例として、1.6 ガイド付き演習 Web コンソールの操作を実施するため lab start intro-navigateというコマンドを入力します。すでにクラスターが起動した状態で同じコマンドを入力すると、次の様にすぐにレスポンスが返ってきます。こうなれば、このガイド付き演習を開始できます。
[student@workstation ~]$ lab start intro-navigate
SUCCESS Verifying cluster state
ところが、仮想マシンを起動した直後に演習を開始しようとするとクラスターが起動途中のため、コマンドがSUCCESSの応答を返すまで数分~10分程度の長い時間待たされます。認定試験前に準備しようと考えているときには、少しの待ち時間でもとてもイライラしますね。
[student@worksation ~]$ lab start intro-navigate
| Verifying cluster state
仮想マシンが起動したあとに、OpenShiftクラスターは起動を始めます。クラスターの起動が完了しなければ演習は開始できません。
でも、このstartスクリプトの実行が完了するまでの待ち時間にでも、できることがあります。この隙間時間にOpenShiftのCLIコマンド (oc) を叩いて肩慣らしをしておきましょう。
utilityサーバーでwait.shを実行しよう
クラスターの起動を早めることはできなくとも、クラスターが起動しているプロセスを「見る」ことはできます。sshでutilityサーバーにログインして、wait.shスクリプトを実行すると、クラスターの起動の様子をログに表示してくれます。このログを眺めることで、クラスターの起動プロセスの進捗を確認することができます。ただクラスターの起動を終わるのを待っているだけより、どこまでクラスターの起動が進んでいるかを確認できる方がいいですよね。
[student@workstation ~]$ ssh lab@utility
[lab@utility ~]$ ./wait.sh
![](https://assets.st-note.com/img/1711261203560-WKY9129VRr.png?width=1200)
wait.shの実行
仮想マシン起動直後にwait.shを実行した場合は、APIサーバーが起動するまで、Waiting for API…というログが繰り返し出力されます。
[lab@utility ~]$ ./wait.sh
Waiting for OpenShift cluster start...
Waiting for API ...
Waiting for API ...
Waiting for API ...
Waiting for API ...
この状態でutilityサーバー上に別のターミナルを開きoc コマンドを実行してもAPIサーバーに接続できません。ocコマンドは、APIサーバーに対してHTTPリクエストを送信するからです。
[lab@utility ~]$ oc get clusterversion
Unable to connect to the server: EOF
APIの起動
wait.shのログにAPI is upと出力されたらAPIサーバーが起動したことを示していますので、さっそくocコマンドを試してみましょう。
まだこの時点でクラスターのすべての機能は完全に起動し終わっていませんが、oc コマンドを使い始めることはできるのです。
[lab@utility ~]$ ./wait.sh
Waiting for OpenShift cluster start...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
parse error: Invalid numeric literal at line 1, column 4
Waiting for API...
API is up
Cluster version is 4.14.0
oc loginをしなくともocコマンドが使えているのは、ocコマンドはデフォルトで~/.kube/configに書かれた設定を参照するためです。
oc get clusterversionコマンドでクラスターのバージョンを返します。
[lab@utility ~]$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.14.0 True False 103d Cluster version is 4.14.0
引き続き、以下のocコマンドを実行してみましょう。コマンドの意味は、RHLSの2.5 OpenShift クラスターの正常性の評価を確認してください。
[lab@utility ~]$ oc get node
NAME STATUS ROLES AGE VERSION
master01 Ready control-plane,master,worker 103d v1.27.6+f67aeb3
[lab@utility ~]$ oc adm top node
error: Metrics API not available
[lab@utility ~]$ oc describe node master01
Name: master01
Roles: control-plane,master,worker
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=master01
<略>
ここで oc get podをすることも可能ですので、クラスター内部の状態をいろいろと調べてみましょう。例えば、以下のようなコマンドをutiltityサーバーのターミナルで打ってみてください。またPodリソースが存在しなかったり、存在していたとしてもPodがREADYでなかったりするかもしれません。
oc get pod -n openshift-authentication
oc get pod -n openshift-ingress
oc get pod -n openshift-kube-apiserver
クラスターの状態監視
OpenShiftクラスターの内部サービスは、複数のCluster Operatorと呼ばれるものによって管理されています(api-server, dns, etcd, ingress, image-registry, monitoring,などの内部サービスはすべてOperatorで管理されています)。これらのCluster Operatorがすべて起動完了しなければクラスターとしては正常に動作できません。
utilityサーバー上で新しいターミナルを開きCluster Operatorを表示してみましょう。oc get clusteroperators でCluster Operatorの一覧を表形式で表示できます(oc get coと略すことも可能です)。継続的にCluster Operatorの状態を観察するために、watch oc get co を実行して定期的に表示を更新します。
[lab@utility ~]$ watch oc get co
Every 2.0s: oc get co utility: Sun Mar 24 06:42:49 2024
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.14.0 True False False 7h25m
baremetal 4.14.0 True False False 102d
cloud-controller-manager 4.14.0 True False False 102d
cloud-credential 4.14.0 True False False 102d
cluster-autoscaler 4.14.0 True False False 102d
config-operator 4.14.0 True False False 102d
console 4.14.0 True False False 102d
control-plane-machine-set 4.14.0 True False False 102d
csi-snapshot-controller 4.14.0 True False False 102d
dns 4.14.0 True False False 5h1m
etcd 4.14.0 True False False 102d
image-registry 4.14.0 True False False 102d
ingress 4.14.0 True False False 102d
insights 4.14.0 True False False 102d
kube-apiserver 4.14.0 True False False 102d
kube-controller-manager 4.14.0 True False False 102d
kube-scheduler 4.14.0 True False False 102d
kube-storage-version-migrator 4.14.0 True False False 102d
machine-api 4.14.0 True False False 102d
machine-approver 4.14.0 True False False 102d
machine-config 4.14.0 True False False 102d
marketplace 4.14.0 True False False 102d
monitoring 4.14.0 True False False 7h29m
network 4.14.0 True False False 102d
node-tuning 4.14.0 True False False 102d
openshift-apiserver 4.14.0 True False False 80d
openshift-controller-manager 4.14.0 True False False 80d
openshift-samples 4.14.0 True False False 80d
operator-lifecycle-manager 4.14.0 True False False 102d
operator-lifecycle-manager-catalog 4.14.0 True False False 102d
operator-lifecycle-manager-packageserver 4.14.0 True False False 9s
service-ca 4.14.0 True False False 102d
storage 4.14.0 True False False 102d 4.14.0 True False False 102d
上のCluster Operatorの表の表示結果は一見すべての起動が終わっているように見えますが、実際にはまだ重要なOperatorの起動は終わっていません。
認証サービス起動前の状態
wait.shのログを観察していると、API起動後にWaiting for authentication...のログが繰り返し出力されていることに気づきます。認証サービスが起動するまでoc loginやoc whoamiのようなコマンドは機能しません。
[lab@utility ~]$ oc whoami
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get users.user.openshift.io ~)
[lab@utility ~]$ ./wait.sh
Waiting for OpenShift cluster start...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
parse error: Invalid numeric literal at line 1, column 4
Waiting for API...
API is up
Cluster version is 4.14.0
Router is up
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
さらに、このあたりでCluster Operatorの一覧を確認すると、ingressやmonitoringのPROGRESSING列がTrueになることが確認できます。下のリストを横にスクロールしてMESSAGE列を確認してください。
[lab@utility ~]$ oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.14.0 True False False 81d
baremetal 4.14.0 True False False 103d
cloud-controller-manager 4.14.0 True False False 103d
cloud-credential 4.14.0 True False False 103d
cluster-autoscaler 4.14.0 True False False 103d
config-operator 4.14.0 True False False 103d
console 4.14.0 True False False 103d
control-plane-machine-set 4.14.0 True False False 103d
csi-snapshot-controller 4.14.0 True False False 103d
dns 4.14.0 True False False 78s
etcd 4.14.0 True False False 103d
image-registry 4.14.0 True False False 103d
ingress 4.14.0 True True False 103d ingresscontroller "default" is progressing: IngressControllerProgressing: One or more status conditions indicate progressing: DeploymentRollingOut=True (DeploymentRollingOut: Waiting for router deployment rollout to finish: 0 of 1 updated replica(s) are available......
insights 4.14.0 True False False 103d
kube-apiserver 4.14.0 True False False 103d
kube-controller-manager 4.14.0 True False False 103d
kube-scheduler 4.14.0 True False False 103d
kube-storage-version-migrator 4.14.0 True False False 103d
machine-api 4.14.0 True False False 103d
machine-approver 4.14.0 True False False 103d
machine-config 4.14.0 True False False 103d
marketplace 4.14.0 True False False 103d
monitoring 4.14.0 False True True 36s deleting Thanos Ruler Route failed: the server is currently unable to handle the request (delete routes.route.openshift.io thanos-ruler), reconciling Alertmanager Route failed: retrieving Route object failed: the server is currently unable to handle the request (get routes.route.openshift.io alertmanager-main), reconciling Thanos Querier Route failed: retrieving Route object failed: the server is currently unable to handle the request (get routes.route.openshift.io thanos-querier), deleting UserWorkload federate Route failed: the server is currently unable to handle the request (delete routes.route.openshift.io federate), failed to create prometheus adapter secret: value not found in extension api server authentication configmap: key requestheader-client-ca-file is missing, reconciling Prometheus API Route failed: retrieving Route object failed: the server is currently unable to handle the request (get routes.route.openshift.io prometheus-k8s)
network 4.14.0 True False False 103d
node-tuning 4.14.0 True False False 103d
openshift-apiserver 4.14.0 True False False 81d
openshift-controller-manager 4.14.0 True False False 81d
openshift-samples 4.14.0 True False False 81d
operator-lifecycle-manager 4.14.0 True False False 103d
operator-lifecycle-manager-catalog 4.14.0 True False False 103d
operator-lifecycle-manager-packageserver 4.14.0 False True False 89s ClusterServiceVersion openshift-operator-lifecycle-manager/packageserver observed in phase Failed with reason: ComponentUnhealthy, message: apiServices not installed
service-ca 4.14.0 True False False 103d
PROGRESSING列がTrueというのはCluster Operatorが更新中であることを意味しています。この時点ではまだクラスターの起動は完了しておらず、機能は安定していません。
認証サービス起動後にできること
wait.shのログにAuthentication is readyのメッセージが出力されたら、認証サービスが利用可能になります。
[lab@utility ~]$ ./wait.sh
Waiting for OpenShift cluster start...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
parse error: Invalid numeric literal at line 1, column 4
Waiting for API...
API is up
Cluster version is 4.14.0
Router is up
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Authentication is ready
Authentication is readyにまで至ると、ocコマンドでさまざまなことが可能になります。やっとクラスター起動の終盤にさしかかってきました。
[lab@utility ~]$ oc whoami
system:admin
[lab@utility ~]$ oc whoami --show-console
https://console-openshift-console.apps.ocp4.example.com
[lab@utility ~]$ oc login -u admin -p redhatocp https://api.ocp4.example.com:6443
Login successful.
You have access to 71 projects, the list has been suppressed. You can list all projects with 'oc projects'
Using project "default".
wait.shの終了
wait.shのスクリプトは指定された条件を満たすまで内部でループしているため、API is upやCluster version is 4.14.0というログが何回か表示されています。クラスターの起動の条件が満たされると最後に[OK] OpenShift cluster ready.と表示されて、wait.sh実行が終了します。
[lab@utility ~]$ ./wait.sh
Waiting for OpenShift cluster start...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
Waiting for API...
parse error: Invalid numeric literal at line 1, column 4
Waiting for API...
API is up
Cluster version is 4.14.0
Router is up
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...
Authentication is ready
Waiting for the ingress operator to be ready...
Waiting for the ingress operator to be ready...
Waiting for the ingress operator to be ready...
The ingress operator is ready
The kube-apiserver operator is ready
Machine Config Operator changes applied
API is up
Cluster version is 4.14.0
Router is up
Authentication is ready
The ingress operator is ready
The kube-apiserver operator is ready
Machine Config Operator changes applied
API is up
Cluster version is 4.14.0
Router is up
Authentication is ready
The ingress operator is ready
The kube-apiserver operator is ready
Machine Config Operator changes applied
[OK] OpenShift cluster ready.
最後に、重要なPodについてoc get podを実行して状態を確認してみましょう。これらのPodのSTATUSがRunningで、かつREADYですべてのコンテナーが起動していることがわかります。
[lab@utility ~]$ oc get pod -n openshift-authentication
NAME READY STATUS RESTARTS AGE
oauth-openshift-854bd4b95f-m55hm 1/1 Running 2 81d
[lab@utility ~]$ oc get pod -n openshift-ingress
NAME READY STATUS RESTARTS AGE
router-default-56cf89f99f-b4fpv 1/1 Running 9 (107s ago) 103d
[lab@utility ~]$ oc get pod -n openshift-kube-apiserver
NAME READY STATUS RESTARTS AGE
installer-10-master01 0/1 Completed 0 35m
installer-11-master01 0/1 Completed 0 33m
installer-2-retry-1-master01 0/1 Completed 0 103d
installer-4-master01 0/1 Completed 0 103d
installer-5-master01 0/1 Completed 0 103d
installer-6-master01 0/1 Completed 0 103d
installer-7-master01 0/1 Completed 0 103d
installer-9-master01 0/1 Completed 0 81d
kube-apiserver-master01 5/5 Running 6 32m
さいごに
OpenShiftコースの演習においてlab start XXXXのようなstartスクリプトを実行すると、まずクラスターが起動しているかどうかの確認を行います。仮想マシンを生成、起動した直後にstartスクリプトを実行すると、クラスターの準備ができるまでstartスクリプトは待ち状態になり、すぐに演習を開始することができません(クラスターが起動してしまえばstartスクリプトはすぐに応答を返します)。
この記事では、演習が実行可能になるまでの間、utilityサーバー上でwait.shスクリプトを実行することによって、OpenShiftクラスターの起動プロセスを可視化し、さらにクラスターの内部状態をocコマンドで調べる方法を紹介しました。クラスターが起動している過程の状態では、すべての機能が完全に動作するわけではありません。Podがまだ起動していないサービスは当然利用できないです。
このようなクラスターが起動している途中のプロセスというのは、DO180, DO280, DO380などの演習では体験できないものです(つまり、これらのコースではOpenShiftクラスターは正常であることが前提に演習が準備されています)。ぜひ演習の準備が整うまでの待ち時間にwait.shを起動し、watch oc get coでCluster Operatorの動きを監視しながら、ocコマンドを使ってクラスターの準備状況を確認してみてください。
この記事が気に入ったらサポートをしてみませんか?