Red Hat Learning Subscription (RHLS): ④OpenShiftの起動を待つ間の暇つぶし


はじめに

OpenShiftの演習を開始するために仮想マシンを起動するのには2~3分程度の時間がかかります。さらにworkstationにログインしてターミナルでラボのstartスクリプトを入力してから数分待たされます。OpenShiftは電源を入れたままの状態で常に動作し続けることが運用の前提です。RHLSのように仮想マシンの起動から始める場合、OpenShiftクラスターの起動をしなければならないので準備に時間がかかるのは仕方ないことです。この記事ではクラスターの起動を待っている間に私が暇つぶしにやっているocコマンドをいくつか紹介します。それらのコマンドによってクラスターの起動状況を確認することができます。

OpenShiftの演習開始まで

この記事ではDO180 OCP4.14の演習環境を例にガイド付き演習を実施してみたいと思います。まず演習環境で [作成] または [開始] ボタンを押して仮想マシン一式を起動します。

すべての仮想マシンがアクティブになったところで、workstationの [コンソールを開く] を押してRHELの環境を開きます。

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 

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コマンドを使ってクラスターの準備状況を確認してみてください。



この記事が気に入ったらサポートをしてみませんか?