見出し画像

OpenShift 4をアップグレードする際に気を付けること

こんにちは。SHIFTからRGA(リアルグローブ・オートメーティッド)に出向中の水谷です。

私が出向しているRGAはRed Hatのパートナー企業の1つであり、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: false

MCP(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が1つでも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