你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

检查节点和 Pod 健康状况

项目
02/19/2024

本文是一系列文章的其中一篇。让我们先了解一下概述。

如果在上一步执行的群集检查中未发现问题，请检查 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 的健康状况，请执行以下步骤：

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

AKS 节点视图

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

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

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

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

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

可以使用预生成的仪表板来可视化和分析 Prometheus 指标。为此，必须设置 AKS 群集，以在监视适用于 Prometheus 的托管服务中收集 Prometheus 指标，并将监视工作区连接到 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 /计算资源/节点 (Pod) 仪表板查看 Linux 代理节点的指标。可以可视化每个 Pod 的 CPU 使用率、CPU 配额、内存使用情况和内存配额。

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

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

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

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

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

若要确保 Konnectivity 代理 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 Pod 日志：

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"

注意

使用 API 服务器虚拟网络集成和 Azure 容器网络接口 (CNI) 或具有动态 Pod IP 分配的 Azure CNI 设置 AKS 群集时，无需部署 Konnectivity 代理。集成 API 服务器 Pod 可以通过专用网络与群集工作器节点建立直接通信。

但是，将 API 服务器虚拟网络集成与 Azure CNI 覆盖或自带 CNI (BYOCNI) 配合使用时，将部署 Konnectivity，以实现 API 服务器和 Pod IP 之间的通信。 API 服务器与工作器节点之间的通信仍为直接通信。

还可以通过在日志记录和监视服务中搜索容器日志来检索这些日志。有关搜索 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 解析正常运行，请执行以下步骤：

运行 kubectl exec 命令，在 Pod 中运行的容器中打开命令行界面。
```
kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
```
检查容器中是否安装了 nslookup 或 dig 工具。
如果 Pod 中未安装这两个工具，请运行以下命令，在同一命名空间中创建实用工具 Pod。
```
kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
```
可以从 Azure 门户中 AKS 群集的概述页检索 API 服务器地址，也可以运行以下命令。
```
az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
```
运行以下命令以尝试解析 AKS API 服务器。有关详细信息，请参阅从 Pod（而不是工作器节点）中排查 DNS 解析失败问题。
```
nslookup myaks-47983508.hcp.westeurope.azmk8s.io
```
从 Pod 检查上游 DNS 服务器，以确定 DNS 解析是否正常工作。例如，对于 Azure DNS，请运行 nslookup 命令。
```
nslookup microsoft.com 168.63.129.16
```
如果前面的步骤未提供见解，请连接到其中一个工作器节点，然后尝试从节点进行 DNS 解析。此步骤有助于确定问题是否与 AKS 或网络配置相关。
如果从节点而不是 Pod 成功解析 DNS，则问题可能与 Kubernetes DNS 相关。有关从 Pod 调试 DNS 解析的步骤，请参阅排查 DNS 解析失败问题。

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

步骤 4：检查 kubelet 错误

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

AKS kubelet 工作簿

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

在 Azure 门户中，转到 AKS 群集。
在导航窗格的“监视”部分中，选择“工作簿”。
选择“Kubelet”工作簿。
选择“操作”，并确保所有工作器节点的操作都已完成。

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

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

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

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

步骤 5：使用节点问题检测器 (NPD) 工具来检查节点健康状况

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

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

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

AKS 节点磁盘 I/O 工作簿

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

在 Azure 门户中，转到 AKS 群集。
在导航窗格的“监视”部分中，选择“工作簿”。
选择“节点磁盘 IO”工作簿。
查看与 I/O 相关的指标。

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

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

可以使用节点导出程序/节点预生成仪表板可视化和分析工作器节点中的磁盘 I/O 相关指标。为此，必须设置 AKS 群集，以在监视适用于 Prometheus 的托管服务中收集 Prometheus 指标，并将监视工作区连接到 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 维护，它最初是由以下贡献者撰写的。

主要作者：

Paolo Salvatori | 首席客户工程师
Francis Simy Nazareth |高级技术专家

若要查看非公开领英个人资料，请登录领英。

后续步骤

监视工作负载部署

通过

检查节点和 Pod 健康状况

步骤 1：检查工作器节点的健康状况

Azure Monitor 容器健康状况视图

AKS 节点视图

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

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

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

步骤 4：检查 kubelet 错误

AKS kubelet 工作簿

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

步骤 5：使用节点问题检测器 (NPD) 工具来检查节点健康状况

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

AKS 节点磁盘 I/O 工作簿

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

监视适用于 Prometheus 的托管服务和 Azure 托管 Grafana

IOPS 和 Azure 磁盘

作者

后续步骤

相关资源

反馈

其他资源