容器见解故障排除

使用容器见解配置 Azure Kubernetes 服务 (AKS) 群集的监视时,可能会遇到阻止数据收集或报告状态的问题。 本文讨论了一些常见问题及其排查步骤。

已知错误消息

下表汇总了使用容器见解时可能遇到的已知错误。

错误消息 操作
错误消息“所选筛选器没有数据” 为新创建的群集建立监视数据流可能需要一段时间。 群集的数据至少需要 10 到 15 分钟才能显示。

如果数据仍未显示,请检查是否为 disableLocalAuth = true 配置了 Log Analytics 工作区。 如果已配置,请更新回 disableLocalAuth = false

az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"

az resource update --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]" --api-version "2021-06-01" --set properties.features.disableLocalAuth=False
错误消息“检索数据时出错” 为 AKS 群集设置运行状况和性能监视时,会在群集与 Log Analytics 工作区之间建立连接。 Log Analytics 工作区用于存储你的群集的所有监视数据。 当 Log Analytics 工作区已删除时,可能会发生此错误。 检查是否已删除工作区。 如果是这样,请使用容器见解重新启用群集监视。 然后指定现有工作区或者创建新的工作区。 若要重新启用,将需要对该群集禁用监视,然后再次启用容器见解。
通过 az aks cli 添加容器见解后出现“检索数据时出错” 使用 az aks cli 启用监视时,可能无法正确部署容器见解。 请检查是否部署了该解决方案。 若要进行验证,请转到你的 Log Analytics 工作区,从左侧的窗格中选择“旧版解决方案”来查看该解决方案是否可用。 若要解决此问题,请重新部署解决方案。 按照启用容器见解中的说明进行操作。
错误消息“缺少订阅注册” 如果收到“缺少 Microsoft.OperationsManagement 的订阅注册”错误,可通过在定义工作区的订阅中注册资源提供程序 Microsoft.OperationsManagement 来解决它。 有关步骤,请参阅解决资源提供程序注册的错误
错误消息“在请求中指定的回复 URL 与为应用程序“<应用程序 ID>”配置的回复 URL 不匹配。 启用实时日志时,可能会看到此错误消息。 有关解决方案,请参阅使用容器见解实时查看容器数据

为了帮助诊断问题,我们提供了一个故障排除脚本

在执行载入或更新操作期间出现授权错误

启用容器见解或更新群集以支持收集指标时,可能会收到类似于以下内容的错误:“对象 ID 为 <user's objectId> 的客户端 <user's Identity> 无权对范围执行操作 Microsoft.Authorization/roleAssignments/write”。

在载入或更新过程中,将对群集资源尝试授予“监视指标发布服务器” 角色分配。 如果用户要启动为容器启用容器见解或用于支持收集指标的更新,则该用户必须可以访问 AKS 群集资源作用域上的 Microsoft.Authorization/roleAssignments/write 权限。 只有所有者和用户访问管理员内置角色的成员才被授权访问此权限。 如果安全策略要求分配粒度级别的权限,请查看 Azure 自定义角色并将权限分配给需要它的用户。

还可以从 Azure 门户手动授予此角色:将“发布者”角色分配到“监视指标”范围。 有关详细步骤,请参阅使用 Azure 门户分配 Azure 角色

已启用容器见解,但未报告任何信息

如果无法查看状态信息或日志查询未返回任何结果,请使用以下步骤诊断问题:

  1. 通过运行以下命令检查代理状态:

    kubectl get ds ama-logs --namespace=kube-system

    Pod 数应等于群集上的 Linux 节点数。 输出应类似于以下示例,指示已正确部署:

    User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
    NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
    ama-logs   2         2         2         2            2           <none>           1d
    
  2. 如果有 Windows Server 节点,请通过运行以下命令检查代理状态:

    kubectl get ds ama-logs-windows --namespace=kube-system

    Pod 数应等于群集上的 Windows 节点数。 输出应类似于以下示例,指示已正确部署:

    User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
    NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
    ama-logs-windows           2         2         2         2            2           <none>       1d
    
  3. 使用以下命令检查部署状态:

    kubectl get deployment ama-logs-rs --namespace=kube-system

    输出应类似于以下示例,指示已正确部署:

    User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
    NAME          READY   UP-TO-DATE   AVAILABLE   AGE
    ama-logs-rs   1/1     1            1           24d
    
  4. 使用命令 kubectl get pods --namespace=kube-system 检查 Pod 的状态,验证它是否正在运行。

    输出应类似于以下示例,ama-logs 状态为 Running

    User@aksuser:~$ kubectl get pods --namespace=kube-system
    NAME                                READY     STATUS    RESTARTS   AGE
    aks-ssh-139866255-5n7k5             1/1       Running   0          8d
    azure-vote-back-4149398501-7skz0    1/1       Running   0          22d
    azure-vote-front-3826909965-30n62   1/1       Running   0          22d
    ama-logs-484hw                      1/1       Running   0          1d
    ama-logs-fkq7g                      1/1       Running   0          1d
    ama-logs-windows-6drwq              1/1       Running   0          1d
    
  5. 如果 pod 处于运行状态,但 Log Analytics 中没有数据,或者数据似乎只在一天中的某一时段发送,则表明可能已达到每日上限。 如果每天都达到此限制,数据将停止引入 Log Analytics 工作区并在重置时重置。 有关详细信息,请参阅 Log Analytics 每日上限

  6. 如果使用 Terraform 启用了容器见解,且 msi_auth_for_monitoring_enabled 设置为 true,请确保也部署了 DCR 和 DCRA 资源,以启用日志收集。 有关详细步骤,请参阅启用容器见解

未在非 AKS 群集上计划容器见解代理 ReplicaSet Pod

容器见解代理 ReplicaSet Pod 依赖于工作器(或代理)节点上的以下节点选择器来进行计划:

nodeSelector:
  beta.kubernetes.io/os: Linux
  kubernetes.io/role: agent

如果工作器节点未附加节点标签,则将不会计划代理 ReplicaSet Pod。 有关如何附加标签的说明,请参阅 Kubernetes 分配标签选择器

性能图表不显示非 Azure 群集上节点和容器的 CPU 或内存

容器见解代理 Pod 使用节点代理上的 cAdvisor 终结点来收集性能指标。 验证节点上的容器化代理是否配置为允许在群集中的所有节点上打开 cAdvisor secure port: 10250cAdvisor unsecure port: 10255 以收集性能指标。

容器见解中不会显示非 AKS 群集

要在容器见解中查看非 AKS 群集,需要在支持此见解的 Log Analytics 工作区和容器见解解决方案资源 ContainerInsights(工作区)上具有读取访问权限。

未收集指标

  1. 使用以下 CLI 命令验证是否存在“监视指标发布者”角色分配:

    az role assignment list --assignee "SP/UserassignedMSI for Azure Monitor Agent" --scope "/subscriptions/<subid>/resourcegroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<clustername>" --role "Monitoring Metrics Publisher"
    

    对于具有 MSI 的群集,每次启用和禁用监视时,用户分配的 Azure Monitor 代理客户端 ID 都会更改,因此当前 MSI 客户端 ID 上应存在角色分配。

  2. 对于启用了 Microsoft Entra Pod 标识并使用 MSI 的群集:

    • 使用以下命令验证 Azure Monitor 代理 Pod 上是否存在所需的“kubernetes.azure.com/managedby: aks”标签:

      kubectl get pods --show-labels -n kube-system | grep ama-logs

    • 验证使用 https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity 上其中一种受支持的方法启用 Pod 标识时是否启用了异常。

      运行以下命令验证:

      kubectl get AzurePodIdentityException -A -o yaml

      应该会收到类似如下示例的输出:

      apiVersion: "aadpodidentity.k8s.io/v1"
      kind: AzurePodIdentityException
      metadata:
      name: mic-exception
      namespace: default
      spec:
      podLabels:
      app: mic
      component: mic
      ---
      apiVersion: "aadpodidentity.k8s.io/v1"
      kind: AzurePodIdentityException
      metadata:
      name: aks-addon-exception
      namespace: kube-system
      spec:
      podLabels:
      kubernetes.azure.com/managedby: aks
      

在已启用 Azure Arc 的 Kubernetes 群集上的 Azure Monitor 容器扩展安装失败

“清单包含了已存在的资源”错误表明已启用 Azure Arc 的 Kubernetes 群集上已经存在了容器见解代理的资源。 此错误指示已安装容器见解代理。 它通过 azuremonitor-containers Helm 图表或监视加载项进行安装(如果是通过 Azure Arc 连接的 AKS 群集)。

此问题的解决方案是清理容器见解代理的现有资源(如果存在)。 然后,启用 Azure Monitor 容器扩展。

对于非 AKS 群集

  1. 对于连接到 Azure Arc 的 K8s 群集,运行以下命令以验证 azmon-containers-release-1 Helm 图表版本是否存在:

    helm list -A

  2. 如果前面命令的输出表明 azmon-containers-release-1 存在,则删除 Helm 图表版本:

    helm del azmon-containers-release-1

对于 AKS 群集

  1. 运行以下命令并查找 Azure Monitor 代理加载项配置文件,以验证是否已启用 AKS 监视加载项:

    az  account set -s <clusterSubscriptionId>
    az aks show -g <clusterResourceGroup> -n <clusterName>
    
  2. 如果输出包含具有日志分析工作区资源 ID 的 Azure Monitor 代理加载项配置文件配置,此信息则表示已启用 AKS 监视加载项,必须禁用它:

    az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>

如果前面的步骤未能解决 Azure Monitor 容器扩展的安装问题,请向 Microsoft 创建支持票证以进行进一步调查。

复制收到的警报

可能已启用 Prometheus 警报规则,而未禁用容器见解建议的警报。

我看到信息横幅“你没有适当的群集权限,这会限制你对容器见解功能的访问。 请联系你的群集管理员以获取正确的权限”

容器见解历来允许用户根据 Log Analytics 工作区的访问权限访问 Azure 门户体验。 它现在会检查群集级权限,以提供对 Azure 门户体验的访问权限。 你可能需要让你的群集管理员分配此权限。

对于基本的只读群集级别访问权限,请为以下类型的群集分配“监视读取者”角色。

  • 未启用 Kubernetes 基于角色的访问控制 (RBAC) 授权的 AKS
  • 使用基于 Microsoft Entra SAML 的单一登录启用的 AKS
  • 启用了 Kubernetes RBAC 授权的 AKS
  • 配置了群集角色绑定 clusterMonitoringUser 的 AKS
  • 已启用 Azure Arc 的 Kubernetes 群集

有关如何为 AKS 分配这些角色的详细信息,请参阅向用户或组分配角色权限;有关角色分配的详细信息,请参阅 Azure Kubernetes 服务 (AKS) 的访问和标识选项

查询 ContainerLog 表时,没看到填充有 Image 和 Name 属性值

对于代理版本 ciprod12042019 及更高版本,为了尽量减少收集日志数据时产生的费用,默认情况下不会为每行日志填充这两个属性。 有两种方法可用于查询表,查询包含这些属性及其值:

选项 1

联接其他表,在结果中包含这些属性值。

通过在 ContainerID 属性上进行联接,将查询修改为包含 ContainerInventory 表中的 ImageImageTag 属性。 通过在 ContainerID 属性上进行联接,可以包含 KubepodInventory 表的 ContainerName 字段中的 Name 属性(与以前在 ContainerLog 表中显示的相同)。 我们建议使用此选项。

下面是一个详细查询示例,说明了如何使用联接来获取这些字段值。

//Let's say we're querying an hour's worth of logs
let startTime = ago(1h);
let endTime = now();
//Below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//Below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//Now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//Now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were rewritten
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types, etc.)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

方法 2

为每行容器日志的这些属性重新启用收集功能。

如果第一个选项因涉及到更改查询而不便使用,可以重新启用收集这些字段。 按照数据收集配置设置中所述,在代理配置映射中启用设置 log_collection_settings.enrich_container_logs

注意

对于包含 50 个以上节点的大型群集,不建议使用第二个选项。 它将从群集中的每个节点生成 API 服务器调用以执行此扩充。 该方法还会增加收集到的每行日志的数据大小。

在加入后无法升级群集

场景如下:你为 Azure Kubernetes 服务群集启用了容器见解。 然后,你删除了群集向其发送数据的 Log Analytics 工作区。 现在,当你尝试升级群集时,它会失败。 若要解决此问题,你必须禁用再重新启用监视功能,使其引用订阅中的其他有效工作区。 在你重新尝试升级群集时,应该就会处理并成功完成。

不收集 Azure Stack HCI 群集上的日志

如果在 2023 年 11 月之前注册了群集和/或配置了 HCI 见解,在 HCI 上使用 Azure Monitor 代理的功能(例如 Arc for Servers 见解、VM 见解、容器见解、Defender for Cloud 或 Microsoft Sentinel)可能无法正确收集日志和事件数据。 有关重新配置代理和 HCI Insights 的步骤,请参阅修复 HCI 的 AMA 代理

后续步骤

启用监视来捕获 AKS 群集节点和 Pod 的运行状况指标后,可在 Azure 门户中找到这些运行状况指标。 要了解如何使用容器见解,请参阅查看 Azure Kubernetes 服务运行状况