14.5. インストールのトラブルシューティング

手順

1. YAML-tips のガイドラインを使用します。
2. syntax-check を使用して YAML 構文が正しいことを確認します。

3. Red Hat Enterprise Linux CoreOS (RHCOS) QEMU イメージが適切に定義され、install-config.yaml で提供される URL 経由でアクセスできることを確認します。以下に例を示します。

   $ curl -s -o /dev/null -I -w "%{http_code}\n" http://webserver.example.com:8080/rhcos-44.81.202004250133-0-qemu.<architecture>.qcow2.gz?sha256=7d884b46ee54fe87bbc3893bf2aa99af3b2d31f2e19ab5529c60636fbd0f1ce7

   出力が 200 の場合、ブートストラップ仮想マシンイメージを保存する Web サーバーからの有効な応答があります。

手順

1. インストールプログラムをトリガー後の約 10 分から 15 分後に、virsh コマンドを使用してブートストラップ仮想マシンが機能していることを確認します。

   $ sudo virsh list

    Id    Name                           State
    --------------------------------------------
    12    openshift-xf6fq-bootstrap      running

   注記

   ブートストラップ仮想マシンの名前は常にクラスター名で始まり、その後にランダムな文字セットが続き、"bootstrap" という単語で終わります。

2. 10 - 15 分経ってもブートストラップ仮想マシンが実行されない場合は、次のコマンドを実行して、システム上で libvirtd が実行されていることを確認します。

   $ systemctl status libvirtd

   ● libvirtd.service - Virtualization daemon
      Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
      Active: active (running) since Tue 2020-03-03 21:21:07 UTC; 3 weeks 5 days ago
        Docs: man:libvirtd(8)
              https://libvirt.org
    Main PID: 9850 (libvirtd)
       Tasks: 20 (limit: 32768)
      Memory: 74.8M
      CGroup: /system.slice/libvirtd.service
              ├─ 9850 /usr/sbin/libvirtd

   ブートストラップ仮想マシンが動作している場合は、これにログインします。

3. virsh console コマンドを使用して、ブートストラップ仮想マシンの IP アドレスを見つけます。

   $ sudo virsh console example.com

   Connected to domain example.com
   Escape character is ^]
   Red Hat Enterprise Linux CoreOS 43.81.202001142154.0 (Ootpa) 4.3
   SSH host key: SHA256:BRWJktXZgQQRY5zjuAV0IKZ4WM7i4TiUyMVanqu9Pqg (ED25519)
   SSH host key: SHA256:7+iKGA7VtG5szmk2jB5gl/5EZ+SNcJ3a2g23o0lnIio (ECDSA)
   SSH host key: SHA256:DH5VWhvhvagOTaLsYiVNse9ca+ZSW/30OOMed8rIGOc (RSA)
   ens3:  fd35:919d:4042:2:c7ed:9a9f:a9ec:7
   ens4: 172.22.0.2 fe80::1d05:e52e:be5d:263f
   localhost login:

   重要

   provisioning ネットワークなしで OpenShift Container Platform クラスターをデプロイする場合、172.22.0.2 などのプライベート IP アドレスではなく、パブリック IP アドレスを使用する必要があります。

4. IP アドレスを取得したら、ssh コマンドを使用してブートストラップ仮想マシンにログインします。

   注記

   直前の手順のコンソール出力では、ens3 で提供される IPv6 IP アドレスまたは ens4 で提供される IPv4 IP を使用できます。

   $ ssh core@172.22.0.2

手順

1. 次のコマンドを実行して、各コントロールプレーンノードで etcd が実行されていることを確認します。

   $ sudo crictl logs $(sudo crictl ps --pod=$(sudo crictl pods --name=etcd-member --quiet) --quiet)

2. 上記のコマンドが失敗した場合は、次のコマンドを実行して、Kubelet により etcd Pod が作成されたことを確認します。

   $ sudo crictl pods --name=etcd-member

   Pod がない場合は、etcd を調査します。

3. 次のコマンドを使用して、クラスターノードに localhost.localdomain だけでなく完全修飾ドメイン名があることを確認します。

   $ hostname

   ホスト名が設定されていない場合、正しいホスト名を設定します。以下に例を示します。

   $ sudo hostnamectl set-hostname <hostname>

4. dig コマンドを使用して、各ノードの DNS サーバーでの名前解決が正しいことを確認します。

   $ dig api.<cluster_name>.example.com

   ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> api.<cluster_name>.example.com
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37551
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
   
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 4096
   ; COOKIE: 866929d2f8e8563582af23f05ec44203d313e50948d43f60 (good)
   ;; QUESTION SECTION:
   ;api.<cluster_name>.example.com. IN A
   
   ;; ANSWER SECTION:
   api.<cluster_name>.example.com. 10800 IN	A 10.19.13.86
   
   ;; AUTHORITY SECTION:
   <cluster_name>.example.com. 10800 IN NS	<cluster_name>.example.com.
   
   ;; ADDITIONAL SECTION:
   <cluster_name>.example.com. 10800 IN A	10.19.14.247
   
   ;; Query time: 0 msec
   ;; SERVER: 10.19.14.247#53(10.19.14.247)
   ;; WHEN: Tue May 19 20:30:59 UTC 2020
   ;; MSG SIZE  rcvd: 140

   前述の例の出力は、api.<cluster_name>.example.com VIP の適切な IP アドレスが 10.19.13.86 であることを示しています。この IP アドレスは baremetal 上にある必要があります。

手順

1. 次のコマンドを実行して ClusterVersion オブジェクトを検査します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion -o yaml

   出力例

   apiVersion: config.openshift.io/v1
   kind: ClusterVersion
   metadata:
     creationTimestamp: 2019-02-27T22:24:21Z
     generation: 1
     name: version
     resourceVersion: "19927"
     selfLink: /apis/config.openshift.io/v1/clusterversions/version
     uid: 6e0f4cf8-3ade-11e9-9034-0a923b47ded4
   spec:
     channel: stable-4.1
     clusterID: 5ec312f9-f729-429d-a454-61d4906896ca
   status:
     availableUpdates: null
     conditions:
     - lastTransitionTime: 2019-02-27T22:50:30Z
       message: Done applying 4.1.1
       status: "True"
       type: Available
     - lastTransitionTime: 2019-02-27T22:50:30Z
       status: "False"
       type: Failing
     - lastTransitionTime: 2019-02-27T22:50:30Z
       message: Cluster version is 4.1.1
       status: "False"
       type: Progressing
     - lastTransitionTime: 2019-02-27T22:24:31Z
       message: 'Unable to retrieve available updates: unknown version 4.1.1
       reason: RemoteFailed
       status: "False"
       type: RetrievedUpdates
     desired:
       image: registry.svc.ci.openshift.org/openshift/origin-release@sha256:91e6f754975963e7db1a9958075eb609ad226968623939d262d1cf45e9dbc39a
       version: 4.1.1
     history:
     - completionTime: 2019-02-27T22:50:30Z
       image: registry.svc.ci.openshift.org/openshift/origin-release@sha256:91e6f754975963e7db1a9958075eb609ad226968623939d262d1cf45e9dbc39a
       startedTime: 2019-02-27T22:24:31Z
       state: Completed
       version: 4.1.1
     observedGeneration: 1
     versionHash: Wa7as_ik1qE=

2. 次のコマンドを実行して状態を表示します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion version \
        -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'

   最も重要な状態は、Failing、Available、Progressing です。

   出力例

   Available True Done applying 4.1.1
   Failing False
   Progressing False Cluster version is 4.0.0-0.alpha-2019-02-26-194020
   RetrievedUpdates False Unable to retrieve available updates: unknown version 4.1.1

3. 次のコマンドを実行して ClusterOperator オブジェクトを検査します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator

   このコマンドは、クラスター Operators のステータスを返します。

   出力例

   NAME                                  VERSION   AVAILABLE   PROGRESSING   FAILING   SINCE
   cluster-baremetal-operator                      True        False         False     17m
   cluster-autoscaler                              True        False         False     17m
   cluster-storage-operator                        True        False         False     10m
   console                                         True        False         False     7m21s
   dns                                             True        False         False     31m
   image-registry                                  True        False         False     9m58s
   ingress                                         True        False         False     10m
   kube-apiserver                                  True        False         False     28m
   kube-controller-manager                         True        False         False     21m
   kube-scheduler                                  True        False         False     25m
   machine-api                                     True        False         False     17m
   machine-config                                  True        False         False     17m
   marketplace-operator                            True        False         False     10m
   monitoring                                      True        False         False     8m23s
   network                                         True        False         False     13m
   node-tuning                                     True        False         False     11m
   openshift-apiserver                             True        False         False     15m
   openshift-authentication                        True        False         False     20m
   openshift-cloud-credential-operator             True        False         False     18m
   openshift-controller-manager                    True        False         False     10m
   openshift-samples                               True        False         False     8m42s
   operator-lifecycle-manager                      True        False         False     17m
   service-ca                                      True        False         False     30m

4. 次のコマンドを実行して、個々のクラスター Operator を検査します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> -oyaml 1

   1

   <operator> は、クラスター Operator の名前に置き換えます。このコマンドは、クラスター Operator のステータスが Available にならない理由、または Failed になる理由を特定するために使用できます。

   出力例

   apiVersion: config.openshift.io/v1
   kind: ClusterOperator
   metadata:
     creationTimestamp: 2019-02-27T22:47:04Z
     generation: 1
     name: monitoring
     resourceVersion: "24677"
     selfLink: /apis/config.openshift.io/v1/clusteroperators/monitoring
     uid: 9a6a5ef9-3ae1-11e9-bad4-0a97b6ba9358
   spec: {}
   status:
     conditions:
     - lastTransitionTime: 2019-02-27T22:49:10Z
       message: Successfully rolled out the stack.
       status: "True"
       type: Available
     - lastTransitionTime: 2019-02-27T22:49:10Z
       status: "False"
       type: Progressing
     - lastTransitionTime: 2019-02-27T22:49:10Z
       status: "False"
       type: Failing
     extension: null
     relatedObjects: null
     version: ""

5. クラスター Operator のステータス状態を取得するには、次のコマンドを実行します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> \
        -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'

   <Operator> は、上記のいずれかの Operator の名前に置き換えます。

   出力例

   Available True Successfully rolled out the stack
   Progressing False
   Failing False

6. クラスター Operator が所有するオブジェクトのリストを取得するには、次のコマンドを実行します。

   oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator kube-apiserver \
      -o=jsonpath='{.status.relatedObjects}'

   出力例

   [map[resource:kubeapiservers group:operator.openshift.io name:cluster] map[group: name:openshift-config resource:namespaces] map[group: name:openshift-config-managed resource:namespaces] map[group: name:openshift-kube-apiserver-operator resource:namespaces] map[group: name:openshift-kube-apiserver resource:namespaces]]

手順

1. 次のコマンドを実行して、コンソールルーターが Available 状態か Failing 状態かを確認します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator console -oyaml

   apiVersion: config.openshift.io/v1
   kind: ClusterOperator
   metadata:
     creationTimestamp: 2019-02-27T22:46:57Z
     generation: 1
     name: console
     resourceVersion: "19682"
     selfLink: /apis/config.openshift.io/v1/clusteroperators/console
     uid: 960364aa-3ae1-11e9-bad4-0a97b6ba9358
   spec: {}
   status:
     conditions:
     - lastTransitionTime: 2019-02-27T22:46:58Z
       status: "False"
       type: Failing
     - lastTransitionTime: 2019-02-27T22:50:12Z
       status: "False"
       type: Progressing
     - lastTransitionTime: 2019-02-27T22:50:12Z
       status: "True"
       type: Available
     - lastTransitionTime: 2019-02-27T22:46:57Z
       status: "True"
       type: Upgradeable
     extension: null
     relatedObjects:
     - group: operator.openshift.io
       name: cluster
       resource: consoles
     - group: config.openshift.io
       name: cluster
       resource: consoles
     - group: oauth.openshift.io
       name: console
       resource: oauthclients
     - group: ""
       name: openshift-console-operator
       resource: namespaces
     - group: ""
       name: openshift-console
       resource: namespaces
     versions: null

2. 次のコマンドを実行して、コンソール URL を手動で取得します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get route console -n openshift-console \
        -o=jsonpath='{.spec.host}' console-openshift-console.apps.adahiya-1.devcluster.openshift.com

手順

1. 次のコマンドを使用して、クラスターから証明書を取得します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get configmaps default-ingress-cert \
        -n openshift-config-managed -o=jsonpath='{.data.ca-bundle\.crt}'

   -----BEGIN CERTIFICATE-----
   MIIC/TCCAeWgAwIBAgIBATANBgkqhkiG9w0BAQsFADAuMSwwKgYDVQQDDCNjbHVz
   dGVyLWluZ3Jlc3Mtb3BlcmF0b3JAMTU1MTMwNzU4OTAeFw0xOTAyMjcyMjQ2Mjha
   Fw0yMTAyMjYyMjQ2MjlaMC4xLDAqBgNVBAMMI2NsdXN0ZXItaW5ncmVzcy1vcGVy
   YXRvckAxNTUxMzA3NTg5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
   uCA4fQ+2YXoXSUL4h/mcvJfrgpBfKBW5hfB8NcgXeCYiQPnCKblH1sEQnI3VC5Pk
   2OfNCF3PUlfm4i8CHC95a7nCkRjmJNg1gVrWCvS/ohLgnO0BvszSiRLxIpuo3C4S
   EVqqvxValHcbdAXWgZLQoYZXV7RMz8yZjl5CfhDaaItyBFj3GtIJkXgUwp/5sUfI
   LDXW8MM6AXfuG+kweLdLCMm3g8WLLfLBLvVBKB+4IhIH7ll0buOz04RKhnYN+Ebw
   tcvFi55vwuUCWMnGhWHGEQ8sWm/wLnNlOwsUz7S1/sW8nj87GFHzgkaVM9EOnoNI
   gKhMBK9ItNzjrP6dgiKBCQIDAQABoyYwJDAOBgNVHQ8BAf8EBAMCAqQwEgYDVR0T
   AQH/BAgwBgEB/wIBADANBgkqhkiG9w0BAQsFAAOCAQEAq+vi0sFKudaZ9aUQMMha
   CeWx9CZvZBblnAWT/61UdpZKpFi4eJ2d33lGcfKwHOi2NP/iSKQBebfG0iNLVVPz
   vwLbSG1i9R9GLdAbnHpPT9UG6fLaDIoKpnKiBfGENfxeiq5vTln2bAgivxrVlyiq
   +MdDXFAWb6V4u2xh6RChI7akNsS3oU9PZ9YOs5e8vJp2YAEphht05X0swA+X8V8T
   C278FFifpo0h3Q0Dbv8Rfn4UpBEtN4KkLeS+JeT+0o2XOsFZp7Uhr9yFIodRsnNo
   H/Uwmab28ocNrGNiEVaVH6eTTQeeZuOdoQzUbClElpVmkrNGY0M42K0PvOQ/e7+y
   AQ==
   -----END CERTIFICATE-----

2. ${INSTALL_DIR}/auth/kubeconfig ファイルの client-certificate-authority-data フィールドに証明書を追加します。

手順

1. ノードに物理的にアクセスできる場合は、コンソールの出力をチェックして、正常に起動したかどうかを確認します。ノードがまだブート設定を取得中の場合は、ブートストラップ仮想マシンに問題がある可能性があります。
2. install-config.yaml ファイルで sshKey: '<ssh_pub_key>' が設定されていることを確認します。<ssh_pub_key> は、プロビジョナーノード上の kni ユーザーの公開鍵です。

手順

1. provisioning ネットワークへのネットワークの接続を確認します。
2. PXE が provisioning ネットワークの NIC で有効にされており、PXE がその他のすべての NIC について無効にされていることを確認します。

3. install-config.yaml 設定ファイルに、provisioning ネットワークに接続されている NIC の rootDeviceHints パラメーターとブート MAC アドレスが含まれていることを確認します。以下に例を示します。

   コントロールプレーンノードの設定

   bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC

   ワーカーノード設定

   bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC

手順

1. 次のコマンドを実行して、Machine API Operator を確認します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \
      --namespace=openshift-machine-api get deployments

   ご使用の環境で ${INSTALL_DIR} が設定されていない場合は、値をインストールディレクトリーの名前に置き換えます。

   出力例

   NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
   cluster-autoscaler-operator   1/1     1            1           86m
   cluster-baremetal-operator    1/1     1            1           86m
   machine-api-controllers       1/1     1            1           85m
   machine-api-operator          1/1     1            1           86m

2. 次のコマンドを実行して、マシンコントローラーのログを確認します。

   $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \
        --namespace=openshift-machine-api logs deployments/machine-api-controllers \
        --container=machine-controller

手順

1. 次のコマンドを実行して、ネットワーク設定が存在することを確認します。

   $ oc get network -o yaml cluster

   存在しない場合は、インストールプログラムによって作成されていません。理由を確認するには、次のコマンドを実行します。

   $ openshift-install create manifests

   マニフェストを確認して、インストールプログラムがネットワーク設定を作成しなかった理由を特定します。

2. 次のコマンドを入力して、ネットワークが実行中であることを確認します。

   $ oc get po -n openshift-network-operator

手順

1. DNS A/AAAA または CNAME レコードを追加して、API ロードバランサーを内部的に識別します。たとえば、dnsmasq を使用する場合は、dnsmasq.conf 設定ファイルを変更します。

   $ sudo nano /etc/dnsmasq.conf

   address=/api-int.<cluster_name>.<base_domain>/<IP_address>
   address=/api-int.mycluster.example.com/192.168.1.10
   address=/api-int.mycluster.example.com/2001:0db8:85a3:0000:0000:8a2e:0370:7334

2. DNS PTR レコードを追加して、API ロードバランサーを内部的に識別します。たとえば、dnsmasq を使用する場合は、dnsmasq.conf 設定ファイルを変更します。

   $ sudo nano /etc/dnsmasq.conf

   ptr-record=<IP_address>.in-addr.arpa,api-int.<cluster_name>.<base_domain>
   ptr-record=10.1.168.192.in-addr.arpa,api-int.mycluster.example.com

3. DNS サーバーを再起動します。たとえば、dnsmasq を使用する場合は、以下のコマンドを実行します。

   $ sudo systemctl restart dnsmasq

手順

1. OpenShift Container Platform クラスターをインストールする前に、次のコマンドを使用して、すべてのベアメタルノードの電源をオフにします。

   $ ipmitool -I lanplus -U <user> -P <password> -H <management_server_ip> power off

2. 次のスクリプトを使用して、以前のデプロイ試行時に残った古いブートストラップリソースをすべて削除します。

   for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
   do
     sudo virsh destroy $i;
     sudo virsh undefine $i;
     sudo virsh vol-delete $i --pool $i;
     sudo virsh vol-delete $i.ign --pool $i;
     sudo virsh pool-destroy $i;
     sudo virsh pool-undefine $i;
   done

3. 次のコマンドを使用して、以前のインストールにより生成されたアーティファクトを削除します。

   $ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \
   .openshift_install.log .openshift_install_state.json

4. 次のコマンドを使用して、OpenShift Container Platform マニフェストを再作成します。

   $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests

手順

1. 認証が正常に行われていることを確認します。

   $ /usr/local/bin/oc adm release mirror \
     -a pull-secret-update.json
     --from=$UPSTREAM_REPO \
     --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \
     --to=$LOCAL_REG/$LOCAL_REPO

   注記

   インストールイメージのミラーリングに使用される変数の出力例:

   UPSTREAM_REPO=${RELEASE_IMAGE}
   LOCAL_REG=<registry_FQDN>:<registry_port>
   LOCAL_REPO='ocp4/openshift4'

   RELEASE_IMAGE および VERSION の値は、OpenShift インストールの環境のセットアップセクションの OpenShift Installer の取得 の手順で設定されています。

2. レジストリーのミラーリング後に、非接続環境でこれにアクセスできることを確認します。

   $ curl -k -u <user>:<password> https://registry.example.com:<registry_port>/v2/_catalog
   {"repositories":["<Repo_Name>"]}

手順

1. OpenShift Container Platform クラスターノードが適切にインストールされると、以下の Ready 状態が STATUS 列に表示されます。

   $ oc get nodes

   NAME                   STATUS   ROLES           AGE  VERSION
   master-0.example.com   Ready    master,worker   4h   v1.28.5
   master-1.example.com   Ready    master,worker   4h   v1.28.5
   master-2.example.com   Ready    master,worker   4h   v1.28.5

2. インストールプログラムによってすべての Pod が正常にデプロイされたことを確認します。以下のコマンドは、実行中の Pod、または出力の一部として完了した Pod を削除します。

   $ oc get pods --all-namespaces | grep -iv running | grep -iv complete