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

手順

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

   Copy to Clipboard Toggle word wrap

   $ ssh core@172.22.0.2

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

   Copy to Clipboard Toggle word wrap

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

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

手順

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

   Copy to Clipboard Toggle word wrap

   $ ssh core@172.22.0.2

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

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

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

   Copy to Clipboard Toggle word wrap

   [core@localhost ~]$ journalctl -xe

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   [core@localhost ~]$ sudo podman ps

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

   Copy to Clipboard Toggle word wrap

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

手順

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

   Copy to Clipboard Toggle word wrap

   $ 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

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

   Copy to Clipboard Toggle word wrap

   $ 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

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

   Copy to Clipboard Toggle word wrap

   $ kubectl -n openshift-network-operator get pods

4. ログを取得します。

   Copy to Clipboard Toggle word wrap

   $ kubectl -n openshift-network-operator logs -l "name=network-operator"

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

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

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

   Copy to Clipboard Toggle word wrap

   # 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]

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

手順

1. hostname を取得します。

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ hostname

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

   注記

   X は、コントロールプレーンノード (別名マスターノード) 番号になります。

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

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ sudo nmcli con up "<bare-metal-nic>"

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

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

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ hostname

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

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ sudo systemctl restart NetworkManager

5. ホスト名がまだ localhost.localdomain の場合は、数分待機してから再度確認します。ホスト名が localhost.localdomain のままの場合は、直前の手順を繰り返します。

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

   Copy to Clipboard Toggle word wrap

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

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

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

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ sudo systemctl daemon-reload

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   [core@master-X ~]$ sudo journalctl -fu kubelet.service

csr の対応

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

   Copy to Clipboard Toggle word wrap

   $ oc get csr

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   $ oc delete csr <wrong_csr>

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

   Copy to Clipboard Toggle word wrap

   $ oc get route oauth-openshift

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

   Copy to Clipboard Toggle word wrap

   $ 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

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

   Copy to Clipboard Toggle word wrap

   [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

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

   Copy to Clipboard Toggle word wrap

   $ 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"

解決策

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

手順

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

   Copy to Clipboard Toggle word wrap

   Failed Units: 1
     machine-config-daemon-firstboot.service

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

   Copy to Clipboard Toggle word wrap

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

手順

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

   Copy to Clipboard Toggle word wrap

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   $ 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

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

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

   注記

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

   Copy to Clipboard Toggle word wrap

   variant: openshift
   version: 4.8.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 アドレスに置き換えます。

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

   Copy to Clipboard Toggle word wrap

   $ butane 99-master-chrony.bu -o 99-master-chrony.yaml

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

   Copy to Clipboard Toggle word wrap

   $ oc apply -f 99-master-chrony.yaml

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

   Copy to Clipboard Toggle word wrap

   $ 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

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

   Copy to Clipboard Toggle word wrap

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

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