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

手順

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

   $ ssh core@172.22.0.2

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

   [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. ブートストラップ仮想マシンにログインします。

   $ ssh core@172.22.0.2

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

   [core@localhost ~]$ sudo podman logs -f ipa-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-api のログを確認するには、以下を実行します。

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

手順

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

   存在しない場合には、インストーラーはこれを作成していません。インストーラーがこれを作成しなかった理由を判別するには、以下のコマンドを実行します。

   $ 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.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. クロックのドリフトによる一貫性のないタイミングの遅延について確認します。以下に例を示します。

   $ 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 ファイルを作成し、これを base64 文字列としてエンコードします。以下に例を示します。

   $ cat << EOF | base 64
   server <NTP-server> iburst1
   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
   EOF

   1

   <NTP-server> を NTP サーバーの IP アドレスに置き換えます。出力をコピーします。

   [text-in-base-64]

2. MachineConfig オブジェクトを作成します。base64 文字列を直前の手順の出力で生成される [text-in-base-64] 文字列に置き換えます。以下の例では、ファイルをコントロールプレーン (マスター) ノードに追加します。ワーカーノードのファイルを変更するか、またはワーカーロールの追加のマシン設定を作成できます。

   $ cat << EOF > ./99_masters-chrony-configuration.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     creationTimestamp: null
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-master-etc-chrony-conf
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,[text-in-base-64]1
           group:
             name: root
           mode: 420
           overwrite: true
           path: /etc/chrony.conf
           user:
             name: root
     osImageURL: ""

   1

   [text-in-base-64] を base64 文字列に置き換えます。

3. 設定ファイルのバックアップコピーを作成します。以下に例を示します。

   $ cp 99_masters-chrony-configuration.yaml 99_masters-chrony-configuration.yaml.backup

4. 設定ファイルを適用します。

   $ oc apply -f ./masters-chrony-configuration.yaml

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

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