Partager via

Architecture avancée de microservices AKS (Azure Kubernetes Service)

Application Gateway Azure
Azure Container Registry
Azure Kubernetes Service (AKS)
Réseau virtuel Azure

Cette architecture de référence détaille plusieurs configurations à envisager lors de l’exécution de microservices sur Azure Kubernetes Service. Les sujets abordés incluent la configuration de stratégies réseau, la mise à l’échelle automatique de pod et le suivi distribué dans une application basée sur un microservice.

Cette architecture s'appuie sur l'architecture de base AKS, le point de départ recommandé par Microsoft pour l'infrastructure Azure Kubernetes Service (AKS). La ligne de base d’AKS détaille des fonctionnalités infrastructurelles telles que Microsoft Entra Workload ID, les restrictions d’entrée et de sortie, les limites de ressources et d’autres configurations d’infrastructure AKS sécurisée. Le présent document ne traite pas de ces détails infrastructurels. Nous vous recommandons de vous familiariser avec la ligne de base AKS avant de passé au contenu traitant des microservices.

Logo GitHub Une implémentation de référence de cette architecture est disponible sur GitHub.

Architecture

Diagramme de réseau montrant le réseau hub-and-spoke avec deux réseaux virtuels appairés et les ressources Azure que cette implémentation utilise.

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

Si vous préférez démarrer avec un exemple plus simple de microservices sur AKS, consultez Architecture de microservices sur AKS.

Flux de travail

Ce flux de requête implémente les modèles de conception cloud Éditeur-abonné, Consommateurs concurrents et Routage de passerelle. Le flux de messagerie se déroule comme suit :

  1. Une requête HTTPS est soumise pour planifier un collecte par drone. Les requêtes transitent via Azure Application Gateway vers l’application web d’ingestion qui s’exécute en tant que microservice dans le cluster dans AKS.

  2. L’application web d’ingestion génère un message et l’envoie à la file d’attente de messages Service Bus.

  3. Le système principal affecte un drone et informe l’utilisateur. Le flux de travail :

    • Utilise les informations de message de la file d’attente de messages Service Bus.
    • Envoie une requête HTTPS au microservice Livraison qui transmet des données au stockage de données externe Azure Cache pour Redis.
    • Envoie une requête HTTPS au microservice Planificateur du drone.
    • Envoie une requête HTTPS au microservice Package qui transmet les données au stockage de données externe MongoDB.

  4. Une requête HTTPS GET est utilisée pour retourner l’état de la livraison. Cette requête transite via Application Gateway vers le microservice Livraison.

  5. Le microservice Livraison lit les données à partir d’Azure Cache pour Redis.

Composants

Cette architecture utilise les composants Azure suivants :

Azure Kubernetes Service est une offre Azure qui fournit un cluster Kubernetes managé. Lorsque vous utilisez AKS, le serveur d’API Kubernetes est managé par Azure. Les nœuds ou pools de nœuds Kubernetes sont accessibles à l’opérateur du cluster, qui peut les gérer.

Les fonctionnalités de l’infrastructure AKS utilisées dans cette architecture sont les suivantes :

Les réseaux virtuels Azure sont isolés et hautement sécurisés pour l’exécution de machines virtuelles et d’applications. Cette architecture de référence utilise une topologie de réseau virtuel hub-and-spoke appairé. Le réseau virtuel hub contient le Pare-feu Azure et des sous-réseaux Azure Bastion. Le réseau virtuel spoke contient les sous-réseaux du pool de nœuds système et utilisateur AKS, ainsi que le sous-réseau Azure Application Gateway.

Azure Private Link alloue des adresses IP privées spécifiques pour accéder à Azure Container Registry et à Key Vault à partir de points de terminaison privés au sein du système AKS et du sous-réseau du pool de nœuds utilisateur.

Azure Application Gateway avec le pare-feu d’applications web (WAF) expose les itinéraires HTTP(S) vers le cluster AKS et équilibre la charge du trafic web vers l’application web. Cette architecture utilise un contrôleur d’entrée Azure Application Gateway (AGIC) en tant que contrôleur d’entrée Kubernetes.

Azure Bastion offre un accès avec protocole RDP (Remote Desktop Protocol) sécurisé et Secure Shell (SSH) aux machines virtuelles dans les réseaux virtuels en utilisant d’une couche SSL (Secure Socket Layer), sans qu’il soit nécessaire d’exposer les machines virtuelles via des adresses IP publiques.

Le Pare-feu Azure est un service de sécurité réseau qui protège toutes les ressources du Réseau virtuel Azure. Le pare-feu n’autorise comme trafic de sortie que des services approuvés et des noms de domaine complets (FQDN).

Stockage externe et autres composants :

Azure Key Vault stocke et gère les clés de sécurité pour les services AKS.

Azure Container Registry stocke des images de conteneur privé qui peuvent être exécutées dans le cluster AKS. AKS s’authentifie auprès de Container Registry à l’aide de son identité managée par Microsoft Entra. Vous pouvez utiliser d’autres registres de conteneurs, tel Docker Hub.

Azure Cosmos DB stocke les données à l’aide d’Azure Cosmos DB for MongoDB open source. Les microservices étant généralement sans état, ils écrivent leur état dans des magasins de données externes. Azure Cosmos DB est une base de données NoSQL avec des API open source pour MongoDB et Cassandra.

Azure Service Bus offre une messagerie cloud en tant que service fiable et une intégration hybride simple. Service Bus prend en charge des modèles de messagerie asynchrone communs avec les applications de microservices.

Azure Cache pour Redis ajoute une couche de mise en cache à l’architecture d’application pour améliorer la vitesse et les performances des charges de trafic lourdes.

Azure Monitor collecte et stocke des métriques et journaux, dont une télémétrie d’application et des métriques de plateforme et de service Azure. Vous pouvez utiliser ces données pour surveiller l’application, définir des alertes et des tableaux de bord, et effectuer une analyse de la cause racine des défaillances.

Autres composants du système de support des opérations (operations Support System, OSS) :

Helm , gestionnaire de package pour Kubernetes qui regroupe des objets Kubernetes dans une seule unité que vous pouvez publier, déployer, mettre à jour et dont vous pouvez contrôler la version.

fournisseur CSI du magasin de secrets Azure Key Vault obtient des secrets stockés dans Azure Key Vault et utilise le pilote CSI Secret Store interface pour les monter dans des pods Kubernetes.

Flux , solution de livraison continue ouverte et extensible pour Kubernetes, optimisée par GitOps Toolkit.

Détails du scénario

L’exemple d’application d’expédition par drone de Fabrikam illustré dans le diagramme précédent implémente les composants architecturaux et les pratiques décrits dans cet article. Dans cet exemple, Fabrikam, Inc., société fictive, gère une flotte de drones. Les entreprises souscrivent au service, et les utilisateurs peuvent demander à ce qu’un drone vienne récupérer les marchandises à livrer. Quand un client planifie une collecte, le système principal assigne un drone et informe l’utilisateur d’un délai de livraison estimé. Pendant le processus de livraison, le client peut suivre la position du drone, avec une heure prévue d’arrivée (ATE) actualisée en permanence.

Cas d’usage potentiels

Cette solution est idéale pour les secteurs de l’aéronautique, de l’aérospatiale et de l’aviation.

Recommandations

Implémentez ces recommandations lors du déploiement d’architectures de microservices AKS avancées.

Contrôleur d’entrée Application Gateway (AGIC)

Le Routage de passerelle API est un modèle de conception de microservices général. Une passerelle API agit comme un proxy inverse qui achemine les requêtes des clients aux microservices. La ressource d’entrée et le contrôleur d’entrée de Kubernetes gèrent l’essentiel de la fonctionnalité de la passerelle API en effectuant les opérations suivantes :

Routage des requêtes des clients vers les services principaux appropriés fournit un point de terminaison unique pour les clients, et permet de découpler les clients des services.

  • Agrégation de plusieurs requêtes en une seule pour réduire les échanges entre le client et le serveur principal.
  • Déchargement de fonctionnalités des services principaux, telles que l’arrêt SSL, l’authentification, la restriction d’adresses IP ou la limitation du débit client.

L’état du cluster AKS est converti en configuration spécifique d’Application Gateway et appliqué via Azure Resource Manager.

Des contrôleurs d’entrée externes simplifient l’ingestion du trafic dans les clusters AKS, améliorent la sécurité et les performances, et économisent les ressources. Cette architecture utilise le contrôleur d’entrée Azure Application Gateway (AGIC) pour le contrôle d’entrée. L’utilisation d’Application Gateway pour gérer tout le trafic élimine la nécessité d’un équilibreur de charge supplémentaire. Étant donné que les pods établissent des connexions directes via Application Gateway, le nombre de tronçons requis est réduit, ce qui contribue à améliorer les performances.

Application Gateway intègre des fonctionnalités de mise à l’échelle automatique, contrairement aux contrôleurs d’entrée dans le cluster, qui nécessitent une montée ne puissance parallèle s’ils consomment une quantité indésirable de ressources de calcul. Application Gateway peut effectuer un routage de couche 7 et un arrêt SSL, et dispose d’un protocole TLS (Transport Layer Security) de bout en bout associé à un pare-feu d’applications web (WAF) intégré.

Pour l’option d’entrée AGIC, vous devez activer la Mise en réseau CNI lorsque vous configurez le cluster AKS, car Application Gateway est déployé dans un sous-réseau du réseau virtuel AKS. Les charges de travail mutualisées ou un cluster unique qui prend en charge les environnements de développement et de test peuvent nécessiter davantage de contrôleurs d’entrée.

Stratégies réseau Confiance Zéro

Les stratégies réseau spécifient la façon dont les pods AKS sont autorisés à communiquer entre eux et avec d’autres points de terminaison réseau. Par défaut, tout le trafic entrant et sortant est autorisé vers et depuis des pods. Lors de la conception de la façon dont vos microservices communiquent entre eux et avec d’autres points de terminaison, songez de suivre le principe de Confiance Zéro en vertu duquel l’accès à un service, un appareil, une application ou un référentiel de données nécessite une configuration explicite.

L’une des approches de l’implémentation d’une politique de Confiance Zéro consiste à créer une stratégie réseau qui refuse tout trafic entrant et sortant vers et depuis tous les pods au sein l’espace de noms cible. L’exemple suivant montre une stratégie de refus de tout trafic qui s’applique à tous les pods situés dans l’espace de noms de développement back-end.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Une fois qu’une stratégie restrictive est en place, commencez à définir des règles de réseau spécifiques afin d’autoriser le trafic entrant et sortant pour chaque pod dans le microservice. Dans l’exemple suivant, la stratégie réseau est appliquée à tout pod dans l’espace de noms de développement back-end avec une étiquette correspondant à app.kubernetes.io/component: backend. La stratégie refuse tout trafic sauf s'il provient d'un pod avec une étiquette correspondant à app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Pour plus d’informations sur les stratégies réseau de Kubernetes et des exemples supplémentaires de stratégies par défaut potentielles, consultez Stratégies réseau dans la documentation de Kubernetes.

Quotas de ressources

Des quotas de ressources permettent aux administrateurs de réserver et limiter des ressources à l’échelle d’un projet ou d’une équipe de développement. Vous pouvez définir des quotas de ressources sur un espace de noms et les utiliser pour définir les limites suivantes :

  • Ressources de calcul (par exemple, le processeur et la mémoire ou des GPU).
  • Ressources de stockage, à savoir le nombre total de volumes ou la quantité d’espace disque pour une classe de stockage donnée.
  • Nombre d’objets, par exemple, nombre maximal de secrets, de services ou de travaux pouvant être créés.

Si le total cumulé des demandes ou des limites de ressources dépasse le quota affecté, tout nouveau déploiement échoue.

Les quotas de ressources garantissent que l’ensemble des pods affectés à l’espace de noms ne peut pas dépasser le quota de ressources de l’espace de noms. Le serveur frontal ne peut pas priver les services principaux de ressources ou inversement.

Quand vous définissez des quotas de ressources, tous les pods créés dans l’espace de noms doivent fournir des demandes ou des limites dans leurs spécifications de pod. S’ils ne fournissent pas ces valeurs, le déploiement est rejeté.

L’exemple suivant illustre une spécification de pod qui définit des demandes et des limites de quota de ressources :

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Pour plus d’informations sur les quotas de ressources, consultez les articles suivants :

Mise à l’échelle automatique

Kubernetes prend en charge la mise à l’échelle automatique pour augmenter le nombre de pods alloués à un déploiement, ou la quantité de nœuds du cluster, afin d’accroître le nombre total de ressources de calcul disponibles. La mise à l’échelle automatique est un système autonome et autocorrecteur de rétroaction. Bien que vous puissiez mettre à l’échelle les pods et les nœuds manuellement, la mise à l’échelle automatique réduit le risque que des services viennent à manquer de ressources lors de pics de charge. Une stratégie de mise à l’échelle automatique doit tenir compte à la fois des pods et des nœuds.

Mise à l’échelle automatique du cluster

L’autoscaler de cluster met à l’échelle le nombre de nœuds. Si des contraintes de ressources viennent à empêcher la planification de pods, l’autoscaler de cluster approvisionne davantage de nœuds. Vous définissez un nombre minimal de nœuds pour maintenir le cluster AKS et vos charges de travail opérationnels, ainsi qu’un nombre maximal de nœuds quand le trafic est dense. L’autoscaler de cluster vérifie toutes les quelques secondes s’il y a des pods en attente ou des nœuds vides, et adapte l’échelle du cluster AKS en conséquence.

L’exemple suivant illustre la configuration de l’autoscaler de cluster à partir du modèle ARM :

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Les lignes suivantes dans le modèle ARM définissent des nombres minimal et maximal de nœuds pour l’autoscaler de cluster :

"minCount": 2,
"maxCount": 5,

Mise à l’échelle automatique des pods

L’autoscaler de pod horizontal met à l’échelle les pods en fonction des métriques d’UC, de mémoire ou personnalisées observées. Pour configurer la mise à l’échelle de pod horizontale, vous spécifiez les métriques cibles et les nombres minimal et maximal de réplicas dans la spécification de pod du déploiement Kubernetes. Pour déterminer ces nombres, testez la charge de vos services.

L’autoscaler de cluster et l’autoscaler de pod horizontal fonctionnant bien ensemble, activez les deux options d’autoscaler dans votre cluster AKS. L’autoscaler de pod horizontal met à l’échelle l’application, tandis que l’autoscaler de cluster met à l’échelle l’infrastructure.

L’exemple suivant définit les métriques de ressources pour l’autoscaler de pod horizontal :

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

L’autoscaler de pod horizontal examine les ressources réelles consommées ou d’autres métriques de pods en cours d’exécution, tandis que l’autoscaler de cluster approvisionne des nœuds pour les pods qui ne sont pas encore planifiés. Par conséquent, l’autoscaler de cluster examine les ressources demandées, comme spécifié dans la spécification de pod. Testez la charge pour affiner ces valeurs.

Sondes d’intégrité

Kubernetes équilibre la charge du trafic vers les pods correspondant à un sélecteur d’étiquette pour un service. Seuls les pods qui ont correctement démarré et qui sont sains reçoivent du trafic. En cas de blocage d’un conteneur, Kubernetes supprime le pod et planifie un remplacement.

Dans Kubernetes, un pod peut exposer deux types de sondes d’intégrité :

  • La sonde probe liveness indique à Kubernetes si un pod a démarré correctement et s’il est sain.
  • La sonde probe readiness indique à Kubernetes si le pod est prêt à accepter des requêtes.

Les sondes probe liveness gèrent les pods en cours d’exécution qui sont on sains et nécessitent un recyclage. Par exemple, si un conteneur servant des requêtes HTTP suspend son exécution, il ne se bloque pas, mais arrête de servir les requêtes. La sonde probe liveness HTTP ne répond plus, ce qui indique à Kubernetes de redémarrer le pod.

Il peut arriver qu’un pod ne soit pas prêt à recevoir du trafic, même s’il a démarré correctement. Par exemple, il se peut que l’application en cours d’exécution dans le conteneur soit en train d’effectuer des tâches d’initialisation. La sonde probe readiness indique si le pod est prêt à recevoir du trafic.

Les microservices doivent exposer dans leur code des points de terminaison qui facilitent le fonctionnement des sondes d’intégrité, avec des délais de temporisation et d’attente adaptés spécifiquement aux vérifications qu’ils effectuent. La formule de l’autoscaler de pod horizontal détermine presque exclusivement la phase Ready sur un pod. Il est donc essentiel que les sondes d’intégrité existent et soient précises.

Supervision

Dans une application de microservices, la surveillance de la gestion des performances applicatives (APM) est essentielle pour détecter des anomalies, diagnostiquer des problèmes et comprendre rapidement les dépendances entre les services. La fonctionnalité Application Insights, qui fait partie d’Azure Monitor, assure une surveillance de la gestion des performances applicatives d’applications dynamiques écrites en .NET Core, Node.js, Java et de nombreux autres langages d’application.

Application Insights :

  • Journalise les requêtes HTTP, notamment la latence et le code de résultat.
  • Active le suivi distribué par défaut.
  • Inclut un ID d’opération dans les suivis, qui permet de rapprocher tous les suivis d’une opération particulière.
  • Inclut souvent des informations contextuelles supplémentaires dans les suivis.

Afin de contextualiser la télémétrie des services avec l’environnement Kubernetes, intégrez la télémétrie d’Azure Monitor avec AKS de manière à collecter des métriques de contrôleurs, nœuds et conteneurs, ainsi que des journaux de conteneur et de nœud. Si vous utilisez .NET, la bibliothèque Application Insights pour Kubernetes enrichit la télémétrie d’Application Insights avec des informations d’image, de conteneur, de nœud, de pod, d’étiquette et de jeu de réplicas.

Le diagramme suivant montre un exemple de carte des dépendances d’application qu’Application Insights génère pour un suivi de télémétrie de microservices AKS :

Exemple de carte de dépendances Application Insights pour une application de microservices AKS.

Pour plus d’informations sur les options d’instrumentation des langages courants pour l’intégration d’insights d’application, consultez Surveillance d’applications pour Kubernetes.

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.

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 liste de vérification de la révision de conception pour security.

Lors de la planification en lien avec la sécurité, considérez les points suivants.

  • Un pod AKS s’authentifie à l’aide d’une identité de charge de travail stockée dans Microsoft Entra ID. L’utilisation d’une identité de charge de travail est préférable, car elle ne nécessite pas de clé secrète client.

  • Avec des identités gérées, le processus en cours d’exécution peut rapidement obtenir des jetons OAuth 2.0 Azure Resource Manager, sans qu’il soit nécessaire d’utiliser des mots de passe ou des chaînes de connexion. Dans AKS, vous pouvez affecter des identités à des pods individuels à l’aide de Microsoft Entra Workload ID.

  • Chaque service de l’application de microservice doit se voir attribuer une identité de charge de travail unique pour faciliter les affectations de RBAC moins privilégié. Vous ne devez affecter des identités qu’aux services qui en ont besoin.

  • Dans les cas où un composant d’application requiert un accès API Kubernetes, assurez-vous que les pods d’application sont configurés pour utiliser un compte de service disposant d’un accès d’API d’une étendue appropriée. Pour plus d’informations sur la configuration et la gestion d’un compte de service Kubernetes, consultez Gestion des comptes de service Kubernetes.

  • Les services Azure ne prennent pas tous en charge l’authentification de plan de données à l’aide de Microsoft Entra ID. Pour stocker des informations d’identification ou des secrets d’application pour ces services, des services tiers ou des clés API, utilisez la solution Azure Key Vault. La solution Azure Key Vault assure la gestion centralisée, le contrôle d’accès, le chiffrement au repos et l’audit de l’ensemble des clés et secrets.

  • Dans AKS, vous pouvez monter un ou plusieurs secrets à partir de Key Vault en tant que volume. Le pod peut ensuite lire les secrets de Key Vault comme il lirait un volume normal. Pour plus d'informations, consultez le projet secrets-store-csi-driver-provider-azure sur GitHub.

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 liste de vérification de la révision de conception pour l’optimisation des coûts.

  • La section Cost dans le Microsoft Azure Well-Architected Framework aborde les considérations relatives aux coûts. Utilisez la Calculatrice de prix Azure pour estimer les coûts de votre scénario spécifique.

  • AKS n’occasionne pas de coûts associés au déploiement, à la gestion et aux opérations du cluster Kubernetes. Vous ne payez que pour les instances de machines virtuelles, le stockage et les ressources réseau que le cluster consomme. La mise à l’échelle automatique du cluster peut réduire sensiblement le coût de celui-ci en supprimant les nœuds vides ou inutilisés.

  • Pour estimer le coût des ressources requises, reportez-vous à la Calculatrice de services conteneurs.

  • Envisagez d’activer l’analyse des coûts AKS pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

Lors de la planification en lien avec la facilité de gestion, considérez les points suivants.

  • Gérez l’infrastructure du cluster AKS via un pipeline de déploiement automatisé. L’implémentation de référence pour cette architecture fournit un flux de travail GitHub Actions que vous pouvez référencer lors de la création de votre pipeline.

  • Le fichier de flux de travail déploie l’infrastructure uniquement, pas la charge de travail, dans le réseau virtuel existant et dans la configuration Microsoft Entra. Le fait de déployer séparément l’infrastructure et la charge de travail vous permet de résoudre des problèmes de cycle de vie et opérationnels distincts.

  • En cas de défaillance régionale, considérez votre flux de travail comme un mécanisme de déploiement vers une autre région. Générez le pipeline de façon à pouvoir déployer un nouveau cluster dans une nouvelle région moyennant quelques modifications de paramètres et d’entrée.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à mettre à l’échelle pour répondre aux demandes qu’elle lui impose par les utilisateurs de manière efficace. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Lors de la planification en lien avec la scalabilité, considérez les points suivants.

  • Ne combinez pas la mise à l’échelle automatique et la gestion impérative ou déclarative du nombre de réplicas. Le fait que des utilisateurs et un autoscaler tentent simultanément de modifier le nombre de réplicas pourrait entraîner un comportement inattendu. Lorsque l’autoscaler de pod horizontal est activé, réduisez le nombre de réplicas au nombre minimal que vous souhaitez déployer.

  • Un effet secondaire de la mise à l’échelle automatique des pods est qu’elle peut entraîner de fréquentes opérations de création ou de suppression de pods, à mesure que des événements de scale-out et de scale-in se produisent. Pour atténuer ces effets :

    • Utilisez des probes readiness pour que Kubernetes sache quand un nouveau pod est prêt à accepter du trafic.
    • Utilisez des budgets d’interruption de pod pour limiter le nombre de pods pouvant être supprimés d’un service simultanément.

  • Comme vous ne pouvez pas modifier la taille de machine virtuelle après la création d’un cluster, dès la création de celui-ci, vous devez planifier la capacité de façon à choisir une taille de machine virtuelle appropriée pour les nœuds d’agent.

  • Les charges de travail multilocataire ou d’autres charges de travail avancées peuvent avoir des exigences d’isolation de pool de nœuds qui demandent plus et probablement des sous-réseaux plus petits. Pour plus d’informations sur la création de pools de nœuds avec des sous-réseaux uniques, consultez Ajouter un pool de nœuds avec un unique sous-réseau. Les organisations adoptent des normes différentes pour leurs implémentations de type hub-and-spoke. Veillez à suivre les directives de votre organisation.

Étapes suivantes