容器见解故障排除

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

已知错误消息

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

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

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

启用容器见解或更新群集以支持收集指标时，可能会收到类似于以下内容的错误：“对象 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: 10250 或 cAdvisor 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 表中的 Image 和 ImageTag 属性。 通过在 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。

在加入后无法升级群集

场景如下：你为 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 服务运行状况。