Preparación para la Certificación Microsoft AI-200
Supervisar y diagnosticar aplicaciones de IA en AKS
Correlaciona registros, métricas de recursos, eventos de Kubernetes, estados de Pods, Services, EndpointSlices, ingreso y conectividad integral para diagnosticar cargas de IA.
Tiempo de estudio sugerido: 85 minutos • Nivel intermedio • Reescritura original completa con versión resumida de cada tema, evaluación comentada y laboratorio guiado
Por João Ricardo Dutra••Contenido original completo
1. Observar toda la carga de IA antes de modificarla
Una de inferencia y un worker de enriquecimiento pueden parecer sanos mientras los usuarios sufren lentitud, errores del modelo o recomendaciones obsoletas. El origen puede ser el código, una dependencia, la configuración de Kubernetes, el enrutamiento del Service, la presión de recursos o el clúster. La supervisión reduce el espacio de búsqueda antes de introducir otra variable.
ofrece vistas complementarias. Microsoft Azure Portal incluye Cargas de trabajo, Registros en vivo, Insights, Supervisión, Consola y Diagnosticar y resolver problemas. kubectl expone recursos, registros, eventos, métricas y objetos de red. Una investigación fiable avanza de síntoma a evidencia, hipótesis, prueba controlada, corrección duradera y verificación.
Identifica la ruta afectada y la ventana temporal.
Compara señales de aplicación, Kubernetes e infraestructura.
Usa el portal para delimitar visualmente y kubectl para profundizar.
Modifica código, configuración o manifiestos, no el contenedor activo.
Resumen del tema
Empieza por el síntoma del usuario y correlaciona evidencias del portal y kubectl antes de elegir una corrección reproducible.
2. Elegir registros y métricas que expliquen el comportamiento de la IA
Latencia, rendimiento, 5xx, , profundidad de cola, duración de lotes, reinicios, códigos de salida, CPU y memoria describen capas distintas. Compara uso con y limits: llegar al límite de CPU causa y latencia; la presión de memoria puede terminar y reiniciar el contenedor.
Mapa de señales.
Señal
Pregunta
Acción habitual
Latencia y rendimiento
¿El satisface la demanda?
Inspeccionar dependencias, escalar u optimizar.
Errores y
¿Qué solicitudes fallan?
Correlacionar registros y trazas.
Reinicios y salidas
¿El contenedor es estable?
Ver registros previos, estado y eventos.
CPU y memoria
¿Capacidad o límites restringen?
Redimensionar o escalar réplicas.
Cola o lote
¿Se acumula trabajo?
Ajustar concurrencia y escalado.
Una señal útil vincula el impacto con aplicación, orquestación o capacidad.
Resumen del tema
Supervisa resultado del usuario, aplicación, ciclo del Pod y capacidad juntos; una sola métrica no explica el incidente.
3. Inspeccionar evidencia actual e histórica en Microsoft Azure Portal
En Recursos de Kubernetes, Cargas de trabajo muestra estado, antigüedad, reinicios y detalles de Deployments, Pods, ReplicaSets, StatefulSets, Jobs y CronJobs. Registros en vivo transmite stdout y stderr, permite pausar, buscar y seleccionar el contenedor de un Pod con . Consola abre un terminal interactivo en el navegador.
La pestaña Supervisión resume grupos de nodos y abre gráficos en el explorador de métricas. Insights correlaciona espacios de nombres, controladores, contenedores, registros, eventos, CPU, memoria, red y sistema de archivos. Los datos en directo requieren y acceso a la ; un clúster privado requiere conectividad de red. El historial depende de y Analytics.
Resumen del tema
Usa Cargas de trabajo y datos en directo para el incidente actual y Insights y para historia y análisis entre Pods.
4. Leer registros de contenedor con precisión mediante kubectl
Enumera Pods en el correcto, elige la instancia problemática y sigue registros mientras reproduces la solicitud. -c selecciona el contenedor de la en lugar del . --previous es esencial después de un reinicio porque los registros actuales pueden ocultar el proceso que falló.
Los espacios de nombres separan lógica, acceso y cuotas; las etiquetas seleccionan la aplicación dentro de ese límite. Registra fecha, correlación, modelo y versión, estado y duración de dependencias con campos estructurados. No registres , prompts confidenciales, cadenas de conexión ni credenciales.
Resumen del tema
Selecciona , Pod, contenedor e instancia de ciclo correctos y correlaciona registros con la solicitud que reproduce el error.
5. Comparar consumo con y limits
El portal muestra CPU y memoria por grupo y, en Insights, por nodo, controlador, Pod o contenedor. Métricas en directo añade CPU, memoria, red y sistema de archivos actuales. Con Metrics Server, kubectl top ofrece una instantánea rápida.
kubectl top nodes
kubectl top pods -n ai-workloads
kubectl top pod <pod-name> --containers -n ai-workloads
Una instantánea no es una tendencia. Compara la ventana del error, y limits, réplicas deseadas, capacidad del nodo y evidencia de o falta de memoria. CPU sostenida en el límite exige probar recursos, réplicas, eficiencia del modelo o distribución, no aumentar valores arbitrariamente.
Resumen del tema
Combina el historial del portal y la instantánea de kubectl y compara consumo con , limits, réplicas y objetivos.
6. Crear telemetría de producción útil para investigar
La observabilidad de producción define objetivos de latencia y error, conserva historia útil y alerta antes del impacto general. Registros estructurados e identificadores de correlación conectan ,, modelo, caché, cola y worker. La versión de modelo y aplicación relaciona una regresión con el rollout.
Usa Prometheus administrado y Grafana para métricas temporales y paneles.
Usa Insights y Analytics para salida, inventario e historia consultable.
Configura reglas de recopilación, retención y filtros equilibrando evidencia y coste.
Alerta sobre síntomas y agotamiento y enlaza un runbook.
Protege telemetría con y excluye datos confidenciales.
Resumen del tema
Diseña registros, métricas, alertas, retención y correlación antes del incidente para reconstruir solicitud e implementación.
7. Reconocer estados problemáticos de los Pods
Síntomas comunes.
Estado
Causa probable
Primera evidencia
Imagen, etiqueta, acceso al registro o identidad incorrectos
Eventos y referencia de imagen.
Proceso termina, comando, configuración o dependencia inválidos
Estado, registros previos y eventos.
Pending
Recursos, afinidad, volumen, cuota o regla de programación
Eventos de programación y .
Reinicios frecuentes
Sondeo, memoria, fuga o excepción
Conteo, motivo, registros y métricas.
Running sin Ready
Readiness o dependencia falla
Condiciones, eventos y salud local.
El estado es un síntoma; eventos y runtime revelan la causa.
Resumen del tema
Usa ,, Pending, reinicios y readiness fallida como puntos de partida, no diagnósticos.
8. Describir Pods y examinar eventos de Kubernetes
kubectl describe pod reúne estado, última terminación, sondeos, fuentes de entorno, montajes, programación y eventos. Los eventos muestran fallos de extracción, restricciones, errores de sondeo y acciones de controladores que el registro de la aplicación no explica.
kubectl get pods -n ai-workloads
kubectl describe pod <pod-name> -n ai-workloads
kubectl get events -n ai-workloads --sort-by=.metadata.creationTimestamp
kubectl exec -it <pod-name> -n ai-workloads -- /bin/sh
Comprueba rutas y puertos de readiness y liveness, variables, ConfigMaps, Secrets, recursos, volúmenes del modelo, service account, imagen y eventos recientes. Los eventos caducan, por lo que conviene capturarlos durante el incidente. Diagnosticar y resolver problemas añade detectores de y acciones recomendadas.
Resumen del tema
Usa describe y eventos para vincular estado con sondeos, configuración, volúmenes, programación, imagen, identidad y controladores.
9. Diagnosticar dentro del contenedor sin crear divergencia
Consola o kubectl exec muestra archivos, configuración montada, variables, y locales. El shell existe solo si la imagen lo incluye; de lo contrario usa un flujo aprobado con contenedor efímero o imagen de diagnóstico.
Confirma archivos de modelo y configuración.
Comprueba valores no sensibles y solo la presencia de credenciales.
Llama a localhost de salud e inferencia.
Resuelve y prueba dependencias permitidas.
Sal sin instalar herramientas ni modificar archivos.
Los cambios interactivos desaparecen y crean drift. Corrige fuente, imagen, ConfigMap, asignación de Secret, sondeo, recursos o manifiesto; implementa normalmente y vuelve a probar.
Resumen del tema
Inspecciona el runtime con Consola o exec, pero aplica la corrección permanente en código, configuración, imagen o manifiesto versionado.
10. Validar selectores, puertos y EndpointSlices del Service
Un Pod sano no hace accesible la . El Service selecciona Pods por etiqueta y el plano de control registra listos en EndpointSlices. Una lista vacía suele indicar incompatibilidad selector-etiqueta, Pods no listos o espacio incorrecto. Una slice poblada muestra , puertos y condiciones utilizadas para enrutar.
kubectl get service -n ai-workloads
kubectl describe service inference-api -n ai-workloads
kubectl get pods --show-labels -n ai-workloads
kubectl get endpointslices -l kubernetes.io/service-name=inference-api -n ai-workloads
Compara selector del Service con etiquetas del Pod, port con targetPort, targetPort con el listener, protocolo, espacio y direcciones. El objeto heredado está en desuso en Kubernetes actual; prefiere EndpointSlices.
Resumen del tema
Demuestra la cadena selector-etiqueta-puerto y confirma direcciones listas en EndpointSlices antes de investigar la exposición.
11. Rastrear ,, e ingreso
sirve solo dentro del clúster. asigna un puerto en cada nodo y suele ser una pieza intermedia. LoadBalancer crea una ruta mediante el y una dirección externa. Ingreso añade reglas de host y ruta mediante un controlador y Services de .
En Microsoft Azure Portal, Servicios e ingresos muestra tipo, , external , puertos, selectores, , hosts, rutas y direcciones. Valida cada salto: listener, Pod, EndpointSlice, Service, ingreso o , / cuando corresponda y cliente.
El éxito integral depende de todos los contratos de enrutamiento.
Resumen del tema
Elige la exposición deliberadamente y prueba puerto del contenedor, Service, EndpointSlice e ingreso o .
12. Probar conectividad interna y externa con seguridad
kubectl port-forward crea un túnel local temporal hacia un Pod seleccionado mediante un Service. Aísla la aplicación y el Service antes del ingreso o la publicación. La sesión termina cuando el Pod elegido finaliza y debe reiniciarse; es diagnóstico, no exposición de producción.
kubectl port-forward service/inference-api 8080:80 -n ai-workloads
curl -i http://localhost:8080/api/inference
kubectl get service inference-api -n ai-workloads
kubectl get ingress -n ai-workloads
Reenvía el puerto y llama a salud o inferencia localmente.
Correlaciona registros, métricas y eventos.
Confirma external del Service o dirección de ingreso.
Prueba desde un cliente representativo con hostname, ruta, y autenticación.
Repite tras corregir y observa error y latencia.
Resumen del tema
Usa port-forward para aislar la ruta interna y después valida externamente el o ingreso real.
13. Laboratorio guiado: diagnosticar una aplicación en
El ejercicio de unos 30 minutos implementa una en contenedor con y y usa kubectl para examinar estado, registros y eventos. El alumno corrige un selector incompatible, una variable de entorno ausente y una ruta de readiness inválida, valida conectividad y elimina recursos.
Descarga el proyecto e identifica recursos intencionadamente defectuosos.
Implementa registro, clúster, imagen y manifiestos.
Reproduce cada síntoma y recopila evidencia antes de editar.
Usa kubectl edit o el manifiesto fuente para corregir selector, configuración y sondeo.
Prueba la , confirma Pods y sanos y limpia recursos facturables.
Requisitos: suscripción de con permisos, , Python 3.12 o posterior, la CLI de actual y kubectl. ACR Tasks puede requerir pago por uso porque los créditos gratuitos quizá no cubran las ejecuciones.
Resumen del tema
El laboratorio practica reparación basada en evidencia de selectores, entorno y readiness manteniendo una implementación reproducible.
14. Evaluación, runbook de producción y referencias
Decisiones de la evaluación.
Escenario
Acción correcta
Motivo
500 y latencia al reproducir
kubectl -f en el Pod concreto
Transmite el fallo actual.
Describir el Pod y ver estado y eventos
Muestra terminación y orquestación.
Pods sanos sin
Describir el Service
Expone selector y .
Prueba antes de publicar
kubectl port-forward service/...
Crea una ruta local al Service.
CPU sostenida en el límite
Ajustar recursos o escalar réplicas
Restaura capacidad medida.
Registra síntoma, alcance, inicio y objetivo.
Captura versión, registros, métricas, estado, eventos, Services y EndpointSlices.
Prueba la hipótesis mínima y registra el resultado.
Aplica cambio versionado con .
Verifica tráfico y señales originales después de recuperar.
