检查节点和 Pod 健康状况

本文是一系列文章的其中一篇。 从 概述开始。

如果您在上一步执行的群集检查均正常，请检查 Azure Kubernetes 服务（AKS）工作节点的运行状态。 按照本文中的六个步骤检查节点的运行状况，确定运行不正常的节点的原因，并解决问题。

步骤 1：检查工作器节点的运行状况

各种因素可能导致 AKS 群集中的节点运行不正常。 一个常见原因是控制平面与节点之间的通信崩溃。 这种错误通信通常是路由和防火墙规则中的配置错误引起的。

为 用户定义的路由配置 AKS 群集时，必须通过网络虚拟设备（NVA）或防火墙（例如 Azure 防火墙）配置出口路径。 若要解决配置错误问题，建议根据 AKS 出口流量指南配置防火墙，以允许必要的端口和完全限定的域名（FQDN）。

运行不正常的节点可能是由于计算、内存或存储资源不足，导致 kubelet 承受压力。 在这种情况下，纵向扩展资源可以有效地解决问题。

在 专用 AKS 群集中，域名系统（DNS）解决问题可能会导致控制平面和节点之间的通信问题。 您必须验证 Kubernetes API 服务器的 DNS 名称是否解析为 API 服务器的专用 IP 地址。 自定义 DNS 服务器的配置不正确是 DNS 解析失败的常见原因。 如果使用自定义 DNS 服务器，请确保将其正确指定为预配节点的虚拟网络上的 DNS 服务器。 另请确认可以通过自定义 DNS 服务器解析 AKS 专用 API 服务器。

解决与控制平面通信和 DNS 解析相关的这些潜在问题后，可以有效地解决 AKS 群集中的节点运行状况问题。

可以使用以下方法之一来评估节点的运行状况。

Azure Monitor 容器运行状况视图

若要查看 AKS 群集中节点、用户 Pod 和系统 Pod 的运行状况，请执行以下步骤：

1. 在 Azure 门户中转到“Azure Monitor”。
2. 在导航窗格的 “见解 ”部分中，选择“ 容器”。
3. 选择受监视的群集以查看正在监视的 AKS 群集列表。
4. 从列表中选择 AKS 群集以查看节点、用户 Pod 和系统 Pod 的运行状况。

AKS 节点视图

若要确保 AKS 群集中的所有节点都处于就绪状态，请执行以下步骤：

1. 在 Azure 门户中，转到 AKS 群集。
2. 在导航窗格的 “设置” 部分中，选择 “节点池”。
3. 选择“节点”。
4. 验证所有节点是否处于就绪状态。

使用 Prometheus 和 Grafana 进行群集内监视

如果在 AKS 群集中部署 了 Prometheus 和 Grafana ，则可以使用 K8 群集详细信息仪表板 获取见解。 此仪表板显示 Prometheus 群集指标，并显示重要信息，例如 CPU 使用率、内存使用情况、网络活动和文件系统使用情况。 它还会显示各个 Pod、容器和 systemd 服务的详细统计信息。

在仪表板中，选择 “节点条件 ”以查看有关群集运行状况和性能的指标。 可以跟踪可能存在问题的节点，例如其计划、网络、磁盘压力、内存压力、成比例积分派生（PID）压力或磁盘空间等问题。 监视这些指标，以便可以主动识别和解决影响 AKS 群集可用性和性能的任何潜在问题。

监视 Prometheus 和 Azure 托管 Grafana 的托管服务

可以使用预生成的仪表板来可视化和分析 Prometheus 指标。 为此，必须设置 AKS 群集，以在 Prometheus 的 Monitor 托管服务中收集 Prometheus 指标，并将 Monitor 工作区 连接到 Azure 托管 Grafana 工作区。 这些仪表板 提供 Kubernetes 群集性能和运行状况的综合视图。

仪表板在“托管 Prometheus”文件夹中的指定 Azure 托管 Grafana 实例中预配。 一些仪表板包括：

• Kubernetes/计算资源/群集
• Kubernetes /计算资源/命名空间 (Pod)
• Kubernetes /计算资源/节点 (Pod)
• Kubernetes/计算资源/Pod
• Kubernetes/计算资源/命名空间（工作负荷）
• Kubernetes/计算资源/工作负荷
• Kubernetes /Kubelet
• 节点导出程序/USE 方法/节点
• 节点导出程序/节点
• Kubernetes / 计算资源 / 群集 （Windows）
• Kubernetes / 计算资源 / 命名空间 （Windows）
• Kubernetes / 计算资源 / Pod （Windows）
• Kubernetes / USE 方法/群集 (Windows)
• Kubernetes / USE 方法/节点 (Windows)

这些内置仪表板在开源社区中广泛使用，用于使用 Prometheus 和 Grafana 监视 Kubernetes 群集。 使用这些仪表板可查看指标，例如资源使用情况、Pod 运行状况和网络活动。 还可以创建自定义仪表板，以满足监视需求。 仪表板可帮助你有效地监视和分析 AKS 群集中的 Prometheus 指标，从而优化性能、排查问题并确保 Kubernetes 工作负载的顺利运行。

可以使用 Kubernetes/计算资源/节点（Pods） 仪表板查看 Linux 代理节点的指标。 可以可视化每个 Pod 的 CPU 使用率、CPU 配额、内存使用情况和内存配额。

如果群集包含 Windows 代理节点，则可以使用 Kubernetes/USE 方法/节点（Windows） 仪表板可视化从这些节点收集的 Prometheus 指标。 此仪表板提供群集中 Windows 节点的资源消耗和性能的综合视图。

利用这些专用仪表板，可以轻松地监视和分析与 Linux 和 Windows 代理节点中的 CPU、内存和其他资源相关的重要指标。 通过此可见性，可以识别潜在的瓶颈、优化资源分配，并确保在 AKS 群集中高效作。

步骤 2：验证控制平面和工作器节点连接

如果工作器节点正常，则应检查托管 AKS 控制平面与群集工作器节点之间的连接。 AKS 允许通过安全隧道通信方法在 Kubernetes API 服务器 与单个节点 kubelets 之间进行通信。 即使这些组件位于不同的虚拟网络上，这些组件也可以进行通信。 隧道使用相互传输层安全性（mTLS）加密进行保护。 AKS 使用的主要隧道称为 Konnectivity（以前称为 apiserver-network-proxy）。 确保所有网络规则和 FQDN 都符合所需的 Azure 网络规则。

若要验证托管 AKS 控制平面与 AKS 群集的群集工作器节点之间的连接，可以使用 kubectl 命令行工具。

若要确保 Konnectivity Agent Pod 正常工作，请运行以下命令：

kubectl get deploy konnectivity-agent -n kube-system

确保 Pod 处于就绪状态。

如果控制平面与工作器节点之间的连接出现问题，请在确保允许所需的 AKS 出口流量规则后建立连接。

运行以下命令以重启 konnectivity-agent Pod：

kubectl rollout restart deploy konnectivity-agent -n kube-system

如果重启 Pod 无法修复连接，请检查日志中是否存在任何异常。 运行以下命令以查看 konnectivity-agent pods 的日志：

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

日志应显示以下输出：

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

还可以在日志记录和监视服务中搜索容器日志以检索日志。 有关搜索 aks-link 连接错误的示例，请参阅从容器见解查询日志。

运行以下查询以检索日志：

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

运行以下查询，搜索特定命名空间中任何失败的 Pod 的容器日志：

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

如果无法使用查询或 kubectl 工具获取日志，请使用 安全外壳（SSH）身份验证。 此示例通过 SSH 连接到节点后查找 tunnelfront pod。

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

步骤 3：限制出口时验证 DNS 解析

DNS 解析是 AKS 群集的关键方面。 如果 DNS 解析无法正常工作，可能会导致控制平面错误或容器映像拉取失败。 若要确保 Kubernetes API 服务器的 DNS 解析正常运行，请执行以下步骤：

1. 运行 kubectl exec 命令，在 Pod 中运行的容器中打开命令行界面。

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. 检查容器中是否安装了 nslookup 或 挖掘 工具。

3. 如果 Pod 中未安装这两个工具，请运行以下命令，在同一命名空间中创建实用工具 Pod。

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. 可以从 Azure 门户中 AKS 群集的概述页检索 API 服务器地址，也可以运行以下命令。

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. 运行以下命令以尝试解析 AKS API 服务器。 有关详细信息，请参阅 从 Pod 内部对 DNS 解析失败进行故障排除，而不是从工作器节点进行故障排除。

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. 检查 Pod 中的上游 DNS 服务器，以确定 DNS 解析是否正常工作。 例如，对于 Azure DNS，请运行 nslookup 命令。

   nslookup microsoft.com 168.63.129.16
   

7. 如果前面的步骤不提供见解， 请连接到其中一个工作器节点，然后尝试从节点进行 DNS 解析。 此步骤有助于确定问题是否与 AKS 或网络配置相关。

8. 如果从节点成功解析 DNS，但从 Pod 无法解析，则问题可能与 Kubernetes DNS 有关。 有关从 Pod 调试 DNS 解析的步骤，请参阅排查 DNS 解析失败问题。

   如果 DNS 解析从节点失败，请查看网络设置，确保打开适当的路由路径和端口，以方便 DNS 解析。

步骤 4：检查 kubelet 错误

验证在每个工作节点上运行的 kubelet 进程的条件，并确保它没有任何压力。 潜在的压力可能与 CPU、内存或存储有关。 若要验证单个节点 kubelets 的状态，可以使用以下方法之一。

AKS kubelet 工作簿

若要确保代理节点 kubelets 正常工作，请执行以下步骤：

1. 在 Azure 门户中，转到 AKS 群集。

2. 在导航窗格的“ 监视 ”部分中，选择 “工作簿”。

3. 选择“Kubelet”工作簿。

   

4. 选择 操作，确保所有工作节点的操作已完成。

   

使用 Prometheus 和 Grafana 进行群集内监视

如果在 AKS 群集中部署 了 Prometheus 和 Grafana ，则可以使用 Kubernetes/Kubelet 仪表板来深入了解各个节点 kubelets 的运行状况和性能。

监视 Prometheus 和 Azure 托管 Grafana 的托管服务

可以使用 Kubernetes/Kubelet 预生成仪表板可视化和分析工作节点 kubelets 的 Prometheus 指标。 为此，必须设置 AKS 群集，以在 Prometheus 的 Monitor 托管服务中收集 Prometheus 指标，并将 Monitor 工作区 连接到 Azure 托管 Grafana 工作区。

当 kubelet 重启并导致偶发的不可预知行为时，压力会增加。 确保错误计数不会持续增加。 偶尔出现错误是可以接受的，但持续增长表示必须调查和解决的基础问题。

步骤 5：使用节点问题检测器（NPD）工具来检查节点运行状况

NPD 是一种 Kubernetes 工具，可用于识别和报告节点相关问题。 它在群集中的每个节点上作为系统服务运行。 它收集指标和系统信息，例如 CPU 使用率、磁盘使用情况和网络连接状态。 检测到问题时，NPD 工具会生成有关事件和节点条件的报告。 在 AKS 中，NPD 工具用于监视和管理 Azure 云上托管的 Kubernetes 群集中的节点。 有关详细信息，请参阅 AKS 节点中的 NPD。

步骤 6：检查磁盘每秒 I/O 操作数 (IOPS) 是否有限制

为了确保 IOPS 不受限制并影响 AKS 群集中的服务和工作负荷，可以使用以下方法之一。

AKS 节点磁盘 I/O 工作簿

若要监视 AKS 群集中工作节点的磁盘 I/O 相关指标，可以使用 节点磁盘 I/O 工作簿。 按照以下步骤访问工作簿：

1. 在 Azure 门户中，转到 AKS 群集。

2. 在导航窗格的“ 监视 ”部分中，选择 “工作簿”。

3. 选择“节点磁盘 IO”工作簿。

   

4. 查看与 I/O 相关的指标。

   

使用 Prometheus 和 Grafana 进行群集内监视

如果在 AKS 群集中部署 了 Prometheus 和 Grafana ，则可以使用 USE 方法/节点 仪表板获取有关群集工作器节点磁盘 I/O 的见解。

监视 Prometheus 和 Azure 托管 Grafana 的托管服务

可以使用 节点导出程序/节点 预生成仪表板可视化和分析工作器节点中的磁盘 I/O 相关指标。 为此，必须设置 AKS 群集，以在 Prometheus 的 Monitor 托管服务中收集 Prometheus 指标，并将 Monitor 工作区 连接到 Azure 托管 Grafana 工作区。

IOPS 和 Azure 磁盘

物理存储设备在带宽方面具有固有的限制，以及可以处理的最大文件作数。 Azure 磁盘用于存储 AKS 节点上运行的作系统。 磁盘受到与作系统相同的物理存储约束。

考虑吞吐量的概念。 可以将平均 I/O 大小乘以 IOPS 来确定每秒吞吐量（MBps）。 由于磁盘的固定吞吐量，较大的 I/O 大小转换为较低的 IOPS。

当工作负荷超过分配给 Azure 磁盘的最大 IOPS 服务限制时，群集可能会无响应并进入 I/O 等待状态。 在基于 Linux 的系统中，许多组件被视为文件，例如网络套接字、CNI、Docker 和其他依赖于网络 I/O 的服务。 因此，如果无法读取磁盘，故障将扩展到所有这些文件。

多个事件和场景可以触发 IOPS 限制，包括：

• 由于 Docker I/O 与操作系统磁盘共享，一个节点上运行着大量的容器。

• 用于安全、监控和日志记录的自定义或第三方工具，这可能会在操作系统磁盘上生成额外的 I/O 操作。

• 出现节点故障转移事件和定期作业，这会增加工作负载或缩放 Pod 数量。 这种增加的负载会加大发生限流的可能性，这可能导致所有节点在 I/O操作结束之前过渡到 未就绪 状态。

供稿人

本文由Microsoft维护。 它最初是由以下贡献者撰写的。

主要作者：

• 保罗·萨尔瓦托里 |首席客户工程师
• 弗朗西斯·西米·纳扎雷斯 |高级技术专家

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

• 虚拟机磁盘限制
• 虚拟机和磁盘性能

相关资源