支持

流程

1. 找到在 OpenShift Container Platform 集群中运行的 Prometheus 服务的 URL：

   $ oc get route prometheus-k8s -n openshift-monitoring -o jsonpath="{.spec.host}"

2. 访问此 URL。

3. 在 Expression 中输入查询条件并点 Execute：

   {__name__=~"cluster:usage:.*|count:up0|count:up1|cluster_version|cluster_version_available_updates|cluster_operator_up|cluster_operator_conditions|cluster_version_payload|cluster_installer|cluster_infrastructure_provider|cluster_feature_set|instance:etcd_object_counts:sum|ALERTS|code:apiserver_request_total:rate:sum|cluster:capacity_cpu_cores:sum|cluster:capacity_memory_bytes:sum|cluster:cpu_usage_cores:sum|cluster:memory_usage_bytes:sum|openshift:cpu_usage_cores:sum|openshift:memory_usage_bytes:sum|workload:cpu_usage_cores:sum|workload:memory_usage_bytes:sum|cluster:virt_platform_nodes:sum|cluster:node_instance_type_count:sum|cnv:vmi_status_running:count|node_role_os_version_machine:cpu_capacity_cores:sum|node_role_os_version_machine:cpu_capacity_sockets:sum|subscription_sync_total|csv_succeeded|csv_abnormal|ceph_cluster_total_bytes|ceph_cluster_total_used_raw_bytes|ceph_health_status|job:ceph_osd_metadata:count|job:kube_pv:count|job:ceph_pools_iops:total|job:ceph_pools_iops_bytes:total|job:ceph_versions_running:count|job:noobaa_total_unhealthy_buckets:sum|job:noobaa_bucket_count:sum|job:noobaa_total_object_count:sum|noobaa_accounts_num|noobaa_total_usage|console_url|cluster:network_attachment_definition_instances:max|cluster:network_attachment_definition_enabled_instance_up:max|insightsclient_request_send_total|cam_app_workload_migrations|cluster:apiserver_current_inflight_requests:sum:max_over_time:2m|cluster:telemetry_selected_series:count",alertstate=~"firing|"}

   此查询复制 Telemetry 对正在运行的 OpenShift Container Platform 集群的 Prometheus 服务所做的请求，并返回由 Telemetry 收集的完整时间序列集。

流程

1. 为 Insights Operator 查找当前正在运行的 pod 的名称：

   $ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

2. 复制 Insights Operator 收集的最近数据存档：

   $ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

流程

1. 把全局集群 pull secret 下载到本地文件系统。

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. 在文本编辑器中编辑所下载的 .dockerconfigjson 文件。

3. 删除 cloud.openshift.com JSON 条目，如：

   "cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}

4. 保存该文件。

流程

1. 可选： 要将新的 pull secret 附加到现有 pull secret 中，请完成以下步骤：

   1. 输入以下命令下载 pull secret：

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      提供 pull secret 文件的路径。

   2. 输入以下命令来添加新 pull secret：

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      提供新的 registry。您可以在同一个 registry 中包含多个软件仓库，例如：--registry="<registry/my-namespace/my-repository>"。

      2

      提供新 registry 的凭据。

      3

      提供 pull secret 文件的路径。

      另外，您可以对 pull secret 文件执行手动更新。

2. 输入以下命令为您的集群更新全局 pull secret：

   $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   提供新 pull secret 文件的路径。

   该更新将推广至所有节点，可能需要一些时间，具体取决于集群大小。

   注意

   从 OpenShift Container Platform 4.7.4 开始，对全局 pull secret 的更改不再触发节点排空或重启。

流程

1. 进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations。

   根据结果，Insights Advisor 会显示以下之一：

   • 如果 Insights 没有发现任何问题，则不会找到匹配的建议。
   • Insights 检测到的问题列表，按风险分组（低、中、重要和严重）。
   • No clusters yet，如果 Insights 还没有分析集群。这个分析会在集群安装、注册并连接到互联网后立即开始。

2. 如果显示任何问题，请点击条目前面的 > 图标以了解更多详情。

   根据具体问题，详细信息还可以包含来自红帽有关此问题的更多信息的链接。

流程

1. 进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations。

2. 点 Clusters Impacted 和 Status 过滤器旁边的 X 图标。

   现在，您可以浏览集群的所有潜在建议。

流程

1. 进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations。
2. 点要禁用的建议名称。您会被定向到单一推荐页面。

3. 禁用单个集群的建议：

   1. 点击该集群的 Options 菜单 ，然后点 Disable recommendations for cluster。
   2. 输入说明并单击 保存。

4. 禁用所有集群的建议：

   1. 点 Actions → Disable recommendations。
   2. 输入说明并单击 保存。

流程

1. 进入 Red Hat Hybrid Cloud Console 上的 Advisor → Recommendations。
2. 按 Status → Disabled 过滤建议。
3. 找到启用的建议。
4. 点击 Options 菜单 ，然后点 Enable recommendations。

流程

1. 在 OpenShift Container Platform Web 控制台中进入 Home → Overview。

2. 点 Status 卡上的 Insights。

   弹出窗口列出了按风险分组的潜在问题。点击独立类别或查看 Insights Advisor 中的所有建议，以显示更多详情。

流程

1. 为 Insights Operator 查找正在运行的 pod 的名称：

   $ oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running

2. 复制 Insights Operator 收集的最近数据存档：

   $ oc cp openshift-insights/<insights_operator_pod_name>:/var/lib/insights-operator ./insights-data 1

   1

   将 <insights_operator_pod_name> 替换为上一命令中的 pod 名称输出。

流程

1. 在归档中，打开 /insights-operator/gathers.json。

   文件包含 Insights Operator 收集操作列表：

       {
         "name": "clusterconfig/authentication",
         "duration_in_ms": 730, 1
         "records_count": 1,
         "errors": null,
         "panic": null
       }

   1

   duration_in_ms 是每个收集操作的时间（毫秒）。

2. 检查每个收集操作是否有异常情况。

流程

1. 使用此模板创建名为 gather-job.yaml 的文件：

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: insights-operator-job
     annotations:
       config.openshift.io/inject-proxy: insights-operator
   spec:
     backoffLimit: 6
     ttlSecondsAfterFinished: 600
     template:
       spec:
         restartPolicy: OnFailure
         serviceAccountName: operator
         nodeSelector:
           beta.kubernetes.io/os: linux
           node-role.kubernetes.io/master: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/master
           operator: Exists
         - effect: NoExecute
           key: node.kubernetes.io/unreachable
           operator: Exists
           tolerationSeconds: 900
         - effect: NoExecute
           key: node.kubernetes.io/not-ready
           operator: Exists
           tolerationSeconds: 900
         volumes:
         - name: snapshots
           emptyDir: {}
         - name: service-ca-bundle
           configMap:
             name: service-ca-bundle
             optional: true
         initContainers:
         - name: insights-operator
           image: quay.io/openshift/origin-insights-operator:latest
           terminationMessagePolicy: FallbackToLogsOnError
           volumeMounts:
           - name: snapshots
             mountPath: /var/lib/insights-operator
           - name: service-ca-bundle
             mountPath: /var/run/configmaps/service-ca-bundle
             readOnly: true
           ports:
           - containerPort: 8443
             name: https
           resources:
             requests:
               cpu: 10m
               memory: 70Mi
           args:
           - gather
           - -v=4
           - --config=/etc/insights-operator/server.yaml
         containers:
           - name: sleepy
             image: quay.io/openshift/origin-base:latest
             args:
               - /bin/sh
               - -c
               - sleep 10m
             volumeMounts: [{name: snapshots, mountPath: /var/lib/insights-operator}]

2. 复制 insights-operator 镜像版本：

   $ oc get -n openshift-insights deployment insights-operator -o yaml

3. 将您的镜像版本粘贴到 gather-job.yaml 中：

   initContainers:
         - name: insights-operator
           image: <your_insights_operator_image_version>
           terminationMessagePolicy: FallbackToLogsOnError
           volumeMounts:

4. 创建收集作业：

   $ oc apply -n openshift-insights -f gather-job.yaml

5. 查找作业 pod 的名称：

   $ oc describe -n openshift-insights job/insights-operator-job

   输出示例

   Events:
     Type    Reason            Age    From            Message
     ----    ------            ----   ----            -------
     Normal  SuccessfulCreate  7m18s  job-controller  Created pod: insights-operator-job-<your_job>

   其中 insights-operator-job-<your_job> 是 pod 的名称。

6. 验证操作是否已完成：

   $ oc logs -n openshift-insights insights-operator-job-<your_job> insights-operator

   输出示例

   I0407 11:55:38.192084       1 diskrecorder.go:34] Wrote 108 records to disk in 33ms

7. 保存创建的归档：

   $ oc cp openshift-insights/insights-operator-job-<your_job>:/var/lib/insights-operator ./insights-data

8. 清理作业：

   $ oc delete -n openshift-insights job insights-operator-job

流程

1. 下载 dockerconfig.json 文件：

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. 复制来自 dockerconfig.json 文件的 "cloud.openshift.com" "auth" 令牌：

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "asd@redhat.com"
       }
   }

3. 将存档上传到 console.redhat.com ：

   $ curl -v -H "User-Agent: insights-operator/one10time200gather184a34f6a168926d93c330 cluster/<cluster_id>" -H "Authorization: Bearer <your_token>" -F "upload=@<path_to_archive>; type=application/vnd.redhat.openshift.periodic+tar" https://console.redhat.com/api/ingress/v1/upload

   其中 <cluster_id> 是集群 ID，<your_token> 是来自 pull secret 的令牌，<path_to_archive> 是 Insights Operator 归档的路径。

   如果操作成功，该命令会返回 "request_id" 和 "account_number"：

   输出示例

   * Connection #0 to host console.redhat.com left intact
   {"request_id":"393a7cf1093e434ea8dd4ab3eb28884c","upload":{"account_number":"6274079"}}%

验证步骤

1. 登录到 https://console.redhat.com/openshift。
2. 点左侧面板中的 Cluster 菜单。
3. 要显示集群详情，点集群名称。

4. 打开集群的 Insights Advisor 选项卡。

   如果上传成功，标签会显示以下之一：

   • 如果 Insights Advisor 没有发现任何问题，代表您的集群已通过了所有建议。
   • Insights Advisor 检测到的问题列表，按风险级别排列（低、中、重要和严重）。

流程

1. 导航到 Workloads → Secrets。
2. 选择 openshift-config 项目。
3. 使用 Search by name 字段搜索 support secret。如果不存在，请点击 Create → Key/value secret 创建它。
4. 点击 Options 菜单 ，然后点 Edit Secret。
5. 单击 Add Key/Value。
6. 创建名为 enableGlobalObfuscation 的键，值为 true，然后点 Save。
7. 进入 Workloads → Pods
8. 选择 openshift-insights 项目。
9. 查找 insights-operator pod。
10. 要重启 insights-operator pod，点 Options 菜单 ，然后点 Delete Pod。

验证

1. 导航到 Workloads → Secrets。
2. 选择 openshift-insights 项目。
3. 使用 Search by name 字段搜索 obfuscat ion-translation-table secret。

流程

1. 进入存储 must-gather 数据的目录。

   注意

   如果集群使用受限网络，则需要执行额外的步骤。如果您镜像的容器镜像仓库有一个信任的 CA，您必须首先将这个信任的 CA 添加到集群中。对于受限网络中的所有集群，您必须导入默认的 must-gather 镜像作为镜像流。

   $ oc import-image is/must-gather -n openshift

2. 运行 oc adm must-gather 命令：

   $ oc adm must-gather

   注意

   因为这个命令会默认会选择一个随机 control plane 节点，所以 pod 可能会被调度到处于 NotReady 和 SchedulingDisabled 状态的 control plane 节点。

   1. 如果此命令失败，例如，您无法在集群中调度 pod，则使用 oc adm inspect 命令来收集特定资源的信息。

      注意

      请联络红帽支持以获取推荐收集的资源信息。

3. 从刚刚在您的工作目录中创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   务必将 must-gather-local.5421342344627712289/ 替换为实际目录名称。

4. 在红帽客户门户中为您的问题单附上压缩文件。

流程

1. 进入存储 must-gather 数据的目录。

2. 使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。例如，使用以下命令可收集默认集群数据和 OpenShift Virtualization 特定信息：

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
    --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.8.7 2

   1

   默认 OpenShift Container Platform must-gather 镜像

   2

   OpenShift Virtualization 的 must-gather 镜像

   您可以将 must-gather 工具与额外参数搭配使用，以收集集群中与 OpenShift Logging 和 Red Hat OpenShift Logging Operator 相关的数据。对于 OpenShift Logging，运行以下命令：

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
    -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   例 5.1. OpenShift Logging 的 must-gather 输出示例

   ├── cluster-logging
   │  ├── clo
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  ├── clusterlogforwarder_cr
   │  │  ├── cr
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── logforwarding_cr
   │  ├── collector
   │  │  ├── fluentd-2tr64
   │  ├── eo
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
   │  ├── es
   │  │  ├── cluster-elasticsearch
   │  │  │  ├── aliases
   │  │  │  ├── health
   │  │  │  ├── indices
   │  │  │  ├── latest_documents.json
   │  │  │  ├── nodes
   │  │  │  ├── nodes_stats.json
   │  │  │  └── thread_pool
   │  │  ├── cr
   │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  │  └── logs
   │  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  ├── install
   │  │  ├── co_logs
   │  │  ├── install_plan
   │  │  ├── olmo_logs
   │  │  └── subscription
   │  └── kibana
   │     ├── cr
   │     ├── kibana-9d69668d4-2rkvz
   ├── cluster-scoped-resources
   │  └── core
   │     ├── nodes
   │     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
   │     └── persistentvolumes
   │        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
   ├── event-filter.html
   ├── gather-debug.log
   └── namespaces
      ├── openshift-logging
      │  ├── apps
      │  │  ├── daemonsets.yaml
      │  │  ├── deployments.yaml
      │  │  ├── replicasets.yaml
      │  │  └── statefulsets.yaml
      │  ├── batch
      │  │  ├── cronjobs.yaml
      │  │  └── jobs.yaml
      │  ├── core
      │  │  ├── configmaps.yaml
      │  │  ├── endpoints.yaml
      │  │  ├── events
      │  │  │  ├── elasticsearch-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
      │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
      │  │  ├── events.yaml
      │  │  ├── persistentvolumeclaims.yaml
      │  │  ├── pods.yaml
      │  │  ├── replicationcontrollers.yaml
      │  │  ├── secrets.yaml
      │  │  └── services.yaml
      │  ├── openshift-logging.yaml
      │  ├── pods
      │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
      │  │  │  ├── cluster-logging-operator
      │  │  │  │  └── cluster-logging-operator
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
      │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
      │  │  │  ├── cluster-logging-operator-registry
      │  │  │  │  └── cluster-logging-operator-registry
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
      │  │  │  └── mutate-csv-and-generate-sqlite-db
      │  │  │     └── mutate-csv-and-generate-sqlite-db
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
      │  │  ├── elasticsearch-im-app-1596030300-bpgcx
      │  │  │  ├── elasticsearch-im-app-1596030300-bpgcx.yaml
      │  │  │  └── indexmanagement
      │  │  │     └── indexmanagement
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── fluentd-2tr64
      │  │  │  ├── fluentd
      │  │  │  │  └── fluentd
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── fluentd-2tr64.yaml
      │  │  │  └── fluentd-init
      │  │  │     └── fluentd-init
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── kibana-9d69668d4-2rkvz
      │  │  │  ├── kibana
      │  │  │  │  └── kibana
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
      │  │  │  └── kibana-proxy
      │  │  │     └── kibana-proxy
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  └── route.openshift.io
      │     └── routes.yaml
      └── openshift-operators-redhat
         ├── ...

3. 使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。例如，使用以下命令可收集默认集群数据和 KubeVirt 特定信息：

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
    --image=quay.io/kubevirt/must-gather 2

   1

   默认 OpenShift Container Platform must-gather 镜像

   2

   KubeVirt 的 must-gather 镜像

4. 从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   务必将 must-gather-local.5421342344627712289/ 替换为实际目录名称。

5. 在红帽客户门户中为您的问题单附上压缩文件。

流程

1. 使用 -- /usr/bin/gather_audit_logs 标志运行 oc adm must-gather 命令：

   $ oc adm must-gather -- /usr/bin/gather_audit_logs

2. 从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

   1

   将 must-gather-local.472290403699006248 替换为实际目录名称。

3. 在红帽客户门户中为您的问题单附上压缩文件。

1. 创建 Ignition 配置文件。
2. 启动引导计算机并开始托管要启动的 control plane 机器（也称为 master 机器）所需的远程资源。
3. control plane 机器从 bootstrap 机器获取远程资源并完成启动。
4. control plane 机器使用 bootstrap 机器组成 etcd 集群。
5. bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
6. 临时 control plane 将生产环境 control plane 调度到 control plane 机器。
7. 临时 control plane 关机，并将控制权交给生产环境 control plane。
8. bootstrap 机器将 OpenShift Container Platform 组件添加到生产环境 control plane。
9. 安装程序关闭 bootstrap 机器。
10. control plane 设置 worker 节点。
11. control plane 以一组 Operator 的形式安装其他服务。
12. 集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建 worker 机器。

流程

1. 检查 haproxy systemd 服务是否活跃：

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. 验证负载均衡器是否在监听所需端口。以下示例引用端口 80、443、6443 和 22623。

   • 对于在 Red Hat Enterprise Linux（RHEL）6 上运行的 HAProxy 实例，请使用 netstat 命令验证端口状态：

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • 对于在 Red Hat Enterprise Linux（RHEL）7 或 8 上运行的 HAProxy 实例，请使用 ss 命令验证端口状态：

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     注意

     红帽建议在 Red Hat Enterprise Linux(RHEL)7 或更高版本中使用 ss 命令而不是 netstat。SS 由 iproute 软件包提供。有关 ss 命令的详情请参考 Red Hat Enterprise Linux（RHEL）7 性能调节指南。

3. 检查通配符 DNS 记录是否被解析为负载均衡器：

   $ dig <wildcard_fqdn> @<dns_server>

流程

1. 在安装过程中监控安装日志：

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. 在 bootstrap 节点引导后，监控 bootkube.service journald 单元日志。这可让您了解第一个 control plane 的 bootstrap。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注意

   bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。

3. 引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。

   1. 使用 oc 监控日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

4. 引导后，监控 control plane 节点上的 crio.service journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 监控日志：

      $ oc adm node-logs --role=master -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

流程

1. 如果可以访问 bootstrap 节点的控制台，请监控控制台，直到节点可以提供登录提示。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 bootstrap 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 bootstrap 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件，请输入以下命令：

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        如果收到 bootstrap Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，这表示请求成功。

     3. 如果未收到 Ignition 文件，请检查 Ignition 文件是否存在，是否在服务主机上具有适当的文件和 Web 服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 bootstrap 节点的控制台，以确定机制是否正确注入 bootstrap 节点 Ignition 文件。
3. 验证 bootstrap 节点分配的存储设备是否可用。
4. 验证 bootstrap 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 从 bootstrap 节点收集 bootkube.service journald 单元日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注意

   bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点（也称为 master 节点）上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。

6. 从 bootstrap 节点容器收集日志。

   1. 使用 bootstrap 节点上的 podman 来收集日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

7. 如果 bootstrap 过程失败，请验证以下内容。

   • 您可从安装主机解析 api.<cluster_name>.<base_domain>。
   • 负载均衡器代理端口 6443 连接到 bootstrap 和 control plane 节点。确保代理配置满足 OpenShift Container Platform 安装要求。

流程

1. 如果您可以访问 control plane 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 control plane 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 control plane 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

        $ grep -is 'master.ign' /var/log/httpd/access_log

        如果收到 master Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。

     3. 如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 control plane 节点的控制台，以确定机制是否正确注入 control plane 节点 Ignition 文件。
3. 检查分配给 control plane 节点的存储设备是否可用。
4. 验证 control plane 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 确定 control plane 节点状态。

   1. 查询 control plane 节点状态：

      $ oc get nodes

   2. 如果一个 control plane 节点没有处于 Ready 状态，检索详细的节点描述：

      $ oc describe node <master_node>

      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令：

6. 确定 OpenShift Container Platform SDN 状态。

   1. 在 openshift-sdn 命名空间内查看 sdn-controller、sdn 和 ovs 守护进程集的状态：

      $ oc get daemonsets -n openshift-sdn

   2. 如果这些资源列为 Not found，查看 openshift-sdn 命名空间中的 pod：

      $ oc get pods -n openshift-sdn

   3. 检查 openshift-sdn 命名空间中与失败的 OpenShift Container Platform SDN pod 相关的日志：

      $ oc logs <sdn_pod> -n openshift-sdn

7. 确定集群网络配置状态。

   1. 查看集群的网络配置是否存在：

      $ oc get network.config.openshift.io cluster -o yaml

   2. 如果安装程序无法创建网络配置，请再次生成 Kubernetes 清单并查看消息输出：

      $ ./openshift-install create manifests

   3. 查看 openshift-network-operator 命名空间中的 pod 状态，以确定 Cluster Network Operator（CNO）是否在运行：

      $ oc get pods -n openshift-network-operator

   4. 从 openshift-network-operator 命名空间中收集网络 Operator pod 日志：

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. 引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

9. 引导后，在 control plane 节点上检索 crio.service journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

10. 从 control plane 节点上的 /var/log/ 下的特定子目录收集日志。

    1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 control plane 节点上的 /var/log/openshift-apiserver/ 中的文件：

       $ oc adm node-logs --role=master --path=openshift-apiserver

    2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

       $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

    3. 如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

11. 使用 SSH 查看 control plane 节点容器日志。

    1. 列出容器：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. 使用 crictl 检索容器日志：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

12. 如果您遇到 control plane 节点配置问题，请验证 MCO、MCO 端点和 DNS 记录是否正常工作。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. 如果端点不响应，请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。

    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

       1. 对定义的 MCO 端点名称运行 DNS 查找：

          $ dig api-int.<cluster_name> @<dns_server>

       2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 检查证书的有效性：

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

流程

1. 检查 etcd pod 的状态。

   1. 查看 openshift-etcd 命名空间中的 pod 状态：

      $ oc get pods -n openshift-etcd

   2. 查看 openshift-etcd-operator 命名空间中的 pod 状态：

      $ oc get pods -n openshift-etcd-operator

2. 如果以上命令中列出的任何 pod 没有显示 Running 或 Completed 状态，请为 pod 收集诊断信息。

   1. 检查 pod 的事件：

      $ oc describe pod/<pod_name> -n <namespace>

   2. 检查 pod 的日志：

      $ oc logs pod/<pod_name> -n <namespace>

   3. 如果 pod 有多个容器，以上命令会创建一个错误并在错误消息中提供容器名称。检查每个容器的日志：

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>

3. 如果 API 无法正常工作，请使用 SSH 来查看每个 control plane 节点上的 etcd pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。

   1. 列出每个 control plane 节点上的 etcd pod：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-

   2. 对于没有显示 Ready 状态的 pod，详细检查 pod 状态。将 <pod_id> 替换为上一命令输出中列出的 pod ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>

   3. 列出与 pod 相关的容器：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

   4. 对于没有显示 Ready 状态的容器，请详细检查容器状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. 检查任何未显示 Ready 状态的容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

4. 验证 control plane 节点的主和从属 DNS 服务器连接。

流程

1. 验证 API 服务器的 DNS 记录是否将 control plane 节点上的 kubelet 定向到 https://api-int.<cluster_name>.<base_domain>:6443。确保记录引用负载均衡器。
2. 确保负载均衡器的端口 6443 定义引用每个 control plane 节点。
3. 检查 DHCP 是否提供了唯一的 control plane 节点主机名。

4. 检查每个 control plane 节点上的 kubelet.service journald 单元日志。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

5. 检查 control plane 节点 kubelet 日志中的证书过期信息。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

流程

1. 如果可以访问 worker 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 worker 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 worker 节点是否收到 Ignition 文件，请查询 HTTP 主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        如果收到 worker Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。

     3. 如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 worker 节点的控制台，以确定机制是否正确注入 worker 节点 Ignition 文件。
3. 检查 worker 节点分配的存储设备是否可用。
4. 验证 worker 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 确定 worker 节点状态。

   1. 查询节点状态：

      $ oc get nodes

   2. 获取没有显示 Ready 状态的 worker 节点的详细节点描述：

      $ oc describe node <worker_node>

      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令。

6. 与 control plane 节点（也称为 master 节点）不同，worker 节点使用 Machine API Operator 部署和扩展。检查 Machine API Operator 的状态。

   1. 查看 Machine API Operator pod 状态：

      $ oc get pods -n openshift-machine-api

   2. 如果 Machine API Operator pod 没有处于 Ready 状态，请详细列出 pod 的事件：

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. 检查 machine-api-operator 容器日志。容器在 machine-api-operator pod 中运行：

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. 同时检查 kube-rbac-proxy 容器日志。容器也会在 machine-api-operator pod 中运行：

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. 引导后，监控 worker 节点上的 kubelet.service journald 单元日志。这可让您了解 worker 节点代理活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=worker -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <worker-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

8. 引导后，在 worker 节点上获取 crio.service journald 单元日志。这可让您了解 worker 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=worker -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

9. 从 worker 节点上的 /var/log/ 下的特定子目录收集日志。

   1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 worker 节点上 /var/log/sssd/ 中的文件：

      $ oc adm node-logs --role=worker --path=sssd

   2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 worker 节点的 /var/log/sssd/audit.log 内容：

      $ oc adm node-logs --role=worker --path=sssd/sssd.log

   3. 如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例显示 /var/log/sssd/sssd.log 的尾部信息：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. 使用 SSH 查看 worker 节点容器日志。

    1. 列出容器：

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. 使用 crictl 检索容器日志：

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

11. 如果您遇到 worker 节点配置问题，检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. 如果端点不响应，请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。

    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

       1. 对定义的 MCO 端点名称运行 DNS 查找：

          $ dig api-int.<cluster_name> @<dns_server>

       2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 检查证书的有效性：

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

流程

1. 检查安装结束时，是否所有集群 Operator 都可用。

   $ oc get clusteroperators

2. 验证所有所需的证书签名请求（CSR）是否已批准。有些节点可能无法变为 Ready 状态，且有些集群 Operator 可能无法使用（如果待处理的 CSR）。

   1. 检查 CSR 的状态，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端和服务器请求：

      $ oc get csr

      输出示例

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      客户端请求 CSR。

      2

      服务器请求 CSR。

      在本例中，两台机器加入了集群。您可能会在列表中看到更多已批准的 CSR。

   2. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

      注意

      由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准初始 CSR 后，集群的 kube-controller-manager 会自动批准后续的节点客户端 CSR。

      注意

      对于在未启用机器 API 的平台中运行的集群，如裸机和其他用户置备的基础架构，必须采用一种方法自动批准 kubelet 提供证书请求（CSR）。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

      • 要单独批准，请对每个有效的 CSR 运行以下命令：

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name> 是当前 CSR 列表中 CSR 的名称。

      • 要批准所有待处理的 CSR，请运行以下命令：

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. 查看 Operator 事件：

   $ oc describe clusteroperator <operator_name>

4. 查看 Operator 命名空间中的 Operator pod 状态：

   $ oc get pods -n <operator_namespace>

5. 获取没有处于 Running 状态的 pod 的详细描述：

   $ oc describe pod/<operator_pod_name> -n <operator_namespace>

6. 检查 pod 日志：

   $ oc logs pod/<operator_pod_name> -n <operator_namespace>

7. 遇到与 pod 基础镜像相关的问题时，请查看基础镜像状态。

   1. 获取有问题的 pod 使用的基础镜像的详情：

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>

   2. 列出基础镜像发行信息：

      $ oc adm release info <image_path>:<tag> --commits

流程

1. 生成从 bootstrap 和 control plane 机器获取安装日志的命令：

   • 如果您使用安装程序置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

     $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory 是您在运行时指定的目录 。/openshift-install create cluster。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。

     对于安装程序置备的基础架构，安装程序会保存有关集群的信息，因此您不用指定主机名或 IP 地址。

   • 如果您使用您置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address>" 5

     1

     对于 installation_directory，请指定您在运行时指定的同一目录 。/openshift-install create cluster。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。

     2

     <bootstrap_address> 是集群 bootstrap 机器的完全限定域名或 IP 地址。

     3 4 5

     对于集群中的每个 control plane 或 master 机器，将 <master_*_address> 替换为其完全限定域名或 IP 地址。

     注意

     默认集群包含三台 control plane 机器。如所示，列出所有 control plane 机器，无论您的集群使用了多少个。

   输出示例

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   如果需要创建关安装失败的红帽支持问题单，请在问题单中附上压缩日志。

流程

1. kubelet 通过每个节点上的 systemd 服务来管理。通过在 debug pod 中查询 kubelet systemd 服务来查看 kubelet 的状态。

   1. 为节点启动 debug pod:

      $ oc debug node/my-node

   2. 将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：

      # chroot /host

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

   3. 检查 kubelet systemd 服务是否在该节点上活跃：

      # systemctl is-active kubelet

   4. 输出更详细的 kubelet.service 状态概述：

      # systemctl status kubelet

流程

1. 查询 OpenShift Container Platform 集群节点的 kubelet journald 单元日志。以下示例仅查询 control plane 节点（也称为 master 节点）：

   $ oc adm node-logs --role=master -u kubelet  1

   1

   根据情况替换 kubelet 以查询其他单元日志。

2. 从集群节点上 /var/log/ 下的特定子目录收集日志。

   1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 control plane 节点上的 /var/log/openshift-apiserver/ 中的文件：

      $ oc adm node-logs --role=master --path=openshift-apiserver

   2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

   3. 如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

流程

1. 通过在节点上查询 debug pod 中的 crio systemd 服务来查看 CRI-O 状态。

   1. 为节点启动 debug pod:

      $ oc debug node/my-node

   2. 将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：

      # chroot /host

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

   3. 检查 crio systemd 服务在该节点上是否活跃：

      # systemctl is-active crio

   4. 输出更详细的 crio.service 状态概述：

      # systemctl status crio.service

流程

1. 收集 CRI-O journald 单元日志。以下示例从所有 control plane 节点（在集群中）收集日志：

   $ oc adm node-logs --role=master -u crio

2. 从特定节点收集 CRI-O journald 单元日志：

   $ oc adm node-logs <node_name> -u crio

3. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <node>.<cluster_name>.<base_domain> 替换为适当的值：

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   注意

   运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

流程

1. 在节点上使用 cordon。这是为了避免在节点处于 Ready 状态时调度任何工作负载。当您的 Status 部分中存在 SchedulingDisabled 时代表调度被禁用：

   $ oc adm cordon <nodename>

2. 以 cluster-admin 用户身份排空节点：

   $ oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data

   注意

   pod 或 pod 模板的 terminationGracePeriodSeconds 属性控制安全终止的时间。此属性的默认值为 30 秒，但可以根据需要针对每个应用程序进行自定义。如果设置的值大于 90 秒，则 pod 可能会标记为 SIGKILL，且无法成功终止。

3. 当节点返回时，通过 SSH 或控制台连接节点。然后连接到 root 用户：

   $ ssh core@node1.example.com
   $ sudo -i

4. 手动停止 kubelet：

   # systemctl stop kubelet

5. 停止容器和 pod：

   1. 使用以下命令停止 HostNetwork 中没有的 pod。必须首先删除它们，因为它们依赖于 HostNetwork 中的网络插件 pod。

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. 停止所有其他 pod：

      # crictl rmp -fa

6. 手动停止 crio 服务：

   # systemctl stop crio

7. 运行这些命令后，您可以完全擦除临时存储：

   # crio wipe -f

8. 启动 crio 和 kubelet 服务：

   # systemctl start crio
   # systemctl start kubelet

9. 如果 crio 和 kubelet 服务启动，且节点处于 Ready 状态时，代表清理操作已正常工作：

   $ oc get nodes

   输出示例

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.22.0-rc.0+75ee307

10. 将节点标记为可以调度。当状态中不再有 SchedulingDisabled 时代表启用了调度：

    $ oc adm uncordon <nodename>

    输出示例

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.22.0-rc.0+75ee307

流程

1. 运行以下命令显示哪个服务单元失败：

   $ systemctl --failed

2. 可选：在单个服务单元上运行以下命令查找更多信息：

   $ journalctl -u <unit>.service

流程

1. 列出 Operator 订阅：

   $ oc get subs -n <operator_namespace>

2. 使用 oc describe 命令检查 Subscription 资源：

   $ oc describe sub <subscription_name> -n <operator_namespace>

3. 在命令输出中，找到 Operator 订阅状况类型的 Conditions 部分。在以下示例中，CatalogSourcesUnhealthy 条件类型具有 false 状态，因为所有可用目录源都健康：

   输出示例

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

流程

1. 列出命名空间中的目录源。例如，您可以检查 openshift-marketplace 命名空间，该命名空间用于集群范围的目录源：

   $ oc get catalogsources -n openshift-marketplace

   输出示例

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

2. 使用 oc describe 命令获取有关目录源的详情和状态：

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   输出示例

   Name:         example-catalog
   Namespace:    openshift-marketplace
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   在上例的输出中，最后观察到的状态是 TRANSIENT_FAILURE。此状态表示目录源建立连接时出现问题。

3. 列出创建目录源的命名空间中的 pod：

   $ oc get pods -n openshift-marketplace

   输出示例

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

   在命名空间中创建目录源时，会在该命名空间中为目录源创建一个 pod。在前面的示例中，example-catalog-bwt8z pod 的状态是 ImagePullBackOff。此状态表示拉取目录源的索引镜像存在问题。

4. 使用 oc describe 命令检查 pod 以获取更多详细信息：

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   输出示例

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   在前面的示例输出中，错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如，索引镜像可能存储在需要登录凭证的 registry 中。

流程

1. 列出集群中运行的 Operator。输出包括 Operator 版本、可用性和运行时间信息：

   $ oc get clusteroperators

2. 列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：

   $ oc get pod -n <operator_namespace>

3. 输出详细的 Operator pod 概述：

   $ oc describe pod <operator_pod_name> -n <operator_namespace>

4. 如果 Operator 问题特定于某个节点，则在该节点上查询 Operator 容器状态。

   1. 为节点启动 debug pod：

      $ oc debug node/my-node

   2. 将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：

      # chroot /host

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

   3. 列出节点容器的详细信息，包括状态和关联的 pod ID:

      # crictl ps

   4. 列出节点上特定 Operator 容器的信息。以下示例列出了 network-operator 容器的信息：

      # crictl ps --name network-operator

   5. 退出 debug shell。

流程

1. 列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：

   $ oc get pods -n <operator_namespace>

2. 检查 Operator pod 的日志：

   $ oc logs pod/<pod_name> -n <operator_namespace>

   如果 Operator pod 具有多个容器，则上述命令将会产生一个错误，其中包含每个容器的名称。从独立容器查询日志：

   $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>

3. 如果 API 无法正常工作，请使用 SSH 来查看每个 control plane 节点上的 Operator pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。

   1. 列出每个 control plane 节点上的 pod：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods

   2. 对于任何未显示 Ready 状态的 Operator pod，详细检查 Pod 的状态。将 <operator_pod_id> 替换为上一命令输出中列出的 Operator pod ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>

   3. 列出与 Operator pod 相关的容器：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

   4. 对于任何未显示 Ready 状态的 Operator 容器，请详细检查容器的状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. 检查任何未显示 Ready 状态的 Operator 容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

流程

1. 从安装 Operator 的命名空间中获取 Subscription 和 ClusterServiceVersion 对象的名称：

   $ oc get sub,csv -n <namespace>

   输出示例

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. 删除订阅：

   $ oc delete subscription <subscription_name> -n <namespace>

3. 删除集群服务版本：

   $ oc delete csv <csv_name> -n <namespace>

4. 在 openshift-marketplace 命名空间中获取所有失败的作业的名称和相关配置映射：

   $ oc get job,configmap -n openshift-marketplace

   输出示例

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. 删除作业：

   $ oc delete job <job_name> -n openshift-marketplace

   这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。

6. 删除配置映射：

   $ oc delete configmap <configmap_name> -n openshift-marketplace

7. 在 Web 控制台中使用 OperatorHub 重新安装 Operator。

流程

1. 切换到项目：

   $ oc project <project_name>

2. 列出在命名空间中运行的 pod，以及 pod 状态、错误状态、重启和年龄：

   $ oc get pods

3. 确定命名空间是否由部署配置管理：

   $ oc status

   如果命名空间由部署配置管理，输出包括部署配置名称和基础镜像引用。

4. 检查以上命令输出中引用的基础镜像：

   $ skopeo inspect docker://<image_reference>

5. 如果基础镜像引用不正确，请更新部署配置中的引用：

   $ oc edit deployment/my-deployment

6. 当部署配置退出时，配置将自动重新部署。在部署过程中的 Watch pod 的状态，以确定这个问题是否已解决：

   $ oc get pods -w

7. 检查命名空间中的事件，以了解与 pod 失败相关的诊断信息：

   $ oc get events

流程

1. 查询特定 pod 的日志：

   $ oc logs <pod_name>

2. 查询 pod 中特定容器的日志：

   $ oc logs <pod_name> -c <container_name>

   由前面的 oc logs 命令所获得的日志由发送到 pod 或容器中的 stdout 的信息组成。

3. 检查 pod 中的 /var/log/ 中包含的日志。

   1. 列出 pod 中 /var/log 中所含的日志文件和子目录：

      $ oc exec <pod_name> ls -alh /var/log

   2. 查询 pod 中 /var/log 中所含的特定日志文件：

      $ oc exec <pod_name> cat /var/log/<path_to_log>

   3. 列出特定容器内 /var/log 中含有的日志文件和子目录：

      $ oc exec <pod_name> -c <container_name> ls /var/log

   4. 查询特定容器中的 /var/log 中所含的特定日志文件：

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>

流程

1. 切换到包含您要访问的 pod 的项目。这是必要的，因为 oc rsh 命令不支持使用 -n 选项指定命名空间：

   $ oc project <namespace>

2. 启动到 pod 的远程 shell:

   $ oc rsh <pod_name>  1

   1

   如果 pod 有多个容器，除非使用 -c <container_name> 指定了一个容器，否则 oc rsh 会默认使用第一个容器。

3. 启动至 pod 中的特定容器中的一个远程 shell ：

   $ oc rsh -c <container_name> pod/<pod_name>

4. 创建一个端口转发会话到 pod 上的端口：

   $ oc port-forward <pod_name> <host_port>:<pod_port>  1

   1

   输入 Ctrl+C 来取消端口转发会话。

流程

1. 根据一个部署启动具有 root 访问权限的 debug pod。

   1. 获取项目部署名称：

      $ oc get deployment -n <project_name>

   2. 根据部署启动带有 root 权限的 debug pod:

      $ oc debug deployment/my-deployment --as-root -n <project_name>

2. 根据部署配置启动具有 root 访问权限的 debug pod。

   1. 获取项目的部署配置名称：

      $ oc get deploymentconfigs -n <project_name>

   2. 根据部署配置，使用 root 权限启动 debug pod:

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>

流程

1. 将文件复制到 pod:

   $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1

   1

   如果没有指定 -c 选项，则会选择 pod 中的第一个容器。

2. 从 pod 复制文件：

   $ oc cp <pod_name>:/<path>  -c <container_name><local_path>  1

   1

   如果没有指定 -c 选项，则会选择 pod 中的第一个容器。

   注意

   要使 oc cp 正常工作，容器内必须有 tar。

1. 在构建配置阶段，构建 pod 用于从基础镜像和应用程序源代码创建应用程序容器镜像。
2. 在部署配置阶段，部署 pod 用于从构建配置阶段构建的应用程序容器镜像中部署应用程序 pod。部署 pod 还会部署其他资源，如服务和路由。部署配置在构建配置成功后开始。
3. 在部署 pod 启动应用程序 pod 后，应用程序故障可能会在运行的应用程序 pod 中发生。例如，即使应用程序 pod 处于 Running 状态，应用程序的行为也可能不会如预期。在这种情况下，您可以访问正在运行的应用程序 pod，以调查 pod 中的应用程序故障。

1. 监控构建、部署和应用程序 pod 状态
2. 确定发生问题 S2I 进程阶段
3. 查看与失败阶段对应的日志

流程

1. 在整个 S2I 过程中监控 pod 状态，以确定在哪个阶段发生故障：

   $ oc get pods -w  1

   1

   使用 -w 来监控 pod 是否有变化，直到您使用 Ctrl+C 退出命令。

2. 检查 pod 失败的日志以找出错误。

   • 如果构建 pod 失败，请检查构建 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-build

     注意

     另外，您可以使用 oc logs -f bc/<application_name> 来查看构建配置的日志。构建配置的日志包括来自构建 pod 的日志。

   • 如果部署 pod 失败，请查看部署 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     注意

     另外，您可以使用 oc logs -f bc/<application_name> 来查看部署配置的日志。此操作会从部署 pod 输出日志，直到部署 pod 成功完成为止。如果在部署 pod 完成后运行，命令会输出来自应用程序 pod 的日志。部署 pod 完成后，仍可通过运行 oc logs -f pod/<application_name>-<build_number>-deploy 来访问其日志。

   • 如果应用程序 pod 失败，或者应用程序没有如预期在正在运行的应用程序 pod 中发生，请查看应用程序 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

流程

1. 列出与特定应用程序 pod 相关的事件。以下示例检索名为 my-app-1-akdlg 的应用程序 pod 的事件:

   $ oc describe pod/my-app-1-akdlg

2. 检查应用程序 pod 的日志：

   $ oc logs -f pod/my-app-1-akdlg

3. 在正在运行的应用程序 pod 中查询特定日志。发送到 stdout 的日志由 OpenShift Logging 框架收集，并包含在上一命令的输出中。以下查询只适用于没有发送到 stdout 的日志。

   1. 如果应用程序日志可以在 pod 内不需要 root 权限的情况下就可以进行访问，则按如下方式处理日志文件：

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

   2. 如果需要 root 访问权限才能查看应用程序日志，您可以启动具有 root 权限的 debug 容器，然后从容器内查看日志文件。从项目的 DeploymentConfig 对象启动 debug 容器。pod 用户通常使用非 root 权限运行，但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用：

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      注意

      如果您运行不使用 -- <command> 的oc debug dc/<deployment_configuration> --as-root，则可以获得 debug pod 内带有 root 权限的一个互动式 shell 。

4. 以互动方式测试应用程序功能,并在带有互动 shell 的应用程序容器中运行诊断工具。

   1. 在应用程序容器上启动一个交互式 shell:

      $ oc exec -it my-app-1-akdlg /bin/bash

   2. 在 shell 中以互动方式测试应用程序功能。例如，您可以运行容器的入口点命令并观察结果。然后，在更新源代码并通过 S2I 进程重建应用程序容器前，直接从命令行测试更改。

   3. 运行容器中的诊断二进制文件。

      注意

      运行一些诊断二进制文件需要 root 权限。在这些情况下，您可以通过运行 oc debug dc/<deployment_configuration> --as-root，根据有问题的 pod 的 DeploymentConfig 对象启动一个带有 root 访问权限的 debug pod。然后，您可以从 debug pod 中以 root 用户身份运行诊断二进制文件。

5. 如果容器中没有诊断二进制文件，您可以使用 nsenter 在容器的命名空间中运行主机的诊断二进制文件。以下实例在一个容器的命名空间中运行 ip ad，使用主机的 ip 二进制代码。

   1. 在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

      $ oc debug node/my-cluster-node

   2. 将 /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：

      # chroot /host

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 4.8 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

   3. 确定目标容器 ID:

      # crictl ps

   4. 确定容器的进程 ID。在本例中，目标容器 ID 是7fe32346b120:

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. 在容器命名空间中运行 ip ad，使用主机的 ip 二进制代码。本例使用 31150 作为容器的进程 ID。nsenter 命令输入目标进程的命名空间并在命名空间中运行命令。因为本例中的目标进程是一个容器的进程 ID，所以 ip ad 命令在主机的容器命名空间中运行：

      # nsenter -n -t 31150 -- ip ad

      注意

      只有在使用特权容器（如 debug 节点）时，才能在容器的命名空间中运行主机的诊断二进制代码。

流程

1. 要在 C:\var\logs 中的所有目录中查看日志，请运行以下命令：

   $ oc adm node-logs -l kubernetes.io/os=windows --path= \
       /ip-10-0-138-252.us-east-2.compute.internal containers \
       /ip-10-0-138-252.us-east-2.compute.internal hybrid-overlay \
       /ip-10-0-138-252.us-east-2.compute.internal kube-proxy \
       /ip-10-0-138-252.us-east-2.compute.internal kubelet \
       /ip-10-0-138-252.us-east-2.compute.internal pods

2. 您现在可以使用同样的命令列出目录中的文件并查看单个日志文件。例如，要查看 kubelet 日志，请运行以下命令：

   $ oc adm node-logs -l kubernetes.io/os=windows --path=/kubelet/kubelet.log

流程

1. SSH 到 Windows 节点并输入 PowerShell:

   C:\> powershell

2. 运行以下命令来查看 Docker 日志：

   C:\> Get-EventLog -LogName Application -Source Docker

流程

1. 在服务和 ServiceMonitor 资源配置中检查对应的标签是否匹配。

   1. 获取服务中定义的标签。以下示例在 ns1 项目中查询 prometheus-example-app 服务：

      $ oc -n ns1 get service prometheus-example-app -o yaml

      输出示例

        labels:
          app: prometheus-example-app

   2. 检查 ServiceMonitor 资源配置中的 matchLabels app 标签是否与上一步中的标签输出匹配：

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      输出示例

      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      注意

      您可以作为具有项目查看权限的开发者检查服务和 ServiceMonitor 资源标签。

2. 在 openshift-user-workload-monitoring 项目中检查 Prometheus Operator 的日志。

   1. 列出 openshift-user-workload-monitoring 项目中的 Pod：

      $ oc -n openshift-user-workload-monitoring get pods

      输出示例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. 从 prometheus-operator Pod 中的 prometheus-operator 容器获取日志。在以下示例中，Pod 名为 prometheus-operator-776fcbbd56-2nbfm：

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      如果服务监控器出现问题，日志可能包含类似本例的错误：

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. 直接在 Prometheus UI 中查看项目的目标状态。

   1. 建立端口转发到 openshift-user-workload-monitoring 项目中的 Prometheus 实例：

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090

   2. 在 Web 浏览器中打开 http://localhost:9090/targets，并在 Prometheus UI 中直接查看项目的目标状态。检查与目标相关的错误消息。

4. 在 openshift-user-workload-monitoring 项目中为 Prometheus Operator 配置 debug 级别的日志记录。

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 在 data/config.yaml 下为 prometheusOperator 添加 logLevel: debug，将日志级别设置为 debug：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug

   3. 保存文件以使改变生效。

      注意

      在应用日志级别更改时，openshift-user-workload-monitoring 项目中的 prometheus-operator 会自动重启。

   4. 确认 debug 日志级别已应用到 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署：

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      输出示例

              - --log-level=debug

      Debug 级别日志记录将显示 Prometheus Operator 发出的所有调用。

   5. 检查 prometheus-operator Pod 是否正在运行：

      $ oc -n openshift-user-workload-monitoring get pods

      注意

      如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值，则 prometheus-operator Pod 可能无法成功重启。

   6. 查看 debug 日志，以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。

流程

1. 在 Administrator 视角中，导航到 Monitoring → Metrics。

2. 在 Expression 字段中运行以下 Prometheus Query Language (PromQL) 查询。这会返回具有最高提取示例数的十个指标：

   topk(10,count by (job)({__name__=~".+"}))

3. 如果指标的提取示例数大于预期，请检查分配给指标的未绑定标签值数量。

   • 如果指标与用户定义的项目相关，请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
   • 如果指标与 OpenShift Container Platform 核心项目相关，请在红帽客户门户网站上创建一个红帽支持问题单。

4. 检查 Prometheus UI 中的 TSDB 状态。

   1. 在 Administrator 视角中，导航至 Networking → Routes。
   2. 选择 Project 列表中的 openshift-monitoring 项目。
   3. 选择 prometheus-k8s 行中的 URL 来打开 Prometheus UI 的登录页面。
   4. 选择 Log in with OpenShift 来使用您的 OpenShift Container Platform 凭证进行登录。
   5. 在 Prometheus UI 中，进入到 Status → TSDB Status。

流程

1. 在运行 oc 命令时指定 oc 日志级别：

   $ oc <options> --loglevel <log_level>

2. OpenShift Container Platform 用户的当前会话令牌通常包含在记录的 curl 请求中。您还可以手动获取当前用户的会话令牌，以便在测试 oc 命令的底层进程的各个方面时使用：

   $ oc whoami -t