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
クラスターをアップグレードする前に、クラスターが正常に実行されており、安全にアップグレードできることを確認するために、以下のチェックを行うことを検討してください。
プロアクティブケースの作成
アップグレードプロアクティブケースの標準ガイドライン
- スケジュールされたメンテナンスウィンドウの日付/時刻 (タイムゾーンを含む)。
- アップグレード元およびアップグレード先のバージョンの完全なバージョン番号 (
4.y.z形式)。 - 適切な連絡先情報。
- 標準の must-gather。
- 特殊な Operator:
- クラスターに Red Hat OpenShift Data Foundation がインストールされている場合は、implications to consider when upgrading OpenShift Data Foundation も参照し、OpenShift Data Foundation 用に別のサポートケースを開いてください。
- クラスターに Red Hat OpenShift Virtualization または MTV がインストールされている場合は、how to open a Proactive case for OpenShift Virtualization/MTV も参照し、OpenShift Virtualization 用に別のサポートケースを開いてください。
具体的なデータ
-
セルフマネージド OpenShift の場合は、how to open a PROACTIVE case for patching or upgrading Red Hat OpenShift Container Platform も参照してください。
-
OSD/ROSA Classic および ROSA HCP については、how to open a PROACTIVE case for ROSA Classic, ROSA HCP, and OSD Clusters も参照してください。
-
ARO については、How to open a PROACTIVE case for ARO Cluster Maintenance and Upgrades も参照し、以下で取得可能な ARO Cluster ResourceID と Region を指定します。
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 - ARO の場合は、https://portal.azure.com/ の
Service Healthをチェックして、アラートが報告されているか確認してください。How to create Azure Service Health alerts for Azure Red Hat OpenShift を参照してください。
クラスターの事前チェック
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) や Red Hat OpenShift Virtualization がインストールされており、それらに問題がある場合は、OpenShift クラスターのアップグレードに影響し、アップグレードがハングする (ノードの drain (Pod の退避) の実行が妨げられるなど) 可能性があることに注意してください。そのため、各 Operator のバージョンが移行先の OpenShift バージョンと互換性があるかを確認することに加えて、それらについては 個別にサポートケースを起票 してください。これらは、OpenShift 本体とは別の Red Hat Support チームが担当しているためです。
- ODF については、implications to consider when upgrading OpenShift Data Foundation および OpenShift Data Foundations (RHODF) Operator Upgrade Pre-Checks を参照してください。
クラスター更新パスの確認
アップグレードに使用可能な 更新パス を 事前に 確認することが重要です。また、アップグレードを開始する 直前 にも (特定のリリースが特定の問題の影響を受けることが判明した場合、アップグレードパスは変更される可能性があることに注意してください)、Red Hat OpenShift Container Platform Update Path 使用して確認することが重要です。
クラスターのアップグレードが遅れている場合、または後日スケジュールされている場合は、アップグレード手順を実行する前に 更新パス を 再度 確認 してください。
- 新しく発見されたバグ/問題のパッチを適用できるように、開発エンジニアリング部門の介入により、サポートされているパスが変更されたり、特定のバージョンへのアップグレードがブロックされたりする可能性があります。
- バージョンブロックがある場合は、上記の更新パスツールを実行した後の結果に、このブロックが発生する理由の詳細が提供されます。
削除された API の確認
新しい OpenShift マイナーバージョン (4.y.z の y) にアップグレードする場合は、削除された API があるかどうか、およびカスタムアプリケーションがまだそれを使用しているかどうかを確認する必要があります。カスタムアプリケーションが使用している API が、目的のマイナーバージョンで削除される場合は、アップグレード後に問題が発生しないように、それらのアプリケーションを更新する必要があります。詳細は、navigating Kubernetes API deprecations and removals を参照してください。
vSphere にインストールされたクラスターを OpenShift 4.13 または 4.14 にアップグレードする場合
known Issues with OpenShift 4.12 to 4.13 or 4.13 to 4.14 vSphere CSI Storage Migration を確認してください。
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 にアップグレードすると、既知のバグが発生します。この問題に関する詳細については、how to upgrade to or between 4.15 releases and above when IPsec is enabled を参照してください。また、network.operator cluster リソースを確認し、IPsec が有効になっているかチェックしてください。
$ oc get network.operator cluster -o yaml
[...]
ipsecConfig:
mode: Full
[...]
OpenShift 4.17 にアップグレードする場合
アップグレードと同時にネットワークプラグインの移行は実行できない
OpenShift SDN は OpenShift 4.17 ではサポートされなくなり、OVN-Kubernetes への移行が必要になります。Is it supported to upgrade the cluster to 4.17 at the same time than performing the network plugin migration? で説明されているように、ネットワークプラグインの移行は、アップグレードと同時に実行しないでください (これは、4.17 より前のバージョンにも該当します)。
LDAP を使用する場合は、TLS 1.3 または ECDHE 暗号をサポートしていることを確認する
使用されている基礎となる Go バージョンにより、TLS 1.3 より前 のハンドシェイクでは、ECDHE をサポートしていない暗号スイートはクライアントからもサーバーからも提供されなくなりました。詳細は、LDAP authentication fails with TLS handshake failure in OpenShift 4.17 or newer を参照してください。
OpenShift 4.18 にアップグレードする場合
API にカスタム証明書を使用する場合は、Certificate Policies が重複していないことを確認してください。
OVN-Kubernetes で使用されている基盤の Go バージョンにより、API 証明書に重複した Certificate Policies を含めることはできません。詳細は、OpenShift 4.18 upgrade blocked by x509: invalid certificate policies で説明されています。
OpenShift 4.19 にアップグレードする場合
コントロールプレーンノードに node-role.kubernetes.io/control-plane というラベルが付いていることを確認します。
インストールからラベル node-role.kubernetes.io/control-plane が含まれていない古いバージョンでインストールされたクラスターでは、このラベルが欠落している可能性があります。これにより、OpenShift 4.18 から 4.19 へのアップグレード中に machine-config-nodes-crd-cleanup Pod が Pending 状態になる など、アップグレード中に問題が発生する可能性があります。詳細は、inconsistency of node-role between newly created vs. long running OpenShift 4 clusters を参照してください。
クラスターでは cgroup v2 のみが使用されていることを確認する
cgroup v1 は OpenShift 4.19 で削除されました (OpenShift 4.16 では非推奨 になっています) ので、アップグレードする前にクラスターが cgroup v2 を使用 していることを確認する必要があります。
OpenShift 4.20 にアップグレードする場合
Red Hat Marketplace が非推奨となる
OpenShift 4.20 では、Red Hat Marketplace は非推奨となり、今後のリリースで削除される予定です。詳細は、Red Hat Marketplace が非推奨となる を参照してください。
cluster が Prometheus の externalLabel として使用されていないことを確認します。
クラスターオブジェクトの確認
-
ノードのステータスをチェックして、どのノードも
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 が
mounted。 unmountedの 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 [...] - すべての PV と PVC が
-
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 およびサードパーティーコンポーネントの互換性を確認する必要があります。
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