Planear una implementación de Container Apps en Kubernetes habilitado para Azure Arc

Consulta este artículo antes de instalar la extensión de Container Apps en un clúster de producción. Container Apps en Azure Arc utiliza los servicios de capacidad y de plataforma proporcionados por su clúster de Kubernetes. Las decisiones sobre nodos, balanceo de carga, DNS, conectividad saliente, almacenamiento, identidad, registro y actualizaciones afectan la disponibilidad de las aplicaciones.

Utiliza las secciones de este artículo para identificar los requisitos de despliegue y validar los prerrequisitos antes de la instalación.

Alcance de planificación

Container Apps en Azure Arc se extiende a recursos de Azure, un clúster de Kubernetes existente y aplicaciones implementadas. Planifica para las siguientes áreas:

Topología soportada y matriz de versiones

Utiliza la última versión de parche de Kubernetes soportada por proveedores que también soporta Kubernetes habilitado para Azure Arc. La documentación de Container Apps no publica un intervalo de versiones de Kubernetes independiente para cada distribución. Valida la distribución exacta y la versión de Kubernetes con soporte de Microsoft antes de una instalación o actualización en producción.

La siguiente matriz registra el soporte de distribución publicado actualmente. Vuelva a validarlo con respecto a las extensiones disponibles para clústeres de Kubernetes habilitados para Azure Arc y las limitaciones de Azure Container Apps en Azure Arc antes de cada instalación.

La extensión no es compatible con nodos de Windows ni en clústeres Arm64. El marco de extensión Arc requiere al menos un nodo adecuado linux/amd64 , pero un despliegue en producción requiere suficientes nodos adecuados para la extensión, cargas de trabajo, actualizaciones y fallos.

Solo una instalación KEDA soportada puede ejecutarse en el clúster. Determina si KEDA se instalará mediante la extensión Container Apps o si ya existe en el clúster. Si KEDA ya existe, deténgase y confirme la configuración de coexistencia admitida antes de continuar. No elimines la instalación existente del KEDA ni apliques configuraciones de extensiones no documentadas porque otras cargas de trabajo podrían depender de ello.

Requisitos de capacidad

Capacidad planificada para:

• Los componentes fijos y por nodo de la extensión Aplicaciones del Contenedor listados en Recursos creados por la extensión Aplicaciones del Contenedor.
• El número máximo previsto de réplicas de cada aplicación contenedora.
• Ejecuciones simultáneas de tareas y ráfagas de reintentos.
• Sidecars Dapr y sidecars de aplicación.
• Cargas de trabajo del sistema Kubernetes y otros inquilinos de clúster.
• Actualizaciones de nodos y extensiones progresivas.
• Al menos un fallo de nodo en un despliegue altamente disponible.

Establecer el conteo máximo de réplicas de una aplicación no reserva capacidad de clúster.

Capacidad mínima de instalación

No hay un mínimo universal de producción porque la colocación de extensiones, componentes habilitados, número de nodos, cargas de trabajo de demonios, instalación de KEDA, Log Analytics, uso de DAPR y solicitudes de carga de trabajo varían. Utiliza las solicitudes de componentes de extensión publicadas como referencia y mide los recursos asignables, no totales, del nodo. El tamaño de un grupo de evaluación no es una recomendación de tamaño de producción.

Antes de la instalación, registra:

• CPU y memoria asignables en nodos elegibles linux/amd64 .
• Número de nodos y ubicación por dominios de error.
• Libera capacidad de IP para pods y servicios.
• Sistema actual, solicitudes y límites de inquilinos.
• Capacidad no disponible debido a contaminaciones, afinidades, cuotas o presupuestos de interrupción.

Estimar la capacidad de carga de trabajo

Para cada aplicación, calcula:

peak capacity = maximum replicas x (application requests + sidecar requests)

Agregar capacidad máxima de trabajos simultáneos, capacidad de extensión, reserva del sistema, capacidad adicional para actualizaciones y reserva para fallos. Asegúrate de que las etiquetas de nodos, las contaminaciones, las reglas de afinidad y la fragmentación de recursos no hagan que la capacidad nominalmente libre no sea programable.

Valida el plan programando cargas de trabajo representativas y simulando un drenaje de nodo. Confirma que los pods de la extensión y las réplicas de carga de trabajo necesarias permanezcan listas.

Requisitos de red

Las aplicaciones contenedor en Azure Arc requieren varias rutas de red distintas:

Utiliza los requisitos de red Kubernetes habilitados para Azure Arc como lista de endpoints canónica. No copies la lista de puntos de conexión en un conjunto de reglas de firewall sin seleccionar la nube de Azure correcta y las características de Arc habilitadas. Prueba todos los nombres de dominio totalmente cualificados (FQDN) requeridos de la red del clúster. Los requisitos de Arc establecen que los endpoints HTTPS utilizan certificados oficialmente firmados y verificables. Confirmar el comportamiento de proxy y de inspección TLS en un clúster no productivo; la intercepción no soportada o un certificado de reemplazo no confiable pueden impedir que agentes y componentes de extensión se conecten.

La implementación seleccionada LoadBalancer determina el conjunto de direcciones, las sondas de salud, el enrutamiento y la capacidad requerida. Si un balanceador de carga personalizado requiere una dirección reservada, reserva primero la dirección y pásala por la configuración de extensión loadBalancerIp durante la instalación. Los puertos de la sonda de salud y los rangos de fuente son específicos de la implementación; obténlos del balanceador de carga seleccionado en lugar de asumir los valores predeterminados de Azure Load Balancer.

El clúster de Kubernetes subyacente habilitado para Arc controla las restricciones de red del entorno conectado. Si una dependencia de la aplicación utiliza un punto de conexión privado, comprueba desde un pod de la aplicación que el clúster puede resolver su nombre DNS y enrutar hacia su IP privada. Las aplicaciones que necesiten información IP del cliente deben validar las cabeceras de reenvío producidas por el balanceador de carga y la cadena proxy seleccionadas y definir qué proxies son de confianza.

Validación de redes

1. Despliega un servicio de prueba Kubernetes LoadBalancer y confirma que recibe una dirección accesible desde cada red cliente prevista.
2. Desde un nodo de clúster o pod de diagnóstico elegible, resuelve y conéctate a todos los endpoints y dependencias de carga de trabajo de Azure Arc necesarios.
3. Confirma que el proxy permite el tráfico HTTPS y WebSocket requerido y que no sustituye los certificados por un emisor no confiable.
4. Confirme que el DNS del clúster, el tráfico entre pods, los servicios, los webhooks de admisión y las sondas de estado del balanceador de carga funcionan con las políticas de red previstas.
5. Tras la instalación de la extensión, confirma que el servicio de entrada recibe la IP prevista y es accesible antes de crear los registros DNS de producción.

Requisitos de DNS

Tras la instalación de la extensión, despliega una aplicación de prueba y recupera su FQDN generado. Comprueba que el FQDN se resuelve y llega al servicio de entrada de la extensión desde todas las redes de clientes previstas. El nombre de entorno conectado forma parte del dominio de aplicación generado, así que elíjalo deliberadamente.

Para aplicaciones internas, utiliza DNS de horizonte dividido cuando los clientes internos y externos requieren respuestas diferentes. Identifica la zona DNS autorizada, registra el tiempo de vida y los requisitos de recuperación. Determinar si las aplicaciones utilizan el dominio generado, dominios personalizados o ambos, y planificar la emisión y renovación de certificados antes del despliegue.

Valida el DNS y el servicio de entrada desde cada red de clientes prevista:

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

El FQDN de la aplicación debe resolverse a la IP de ingreso y devolver la respuesta esperada de la aplicación. Elimina encabezados de autorización, cookies y cadenas de consulta sensibles antes de compartir la salida verbosa.

Identidad, secretos y registros

Las identidades gestionadas no están soportadas para aplicaciones contenedor en Azure Arc. Extraer imágenes de Azure Container Registry usando Managed Identity tampoco está soportado.

Para acceder a los recursos de Azure, utiliza un registro de aplicación dedicado y un principal de servicio solo cuando el servicio destino lo permita. Conceda únicamente los roles del plano de datos necesarios con el alcance más limitado que resulte práctico. Mantén el ID de inquilino y el ID del cliente separados de la credencial, usa un certificado cuando la aplicación y el servicio objetivo lo soporten, y planifica la caducidad y rotación de credenciales. No reutilices la identidad de clúster conectado de Arc ni la identidad de administrador de clúster para acceder a aplicaciones.

Para registros privados, utiliza una credencial de ámbito de registro con acceso de solo extracción cuando el registro lo admita. Evita las credenciales de administrador ACR para cargas de trabajo en producción. Guarda las credenciales del registro y de la aplicación como secretos de Container Apps y haz referencia a ellas por su nombre desde la configuración de la aplicación.

Los secretos de Container Apps se limitan al ámbito de la aplicación, y al cambiar un secreto no se actualizan automáticamente las revisiones existentes. Trata tanto el acceso al plano de control de Azure como el acceso privilegiado a Kubernetes como límites de seguridad. Restringir el acceso a los espacios de nombres de las extensiones y de las aplicaciones de acuerdo con los requisitos de seguridad de Kubernetes para el despliegue.

Utiliza esta secuencia de rotación:

1. Crea una segunda credencial válida en el proveedor de identidad o en el registro.
2. Actualiza el secreto de Container Apps e implementa o reinicia la revisión afectada según sea necesario.
3. Verifica las extracciones de imágenes y la autenticación de la aplicación con la nueva credencial.
4. Revoca la credencial antigua.
5. Confirme que ninguna revisión ni ningún trabajo activo siga haciendo referencia al valor anterior.

Nunca coloques valores secretos en el historial de comandos, control de versiones, paquetes de diagnóstico, descripciones de pods o registros de aplicaciones. Limita quién puede leer configuraciones protegidas por extensiones y secretos de Kubernetes.

Storage

Planifica el almacenamiento según la persistencia requerida por la carga de trabajo:

Las limitaciones de Container Apps en Arc documentan actualmente Azure Files SMB y requieren el controlador CSI de SMB. No des por hecho que un tipo de volumen admitido por Azure-hosted Container Apps también lo esté en Arc. Utiliza los comandos de instalación de SMB a los que se enlaza desde Azure Container Apps en Azure Arc en lugar de mantener aquí otra copia.

Trata las credenciales de cuenta de almacenamiento usadas para un montaje como secretos. No se soportan identidades gestionadas para Aplicaciones de Contenedor en Arc. Prueba las opciones de montaje seleccionadas, permisos de archivo, acceso concurrente, comportamiento de fallos y rotación de credenciales con las versiones exactas de drivers CSI y servicios de almacenamiento usadas en producción.

Planifica la copia de seguridad persistente de datos, las pruebas de restauración, la retención y la recuperación ante desastres. Comprueba cómo las revisiones y las tareas notifican los errores de montaje, e incluye los eventos de los pods y los registros de los controladores CSI en el procedimiento de diagnóstico. Linux es el único nodo operativo compatible con la extensión.

Observabilidad del plan

La integración de Log Analytics es opcional. Si planeas usarla, configúrala cuando instales la extensión porque no puedes añadirla a esa instancia más adelante.

Cuando configuras Log Analytics, puedes encontrar registros de aplicaciones en ContainerAppConsoleLogs_CL. El tutorial de Crear una aplicación contenedor en Azure Arc demuestra TimeGenerated, ContainerAppName_s, y Log_s; inspecciona la tabla activa antes de crear consultas o alertas. Prevea entre 10 y 15 minutos para validar la ingestión inicial.

Planifica el acceso al espacio de trabajo, la retención, las alertas, la exportación y el coste de ingestión. Revisa el registro de la aplicación para identificar credenciales, datos personales y URLs sensibles antes de habilitar la recopilación.

Si no configuras Log Analytics, o durante un incidente de ingestión, usa los registros de Kubernetes:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

Los componentes del sistema escriben los registros en la salida estándar. Por defecto, la telemetría de componentes del sistema se envía a Microsoft mientras que los registros de aplicaciones no se envían a menos que configures Log Analytics. La configuración logProcessor.enabled=false desactiva el procesamiento y el reenvío de registros al espacio de trabajo y puede aumentar la evidencia diagnóstica que el soporte te pide que recopiles manualmente.

Antes de la producción, prueba un mensaje único de registro de aplicación de principio a fin, crea alertas para la salud de las extensiones y fallos de la aplicación, y confirma que tanto los diagnósticos de Azure como Kubernetes son accesibles.

Actualización, copia de seguridad y recuperación

Selecciona y documenta una política de liberación de extensiones y de actualización. El tutorial de configuración de Container Apps utiliza el tren de lanzamiento stable con actualizaciones automáticas de versiones menores. Las extensiones del clúster de Azure Arc pueden seguir un tren de lanzamientos con actualizaciones automáticas o fijarse y actualizarse manualmente. Revisa las notas de la versión de la extensión de Container Apps antes de cambiar de versión, y proporciona capacidad adicional, versiones compatibles de Kubernetes, ventanas de mantenimiento y validación de aplicaciones.

Antes de una extensión o actualización de Kubernetes:

1. Confirma que los estados de aprovisionamiento del clúster conectado y de la extensión son Succeeded.
2. Confirma que la combinación de Kubernetes y extensión objetivo es compatible.
3. Revisa las notas de lanzamiento y la configuración actual, incluyendo el tren de lanzamientos, la configuración de actualización automática, la instalación de KEDA, los espacios de nombres, Log Analytics y loadBalancerIp.
4. Verificar la capacidad sobrante para la sustitución progresiva y confirmar que los presupuestos de interrupción permiten el progreso.
5. Verifica la conectividad del registro de imágenes y las políticas de admisión para las imágenes de destino.
6. Haz una copia de seguridad de la configuración del código fuente de la aplicación y de todos los datos persistentes de la aplicación.
7. Ejecute pruebas de funcionamiento de la aplicación, el ingreso, el escalado, los trabajos, el almacenamiento y el registro antes y después del cambio.

No trates la copia de seguridad del espacio de nombres de Kubernetes como una copia de seguridad de los recursos de Azure. El clúster conectado, la extensión, la ubicación personalizada, el entorno conectado, las aplicaciones contenedor y los trabajos están representados en Azure Resource Manager y dependen de los recursos dentro del clúster. Haz una copia de seguridad de la configuración declarativa de la aplicación por separado. No restaures manualmente despliegues gestionados por extensiones, recursos personalizados o secretos sobre una extensión recién instalada a menos que el soporte de Microsoft proporcione ese procedimiento de recuperación.

Una degradación o retroceso de extensiones no es un mecanismo general de recuperación documentado para Aplicaciones Contenedor en Arc. No cambies el tren de lanzamientos, no fijes una versión antigua ni modifiques cargas de trabajo gestionadas por extensiones como respuesta a incidentes sin confirmar una ruta compatible con soporte de Microsoft.

Desarrolla y prueba un runbook de recuperación que tenga en cuenta la infraestructura Kubernetes, redes, DNS, balanceo de carga, almacenamiento, agentes de Azure Arc, la extensión Contenedores, ubicación personalizada, entorno conectado, configuración de aplicaciones, credenciales y datos persistentes de la aplicación. Valide el ingreso, las revisiones, el escalado, los trabajos, el almacenamiento y los registros tras la recuperación. Utiliza procedimientos de recuperación soportados por la topología Kubernetes y los productos de respaldo en el despliegue.

Planifica la desconexión de Azure. Los agentes de arco requieren conectividad para descubrir cambios en la extensión y propagar el estado deseado. Los ajustes protegidos para un recurso de extensión recién creado se mantienen hasta 48 horas; si el clúster permanece desconectado durante ese periodo, la extensión puede moverse de Pending a Failed. Prueba el comportamiento de la carga de trabajo durante la pérdida de conectividad con Azure en lugar de asumir una garantía de continuidad.

Contenido relacionado

• Azure Container Apps en Azure Arc
• Configurar un cluster Kubernetes habilitado para Azure Arc para ejecutar Azure Container Apps
• Creación de una aplicación de contenedor en Azure Arc
• Solucionar problemas de Azure Container Apps en Kubernetes habilitado para Azure Arc
• Requisitos de red para Kubernetes habilitados con Azure Arc
• Ubicaciones personalizadas en Kubernetes habilitado con Azure Arc
• Extensiones de clúster en Kubernetes habilitado para Azure Arc