Exécution de conteneurs Windows sur AKS

Cet article est destiné à être considéré comme une extension de l’architecture de base AKS, qui fournit un examen approfondi des configurations recommandées pour déployer un cluster AKS dans un environnement de production. L’objectif de cet article est de fournir des conseils relatifs au déploiement de conteneurs Windows sur AKS. Par conséquent, cet article se concentre sur ces configurations spécifiques au déploiement de Windows sur AKS et vous devez vous référer à la documentation de base AKS pour les configurations déjà décrites ici.

Reportez-vous au Projet GitHub de référence Windows AKS pour passer en revue l’implémentation de référence associée à cette architecture de référence, y compris l’exemple de code de déploiement.

Conception du réseau

La conception réseau utilisée dans cette architecture est basée sur la conception utilisée dans l’architecture de base AKS et partage par conséquent tous les composants principaux avec cette conception, à l’exception des modifications suivantes.

• Des contrôleurs de domaine Active Directory ont été ajoutés pour prendre en charge les charges de travail Windows.
• La solution d’entrée de cette architecture utilise Azure Front Door (AFD) et Proxy d’application Microsoft Entra au lieu d’Azure App Gateway qui est utilisé dans l’architecture de base AKS.

Conception d’entrée

Composants :

• Azure Front Door avec un WAF : AFD est le point d’entrée public pour les applications hébergées sur le cluster AKS. AFD Premium est utilisé dans cette conception, car il permet l’utilisation de Private Link qui verrouille le trafic d’application interne vers la mise en réseau privée, offrant le plus haut niveau de sécurité. Web Application Firewall (WAF) protège contre les vulnérabilités et les codes malveillants exploitant une faille de sécurité courants d’applications web.
• Proxy d’application Microsoft Entra : ce composant sert de deuxième point d’entrée devant l’équilibreur de charge interne géré par AKS. Microsoft Entra ID est activé pour la pré-authentification des utilisateurs et utilise une stratégie d’accès conditionnel pour empêcher des plages d’adresses IP non autorisées (le proxy d'application voit l’adresse IP du client d’origine, qu’il compare à la stratégie d’accès conditionnel) et des utilisateurs d’accéder au site. Il s’agit de la seule façon d’acheminer des demandes d’authentification Kerberos lors de l’utilisation d’un service Azure qui prend en charge WAF. Pour obtenir une description détaillée de la fourniture de l’accès à l’authentification unique aux applications protégées par Proxy d'application, consultez Délégation contrainte Kerberos pour l’authentification unique (SSO) à vos applications avec Proxy d’application
• Équilibreur de charge interne : géré par AKS. Cet équilibreur de charge expose le contrôleur d’entrée via une adresse IP statique privée. Il fait office de point de contact unique recevant des requêtes HTTP entrantes.
• Aucun contrôleur d’entrée dans le cluster (comme Nginx) n’est utilisé dans cette architecture.

Pour implémenter cette conception, AFD doit être configuré pour utiliser l’URL Proxy d'application créée lors de la publication de l’application dans ce service. Cette configuration achemine le trafic entrant vers le proxy et permet à la pré-authentification de se produire.

Topologie du réseau

Le diagramme ci-dessous montre la conception du réseau hub-and-spoke utilisée dans cette architecture.

Téléchargez un fichier Visio de cette architecture.

Topologie du pool de nœuds

Cette architecture utilise trois pools de nœuds : un pool de nœuds système exécutant Linux, un pool de nœuds utilisateur exécutant Linux et un pool de nœuds utilisateur exécutant Windows. Les pools de nœuds utilisateur Windows et Linux sont utilisés pour des charges de travail, tandis que le pool de nœuds système est utilisé pour toutes les configurations au niveau du système, telles que CoreDNS.

Flux de trafic d’entrée

1. Le client envoie une requête HTTPS au nom de domaine : bicycle.contoso.com. Ce nom est associé à l’enregistrement DNS A pour l’adresse IP publique d’Azure Front Door. Ce trafic est chiffré pour veiller à ce que le trafic entre le navigateur client et la passerelle ne soit pas inspecté ou modifié.
2. Azure Front Door dispose d’un pare-feu d’applications Web (WAF) intégré et se charge de la négociation TLS pour bicycle.contoso.com, autorisant ainsi les seuls chiffrements sécurisés. Azure Front Door Gateway est un point de terminaison TLS requis pour traiter des règles d’inspection WAF et exécuter des règles d’acheminement qui transfèrent le trafic vers le back-end configuré. Le certificat TLS est stocké dans Azure Key Vault.
3. Le service AFD achemine la requête de l’utilisateur vers le Proxy d’application Azure. AFD est configuré pour autoriser uniquement un trafic HTTPS. L’utilisateur doit s’authentifier auprès de Microsoft Entra ID en cas d’activation de la pré-authentification.
4. Le Proxy d’application achemine l’utilisateur vers le conteneur d’application back-end via l’équilibreur de charge AKS.

Flux du trafic de sortie

Tous les conseils de l’article de base AKS s’appliquent ici avec une recommandation supplémentaire pour les charges de travail Windows : pour tirer parti des mises à jour automatiques de Windows Server, vous ne devez pas bloquer les Noms de domaine complets requis dans votre ensemble de règles de Pare-feu Azure.

Planification des adresses IP

Contrairement aux clusters AKS avec des pools de nœuds Linux, les clusters AKS ayant des pools de nœuds Windows nécessitent Azure CNI. L’utilisation d’Azure CNI permet d’affecter à un pod une adresse IP d’un réseau virtuel Azure. Le pod peut ensuite communiquer via le réseau virtuel Azure comme n’importe quel autre appareil. Il peut se connecter à d’autres pods, à des réseaux appairés ou à des réseaux locaux à l’aide d’ExpressRoute ou d’un VPN, ou à d’autres services Azure via Private Link.

Tous les conseils relatifs à la planification des adresses IP fournies dans l’article sur l’architecture de base AKS s’appliquent ici, incluant une recommandation supplémentaire : envisagez d’approvisionner un sous-réseau dédié pour vos contrôleurs de domaine. En ce qui concerne le pool de nœuds Windows, il est recommandé de le séparer logiquement des autres pools de nœuds via des sous-réseaux distincts.

Mise à niveau d’un pool de nœuds

Le processus de mise à niveau de nœuds Windows est inchangé par rapport aux instructions fournies dans la documentation de mise à niveau de l’image de nœud Azure Kubernetes Service (AKS), mais vous devez tenir compte des différences de planification suivantes pour planifier votre cadence de mise à niveau.

Microsoft fournit de nouvelles images Windows Server, y compris des correctifs à jour, pour des nœuds tous les mois et n’effectue aucune mise à jour corrective ou mise à jour automatique. Par conséquent, vous devez mettre à jour manuellement ou par programme vos nœuds conformément à cette planification. L’utilisation de GitHub Actions pour créer une tâche cron qui s’exécute selon une planification vous permet de planifier par programme des mises à niveau mensuelles. Les conseils fournis dans la documentation liée ci-dessus reflètent les processus de nœud Linux, mais vous pouvez mettre à jour le fichier YAML pour définir votre planification cron afin qu’elle s’exécute mensuellement plutôt que deux fois par semaine. Vous devez également remplacer le paramètre « runs-on » dans le fichier YAML par « windows-latest » pour vous assurer que vous effectuez une mise à niveau vers l’image Windows Server la plus récente.

Si vous souhaitez obtenir des conseils supplémentaires, consultez le guide de l’opérateur AKS sur la mise à jour corrective et la mise à jour des nœuds Worker.

Considérations relatives à la capacité de calcul

Les plus grandes tailles d’images associées aux images basées sur un serveur Windows nécessitent le déploiement de disques de système d’exploitation de taille appropriée dans votre pool de nœuds. L’utilisation de disques de système d’exploitation éphémères est toujours recommandée pour tous les nœuds, y compris Windows. Veillez donc à bien comprendre les exigences de taille que vous devez respecter lors de la planification de votre déploiement.

Gestion des identités

Les conteneurs Windows ne pouvant pas être joints à un domaine, si vous avez besoin d’une authentification et d’une autorisation Active Directory, vous pouvez utiliser des Comptes de service administrés de groupe (gMSA). Pour utiliser un gMSA, vous devez activer le profil de gMSA sur votre cluster AKS exécutant des nœuds Windows. Reportez-vous à la documentation AKS sur les gMSA pour bénéficier d’un examen complet de l’architecture et d’un guide sur l’activation du profil.

Nœud et la mise à l’échelle de pod

Les instructions relatives à l’autoscaler de cluster sont inchangées pour des conteneurs Windows. Pour obtenir des conseils, reportez-vous à la documentation sur l’autoscaler de cluster.

La documentation du cluster de base décrit les approches manuelles et de mise à l’échelle automatique disponibles pour la mise à l’échelle de pods. Les deux approches sont disponibles pour des clusters exécutant des conteneurs Windows et les conseils fournis dans cet article s’appliquent également ici en général.

La différence entre des conteneurs Linux et Windows en ce qui concerne les opérations de mise à l’échelle de pods est la taille de l’image dans la plupart des cas. Les plus grandes tailles d’image de conteneurs Windows sont susceptibles d’augmenter la durée d’exécution des opérations de mise à l’échelle et, par conséquent, certaines considérations relatives à l’approche de mise à l’échelle doivent être prises en compte. Ce scénario est courant avec des applications .NET héritées en raison de la taille du runtime .NET. Afin d’atténuer les retards d’extraction de l’image pendant des périodes de mise à l’échelle, vous pouvez utiliser un DaemonSet pour extraire l’image d’ACR vers un cache sur chaque nœud Windows, et donc effectuer une rotation des pods avec l’image pré-chargée. À partir de ce moment, les pods doivent simplement exécuter les processus de configuration d’application définis pour votre charge de travail avant leur mise en ligne.

Des exercices de point de référence doivent être effectués pour comprendre l’impact sur le temps de l’exécution des opérations de mise à l’échelle et ces données doivent être évaluées par rapport aux besoins de l’entreprise. Si votre charge de travail doit être mise à l’échelle plus rapidement que ce qui est possible via une mise à l’échelle automatique, il est recommandé d’envisager l’autre solution d’« échange à chaud » suivante :

Vous devez d’abord effectuer des tests de base pour identifier le nombre de pods que vous devez exécuter lors de périodes de chargement fortes et creuses. Une fois cette base établie, vous pouvez planifier votre nombre de nœuds pour tenir compte du nombre total de nœuds dont vous avez besoin à un moment donné. Cette solution implique l’utilisation de la mise à l’échelle manuelle pour votre cluster et la définition du nombre initial de nœuds sur le nombre de nœuds requis en période creuse. Lorsque vous approchez d’une période de pointe, vous devez effectuer une mise à l’échelle préemptive sur le nombre de nœuds de la période de chargement forte. Au fil du temps, vous devez rétablir régulièrement votre base pour tenir compte de l’évolution de l’utilisation des applications ou d’autres besoins de l’entreprise.

Surveillance

Les conteneurs exécutant Windows peuvent être surveillés avec Azure Monitor et Container Insights, tout comme des conteneurs Linux. Par conséquent, les conseils fournis dans l’article de base AKS s’appliquent également ici pour la plupart des conteneurs. Toutefois, la surveillance Container Insights pour un cluster Windows Server présente les limitations suivantes :

• Windows n’a pas de métrique Mémoire RSS. Elle n’est donc pas disponible pour les nœuds et les conteneurs Windows. La métrique Plage de travail est disponible
• Les informations de capacité de stockage des disques ne sont pas disponibles pour les nœuds Windows.

Vous pouvez également compléter Container Insights en utilisant des règles de collecte de données pour collecter des événements et des compteurs de performances à partir de vos systèmes Windows Server.

Gestion des stratégies

Tous les conseils de stratégie figurant dans l’article de base AKS s’appliquent aux charges de travail Windows. Les stratégies spécifiques à Windows supplémentaires trouvées dans l’article de référence Définitions intégrées d’Azure Policy pour Azure Kubernetes Service à prendre en compte sont les suivantes :

• Les conteneurs Windows du cluster Kubernetes ne doivent pas surcharger le processeur et la mémoire
• Les conteneurs Windows de cluster Kubernetes ne doivent pas s’exécuter en tant que ContainerAdministrator
• Les conteneurs Windows du cluster Kubernetes ne doivent s’exécuter qu’avec un utilisateur et un groupe d’utilisateurs de domaine approuvés

Démarrage de cluster

Comme avec les conseils de démarrage du cluster fournis dans l’article de base AKS, les opérateurs de cluster doivent également prendre en compte leur approche de démarrage pour des charges de travail Windows. Les mêmes conseils fournis dans l’article de base AKS s’appliquent également ici.

Gestion des coûts

Tous les conseils d’optimisation des coûts figurant dans l’article de base AKS s’appliquent aux charges de travail Windows. Les autres considérations relatives aux coûts devant être prises en compte sont les suivantes :

• Les coûts de licence pour Windows Server augmentent le coût des nœuds de votre cluster AKS. Les recommandations d’optimisation des coûts pour ce facteur incluent la réservation de capacité ou l’utilisation de licences existantes si vous en avez déjà pour d’autres utilisations d’entreprise.
  • Consultez la documentation Azure Hybrid Benefit pour Windows Server (AHUB) pour en savoir plus sur les remises pour vos licences Software Assurance (SA) de Windows Server applicables.
  • Consultez le FAQ sur les conteneurs Windows Server pour obtenir des instructions sur l’application de l’avantage aux clusters nouveaux et existants.
• La taille des images de conteneur Windows peut entraîner des coûts Azure Container Registry (ACR) supplémentaires en raison de la quantité de stockage nécessaire pour plusieurs images, du nombre de nœuds simultanés extraits à partir d’ACR et des exigences de géoréplication.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Isabelle Bersano | Architecte de solution cloud
• Akshay Nimbalkar | Architecte principal de solution cloud
• Clayton Siemens | Développeur principal de contenu

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• En savoir plus sur les Conteneurs Windows

Ressources associées

• Découvrir comment déployer des pools de nœuds Windows sur un cluster AKS