17.2. 通信事業者向けコア CNF クラスターのトラブルシューティングとメンテナンス
17.2.1. 通信事業者向けコア CNF クラスターのトラブルシューティングとメンテナンス
トラブルシューティングとメンテナンスは週次のタスクであり、コンポーネントを更新する場合でも、問題を調査する場合でも、目標を達成するためのツールがなければ困難になる可能性があります。ツールや回答をどこでどのように検索するかを知ることも、課題の 1 つです。
高帯域幅のネットワークスループットが必要なベアメタル環境をメンテナンスおよびトラブルシューティングするには、次の手順を参照してください。
このトラブルシューティング情報は、OpenShift Container Platform の設定やクラウドネイティブネットワーク機能 (CNF) アプリケーションの開発に関する参考資料ではありません。
通信事業者向け CNF アプリケーションの開発については、Red Hat Best Practices for Kubernetes を参照してください。
17.2.1.1. クラウドネイティブネットワーク機能
通信事業者向けのクラウドネイティブネットワーク機能 (CNF) アプリケーションに OpenShift Container Platform の使用を開始する場合、CNF について理解すると、発生する可能性のある問題を把握するのに役立ちます。
CNF とその進化の詳細は、VNF and CNF, what’s the difference? を参照してください。
17.2.1.2. サポート
手順で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルから、次のようにさまざまな方法でヘルプを見つけることができます。
- Red Hat 製品に関する記事やソリューションを対象とした Red Hat ナレッジベースの検索またはブラウズ。
- Red Hat サポートに対するサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
デプロイメントの問題を特定するには、デバッグツールを使用するか、デプロイメントのヘルスエンドポイントを確認します。デプロイメントのデバッグまたは健全性情報の取得が完了したら、Red Hat ナレッジベースでソリューションを検索したり、サポートチケットを提出したりできます。
17.2.1.2.1. Red Hat ナレッジベースについて
Red Hat ナレッジベース は、お客様が Red Hat の製品やテクノロジーを最大限に活用できるようにするための豊富なコンテンツを提供します。Red Hat ナレッジベースは、Red Hat 製品のインストール、設定、および使用に関する記事、製品ドキュメント、および動画で構成されています。さらに、既知の問題に対する解決策を検索でき、それぞれに根本原因の簡潔な説明と修復手順が記載されています。
17.2.1.2.2. Red Hat ナレッジベースの検索
OpenShift Container Platform の問題が発生した場合には、初期検索を実行して、解決策を Red Hat ナレッジベース内ですでに見つけることができるかどうかを確認できます。
前提条件
- Red Hat カスタマーポータルのアカウントがある。
手順
- Red Hat カスタマーポータル にログインします。
- Search をクリックします。
検索フィールドに、問題に関連する次のようなキーワードと文字列を入力します。
- OpenShift Container Platform コンポーネント (etcd など)
- 関連する手順 (installation など)
- 明示的な失敗に関連する警告、エラーメッセージ、およびその他の出力
- Enter キーをクリックします。
- オプション: OpenShift Container Platform 製品フィルターを選択します。
- オプション: Documentation コンテンツタイプフィルターを選択します。
17.2.1.2.3. サポートケースの送信
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - Red Hat カスタマーポータルのアカウントがある。
- Red Hat の標準またはプレミアムサブスクリプションがある。
手順
- Red Hat カスタマーポータルの Customer Support ページ にログインします。
- Get support をクリックします。
Customer Support ページの Cases タブで、以下を行います。
- オプション: 必要に応じて、事前に入力されたアカウントと所有者の詳細を変更します。
- 問題に該当するカテゴリー (Bug、Defect など) を選択し、Continue をクリックします。
以下の情報を入力します。
- Summary フィールドには､問題の簡潔で説明的な概要と、確認されている現象および予想される動作の詳細情報を入力します。
- Product ドロップダウンメニューから OpenShift Container Platform を選択します。
- Version ドロップダウンから 4.17 を選択します。
- Red Hat ナレッジベースで推奨されるソリューション一覧を確認してください。この一覧に上げられているソリューションは、報告しようとしている問題に適用される可能性があります。提案されている記事が問題に対応していない場合は、Continue をクリックします。
- 報告している問題に対する一致に基づいて推奨される Red Hat ナレッジベースソリューションの一覧が更新されることを確認してください。ケース作成プロセスでより多くの情報を提供すると、このリストの絞り込みが行われます。提案されている記事が問題に対応していない場合は、Continue をクリックします。
- アカウント情報が予想通りに表示されていることを確認し、そうでない場合は適宜修正します。
自動入力された OpenShift Container Platform クラスター ID が正しいことを確認します。正しくない場合は、クラスター ID を手動で取得します。
OpenShift Container Platform Web コンソールを使用してクラスター ID を手動で取得するには、以下を実行します。
-
Home
Overview に移動します。 - Details セクションの Cluster ID フィールドで値を見つけます。
-
Home
または、OpenShift Container Platform Web コンソールで新規サポートケースを作成し、クラスター ID を自動的に入力することができます。
-
ツールバーから、(?)Help
Open Support Case に移動します。 - Cluster ID 値が自動的に入力されます。
-
ツールバーから、(?)Help
OpenShift CLI (
oc) を使用してクラスター ID を取得するには、以下のコマンドを実行します。$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
プロンプトが表示されたら、以下の質問に回答し、Continue をクリックします。
- What are you experiencing? What are you expecting to happen?
- Define the value or impact to you or the business.
- Where are you experiencing this behavior? What environment?
- When does this behavior occur? Frequency? 繰り返し発生するか。At certain times?
-
関連する診断データファイルをアップロードし、Continue をクリックします。まずは、
oc adm must-gatherコマンドを使用して収集されるデータと、そのコマンドによって収集されない問題に固有のデータを含めることが推奨されます。 - 関連するケース管理の詳細情報を入力し、Continue をクリックします。
- ケースの詳細を確認し、Submit をクリックします。
17.2.2. 一般的なトラブルシューティング
問題が発生した場合は、まず問題が発生している特定の領域を確認します。問題が発生する可能性のある領域を絞り込むには、次の 1 つ以上のタスクを完了します。
- クラスターのクエリー
- Pod ログの確認
- Pod のデバッグ
- イベントの確認
17.2.2.1. クラスターのクエリー
潜在的な問題をより正確に発見できるように、クラスターに関する情報を取得します。
手順
次のコマンドを実行してプロジェクトに切り替えます。
$ oc project <project_name>
次のコマンドを実行して、クラスターのバージョン、クラスター Operator、およびその namespace 内のノードをクエリーします。
$ oc get clusterversion,clusteroperator,node
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.16.11 True False 62d Cluster version is 4.16.11 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/authentication 4.16.11 True False False 62d clusteroperator.config.openshift.io/baremetal 4.16.11 True False False 62d clusteroperator.config.openshift.io/cloud-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/cloud-credential 4.16.11 True False False 62d clusteroperator.config.openshift.io/cluster-autoscaler 4.16.11 True False False 62d clusteroperator.config.openshift.io/config-operator 4.16.11 True False False 62d clusteroperator.config.openshift.io/console 4.16.11 True False False 62d clusteroperator.config.openshift.io/control-plane-machine-set 4.16.11 True False False 62d clusteroperator.config.openshift.io/csi-snapshot-controller 4.16.11 True False False 62d clusteroperator.config.openshift.io/dns 4.16.11 True False False 62d clusteroperator.config.openshift.io/etcd 4.16.11 True False False 62d clusteroperator.config.openshift.io/image-registry 4.16.11 True False False 55d clusteroperator.config.openshift.io/ingress 4.16.11 True False False 62d clusteroperator.config.openshift.io/insights 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-apiserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-scheduler 4.16.11 True False False 62d clusteroperator.config.openshift.io/kube-storage-version-migrator 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-api 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-approver 4.16.11 True False False 62d clusteroperator.config.openshift.io/machine-config 4.16.11 True False False 62d clusteroperator.config.openshift.io/marketplace 4.16.11 True False False 62d clusteroperator.config.openshift.io/monitoring 4.16.11 True False False 62d clusteroperator.config.openshift.io/network 4.16.11 True False False 62d clusteroperator.config.openshift.io/node-tuning 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-apiserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-controller-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/openshift-samples 4.16.11 True False False 35d clusteroperator.config.openshift.io/operator-lifecycle-manager 4.16.11 True False False 62d clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.16.11 True False False 62d clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.16.11 True False False 62d clusteroperator.config.openshift.io/service-ca 4.16.11 True False False 62d clusteroperator.config.openshift.io/storage 4.16.11 True False False 62d NAME STATUS ROLES AGE VERSION node/ctrl-plane-0 Ready control-plane,master,worker 62d v1.29.7 node/ctrl-plane-1 Ready control-plane,master,worker 62d v1.29.7 node/ctrl-plane-2 Ready control-plane,master,worker 62d v1.29.7
詳細は、「oc get」および「Pod ステータスの確認」を参照してください。
関連情報
17.2.2.2. Pod ログの確認
Pod からログを取得して、ログで問題を確認します。
手順
次のコマンドを実行して、Pod を一覧表示します。
$ oc get pod
出力例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
次のコマンドを実行して、Pod ログファイルを確認します。
$ oc logs -n <namespace> busybox-1
詳細は、「oc ログ」、「ロギング」、および「Pod およびコンテナーログの検査」を参照してください。
関連情報
17.2.2.3. Pod に対する describe の実行
Pod に対して describe を実行すると、その Pod に関する情報が得られ、トラブルシューティングに役立ちます。Events セクションに、Pod とその中のコンテナーに関する詳細情報が表示されます。
手順
次のコマンドを実行して Pod に関する情報を取得します。
$ oc describe pod -n <namespace> busybox-1
出力例
Name: busybox-1 Namespace: busy Priority: 0 Service Account: default Node: worker-3/192.168.0.0 Start Time: Mon, 27 Nov 2023 14:41:25 -0500 Labels: app=busybox pod-template-hash=<hash> Annotations: k8s.ovn.org/pod-networks: … Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Pulled 41m (x170 over 7d1h) kubelet Container image "quay.io/quay/busybox:latest" already present on machine Normal Created 41m (x170 over 7d1h) kubelet Created container busybox Normal Started 41m (x170 over 7d1h) kubelet Started container busybox
詳細は、「oc describe」を参照してください。
関連情報
17.2.2.4. イベントの確認
特定の namespace 内のイベントを確認すると、潜在的な問題を発見できます。
手順
次のコマンドを実行して、namespace 内のイベントを確認します。
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp" 1- 1
--sort-by=".metadata.creationTimestamp"フラグを追加すると、最新のイベントが出力の最後に配置されます。
オプション: 指定した namespace 内のイベントで十分な情報が得られない場合は、次のコマンドを実行して、クエリーの対象をすべての namespace に拡張します。
$ oc get events -A --sort-by=".metadata.creationTimestamp" 1- 1
--sort-by=".metadata.creationTimestamp"フラグを指定すると、最新のイベントが出力の最後に配置されます。
クラスターからのすべてのイベントの結果をフィルタリングするには、
grepコマンドを使用できます。たとえば、エラーを探している場合、エラーは出力の 2 つの異なるセクション (TYPEまたはMESSAGEセクション) に表示されることがあります。grepコマンドを使用すると、errorやfailedなどのキーワードを検索できます。たとえば、次のコマンドを実行して、
warningまたはerrorを含むメッセージを検索します。$ oc get events -A | grep -Ei "warning|error"
出力例
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE openshift 59s Warning FailedMount pod/openshift-1 MountVolume.SetUp failed for volume "v4-0-config-user-idp-0-file-data" : references non-existent secret key: test
オプション: イベントをクリーンアップして繰り返し発生しているイベントのみを表示するには、次のコマンドを実行して、関連する namespace 内のイベントを削除します。
$ oc delete events -n <namespace> --all
詳細は、「クラスターイベントの監視」を参照してください。
関連情報
17.2.2.5. Pod への接続
oc rsh コマンドを使用して、現在実行中の Pod に直接接続すると、その Pod のシェルを使用できます。
低レイテンシーのアプリケーションを実行する Pod では、oc rsh コマンドを実行するとレイテンシーの問題が発生する可能性があります。oc rsh コマンドは、oc debug コマンドを使用してノードに接続できない場合にのみ使用してください。
手順
次のコマンドを実行して Pod に接続します。
$ oc rsh -n <namespace> busybox-1
詳細は、「oc rsh」および「実行中の Pod へのアクセス」を参照してください。
関連情報
17.2.2.6. Pod のデバッグ
場合によっては、実稼働環境の Pod を直接操作するのを避けたほうがよいこともあります。
実行中のトラフィックを妨げないようにするには、元の Pod のコピーであるセカンダリー Pod を使用します。セカンダリー Pod は元の Pod と同じコンポーネントを使用しますが、セカンダリー Pod には実行中のトラフィックがありません。
手順
次のコマンドを実行して、Pod を一覧表示します。
$ oc get pod
出力例
NAME READY STATUS RESTARTS AGE busybox-1 1/1 Running 168 (34m ago) 7d busybox-2 1/1 Running 119 (9m20s ago) 4d23h busybox-3 1/1 Running 168 (43m ago) 7d busybox-4 1/1 Running 168 (43m ago) 7d
次のコマンドを実行して Pod をデバッグします。
$ oc debug -n <namespace> busybox-1
出力例
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
シェルプロンプトが表示されない場合は、Enter キーを押します。
詳細は、「oc debug」および「root アクセスでのデバッグ Pod の起動」を参照してください。
17.2.2.7. Pod でのコマンドの実行
Pod に直接ログインせずに、Pod 上でコマンドまたはコマンドのセットを実行する場合は、oc exec -it コマンドを使用できます。Pod を素早く操作して、Pod からプロセス情報や出力情報を取得できます。一般的な使用例としては、スクリプト内で oc exec -it コマンドを実行して、レプリカセットまたはデプロイメント内の複数の Pod で同じコマンドを実行することが挙げられます。
低レイテンシーのアプリケーションを実行する Pod では、oc exec コマンドによってレイテンシーの問題が発生する可能性があります。
手順
Pod にログインせずに Pod でコマンドを実行するには、次のコマンドを実行します。
$ oc exec -it <pod> -- <command>
詳細は、「oc exec」および「コンテナー内でのリモートコマンドの実行」を参照してください。
17.2.3. クラスターのメンテナンス
通信事業者ネットワークでは、ベアメタルデプロイメントの性質上、特定の設定にさらに注意を払う必要があります。次のタスクを完了すると、より効果的にトラブルシューティングを行うことができます。
- 故障したハードウェアコンポーネントを監視する
- 定期的にクラスター Operator のステータスを確認する
ハードウェアの監視については、ハードウェアベンダーに問い合わせて、特定のハードウェアに適したログツールを見つけてください。
17.2.3.1. クラスター Operator の確認
問題を早期に発見するために、クラスター Operator のステータスを定期的に確認します。
手順
次のコマンドを実行して、クラスター Operator のステータスを確認します。
$ oc get co
17.2.3.2. 失敗した Pod の監視
トラブルシューティングの時間を短縮するには、クラスター内の障害が発生した Pod を定期的に監視します。
手順
失敗した Pod を監視するには、次のコマンドを実行します。
$ oc get po -A | grep -Eiv 'complete|running'
17.2.4. セキュリティー
堅牢なクラスターセキュリティープロファイルを実装することは、回復力のある通信事業者ネットワークを構築する上で重要です。
17.2.4.1. 認証
クラスター内にあるアイデンティティープロバイダーを特定します。サポートされているアイデンティティープロバイダーの詳細は、認証および認可 の「サポートされるアイデンティティープロバイダー」を参照してください。
どのプロバイダーが設定されているのかがわかったら、openshift-authentication namespace を調べて、潜在的な問題があるかどうかを確認できます。
手順
次のコマンドを実行して、
openshift-authenticationnamespace 内のイベントを確認します。$ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
次のコマンドを実行して、
openshift-authenticationnamespace 内の Pod を確認します。$ oc get pod -n openshift-authentication
オプション: 詳細情報が必要な場合は、次のコマンドを実行して、実行中のいずれかの Pod のログを確認します。
$ oc logs -n openshift-authentication <pod_name>
17.2.5. 証明書のメンテナンス
継続的なクラスター認証を実現するには、証明書のメンテナンスが欠かせません。一部の証明書はクラスター管理者が手動で更新する必要がありますが、その他の証明書はクラスターによって自動的に更新されます。
以下のリソースを使用して、OpenShift Container Platform の証明書とその管理方法を確認してください。
17.2.5.1. 管理者が手動で管理する証明書
次の証明書は、クラスター管理者が更新する必要があります。
- プロキシー証明書
- ユーザーがプロビジョニングする API サーバー証明書
17.2.5.1.1. プロキシー証明書の管理
プロキシー証明書を使用すると、ユーザーは、Egress 接続を行うときにプラットフォームコンポーネントによって使用される 1 つ以上のカスタム認証局 (CA) 証明書を指定できます。
一部の CA には有効期限が設定されています。このような証明書は 2 年ごとに更新する必要がある場合があります。
要求される証明書を最初に設定しなかった場合は、いくつかの方法で証明書の有効期限を決定できます。ほとんどのクラウドネイティブネットワーク機能 (CNF) が使用する証明書は、ブラウザーベースの接続用に特別に設計されたものではありません。したがって、デプロイメントの ConfigMap オブジェクトから証明書を取得する必要があります。
手順
有効期限を取得するには、証明書ファイルに対して次のコマンドを実行します。
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
プロキシー証明書を更新する方法と時期を確認する方法の詳細は、セキュリティーおよびコンプライアンス の「プロキシー証明書」を参照してください。
関連情報
17.2.5.1.2. ユーザーがプロビジョニングする API サーバー証明書
API サーバーには、クラスター外部のクライアントから api.<cluster_name>.<base_domain> でアクセスできます。クライアントに別のホスト名で API サーバーにアクセスさせたり、クラスター管理の認証局 (CA) 証明書をクライアントに配布せずに API サーバーにアクセスさせたりする必要が生じる場合があります。コンテンツを提供するときに API サーバーが使用するカスタムのデフォルト証明書を設定する必要があります。
詳細は、セキュリティーおよびコンプライアンス の「API サーバー用のユーザーがプロビジョニングする証明書」を参照してください。
17.2.5.2. クラスターによって管理される証明書
クラスターによって管理される証明書は、ログで問題が検出された場合にのみ確認する必要があります。次の証明書はクラスターによって自動的に管理されます。
- サービス CA 証明書
- ノード証明書
- ブートストラップ証明書
- etcd 証明書
- OLM 証明書
- Machine Config Operator 証明書
- モニタリングおよびクラスターロギング Operator コンポーネント証明書
- コントロールプレーンの証明書
- Ingress 証明書
関連情報
17.2.5.2.1. etcd によって管理される証明書
etcd 証明書は、etcd メンバーのピア間の暗号化された通信と、暗号化されたクライアントトラフィックに使用されます。すべてのノードとすべてのサービス間の通信が最新であれば、証明書はクラスター内で自動的に更新されます。したがって、etcd 証明書の有効期限に近い特定期間中にクラスターがコンポーネント間の通信を失う可能性がある場合は、事前に証明書を更新することを推奨します。たとえば、ノードが異なるタイミングで再起動するため、アップグレード中に通信が失われる可能性があります。
次のコマンドを実行して、etcd 証明書を手動で更新できます。
$ for each in $(oc get secret -n openshift-etcd | grep "kubernetes.io/tls" | grep -e \ "etcd-peer\|etcd-serving" | awk '{print $1}'); do oc get secret $each -n openshift-etcd -o \ jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -noout -enddate; done
etcd 証明書の更新の詳細は、Checking etcd certificate expiry in OpenShift 4 を参照してください。etcd 証明書の詳細は、セキュリティーおよびコンプライアンス の「etcd 証明書」を参照してください。
関連情報
17.2.5.2.2. ノード証明書
ノード証明書は自己署名証明書です。つまり、クラスターによって署名され、ブートストラッププロセスによって生成された内部認証局 (CA) から発行されたものです。
クラスターがインストールされると、クラスターはノード証明書を自動的に更新します。
詳細は、セキュリティーおよびコンプライアンス の「ノード証明書」を参照してください。
関連情報
17.2.5.2.3. サービス CA 証明書
service-ca は、OpenShift Container Platform クラスターがデプロイされるときに自己署名認証局 (CA) を作成する Operator です。これにより、ユーザーは手動で証明書を作成せずに、デプロイメントに証明書を追加できます。サービス CA 証明書は自己署名証明書です。
詳細は、セキュリティーおよびコンプライアンス の「サービス CA 証明書」を参照してください。
関連情報
17.2.6. Machine Config Operator
Machine Config Operator は、クラスター管理者に有用な情報を提供し、ベアメタルホスト上で直接実行されているコンポーネントを制御します。
Machine Config Operator は、クラスター内の各ノードグループを区別し、コントロールプレーンノードとワーカーノードを異なる設定で実行できるようにします。これらのノードグループは、MachineConfigPool (mcp) グループと呼ばれるワーカー Pod またはアプリケーション Pod を実行します。同じマシン設定が、クラスター内のすべてのノードまたは 1 つの MCP にのみ適用されます。
通信事業者向けコアクラスターで MCP を適用する方法と理由の詳細は、更新前にノードに MachineConfigPool ラベルを適用する を参照してください。
Machine Config Operator の詳細は、Machine Config Operator を参照してください。
17.2.6.1. Machine Config Operator の目的
Machine Config Operator (MCO) は、カーネルと kubelet 間にあるすべてのものを含む、Red Hat Enterprise Linux CoreOS (RHCOS) とコンテナーランタイムの設定と更新を管理および適用します。ほとんどの通信事業者はベアメタルハードウェア上で運用し、何らかのハードウェアアクセラレーターまたはカーネルの変更を使用しているため、RHCOS の管理は重要です。MCO は各ノードとそれに適用される内容を監視するため、マシン設定を RHCOS に手動で適用すると問題が発生する可能性があります。
このような細かいコンポーネントと、MCO がクラスターを効果的に管理するのにどのように役立つかを考慮する必要があります。
ワーカーノードまたはコントロールプレーンノードに対する変更は、すべて MCO を使用して実行する必要があります。RHCOS またはノードファイルを手動で変更しないでください。
17.2.6.2. 複数のマシン設定ファイルを同時に適用する
クラスター内のノードグループ (マシン設定プール (MCP) とも呼ばれます) のマシン設定を変更する必要がある場合、複数の異なるマシン設定ファイルを使用して変更を適用する必要があることがあります。マシン設定ファイルを適用するには、ノードを再起動する必要があります。各マシン設定ファイルがクラスターに適用されると、そのマシン設定ファイルの影響を受けるすべてのノードが再起動します。
マシン設定ファイルごとにノードが再起動するのを防ぐには、新しいマシン設定ファイルによって更新される各 MCP を一時停止して、すべての変更を同時に適用します。
手順
次のコマンドを実行して、影響を受ける MCP を一時停止します。
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'すべてのマシン設定の変更をクラスターに適用したら、次のコマンドを実行します。
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
これにより、MCP 内のノードが新しい設定で再起動できるようになります。
17.2.7. ベアメタルノードのメンテナンス
ノードに接続すると、一般的なトラブルシューティングを実行できます。ただし、場合によっては、特定のハードウェアコンポーネントに対してトラブルシューティングやメンテナンスのタスクを実行する必要があります。このセクションでは、ハードウェアのメンテナンスを実行するために必要なトピックについて説明します。
17.2.7.1. クラスター内のベアメタルノードに接続する
ベアメタルクラスターノードに接続すると、一般的なメンテナンスタスクを実行できます。
ホストオペレーティングシステムからクラスターノードを設定することは推奨されておらず、サポートもされていません。
ノードのトラブルシューティングを行う際には、次のタスクを実行できます。
- ノードからログを取得する
- デバッグを使用する
- SSH を使用してノードに接続する
SSH は、oc debug コマンドを使用してノードに接続できない場合にのみ使用してください。
手順
次のコマンドを実行して、ノードからログを取得します。
$ oc adm node-logs <node_name> -u crio
次のコマンドを実行してデバッグを使用します。
$ oc debug node/<node_name>
/hostをデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストの root ファイルシステムをマウントします。root ディレクトリーを/hostに変更すると、ホストの実行パスに含まれるバイナリーを実行できます。# chroot /host
出力
You are now logged in as root on the node
オプション: 次のコマンドを実行して、SSH を使用してノードに接続します。
$ ssh core@<node_name>
17.2.7.2. クラスター内の Pod にアプリケーションを移動する
計画的なハードウェアメンテナンスの場合、Pod のワークロードに影響を与えずに、アプリケーション Pod をクラスター内の他のノードに移動する方法を検討する必要があります。
手順
次のコマンドを実行して、ノードをスケジュール対象外としてマークします。
$ oc adm cordon <node_name>
ノードがスケジュール対象外の場合、そのノードで Pod をスケジュールすることはできません。詳細は、「ノードの操作」を参照してください。
CNF アプリケーションを移動する場合、アンチアフィニティーと Pod Disruption Budget 用に、クラスター内に十分な追加ワーカーノードがあるかどうかを事前に確認する必要がある場合があります。
関連情報
17.2.7.3. DIMM メモリーの交換
デュアルインラインメモリーモジュール (DIMM) の問題が発生することがあるのは、サーバーの再起動後だけです。このような問題についてはログファイルで確認できます。
標準の再起動を実行してもサーバーが起動しない場合は、DIMM メモリーに障害があることを示すメッセージがコンソールに表示されます。その場合、障害のある DIMM を確認し、残りのメモリーが十分であれば再起動を続行できます。その後、障害のある DIMM を交換するためのメンテナンスウィンドウをスケジュールすることができます。
場合によっては、イベントログのメッセージにメモリーモジュールの不良が示されることがあります。このような場合は、サーバーを再起動する前にメモリーの交換をスケジュールすることができます。
17.2.7.4. ディスクの交換
ハードウェアまたはソフトウェアの Redundant Array of Independent Disks (RAID) を通じてノードにディスク冗長性が設定されていない場合は、次の点を確認する必要があります。
- ディスクに実行中の Pod イメージが含まれているかどうか
- ディスクに Pod の永続データが含まれているかどうか
詳細は、ストレージ の「OpenShift Container Platform ストレージの概要」を参照してください。
17.2.7.5. クラスターネットワークカードの交換
ネットワークカードを交換すると、MAC アドレスが変更されます。MAC アドレスは、DHCP または SR-IOV Operator 設定、ルーター設定、ファイアウォールルール、またはアプリケーションのクラウドネイティブネットワーク機能 (CNF) 設定の一部である場合があります。ネットワークカードを交換した後、ノードをオンラインに戻す前に、これらの設定が最新であることを確認する必要があります。
ネットワーク内で MAC アドレスを変更するための具体的な手順が整備されていない場合は、ネットワーク管理者またはネットワークハードウェアベンダーに問い合わせてください。
