Share via

Modélisation d’intégrité pour les charges de travail stratégiques

  • Article

La surveillance des applications et de l’infrastructure constitue une partie importante des déploiements d’infrastructure. Pour une charge de travail stratégique, la surveillance constitue une partie essentielle du déploiement. La surveillance de l’intégrité des applications et des métriques clés des ressources Azure vous permet de comprendre si l’environnement fonctionne comme prévu.

Pour comprendre pleinement ces métriques et évaluer l’intégrité d’une charge de travail, il est nécessaire d’avoir une compréhension globale de toutes les données surveillées. Un modèle d’intégrité peut aider à évaluer l’état d’intégrité global en affichant une indication claire de l’intégrité de la charge de travail plutôt que des métriques brutes. L’état est souvent présenté sous la forme d’indicateurs de type feu tricolore (par exemple, rouge, vert ou jaune). La représentation d’un modèle d’intégrité avec des indicateurs clairs permet à un opérateur de cerner l’intégrité globale de la charge de travail et de répondre rapidement aux problèmes qui surviennent.

La modélisation d’intégrité peut être développée dans les tâches opérationnelles suivantes à des fins de déploiement stratégique :

  • Service de contrôle d’intégrité des applications : composant d’application sur le cluster de calcul qui fournit une API pour déterminer l’intégrité d’une empreinte.

  • Surveillance : collecte des compteurs de performance et d’application qui évaluent l’intégrité et les performances de l’application et de l’infrastructure.

  • Alertes : alertes actionnables relatives aux problèmes et interruptions dans l’infrastructure et l’application.

  • Analyse des défaillances : répartition et analyse des défaillances, y compris la documentation de la cause racine.

Ces tâches constituent un modèle d’intégrité complet pour l’infrastructure stratégique. Le développement d’un modèle d’intégrité peut et doit faire partie intégrante et exhaustive de tout déploiement stratégique.

Pour plus d’informations, consultez Modélisation d’intégrité et observabilité des charges de travail critiques sur Azure.

Service de contrôle d’intégrité des applications

Le service de contrôle d’intégrité des applications (HealthService) est un composant d’application qui réside avec le service de catalogue (CatalogService) et le processeur en arrière-plan (BackgroundProcessor) au sein du cluster de calcul. HealthService fournit une API REST pour Azure Front Door à appeler pour déterminer l’intégrité d’une empreinte. HealthService est un composant complexe qui reflète l’état des dépendances, en plus du sien.

Lorsque le cluster de calcul est en panne, le service de contrôle d’intégrité ne répond pas. Lorsque les services sont en cours d’exécution, il effectue des vérifications périodiques sur les composants suivants de l’infrastructure :

  • Il tente d’effectuer une requête sur Azure Cosmos DB.

  • Il tente d’envoyer un message à Event Hubs. Le message est filtré par le worker en arrière-plan.

  • Il recherche un fichier d’état dans le compte de stockage. Ce fichier peut être utilisé pour désactiver une région, même si les autres vérifications continuent de fonctionner correctement. Ce fichier peut être utilisé pour communiquer avec d’autres processus. Par exemple, si l’empreinte doit être libérée à des fins de maintenance, le fichier peut être supprimé afin de forcer un état défectueux et de rediriger le trafic.

  • Il interroge le modèle d’intégrité pour déterminer si toutes les métriques opérationnelles se trouvent dans les seuils prédéterminés. Lorsque le modèle d’intégrité indique que l’empreinte n’est pas saine, le trafic ne doit pas être routé vers l’empreinte, même si les autres tests effectués par HealthService sont retournés correctement. Le modèle d’intégrité prend en compte une vue plus complète de l’état d’intégrité.

Tous les résultats de vérification d’intégrité sont mis en cache en mémoire pendant un nombre configurable de secondes (par défaut, 10). Si cette opération ajoute potentiellement une petite latence dans le cadre de la détection des pannes, elle garantit que toutes les requêtes HealthService ne nécessitent pas des appels back-end, ce qui réduit la charge sur le cluster et les services en aval.

Ce modèle de mise en cache est important, car le nombre de requêtes HealthService augmente considérablement lors de l’utilisation d’un routeur global comme Azure Front Door. Chaque nœud de périphérie de chaque centre de données Azure qui sert les demandes appelle le service de contrôle d’intégrité pour déterminer s’il dispose d’une connexion back-end fonctionnelle. La mise en cache des résultats réduit la charge de cluster supplémentaire générée par les contrôles d’intégrité.

Configuration

HealthService et CatalogService ont des paramètres de configuration communs entre les composants, à l’exception des paramètres suivants utilisés exclusivement par HealthService :

Paramètre Valeur
HealthServiceCacheDurationSeconds Contrôle le délai d’expiration du cache en mémoire, en secondes.
HealthServiceStorageConnectionString Chaîne de connexion pour le compte de stockage où le fichier d’état doit être présent.
HealthServiceBlobContainerName Conteneur de stockage où le fichier d’état doit être présent.
HealthServiceBlobName Nom du fichier d’état : le contrôle d’intégrité recherchera ce fichier.
HealthServiceOverallTimeoutSeconds Délai d’expiration pour l’ensemble du contrôle (par défaut, 3 secondes). Si le contrôle ne se termine pas dans cet intervalle, le service signale un état défectueux.

Implémentation

Tous les contrôles sont effectués de manière asynchrone et en parallèle. Si l’un d’entre eux échoue, l’intégralité de l’empreinte est considérée comme indisponible.

Les résultats du contrôle sont mis en cache en mémoire, avec l’objet ASP.NET Core MemoryCache non distribué standard. L’expiration du cache est contrôlée par SysConfig.HealthServiceCacheDurationSeconds et est définie sur 10 secondes par défaut.

Notes

Le paramètre de configuration SysConfig.HealthServiceCacheDurationSeconds réduit la charge supplémentaire générée par les contrôles d’intégrité, car toutes les demandes ne généreront pas un appel en aval aux services dépendants.

Le tableau suivant détaille les contrôles d’intégrité appliqués aux composants de l’infrastructure :

Composant Contrôle d’intégrité
Compte de stockage - Objets blob Le contrôle d’objet blob sert actuellement à deux fins :
1. Testez s’il est possible d’atteindre le stockage blob. Le compte de stockage est utilisé par d’autres composants de l’empreinte et est considéré comme une ressource critique.
2. Désactiver manuellement une région en supprimant le fichier d’état.
Il a été décidé que le contrôle ne rechercherait que la présence d’un fichier d’état dans le conteneur d’objets blob spécifié. Le contenu du fichier n’est pas traité. Il est possible de configurer un système plus sophistiqué qui lit le contenu du fichier et retourne un état différent en fonction du contenu du fichier.
HEALTHY, UNHEALTHY et MAINTENANCE sont des exemples de contenu.
La suppression du fichier d’état désactive l’empreinte. Vérifiez que le fichier d’intégrité est présent après le déploiement de l’application. L’absence du fichier d’intégrité entraîne toujours une réponse UNHEALTHY du service. Front Door ne reconnaît pas le back-end comme disponible.
Le fichier est créé par Terraform et doit être présent après le déploiement de l’infrastructure.
Event Hub Les rapports d’intégrité Event Hubs sont gérés par le EventHubProducerService. Ce service signale un état sain s’il est en mesure d’envoyer un nouveau message à Event Hubs. À des fins de filtrage, ce message a une propriété d’identification qui lui est ajoutée :
HEALTHCHECK=TRUE
Ce message est ignoré à l’extrémité de réception. Le paramètre de configuration AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() recherche la propriété HEALTHCHECK.
Azure Cosmos DB Les rapports d’intégrité Azure Cosmos DB sont gérés par le CosmosDbService, qui signale un état sain avec la valeur :
1. Possibilité de se connecter à la base de données Azure Cosmos DB et d’effectuer une requête.
2. Possibilité d’écrire un document de test dans la base de données.
Le document de test a une durée de vie courte définie, Azure Cosmos DB le supprime automatiquement.
HealthService effectue deux sondages distincts. Si Azure Cosmos DB est dans un état où les lectures fonctionnent mais pas les écritures, les deux sondages garantissent qu’une alerte est déclenchée.

Requêtes Azure Cosmos DB

Pour la requête en lecture seule, la requête suivante, qui n’extrait aucune donnée et n’a pas d’effet important sur la charge globale, est utilisée :

SELECT GetCurrentDateTime ()

La requête d’écriture crée un ItemRating factice avec un contenu minimal :

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Surveillance

Azure Log Analytics est utilisé comme magasin central des journaux et métriques pour tous les composants d’application et d’infrastructure. Azure Application Insights est utilisé pour toutes les données de surveillance des applications. Chaque empreinte dans l’infrastructure a un espace de travail Log Analytics dédié et une instance Application Insights. Un espace de travail Log Analytics distinct est utilisé pour les ressources partagées globalement telles que Front Door et Azure Cosmos DB.

Toutes les empreintes sont de courte durée et sont remplacées en continu par chaque nouvelle version. Les espaces de travail Log Analytics par empreinte sont déployés en tant que ressource globale dans un groupe de ressources de surveillance distinct en tant que ressources Log Analytics d’empreinte. Ces ressources ne partagent pas le cycle de vie d’une empreinte.

Pour plus d’informations, consultez Récepteur de données unifié pour l’analyse corrélée.

Surveillance : sources de données

  • Paramètres de diagnostic : tous les services Azure utilisés pour Azure Mission-Critical sont configurés pour envoyer toutes leurs données de diagnostic, y compris les journaux et métriques de l’espace de travail Log Analytics (global ou empreinte) spécifique au déploiement. Ce processus se produit automatiquement dans le cadre du déploiement de Terraform. De nouvelles options seront identifiées automatiquement et ajoutées dans le cadre de terraform apply.

  • Surveillance Kubernetes : les paramètres de diagnostic sont utilisés pour envoyer des journaux et métriques AKS à Log Analytics. AKS est configuré pour utiliser Container Insights. Container Insights déploie OMSAgentForLinus via un DaemonSet Kubernetes sur chaque nœud dans les clusters AKS. OMSAgentForLinux peut collecter des journaux et des métriques supplémentaires à partir du cluster Kubernetes et les envoie à son espace de travail Log Analytics correspondant. Ceux-ci contiennent des données plus granulaires sur les pods, les déploiements, les services et l’intégrité globale du cluster. Pour plus d’informations sur les différents composants tels que ingress-nginx, cert-manager et d’autres composants déployés sur Kubernetes en regard de la charge de travail critique, il est possible d’utiliser le scraping de Prometheus. Celui-ci configure OMSAgentForLinux afin de scraper les métriques Prometheus de différents points de terminaison au sein du cluster.

  • Télémétrie Application Insights : Application Insights permet de recueillir des données de télémétrie auprès de l’application. Le code a été instrumenté pour collecter des données sur les performances de l’application avec le Kit de développement logiciel (SDK) Application Insights. Les informations critiques, telles que le code d’état résultant et la durée des appels de dépendance et des compteurs pour les exceptions non gérées, sont collectées. Ces informations sont utilisées dans le modèle d’intégrité et sont disponibles pour la génération des alertes et la résolution des problèmes.

Surveillance : tests de disponibilité d’Application Insights

Pour surveiller la disponibilité des empreintes individuelles et la solution globale d’un point de vue extérieur, les tests de disponibilité d’Application Insights sont configurés à deux emplacements :

  • Tests de disponibilité régionale : ces tests sont configurés dans les instances Application Insights régionales et sont utilisés pour surveiller la disponibilité des empreintes. Ces tests ciblent directement les clusters et les comptes de stockage statiques des empreintes. Pour appeler les points d’entrée des clusters directement, les demandes doivent porter l’en-tête d’ID Front Door correct, sinon elles sont rejetées par le contrôleur d’entrée.

  • Test de disponibilité globale : ces tests sont configurés dans l’instance d’Application Insights globale et sont utilisés pour surveiller la disponibilité de la solution globale en effectuant un test ping sur Front Door. Deux tests sont utilisés : un pour tester un appel d’API sur CatalogService et un pour tester la page d’accueil du site web.

Surveillance : requêtes

Azure Mission-Critical utilise différentes requêtes KQL (Langage de requête Kusto) pour implémenter des requêtes personnalisées en tant que fonctions pour récupérer des données à partir de Log Analytics. Ces requêtes sont stockées en tant que fichiers individuels dans notre référentiel de code, séparés pour les déploiements globaux et d’empreinte. Ils sont importés et appliqués automatiquement via Terraform dans le cadre de chaque exécution du pipeline d’infrastructure.

Cette approche sépare la logique de requête de la couche de visualisation. Les requêtes Log Analytics sont appelées directement à partir du code, par exemple à partir de l’API HealthService. Un autre exemple provient d’un outil de visualisation tel que les tableaux de bord Azure, les classeurs Monitor ou Grafana.

Surveillance : visualisation

Pour visualiser les résultats de nos requêtes d’intégrité Log Analytics, nous avons utilisé Grafana dans notre implémentation de référence. Grafana est utilisé pour afficher les résultats des requêtes Log Analytics et ne contient aucune logique lui-même. La pile Grafana ne fait pas partie du cycle de vie de déploiement de la solution (elle est publiée séparément).

Pour plus d’informations, consultez Visualisation.

Génération d’alertes

Les alertes sont une partie importante de la stratégie opérationnelle globale. Une surveillance proactive telle que l’utilisation de tableaux de bord doit être utilisée avec des alertes qui attirent immédiatement l’attention sur les problèmes.

Ces alertes forment une extension du modèle d’intégrité, en alertant l’opérateur des changements de l’état d’intégrité, soit vers l’état dégradé/jaune, soit vers l’état non sain/rouge. En définissant l’alerte sur le nœud racine du modèle d’intégrité, l’opérateur est immédiatement conscient de tout impact sur l’état de la solution. Ce nœud racine devient jaune ou rouge si l’un des flux d’utilisateurs ou ressources sous-jacents indique des métriques jaune ou rouge. L’opérateur peut diriger son attention vers la visualisation du modèle d’intégrité à des fins de résolution des problèmes.

Pour plus d’informations, consultez Réponse automatique aux incidents.

Analyse des défaillances

La composition de l’analyse des défaillances est principalement un exercice de planification théorique. Cet exercice théorique doit être utilisé comme entrée pour les injections de défaillance automatisées qui font partie du processus de validation continue. En simulant les modes d’échec définis ici, nous pouvons valider la résilience de la solution contre ces échecs pour s’assurer qu’ils n’occasionneront pas des pannes.

Le tableau suivant répertorie les exemples de cas de défaillance des différents composants de l’implémentation de référence Azure Mission-Critical.

Service Risque Impact/Atténuation/Commentaire Outage
Microsoft Entra ID Microsoft Entra ID devient indisponible. Actuellement, aucune atténuation possible n’est en place. Une approche multirégion ne permet pas d’atténuer les pannes car il s’agit d’un service global. Ce service est une dépendance dure. Microsoft Entra ID est utilisé pour les opérations de plan de contrôle telles que la création de nouveaux nœuds AKS, l’extraction d’images conteneur à partir depuis ACR ou l’accès à Key Vault au démarrage du pod. Il est attendu que les composants exécutés existants soient en mesure de continuer à s’exécuter si Microsoft Entra ID rencontre des problèmes. Il est probable que de nouveaux pods ou nœuds AKS ne pourront pas être générés. Si des opérations de mise à l’échelle sont nécessaires pendant ce temps, cela peut entraîner une dégradation de l’expérience utilisateur et potentiellement des pannes. Partial
DNS Azure Azure DNS devient indisponible et la résolution DNS échoue. Si Azure DNS devient indisponible, il est probable que la résolution DNS pour les demandes utilisateur et entre différents composants de l’application échoueront. Actuellement, aucune atténuation possible n’est en place pour ce scénario. Une approche multirégion ne permet pas d’atténuer les pannes car il s’agit d’un service global. Azure DNS est une dépendance dure. Les services DNS externes comme sauvegarde ne seraient d’aucune aide, car tous les composants PaaS utilisés reposent sur Azure DNS. Il n’est pas possible de contourner le DNS en basculant vers l’adresse IP. Les services Azure n’ont pas d’adresses IP statiques et garanties. Complète
Front Door Panne générale de Front Door. Si Front Door tombe entièrement en panne, aucune atténuation n’est possible. Ce service est une dépendance dure. Oui
Front Door Erreurs de configuration du routage/front-end/back-end. Peut se produire en raison d’une incompatibilité dans la configuration lors du déploiement. Doit être détecté en phases de test. La configuration du front-end avec DNS est spécifique à chaque environnement. Atténuation : la restauration vers la configuration précédente doit résoudre la plupart des problèmes.. Comme le déploiement des modifications prend quelques minutes dans Front Door, cela entraîne une panne. Complète
Front Door Le certificat TLS/SSL managé est supprimé. Peut se produire en raison d’une incompatibilité dans la configuration lors du déploiement. Doit être détecté en phases de test. Techniquement, le site fonctionne toujours, mais les erreurs de certificat TLS/SSL empêchent les utilisateurs d’y accéder. Atténuation : la réécriture du certificat peut prendre environ 20 minutes, ainsi que la correction et la réécriture du pipeline.. Complète
Azure Cosmos DB La base de données/collection est renommée. Peut se produire en raison d’une incompatibilité dans la configuration lors du déploiement. Terraform remplacerait la base de données entière, ce qui pourrait entraîner la perte de données. La perte de données peut être évitée à l’aide de verrous au niveau de la base de données/collection. L’application ne pourra accéder à aucune donnée. La configuration de l’application doit être mise à jour et les pods redémarrés. Oui
Azure Cosmos DB Panne régionale Les écritures multirégions sont activées dans Azure Mission-Critical. S’il y a un échec sur une lecture ou une écriture, le client réitère l’opération en cours. Toutes les opérations ultérieures sont acheminées de manière permanente vers la région suivante par ordre de préférence. Si la liste de préférences ne comportait qu’une seule entrée (ou si elle était vide), mais que le compte a d’autres régions disponibles, elle sera routée vers la région suivante dans la liste du compte. Non
Azure Cosmos DB Limitation étendue en raison d’un manque d’unités de requête. Selon le nombre d’unités de requête et l’équilibrage de charge employés au niveau de Front Door, certaines empreintes peuvent s’exécuter à chaud sur l’utilisation d’Azure Cosmos DB, tandis que d’autres empreintes peuvent traiter plus de demandes. Atténuation : meilleure distribution de charge ou plus d’unités de requête. Non
Azure Cosmos DB Partition complète La limite de taille de la partition logique Azure Cosmos DB est de 20 Go. Si les données d’une clé de partition au sein d’un conteneur atteignent cette taille, les demandes d’écriture supplémentaires échouent avec l’erreur « La clé de partition a atteint la taille maximale ». Partiel (écritures de base de données désactivées)
Azure Container Registry Panne régionale Le registre de conteneurs utilise Traffic Manager pour basculer entre les régions de réplica. Toute requête doit être routée automatiquement vers une autre région. Au pire, les images Docker ne peuvent pas être extraites pendant quelques minutes par les nœuds AKS pendant que le basculement DNS se produit. Non
Azure Container Registry Image(s) supprimée(s) Aucune image ne peut être extraite. Cette panne ne doit affecter que les nœuds nouvellement générés/redémarrés. Les nœuds existants doivent avoir les images mises en cache. **Atténuation : si le problème est détecté rapidement, la réexécution des pipelines de build les plus récents doit ramener les images dans le Registre. Non
Azure Container Registry Limitation La limitation peut retarder les opérations de scale-out qui peuvent entraîner une dégradation temporaire des performances. Atténuation : Azure Mission-Critical utilise la référence SKU Premium qui fournit 10 000 opérations de lecture par minute. Les images conteneur sont optimisées et n’ont que de petits nombres de couches. ImagePullPolicy est défini sur IfNotPresent pour utiliser d’abord les versions mises en cache localement. Commentaire : L’extraction d’une image conteneur se compose de plusieurs opérations de lecture, en fonction du nombre de couches. Le nombre d’opérations de lecture par minute est limité et dépend de la taille de la référence SKU ACR. Non
Azure Kubernetes Service Échec de la mise à niveau du cluster Les mises à niveau des nœuds AKS doivent se produire à différents moments entre les empreintes. Si une mise à niveau échoue, l’autre cluster ne doit pas être affecté. Les mises à niveau de cluster doivent être déployées de manière propagée sur les nœuds pour empêcher tous les nœuds de devenir indisponibles. Non
Azure Kubernetes Service Le pod d’application est tué lors du traitement de la demande. Cela peut entraîner des erreurs à l’utilisateur final et une mauvaise expérience utilisateur. Atténuation: Kubernetes supprime par défaut les pods de manière appropriée. Les pods sont supprimés d’abord des services et la charge de travail reçoit un SIGTERM avec une période de grâce pour terminer les demandes ouvertes et écrire des données avant de se terminer. Le code de l’application doit comprendre SIGTERM et la période de grâce peut avoir besoin d’être ajusté si la charge de travail prend plus de temps pour s’arrêter. Non
Azure Kubernetes Service Capacité de calcul indisponible dans la région pour ajouter d’autres nœuds. Les opérations de scale-up/out échouent, mais elles ne doivent pas affecter les nœuds existants et leur fonctionnement. Dans l’idéal, le trafic doit être migré automatiquement vers d’autres régions à des fins d’équilibrage de la charge. Non
Azure Kubernetes Service L’abonnement atteint le quota de cœurs d’UC pour ajouter de nouveaux nœuds. Les opérations de scale-up/out échouent, mais elles ne doivent pas affecter les nœuds existants et leur fonctionnement. Dans l’idéal, le trafic doit être migré automatiquement vers d’autres régions à des fins d’équilibrage de la charge. Non
Azure Kubernetes Service Nous allons chiffrer les certificats TLS/SSL qui ne peuvent pas être émis/renouvelés. Le cluster doit signaler un état défectueux vers Front Door et le trafic doit basculer vers d’autres empreintes. Atténuation : recherchez la cause racine d’un problème/échec de renouvellement. Non
Azure Kubernetes Service Lorsque les demandes/limites de ressources sont configurées incorrectement, les pods peuvent atteindre 100 % d’utilisation du processeur et provoquer l’échec des demandes. Le mécanisme de nouvelle tentative d’application doit être en mesure de récupérer les demandes ayant échoué. Les nouvelles tentatives peuvent entraîner une durée de requête plus longue, sans qu’une erreur ne soit affichée au client. Une charge excessive peut finalement provoquer une défaillance. Non (si la charge n’est pas excessive)
Azure Kubernetes Service Images conteneur tierces/Registre indisponible Certains composants tels que cert-manager et ingress-nginx nécessitent le téléchargement d’images conteneurs et de graphiques Helm extraites de registres de conteneurs externes (trafic sortant). Lorsqu’un ou plusieurs de ces référentiels ou images ne sont pas disponibles, de nouvelles instances sur de nouveaux nœuds (où l’image n’est pas déjà mise en cache) peuvent ne pas démarrer. Atténuation possible : Dans certains scénarios, il est possible d’importer des images conteneur tierces dans le registre de conteneurs par solution. Cela ajoute une complexité supplémentaire et devrait être planifié et opérationnel avec soin. Partiellement (pendant les opérations de mise à l’échelle et de mise à jour/mise à niveau)
Event Hub Les messages ne peuvent pas être envoyés à Event Hubs L’empreinte devient inutilisable pour les opérations d’écriture. Le service de contrôle d’intégrité doit détecter automatiquement cela et retirer l’empreinte de la rotation. Non
Event Hub Les messages ne peuvent pas être lus par BackgroundProcessor Les messages sont mis en file d’attente. Les messages ne devraient pas être perdus, car ils sont conservés. Actuellement, cette défaillance n’est pas couverte par le service de contrôle d’intégrité. Il doit y avoir une surveillance/des alertes en place sur le worker pour détecter les erreurs dans le cadre de la lecture des messages. Atténuation : l’empreinte doit être désactivée manuellement jusqu’à ce que le problème soit résolu. Non
Compte de stockage Le compte de stockage devient inutilisable par le worker pour le pointage de contrôle d’Event Hubs L’empreinte ne traite pas les messages à partir d’Event Hubs. Le compte de stockage est également utilisé par HealthService. Les problèmes attendus liés au stockage doivent être détectés par HealthService et l’empreinte doit être retirée de la rotation. On peut s’attendre à ce que d’autres services dans l’empreinte soient affectés simultanément. Non
Compte de stockage Le site web statique rencontre des problèmes. Si le service du site web statique rencontre des problèmes, cette défaillance doit être détectée par Front Door. Le trafic n’est pas envoyé à ce compte de stockage. La mise en cache au niveau de Front Door peut également atténuer ce problème. Non
Key Vault Key Vault indisponible pour les opérations GetSecret. Au démarrage des nouveaux pods, le pilote CSI AKS récupère tous les secrets de Key Vault et échoue. Les pods ne peuvent pas démarrer. Il existe actuellement une mise à jour automatique toutes les 5 minutes. La mise à jour échoue. Les erreurs doivent s’afficher dans kubectl describe pod mais le pod continue de fonctionner. Non
Key Vault Key Vault indisponible pour les opérations GetSecret ou SetSecret. Les nouveaux déploiements ne peuvent pas être exécutés. Actuellement, cette défaillance peut entraîner l’arrêt de l’ensemble du pipeline de déploiement, même si une seule région est affectée. Non
Key Vault Limitation de Key Vault Key Vault a une limite de 1 000 opérations par tranche de 10 secondes. En raison de la mise à jour automatique des secrets, vous pouvez en théorie atteindre cette limite si vous aviez de nombreux (milliers) de pods dans une empreinte. Atténuation possible : réduisez encore davantage la fréquence de mise à jour ou désactivez-la complètement. Non
Application Configuration incorrecte Chaînes de connexion ou secrets incorrects injectés dans l’application. Doit être atténué par le déploiement automatisé (le pipeline gère automatiquement la configuration) et le déploiement bleu-vert des mises à jour. Non
Application Informations d’identification expirées (ressource d’empreinte) Par exemple, si le jeton SAS ou la clé de compte de stockage Event Hub a été modifié sans avoir été correctement mis à jour dans Key Vault afin que les pods puissent les utiliser, le composant d’application respectif échoue. Cet échec doit ensuite affecter le service de contrôle d’intégrité et l’empreinte doit être retirée automatiquement de la rotation. Atténuation des risques : utilisez l’authentification basée sur Microsoft Entra ID pour tous les services qui le prennent en charge. AKS nécessite que les pods s’authentifient à l’aide de Microsoft Entra Workload ID (préversion). L’utilisation de l’identité de pod a été prise en compte dans l’implémentation de référence. Il a été déterminé que l’identité de pod n’était pas suffisamment stable actuellement et il a été décidé de ne plus utiliser l’architecture de référence actuelle. L’identité de pod pourrait être une solution à l’avenir. Non
Application Informations d’identification expirées (ressource globale partagée) Par exemple, si la clé API Azure Cosmos DB a été modifiée sans avoir été correctement mise à jour dans tous les Key Vault d’empreinte afin que les pods puissent les utiliser, les composants d’application respectifs échouent. Cet échec entraîne une panne de toutes les empreintes en même temps et provoque une panne à l’échelle de la charge de travail. Pour découvrir un moyen possible de contourner la nécessité de clés et de secrets à l’aide de l’authentification Microsoft Entra, consultez l’élément précédent. Complète
Réseau virtuel Espace d’adressage IP du sous-réseau épuisé Si l’espace d’adressage IP sur un sous-réseau est épuisé, aucune opération de scale-out, comme la création de nouveaux nœuds ou pods AKS, peut se produire. Elle n’entraîne pas de panne, mais peut réduire les performances et avoir un impact sur l’expérience utilisateur. Atténuation : augmentez l’espace IP (le cas échéant). S’il ne s’agit pas d’une option, cela peut aider à augmenter les ressources par nœud (références SKU de machine virtuelle plus volumineuses) ou par pod (plus d’UC/mémoire), afin que chaque pod puisse gérer plus de trafic, ce qui réduit la nécessité d’un scale-out. Non

Étapes suivantes

Déployez l’implémentation de référence pour comprendre pleinement les ressources utilisées dans cette architecture, ainsi que leur configuration.

Implémentation : Mission-Critical Online