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

手順

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

   $ ssh core@172.22.0.2

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

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

   <container_name> を ironic または ironic-inspector のいずれかに置き換えます。コントロールプレーンノードが PXE から起動しないという問題が発生した場合は、ironic Pod を確認してください。ironic Pod は、IPMI 経由でノードにログインしようとするため、クラスターノードを起動しようとする試みに関する情報を含んでいます。

手順

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

   $ ssh core@172.22.0.2

2. 次のコマンドを実行して、ブートストラップ VM 内の coreos-downloader コンテナーのステータスを確認します。

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

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

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

   [core@localhost ~]$ journalctl -xe

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

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

   [core@localhost ~]$ sudo podman ps

5. Pod に問題がある場合には、問題のあるコンテナーのログを確認します。ironic サービスのログを確認するには、次のコマンドを実行します。

   [core@localhost ~]$ sudo podman logs ironic

手順

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

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

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

   $ kubectl -n openshift-network-operator get pods

4. ログを取得します。

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

   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]

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

手順

1. hostname を取得します。

   [core@master-X ~]$ hostname

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

   注記

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

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

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

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

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

   [core@master-X ~]$ hostname

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

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

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

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

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

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

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

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

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

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

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

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

csr の対応

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

   $ oc get csr

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

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

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

   $ oc delete csr <wrong_csr>

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

   $ oc get route oauth-openshift

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

   $ 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

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

   [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

4. 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"

解決策

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

手順

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

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

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

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

手順

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

   $ oc get nodes

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

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

   $ 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

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

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

   注記

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

   variant: openshift
   version: 4.12.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) を生成します。

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

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

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

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

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