排查部署 AKS 群集扩展时出现的错误
本文介绍如何排查为 Microsoft Azure Kubernetes 服务（AKS）部署群集扩展时发生的错误。
扩展创建错误
错误：无法及时从代理获取响应
如果 Azure 服务未收到来自群集扩展代理的响应，则会发生此错误。 这种情况可能发生，因为 AKS 群集无法与 Azure 建立连接。
原因 1：群集扩展代理和管理器 Pod 未初始化
群集扩展代理和管理器是负责管理 Kubernetes 应用程序的生命周期的关键系统组件。 由于以下问题，群集扩展代理和管理器 Pod 的初始化可能会失败：
- 资源限制
- 策略限制
- 节点污点，例如
NoSchedule
解决方案 1：确保群集扩展代理和管理器 Pod 正常工作
若要解决此问题，请确保群集扩展代理和管理器 Pod 已正确安排并可以启动。 如果 Pod 停滞在未读状态，请运行以下命令 kubectl describe pod 来检查 Pod 说明，以获取有关潜在问题的更多详细信息（例如，阻止计划、内存不足或策略限制的污点）：
kubectl describe pod -n kube-system extension-operator-{id}
下面是命令输出示例：
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
对于 ARC 连接的群集，请运行以下命令来检查 Pod 说明：
kubectl describe pod -n azure-arc extension-manager-{id}
下面是命令输出示例：
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
群集扩展代理和管理器 Pod 正常运行时，它们与 Azure 服务建立通信，以安装和管理 Kubernetes 应用程序。
原因 2：问题会影响出口块或防火墙
如果群集扩展代理和管理器 Pod 正常运行，并且仍遇到“无法及时从代理获取响应”错误，则可能存在出口块或防火墙问题。 此问题可能会阻止群集扩展代理和管理器 Pod 与 Azure 通信。
解决方案 2：确保满足网络先决条件
若要解决此问题，请确保遵循出站网络和 Azure Kubernetes 服务 （AKS） 群集的 FQDN 规则中概述的网络先决条件。
原因 3：流量未获授权
扩展代理未成功尝试调用 <region>.dp.kubernetesconfiguration.azure.com 数据平面服务终结点。 此失败会生成扩展代理 Pod 日志中的“错误代码：403，消息此流量未获得授权”。
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
如果已启用 Azure Arc 的 Kubernetes 的扩展数据平面中存在预先存在的 PrivateLinkScope，并且虚拟网络（或专用 DNS 服务器）在已启用 Azure Arc 的 Kubernetes 与 AKS 托管群集之间共享，则会发生此错误。 此网络配置会导致来自扩展数据平面的 AKS 出站流量也通过同一专用 IP 地址而不是公共 IP 地址进行路由。
在 AKS 群集中运行以下 nslookup 命令，检索数据平面终结点解析为的特定专用 IP 地址：
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
在Azure 门户中搜索专用 IP 地址时，搜索结果将指向确切的资源：虚拟网络、专用 DNS 区域、专用 DNS 服务器等。 此资源具有为已启用 Azure Arc 的 Kubernetes 的扩展数据平面配置的专用终结点。
解决方案 3.1：（建议）创建单独的虚拟网络
若要解决此问题，我们建议为已启用 Azure Arc 的 Kubernetes 和 AKS 计算创建单独的虚拟网络。
解决方案 3.2：创建 CoreDNS 替代
如果你的情况中无法实现建议的解决方案，请为扩展数据平面终结点创建 CoreDNS 替代，以便通过公用网络。 有关如何自定义 CoreDNS 的详细信息，请参阅“使用 Azure Kubernetes 服务 自定义 CoreDNS”的“Hosts 插件”部分。
若要创建 CoreDNS 替代，请执行以下步骤：
通过运行以下命令
nslookup查找扩展数据平面终结点的公共 IP 地址。 请确保根据 AKS 群集的位置更改区域（例如eastus2euap），nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.net创建现有 coreDNS 配置的备份：
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yaml覆盖区域（例如）
eastus2euap数据平面终结点到公共 IP 地址的映射。 为此，请创建名为 corednsms.yaml 的 YAML 文件，然后将以下示例配置复制到新文件中。 （请确保使用环境的值更新地址和主机名。apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }若要创建 ConfigMap，请运行
kubectl apply命令，指定 YAML 清单文件的名称：kubectl apply -f corednsms.yaml若要重新加载 ConfigMap 并让 Kubernetes 计划程序在不停机的情况下重启 CoreDNS，请运行 kubectl 推出重启 命令：
kubectl -n kube-system rollout restart deployment corednsnslookup再次运行以下命令，确保数据平面终结点解析为提供的公共 IP 地址：kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
扩展代理 Pod 日志不应再记录“Errorcode： 403，消息此流量未获得授权”错误条目。 相反，日志应包含“200”响应代码。
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
错误：如果群集中的所有节点池被“CriticalAddonsOnly”污染，则无法计划扩展 Pod
发生此错误时，扩展代理日志中记录了以下条目：
扩展 Pod 错误：0/2 节点可用：2 个节点未中断 {CriticalAddonsOnly： true}。 抢占：0/2 节点可用：2 抢占对计划没有帮助。
原因
尝试在 AKS CriticalAddonsOnly 群集上启用已污染节点池的扩展（例如分布式应用程序运行时（DAPR）时，会发生此错误。 在这种情况下，扩展 Pod 不会在任何节点上计划，因为这些污点不存在容忍。
若要查看错误情况，请检查扩展 Pod 以验证它们是否停滞在挂起状态：
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
描述 Pod 以查看由于不受支持的污点而无法计划它们：
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
注意
建议不要在受污染的节点池上安装
CriticalAddOnsOnly扩展，除非对应用程序工作负荷执行此操作。建议不要在单节点池群集上使用
CriticalAddOnsOnly污点。 如果在只有一个节点池的群集中使用该污点，则无法在群集中计划应用程序 Pod。 请确保群集中至少有一个节点池没有此污点。 有关何时应使用批注的详细信息CriticalAddonsOnly，请参阅Azure Kubernetes 服务（AKS）中的管理系统节点池。
解决方案 1：将节点池添加到群集
若要解决此问题，请添加一个没有 CriticalAddonsOnly 污点的节点池。 此操作会导致在新的节点池上计划扩展 Pod。
解决方案 2：删除“CriticalAddonsOnly”污点
如果可能且可行，可以删除 CriticalAddonsOnly 污点，以便在群集上安装扩展。
Helm 错误
可能会遇到以下任何与 Helm 相关的错误：
错误：等待资源准备的超时
Kubernetes 应用程序的安装失败并显示以下错误消息：
作业失败：BackoffLimitExceeded
等待资源进入就绪/已完成状态的超时。
原因
此问题有以下常见原因：
资源约束：群集中的内存或 CPU 资源不足可以防止 Pod、作业或其他 Kubernetes 资源的成功初始化。 最终，这种情况会导致安装超时。策略约束或节点污点（如
NoSchedule）还可以阻止资源初始化。体系结构不匹配：尝试在基于 Windows 的节点（反之亦然）上计划基于 Linux 的应用程序可能会导致 Kubernetes 资源初始化失败。
配置设置不正确：配置设置不正确可能会阻止 Pod 启动。
解决方案
若要解决该问题，请执行以下步骤：
检查资源：确保 Kubernetes 群集有足够的资源，并且允许在节点上安排 Pod（应考虑污点）。 验证内存和 CPU 资源是否符合要求。
检查事件：检查 Kubernetes 命名空间中的事件，以确定可能阻止 Pod、作业或其他 Kubernetes 资源达到就绪状态的潜在问题。
检查 Helm 图表和配置：许多 Kubernetes 应用程序使用 Helm 图表在群集上部署资源。 某些应用程序可能需要通过配置设置进行用户输入。 确保所有提供的配置值都准确且满足安装要求。
错误：无法从存储库 URL 下载 Helm 图表
此错误是由群集与防火墙之间发生的连接问题以及出口阻止问题引起的。 若要解决此问题，请参阅 Azure Kubernetes 服务 （AKS） 群集的出站网络和 FQDN 规则。
错误：Helm 图表呈现失败并显示给定值
如果 Kubernetes 应用程序依赖于 Helm 图表在 Kubernetes 群集中部署资源，则会发生此错误。 这些应用程序可能需要通过安装过程中作为 Helm 值传递的配置设置提供的用户输入。 如果其中任一关键配置设置缺失或不正确，Helm 图表可能不会呈现。
若要解决此问题，请检查扩展或应用程序文档，以确定是在应用程序安装过程中省略任何必需值还是提供了不正确的值。 这些准则可以帮助你解决 Helm 图表呈现问题，这些问题是由缺少或不准确的配置值引起的。
错误：群集中已存在资源
如果群集中的 Kubernetes 资源与应用程序尝试安装的 Kubernetes 资源之间存在冲突，则会发生此错误。 错误消息通常指定冲突资源的名称。
如果冲突的资源至关重要且无法替换，则可能无法安装应用程序。 如果资源不关键且可删除，请删除冲突的资源，然后重试安装。
错误：Helm 的操作已在进行中
如果特定版本正在进行操作，则会发生此错误。 若要解决此问题，请等待 10 分钟，然后重试该操作。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。