10.6. トラブルシューティング

手順

1. ブートストラップ仮想マシンにログインします。

   $ ssh core@172.22.0.2

   Copy to Clipboard Toggle word wrap

2. コンテナーログを確認するには、以下を実行します。

   [core@localhost ~]$ sudo podman logs -f <container-name>

   Copy to Clipboard Toggle word wrap

   <container-name> を、ironic-api、ironic-conductor、または ironic-inspector のいずれかに置き換えます。コントロールプレーンノードが PXE 経由で起動しない問題が発生した場合には、ironic-conductor Pod を確認してください。ironic-conductor Pod には、IPMI 経由でノードへのログインを試みるため、クラスターノードのブートの試行についての最も詳細な情報が含まれます。

手順

1. ブートストラップ仮想マシンにログインします。

   $ ssh core@172.22.0.2

   Copy to Clipboard Toggle word wrap

2. ブートストラップ仮想マシン内の ipa-downloader および coreos-downloader コンテナーのステータスを確認します。

   [core@localhost ~]$ sudo podman logs -f ipa-downloader

   Copy to Clipboard Toggle word wrap

   [core@localhost ~]$ sudo podman logs -f coreos-downloader

   Copy to Clipboard Toggle word wrap

   ブートストラップ仮想マシンがイメージへの URL にアクセスできない場合、curl コマンドを使用して、仮想マシンがイメージにアクセスできることを確認します。

3. すべてのコンテナーがデプロイメントフェーズで起動されているかどうかを示す bootkube ログを検査するには、以下を実行します。

   [core@localhost ~]$ journalctl -xe

   Copy to Clipboard Toggle word wrap

   [core@localhost ~]$ journalctl -b -f -u bootkube.service

   Copy to Clipboard Toggle word wrap

4. dnsmasq、mariadb、httpd、および ironic を含むすべての Pod が実行中であることを確認します。

   [core@localhost ~]$ sudo podman ps

   Copy to Clipboard Toggle word wrap

5. Pod に問題がある場合には、問題のあるコンテナーのログを確認します。ironic-api のログを確認するには、以下を実行します。

   [core@localhost ~]$ sudo podman logs <ironic-api>

   Copy to Clipboard Toggle word wrap

手順

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: OpenShiftSDN

   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 を参照してください。

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 アドレス範囲を提供する必要なインターフェイスでリッスンしていることを確認します。

手順

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 の対応

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

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 が正常に起動されなくなる可能性があります。

手順

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

手順

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.22.1
   master-1.cloud.example.com   Ready    master   135m   v1.22.1
   master-2.cloud.example.com   Ready    master   145m   v1.22.1
   worker-2.cloud.example.com   Ready    worker   100m   v1.22.1

   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.9.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

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