这是本节的多页打印视图。点击此处打印.

集群故障排查

调试常见的集群问题。

1: 资源监控工具
2: 资源指标管道
3: 节点健康监测
4: 使用 crictl 对 Kubernetes 节点进行调试
5: Windows 调试技巧
6: 审计
7: 使用 telepresence 在本地开发和调试服务
8: 用 Kubectl 调试 Kubernetes 节点

本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。对于应用的调试，请参阅应用故障排查指南。你也可以访问故障排查来获取更多的信息。

列举集群节点

调试的第一步是查看所有的节点是否都已正确注册。

运行以下命令：

kubectl get nodes

验证你所希望看见的所有节点都能够显示出来，并且都处于 Ready 状态。

为了了解你的集群的总体健康状况详情，你可以运行：

kubectl cluster-info dump

示例：调试关闭/无法访问的节点

有时在调试时查看节点的状态很有用 —— 例如，因为你注意到在节点上运行的 Pod 的奇怪行为，或者找出为什么 Pod 不会调度到节点上。与 Pod 一样，你可以使用 kubectl describe node 和 kubectl get node -o yaml 来检索有关节点的详细信息。例如，如果节点关闭（与网络断开连接，或者 kubelet 进程挂起并且不会重新启动等），你将看到以下内容。请注意显示节点为 NotReady 的事件，并注意 Pod 不再运行（它们在 NotReady 状态五分钟后被驱逐）。

kubectl get nodes

NAME                     STATUS       ROLES     AGE     VERSION
kube-worker-1            NotReady     <none>    1h      v1.23.3
kubernetes-node-bols     Ready        <none>    1h      v1.23.3
kubernetes-node-st6x     Ready        <none>    1h      v1.23.3
kubernetes-node-unaj     Ready        <none>    1h      v1.23.3

kubectl describe node kube-worker-1

Name:               kube-worker-1
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=kube-worker-1
                    kubernetes.io/os=linux
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Thu, 17 Feb 2022 16:46:30 -0500
Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule
Unschedulable:      false
Lease:
  HolderIdentity:  kube-worker-1
  AcquireTime:     <unset>
  RenewTime:       Thu, 17 Feb 2022 17:13:09 -0500
Conditions:
  Type                 Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----                 ------    -----------------                 ------------------                ------              -------
  NetworkUnavailable   False     Thu, 17 Feb 2022 17:09:13 -0500   Thu, 17 Feb 2022 17:09:13 -0500   WeaveIsUp           Weave pod has set this
  MemoryPressure       Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  DiskPressure         Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  PIDPressure          Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  Ready                Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
Addresses:
  InternalIP:  192.168.0.113
  Hostname:    kube-worker-1
Capacity:
  cpu:                2
  ephemeral-storage:  15372232Ki
  hugepages-2Mi:      0
  memory:             2025188Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  14167048988
  hugepages-2Mi:      0
  memory:             1922788Ki
  pods:               110
System Info:
  Machine ID:                 9384e2927f544209b5d7b67474bbf92b
  System UUID:                aa829ca9-73d7-064d-9019-df07404ad448
  Boot ID:                    5a295a03-aaca-4340-af20-1327fa5dab5c
  Kernel Version:             5.13.0-28-generic
  OS Image:                   Ubuntu 21.10
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.5.9
  Kubelet Version:            v1.23.3
  Kube-Proxy Version:         v1.23.3
Non-terminated Pods:          (4 in total)
  Namespace                   Name                                 CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                 ------------  ----------  ---------------  -------------  ---
  default                     nginx-deployment-67d4bdd6f5-cx2nz    500m (25%)    500m (25%)  128Mi (6%)       128Mi (6%)     23m
  default                     nginx-deployment-67d4bdd6f5-w6kd7    500m (25%)    500m (25%)  128Mi (6%)       128Mi (6%)     23m
  kube-system                 kube-proxy-dnxbz                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         28m
  kube-system                 weave-net-gjxxp                      100m (5%)     0 (0%)      200Mi (10%)      0 (0%)         28m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                1100m (55%)  1 (50%)
  memory             456Mi (24%)  256Mi (13%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%)
Events:
...

kubectl get node kube-worker-1 -o yaml

apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
  creationTimestamp: "2022-02-17T21:46:30Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: kube-worker-1
    kubernetes.io/os: linux
  name: kube-worker-1
  resourceVersion: "4026"
  uid: 98efe7cb-2978-4a0b-842a-1a7bf12c05f8
spec: {}
status:
  addresses:
  - address: 192.168.0.113
    type: InternalIP
  - address: kube-worker-1
    type: Hostname
  allocatable:
    cpu: "2"
    ephemeral-storage: "14167048988"
    hugepages-2Mi: "0"
    memory: 1922788Ki
    pods: "110"
  capacity:
    cpu: "2"
    ephemeral-storage: 15372232Ki
    hugepages-2Mi: "0"
    memory: 2025188Ki
    pods: "110"
  conditions:
  - lastHeartbeatTime: "2022-02-17T22:20:32Z"
    lastTransitionTime: "2022-02-17T22:20:32Z"
    message: Weave pod has set this
    reason: WeaveIsUp
    status: "False"
    type: NetworkUnavailable
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has sufficient memory available
    reason: KubeletHasSufficientMemory
    status: "False"
    type: MemoryPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has no disk pressure
    reason: KubeletHasNoDiskPressure
    status: "False"
    type: DiskPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has sufficient PID available
    reason: KubeletHasSufficientPID
    status: "False"
    type: PIDPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:15:15Z"
    message: kubelet is posting ready status. AppArmor enabled
    reason: KubeletReady
    status: "True"
    type: Ready
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250
  nodeInfo:
    architecture: amd64
    bootID: 22333234-7a6b-44d4-9ce1-67e31dc7e369
    containerRuntimeVersion: containerd://1.5.9
    kernelVersion: 5.13.0-28-generic
    kubeProxyVersion: v1.23.3
    kubeletVersion: v1.23.3
    machineID: 9384e2927f544209b5d7b67474bbf92b
    operatingSystem: linux
    osImage: Ubuntu 21.10
    systemUUID: aa829ca9-73d7-064d-9019-df07404ad448

查看日志

目前，深入挖掘集群需要登录相关机器。以下是相关日志文件的位置。在基于 systemd 的系统上，你可能需要使用 journalctl 而不是检查日志文件。

控制平面节点

/var/log/kube-apiserver.log —— API 服务器，负责提供 API 服务
/var/log/kube-scheduler.log —— 调度器，负责制定调度决策
/var/log/kube-controller-manager.log —— 运行大多数 Kubernetes 内置控制器的组件，除了调度（kube-scheduler 处理调度）。

工作节点

/var/log/kubelet.log —— 负责在节点运行容器的 kubelet 所产生的日志
/var/log/kube-proxy.log —— 负责将流量转发到服务端点的 kube-proxy 所产生的日志

集群故障模式

这是可能出错的事情的不完整列表，以及如何调整集群设置以缓解问题。

故障原因

虚拟机关闭
集群内或集群与用户之间的网络分区
Kubernetes 软件崩溃
持久存储（例如 GCE PD 或 AWS EBS 卷）的数据丢失或不可用
操作员错误，例如配置错误的 Kubernetes 软件或应用程序软件

具体情况

API 服务器所在的 VM 关机或者 API 服务器崩溃
- 结果
  - 不能停止、更新或者启动新的 Pod、服务或副本控制器
  - 现有的 Pod 和服务在不依赖 Kubernetes API 的情况下应该能继续正常工作
API 服务器的后端存储丢失
- 结果
  - kube-apiserver 组件未能成功启动并变健康
  - kubelet 将不能访问 API 服务器，但是能够继续运行之前的 Pod 和提供相同的服务代理
  - 在 API 服务器重启之前，需要手动恢复或者重建 API 服务器的状态

Kubernetes 服务组件（节点控制器、副本控制器管理器、调度器等）所在的 VM 关机或者崩溃
- 当前，这些控制器是和 API 服务器在一起运行的，它们不可用的现象是与 API 服务器类似的
- 将来，这些控制器也会复制为多份，并且可能不在运行于同一节点上
- 它们没有自己的持久状态
单个节点（VM 或者物理机）关机
- 结果
  - 此节点上的所有 Pod 都停止运行
网络分裂
- 结果
  - 分区 A 认为分区 B 中所有的节点都已宕机；分区 B 认为 API 服务器宕机（假定主控节点所在的 VM 位于分区 A 内）。

kubelet 软件故障
- 结果
  - 崩溃的 kubelet 就不能在其所在的节点上启动新的 Pod
  - kubelet 可能删掉 Pod 或者不删
  - 节点被标识为非健康态
  - 副本控制器会在其它的节点上启动新的 Pod
集群操作错误
- 结果
  - 丢失 Pod 或服务等等
  - 丢失 API 服务器的后端存储
  - 用户无法读取 API
  - 等等

缓解措施

措施：对于 IaaS 上的 VM，使用 IaaS 的自动 VM 重启功能
- 缓解：API 服务器 VM 关机或 API 服务器崩溃
- 缓解：Kubernetes 服务组件所在的 VM 关机或崩溃
措施: 对于运行 API 服务器和 etcd 的 VM，使用 IaaS 提供的可靠的存储（例如 GCE PD 或者 AWS EBS 卷）
- 缓解：API 服务器后端存储的丢失
措施：使用高可用性的配置
- 缓解：主控节点 VM 关机或者主控节点组件（调度器、API 服务器、控制器管理器）崩溃
  - 将容许一个或多个节点或组件同时出现故障
- 缓解：API 服务器后端存储（例如 etcd 的数据目录）丢失
  - 假定你使用了高可用的 etcd 配置

措施：定期对 API 服务器的 PD 或 EBS 卷执行快照操作
- 缓解：API 服务器后端存储丢失
- 缓解：一些操作错误的场景
- 缓解：一些 Kubernetes 软件本身故障的场景
措施：在 Pod 的前面使用副本控制器或服务
- 缓解：节点关机
- 缓解：kubelet 软件故障
措施：应用（容器）设计成容许异常重启
- 缓解：节点关机
- 缓解：kubelet 软件故障

接下来

了解资源指标管道中可用的指标
发现用于监控资源使用的其他工具
使用节点问题检测器监控节点健康
使用 kubectl debug node 调试 Kubernetes 节点
使用 crictl 来调试 Kubernetes 节点
获取更多关于 Kubernetes 审计的信息
使用 telepresence 本地开发和调试服务

1 - 资源监控工具

要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。你可以通过检测容器检查 Kubernetes 集群中的应用程序性能， Pod、服务和整个集群的特征。 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。

在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。在新集群上，你可以使用资源度量或完整度量管道来收集监视统计信息。

资源度量管道

资源指标管道提供了一组与集群组件，例如 Horizontal Pod Autoscaler 控制器以及 kubectl top 实用程序相关的有限度量。这些指标是由轻量级的、短期、内存存储的 metrics-server 收集的，通过 metrics.k8s.io 公开。

度量服务器发现集群中的所有节点，并且查询每个节点的 kubelet 以获取 CPU 和内存使用情况。 Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。 kubelet 将每个 Pod 转换为其组成的容器，并通过容器运行时接口从容器运行时获取各个容器使用情况统计信息。如果某个容器运行时使用 Linux cgroups 和名字空间来实现容器。并且这一容器运行时不发布资源用量统计信息，那么 kubelet 可以直接查找这些统计信息（使用来自 cAdvisor 的代码）。无论这些统计信息如何到达，kubelet 都会通过 metrics-server Resource Metrics API 公开聚合的 Pod 资源用量统计信息。该 API 在 kubelet 的经过身份验证和只读的端口上的 /metrics/resource/v1beta1 中提供。

完整度量管道

一个完整度量管道可以让你访问更丰富的度量。 Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，通过自动调用扩展或调整集群来响应这些度量。监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes，方法是实现 custom.metrics.k8s.io 或 external.metrics.k8s.io API。

将完整的指标管道集成到 Kubernetes 实现中超出了 Kubernetes 文档的范围，因为可能的解决方案具有非常广泛的范围。

监控平台的选择在很大程度上取决于你的需求、预算和技术资源。 Kubernetes 不推荐任何特定的指标管道；可使用许多选项。你的监控系统应能够处理 OpenMetrics 指标传输标准，并且需要选择最适合基础设施平台的整体设计和部署。

接下来

了解其他调试工具，包括：

2 - 资源指标管道

对于 Kubernetes，Metrics API 提供了一组基本的指标，以支持自动伸缩和类似的用例。该 API 提供有关节点和 Pod 的资源使用情况的信息，包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。

HorizontalPodAutoscaler (HPA) 和 VerticalPodAutoscaler (VPA) 使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。

你也可以通过 kubectl top 命令来查看资源指标。

说明：

Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。如果你想提供更完整的指标集，你可以通过部署使用 Custom Metrics API 的第二个指标管道来作为简单的 Metrics API 的补充。

图 1 说明了资源指标管道的架构。

flowchart RL subgraph cluster[集群] direction RL S[

] A[Metrics-
Server] subgraph B[节点] direction TB D[cAdvisor] --> C[kubelet] E[容器
运行时] --> D E1[容器
运行时] --> D P[Pod 数据] -.- C end L[API
服务器] W[HPA] C ---->|Summary
API| A -->|metrics
API| L --> W end L ---> K[kubectl
top] classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class W,B,P,K,cluster,D,E,E1 box classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class S spacewhite classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; class A,L,C k8s

图 1. 资源指标管道

图中从右到左的架构组件包括以下内容：

cAdvisor: 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。
kubelet: 用于管理容器资源的节点代理。可以使用 /metrics/resource 和 /stats kubelet API 端点访问资源指标。
Summary API: kubelet 提供的 API，用于发现和检索可通过 /stats 端点获得的每个节点的汇总统计信息。
metrics-server: 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。 API 服务器提供 Metrics API 以供 HPA、VPA 和 kubectl top 命令使用。Metrics Server 是 Metrics API 的参考实现。
Metrics API: Kubernetes API 支持访问用于工作负载自动缩放的 CPU 和内存。要在你的集群中进行这项工作，你需要一个提供 Metrics API 的 API 扩展服务器。
说明： cAdvisor 支持从 cgroups 读取指标，它适用于 Linux 上的典型容器运行时。如果你使用基于其他资源隔离机制的容器运行时，例如虚拟化，那么该容器运行时必须支持 CRI 容器指标以便 kubelet 可以使用指标。

Metrics API

特性状态： Kubernetes 1.8 [beta]

metrics-server 实现了 Metrics API。此 API 允许你访问集群中节点和 Pod 的 CPU 和内存使用情况。它的主要作用是将资源使用指标提供给 K8s 自动缩放器组件。

下面是一个 minikube 节点的 Metrics API 请求示例，通过 jq 管道处理以便于阅读：

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.'

这是使用 curl 来执行的相同 API 调用：

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes/minikube

响应示例：

{
  "kind": "NodeMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "minikube",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/minikube",
    "creationTimestamp": "2022-01-27T18:48:43Z"
  },
  "timestamp": "2022-01-27T18:48:33Z",
  "window": "30s",
  "usage": {
    "cpu": "487558164n",
    "memory": "732212Ki"
  }
}

下面是一个 kube-system 命名空间中的 kube-scheduler-minikube Pod 的 Metrics API 请求示例，通过 jq 管道处理以便于阅读：

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.'

这是使用 curl 来完成的相同 API 调用：

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube

响应示例：

{
  "kind": "PodMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "kube-scheduler-minikube",
    "namespace": "kube-system",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube",
    "creationTimestamp": "2022-01-27T19:25:00Z"
  },
  "timestamp": "2022-01-27T19:24:31Z",
  "window": "30s",
  "containers": [
    {
      "name": "kube-scheduler",
      "usage": {
        "cpu": "9559630n",
        "memory": "22244Ki"
      }
    }
  ]
}

Metrics API 在 k8s.io/metrics 代码库中定义。你必须启用 API 聚合层并为 metrics.k8s.io API 注册一个 APIService。

要了解有关 Metrics API 的更多信息，请参阅资源 Resource Metrics API Design、 metrics-server 代码库和 Resource Metrics API。

说明：

你必须部署提供 Metrics API 服务的 metrics-server 或其他适配器才能访问它。

度量资源用量

CPU

CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes 中，一个 cpu 相当于云提供商的 1 个 vCPU/Core，以及裸机 Intel 处理器上的 1 个超线程。

该值是通过对内核提供的累积 CPU 计数器（在 Linux 和 Windows 内核中）取一个速率得出的。用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。

要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅 CPU 的含义。

内存

内存报告为在收集度量标准的那一刻的工作集大小，以字节为单位。

在理想情况下，“工作集”是在内存压力下无法释放的正在使用的内存量。然而，工作集的计算因主机操作系统而异，并且通常大量使用启发式算法来产生估计。

Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容器关联的匿名内存。工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。

要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，请参阅内存的含义。

Metrics 服务器

metrics-server 从 kubelet 中获取资源指标，并通过 Metrics API 在 Kubernetes API 服务器中公开它们，以供 HPA 和 VPA 使用。你还可以使用 kubectl top 命令查看这些指标。

metrics-server 使用 Kubernetes API 来跟踪集群中的节点和 Pod。metrics-server 服务器通过 HTTP 查询每个节点以获取指标。 metrics-server 还构建了 Pod 元数据的内部视图，并维护 Pod 健康状况的缓存。缓存的 Pod 健康信息可通过 metrics-server 提供的扩展 API 获得。

例如，对于 HPA 查询，metrics-server 需要确定哪些 Pod 满足 Deployment 中的标签选择器。

metrics-server 调用 kubelet API 从每个节点收集指标。根据它使用的度量服务器版本：

版本 v0.6.0+ 中，使用指标资源端点 /metrics/resource
旧版本中使用 Summary API 端点 /stats/summary

接下来

了解更多 metrics-server，参阅 metrics-server 代码库。

你还可以查看以下内容：

若要了解 kubelet 如何提供节点指标以及你可以如何通过 Kubernetes API 访问这些指标，请阅读节点指标数据。

3 - 节点健康监测

节点问题检测器（Node Problem Detector） 是一个守护程序，用于监视和报告节点的健康状况。你可以将节点问题探测器以 DaemonSet 或独立守护程序运行。节点问题检测器从各种守护进程收集节点问题，并以节点 Condition 和 Event 的形式报告给 API 服务器。

要了解如何安装和使用节点问题检测器，请参阅节点问题探测器项目文档。

准备开始

你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

局限性

节点问题检测器使用内核日志格式来报告内核问题。要了解如何扩展内核日志格式，请参阅添加对另一个日志格式的支持。

启用节点问题检测器

一些云供应商将节点问题检测器以插件形式启用。你还可以使用 kubectl 或创建插件 DaemonSet 来启用节点问题探测器。

使用 kubectl 启用节点问题检测器

kubectl 提供了节点问题探测器最灵活的管理。你可以覆盖默认配置使其适合你的环境或检测自定义节点问题。例如：

创建类似于 node-strought-detector.yaml 的节点问题检测

apiVersion: apps/v1 style=color:green;font-weight:700>kind: DaemonSet style=color:green;font-weight:700>metadata: name: node-problem-detector-v0.1 namespace: kube-system labels: k8s-app: node-problem-detector version: v0.1 kubernetes.io/cluster-service: "true" style=color:green;font-weight:700>spec: selector: matchLabels: k8s-app: node-problem-detector   version: v0.1 kubernetes.io/cluster-service: "true" template: metadata: labels: k8s-app: node-problem-detector version: v0.1 kubernetes.io/cluster-service: "true" spec: hostNetwork: true containers: - name: node-problem-detector image: registry.k8s.io/node-problem-detector:v0.1 securityContext: privileged: true resources: limits: cpu: "200m" memory: "100Mi" requests: cpu: "20m" memory: "20Mi" volumeMounts: - name: log mountPath: /log readOnly: true volumes: - name: log hostPath: path: /var/log/

集群故障排查

列举集群节点

示例：调试关闭/无法访问的节点

查看日志

控制平面节点

工作节点

集群故障模式

故障原因

具体情况

缓解措施

接下来

1 - 资源监控工具

资源度量管道

完整度量管道

接下来

2 - 资源指标管道

Metrics API

度量资源用量

CPU

内存

Metrics 服务器

接下来

3 - 节点健康监测

准备开始

局限性

启用节点问题检测器

使用 kubectl 启用节点问题检测器

使用插件 Pod 启用节点问题检测器

覆盖配置文件

问题守护程序

增加对其他日志格式的支持

添加自定义插件监视器

导出器

建议和限制

4 - 使用 crictl 对 Kubernetes 节点进行调试

准备开始

安装 crictl

一般用法

crictl 命令示例

打印 Pod 清单

打印镜像清单

打印容器清单

在正在运行的容器上执行命令

获取容器日志

运行 Pod 沙盒

创建容器

启动容器

接下来

5 - Windows 调试技巧

工作节点级别排障

网络排障

Flannel 故障排查

进一步探查

6 - 审计

审计策略

审计后端

Log 后端

Webhook 后端

事件批处理

参数调整

日志条目截断

7 - 使用 telepresence 在本地开发和调试服务

准备开始

从本机连接到远程 Kubernetes 集群

开发和调试现有的服务

Telepresence 是如何工作的？

接下来

8 - 用 Kubectl 调试 Kubernetes 节点

准备开始

使用 kubectl debug node 调试节点

清理现场

使用 `kubectl debug node` 调试节点