创建快照以帮助诊断集群问题

Version 1.9 (unsupported)

• 最新
• 版本 1.16
• 早期版本（不受支持）

如果某个集群存在问题，您可以从 Cloud Customer Care 获取帮助。Customer Care 可能会要求您截取集群的“快照”，可用于诊断问题。快照会捕获集群和节点配置文件，并将该信息打包为一个 tar 文件。

本文档介绍如何创建集群的默认快照或更多自定义快照，还介绍了在集群出现特定错误时如何创建快照。

默认快照

以下部分介绍了标准快照中的内容以及如何创建标准快照。如需了解自定义快照，请参阅自定义快照部分。

默认快照包含哪些信息？

集群的快照是一个有关该集群的配置文件和日志的 tar 文件。具体而言，该命令的默认配置会捕获有关集群的以下信息：

• Kubernetes 版本

• kubenetes 资源在 kube-system 和 gke-system 命名空间中的状态：集群、机器、节点、服务、端点、ConfigMap、ReplicaSet、CronJob、Pod 以及这些 Pod 的所有者，包括 Deployment、DaemonSet 和 StatefulSet

• 有关每个节点配置的详细信息，包括 IP 地址、iptables 规则、装载点、文件系统、网络连接，以及正在运行的进程

• 来自 bmctl check cluster --snapshot 命令的日志

集群的凭据信息不包含在默认快照中。如果 Cloud Customer Care 请求该信息，请参阅检索集群信息。

如需查看运行快照命令时收集的信息的完整列表，请参阅详细的配置文件部分中显示的配置文件。此配置文件展示了截取默认快照时运行的命令。

如何创建默认快照

bmctl check cluster 命令用于截取集群的快照。您可以使用此命令执行以下任一操作： * 创建快照并将该快照自动上传到 Cloud Storage 存储桶 * 创建集群快照并将快照文件保存在运行该命令的本地机器上。

方法 #1：创建默认快照并自动上传到 Cloud Storage 存储桶

如需创建快照并将其上传到 Cloud Storage 存储桶，请执行以下操作：

1. 设置 API 和服务帐号：

   1. 在 Google Cloud 项目中启用 Cloud Storage API。
   2. 为服务帐号授予 storage.admin 角色，以便服务帐号能够将数据上传到 Cloud Storage。
   3. 下载服务帐号的 JSON 密钥。

   如需了解详情，请参阅启用 Google 服务和服务帐号。

2. 运行以下 bmctl 命令以创建快照并将快照自动上传到 Cloud Storage 存储桶：

   bmctl check cluster --snapshot --cluster=CLUSTER_NAME
   --kubeconfig=KUBECONFIG_PATH
   --upload-to BUCKET_NAME
   [--service-account-key-file SERVICE_ACCOUNT_KEY_FILE]
   

   在该命令中，将以下条目替换为特定于您的集群环境的信息：

   • CLUSTER_NAME：您要截取其快照的集群的名称。
   • KUBECONFIG_PATH：管理员集群 kubeconfig 文件的路径。 （kubeconfig 文件的路径通常为 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig。但是，如果您使用 WORKSPACE_DIR 标志指定工作区，则路径为 WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig。）
   • BUCKET_NAME：您拥有的 Cloud Storage 存储桶的名称。
   • SERVICE_ACCOUNT_KEY_FILE_PATH：如果您未提供 --service-account-key-file 标志，则 bmctl 会尝试从环境变量 GOOGLE_APPLICATION_CREDENTIALS 获取服务帐号的密钥文件的路径。

3. 为 Cloud Customer Care 授予对包含快照的存储桶的读取权限：

   gsutil iam ch \
   serviceAccount:[e-mail]:roles/storage.objectViewer \
   gs://BUCKET_NAME
   

方法 #2：在本地机器上创建默认快照

您可以使用以下命令捕获已创建的集群的状态：

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=KUBECONFIG_PATH

替换以下内容：

• CLUSTER_NAME：目标集群的名称。

• KUBECONFIG_PATH：管理员集群 kubeconfig 文件的路径。 （kubeconfig 文件的路径通常为 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig。但是，如果您使用 WORKSPACE_DIR 标志指定工作区，则路径为 WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig。）

此命令会将一个 tar 文件输出到本地机器。此 tar 文件的名称采用 snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz 格式，其中 TIMESTAMP 表示该文件的创建日期和时间。此 tar 文件包含集群的系统组件和机器的相关调试信息。

执行此命令时，系统会从以下命名空间收集有关 Pod 的信息：gke-system、gke-connect、capi-system、capi-webhook-system、cert-manager 和 capi-kubeadm-bootstrap-system

但是，您可以使用 --snapshot-scenario all 标志扩大收集的诊断信息的范围。此标志会将诊断快照的范围扩大为包含集群中的所有 Pod：

bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=CLUSTER_NAME \
--kubeconfig=KUBECONFIG_PATH

自定义快照

出于以下原因，您可能需要创建集群的自定义快照：

• 包含的集群相关信息超过默认快照中提供的信息。
• 排除默认快照中的某些信息。
• 在遇到 admin cluster is unreachable 错误时截取集群的快照。如需了解详情，请参阅如何在管理员集群无法访问时创建自定义快照部分。

如何创建自定义快照

创建自定义快照需要使用快照配置文件。以下步骤介绍了如何创建和修改配置文件，并使用配置文件创建集群的自定义快照：

1. 通过在集群上运行以下命令并将输出写入文件来创建快照配置文件：

    bmctl check cluster
   --snapshot --snapshot-dry-run --cluster CLUSTER_NAME
   --kubeconfig KUBECONFIG_PATH
   

2. 定义您要在自定义快照中显示的信息类型。为此，请修改您在第 1 步中创建的快照配置文件。例如，如果您希望快照包含其他信息（例如特定节点的运行时长），请将 Linux 命令 uptime 添加到配置文件的相关部分。配置文件的以下代码段展示了如何让快照命令提供关于节点 10.200.0.3 的 uptime 信息。此信息不会出现在标准快照中。

   ...
   nodeCommands:
   - nodes:
     - 10.200.0.3
     commands:
     - uptime
   ...
   

3. 修改配置文件以定义所需的快照类型后，通过运行以下命令创建自定义快照：

    bmctl check cluster
   --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster
   CLUSTER_NAME --kubeconfig KUBECONFIG_PATH
   

   --snapshot-config 标志指示 bmctl 命令使用快照配置文件的内容来定义快照中显示的信息。

详细的配置文件

以下示例快照配置文件展示了用于创建快照的标准命令和文件，但当需要其他诊断信息时，您可以添加更多命令和文件：

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file

配置文件中的以下条目可能与上述示例配置文件中显示的条目不同：

• nodeCommands 和 nodeFiles 部分中节点的 IP 地址
• 集群的 nodeSSHKey 的路径

配置文件中的字段

快照配置文件采用 YAML 格式。配置文件包含以下字段：

• numOfParallelThreads：快照例程通常运行大量命令。多个并行线程可帮助例程更快地执行。按照前面的示例配置文件所示，我们建议您将 numOfParallelThreads 设置为 10。如果快照截取时间过长，请提高此值。

• excludeWords：快照包含大量用于集群节点的数据。使用 excludeWords 时，您可以在共享快照时降低安全风险。例如，排除 password 以便无法识别相应的密码字符串。

• nodeCommands：本部分指定了以下信息：

  • nodes：您要从中收集信息的集群节点的 IP 地址列表。如需在管理员集群无法访问时创建快照，请指定至少一个节点 IP 地址。

  • commands：要在每个节点上运行的命令（和参数）的列表。每个命令的输出都包含在快照中。

• nodeFiles：本部分指定了以下信息：

  • nodes：要从中收集文件的集群节点的 IP 地址列表。要在管理员集群无法访问时创建快照，请至少指定一个节点 IP 地址。

  • files：要从每个节点检索的文件列表。在节点上发现指定文件时，文件将包含在快照中。

• nodeSSHKey：您的 SSH 密钥文件的路径。如果管理员集群无法访问，则此字段为必填字段。

在遇到特定错误时创建快照

如何在安装或升级停滞期间创建默认快照

安装或升级管理员集群、混合集群或独立集群时，bmctl 有时可能会停滞，此时可以看到以下输出：

• 等待集群 kubeconfig 准备就绪。
• 等待集群准备就绪。
• 等待节点池准备就绪。
• 等待升级完成。

尽管如此，如果您遇到安装或升级停滞的情况，可以通过运行以下命令使用引导集群截取集群的快照：

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

如何在安装或升级停滞期间创建自定义快照

以下步骤展示了如何在安装或升级停滞时创建集群的自定义快照：

1. 从归档中检索集群的快照配置文件。

2. 修改快照配置文件，使快照包含您需要的信息。

3. 通过运行以下命令创建自定义快照：

   bmctl check cluster --snapshot
   --snapshot-config=SNAPSHOT_CONFIG_FILE
   --cluster=CLUSTER_NAME
   --kubeconfig=WORKSPACE_DIR/.kindkubeconfig
   

如何在管理员集群无法访问时创建自定义快照

如果您的集群生成错误，表明管理员集群无法访问，则您无法截取集群的默认快照。这是因为默认 bmctl 命令会尝试从管理员集群中检索信息以及其他操作。当默认命令尝试从无法访问的管理员集群检索信息时，快照命令将失败。

因此，当管理员集群无法访问时，您应该截取集群的自定义快照，而不是默认快照。这样，您就可以创建不会从故障管理员集群请求信息的自定义快照。

以下步骤展示了如何在管理员集群无法访问时创建集群的自定义快照：

1. 从归档中检索集群的快照配置文件。

2. 在节点部分中，列出需要其信息的节点的 IP 地址，但请务必排除管理员集群节点的 IP 地址。

3. 通过运行以下命令创建自定义快照：

   bmctl check cluster
   --snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE
   --cluster=CLUSTER_NAME
   --kubeconfig=KUBECONFIG_PATH
   

收集关于入站流量或 Anthos Service Mesh 问题的日志

bmctl 快照不包含用于排查 Ingress 或 Anthos Service Mesh 问题的信息。如需了解如何收集相关诊断日志，请参阅 Anthos Service Mesh 文档中的收集 Anthos Service Mesh 日志。