OpenShift 4 クラスターアップグレードの事前チェック要件
Environment
- Red Hat OpenShift Container Platform (RHOCP)
- 4
- Red Hat OpenShift Service on AWS (ROSA)
- 4
- Red Hat OpenShift Dedicated (OSD)
- 4
- Azure Red Hat OpenShift (ARO)
- 4
Issue
- OpenShift Cluster をアップグレードする前の初期要件は何ですか?
- クラスターオブジェクトの健全性を確認するにはどうすればよいですか?
- クラスターのリソース割り当てを確認するにはどうすればよいですか?
- Pod のステータスと実行状態を確認するにはどうすればよいですか?
- その他の事前チェック。
Resolution
クラスターをアップグレードする前に、クラスターが正常に実行されており、安全にアップグレードできることを確認するために、以下のチェックを行うことを検討してください。
プロアクティブケースの作成
ARO の標準ガイドライン
以下は、ARO クラスターのアップグレードに関する標準的なプロアクティブチケットを作成するために必要な前提条件です。
- How to open a PROACTIVE case for ARO Clusters に基づく、スケジュールされたメンテナンスウィンドウの日付/時刻 (タイムゾーンを含む)。
- アップグレード先バージョンの完全なバージョン番号 (
4.y.z形式)。 - 適切な連絡先情報。
- 標準の must-gather。
-
ARO クラスターの ResourceID とリージョン。以下を使用して取得できます。
Resource ID: $ az aro show -n <cluster_name> -g <resource_group> --subscription <subscription_name> --query id Region: $ az aro show -n <cluster_name> -g <resource_group> --subscription <subscription_name> --query location
OSD/ROSA Classic の標準ガイドライン
以下は、OSD/ROSA Classic クラスターのアップグレードに関する標準的なプロアクティブチケットを作成するために必要な前提条件です。
- How to open a PROACTIVE case for ROSA Classic, ROSA HCP, and OSD Clusters に基づく、スケジュールされたメンテナンスウィンドウの日付/時刻 (タイムゾーンを含む)。
- 適切な連絡先情報。
- アップグレード先バージョンの完全なバージョン番号 (
4.y.z形式)。
ROSA HCP の標準ガイドライン
以下は、ROSA HCP クラスターのアップグレードに関する標準的なプロアクティブチケットを作成するために必要な前提条件です。
- How to open a PROACTIVE case for ROSA Classic, ROSA HCP, and OSD Clusters に基づく、スケジュールされたメンテナンスウィンドウの日付/時刻 (タイムゾーンを含む)。
- 適切な連絡先情報。
- アップグレード先バージョンの完全なバージョン番号 (
4.y.z形式)。 - 標準の must-gather。
OCP の標準ガイドライン
以下は、OCP クラスターのアップグレードに関する標準的なプロアクティブチケットを作成するために必要な前提条件です。
- プロアクティブケースの標準ガイドライン に基づく、スケジュールされたメンテナンスウィンドウの日付/時刻 (タイムゾーンを含む)。
- 適切な連絡先情報。
- アップグレード先バージョンの完全なバージョン番号 (
4.y.z形式)。 - 標準の must-gather。
クラスターの事前チェック
Operator の確認
クラスター上で実行されている Operator のバージョンが、必要な OpenShift バージョンと互換性があるかどうかを確認します。OpenShift で Red Hat がサポートする Operator については、OpenShift Operator Life Cycles および Red Hat OpenShift Container Platform Operator Update Information Checker を参照し、特定の Operator をそれぞれ検索してください。これは、新しい OpenShift マイナーバージョン (4.y.z の y) にアップグレードするときに特に重要です。
重要な注意事項: Red Hat OpenShift Data Foundations (RHODF) がクラスターにインストールされている場合は、RHODF のバージョンが目的の RHOCP バージョンと互換性があるかどうかを確認することに加えて、OpenShift Data Foundations (RHODF) Operator Upgrade Pre-Checks も参照してください。ODF クラスターのステータスが正常でない場合は、ODF ノードの drain (Pod の退避) を実行できないため、OpenShift のアップグレードがハングします。
クラスター更新パスの確認
- Red Hat OpenShift Container Platform Update Path を使用すると、アップグレードに利用できる更新パスを確認できます。
- クラスターのアップグレードが後日に延期された場合は、アップグレード手順を実行する前に 更新パス を再度確認してください。
- 新しく発見されたバグ/問題のパッチを適用できるように、開発エンジニアリング部門の介入により、サポートされているパスが変更されたり、特定のバージョンへのアップグレードがブロックされたりする可能性があります。
- バージョンがブロックされている場合は、更新パス ツールを実行した後の結果に、このブロックが行われている理由の詳細が表示されます。
削除された API の確認
新しい OpenShift マイナーバージョン (4.y.z の y) にアップグレードする場合は、削除された API があるかどうか、およびカスタムアプリケーションがまだそれを使用しているかどうかを確認する必要があります。カスタムアプリケーションが使用している API が、目的のマイナーバージョンで削除される場合は、アップグレード後に問題が発生しないように、それらのアプリケーションを更新する必要があります。詳細は、Navigating Kubernetes API deprecations and removals を参照してください。
OpenShift 4.14 にアップグレードする場合
リクエスト内の重複したヘッダーの確認
OpenShift 4.14 にアップグレードすると、HAProxy が以前のバージョン 2.2 から 4.14 の 2.6 にアップグレードされます。このアップグレードには、重複したヘッダーが検出された場合の HAProxy の新しい動作が含まれます。この動作は、Pods returns a 502 or 400 error when accessing via the application route after upgrading the RHOCP cluster to version 4.14 で説明されています。この記事には、重複したヘッダーの使用をアップグレード前に特定するための情報が記載されています。
OpenShift 4.15 にアップグレードする場合
ServiceAccount トークンシークレットの使用状況の確認
OpenShift 4.15 にアップグレードすると、内部イメージレジストリーが Removed として設定されている場合、以前のリリースで自動的に作成された ServiceAccount トークンシークレットが削除されます。OpenShift 4.15 にアップグレードする前に、ServiceAccount token secrets missing after upgrading to OpenShift 4.15 を参照し、関連情報を確認してください。
クラスターで IPsec が設定されているかどうかの確認
IPsec が有効なクラスターを OpenShift 4.15 にアップグレードすると、既知のバグが発生します。upgrading Full IPsec cluster from 4.14 to 4.15 has broken network communication in some nodes を参照し、この問題の関連情報を確認してください。また、network.operator cluster リソースで IPsec が有効になっているかどうかを確認してください。
$ oc get network.operator cluster -o yaml
[...]
ipsecConfig:
mode: Full
[...]
vSphere にインストールされたクラスターをアップグレードする場合
Known Issues with OpenShift 4.12 to 4.13 or 4.13 to 4.14 vSphere CSI Storage Migration を確認してください。
クラスターオブジェクトの確認
-
ノードのステータスをチェックして、どのノードも
NotReady状態またはSchedulingDisabled状態になっていないことを確認します。$ oc get nodes NAME STATUS ROLES AGE VERSION master-0.lab.example.com Ready master 3d18h v1.23.12+8a6bfe4 master-1.lab.example.com Ready master 3d18h v1.23.12+8a6bfe4 master-2.lab.example.com Ready master 3d18h v1.23.12+8a6bfe4 worker-0.lab.example.com Ready worker 3d17h v1.23.12+8a6bfe4 worker-1.lab.example.com Ready worker 3d17h v1.23.12+8a6bfe4 worker-2.lab.example.com Ready worker 3d17h v1.23.12+8a6bfe4 -
クラスター Operator のステータスをチェックして、すべてのクラスター Operator が
Availableであり、Degraded状態ではないことを確認します。$ oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE [...] etcd 4.10.54 True False False 3d18h image-registry 4.10.54 True False False 3d9h ingress 4.10.54 True False False 3d17h insights 4.10.54 True False False 3d18h kube-apiserver 4.10.54 True False False 3d18h kube-controller-manager 4.10.54 True False False 3d18h kube-scheduler 4.10.54 True False False 3d18h kube-storage-version-migrator 4.10.54 True False False 2d3h machine-api 4.10.54 True False False 3d18h machine-approver 4.10.54 True False False 3d18h machine-config 4.10.54 True False False 2d2h [...] -
PVとPVCの健全性をチェックして、次のことを確認します。- すべての PV と PVC がマウントされている。
- アンマウントされている PV および PVC がない。
terminating状態で停止している PV および PVC がない。- 異常な設定が存在しない。
$ oc get pv,pvc -A NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE [...] openshift-compliance persistentvolumeclaim/ocp4-cis Active 6d10h openshift-compliance persistentvolumeclaim/ocp4-cis-node-master Active 6d10h openshift-compliance persistentvolumeclaim/ocp4-cis-node-worker Active 6d10h [...] -
machineConfigPoolsに関するチェック:-
クラスター上のすべてのノードが、少なくとも 1 つの
machineConfigPoolに関連付けられていることを確認します。これを実現するには、既存のいずれかのmachineConfigPoolsにおいてnodeSelectorとして指定されているラベルが、すべてのノードに適用されている必要があります。クラスターのアップグレードを開始すると、新しくレンダリングされた設定が作成されるため、machineConfigPoolsは新しくレンダリングされた設定をノードに適用します。ノードがmachineConfigPoolに関連付けられていない場合、MachineConfigController がこのノードの更新を回避します。ノードがmachineConfigPoolに関連付けられると、その設定が、対応するレンダリングされた設定と同期されます。 -
すべての
machineConfigPoolsにpaused: falseパラメーターが設定されていることを確認します。machineConfigPoolが一時停止状態の場合、このmachineConfigPoolに関連付けられているノードは更新されません。詳細は、Red Hat ソリューション MachineConfigPools are paused, preventing the Machine Config Operator to push out updates in OpenShift 4. を参照してください。 -
machineConfigPoolsの健全性をチェックし、MACHINECOUNTがREADYMACHINECOUNTと等しいこと、UPDATEDMACHINECOUNTおよびDEGRADEDMACHINECOUNTで停止しているマシンがないことを確認します。
$ oc get mcp NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX True False False 3 3 3 0 4d7h worker rendered-worker-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX True False False 3 3 3 0 4d7h -
クラスターノードの割り当ての確認
リソースの割り当てを確認するには、次の 2 つの方法があります。
$ oc describe の使用
$ oc describe node worker-0.lab.example.com
[...]
Conditions: <====
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
MemoryPressure False Wed, 14 Jun 2023 15:24:09 -0400 Tue, 13 Jun 2023 02:59:26 -0400 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Wed, 14 Jun 2023 15:24:09 -0400 Tue, 13 Jun 2023 02:59:26 -0400 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Wed, 14 Jun 2023 15:24:09 -0400 Tue, 13 Jun 2023 02:59:26 -0400 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Wed, 14 Jun 2023 15:24:09 -0400 Tue, 13 Jun 2023 02:59:36 -0400 KubeletReady kubelet is posting ready status
Capacity: <====
cpu: 4
ephemeral-storage: 41407468Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 8146240Ki
pods: 250
Allocatable: <====
cpu: 3500m
ephemeral-storage: 37087380622
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 6995264Ki
pods: 250
System Info: <====
Machine ID: bc21e1755a9142238b04129b97e118c0
System UUID: bc21e175-5a91-4223-8b04-129b97e118c0
Boot ID: b0520f6a-09e7-4bf8-8e0c-9aa749fd14bc
Kernel Version: 4.18.0-372.58.1.el8_6.x86_64
OS Image: Red Hat Enterprise Linux CoreOS 412.86.202305230130-0 (Ootpa)
Operating System: linux
Architecture: amd64
Container Runtime Version: cri-o://1.25.3-4.rhaos4.12.git76ceef4.el8
Kubelet Version: v1.25.8+37a9a08
Kube-Proxy Version: v1.25.8+37a9a08
Non-terminated Pods: (33 in total) <====
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
new-test httpd-675fd5bfdd-9s4pr 0 (0%) 0 (0%) 0 (0%) 0 (0%) 34h
openshift-cluster-node-tuning-operator tuned-wfrxw 10m (0%) 0 (0%) 50Mi (0%) 0 (0%) 37h
openshift-cnv cdi-operator-6ffbc46886-rfb97 10m (0%) 0 (0%) 150Mi (2%) 0 (0%) 27h
openshift-cnv cluster-network-addons-operator-675b769f6f-954wl 60m (1%) 0 (0%) 50Mi (0%) 0 (0%) 27h
openshift-cnv hco-operator-7f8c48598d-c6vh5 10m (0%) 0 (0%) 96Mi (1%) 0 (0%) 27h
openshift-cnv hco-webhook-fc6b4c4b5-7zrdb 5m (0%) 0 (0%) 48Mi (0%) 0 (0%) 27h
openshift-cnv hostpath-provisioner-operator-6b6bc8bf8-6mxkp 10m (0%) 0 (0%) 150Mi (2%) 0 (0%) 27h
openshift-cnv hyperconverged-cluster-cli-download-7f5844cb77-ftjbz 10m (0%) 0 (0%) 96Mi (1%) 0 (0%) 27h
Allocated resources: <====
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 959m (27%) 1700m (48%)
memory 2968Mi (43%) 1800Mi (26%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none> <====
[...]
次の方法を使用すると、一度にすべてのノードの詳細情報を取得できます。
$ oc describe nodes > nodes_description.yaml
YAML 出力の使用
$ oc get node worker.lab.example.com -oyaml
すべてのノードのリソース割り当てを一度に取得するには、以下のコマンドを使用できます。
$ for i in $(oc get nodes | awk '{print $1}'); do echo "==== $i ====";oc describe node $i 2> /dev/null | grep -A10 Allocated; echo; done
[...]
==== master-0.lab.example.com ====
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1970m (56%) 400m (11%)
memory 8022Mi (53%) 900Mi (6%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none>
==== master-1.lab.example.com ====
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1935m (55%) 0 (0%)
memory 8357Mi (56%) 0 (0%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none>
==== master-2.lab.example.com ====
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1579m (45%) 0 (0%)
memory 6282Mi (42%) 0 (0%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none>
[...]
リクエスト/制限 および ノードのオーバーコミット に関する詳細は、以下のドキュメントを参照してください。
Pod の健全性とステータスの確認
-
Running、Completed、またはSucceeded以外のステータスになっている Pod がないか確認します。$ oc get pods --all-namespaces | egrep -v 'Running | Completed | Succeeded' -
namespace 内のすべての Pod のステータスを確認します。
$ for i in `oc adm top pods -A | awk '{print $1}' | uniq`; do echo $i; oc get pods -owide -n $i; done ###[Using grep against node name will limit the search to get more accurate results] $ for i in `oc adm top pods -A | awk '{print $1}' | uniq`; do echo $i; oc get pods -owide -n $i | grep <node_name>; echo '---------------------'; done -
次のコマンドを使用して Pod ログを確認します。
$ oc logs pod/<pod_name> -n <namespace_name> -
特定のコンテナーからログを取得するには、
-cパラメーターを使用します。$ oc logs pod/<pod_name> -c <conatiner_name> -n <namespace_name>
その他の事前チェック:
- etcd クラスターの健全性 を確認します。
- Network Observability を使用してネットワークの健全性を確認します。
-
保留中の証明書署名要求を確認します。
$ oc get csr -
Pod Disruption Budget に関して、アップグレード中にノードの drain プロセスをブロックする可能性のある Pod があるかどうかを確認するために、以下のコマンド出力が必要です。通常、ノードが適切に drain できるように、許容される中断は 1 に設定されます。これは must-gather によって適切に収集されないため、この出力を手動で確認する必要があります。
$ oc get pdb -A -
Web Console -> Observe -> Alerting からアラートマネージャーで発生中のアラートを確認し、Warning または Critical アラートが発生していないこと、および既存の Info アラートが確認済みのものであることを確認します。
-
すべての namespace で Warning イベントを探し、問題となる可能性があるものがないか確認します。
$ oc get events -A --field-selector type=Warning --sort-by=".lastTimestamp" -
アップグレードする前に、クラスターで実行されているサードパーティー製ソフトウェアが、目的の OpenShift バージョンと互換性があることを確認します。Red Hat は、どのバージョンの OCP ともサードパーティーの互換性を検証していないことに注意してください。 これに関する責任はベンダーが単独で負います。 詳細は、サードパーティーのサポート に関するドキュメントを確認してください。
-
対象の OpenShift バージョンのリリースノートを参照し、アプリケーションに影響を与える可能性のあるプラットフォームの変更点がないか確認します。これにより、アップグレードを進める前に潜在的なリスクを評価し、必要な調整を実施できます。
Root Cause
Red Hat OpenShift Container Platform 4 のアップグレードには、複数の異なるコンポーネントのアップグレードが伴います。アップグレードを開始する前に、クラスターの全体的なステータスと、追加の Operator およびサードパーティーコンポーネントの互換性を確認する必要があります。
Diagnostic Steps
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments