Solución de errores al implementar extensiones de clúster de AKS
En este artículo se describe cómo solucionar errores que se producen al implementar extensiones de clúster para Microsoft Azure Kubernetes Service (AKS).
Errores de creación de extensiones
Error: No se puede obtener una respuesta del agente a tiempo
Este error se produce si los servicios de Azure no reciben una respuesta del agente de extensión de clúster. Esta situación puede producirse porque el clúster de AKS no puede establecer una conexión con Azure.
Causa 1: El agente de extensión de clúster y los pods del administrador no se inicializan
El agente de extensión de clúster y el administrador son componentes del sistema cruciales que son responsables de administrar el ciclo de vida de las aplicaciones de Kubernetes. Es posible que se produzca un error en la inicialización del agente de extensión de clúster y los pods del administrador debido a los siguientes problemas:
- Limitaciones de recursos
- Restricciones de directiva
- Taints de nodo, como
NoSchedule
Solución 1: Asegúrese de que el agente de extensión de clúster y los pods del administrador funcionan correctamente
Para resolver este problema, asegúrese de que el agente de extensión de clúster y los pods del administrador estén correctamente programados y puedan iniciarse. Si los pods están bloqueados en un estado no leído, compruebe la descripción del pod ejecutando el siguiente kubectl describe pod comando para obtener más detalles sobre los problemas subyacentes (por ejemplo, taints que impiden la programación, la memoria insuficiente o las restricciones de directiva):
kubectl describe pod -n kube-system extension-operator-{id}
Este es un ejemplo de salida de comando:
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
Para los clústeres conectados a ARC, ejecute el siguiente comando para comprobar la descripción del pod:
kubectl describe pod -n azure-arc extension-manager-{id}
Este es un ejemplo de salida de comando:
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
Cuando el agente de extensión de clúster y los pods de administrador están operativos y en buen estado, establecen la comunicación con los servicios de Azure para instalar y administrar aplicaciones de Kubernetes.
Causa 2: un problema afecta al bloque de salida o al firewall
Si el agente de extensión de clúster y los pods del administrador están en buen estado y se encuentra con el error "No se puede obtener una respuesta del agente en el tiempo", es probable que exista un problema de firewall o bloque de salida. Este problema podría impedir que el agente de extensión de clúster y los pods de administrador se comuniquen con Azure.
Solución 2: Asegúrese de que se cumplen los requisitos previos de red
Para resolver este problema, asegúrese de seguir los requisitos previos de red que se describen en Reglas de FQDN y red de salida para clústeres de Azure Kubernetes Service (AKS).
Causa 3: El tráfico no está autorizado
El agente de extensión intenta llamar incorrectamente a los puntos de conexión de servicio del <region>.dp.kubernetesconfiguration.azure.com plano de datos. Este error genera una entrada "Errorcode: 403, Message This traffic is not authorized" (Código de error: 403, Mensaje: Este tráfico no está autorizado) en los registros del pod de extension-agent.
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" }
Este error se produce si existe un privateLinkScope preexistente en el plano de datos de una extensión para Kubernetes habilitado para Azure Arc y la red virtual (o servidor DNS privado) se comparte entre Kubernetes habilitado para Azure Arc y el clúster administrado por AKS. Esta configuración de red hace que el tráfico saliente de AKS desde el plano de datos de extensión también se enrute a través de la misma dirección IP privada en lugar de a través de una dirección IP pública.
Ejecute el siguiente comando nslookup en el clúster de AKS para recuperar la dirección IP privada específica a la que se resuelve el punto de conexión del plano de datos:
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
Al buscar la dirección IP privada en Azure Portal, los resultados de búsqueda apuntan al recurso exacto: red virtual, zona DNS privada, servidor DNS privado, etc. Este recurso tiene un punto de conexión privado configurado para el plano de datos de extensión para Kubernetes habilitado para Azure Arc.
Solución 3.1: (recomendado) Creación de redes virtuales independientes
Para resolver este problema, se recomienda crear redes virtuales independientes para los procesos de Kubernetes y AKS habilitados para Azure Arc.
Solución 3.2: Creación de una invalidación de CoreDNS
Si la solución recomendada no es posible en su situación, cree una invalidación de CoreDNS para que el punto de conexión del plano de datos de extensión pase por la red pública. Para más información sobre cómo personalizar CoreDNS, consulte la sección "Complemento hosts" de "Personalización de CoreDNS con Azure Kubernetes Service".
Para crear una invalidación de CoreDNS, siga estos pasos:
Para buscar la dirección IP pública del punto de conexión del plano de datos de extensión, ejecute el
nslookupcomando . Asegúrese de cambiar la región (por ejemplo,eastus2euap) en función de la ubicación del clúster de AKS: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.netCree una copia de seguridad de la configuración de coreDNS existente:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlInvalide la asignación del punto de conexión del plano de datos regional (por ejemplo,
eastus2euap) a la dirección IP pública. Para ello, cree un archivo YAML denominado corednsms.yaml y, a continuación, copie la siguiente configuración de ejemplo en el nuevo archivo. (Asegúrese de actualizar la dirección y el nombre de host mediante los valores de su entorno).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 }Para crear configMap, ejecute el
kubectl applycomando y especifique el nombre del archivo de manifiesto DE YAML:kubectl apply -f corednsms.yamlPara volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, ejecute el comando kubectl rollout restart :
kubectl -n kube-system rollout restart deployment corednsVuelva a ejecutar el
nslookupcomando para asegurarse de que el punto de conexión del plano de datos se resuelve en la dirección IP pública proporcionada: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
Los registros del pod del agente de extensión ya no deben registrar las entradas de error "Errorcode: 403, Message This traffic is not authorized" (Código de error: 403, mensaje Este tráfico no está autorizado). En su lugar, los registros deben contener códigos de respuesta "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" }
Error: Los pods de extensión no se pueden programar si todos los grupos de nodos del clúster son "CriticalAddonsOnly" entendido
Cuando se produce este error, se registra la siguiente entrada en el registro del agente de extensión:
Error de pod de extensión: 0/2 nodos están disponibles: 2 nodos tenían taint sinler {CriticalAddonsOnly: true}. adelantamiento: 0/2 nodos están disponibles: 2 El adelantamiento no es útil para la programación.
Causa
Este error se produce cuando intenta habilitar extensiones (como Distributed Application Runtime (DAPR)) en un clúster de AKS que tiene CriticalAddonsOnly grupos de nodos entendados. En esta situación, los pods de extensión no están programados en ningún nodo porque no existe tolerancia para estos taints.
Para ver la situación de error, examine los pods de extensión para comprobar que están bloqueados en un estado pendiente:
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Describa los pods para ver que no se pueden programar debido a un taint no compatible:
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.
Nota:
Se recomienda no instalar extensiones en
CriticalAddOnsOnlygrupos de nodos de estado, a menos que esto sea necesario para las cargas de trabajo de la aplicación.Se recomienda no usar un
CriticalAddOnsOnlytaint en clústeres de grupo de nodos únicos. Si usa ese taint en un clúster que tiene solo un grupo de nodos, no puede programar pods de aplicación en el clúster. Asegúrese de que al menos un grupo de nodos del clúster no tenga este valor taint. Para más información sobre cuándo se debe usar laCriticalAddonsOnlyanotación, consulte Administración de grupos de nodos del sistema en Azure Kubernetes Service (AKS).
Solución 1: Agregar un grupo de nodos al clúster
Para resolver este problema, agregue un grupo de nodos más que no tenga un CriticalAddonsOnly taint. Esta acción hace que los pods de extensión se programe en el nuevo grupo de nodos.
Solución 2: Quitar el taint "CriticalAddonsOnly"
Si es posible y práctico, puede quitar el CriticalAddonsOnly taint para instalar la extensión en el clúster.
Errores de Helm
Es posible que encuentre cualquiera de los siguientes errores relacionados con Helm:
- Se agota el tiempo de espera para la preparación de los recursos
- No se puede descargar el gráfico Helm desde la dirección URL del repositorio
- Error en la representación del gráfico Helm con los valores especificados
- El recurso ya existe en el clúster
- La operación ya está en curso para Helm
Error: se agota el tiempo de espera para la preparación de los recursos
Se produce un error en la instalación de una aplicación de Kubernetes y se muestran los siguientes mensajes de error:
error de trabajo: BackoffLimitExceeded
Se agota el tiempo de espera para que el recurso llegue a un estado listo o completado.
Causa
Este problema tiene las siguientes causas comunes:
Restricciones de recursos: la memoria insuficiente o los recursos de CPU dentro del clúster pueden impedir la inicialización correcta de pods, trabajos u otros recursos de Kubernetes. Finalmente, esta situación hace que la instalación agote el tiempo de espera. Las restricciones de directiva o los taints de nodo (como
NoSchedule) también pueden bloquear la inicialización de recursos.Errores de coincidencia de arquitectura: intentar programar una aplicación basada en Linux en un nodo basado en Windows (o viceversa) puede provocar errores en la inicialización de recursos de Kubernetes.
Valores de configuración incorrectos: los valores de configuración incorrectos pueden impedir que los pods se inicien.
Solución
Para solucionar este problema, siga estos pasos:
Comprobar recursos: asegúrese de que el clúster de Kubernetes tiene suficientes recursos y de que la programación de pods está permitida en los nodos (debe tener en cuenta los valores taint). Compruebe que los recursos de memoria y CPU cumplen los requisitos.
Inspeccionar eventos: compruebe los eventos dentro del espacio de nombres de Kubernetes para identificar posibles problemas que podrían impedir que los pods, los trabajos u otros recursos de Kubernetes lleguen a un estado listo.
Compruebe los gráficos y configuraciones de Helm: muchas aplicaciones de Kubernetes usan gráficos de Helm para implementar recursos en el clúster. Algunas aplicaciones pueden requerir la entrada del usuario a través de las opciones de configuración. Asegúrese de que todos los valores de configuración proporcionados sean precisos y cumplan los requisitos de instalación.
Error: No se puede descargar el gráfico de Helm desde la dirección URL del repositorio
Este error se debe a problemas de conectividad que se producen entre el clúster y el firewall además de problemas de bloqueo de salida. Para resolver este problema, consulte Reglas de red de salida y FQDN para clústeres de Azure Kubernetes Service (AKS).
Error: Error en la representación del gráfico de Helm con valores especificados
Este error se produce si las aplicaciones de Kubernetes dependen de gráficos de Helm para implementar recursos en el clúster de Kubernetes. Estas aplicaciones pueden requerir la entrada del usuario que se proporciona a través de las opciones de configuración que se pasan como valores de Helm durante la instalación. Si falta alguna de estas opciones de configuración cruciales o no es correcta, es posible que el gráfico de Helm no se represente.
Para resolver este problema, compruebe la documentación de la extensión o de la aplicación para determinar si omitió valores obligatorios o proporcionó valores incorrectos durante la instalación de la aplicación. Estas instrucciones pueden ayudarle a corregir problemas de representación de gráficos de Helm causados por valores de configuración que faltan o son inexactos.
Error: El recurso ya existe en el clúster
Este error se produce si existe un conflicto entre los recursos de Kubernetes dentro del clúster y los recursos de Kubernetes que la aplicación está intentando instalar. El mensaje de error normalmente especifica el nombre del recurso en conflicto.
Si el recurso en conflicto es esencial y no se puede reemplazar, es posible que no pueda instalar la aplicación. Si el recurso no es crítico y se puede quitar, elimine el recurso en conflicto y vuelva a intentar la instalación.
Error: La operación ya está en curso para Helm
Este error se produce si ya hay una operación en curso para una versión determinada. Para resolver este problema, espere 10 minutos y vuelva a intentar la operación.
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.