OpenShift 4をアップグレードする際に気を付けること
こんにちは。SHIFTからRGA（リアルグローブ・オートメーティッド）に出向中の水谷です。
私が出向しているRGAはRed Hatのパートナー企業の１つであり、Red HatのコンテナオーケストレーションツールであるOpenShiftを使ったお仕事もさせていただいています。
OpenShiftと言えば、つい先日（2022/3/10）新しいEUS（Extended Update Support）バージョンである、4.10がリリースされました。多数の新機能やバグフィックスが行われていますので、アップグレードを検討されている運用者の方もいるかと思います。4.10へのアップグレードでなくても、今のマイナーバージョン内でのアップグレード（主にバグ修正）を行うケースも少なくないと思います。そこで、OpenShift 4.x環境のアップグレードを行う際にチェックするべき点などをまとめてみたいと思います。
アップグレード前の確認事項
アップグレード前に以下の項目を確認しましょう。
クラスターおよびクライアントのバージョン
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.9.0 True False 62m Cluster version is 4.9.0
$ oc version
Client Version: 4.9.0
Server Version: 4.9.0
Kubernetes Version: v1.22.0-rc.0+894a78bまずは、現在のバージョンの確認ですね。"oc version"コマンドで、Client（ocコマンド）のバージョンと、Server側のバージョンの両方が表示されます。
Clientバージョンはアップグレード後のバージョンに合わせることが推奨されています。低い場合は以下のロケーションなどからダウンロードし、アップグレードしておくとよいでしょう。
https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/
https://console.redhat.com/openshift/downloads
現在のアップグレードチャンネルの確認
$ oc get clusterversion -o yaml
apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
kind: ClusterVersion
metadata:
creationTimestamp: "2022-03-17T23:44:16Z"
generation: 2
name: version
resourceVersion: "117716"
uid: 6d9a1f92-6bf6-40aa-8316-a21aa4f6d83a
spec:
channel: stable-4.9
clusterID: 73074d91-e7b9-41a8-8576-cd59b55317a0
..."spec:"の下の"channel:"に表示されているのが、現在のアップグレードチャンネルです。OpenShiftでは以下の4つのアップグレードチャンネルが存在し、必要に応じて選択できます。
・EUSチャンネル： EUS リリース間の検証済みのアップグレードパスに沿ったアップグレードが提供されるチャンネル（OpenShift 4.8以降の偶数マイナーバージョン）
・Stableチャンネル： 安定性が確認されたアップデートが含まれるアップグレードパス
・Fastチャンネル： テスト済みのErrata修正がすぐに反映されるアップグレードパス
・Candidateチャンネル： リリース候補となるバージョンが適用できるアップグレードパス（新機能の早期テストなどに使います）
アップグレードチャンネルの変更はoc patchコマンドで行います。以下のページを参照してください。
https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.9/html/updating_clusters/update-upgrading-cli_updating-cluster-cli
Paused状態のmcpがないことの確認
$ oc get mcp -o yaml | grep -i paused
paused: false
paused: falseMCP(Machine Config Pool)がpaused: true に設定されていると、アップグレード後にクラスターが再起動しないためトラブルになるので、確認しておきます。
もしtrueになっている場合は、oc edit mcp コマンドを実行するなどの方法でfalseに変更します。
Operator バージョンの確認
$ oc get clusteroperator
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
authentication 4.9.0 True False False 6d5h
baremetal 4.9.0 True False False 6d7h
cloud-controller-manager 4.9.0 True False False 6d7h
cloud-credential 4.9.0 True False False 6d7h
cluster-autoscaler 4.9.0 True False False 6d7h
config-operator 4.9.0 True False False 6d7h
console 4.9.0 True False False 6d6h
csi-snapshot-controller 4.9.0 True False False 6d7h
dns 4.9.0 True False False 6d7h
etcd 4.9.0 True False False 6d7h
image-registry 4.9.0 True False False 6d7h
ingress 4.9.0 True False False 6d7h
insights 4.9.0 True False False 6d7h
kube-apiserver 4.9.0 True False False 6d7h
...すべてのOperatorのAVAILABLE欄がTrueである（PROGRESSINGとDEGRADEDがFalse）ことを確認します。
AVAILABLEがTrueでないOperatorがある場合は、Operatorのアップグレードが正常にできない可能性がありますので、アップグレード前に問題を調査して解決しておきましょう。
希望するアップグレード先のバージョンが表示されることを確認
"oc adm upgrade"コマンドを実行すると、現在選択されているアップグレードチャンネルにおけるアップグレード可能なバージョンが表示されますので、アップグレード先のバージョンが表示されることを確認します。
$ oc adm upgrade
Cluster version is 4.8.2
Updates:
VERSION IMAGE
4.9.4 quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
4.9.5 quay.io/openshift-release-dev/ocp-release@sha256:386f4e08c48d01e0c73d294a88bb64fac3284d1d16a5b8938deb3b8699825a88
4.9.6 quay.io/openshift-release-dev/ocp-release@sha256:c9f58ccb8a9085df4eeb23e21ca201d4c7d39bc434786d58a55381e13215a199
4.9.7 quay.io/openshift-release-dev/ocp-release@sha256:5c55be02e32e688ec5a404858a08cf533ba15b50b6f0e028089635b47db5866e
4.9.8 quay.io/openshift-release-dev/ocp-release@sha256:c91c0faf7ae3c480724a935b3dab7e5f49aae19d195b12f3a4ae38f8440ea96b
4.9.9 quay.io/openshift-release-dev/ocp-release@sha256:dc6d4d8b2f9264c0037ed0222285f19512f112cc85a355b14a66bd6b910a4940
4.9.10 quay.io/openshift-release-dev/ocp-release@sha256:e1853d68d8ff093ec353ca7078b6b6df1533729688bb016b8208263ee7423f66
4.9.11 quay.io/openshift-release-dev/ocp-release@sha256:0f72e150329db15279a1aeda1286c9495258a4892bc5bf1bf5bb89942cd432de
4.9.12 quay.io/openshift-release-dev/ocp-release@sha256:dd71b3cd08ce1e859e0e740a585827c9caa1341819d1121d92879873a127f5e2
4.9.13 quay.io/openshift-release-dev/ocp-release@sha256:0ff5adc1199c77c2814c2030642109b24039087a2621b19e553a2315bcdc4801
4.9.15 quay.io/openshift-release-dev/ocp-release@sha256:bb1987fb718f81fb30bec4e0e1cd5772945269b77006576b02546cf84c77498e
4.9.17 quay.io/openshift-release-dev/ocp-release@sha256:7b67b0cb5ab016528b8efdb6130c000398efc58f55e2226f3cf4e3be59c78443
...Nodeのステータス
全ての Node のステータスが Ready、全ての Pod が Running であることの確認します。
もしNodeが１つでもNotReadyになっている場合は、"oc debug node/<node name>"などのコマンドでノードの中を見て問題を調査し、Ready状態にしましょう。
$ oc get nodes
NAME STATUS ROLES
ip-10-0-133-16.us-east-2.compute.internal Ready worker 6d7h v1.22.0-rc.0+894a78b
ip-10-0-136-231.us-east-2.compute.internal Ready master 6d7h v1.22.0-rc.0+894a78b
ip-10-0-142-116.us-east-2.compute.internal Ready master 6d7h v1.22.0-rc.0+894a78b
...
etcdのバックアップ
etcdがバックアップされていることを確認します。定期バックアップなどをされていない場合は以下の手順でバックアップを実施しましょう。
コントロールプレーンノードのデバッグセッションを開始します。
$ oc debug node/<node_name>ルートディレクトリーをホストに切り替えます。
sh-4.2# chroot /hostクラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。
etcd-snapshot-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。
sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backupアップグレードとアップグレード後の確認事項
アップグレード自体は"oc adm upgrade --to=<version>"の1コマンドで開始できますので、説明も不要でしょう。
今回は以下のコマンドで4.9.0から4.9.23にアップグレードしてみます。
$ oc adm upgrade --to=4.9.23アップグレード中に"oc get clusterversion"を実行すると、以下のように進捗が確認できます。
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.9.0 True True 51s Working towards 4.9.23: 71 of 738 done (9% complete)アップグレードが完了すると以下のような表示に変わります。なお、環境にもよりますが、完了までに1時間程度はかかります。
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.9.23 True False 96m Cluster version is 4.9.23その後、上記アップグレード前に確認した項目と同じ項目を再度確認していきます。
・oc get version
・oc get clusteroperator
・oc get nodes
なお、"oc get clusterversion -o yaml"を実行すると、下の方にアップグレード履歴が表示されますので、こちらも念のため確認しておきましょう。
$ oc get clusterversion -o yaml
history:
- completionTime: "2022-03-24T22:26:43Z"
image: quay.io/openshift-release-dev/ocp-release@sha256:1c13f0926c37c122eb5c86afd754c007f38977c8fc32d7da090490f556945afd
startedTime: "2022-03-24T21:17:23Z"
state: Completed
verified: true
version: 4.9.23
- completionTime: "2022-03-24T19:22:38Z"
image: quay.io/openshift-release-dev/ocp-release@sha256:d262a12de33125907e0b75a5ea34301dd27c4a6bde8295f6b922411f07623e61
startedTime: "2022-03-24T18:56:47Z"
state: Completed
verified: false
version: 4.9.0その他関連事項
アップグレードの中止
基本的にアップグレードの中止はできませんのでご注意ください。なお、ダウンロードフェーズの場合のみ以下のコマンドで中止できます
$ oc adm upgrade --clearアップグレード進捗の監視
最後にTipsとして、OCバージョン、クラスタバージョン、クラスターオペレーター、ノードなどをまとめて監視する（これだけ見ておけば良いんじゃない？的な）便利なコマンドを書いておきます。
$ watch -n10 "oc version && echo && oc get clusterversion && echo && oc get co && echo && oc get nodes -o wide"OpenShiftのアップグレードは失敗すると復旧に時間がかかりますので、しっかり確認しながら行うのが良いかと思います。もし本記事が参考になれば幸いです。
――――――――――――――――――――――――――――――――――
執筆者プロフィール：水谷 裕一
大手外資系IT企業で15年間テストエンジニアとして、多数のプロジェクトでテストの自動化作業を経験。その後画像処理系ベンチャーを経てSHIFTに自動化エンジニアとして入社。
SHIFTでは、テストの自動化案件を2件こなした後、株式会社リアルグローブ・オートメーティッド（RGA）に出向中。RGAでは副社長という立場でありながら、エンジニアとしてAnsibleやOpenshiftに関する案件も担当。また、Ansibleの社内教育や、外部セミナー講師も行っている。
最近の趣味は電動キックボードでの散歩。
【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！
お問合せは以下の窓口までお願いいたします。
【お問い合わせ窓口】
代表窓口：info@rg-automated.jp
URL：https://rg-automated.jp
