Notes de publication d’Azure Stack Edge 2403
S’APPLIQUE À : Azure Stack Edge Pro : GPUAzure Stack Edge Pro 2Azure Stack Edge Pro RAzure Stack Edge Mini R
Les notes de publication suivantes identifient les problèmes d’ouverture critiques et les problèmes résolus dans la version 2403 de vos appareils Azure Stack Edge. Les fonctionnalités et les problèmes qui correspondent à un modèle spécifique d’Azure Stack Edge sont indiqués dans la mesure du possible.
Les notes de publication sont régulièrement mises à jour ; les problèmes critiques nécessitant une solution de contournement sont ajoutés au fur et à mesure de leur découverte. Avant de déployer votre appareil, lisez attentivement les informations contenues dans les notes de publication.
Cet article concerne la version 2403 d'Azure Stack Edge, qui correspond à la version logicielle 3.2.2642.2487.
Avertissement
Dans cette version, vous devez mettre à jour Packet Core vers la version AP5GC 2308 avant de procéder à la mise à jour vers Azure Stack Edge 2403. Pour obtenir les étapes détaillées, consultez l’article Notes de publication d’Azure Private 5G Core 2308. Si vous effectuez la mise à jour vers Azure Stack Edge 2403 avant de procéder à la mise à jour vers Packet Core 2308.0.1, vous rencontrerez une panne générale du système. Dans ce cas, vous devez supprimer et recréer le cluster Azure Kubernetes Service sur votre appareil Azure Stack Edge. Chaque fois que vous modifiez le profil de charge de travail Kubernetes, vous êtes invité à effectuer la mise à jour Kubernetes. Continuez et appliquez la mise à jour.
Chemins de mise à jour pris en charge
Pour appliquer la mise à jour 2403, votre appareil doit exécuter la version 2303 ou ultérieure.
Si la version minimale requise n’est pas installée, le message d’erreur suivant s’affiche :
Le package de mise à jour ne peut pas être installé car ses dépendances ne sont pas satisfaites.
Vous pouvez effectuer une mise à jour vers la version 2303 à partir de la version 2207 ou ultérieure, puis installer la version 2403.
Vous pouvez effectuer une mise à jour vers la dernière version à l’aide des chemins de mise à jour suivants :
Version actuelle du logiciel Azure Stack Edge et de Kubernetes | Mise à jour vers le logiciel Azure Stack Edge et Kubernetes | Mise à jour souhaitée vers 2403 |
---|---|---|
2207 | 2303 | 2403 |
2209 | 2303 | 2403 |
2210 | 2303 | 2403 |
2301 | 2303 | 2403 |
2303 | Directement vers | 2403 |
Nouveautés
La version 2403 présente les nouvelles fonctionnalités et améliorations suivantes :
- Prise en charge déconseillée de la télémétrie du service Azure Kubernetes sur Azure Stack Edge.
- Prise en charge des étiquettes de zone pour les clusters Kubernetes à deux nœuds.
- Gestion des machines virtuelles Hyper-V, surveillance de l’utilisation de la mémoire sur l’hôte Azure Stack Edge.
Problèmes résolus dans cette version
Non. | Fonctionnalité | Problème |
---|---|---|
1. | Clustering | Le démarrage à froid du serveur à deux nœuds entraîne la mise hors ligne des ressources du cluster de machines virtuelles à haute disponibilité. Remplacement de ColdStartSetting par AlwaysStart. |
2. | Prise en charge des images de la Place de marché | Correction d’un bogue autorisant l’image de la Place de marché Windows sur Azure Stack Edge A et TMA. |
3. | Connectivité réseau | Correction de l’altération de la liaison avec la carte d’interface réseau (NIC) de la machine virtuelle après la désactivation ou l’activation de l’hôte Azure Stack Edge, pouvant entraîner la perte de l’IP DHCP de la machine virtuelle. |
4. | Connectivité réseau | En raison des configurations ARP proxy dans certains environnements clients, la vérification de l’adresse IP en cours d’utilisation retourne un faux positif, même lorsqu’aucun point de terminaison du réseau n’utilise l’adresse IP. Le correctif ignore la vérification de l’adresse IP en cours d’utilisation de la machine virtuelle basée sur ARP si l’adresse IP est allouée à partir d’un réseau interne géré par Azure Stack Edge. |
5. | Connectivité réseau | L’opération de modification de la carte d’interface réseau de la machine virtuelle s’achève au bout de 3 heures, ce qui bloque toute autre opération de mise à jour de la machine virtuelle. Sur les clusters Microsoft Kubernetes, les pods dépendants du volume persistant (PV) sont bloqués. Ce problème survient lorsque plusieurs cartes d’interface réseau au sein d’une machine virtuelle sont transférées d’un réseau virtuel VLAN vers un réseau virtuel non-VLAN. Suite au correctif, l’opération de modification de la carte d’interface réseau de la machine virtuelle s’achève rapidement et la mise à jour de la machine virtuelle n’est pas bloquée. |
6. | Kubernetes | Améliorations générales de la résilience de Kubernetes à deux nœuds, telles que l’augmentation de la mémoire pour le plan de contrôle du cluster de charge de travail AKS, l’augmentation des limites pour etcd, multi-replica, et la prise en charge de l’anti-affinité stricte pour le DNS principal et les pods de contrôleur csi du disque Azure, ainsi que l’amélioration des temps de basculement des machines virtuelles. |
7. | Diagnostic et mise à jour du calcul | Correctifs en matière de résilience |
8. | Sécurité | Correctifs de sécurité STIG pour le système d’exploitation invité Mariner dans le cadre du service Azure Kubernetes sur Azure Stack Edge. |
9. | Opérations de la machine virtuelle | Sur un cluster Azure Stack Edge qui déploie une charge de travail AP5GC, lorsque l’hôte renvoie une erreur transitoire concernant la configuration du groupe de processeur après un test de cycle d’alimentation de l’hôte, AzSHostAgent se bloque. Cela provoque une défaillance des opérations de la machine virtuelle. Le correctif a rendu AzSHostAgent résilient à une erreur de groupe de processeur transitoire. |
Problèmes connus dans cette version
Non. | Fonctionnalité | Problème | Solution de contournement/commentaires |
---|---|---|---|
1. | Explorateur Stockage Azure | Le certificat du point de terminaison du stockage Blob auto-généré par l’appareil Azure Stack Edge peut ne pas fonctionner correctement avec Azure Storage Explorer. | Remplacez le certificat du point de terminaison du stockage Blob. Pour obtenir des instructions détaillées, consultez la rubrique Apportez vos propres certificats. |
2. | Connectivité réseau | Sur un cluster Azure Stack Edge Pro 2 à deux nœuds doté d’un commutateur virtuel associé pour le port 1 et le port 2, si un lien du Port 1 ou du Port 2 est défaillant, la restauration de la connectivité réseau sur le port actif restant peut prendre jusqu’à 5 secondes. Si le cluster Kubernetes utilise ce commutateur virtuel associé pour le trafic de gestion, la communication entre les pods peut être interrompue pendant une durée maximale de 5 secondes. | |
3. | Machine virtuelle | Après l’arrêt de l’hôte ou de la machine virtuelle du pool de nœuds Kubernetes, il est possible que le kubelet de la machine virtuelle du pool de nœuds ne démarre pas en raison d’une erreur de stratégie statique du processeur. La machine virtuelle du pool de nœuds affiche l’état Non prêt, et les pods ne sont pas planifiés sur cette machine virtuelle. | Ouvrez une session d’assistance et connectez-vous en mode ssh à la machine virtuelle du pool de nœuds, puis suivez les étapes indiquées dans la section Modification de la stratégie du gestionnaire de processeur pour corriger le service kubelet. |
Problèmes connus issus des versions précédentes
Le tableau suivant fournit un résumé des problèmes connus déjà présents dans les versions précédentes.
Non. | Fonctionnalité | Problème | Solution de contournement/commentaires |
---|---|---|---|
1. | Azure Stack Edge Pro + Azure SQL | La création d’une base de données SQL nécessite un accès administrateur. | Effectuez les étapes suivantes à la place des étapes 1 à 2 dans Create-the-sql-database. 1. Dans l’interface utilisateur locale de votre appareil, activez l’interface de calcul. Sélectionnez Compute > N° de port > Activer pour le calcul > Appliquer. 2. Téléchargez sqlcmd sur votre ordinateur client à partir de l’utilitaire de commande SQL. 3. Connectez-vous à l’adresse IP de votre interface de calcul (port activé), en ajoutant un « 1401 » à la fin de l’adresse. 4. La commande finale ressemble à ceci : sqlcmd -S {Interface IP},1401 -U SA -P "Strong!Passw0rd". Ensuite, les étapes 3-4 de la documentation actuelle devraient être identiques. |
2. | Refresh | Les modifications incrémentielles d’objets blob restaurés via la fonctionnalité Actualiser ne sont pas prises en charge. | Pour les points de terminaison d’objet blob, des mises à jour partielles d’objets blob après une actualisation peuvent empêcher le chargement des mises à jour dans le cloud. Prenons l’exemple de la séquence d’actions suivante : 1. Créer un blob dans le cloud. Ou supprimer un objet blob précédemment chargé à partir de l’appareil. 2. Actualiser le blob du cloud vers l’appliance à l’aide de la fonctionnalité d’actualisation. 3. Mettre à jour une partie seulement du blob à l’aide des API REST du Kit de développement logiciel (SDK) Azure. Ces actions peuvent avoir pour effet que des sections mises à jour de l’objet blob ne sont pas mises à jour dans le cloud. Solution de contournement : servez-vous d’outils tels que Robocopy ou d’une copie de fichiers normale via l’Explorateur ou la ligne de commande pour remplacer des objets blob entiers. |
3. | Limitation | Lors d’une limitation, si de nouvelles écritures sur l’appareil ne sont pas autorisées, les écritures effectuées par le client NFS échouent avec l’erreur « Autorisation refusée ». | L’erreur s’affiche comme suit :hcsuser@ubuntu-vm:~/nfstest$ mkdir test mkdir : impossible de créer le répertoire 'test' : Autorisation refusée |
4. | Ingestion du Stockage Blob | Lors de l’utilisation d’AzCopy version 10 pour l’ingestion du stockage d’objets blob, exécutez AzCopy avec l’argument suivant : Azcopy <other arguments> --cap-mbps 2000 . |
Si ces limites ne sont pas fournies pour AzCopy, cela risque d’entraîner l’envoi d’un grand nombre de demandes à l’appareil et d’occasionner des problèmes avec le service. |
5. | Comptes de stockage hiérarchisés | Voici ce qu’il se produit lors de l’utilisation de comptes de stockage hiérarchisés : – Seuls les objets blob de blocs sont pris en charge. Les objets blob de pages ne sont pas pris en charge. - Il n’existe aucune prise en charge de l’API de copie ni de la capture instantanée. - L’ingestion de charge de travail Hadoop via distcp n’est pas prise en charge, car elle sollicite abondamment l’opération de copie. |
|
6. | Connexion de partage NFS | Si plusieurs processus copient vers le même partage et que l’attribut nolock n’est pas utilisé, des erreurs peuvent apparaître en cours de copie. |
L’attribut nolock doit être passé à la commande mount pour copier des fichiers vers le partage NFS. Par exemple : C:\Users\aseuser mount -o anon \\10.1.1.211\mnt\vms Z: . |
7. | Cluster Kubernetes | Lorsque vous appliquez une mise à jour sur votre appareil exécutant un cluster Kubernetes, les machines virtuelles Kubernetes redémarrent. Dans ce cas, seuls les pods déployés avec des réplicas spécifiés sont automatiquement restaurés après une mise à jour. | Si vous avez créé des pods individuels en dehors d’un contrôleur de réplication sans spécifier de jeu de réplicas, ces pods ne seront pas restaurés automatiquement après la mise à jour de l’appareil. Vous devez restaurer ces pods. Un jeu de réplicas remplace des pods supprimés ou arrêtés pour une raison quelconque, par exemple un échec de nœud ou une mise à niveau de nœud perturbatrice. Pour cette raison, nous vous recommandons d’utiliser un jeu de réplicas même si votre application ne requiert qu’un seul pod. |
8. | Cluster Kubernetes | Kubernetes sur Azure Stack Edge Pro est pris en charge uniquement avec Helm v3 ou ultérieur. Pour plus d’informations, consultez le forum aux questions : suppression de Tiller. | |
9. | Kubernetes | Le port 31000 est réservé au tableau de bord Kubernetes. Le port 31001 est réservé au registre de conteneurs Edge. De même, dans la configuration par défaut, les adresses IP 172.28.0.1 et 172.28.0.10 sont réservées respectivement pour le service Kubernetes et le service DNS de base. | N’utilisez pas d’adresses IP réservées. |
10. | Kubernetes | Kubernetes n’autorise pas actuellement les services LoadBalancer multiprotocoles. Par exemple, un service DNS devant écouter à la fois les protocoles TCP et UDP. | Pour contourner cette limitation de Kubernetes avec MetalLB, deux services (un pour TCP, un pour UDP) peuvent être créés sur le même sélecteur de pod. Ces services utilisent la même clé de partage et spec.loadBalancerIP pour partager la même adresse IP. Des adresses IP peuvent également être partagées si vous avez plus de services qu’il n’y d’adresses IP disponibles. Pour plus d’informations, voir Partage d’adresse IP. |
11. | Cluster Kubernetes | Des modules existants de la Place de marché Azure IoT Edge peuvent nécessiter des modifications pour s’exécuter sur IoT Edge sur un appareil Azure Stack Edge. | Pour plus d’informations, consultez Exécuter des modules IoT Edge existants d’appareils Azure Stack Edge Pro FPGA sur un appareil Azure Stack Edge Pro GPU. |
12. | Kubernetes | Les montages de liaison basés sur des fichiers ne sont pas pris en charge avec Azure IoT Edge sur Kubernetes sur un appareil Azure Stack Edge. | IoT Edge utilise une couche de traduction pour convertir des options de ContainerCreate en constructions Kubernetes. La création de Binds mappe au répertoire hostpath . Par conséquent, des montages de liaisons basés sur des fichiers ne peuvent pas être liés à des chemins dans des conteneurs IoT Edge. Si possible, mappez le répertoire parent. |
13. | Kubernetes | Si vous apportez vos propres certificats pour IoT Edge et que vous les ajoutez sur votre appareil Azure Stack Edge une fois le calcul configuré sur celui-ci, les nouveaux certificats ne sont pas sélectionnés. | Pour contourner ce problème, vous devez charger les certificats avant de configurer le calcul sur l’appareil. Si le calcul est déjà configuré, connectez-vous à l’interface PowerShell de l’appareil et exécutez des commandes IoT Edge. Redémarrez les pods iotedged et edgehub . |
14. | Certificats | Dans certains cas, la mise à jour de l’état des certificats dans l’interface utilisateur locale peut prendre plusieurs secondes. | Les scénarios suivants dans l’interface utilisateur locale peuvent être affectés. - Colonne État dans la page Certificats. - Vignette Sécurité dans la page Démarrer. - Vignette Configuration dans la page Vue d’ensemble. |
15. | Certificats | Les alertes liées aux certificats de chaîne de signature ne sont pas supprimées du portail, même après le chargement de nouveaux certificats de chaîne de signature. | |
16. | Proxy web | Le proxy web basé sur l’authentification NTLM n’est pas pris en charge. | |
17. | Internet Explorer | Si les fonctionnalités de sécurité améliorées sont activées, vous ne pourrez peut-être pas accéder aux pages de l’interface utilisateur web locale. | Désactivez la sécurité renforcée, puis redémarrez votre navigateur. |
18. | Kubernetes | Kubernetes ne prend pas en charge « : » dans les noms de variables d’environnement utilisés par les applications .NET. Cela est également nécessaire pour que le module Event Grid IoT Edge fonctionne sur l’appareil Azure Stack Edge et d’autres applications. Pour plus d’informations, consultez la documentation sur ASP.NET Core. | Remplacez « : » par un trait de soulignement double. Pour plus d’informations, consultez la rubrique Problème Kubernetes |
19. | Cluster Azure Arc + Kubernetes | Par défaut, lorsque les ressources yamls sont supprimées du dépôt Git, les ressources correspondantes ne sont pas supprimées du cluster Kubernetes. |
Pour autoriser la suppression des ressources quand elles sont supprimées du référentiel git, définissez --sync-garbage-collection dans OperatorParams, dans Arc. Pour plus d’informations, consultez Supprimer une configuration. |
20. | NFS | Les applications qui utilisent des montages de partage NFS sur votre appareil pour écrire des données doivent utiliser l’écriture exclusive. Ceci garantit que les écritures sont écrites sur le disque. | |
21. | Configuration du calcul | La configuration du calcul échoue dans les configurations réseau où les passerelles, commutateurs ou routeurs répondent aux demandes ARP (Address Resolution Protocol) pour des systèmes qui n’existent pas sur le réseau. | |
22. | Calcul et Kubernetes | Si Kubernetes est configuré en premier sur votre appareil, il réclame tous les GPU disponibles. Par conséquent, il n’est pas possible de créer des machines virtuelles Azure Resource Manager à l’aide de GPU après avoir configuré Kubernetes. | Si votre appareil a 2 GPU, vous pouvez créer une machine virtuelle qui utilise le GPU, puis configurer Kubernetes. Dans ce cas, Kubernetes utilise le GPU disponible restant. |
23. | Extension de script personnalisé de machine virtuelle | Il existe un problème connu dans les machines virtuelles Windows créées dans une version antérieure alors que l’appareil a été mis à jour vers la version 2103. Si vous ajoutez une extension de script personnalisé sur ces machines virtuelles, l’agent invité de machine virtuelle Windows (version 2.7.41491.901 uniquement) est bloqué dans la mise à jour entraînant une expiration du délai de déploiement de l’extension. |
Pour contourner ce problème : 1. Connectez-vous à la machine virtuelle Windows à l’aide du protocole RDP. 2. Vérifiez que waappagent.exe est en cours d’exécution sur la machine : Get-Process WaAppAgent . 3. Si waappagent.exe n’est pas en cours d’exécution, redémarrez le service rdagent : Get-Service RdAgent | Restart-Service . Patientez 5 minutes.4. Pendant l’exécution de waappagent.exe , arrêtez le processus WindowsAzureGuest.exe . 5. Une fois le processus arrêté, il recommence à s’exécuter avec la version plus récente. 6. Vérifiez que la version de l’agent invité de machine virtuelle Windows est 2.7.41491.971 à l’aide de la commande suivante : Get-Process WindowsAzureGuestAgent | fl ProductVersion .7. Configurer l’extension de script personnalisé sur une machine virtuelle Windows |
24. | Service multiprocessus (MPS) | Lors de la mise à jour du logiciel de l’appareil et du cluster Kubernetes, le paramètre MPS n’est pas conservé pour les charges de travail. | Réactivez MPS et redéployez les charges de travail qui utilisaient MPS. |
25. | Wi-Fi | Le Wi-Fi ne fonctionne pas sur Azure Stack Edge Pro 2 dans cette version. | |
26. | Azure IoT Edge | La solution Azure IoT Edge managée sur Azure Stack Edge s’exécute sur un runtime IoT Edge plus ancien et obsolète, qui est en fin de vie. Pour plus d’informations, consultez l’article IoT Edge v1.1 EoL: What does that mean for me?. Bien que la solution continue de fonctionner après avoir atteint sa fin de vie, il ne sera pas possible de la mettre à jour. | Pour exécuter la dernière version LTS d’Azure IoT Edge avec les dernières mises à jour et fonctionnalités sur Azure Stack Edge, nous vous recommandons de déployer une solution IoT Edge auto-gérée par le client qui s’exécute sur une machine virtuelle Linux. Pour plus d’informations, consultez l’article Déplacer des charges de travail d’IoT Edge managé sur Azure Stack Edge vers une solution IoT Edge sur une machine virtuelle Linux. |
27. | AKS sur Azure Stack Edge | Dans cette version, vous ne pouvez plus modifier les réseaux virtuels une fois le cluster AKS déployé sur votre cluster Azure Stack Edge. | Pour modifier un réseau virtuel, vous devez supprimer le cluster AKS, modifier le réseau virtuel, puis recréer un cluster AKS sur votre instance Azure Stack Edge. |
28. | Mise à jour AKS | La mise à jour AKS Kubernetes peut échouer si l’une des machines virtuelles AKS n’est pas en cours d’exécution. Ce problème peut survenir sur le cluster à 2 nœuds. | En cas d’échec de la mise à jour AKS, connectez-vous à l’interface PowerShell de l’appareil. Vérifiez l’état des machines virtuelles Kubernetes en exécutant la cmdlet Get-VM . Si la machine virtuelle est arrêtée, exécutez la cmdlet Start-VM pour la redémarrer. Une fois la machine virtuelle Kubernetes en cours d’exécution, réappliquez la mise à jour. |
29. | Wi-Fi | La fonctionnalité Wi-Fi pour Azure Stack Edge Mini R est obsolète. |