Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.16. その他の問題点

5.16.1. runtime network not ready エラーへの対応
リンクのコピー

クラスターのデプロイメント後に、以下のエラーが発生する可能性があります。 

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
Copy to Clipboard Toggle word wrap

Cluster Network Operator は、インストールプログラムによって作成される特別なオブジェクトに応じてネットワークコンポーネントをデプロイします。これは、コントロールプレーン (マスター) ノードが起動した後、ブートストラップコントロールプレーンが停止する前にインストールプロセスの初期段階で実行されます。これは、コントロールプレーン (マスター) ノードの起動の長い遅延や apiserver の通信の問題など、より判別しにくいインストールプログラムの問題を示している可能性があります。

手順

  1. openshift-network-operator namespace の Pod を検査します。 

    $ oc get all -n openshift-network-operator
    Copy to Clipboard Toggle word wrap 
    NAME                                    READY STATUS            RESTARTS   AGE
pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m
    Copy to Clipboard Toggle word wrap

  2. provisioner ノードで、ネットワーク設定が存在することを判別します。 

    $ kubectl get network.config.openshift.io cluster -oyaml
    Copy to Clipboard Toggle word wrap 
    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNetwork:
  - 172.30.0.0/16
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OVNKubernetes
    Copy to Clipboard Toggle word wrap

    存在しない場合は、インストールプログラムによって作成されていません。インストールプログラムによって作成されなかった理由を確認するには、次のコマンドを実行します。 

    $ openshift-install create manifests
    Copy to Clipboard Toggle word wrap

  3. network-operator が実行されていることを確認します。 

    $ kubectl -n openshift-network-operator get pods
    Copy to Clipboard Toggle word wrap

  4. ログを取得します。 

    $ kubectl -n openshift-network-operator logs -l "name=network-operator"
    Copy to Clipboard Toggle word wrap

    3 つ以上のコントロールプレーンノードを持つ高可用性クラスターでは、Operator がリーダー選択を実行し、他のすべての Operator がスリープ状態になります。詳細は、Troubleshooting を参照してください。

5.16.2. "No disk found with matching rootDeviceHints" エラーメッセージへの対処
リンクのコピー

クラスターをデプロイした後、次のエラーメッセージが表示される場合があります。 

No disk found with matching rootDeviceHints
Copy to Clipboard Toggle word wrap

No disk found with matching rootDeviceHints エラーメッセージに対処するための一時的な回避策は、rootDeviceHints を minSizeGigabytes: 300 に変更することです。

rootDeviceHints 設定を変更した後、CoreOS を起動し、次のコマンドを使用してディスク情報を確認します。 

$ udevadm info /dev/sda
Copy to Clipboard Toggle word wrap

DL360 Gen 10 サーバーを使用している場合は、/dev/sda デバイス名が割り当てられている SD カードスロットがあることに注意してください。サーバーに SD カードが存在しない場合は、競合が発生する可能性があります。サーバーの BIOS 設定で SD カードスロットが無効になっていることを確認してください。

minSizeGigabytes の回避策が要件を満たしていない場合は、rootDeviceHints を /dev/sda に戻さないといけない場合があります。この変更により、Ironic イメージが正常に起動できるようになります。

この問題を解決する別の方法は、ディスクのシリアル ID を使用することです。ただし、シリアル ID を見つけるのは困難な場合があり、設定ファイルが読みにくくなる可能性があることに注意してください。このパスを選択する場合は、前に説明したコマンドを使用してシリアル ID を収集し、それを設定に組み込んでください。

5.16.3. クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない
リンクのコピー

クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない場合は、以下の点を確認してください。

  1. 予約された IPv6 アドレスが DHCP 範囲外にあることを確認します。

  2. DHCP サーバーの IP アドレス予約では、予約で正しい DUID (DHCP 固有識別子) が指定されていることを確認します。以下に例を示します。 

    # This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]
    Copy to Clipboard Toggle word wrap
  3. Route Announcement が機能していることを確認します。
  4. DHCP サーバーが、IP アドレス範囲を提供する必要なインターフェイスでリッスンしていることを確認します。

5.16.4. クラスターノードが DHCP 経由で正しいホスト名を取得しない
リンクのコピー

IPv6 のデプロイメント時に、クラスターノードは DHCP でホスト名を取得する必要があります。NetworkManager はホスト名をすぐに割り当てない場合があります。コントロールプレーン (マスター) ノードは、以下のようなエラーを報告する可能性があります。 

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service
Copy to Clipboard Toggle word wrap

このエラーは、最初に DHCP サーバーからホスト名を受信せずにクラスターノードが起動する可能性があることを示しています。これにより、kubelet が localhost.localdomain ホスト名で起動します。エラーに対処するには、ノードによるホスト名の更新を強制します。

手順

  1. hostname を取得します。 

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap

    ホスト名が localhost の場合は、以下の手順に進みます。

    注記

    X はコントロールプレーンノード番号です。

  2. クラスターノードによる DHCP リースの更新を強制します。 

    [core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"
    Copy to Clipboard Toggle word wrap

    <bare_metal_nic> を、baremetal ネットワークに対応する有線接続に置き換えます。

  3. hostname を再度確認します。 

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap

  4. ホスト名が localhost.localdomain の場合は、NetworkManager を再起動します。 

    [core@master-X ~]$ sudo systemctl restart NetworkManager
    Copy to Clipboard Toggle word wrap
  5. ホスト名がまだ localhost.localdomain の場合は、数分待機してから再度確認します。ホスト名が localhost.localdomain のままの場合は、直前の手順を繰り返します。

  6. nodeip-configuration サービスを再起動します。 

    [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service
    Copy to Clipboard Toggle word wrap

    このサービスは、正しいホスト名の参照で kubelet サービスを再設定します。

  7. kubelet が直前の手順で変更された後にユニットファイル定義を再読み込みします。 

    [core@master-X ~]$ sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap

  8. kubelet サービスを再起動します。 

    [core@master-X ~]$ sudo systemctl restart kubelet.service
    Copy to Clipboard Toggle word wrap

  9. kubelet が正しいホスト名で起動されていることを確認します。 

    [core@master-X ~]$ sudo journalctl -fu kubelet.service
    Copy to Clipboard Toggle word wrap

再起動時など、クラスターの稼働後にクラスターノードが正しいホスト名を取得しない場合、クラスターの csr は保留中になります。csr は承認 しません。承認すると、他の問題が生じる可能性があります。

csr の対応

  1. クラスターで CSR を取得します。 

    $ oc get csr
    Copy to Clipboard Toggle word wrap

  2. 保留中の csr に Subject Name: localhost.localdomain が含まれているかどうかを確認します。 

    $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
    Copy to Clipboard Toggle word wrap

  3. Subject Name: localhost.localdomain が含まれる csr を削除します。 

    $ oc delete csr <wrong_csr>
    Copy to Clipboard Toggle word wrap

5.16.5. ルートがエンドポイントに到達しない
リンクのコピー

インストールプロセス時に、VRRP (Virtual Router Redundancy Protocol) の競合が発生する可能性があります。この競合は、特定のクラスター名を使用してクラスターデプロイメントの一部であった、以前に使用された OpenShift Container Platform ノードが依然として実行中であるものの、同じクラスター名を使用した現在の OpenShift Container Platform クラスターデプロイメントの一部ではない場合に発生する可能性があります。たとえば、クラスターはクラスター名 openshift を使用してデプロイされ、3 つのコントロールプレーン (マスター) ノードと 3 つのワーカーノードをデプロイします。後に、別のインストールで同じクラスター名 openshift が使用されますが、この再デプロイメントは 3 つのコントロールプレーン (マスター) ノードのみをインストールし、以前のデプロイメントの 3 つのワーカーノードを ON 状態のままにします。これにより、VRID (Virtual Router Identifier) の競合が発生し、VRRP が競合する可能性があります。

  1. ルートを取得します。 

    $ oc get route oauth-openshift
    Copy to Clipboard Toggle word wrap

  2. サービスエンドポイントを確認します。 

    $ oc get svc oauth-openshift
    Copy to Clipboard Toggle word wrap 
    NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m
    Copy to Clipboard Toggle word wrap

  3. コントロールプレーン (マスター) ノードからサービスへのアクセスを試行します。 

    [core@master0 ~]$ curl -k https://172.30.19.162
    Copy to Clipboard Toggle word wrap 
    {
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
  },
  "code": 403
    Copy to Clipboard Toggle word wrap

  4. provisioner ノードからの authentication-operator エラーを特定します。 

    $ oc logs deployment/authentication-operator -n openshift-authentication-operator
    Copy to Clipboard Toggle word wrap 
    Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"
    Copy to Clipboard Toggle word wrap

解決策

  1. すべてのデプロイメントのクラスター名が一意であり、競合が発生しないことを確認します。
  2. 同じクラスター名を使用するクラスターデプロイメントの一部ではない不正なノードをすべてオフにします。そうしないと、OpenShift Container Platform クラスターの認証 Pod が正常に起動されなくなる可能性があります。

5.16.6. 初回起動時の Ignition の失敗
リンクのコピー

初回起動時に、Ignition 設定が失敗する可能性があります。

手順

  1. Ignition 設定が失敗したノードに接続します。 

    Failed Units: 1
  machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap

  2. machine-config-daemon-firstboot サービスを再起動します。 

    [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap

5.16.7. NTP が同期しない
リンクのコピー

OpenShift Container Platform クラスターのデプロイメントは、クラスターノード間の NTP の同期クロックによって異なります。同期クロックがない場合、時間の差が 2 秒を超えるとクロックのドリフトによりデプロイメントが失敗する可能性があります。

手順

  1. クラスターノードの AGE の差異の有無を確認します。以下に例を示します。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap 
    NAME                         STATUS   ROLES    AGE   VERSION
master-0.cloud.example.com   Ready    master   145m   v1.30.3
master-1.cloud.example.com   Ready    master   135m   v1.30.3
master-2.cloud.example.com   Ready    master   145m   v1.30.3
worker-2.cloud.example.com   Ready    worker   100m   v1.30.3
    Copy to Clipboard Toggle word wrap

  2. クロックのドリフトによる一貫性のないタイミングの遅延について確認します。以下に例を示します。 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap 
    master-1   error registering master-1  ipmi://<out_of_band_ip>
    Copy to Clipboard Toggle word wrap 
    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap 
                   Local time: Tue 2020-03-10 18:20:02 UTC
           Universal time: Tue 2020-03-10 18:20:02 UTC
                 RTC time: Tue 2020-03-10 18:36:53
                Time zone: UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

既存のクラスターでのクロックドリフトへの対応

  1. ノードに配信される chrony.conf ファイルの内容を含む Butane 設定ファイルを作成します。以下の例で、99-master-chrony.bu を作成して、ファイルをコントロールプレーンノードに追加します。ワーカーノードのファイルを変更するか、ワーカーロールに対してこの手順を繰り返すことができます。

    注記

    Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。 

    variant: openshift
version: 4.17.0
metadata:
  name: 99-master-chrony
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  files:
  - path: /etc/chrony.conf
    mode: 0644
    overwrite: true
    contents:
      inline: |
        server <NTP_server> iburst
    1 
    
        stratumweight 0
        driftfile /var/lib/chrony/drift
        rtcsync
        makestep 10 3
        bindcmdaddress 127.0.0.1
        bindcmdaddress ::1
        keyfile /etc/chrony.keys
        commandkey 1
        generatecommandkey
        noclientlog
        logchange 0.5
        logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap
    1
    <NTP_server> を NTP サーバーの IP アドレスに置き換えます。

  2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-master-chrony.yaml) を生成します。 

    $ butane 99-master-chrony.bu -o 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap

  3. MachineConfig オブジェクトファイルを適用します。 

    $ oc apply -f 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap

  4. System clock synchronized の値が yes であることを確認します。 

    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap 
                   Local time: Tue 2020-03-10 19:10:02 UTC
           Universal time: Tue 2020-03-10 19:10:02 UTC
                 RTC time: Tue 2020-03-10 19:36:53
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

    デプロイメントの前にクロック同期を設定するには、マニフェストファイルを生成し、このファイルを openshift ディレクトリーに追加します。以下に例を示します。 

    $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml
    Copy to Clipboard Toggle word wrap

    クラスターの作成を継続します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat