7.10. その他の問題点

7.10.1. `runtime network not ready` エラーへの対応

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

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`

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

手順

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

$ oc get all -n openshift-network-operator

NAME                                    READY STATUS            RESTARTS   AGE
pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m

provisioner ノードで、ネットワーク設定が存在することを判別します。
```
$ kubectl get network.config.openshift.io cluster -oyaml
```
```
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
```
存在しない場合には、インストーラーはこれを作成していません。インストーラーがこれを作成しなかった理由を判別するには、以下のコマンドを実行します。
```
$ openshift-install create manifests
```
network-operator が実行されていることを確認します。
```
$ kubectl -n openshift-network-operator get pods
```
ログを取得します。
```
$ kubectl -n openshift-network-operator logs -l "name=network-operator"
```
3 つ以上のコントロールプレーン (マスター) ノードを持つ高可用性クラスターの場合、Operator はリーダーの選択を実行し、他の Operator はすべてスリープ状態になります。詳細は、Troubleshooting を参照してください。

7.10.2. "No disk found with matching rootDeviceHints" エラーメッセージへの対処

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

No disk found with matching rootDeviceHints

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

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

$ udevadm info /dev/sda

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

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

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

7.10.3. クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない

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

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

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]

Route Announcement が機能していることを確認します。
DHCP サーバーが、IP アドレス範囲を提供する必要なインターフェイスでリッスンしていることを確認します。

7.10.4. クラスターノードが DHCP 経由で正しいホスト名を取得しない

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

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service

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

手順

hostname を取得します。
```
[core@master-X ~]$ hostname
```
ホスト名が localhost の場合は、以下の手順に進みます。
注記
X はコントロールプレーンノード番号です。
クラスターノードによる DHCP リースの更新を強制します。
```
[core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"
```
<bare_metal_nic> を、baremetal ネットワークに対応する有線接続に置き換えます。
hostname を再度確認します。
```
[core@master-X ~]$ hostname
```
ホスト名が localhost.localdomain の場合は、NetworkManager を再起動します。
```
[core@master-X ~]$ sudo systemctl restart NetworkManager
```
ホスト名がまだ localhost.localdomain の場合は、数分待機してから再度確認します。ホスト名が localhost.localdomain のままの場合は、直前の手順を繰り返します。
nodeip-configuration サービスを再起動します。
```
[core@master-X ~]$ sudo systemctl restart nodeip-configuration.service
```
このサービスは、正しいホスト名の参照で kubelet サービスを再設定します。
kubelet が直前の手順で変更された後にユニットファイル定義を再読み込みします。
```
[core@master-X ~]$ sudo systemctl daemon-reload
```

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

[core@master-X ~]$ sudo systemctl restart kubelet.service

kubelet が正しいホスト名で起動されていることを確認します。
```
[core@master-X ~]$ sudo journalctl -fu kubelet.service
```

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

csr の対応

クラスターで CSR を取得します。
```
$ oc get csr
```
保留中の csr に Subject Name: localhost.localdomain が含まれているかどうかを確認します。
```
$ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
```
Subject Name: localhost.localdomain が含まれる csr を削除します。
```
$ oc delete csr <wrong_csr>
```

7.10.5. ルートがエンドポイントに到達しない

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

ルートを取得します。
```
$ oc get route oauth-openshift
```

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

$ oc get svc oauth-openshift

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m

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

[core@master0 ~]$ curl -k https://172.30.19.162

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
  },
  "code": 403

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

$ oc logs deployment/authentication-operator -n openshift-authentication-operator

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"

解決策

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

7.10.6. 初回起動時の Ignition の失敗

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

手順

Ignition 設定が失敗したノードに接続します。
```
Failed Units: 1
  machine-config-daemon-firstboot.service
```

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

[core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service

7.10.7. NTP が同期しない

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

手順

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

$ oc get nodes

NAME                         STATUS   ROLES    AGE   VERSION
master-0.cloud.example.com   Ready    master   145m   v1.26.0
master-1.cloud.example.com   Ready    master   135m   v1.26.0
master-2.cloud.example.com   Ready    master   145m   v1.26.0
worker-2.cloud.example.com   Ready    worker   100m   v1.26.0

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

$ oc get bmh -n openshift-machine-api

master-1   error registering master-1  ipmi://<out_of_band_ip>

$ sudo timedatectl

               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

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

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

注記

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

variant: openshift
version: 4.13.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

1: <NTP_server> を NTP サーバーの IP アドレスに置き換えます。

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

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

$ sudo timedatectl

               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

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

$ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml

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

7.10. その他の問題点

7.10.1. `runtime network not ready` エラーへの対応

7.10.2. "No disk found with matching rootDeviceHints" エラーメッセージへの対処

7.10.3. クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない

7.10.4. クラスターノードが DHCP 経由で正しいホスト名を取得しない

7.10.5. ルートがエンドポイントに到達しない

7.10.6. 初回起動時の Ignition の失敗

7.10.7. NTP が同期しない

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

7.10. その他の問題点

7.10.1. runtime network not ready エラーへの対応

7.10.2. "No disk found with matching rootDeviceHints" エラーメッセージへの対処

7.10.3. クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない

7.10.4. クラスターノードが DHCP 経由で正しいホスト名を取得しない

7.10.5. ルートがエンドポイントに到達しない

7.10.6. 初回起動時の Ignition の失敗

7.10.7. NTP が同期しない

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

7.10.1. `runtime network not ready` エラーへの対応