Cette solution montre comment effectuer une mise à l’échelle entre clusters des charges de travail déployées sur une infrastructure hybride. Cette solution est obtenue en appliquant les fonctionnalités de scalabilité et de gestion des services avec Azure Arc sur les clusters Azure Stack HCI.
Architecture
L’architecture montre le déploiement de solutions hybrides à l’aide de services avec Azure Arc sur Azure Stack HCI, Azure Pipelines et l’intégration d’un équilibreur de charge global et d’une application de fonction Azure.
Téléchargez un fichier Visio de cette architecture.
Workflow
L’architecture se compose des étapes suivantes :
Deux clusters Azure Stack HCI sont configurés dans deux emplacements différents : Azure Stack HCI (HCI1) sert d’infrastructure locale principale et Azure Stack HCI (HCI2) comme infrastructure locale secondaire pour l’exécution de charges de travail.
Les clusters Azure Stack HCI se connectent à Azure via SD-WAN et sont gérés via Azure Arc et Windows Admin Center. Par conséquent, vous pouvez étendre les fonctionnalités Azure à l’infrastructure locale et utiliser les outils et services de gestion Azure pour gérer et surveiller l’infrastructure et la charge de travail locales.
Azure Kubernetes Service (AKS), déployés sur Azure Stack HCI, sont composés du cluster de gestion (hôte AKS) et des clusters de charge de travail (également appelés clusters cibles) où des applications conteneurisées sont déployées. Consultez Architecture de référence d’Azure Kubernetes Service (AKS) pour AKS sur Azure Stack HCI.
L’hôte Azure Kubernetes Service sur Azure Stack HCI et le cluster de charge de travail sont déployés à l’aide des modules AksHci PowerShell. Consultez Utiliser PowerShell pour configurer Kubernetes sur les clusters Azure Stack HCI et Windows Server.
La virtualisation des ressources réseau est implémentée en appliquant des fonctionnalités SDN du cluster Azure Stack HCI. Il déploie les ressources d’infrastructure réseau SDN nécessaires, telles que les machines virtuelles Mux de l’équilibreur de charge logiciel, les machines virtuelles de passerelle RAS et les contrôleurs de réseau pour une disponibilité réseau plus élevée. Consultez SDN (Software defined networking) dans Azure Stack HCI et Windows Server.
Les machines virtuelles d’infrastructure et de charge de travail AKS sont déployées sur un réseau virtuel SDN avec équilibrage de charge hybride obtenu via l’équilibreur de charge logiciel (SLB) SDN. Consultez Déployer la mise en réseau SDN (Software Defined Networking) Microsoft avec AKS sur Azure Stack HCI.
Azure Pipelines déploie les applications front-end avec les mêmes versions des applications conteneurisées déployées dans les deux environnements locaux Azure Stack HCI.
Les bases de données sont hébergées dans SQL Managed Instances avec Arc déployé sur AKS hybride.
Un développeur conditionne ses applications en tant que conteneur à déployer à la fois sur des clusters hybrides AKS à l’aide de manifestes Kubernetes et sur des modules AksHci PowerShell, et automatise les tâches de déploiement via Azure Pipelines.
Une requête du client adressée à l’application est dirigée par un service d’équilibreur de charge global tel qu’Azure Front Door ou Azure Traffic Manager, qui achemine la requête vers le point de terminaison de service approprié à l’aide d’une méthode d’acheminement du trafic pondérée. En fonction du pourcentage pondéré affecté, le trafic est distribué aux services déployés sur les deux clusters hybrides AKS sur Stack HCI.
Traffic Manager et Azure Front Door sont des options viables pour traiter les fonctionnalités d’équilibrage de charge globales en raison de la présence de clusters dans plusieurs régions. La sélection entre Azure Front Door et Traffic Manager dépend de différents facteurs, et la décision de recommander l’une plus que l’autre nécessite une considération minutieuse. Voici quelques raisons de prendre en compte différents services d’équilibrage de charge :
- Si vos applications internet utilisent HTTPS, alors Azure Front Door est l’option préférable. En règle générale, Traffic Manager n’est pas le premier choix dans ces instances. Bien qu’il puisse y avoir des exceptions, les scénarios spécifiques dépassent le cadre de cette discussion.
- Si votre objectif principal est d’équilibrer la charge globale de manière efficace, Traffic Manager peut être suffisant. Si vous avez également besoin d’une optimisation de la distribution de contenu, d’une sécurité de couche application et de fonctionnalités de routage plus avancées, Azure Front Door peut être plus adapté.
- Traffic Manager est plus simple à configurer et se concentre principalement sur l’équilibrage de charge. Azure Front Door offre plus de fonctionnalités, mais peut avoir une courbe d’apprentissage plus abrupte.
- Prenez en compte votre type d’application. Si elle est plus centrée sur le web et que vous avez besoin d’optimisations telles que la mise en cache et l’arrêt SSL, Azure Front Door peut être bénéfique.
- En ce qui concerne le routage basé sur DNS, la complexité diminue lorsqu’il s’agit de l’équilibrage de charge au niveau de l’application. Toutefois, il est essentiel de noter que s’appuyer uniquement sur le routage DNS peut entraîner un temps d’arrêt accru lors d’une défaillance, ce qui pourrait négativement affecter les contrats de niveau de service (SLA) de vos applications. La décision entre Azure Front Door et Traffic Manager doit prendre en compte le contrat de niveau de service de votre solution DNS et déterminer si votre application peut prendre en charge les temps de basculement différents entre les deux options.
Les applications de charge de travail déployées sont surveillées pour la charge à l’aide des services avec Azure Arc, d’Azure Monitor et de l’espace de travail Log Analytics.
Dans des conditions de charge normales, la requête du client est acheminée vers l’instance de l’application hébergée localement dans l’environnement Azure Stack HCI-1 (environnement de cluster principal).
Les charges de travail de cluster AKS avec Arc sont conçues pour effectuer une mise à l’échelle horizontale vers plusieurs instances à l’aide d’un générateur de mise à l’échelle automatique intégré, qui augmente ou diminue automatiquement le nombre de nœuds dans le cluster AKS déployé en fonction de la demande.
Container Insights est activé pour capturer les diagnostics et surveiller les performances de la charge de travail sur le cluster Kubernetes hébergé sur Azure Stack HCI.
Lorsqu’il y a une augmentation du trafic et que le cluster de charge de travail sur Azure Stack HCI-1 atteint son nombre maximal de nœuds sans options de mise à l’échelle de pods supplémentaires, il génère une alerte pour déclencher une application de fonction Azure.
Une règle d’alerte est configurée pour surveiller le résultat d’une requête Kusto personnalisée, qui recherche le nombre maximal de nœuds et le pourcentage de préparation des pods à partir des tables Azure Monitor KubeNodeInventory et KubePodInventory. Consultez Création d’alertes de journal à partir de Container Insights.
La supervision Kubernetes peut également être effectuée à l’aide de règles d’alerte préconfigurées à partir de Kubernetes Container Insights. Vous pouvez également appliquer les règles de mesures KubePodNotReady ou KubeHpaMaxedOut à partir de Container Insights pour configurer les conditions de règle d’alerte. Consultez Règles d’alerte de métrique dans Container Insights (préversion) et appelez l’application de fonction Azure via le groupe d’actions de l’alerte.
L’application de fonction Azure gère dynamiquement les règles d’acheminement du trafic pondérées en fonction de la condition du cluster principal et redirige le trafic vers le cluster Azure Stack HCI-2.
- Vous pouvez utiliser la fonction Azure pour calculer le pourcentage de trafic qui doit être redirigé en fonction des limites de seuil prédéfinies de préparation du cluster et des conditions de trafic. Cela peut vous aider à vous adapter rapidement aux modifications, à automatiser les tâches, à mettre à l’échelle efficacement les ressources et à économiser de l’argent.
- La fonction Azure permet de gérer dynamiquement les règles d’acheminement du trafic. Cette fonctionnalité garantit la haute disponibilité, la scalabilité et les performances, et offre une expérience utilisateur harmonieuse, même pendant les scénarios de pic de trafic et de basculement. Par exemple, la distribution initiale du trafic commence par diriger 100 % du trafic vers le cluster principal lorsqu’il fonctionne correctement et qu’il est en mesure de gérer la charge. Lorsque le cluster principal est presque complet ou subit une dégradation des performances, vous pouvez ajuster les règles d’acheminement du trafic dans la fonction Azure. Cela redirige une partie du trafic en lecture seule vers le cluster secondaire.
Les instances d’application s’exécutant sur les deux environnements de cluster se connectent localement aux services de données, tels que SQL Managed Instances avec Arc, dans leurs clusters respectifs.
La synchronisation des données entre les clusters pour SQL Managed Instances avec Arc est régie par le groupe de basculement Azure, qui utilise à son tour les groupes de disponibilité distribués. La synchronisation entre les clusters peut être synchrone ou asynchrone. Consultez SQL Managed Instance avec Azure Arc.
Dans l’ensemble, ce flux de travail implique la création et le déploiement d’applications, l’équilibrage de charge, la gestion du trafic, la mise à l’échelle automatique et la synchronisation des données dans plusieurs environnements de cluster. Cette configuration vous permet de mettre à l’échelle l’infrastructure horizontalement entre les clusters à deux centres de données ou emplacements différents, ce qui offre une sécurité, une redondance, une flexibilité et une utilisation efficace des ressources.
Composants
Azure Front Door est un équilibreur de charge de couche 7. Dans cette architecture, elle route les requêtes HTTP vers les applications web déployées sur le cluster Stack HCI. Vous pouvez également utiliser un pare-feu d’applications web (WAF) avec Azure Front Door qui protège l’application contre les codes malveillants exploitant une faille de sécurité et les vulnérabilités courantes, ainsi qu’une solution de réseau de distribution de contenu (CDN) dans cette conception afin de réduire la latence et d’améliorer le temps de chargement du contenu en mettant en cache le contenu aux emplacements de périphérie.
Traffic Manager est un équilibreur de charge de trafic basé sur le DNS et une option viable d’équilibrage de la charge. Utilisez-le pour contrôler la répartition du trafic de l’application pour les points de terminaison de service dans différents centres de données. Voici comment fonctionne la configuration de Traffic Manager :
- Configurez Traffic Manager, une solution d’équilibrage de charge globale dans Azure, pour distribuer le trafic entrant sur vos clusters Azure Stack HCI. Traffic Manager peut être configuré pour utiliser différentes méthodes d’équilibrage de charge, telles que les performances, le basculement ou le tourniquet pondéré, en fonction des besoins.
- Créez des points de terminaison Traffic Manager qui correspondent aux points de terminaison des charges de travail déployées sur les clusters Azure Stack HCI. Cela permet à Traffic Manager de diriger le trafic vers le point de terminaison approprié. Dans ce scénario, dirigez le trafic en fonction de la méthode d’équilibrage de charge d’acheminement pondérée.
- En fonction des stratégies de mise à l’échelle calculées par le biais d’une fonction Azure, lorsqu’il y a un besoin d’une capacité supplémentaire ou d’une haute disponibilité, Traffic Manager peut acheminer dynamiquement le trafic vers d’autres instances en fonction des règles d’acheminement et de leurs pourcentages pondérés.
Application Insights collecte des données de télémétrie à partir de différents composants déployés dans cette solution hybride. Des insights et des analyses sont fournis et peuvent être utilisés pour identifier les problèmes, optimiser les performances et améliorer l’expérience utilisateur.
Azure Functions agit comme orchestrateur pour la distribution du trafic. Il surveille les conditions de préparation de chaque cluster, en évaluant des facteurs tels que l’utilisation des ressources, la latence et l’intégrité. En fonction de cette évaluation, l’application de fonction décide où diriger le trafic entrant.
Azure Stack HCI est une solution de cluster d’infrastructure hyperconvergée (HCI) qui héberge des charges de travail Windows et Linux virtualisées et leur stockage dans un environnement hybride combinant une infrastructure locale avec des services Azure.
- La solution utilise Azure Kubernetes Service avec Arc sur Azure Stack HCI (AKS-HCI) pour héberger l’application web ou des API, des serveurs Azure avec Arcet des services de données avec Arc dans les deux environnements.
Azure DevOps Services sert de base pour cette stratégie de déploiement de solution hybride, fournissant l’automatisation et l’orchestration nécessaires pour simplifier l’ensemble du cycle de vie de la livraison de logiciels. Cela permet aux équipes de développement de se concentrer sur la livraison de code de haute qualité pendant que le pipeline s’occupe de la création, du test et du déploiement d’applications.
Pour déployer un cluster AKS sur Azure Stack HCI, vous pouvez configurer un serveur de build dans Azure Pipelines. Le serveur de build est responsable de l’exécution du processus de déploiement.
a. Créez une machine virtuelle dans Azure ou une machine virtuelle à partir de l’environnement Stack HCI. Vous pouvez également utiliser une machine virtuelle locale existante comme serveur de build si elle dispose d’une connectivité réseau aux infrastructures hybrides.
b. Installez les outils nécessaires sur le serveur de build, tels que Git, Azure CLI et les modules Azure PowerShell.
c. Configurez l’authentification auprès d’Azure en configurant des principaux de service ou en utilisant des identités managées.
Azure Pipelines est un service qui fournit une intégration continue et une livraison continue et gère les agents et définitions de build et de mise en production hébergés. Le pipeline de développement peut utiliser divers référentiels de code, notamment GitHub, Bitbucket, Dropbox, OneDrive et Azure Repos.
Azure Monitor collecte les données de télémétrie et surveille les performances des clusters et des charges de travail. Il vous permet également de configurer des alertes pour déclencher une fonction Azure ou pour notifier un administrateur si un cluster devient défectueux ou si des seuils prédéfinis sont dépassés. Vous pouvez utiliser Azure Automation ou Azure Logic Apps pour automatiser les actions de mise à l’échelle en fonction des données de surveillance.
Azure Policy agit en tant qu’application de gouvernance et de conformité, garantissant que les clusters Stack HCI et les ressources SDN associées fonctionnent dans les directives et normes définies. Voici quelques exemples pour améliorer la sécurité de l’environnement via Azure Policy :
- Application d’un module complémentaire Container Insight
- Installation d’extensions essentielles dans des clusters Stack HCI
- Application de l’identification des ressources
- Contrôle d’accès en fonction de la stratégie
- Stratégies liées à la mise en réseau et à la surveillance
Azure Container Registry est un service de registre Docker privé et managé disponible sur Azure. Utilisez le registre de conteneurs pour stocker les images Docker privées, qui sont déployées sur le cluster.
Azure Arc étend les services Azure aux environnements locaux, ce qui permet aux organisations de tirer parti des fonctionnalités cloud tout en conservant les données sensibles au sein de leur propre infrastructure.
Container Insights est une solution de supervision et d’observabilité fournie par Azure Monitor qui vous permet d’obtenir des insights sur les performances et l’intégrité des conteneurs s’exécutant dans des clusters AKS. Avec Azure Arc activé pour AKS, vous pouvez étendre les fonctionnalités de Container Insights pour surveiller et gérer vos clusters AKS qui s’exécutent en dehors d’Azure, tels que pour les environnements locaux ou multiclouds.
SQL Managed Instances avec Arc est un service de données Azure SQL qui peut être créé sur l’infrastructure Stack HCI et géré à l’aide d’Azure Arc.
Azure Key Vault vous permet de stocker et de gérer en toute sécurité les clés de chiffrement, les secrets et les certificats. Bien qu’Azure Key Vault soit principalement un service cloud, il peut également être utilisé avec les déploiements Azure Stack HCI pour stocker et gérer localement des informations sensibles en toute sécurité.
Infrastructure SDN. Dans un déploiement hybride AKS sur Azure Stack HCI, l’équilibrage de charge est réalisé via le SDN Software Load Balancer (SLB). SLB gère l’infrastructure et les applications AKS-HCI au sein du réseau virtuel SDN (mise en réseau à définition logicielle), y compris les ressources d’infrastructure réseau SDN nécessaires, telles que les machines virtuelles de l’équilibreur de charge Mux, les machines virtuelles de passerelle et les contrôleurs réseau.
Vous trouverez ci-dessous une décomposition des composants impliqués :
- L’équilibreur de charge logiciel (SLB) : il s’agit d’un composant clé de l’infrastructure AKS-HCI qui fournit des fonctionnalités d’équilibrage de charge pour distribuer le trafic réseau aux applications en cours d’exécution sur le cluster. Il fonctionne au niveau de la couche de transport (couche 4) et dirige le trafic en fonction des règles configurées.
- Les machines virtuelles de l’équilibreur de charge Mux : il s’agit de machines virtuelles qui gèrent le trafic réseau entrant provenant de sources externes et les distribuent aux pods ou services principaux appropriés au sein du cluster AKS-HCI. Elles fonctionnent avec SLB pour effectuer l’équilibrage de charge.
- Les machines virtuelles de passerelle : elles fournissent une connectivité entre le cluster AKS-HCI et les réseaux externes. Elles agissent comme un pont entre le réseau virtuel SDN interne et les réseaux externes, ce qui permet au trafic d’entrée et de sortie de circuler en toute sécurité.
- Les contrôleurs de réseau : ils sont responsables de la gestion de l’infrastructure SDN au sein du cluster AKS-HCI. Ils gèrent des tâches telles que l’application de stratégie réseau, la configuration réseau et la configuration de l’équilibreur de charge.
En utilisant SLB, les machines virtuelles de l’équilibreur de charge Mux, les machines virtuelles de passerelle et les contrôleurs de réseau, AKS-HCI permet d’équilibrer la charge pour les déploiements hybrides. Cela garantit que le trafic réseau entrant est distribué efficacement entre les applications exécutées au sein du cluster, ce qui offre une haute disponibilité et une scalabilité.
Remarque
Ces composants sont gérés et configurés par AKS-HCI, ce qui vous permet de vous concentrer sur le déploiement et la gestion de vos applications tout en utilisant les fonctionnalités intégrées d’équilibrage de charge de la plateforme.
Autres solutions
Pour les services d’application web et d’événements, vous pouvez exécuter App Service, Functions et Logic Apps sur un cluster Kubernetes avec Azure Arc hébergé sur Azure Stack HCI. Pour la base de données, vous pouvez utiliser une autre option de stockage telle que le serveur PostgreSQL avec Azure Arc.
Pour les applications web, vous pouvez utiliser Azure Front Door. Azure Front Door fonctionne au niveau de la couche 7, c’est-à-dire la couche HTTP/HTTPS. Il utilise le protocole anycast avec le TCP fractionné et le réseau mondial Microsoft afin d’améliorer la connectivité globale. Selon votre méthode de routage, vous pouvez faire en sorte qu’Azure Front Door route vos demandes clientes vers le back-end d’application offrant les plus hautes performances et la meilleure disponibilité.
Vous pouvez utiliser Azure ExpressRoute pour connecter votre réseau local directement aux ressources Azure à l’aide d’une connexion réseau privé dédiée.
Si votre référentiel est en GitHub, vous pouvez utiliser GitHub Actions au lieu d’Azure Pipelines.
Détails du scénario
L’objectif principal est de faciliter la mise à l’échelle entre clusters en répartissant efficacement les charges de travail entre les clusters situés dans deux centres de données ou emplacements différents. Cette approche empêche la surcharge de tout cluster unique et optimise l’utilisation des ressources sur tous les clusters. L’application de fonction Azure joue un rôle essentiel dans la répartition intelligente du trafic en fonction des conditions de préparation du cluster, améliorant ainsi l’efficacité, la scalabilité, la disponibilité et les performances.
Ce scénario s’applique aux organisations qui utilisent un ensemble strict de contraintes, de réglementations en matière de souveraineté des données ou de résilience cruciale et des besoins de continuité de l’activité, ou qui gèrent des charges de travail critiques dans des environnements hautement restreints et réglementés tels que des banques, des établissements de finance, de défense ou gouvernementaux. En raison des stratégies réglementaires et de conformité des organisations, les applications et les bases de données s’exécutent localement pour empêcher l’exposition de données confidentielles ou sensibles dans le cloud public. Cette solution est utile dans les situations suivantes :
Les applications locales rencontrent des pics d’utilisation pendant la période de pointe et la mise à l’échelle automatique au sein du cluster, mais le cluster principal atteint une capacité de 100 % et souhaite rediriger le trafic de dépassement vers un autre cluster de centre de données sans interrompre les exécutions de service.
Vous souhaitez résoudre automatiquement la réacheminement du trafic d’application/d’API vers l’environnement local disponible le plus proche.
Vous souhaitez simplifier la gouvernance et la gestion de la configuration locale et accéder aux services cloud pertinents qui sont filtrés via un pare-feu ou un serveur proxy de manière cohérente et sécurisée via les services avec Azure Arc déployés sur Azure Stack HCI.
Cas d’usage potentiels
- Vous souhaitez implémenter des charges de travail hautement disponibles, évolutives, sécurisées et restreintes dans un environnement de cluster Azure Stack HCI local.
- Vous souhaitez une mise à l’échelle dynamique des applications en cours d’exécution entre les centres de données à chaque fois que les applications locales rencontrent des pics dans leurs utilisations.
- Vous souhaitez appliquer l’automatisation basée sur le cloud avec une gestion, une gouvernance et une supervision centralisées.
- Vous disposez de composants locaux et souhaitez utiliser une autre configuration locale pour les mettre à l'échelle.
- Vous souhaitez une scalabilité dynamique entre clusters pour exécuter vos applications localement jusqu’au moment où vous pouvez étendre la mise à l’échelle de vos charges de travail vers des instances cloud.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Une entreprise peut adopter une approche hybride pour maintenir ses systèmes en conservant localement des applications et des ressources pour des raisons réglementaires et de performances. Si elle souhaite appliquer des fonctionnalités cloud Azure, elle peut déployer la même version d’applications hébergées sur un cluster Azure HCI dans plusieurs régions. Cela répond à sa conformité des services hautement disponibles et évolutifs.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Lors du déploiement d’AKS-HCI, il est essentiel de prendre en compte les pratiques de sécurité pour protéger vos applications et votre infrastructure. Voici quelques considérations clés relatives à la sécurité pour AKS-HCI :
Sécuriser l’accès au cluster
- Limitez l’accès au cluster AKS-HCI en suivant le principe des privilèges minimum. Accordez uniquement les autorisations nécessaires aux utilisateurs, aux groupes ou aux comptes de service.
- Utilisez des mécanismes d’authentification forts, tels que l’intégration de Microsoft Entra, Microsoft Entra Pod Identity ou le contrôle d’accès en fonction du rôle Kubernetes (Kubernetes RBAC) pour contrôler l’accès au cluster et à ses ressources.
- Envisagez d’implémenter l’authentification multifacteur (MFA) pour l’accès au cluster afin d’ajouter une couche de sécurité supplémentaire.
Sécurité du réseau
- Implémentez la segmentation et l’isolation du réseau au sein du cluster AKS-HCI à l’aide de stratégies réseau Kubernetes ou de groupes de sécurité réseau Azure.
- Contrôlez le trafic entrant et sortant avec des pare-feu au niveau du réseau, tels que le Pare-feu Azure, et limitez l’accès en fonction de la liste verte d’adresses IP ou du peering de réseau virtuel.
- Chiffrez le trafic réseau entre les services à l’aide de l’authentification TLS (Transport Layer Security) ou de l’authentification mutuelle TLS (mTLS).
Sécurité de l’image de conteneur
- Utilisez des images conteneur sécurisées à partir de sources approuvées et mettez-les régulièrement à jour avec les derniers correctifs de sécurité et de vulnérabilité.
- Implémentez des outils d’analyse d’images et d’évaluation des vulnérabilités pour identifier et corriger les problèmes de sécurité dans les images conteneur.
- Utilisez les mécanismes de signature et de vérification des images conteneur pour garantir l’intégrité et l’authenticité des images.
Gestion des secrets
- Évitez de coder en dur les informations sensibles (telles que les mots de passe, les clés API ou les chaînes de connexion) dans le code ou les fichiers de configuration de votre application.
- Utilisez Azure Key Vault ou une solution de gestion des secrets sécurisée pour stocker et récupérer des informations sensibles en toute sécurité.
- Utilisez des secrets Kubernetes ou l’intégration d’Azure Key Vault pour injecter des secrets en toute sécurité dans vos conteneurs d’applications.
Journalisation et supervision
- Implémentez la journalisation et la surveillance centralisées pour les clusters AKS-HCI à l’aide d’Azure Monitor ou de solutions tierces.
- Configurez les journaux d’audit, les journaux de conteneur et les journaux système pour capturer les événements de sécurité critiques.
- Configurez des mécanismes d’alerte et de notification pour détecter et répondre de manière proactive aux incidents ou anomalies de sécurité.
Mises à jour et mise à jour corrective régulières
- Conservez les nœuds de cluster AKS-HCI et l’infrastructure sous-jacente à jour avec les derniers correctifs et mises à jour de sécurité.
- Établissez un processus de gestion des correctifs pour garantir l’application ponctuelle des correctifs de sécurité.
Considérations relatives à la conformité et aux réglementations
- Comprendre et respecter les réglementations de sécurité et de conformité spécifiques au secteur d’activité (telles que HIPAA ou PCI DSS) en fonction des exigences de votre organisation.
- Implémentez des contrôles et des pratiques de sécurité pour respecter les normes de conformité applicables à votre secteur d’activité.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Quelques considérations relatives à l’optimisation des coûts pour le déploiement de services avec Arc sur Azure Stack HCI :
- Dimensionnez correctement les nœuds de cluster AKS-HCI en fonction des exigences de charge de travail réelles pour éviter le surapprovisionnement ou la sous-utilisation.
- La mise à l’échelle automatique AKS-HCI permet d’optimiser l’allocation des ressources et de réduire les coûts pendant les périodes de faible demande. Configurez la mise à l’échelle horizontale automatique des pods (HPA) en fonction des modèles de demande et de charge de travail pour mettre automatiquement à l’échelle le nombre de pods dans votre cluster AKS-HCI.
- Optimisation du stockage :
- Choisissez les options de stockage appropriées en fonction des vos exigences de charge de travail et de vos besoins en matière de performances.
- Envisagez d’utiliser Stockage disque Azure pour les volumes persistants ou Azure Files pour le stockage de fichiers partagés.
- Optimisez les configurations de stockage, telles que l’ajustement de la taille et du type de disques en fonction des demandes de charge de travail.
- Gestion des groupes de ressources et d’étiquetage :
- Implémentez l’étiquetage cohérent des ressources pour suivre et classer les ressources.
- Utilisez des groupes de ressources pour organiser logiquement les ressources, ce qui facilite la gestion et le suivi des coûts.
- Supervision et optimisation continues des coûts :
- Passez régulièrement en revue les rapports de coûts et les tableaux de bord fournis par Microsoft Cost Management pour identifier les opportunités d’économie de coûts et optimiser les dépenses.
- Utilisez des outils comme Azure Advisor pour recevoir des suggestions afin d’optimiser l’utilisation des ressources, améliorer la sécurité et réduire les coûts.
- Réduisez les efforts de déploiement et de maintenance avec Azure DevOps Services.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
L’avantage majeur de la mise à l’échelle entre clusters est la possibilité de fournir une mise à l’échelle à la demande avec des environnements locaux, ainsi qu’un contrôle total sur la configuration au sein du réseau sécurisé de votre organisation.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
Mayuri Bhavsar | Architecte de solutions cloud senior
Vidya Narasimhan | Architecte de solutions cloud principal
Autres contributeurs :
Himanshu Amodwala | Architecte de solutions cloud senior
Nakul Joshi | Responsable principal de l’ingénierie logicielle
Vineeth Marar | Architecte de solutions cloud senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Modèle Kubernetes à haute disponibilité avec Azure et Azure Stack Hub
- Documentation Azure Kubernetes Service (AKS)