OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

安装故障排除

安装程序工作流程故障排除

在对安装环境进行故障排除之前，务必了解安装程序配置的裸机安装的整体流程。下图显示了环境的逐步故障排除流程。

Flow-Diagram-1

工作流程 1/4 显示了当install-config.yaml文件有错误或Red Hat Enterprise Linux CoreOS (RHCOS)镜像不可访问时的故障排除工作流程。有关故障排除建议，请参阅install-config.yaml故障排除。

Flow-Diagram-2

工作流程 2/4 显示了引导虚拟机问题、无法启动集群节点的引导虚拟机和检查日志的故障排除工作流程。在没有provisioning网络的情况下安装OpenShift Container Platform集群时，此工作流程不适用。

Flow-Diagram-3

工作流程 3/4 显示了无法 PXE 启动的集群节点的故障排除工作流程。如果使用 Redfish 虚拟介质进行安装，则每个节点必须满足安装程序才能部署节点的最低固件要求。有关更多详细信息，请参阅“先决条件”部分中的使用虚拟介质安装的固件要求。

Flow-Diagram-4

工作流程 4/4 显示了从不可访问的 API到已验证的安装的故障排除工作流程。

install-config.yaml故障排除

install-config.yaml 配置文件包含 OpenShift Container Platform 集群中所有节点的信息。该文件包含必要的选项，包括但不限于 apiVersion、baseDomain、imageContentSources 和虚拟 IP 地址。如果在 OpenShift Container Platform 集群部署的早期阶段出现错误，则错误很可能位于 install-config.yaml 配置文件中。

步骤

  1. 请参考 YAML 指南。

  2. 使用 语法检查工具 验证 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，则表示存储引导 VM 镜像的 Web 服务器已做出有效响应。

排查引导 VM 问题

OpenShift Container Platform 安装程序会生成一个引导节点虚拟机，用于配置 OpenShift Container Platform 集群节点。

步骤

  1. 触发安装程序后约 10 到 15 分钟后，使用 virsh 命令检查引导 VM 是否正在运行

    $ sudo virsh list
     Id    Name                           State
 --------------------------------------------
 12    openshift-xf6fq-bootstrap      running

    引导 VM 的名称始终为集群名称后跟一组随机字符，最后以“bootstrap”结尾。

  2. 如果 10-15 分钟后引导 VM 仍未运行，请执行以下命令验证 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

    如果引导 VM 正在运行，请登录到它。

  3. 使用 virsh console 命令查找引导 VM 的 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 集群时，必须使用公网 IP 地址，而不是私网 IP 地址，例如 172.22.0.2。

  4. 获得 IP 地址后，使用 ssh 命令登录到引导 VM

    在上一步的控制台输出中，您可以使用 ens3 提供的 IPv6 IP 地址或 ens4 提供的 IPv4 IP 地址。

    		 
    $ ssh core@172.22.0.2

如果无法登录到引导 VM，则很可能遇到以下情况之一

  • 无法访问 172.22.0.0/24 网络。验证提供程序和 provisioning 网络桥之间的网络连接。如果您使用的是 provisioning 网络，则可能会出现此问题。

  • 无法通过公网访问引导 VM。当尝试通过 baremetal 网络进行 SSH 连接时，请验证 provisioner 主机上 baremetal 网络桥周围的连接性。

  • 遇到 Permission denied (publickey,password,keyboard-interactive) 错误。当尝试访问引导 VM 时，可能会出现 Permission denied 错误。请验证尝试登录 VM 的用户的 SSH 密钥是否已设置在 install-config.yaml 文件中。

引导 VM 无法启动集群节点

在部署过程中，引导 VM 可能无法启动集群节点，从而阻止 VM 使用 RHCOS 镜像配置节点。这种情况可能是由于以下原因造成的：

  • install-config.yaml 文件存在问题。

  • 使用 baremetal 网络时带外网络访问出现问题。

要验证问题，有三个与 ironic 相关的容器

  • ironic

  • ironic-inspector

步骤

  1. 登录到引导 VM

    $ 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 登录到节点。

可能原因

部署启动时，集群节点可能处于 ON 状态。

解决方案

通过 IPMI 关闭 OpenShift Container Platform 集群节点后再开始安装。

$ ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off

检查日志

如果遇到下载或访问 RHCOS 镜像的问题，首先验证 install-config.yaml 配置文件中 URL 是否正确。

托管 RHCOS 镜像的内部 Web 服务器示例
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0

coreos-downloader 容器从 Web 服务器或外部 quay.io 注册表下载资源，具体取决于 install-config.yaml 配置文件中的指定。验证 coreos-downloader 容器是否已启动并运行，并根据需要检查其日志。

步骤

  1. 登录到引导 VM

    $ ssh core@172.22.0.2

  2. 通过运行以下命令检查引导 VM 中 coreos-downloader 容器的状态

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

    如果引导 VM 无法访问镜像的 URL，请使用 curl 命令验证 VM 是否可以访问镜像。

  3. 要检查指示在部署阶段启动的所有容器的 bootkube 日志，请执行以下操作：

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

  4. 验证所有 pod（包括 dnsmasq、mariadb、httpd 和 ironic）是否正在运行

    [core@localhost ~]$ sudo podman ps

  5. 如果 pod 出现问题，请检查出现问题的容器的日志。要检查 ironic 服务的日志，请运行以下命令：

    [core@localhost ~]$ sudo podman logs ironic

调查 Kubernetes API 不可用

当 Kubernetes API 不可用时，请检查控制平面节点以确保它们正在运行正确的组件。还要检查主机名解析。

步骤

  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 网络上。

排查集群初始化失败

安装程序使用集群版本操作符创建 OpenShift Container Platform 集群的所有组件。当安装程序无法初始化集群时，您可以从ClusterVersion和ClusterOperator对象中检索最重要的信息。

步骤

  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

    该命令返回集群操作符的状态。

    示例输出：
    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. 运行以下命令检查单个集群操作符：

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> -oyaml (1)
    1 将<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. 要获取集群操作符的状态条件，请运行以下命令：

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

    将<operator>替换为上述操作符之一的名称。

    示例输出：
    Available True Successfully rolled out the stack
Progressing False
Failing False

  6. 要检索集群操作符拥有的对象列表，请执行以下命令：

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

故障排除：无法获取控制台 URL

安装程序使用openshift-console命名空间内的[route][route-object]检索 OpenShift Container Platform 控制台的 URL。如果安装程序无法检索控制台的 URL，请使用以下步骤。

步骤

  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

故障排除：无法将 Ingress 证书添加到 kubeconfig

安装程序会将默认的 Ingress 证书添加到${INSTALL_DIR}/auth/kubeconfig中受信任的客户端证书颁发机构列表。如果安装程序无法将 Ingress 证书添加到kubeconfig文件，您可以从集群中检索证书并添加它。

步骤

  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字段中。

故障排除：SSH 无法访问集群节点

出于安全考虑，默认情况下您无法从集群外部 SSH 登录集群。但是，您可以从供应程序节点访问控制平面和工作节点。如果您无法从供应程序节点 SSH 登录集群节点，则节点可能正在等待引导 VM。控制平面节点从引导 VM 检索其引导配置，如果它们未检索到引导配置，则无法成功引导。

步骤

  1. 如果您有权访问节点的物理设备，请检查其控制台输出以确定它们是否已成功引导。如果节点仍在检索其引导配置，则引导 VM 可能存在问题。

  2. 确保您已在install-config.yaml文件中配置了sshKey: '<ssh_pub_key>'设置，其中<ssh_pub_key>是供应程序节点上kni用户的公钥。

集群节点无法进行 PXE 引导

当 OpenShift Container Platform 集群节点无法进行 PXE 引导时，请对无法进行 PXE 引导的集群节点执行以下检查。在不使用provisioning网络安装 OpenShift Container Platform 集群时，此步骤不适用。

步骤

  1. 检查与provisioning网络的网络连接。

  2. 确保为provisioning网络的网卡启用了 PXE，并为所有其他网卡禁用了 PXE。

  3. 验证install-config.yaml配置文件是否包含连接到provisioning网络的网卡的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

安装未创建任何工作节点

安装程序不会直接配置工作节点。相反，机器 API 操作符会在受支持的平台上向上和向下扩展节点。如果在 15 到 20 分钟后（取决于集群互联网连接速度）未创建工作节点，请调查机器 API 操作符。

步骤

  1. 运行以下命令检查机器 API 操作符：

    $ 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

无法使用 BMC 发现新的裸机主机

在某些情况下，安装程序将无法发现新的裸机主机并发出错误，因为它无法挂载远程虚拟媒体共享。

例如：

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST
https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia
returned code 400.
Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information
Extended information: [
  {
    "Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.",
    "MessageArgs": [
      "https://<ironic_address>/redfish/boot-<uuid>.iso"
    ],
    "MessageArgs@odata.count": 1,
    "MessageId": "IDRAC.2.5.RAC0720",
    "RelatedProperties": [
      "#/Image"
    ],
    "RelatedProperties@odata.count": 1,
    "Resolution": "Retry the operation.",
    "Severity": "Informational"
  }
].

在这种情况下，如果您使用的是具有未知证书颁发机构的虚拟媒体，您可以配置基板管理控制器 (BMC) 远程文件共享设置以信任未知证书颁发机构，以避免此错误。

此解决方案已在具有 Dell iDRAC 9 和固件版本 5.10.50 的 OpenShift Container Platform 4.11 上进行了测试。

故障排除：工作节点无法加入集群

安装程序配置的集群使用包含api-int.<cluster_name>.<base_domain> URL 的 DNS 条目的 DNS 服务器进行部署。如果集群中的节点使用外部或上游 DNS 服务器来解析api-int.<cluster_name>.<base_domain> URL，并且没有这样的条目，则工作节点可能无法加入集群。确保集群中的所有节点都可以解析域名。

步骤

  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

这些记录必须能够从集群中的所有节点解析。

清理之前的安装

如果之前的部署失败，请在尝试再次部署 OpenShift Container Platform 之前删除失败尝试中的工件。

步骤

  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

创建注册表时出现的问题

创建断开连接的注册表时，尝试镜像注册表时可能会遇到“用户未授权”错误。如果未能将新的身份验证追加到现有的pull-secret.txt文件中，则可能会出现此错误。

步骤

  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 安装程序步骤中设置。

  2. 镜像注册表后，确认您可以在断开连接的环境中访问它

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

其他问题

解决runtime network not ready错误

集群部署后，您可能会收到以下错误

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`

集群网络操作员负责根据安装程序创建的特殊对象部署网络组件。它在安装过程的早期运行，在控制平面（主节点）启动后但引导控制平面拆除之前运行。这可能表示安装程序存在更细微的问题，例如控制平面（主节点）启动时间过长或apiserver通信出现问题。

步骤

  1. 检查openshift-network-operator命名空间中的 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"

    在具有三个或更多控制平面节点的高可用性集群中，操作员将执行领导者选举，所有其他操作员将休眠。有关更多详细信息，请参阅故障排除。

解决“找不到与 rootDeviceHints 匹配的磁盘”错误消息

部署集群后，您可能会收到以下错误消息

No disk found with matching rootDeviceHints

要解决找不到与 rootDeviceHints 匹配的磁盘错误消息，一个临时的解决方法是将rootDeviceHints更改为minSizeGigabytes: 300。

更改rootDeviceHints设置后，启动 CoreOS，然后使用以下命令验证磁盘信息

$ udevadm info /dev/sda

如果您使用的是 DL360 Gen 10 服务器，请注意它们具有 SD 卡插槽，该插槽可能会分配/dev/sda设备名称。如果服务器中没有 SD 卡，则可能会导致冲突。确保在服务器的 BIOS 设置中禁用 SD 卡插槽。

如果minSizeGigabytes解决方法无法满足要求，您可能需要将rootDeviceHints恢复为/dev/sda。此更改允许 ironic 映像成功启动。

解决此问题的另一种方法是使用磁盘的序列号。但是，请注意，查找序列号可能具有挑战性，并且可能会使配置文件的可读性降低。如果您选择此方法，请确保使用前面介绍的命令收集序列号并将其添加到您的配置中。

集群节点无法通过 DHCP 获取正确的 IPv6 地址

如果集群节点无法通过 DHCP 获取正确的 IPv6 地址，请检查以下内容

  1. 确保保留的 IPv6 地址位于 DHCP 范围之外。

  2. 在 DHCP 服务器上的 IP 地址预留中，确保预留指定了正确的 DHCP 唯一标识符 (DUID)。例如

    # 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. 确保路由公告正常工作。

  4. 确保 DHCP 服务器正在监听提供 IP 地址范围的所需接口。

集群节点无法通过 DHCP 获取正确的主机名

在 IPv6 部署期间，集群节点必须通过 DHCP 获取其主机名。有时NetworkManager不会立即分配主机名。控制平面（主节点）可能会报告错误，例如

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service

此错误表明集群节点可能在未首先从 DHCP 服务器接收主机名的情况下启动，这会导致kubelet使用localhost.localdomain主机名启动。要解决此错误，请强制节点更新主机名。

步骤

  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

如果集群启动并运行后集群节点无法通过 DHCP 获取正确的主机名（例如在重新引导期间），则集群将具有挂起的csr。**不要**批准csr，否则可能会出现其他问题。

处理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>

路由无法到达端点

在安装过程中，可能会遇到虚拟路由冗余协议 (VRRP) 冲突。如果之前用过的 OpenShift Container Platform 节点（曾经是使用特定集群名称的集群部署的一部分）仍在运行，但不是当前使用相同集群名称的 OpenShift Container Platform 集群部署的一部分，则可能会发生此冲突。例如，一个集群使用集群名称openshift进行部署，部署了三个控制平面（主）节点和三个工作节点。稍后，单独的安装使用相同的集群名称openshift，但是此重新部署只安装了三个控制平面（主）节点，留下之前部署的三个工作节点处于ON状态。这可能会导致虚拟路由标识符 (VRID) 冲突和 VRRP 冲突。

  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 可能无法成功启动。

首次启动期间 Ignition 失败

在首次启动期间，Ignition 配置可能会失败。

步骤

  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

NTP 时间不同步

OpenShift Container Platform 集群的部署依赖于集群节点之间 NTP 同步的时钟。如果没有同步的时钟，如果时间差大于两秒，则部署可能会由于时钟漂移而失败。

步骤

  1. 检查集群节点的AGE差异。例如：

    $ oc get nodes
    NAME                         STATUS   ROLES    AGE   VERSION
master-0.cloud.example.com   Ready    master   145m   v1.30.3
master-1.cloud.example.com   Ready    master   135m   v1.30.3
master-2.cloud.example.com   Ready    master   145m   v1.30.3
worker-2.cloud.example.com   Ready    worker   100m   v1.30.3

  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. 创建一个 Butane 配置文件，其中包含要传递给节点的chrony.conf文件的内容。在下面的示例中，创建99-master-chrony.bu将文件添加到控制平面节点。您可以修改工作节点的文件或对工作角色重复此过程。

    有关 Butane 的信息，请参阅“使用 Butane 创建机器配置”。

    		 
    variant: openshift
version: 4.17.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

    然后，继续创建集群。

查看安装情况

安装完成后，请确保安装程序已成功部署节点和 Pod。

步骤

  1. 当 OpenShift Container Platform 集群节点正确安装后，STATUS列中会显示以下Ready状态：

    $ oc get nodes
    NAME                   STATUS   ROLES           AGE  VERSION
master-0.example.com   Ready    master,worker   4h   v1.30.3
master-1.example.com   Ready    master,worker   4h   v1.30.3
master-2.example.com   Ready    master,worker   4h   v1.30.3

  2. 确认安装程序已成功部署所有 Pod。以下命令将删除作为输出的一部分仍在运行或已完成的任何 Pod。

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