16.2. 電話会社のコア CNF クラスターのトラブルシューティングと保守
16.2.1. 電話会社のコア CNF クラスターのトラブルシューティングと保守
トラブルシューティングとメンテナンスは、コンポーネントを更新するか問題を調査したいかに関係なく、目標を達成するためのツールがない場合は、毎週のタスクであり、課題になる可能性があります。課題の一部は、ツールと回答の場所と検索方法を知っていることです。
高帯域幅のネットワークスループットが必要なベアメタル環境を維持およびトラブルシューティングするには、以下の手順を参照してください。
このトラブルシューティング情報は、OpenShift Container Platform の設定やクラウドネイティブネットワーク機能(CNF)アプリケーションの開発の参照情報ではありません。
telco 用の CNF アプリケーションの開発に関する詳細は、Red Hat Best Practices for Kubernetes を参照してください。
16.2.1.1. クラウドネイティブネットワーク機能
通信 Cloud-native Network Function (CNF)アプリケーションでの OpenShift Container Platform の使用を開始する場合、CNF について学習すると、発生する可能性のある問題を理解するのに役立ちます。
CNF とその進化の詳細は、VNF および CNF を参照して ください。
16.2.1.2. サポート
手順で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、さまざまな方法でヘルプを見つけることができます。
- Red Hat 製品に関する記事およびソリューションの Red Hat ナレッジベースの検索またはブラウズ。
- Red Hat サポートに対するサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
デプロイメントの問題を特定するには、デバッグツールを使用するか、デプロイメントの ヘルスエンドポイントを確認します。デプロイメントに関する正常性情報をデバッグまたは取得したら、Red Hat ナレッジベースで解決策を検索したり、サポートチケットを提出したりできます。
16.2.1.2.1. Red Hat ナレッジベースについて
Red Hat ナレッジベース は、お客様が Red Hat の製品やテクノロジーを最大限に活用できるようにするための豊富なコンテンツを提供します。Red Hat ナレッジベースは、Red Hat 製品のインストール、設定、および使用に関する記事、製品ドキュメント、および動画で構成されています。さらに、既知の問題に対する解決策を検索でき、それぞれに根本原因の簡潔な説明と修復手順が記載されています。
16.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 コンテンツタイプフィルターを選択します。
16.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.16 を選択します。
- 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 をクリックします。
16.2.2. 一般的なトラブルシューティング
問題が発生した場合には、最初のステップは、問題が発生している特定の領域を見つけることです。問題が発生する可能性のある領域を絞り込むには、1 つ以上のタスクを実行します。
- クラスターのクエリー
- Pod ログの確認
- Pod のデバッグ
- イベントの確認
16.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 ステータスの確認" を参照してください。
関連情報
16.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 logs、Logging、Inspecting Pod and container logs を参照してください。
関連情報
16.2.2.3. Pod の記述
Pod の記述は、トラブルシューティングに役立つ 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 を参照してください。
関連情報
16.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コマンドを使用できます。たとえば、エラーを検索する場合、エラーは、TYPEセクションまたはMESSAGEセクションの出力の 2 つの異なるセクションに表示されることがあります。grepコマンドを使用すると、errorやfailedなどのキーワードを検索できます。たとえば、次のコマンドを実行して、
警告またはエラーが含まれるメッセージを検索します。$ 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
詳細は、「クラスターイベントの監視」を参照してください。
関連情報
16.2.2.5. Pod への接続
現在実行中の Pod に直接接続するには oc rsh コマンドを使用します。これにより、その Pod のシェルが提供されます。
低レイテンシーアプリケーションを実行する Pod では、oc rsh コマンドの実行時にレイテンシーの問題が発生する可能性があります。oc rsh コマンドは、oc debug コマンドを使用してノードに接続できない場合にのみ使用します。
手順
次のコマンドを実行して、Pod に接続します。
$ oc rsh -n <namespace> busybox-1
詳細は、oc rsh および実行中の Pod へのアクセスを参照してください。
関連情報
16.2.2.6. 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 および Starting debug pods with root access を参照してください。
16.2.2.7. Pod でコマンドの実行
直接ログインせずに Pod でコマンドまたはコマンドセットを実行する必要がある場合は、oc exec -it コマンドを使用できます。Pod を迅速に対話し、Pod からプロセスまたは出力情報を取得できます。一般的なユースケースは、スクリプト内で oc exec -it コマンドを実行して、レプリカセットまたはデプロイメントの複数の Pod で同じコマンドを実行することです。
低レイテンシーアプリケーションを実行する Pod では、oc exec コマンドを実行するとレイテンシーの問題が発生する可能性があります。
手順
Pod にログインせずに実行するには、次のコマンドを実行します。
$ oc exec -it <pod> -- <command>
詳細は、"oc exec" および "Executing remote commands in containers" を参照してください。
16.2.3. クラスターのメンテナンス
通信ネットワークでは、ベアメタルデプロイメントの性質上、特定の設定に注意を払う必要があります。これらのタスクを完了することで、より効果的にトラブルシューティングを行うことができます。
- 障害が発生したハードウェアまたは故障しているハードウェアコンポーネントの監視
- クラスター Operator のステータスを定期的に確認します。
ハードウェアの監視については、ハードウェアベンダーに連絡して、特定のハードウェアに適したログツールを見つけてください。
16.2.3.1. クラスター Operator の確認
クラスター Operator のステータスを定期的にチェックして、問題を早期に特定します。
手順
次のコマンドを実行して、クラスター Operator のステータスを確認します。
$ oc get co
16.2.3.2. 失敗した Pod の監視
トラブルシューティング時間を短縮するには、クラスター内で失敗した Pod を定期的に監視します。
手順
失敗した Pod を監視するには、以下のコマンドを実行します。
$ oc get po -A | grep -Eiv 'complete|running'
16.2.4. セキュリティー
回復性の高い通信ネットワークを構築するには、堅牢なクラスターセキュリティープロファイルを実装することが重要です。
16.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>
16.2.5. 証明書のメンテナンス
継続的なクラスター認証には、証明書メンテナンスが必要です。クラスター管理者は、特定の証明書を手動で更新し、その他はクラスターによって自動的に更新されます。
OpenShift Container Platform の証明書について、および以下のリソースを使用して証明書を維持する方法を説明します。
16.2.5.1. 管理者が手動で管理する証明書
以下の証明書はクラスター管理者が更新する必要があります。
- プロキシー証明書
- API サーバーのユーザーによってプロビジョニングされる証明書
16.2.5.1.1. プロキシー証明書の管理
プロキシー証明書により、ユーザーは egress 接続の実行時にプラットフォームコンポーネントによって使用される 1 つ以上のカスタム認証局(CA)証明書を指定できます。
特定の CA は有効期限を設定し、2 年ごとにこれらの証明書を更新する必要がある場合があります。
要求された証明書を設定しなかった場合、証明書の有効期限を複数の方法で設定できます。ほとんどのクラウドネイティブネットワーク機能(CNF)は、ブラウザーベースの接続用に特別に設計されていない証明書を使用します。したがって、デプロイメントの ConfigMap オブジェクトから証明書をプルする必要があります。
手順
有効期限を取得するには、証明書ファイルに対して次のコマンドを実行します。
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
プロキシー証明書を更新する方法とタイミングを決定する方法の詳細については、セキュリティーおよびコンプライアンス の プロキシー証明書 を参照してください。
関連情報
16.2.5.1.2. ユーザーによってプロビジョニングされる API サーバー証明書
API サーバーは、api.<cluster_name>.<base_domain> のクラスター外にあるクライアントからアクセスできます。クライアントに別のホスト名で API サーバーにアクセスさせたり、クラスター管理の認証局 (CA) 証明書をクライアントに配布せずに API サーバーにアクセスさせたりする必要が生じる場合があります。コンテンツを提供する際に API サーバーによって使用されるカスタムデフォルト証明書を設定する必要があります。
詳細は、セキュリティーおよびコンプライアンスの API サーバーのユーザー提供の証明書を参照してください。
16.2.5.2. クラスターによって管理される証明書
ログで問題を検出した場合のみ、クラスター管理の証明書を確認する必要があります。以下の証明書はクラスターによって自動的に管理されます。
- サービス CA 証明書
- ノード証明書
- ブートストラップ証明書
- etcd 証明書
- OLM 証明書
- Machine Config Operator 証明書
- モニタリングおよびクラスターロギング Operator コンポーネント証明書
- コントロールプレーンの証明書
- Ingress 証明書
関連情報
16.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 証明書の更新の詳細については、OpenShift 4 での etcd 証明書の有効期限の確認 を参照してください。etcd 証明書の詳細については、セキュリティーおよびコンプライアンス の etcd 証明書 を参照してください。
関連情報
16.2.5.2.2. ノード証明書
ノード証明書は自己署名証明書です。つまり、クラスターによって署名され、ブートストラッププロセスで生成される内部認証局(CA)から取得されます。
クラスターがインストールされると、クラスターはノード証明書を自動的に更新します。
詳細は、セキュリティーおよびコンプライアンスの ノード証明書 を参照し てください。
関連情報
16.2.5.2.3. サービス CA 証明書
service-ca は、OpenShift Container Platform クラスターのデプロイ時に自己署名の認証局(CA)を作成する Operator です。これにより、ユーザーは手動で証明書を作成せずにデプロイメントに追加できます。サービス CA 証明書は自己署名証明書です。
詳細は、セキュリティーおよびコンプライアンス の サービス CA 証明書 を参照してください。
関連情報
16.2.6. Machine Config Operator
Machine Config Operator はクラスター管理者に有用な情報を提供し、ベアメタルホストで直接実行されるものを制御します。
Machine Config Operator はクラスター内のノードの異なるグループを区別し、コントロールプレーンノードとワーカーノードを異なる設定で実行できます。ノードのこれらのグループは、MachineConfigPool (mcp)グループと呼ばれるワーカーまたはアプリケーション Pod を実行します。同じマシン設定がすべてのノードに適用されるか、クラスター内の 1 つの MCP にのみ適用されます。
テレルコのコアクラスターに MCP を適用する方法と理由の詳細については、更新前の MachineConfigPool ラベルをノードに適用する を参照し てください。
Machine Config Operator についての詳細は、Machine Config Operator を参照してください。
16.2.6.1. Machine Config Operator の目的
Machine Config Operator (MCO)は、カーネルと kubelet 間のすべてを含む、Red Hat Enterprise Linux CoreOS (RHCOS)およびコンテナーランタイムの設定および更新を管理し、適用します。ほとんどの通信会社はベアメタルハードウェアで実行され、ハードウェアアクセラレーターやカーネルの変更を使用するため、RHCOS の管理が重要になります。マシン設定を RHCOS に手動で適用すると、MCO が各ノードを監視し、それに適用される内容により問題が発生する可能性があります。
これらのマイナーコンポーネントを考慮し、MCO がクラスターを効果的に管理できるようにする方法を考慮する必要があります。
ワーカーノードまたはコントロールプレーンノードですべての変更を実行するには、MCO を使用する必要があります。RHCOS またはノードファイルを手動で変更しないでください。
16.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 内のノードが新しい設定に再起動できるようになります。
16.2.7. ベアメタルノードのメンテナンス
一般的なトラブルシューティングのために、ノードに接続できます。ただし、特定のハードウェアコンポーネントでトラブルシューティングまたはメンテナンスタスクを実行する必要がある場合があります。この項では、そのハードウェアのメンテナンスに必要なトピックについて説明します。
16.2.7.1. クラスター内のベアメタルノードへの接続
一般的なメンテナンスタスクのために、ベアメタルノードに接続できます。
ホストオペレーティングシステムからのクラスターノードの設定は推奨されず、サポートされていません。
ノードのトラブルシューティングを行うには、以下のタスクを実行できます。
- ノードからログを取得する
- デバッグの使用
- SSH を使用したノードへの接続
oc debug コマンドでノードに接続できない場合にのみ SSH を使用します。
手順
次のコマンドを実行して、ノードからログを取得します。
$ 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>
16.2.7.2. クラスター内の Pod へのアプリケーションの移動
スケジュールされたハードウェアメンテナンスについては、Pod ワークロードに影響を与えずに、アプリケーション Pod をクラスター内の他のノードに移行する方法を考慮する必要があります。
手順
以下のコマンドを実行して、ノードにスケジュール対象外(unschedulable)のマークを付けます。
$ oc adm cordon <node_name>
ノードをスケジュール対象外の場合、ノードで Pod をスケジュールできません。詳しくは、ノードの操作を参照してください。
CNF アプリケーションを移動する場合、非アフィニティーおよび Pod の中断バジェットにより、クラスター内に追加のワーカーノードが十分にあることを事前に確認する必要がある場合があります。
関連情報
16.2.7.3. DIMM メモリー置換
デュアルインラインメモリーモジュール(DIMM)の問題は、サーバーの再起動後にのみ表示されることがあります。これらの問題について、ログファイルを確認できます。
標準の再起動を実行し、サーバーが起動しない場合は、コンソールに問題のある DIMM メモリーがあるというメッセージが表示されます。この場合、障害のある DIMM を確認し、残りのメモリーが十分にある場合に再起動を続行できます。その後、障害のある DIMM を置き換えるメンテナンス期間をスケジュールできます。
イベントログのメッセージが不適切なメモリーモジュールを示す場合があります。このような場合は、サーバーを再起動する前にメモリー置き換えをスケジュールできます。
16.2.7.4. ディスクの置き換え
ハードウェアまたはソフトウェアの冗長ディスク(RAID)を使用してノードにディスクの冗長性が設定されていない場合は、以下を確認する必要があります。
- ディスクに実行中の Pod イメージが含まれているか ?
- ディスクには Pod の永続データが含まれているか ?
詳細は、ストレージ の OpenShift Container Platform ストレージの概要を参照して ください。
16.2.7.5. クラスターネットワークカードの交換
ネットワークカードを置き換えると、MAC アドレスが変更されます。MAC アドレスは、DHCP または SR-IOV Operator 設定、ルーター設定、ファイアウォールルール、またはアプリケーションのクラウドネイティブネットワーク機能(CNF)設定の一部にすることができます。ネットワークカードを交換した後、ノードをオンラインに戻す前に、これらの設定が最新であることを確認する必要があります。
ネットワークに MAC アドレスの変更に関する特定の手順がない場合は、ネットワーク管理者またはネットワークハードウェアベンダーにお問い合わせください。
