Notas de la versión 2403 de Azure Stack Edge
SE APLICA A: 
Azure Stack Edge Pro: GPUAzure Stack Edge Pro 2Azure Stack Edge Pro RAzure Stack Edge Mini R
En las notas de la versión siguientes se identifican las incidencias críticas abiertas y las incidencias resueltas de la versión 2403 de los dispositivos Azure Stack Edge. Las características y las incidencias que corresponden a un modelo específico de Azure Stack Edge se indican siempre que proceda.
Las notas de la versión se actualizan continuamente y se van agregando a medida que se descubren problemas críticos que requieren una solución alternativa. Antes de implementar el dispositivo, revise detenidamente la información que encontrará en las notas de la versión.
Este artículo se aplica a la versión Azure Stack Edge 2403, correspondiente al número de versión de software 3.2.2642.2487.
Advertencia
En esta versión, debe actualizar la versión de núcleo de paquetes a AP5GC 2308 antes de actualizar a Azure Stack Edge 2403. Para obtener pasos detallados, consulte Notas de la versión de Azure Private 5G Core 2308. Si actualiza a Azure Stack Edge 2403 antes de actualizar a Packet Core 2308.0.1, experimentará una interrupción total del sistema. En este caso, debe eliminar y volver a crear el clúster de Azure Kubernetes Service en el dispositivo Azure Stack Edge. Cada vez que cambie el perfil de carga de trabajo de Kubernetes, se le pedirá que actualice Kubernetes. Continúe y aplique la actualización.
Rutas de acceso de actualización admitidas
Para aplicar la actualización 2403, el dispositivo debe ejecutar la versión 2303 o posterior.
Si no ejecuta la versión mínima necesaria, verá este error:
No se puede instalar el paquete de actualización porque no se cumplen sus dependencias.
Puede actualizar a 2303 desde la versión 2207 o posterior y, a continuación, actualizar a 2403.
Puede actualizar a la versión más reciente mediante las siguientes rutas de acceso de actualización:
| Versión actual del software de Azure Stack Edge y Kubernetes | Actualización al software de Azure Stack Edge y Kubernetes | Actualización deseada a la versión 2403 |
|---|---|---|
| 2207 | 2303 | 2403 |
| 2209 | 2303 | 2403 |
| 2210 | 2303 | 2403 |
| 2301 | 2303 | 2403 |
| 2303 | Directamente a | 2403 |
Novedades
La versión 2403 tiene las siguientes características y mejoras nuevas:
- Compatibilidad en desuso con la telemetría del servicio Azure Kubernetes en Azure Stack Edge.
- Compatibilidad con etiquetas de zona para clústeres de Kubernetes de dos nodos.
- Administración de máquinas virtuales de Hyper-V, supervisión del uso de memoria en el host de Azure Stack Edge.
Problemas corregidos en esta versión
| No. | Característica | Problema |
|---|---|---|
| 1. | Clustering | El arranque en frío de dos nodos del servidor hace que los recursos del clúster de máquinas virtuales de alta disponibilidad aparezcan como sin conexión. Se ha cambiado ColdStartSetting a AlwaysStart. |
| 2. | Compatibilidad con imágenes de Marketplace | Se ha corregido un error que permitía la imagen de Windows Marketplace en Azure Stack Edge A y TMA. |
| 3. | Conectividad de red | Se corrigió la marca de vínculo de NIC de máquina virtual después de apagar o encender el host de Azure Stack Edge, lo que puede provocar que la máquina virtual pierda su dirección IP de DHCP. |
| 4. | Conectividad de red | Debido a las configuraciones de ARP de proxy en algunos entornos de cliente, la Dirección IP en uso devuelve falsos positivos aunque ningún punto de conexión de la red use la dirección IP. La corrección omite la Dirección IP en usobasada en ARP de máquina virtual. Compruebe si la dirección IP se asigna desde una red interna administrada por Azure Stack Edge. |
| 5. | Conectividad de red | La operación de cambio de NIC de máquina virtual agota el tiempo de espera después de 3 horas, lo que bloquea otras operaciones de actualización de máquina virtual. En los clústeres de Microsoft Kubernetes, los pods dependientes del volumen persistente (PV) se bloquean. El problema se produce cuando se transfieren varias NIC dentro de una máquina virtual desde una red virtual VLAN a una red virtual que no es VLAN. Después de la corrección, la operación de cambio de NIC de máquina virtual agota el tiempo de espera rápidamente y la actualización de la máquina virtual no se bloqueará. |
| 6. | Kubernetes | Mejoras generales de resistencia de Kubernetes de dos nodos, como aumento de memoria para el plano de control para el clúster de cargas de trabajo de AKS, aumento de los límites para etcd, soporte multi-réplica e implementación de anti-afinidad estricta para pods DNS principales y pods del controlador Azure Disk CSI y mejora de los tiempos de conmutación por error de las máquinas virtuales. |
| 7. | Diagnóstico y actualización de proceso | Correcciones de resistencia |
| 8. | Seguridad | Correcciones de seguridad de STIG para el sistema operativo invitado de Mariner para Azure Kubernetes Service en Azure Stack Edge. |
| 9. | Operaciones de máquina virtual | En un clúster de Azure Stack Edge que implementa una carga de trabajo AP5GC, después de una prueba de ciclo de energía del host, cuando el host devuelve un error transitorio sobre la configuración del grupo de CPU, AzSHostAgent se bloquearía. Esto provocó un error de operaciones de máquina virtual. La corrección ha hecho que AzSHostAgent sea resistente a un error transitorio del grupo de CPU. |
Problemas conocidos en esta versión
| No. | Característica | Problema | Soluciones alternativas o comentarios |
|---|---|---|---|
| 1. | Explorador de Azure Storage | Es posible que el certificado del punto de conexión de Blob Storage generado automáticamente por el dispositivo de Azure Stack Edge no funcione correctamente con el Explorador de Azure Storage. | Reemplace el certificado de punto de conexión de Blob Storage. Para conocer los pasos detallados, consulte Aportación de sus propios certificados. |
| 2. | Conectividad de red | En un clúster de Azure Stack Edge Pro 2 de dos nodos con un conmutador virtual en equipo para el puerto 1 y el puerto 2, si un vínculo de puerto 1 o puerto 2 está inactivo, puede tardar hasta 5 segundos en reanudar la conectividad de red en el puerto activo restante. Si un clúster de Kubernetes usa este conmutador virtual en equipo para el tráfico de administración, la comunicación de pods puede interrumpirse hasta por 5 segundos. | |
| 3. | Máquina virtual | Después de apagar el host o la máquina virtual del grupo de nodos de Kubernetes, existe la posibilidad de que kubelet en la máquina virtual del grupo de nodos no se inicie debido a un error de directiva estática de CPU. La máquina virtual del grupo de nodos muestra el estado No listo y los pods no se programarán en esta máquina virtual. | Escriba una sesión de soporte técnico y ssh en la máquina virtual del grupo de nodos y siga los pasos descritos en Cambio de la directiva del Administrador de CPU para corregir el servicio kubelet. |
Problemas conocidos de las versiones anteriores
En la tabla siguiente se proporciona un resumen de los problemas conocidos que se arrastran de las versiones anteriores.
| No. | Característica | Problema | Soluciones alternativas o comentarios |
|---|---|---|---|
| 1. | Azure Stack Edge Pro y Azure SQL | La creación de una base de datos SQL requiere acceso de administrador. | Realice los pasos siguientes en lugar de los pasos 1 y 2 en Create-the-sql-database. 1. En la interfaz de usuario local del dispositivo, habilite la interfaz de proceso. Seleccione Proceso > Número de puerto > Habilitar para el proceso > Aplicar. 2. Descargue sqlcmd en la máquina cliente desde la utilidad de comandos de SQL. 3. Conéctese a la dirección IP de la interfaz de proceso (el puerto que se habilitó), agregando ",1401" al final de la dirección. 4. El comando final tiene el siguiente aspecto: sqlcmd -S {Interface IP},1401 -U SA -P "Strong!Passw0rd". Tras este cambio, los pasos 3 y 4 de la documentación actual deben ser idénticos. |
| 2. | Actualizar | No se admiten los cambios incrementales en los blobs restaurados mediante la funcionalidad de actualización. | En los puntos de conexión de blob, las actualizaciones parciales de los blobs después de la funcionalidad de actualización pueden dar lugar a que las actualizaciones no se carguen en la nube. Por ejemplo, supongamos una secuencia de acciones como la siguiente: 1. Crear un blob en la nube. O bien, eliminar del dispositivo un blob cargado previamente. 2. Actualizar el blob desde la nube en el dispositivo mediante la funcionalidad de actualización. 3. Actualizar solo una parte del blob mediante las API REST de Azure SDK. Estas acciones pueden dar lugar a que las secciones actualizadas del blob no se actualicen en la nube. Solución alternativa: use herramientas como robocopy o la copia normal de archivos con el Explorador o la línea de comandos para reemplazar los blobs completos. |
| 3. | Limitaciones | En una limitación, si no se permiten nuevas escrituras en el dispositivo, las escrituras realizadas por el cliente NFS generarán el error "Permiso denegado". | El error se muestra como se muestra a continuación:hcsuser@ubuntu-vm:~/nfstest$ mkdir testmkdir: no se puede crear el directorio "test"; permiso denegado. |
| 4. | Ingesta de Blob Storage | Si usa AzCopy versión 10 para la ingesta de Blob Storage, ejecute AzCopy con el siguiente argumento: Azcopy <other arguments> --cap-mbps 2000. |
Si no se proporcionan estos límites para AzCopy, se podría enviar un gran número de solicitudes al dispositivo, lo que provocaría problemas con el servicio. |
| 5. | Cuentas de almacenamiento en capas | Cuando se usan cuentas de almacenamiento en capas, se aplica lo siguiente: - Solo se admiten blobs en bloques. No se admiten los blobs en páginas. - No hay compatibilidad con la API de copia o instantánea. - No se admite la ingesta de cargas de trabajo de Hadoop mediante distcp, ya que utiliza la operación de copia de forma intensiva. |
|
| 6. | Conexión de recurso compartido NFS | Si varios procesos realizan copias en el mismo recurso compartido y no se utiliza el atributo nolock, es posible que aparezcan errores durante la copia. |
Para copiar archivos en el recurso compartido NFS, se debe usar el atributo nolock con el comando mount. Por ejemplo: C:\Users\aseuser mount -o anon \\10.1.1.211\mnt\vms Z:. |
| 7. | Clúster de Kubernetes | Cuando se aplica una actualización en el dispositivo que ejecuta un clúster de Kubernetes, las máquinas virtuales de Kubernetes se reinician. En este caso, solo se restauran automáticamente después de una actualización los pods que se implementan con las réplicas especificadas. | Si ha creado pods individuales fuera de un controlador de replicación sin especificar un conjunto de réplicas, estos pods no se restaurarán automáticamente después de la actualización del dispositivo. Debe restaurar estos pods. Los pods que se eliminan o finalizan por alguna razón, como un error en un nodo o una actualización del nodo que genere problemas, se sustituyen por conjuntos de réplicas. Por este motivo, es conveniente que utilice un conjunto de réplicas aunque la aplicación solamente necesite un único pod. |
| 8. | Clúster de Kubernetes | Kubernetes en Azure Stack Edge Pro solo es compatible con Helm v3 o posterior. Para más información, consulte las preguntas frecuentes: eliminación de Tiller. | |
| 9. | Kubernetes | El puerto 31000 está reservado para el panel de Kubernetes. El puerto 31001 está reservado para el registro de contenedor de Edge. De forma similar, en la configuración predeterminada, las direcciones IP 172.28.0.1 y 172.28.0.10 se reservan para el servicio Kubernetes y el servicio DNS principal, respectivamente. | No use direcciones IP reservadas. |
| 10. | Kubernetes | Actualmente, Kubernetes no permite servicios LoadBalancer con varios protocolos. Por ejemplo, un servicio DNS que tuviese que escuchar en TCP y UDP. | Para solucionar esta limitación de Kubernetes con MetalLB, se pueden crear dos servicios, uno para TCP y otro para UDP, en el mismo selector del pod. Estos servicios usan la misma clave de uso compartido y el mismo valor de spec.loadBalancerIP para compartir la misma dirección IP. También puede compartir las direcciones IP si tiene más servicios que direcciones IP disponibles. Para obtener más información, consulte Uso compartido de las direcciones IP. |
| 11. | Clúster de Kubernetes | Es posible que los módulos de Azure IoT Edge Marketplace existentes necesiten modificaciones para que se ejecuten en IoT Edge en el dispositivo Azure Stack Edge. | Para obtener información adicional, consulte Ejecución de módulos de IoT Edge existentes desde dispositivos de FPGA de Azure Stack Edge Pro en el dispositivo de GPU de Azure Stack Edge Pro. |
| 12. | Kubernetes | En un dispositivo Azure Stack Edge, no se admiten los montajes de enlace basados en archivos con Azure IoT Edge en Kubernetes. | IoT Edge usa una capa de traducción para traducir las opciones ContainerCreate a construcciones de Kubernetes. La creación de asignaciones de Binds al directorio hostpath y los posteriores montajes de los enlaces basados en archivos no se pueden enlazar a rutas de acceso en los contenedores de IoT Edge. Si es posible, asigne el directorio principal. |
| 13. | Kubernetes | Si trae sus propios certificados para IoT Edge y los agrega al dispositivo Azure Stack Edge después de que el proceso se haya configurado en el dispositivo, los nuevos certificados no se seleccionarán. | Para solucionar este problema, debe cargar los certificados antes de configurar el proceso en el dispositivo. Si el proceso ya está configurado, Conéctese a la interfaz de PowerShell del dispositivo y ejecute los comandos de IoT Edge. Reinicie los pods iotedged y edgehub. |
| 14. | Certificados | En determinados casos, el estado del certificado en la interfaz de usuario local puede tardar varios segundos en actualizarse. | Los escenarios siguientes en la interfaz de usuario local pueden verse afectados. - La columna Estado en la página Certificados. - El icono Seguridad en la página de Introducción. - El icono Configuración en la página de Información general. |
| 15. | Certificados | Las alertas relacionadas con los certificados de cadena de firma no se quitan del portal incluso después de cargar nuevos certificados de cadena de firma. | |
| 16. | Proxy web | No se admite el proxy web basado en autenticación NTLM. | |
| 17. | Internet Explorer | Si las características de seguridad mejorada están habilitadas, es posible que no pueda acceder a las páginas de la interfaz de usuario web local. | Deshabilite la seguridad mejorada y reinicie el explorador. |
| 18. | Kubernetes | Kubernetes no admite ":" en los nombres de las variables de entorno que utilizan las aplicaciones .NET. Esto también es necesario para que el módulo de IoT Edge de Event Grid funcione en el dispositivo de Azure Stack Edge y en otras aplicaciones. Para más información, consulte Documentación de ASP.NET Core. | Reemplace ":" por un guion bajo doble. Para más información, consulte Incidencia de Kubernetes |
| 19. | Azure Arc + clúster de Kubernetes | De manera predeterminada, cuando el recurso yamls se elimina del repositorio de Git, no se eliminan los recursos correspondientes del clúster de Kubernetes. |
Para permitir la eliminación de recursos cuando se eliminen del repositorio de Git, establezca --sync-garbage-collection en Arc OperatorParams. Para obtener más información, consulte Eliminación de una configuración. |
| 20. | NFS | Las aplicaciones que usan montajes de recursos compartidos de NFS en el dispositivo para escribir datos deben usar escritura exclusiva. Así se garantiza que las escrituras se realizan en el disco. | |
| 21. | Configuración del proceso | En configuraciones de red en las que las puertas de enlace o los conmutadores o enrutadores responden a las solicitudes del Protocolo de resolución de direcciones (ARP) para sistemas que no existen en la red se produce un error en la configuración del proceso. | |
| 22. | Proceso y Kubernetes | Si Kubernetes se configura en primer lugar en el dispositivo, notifica todas las GPU disponibles. Por lo tanto, no es posible crear máquinas virtuales de Azure Resource Manager mediante GPU después de configurar Kubernetes. | Si el dispositivo tiene dos GPU, puede crear una máquina virtual que use la GPU y, a continuación, configurar Kubernetes. En este caso, Kubernetes usará la otra GPU disponible. |
| 23. | Extensión de script personalizado en las máquinas virtuales | Hay un problema conocido en las máquinas virtuales Windows que se crearon en una versión anterior y cuyo dispositivo se actualizó a la versión 2103. Si agrega una extensión de script personalizado a estas máquinas virtuales, el agente invitado de la máquina virtual Windows (solo la versión 2.7.41491.901) se bloquea en la actualización, lo que hace que se agote el tiempo de espera de la implementación de la extensión. |
Para evitar este problema: 1. Conéctese a la máquina virtual Windows mediante el protocolo de escritorio remoto (RDP). 2. Asegúrese de que waappagent.exe se está ejecutando en la máquina: Get-Process WaAppAgent. 3. Si waappagent.exe no se está ejecutando, reinicie el servicio rdagent: Get-Service RdAgent | Restart-Service. Espere 5 minutos.4. Mientras waappagent.exe se está ejecutando, termine el proceso WindowsAzureGuest.exe. 5. Después de terminar el proceso, este empieza a ejecutarse de nuevo con la versión más reciente. 6. Compruebe que la versión del agente invitado de la máquina virtual Windows sea la 2.7.41491.971 con este comando: Get-Process WindowsAzureGuestAgent | fl ProductVersion.7. Configure la extensión de script personalizado en una máquina virtual Windows. |
| 24. | Servicio multiproceso (MPS) | Cuando se actualizan el software del dispositivo y el clúster de Kubernetes, la configuración de MPS para las cargas de trabajo no se conserva. | Vuelva a habilitar MPS y a implementar las cargas de trabajo que usaban MPS. |
| 25. | Wi-Fi | La Wi-Fi no funciona en Azure Stack Edge Pro 2 en esta versión. | |
| 26. | Azure IoT Edge | La solución de Azure IoT Edge administrada en Azure Stack Edge se ejecuta en un entorno de ejecución de IoT Edge antiguo y obsoleto que está en el final de su ciclo de vida. Para obtener más información, consulte IoT Edge v1.1 EoL: ¿Qué consecuencias tiene esto para mí? Aunque la solución no deja de funcionar al terminar su vida útil, no hay ningún plan para actualizarla. | Para ejecutar la versión LTS más reciente de Azure IoT Edge con las actualizaciones y características más recientes en Azure Stack Edge, se recomienda implementar una solución de IoT Edge autoadministrada por el cliente que se ejecute en una máquina virtual Linux. Para más información, consulte Traslado de cargas de trabajo de IoT Edge administradas en Azure Stack Edge a una solución de IoT Edge en una máquina virtual Linux. |
| 27. | AKS en Azure Stack Edge | En esta versión, no puede modificar las redes virtuales una vez implementado el clúster de AKS en el clúster de Azure Stack Edge. | Para modificar la red virtual, debe eliminar el clúster de AKS, modificar las redes virtuales y volver a crear el clúster de AKS en Azure Stack Edge. |
| 28. | Actualización de AKS | Es posible que se produzca un error en la actualización de Kubernetes de AKS si una de las máquinas virtuales de AKS no se está ejecutando. Esta incidencia puede verse en el clúster de dos nodos. | Si se ha producido un error en la actualización de AKS, consulte Conectarse a la interfaz de PowerShell del dispositivo. Para comprobar el estado de las máquinas virtuales de Kubernetes, ejecute el cmdlet Get-VM. Si la máquina virtual está desactivada, ejecute el cmdlet Start-VM para reiniciarla. Una vez que se esté ejecutando la máquina virtual de Kubernetes, vuelva a aplicar la actualización. |
| 29. | Wi-Fi | La funcionalidad Wi-Fi para Azure Stack Edge Mini R está en desuso. |