Architecture de base pour un cluster Azure Kubernetes Service (AKS)

Application Gateway Azure

Azure Container Registry

Pare-feu Azure

Azure Kubernetes Service (AKS)

Contrôle d’accès en fonction du rôle Azure

Cet article fournit une architecture d’infrastructure de référence recommandée pour déployer un cluster Azure Kubernetes Service (AKS). Il suit nos principes de conception et s’aligne sur les meilleures pratiques architecturales du cadre Azure Well-Architected. L’article guides plusieurs groupes interdisciplinaires distincts, tels que la mise en réseau, la sécurité et les équipes d’identité, lorsqu’ils déploient cette infrastructure à usage général.

Cette architecture ne se concentre pas sur une charge de travail. Il se concentre sur le cluster AKS lui-même. Ces informations constituent la base minimale recommandée pour la plupart des clusters AKS. Il s’intègre aux services Azure qui fournissent une observabilité, fournissent une topologie de réseau qui prend en charge la croissance multirégion et le trafic en cluster sécurisé.

Vos besoins métier influencent l’architecture cible et peuvent varier entre les contextes d’application. Considérez cette architecture comme votre point de départ pour les étapes de préproduction et de production.

Kubernetes est un vaste écosystème qui s’étend au-delà des technologies Azure et Microsoft. Lorsque vous déployez un cluster AKS, vous êtes responsable de nombreuses décisions sur la conception et l’exploitation du cluster. L’exécution d’un cluster AKS implique des composants sources fermés de différents fournisseurs, y compris Microsoft, ainsi que des composants open source de l’écosystème Kubernetes. Le paysage change fréquemment, donc revisiter régulièrement les décisions. Lorsque vous adoptez Kubernetes, vous reconnaissez que votre charge de travail a besoin de ses fonctionnalités et que votre équipe de charge de travail est prête à investir en permanence.

Vous pouvez utiliser une implémentation de cette architecture sur GitHub : implémentation de référence de référence AKS comme autre point de départ et la configurer pour répondre à vos besoins.

Note

L'architecture de référence nécessite une connaissance de Kubernetes et de ses concepts. Si vous avez besoin d’un rafraîchissement, consultez les parcours de formation Introduction à Kubernetes et Développer et déployer des applications sur Kubernetes.

Architecture

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

Pour plus d’informations, consultez topologie de réseau hub-and-spoke dans Azure.

Topologie du réseau

Cette architecture utilise une topologie de réseau hub-and-spoke. Déployez les hub-and-spokes dans des réseaux virtuels distincts connectés via virtual network peering. Cette topologie présente plusieurs avantages :

Permettre une gestion séparée. Vous pouvez appliquer la gouvernance et respecter le principe du privilège minimum (PoLP). Il prend également en charge le concept d’une zone d’atterrissage Azure avec une séparation des tâches.
Réduisez l’exposition directe des ressources Azure à l’Internet public.
Fournissez des topologies hub-and-spoke régionales. Vous pouvez étendre les topologies de réseau hub-and-spoke à l'avenir et assurer une isolation des charges de travail.
Utilisez un service web application firewall pour inspecter le flux de trafic HTTP pour toutes les applications web.
Prenez en charge les charges de travail qui s'étendent sur plusieurs abonnements.
Rendez l'architecture extensible. Pour prendre en charge de nouvelles fonctionnalités ou charges de travail, vous pouvez ajouter de nouveaux spokes au lieu de revoir la topologie du réseau.
Prise en charge du partage de ressources, comme un pare-feu et des zones DNS (Domain Name System), entre les réseaux.
Aligner avec la zone d’atterrissage à l’échelle de l’entreprise Azure.

Hub virtual network

Le hub virtual network est le point central de connectivité et d’observabilité. Dans cette architecture, le hub contient les composants suivants :

Azure Firewall avec des stratégies de pare-feu globales que vos équipes informatiques centrales définissent pour appliquer des règles à l’échelle de l’organisation
Azure Bastion, qui établit un tunnel sécurisé dans le périmètre du réseau privé afin de pouvoir effectuer des opérations de gestion de cluster
Sous-réseau de passerelle pour la connectivité VPN
moniteur Azure pour l’observabilité du réseau

Au sein du réseau, l'architecture comporte trois sous-réseaux.

Sous-réseau pour héberger le pare-feu Azure

Azure Firewall est un service de pare-feu managé. L’instance Azure Firewall sécurise le trafic réseau sortant. Sans cette couche de sécurité, le trafic pourrait communiquer avec un service malveillant, non Microsoft, qui pourrait exfiltrer des données sensibles de la charge de travail. Utilisez Azure Firewall Manager pour déployer et configurer de manière centralisée plusieurs instances Azure Firewall et gérer des stratégies de Azure Firewall pour ce type d’architecture hub virtual network.

Sous-réseau pour héberger une passerelle

Ce sous-réseau est un espace réservé pour un VPN gateway ou une passerelle ExpressRoute Azure. La passerelle fournit une connectivité entre les routeurs de votre réseau local et le virtual network.

Sous-réseau pour héberger des Azure Bastion

Ce sous-réseau est utilisé pour Azure Bastion. Vous pouvez utiliser Azure Bastion pour accéder en toute sécurité aux ressources Azure sans exposer les ressources à Internet. Cette architecture utilise Azure Bastion pour se connecter en toute sécurité au serveur d'API du cluster AKS pour les opérations de gestion. Le sous-réseau est destiné uniquement à la gestion et aux opérations.

Réseau virtuel spoke

Le virtual network spoke contient le cluster AKS et d’autres ressources associées. Le spoke possède les sous-réseaux suivants .

Sous-réseau pour héberger l'Azure Application Gateway

Azure Application Gateway est un équilibreur de charge de trafic de site web qui fonctionne au niveau de la couche 7. L’implémentation de référence utilise la référence SKU Application Gateway v2 qui active Azure Web Application Firewall. Web Application Firewall sécurise le trafic entrant contre les attaques courantes de trafic web, y compris les bots. L'instance dispose d'une configuration IP frontale publique qui reçoit les requêtes des utilisateurs. Par conception, Application Gateway nécessite un sous-réseau dédié.

Sous-réseau pour héberger les ressources d’entrée

Pour router et distribuer le trafic, Traefik est le contrôleur d’entrée qui remplit les ressources d’entrée Kubernetes. Les Azure équilibreurs de charge internes existent dans ce sous-réseau. Pour plus d’informations, consultez Utilisez un load balancer interne avec AKS.

Sous-réseau pour héberger les nœuds de cluster

AKS maintient deux pools de nœuds, qui sont des groupes distincts de nœuds. Le pool de nœuds système héberge les pods qui exécutent les principaux services de cluster. Le pool de nœuds utilisateur exécute votre charge de travail et le contrôleur d’entrée pour permettre une communication entrante vers la charge de travail.

Sous-réseau pour héberger des points de terminaison Azure Private Link

Créer des connexions Azure Private Link pour Azure Container Registry et Azure Key Vault afin que les utilisateurs puissent access ces services via un point de terminaison private dans le spoke virtual network. Les points de terminaison privés ne nécessitent pas de sous-réseau dédié. Vous pouvez également placer des points de terminaison privés dans le hub virtual network. Dans l’implémentation de la base de référence, les points de terminaison sont déployés sur un sous-réseau dédié dans le virtual network spoke. Cette approche permet de réduire le trafic qui passe par la connexion réseau interconnectée. Cela conserve les ressources qui appartiennent au cluster dans le même réseau virtuel. Vous pouvez également appliquer des règles de sécurité granulaires au niveau du sous-réseau à l’aide de groupes de sécurité réseau (NSG).

Pour plus d’informations, consultez Private Link options de déploiement.

Sous-réseau pour le serveur d’API AKS

Vous pouvez configurer un cluster AKS pour qu'il utilise l'intégration du serveur API du réseau virtuel, ce qui intègre le point de terminaison du serveur d'API du cluster dans un sous-réseau délégué de votre réseau virtuel. Cette configuration est appelée cluster privé , car elle garantit que tout le trafic entre le serveur d’API, les pools de nœuds et les clients connectés restent entièrement au sein de votre réseau privé.

Toutes les communications entre le serveur d’API Kubernetes géré par AKS et les clients (clients internes et externes) sont limitées à un réseau approuvé.

Avec un cluster privé, vous pouvez utiliser des groupes de sécurité réseau et autres mécanismes de contrôle réseau intégrés pour sécuriser votre environnement. Cette configuration interdit tout accès public non autorisé entre Internet et environnement. Pour plus d’informations, consultez Créer un cluster AKS privé.

Planifier les adresses IP

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

Cette architecture de référence utilise plusieurs approches réseau, chacune nécessitant un espace d’adressage IP :

Votre Azure virtual network que vous utilisez pour les ressources telles que les nœuds de cluster, le serveur d'API du cluster, les points de terminaison privés pour les services Azure et les Application Gateway.
Le cluster utilise Azure Container Networking Interface (CNI) Overlay, qui alloue des adresses IP aux pods d’un espace d’adressage distinct de votre réseau virtuel Azure.

Adresse IP de l'espace d'adressage du réseau virtuel

L’espace d’adressage de votre Azure virtual network doit être suffisamment grand pour contenir tous vos sous-réseaux. Tenez compte de toutes les entités qui reçoivent du trafic. Kubernetes alloue des adresses IP pour les entités à partir de l’espace d’adressage du sous-réseau. Tenez compte des points suivants lorsque vous planifiez les adresses IP de votre Azure virtual network :

Améliorations: AKS met régulièrement à jour les nœuds pour vous assurer que les machines virtuelles sous-jacentes sont up-to-date sur les fonctionnalités de sécurité et d’autres correctifs système. Lors d’un processus de mise à niveau, AKS crée un nœud qui héberge temporairement les pods, tandis que le nœud de mise à niveau est fermé et vidé. Ce nœud temporaire reçoit une adresse IP du sous-réseau du cluster. Vérifiez que vous disposez d’un espace d’adressage suffisant pour les adresses IP de nœud temporaires.

Dans cette architecture, les adresses IP sont allouées aux pods à partir de l’espace d’adressage du pod de l'overlay CNI Azure, y compris pendant les mises à jour progressives. Cette approche réduit le nombre global d’adresses IP utilisées à partir de votre Azure virtual network par rapport à d’autres approches réseau Kubernetes.
Évolutivité: Tenez compte du nombre total de nœuds système et utilisateur et de leurs limites d’extensibilité maximales. Par exemple, si vous souhaitez étendre de 400 %, vous avez besoin de quatre fois le nombre d’adresses pour tous les nœuds étendus.

Étant donné que cette architecture utilise Azure CNI Overlay, l'évolutivité de vos pods n'affecte pas l'espace d'adressage de votre réseau virtuel.
adresses Private Link : Prenez en compte les adresses nécessaires à la communication avec d’autres services Azure via Private Link. Cette architecture comporte deux adresses attribuées pour les liens vers Container Registry et Key Vault.
Adresses du serveur d’API de cluster privé : l'intégration du serveur d’API dans votre réseau virtuel vous aide à projeter le serveur d’API AKS comme un point de terminaison à l'intérieur de votre réseau virtuel. Cette fonctionnalité nécessite une taille de sous-réseau minimum. Veillez donc à respecter ces conditions préalables lors de la planification de votre réseau.
Adresses IP réservées : Azure réserve des adresses specifices pour ses utilisations. Ils/Elles ne peuvent pas être affecté(e)s.

La liste précédente n’est pas exhaustive. Si votre conception comporte d'autres ressources qui affectent le nombre d'adresses IP disponibles, tenez compte de ces adresses.

Cette architecture est conçue pour une charge de travail unique. Dans un cluster AKS de production, séparez toujours le pool de nœuds système du pool de nœuds utilisateur. Lorsque vous exécutez plusieurs charges de travail sur le cluster, il se peut que vous souhaitiez isoler les pools de nœuds utilisateur les uns des autres. Cette isolation entraîne un plus grand nombre de sous-réseaux plus petits. La ressource d’entrée peut également être plus complexe. Par conséquent, vous pouvez avoir besoin de plusieurs contrôleurs d’entrée qui nécessitent chacune des adresses IP supplémentaires.

Espace d’adressage IP du pod

Azure CNI Overlay attribue des adresses IP aux pods à l’aide d’un espace d’adressage dédié, distinct de l’espace d’adressage que vous utilisez dans votre réseau virtuel. Utilisez un espace d'adressage IP qui ne chevauche pas votre réseau virtuel ni tout autre réseau virtuel appairé. Toutefois, si vous créez plusieurs clusters AKS, vous pouvez utiliser en toute sécurité le même espace d’adressage de pod sur chaque cluster.

Azure CNI Overlay affecte un espace d’adressage /24 à chaque nœud pour ses pods. Il est important de s’assurer que l’espace d’adressage du pod est suffisamment grand. Autorisez autant de blocs /24 que nécessaire pour le nombre de nœuds de votre cluster. N’oubliez pas d’inclure les nœuds temporaires créés pendant les mises à niveau ou les opérations de mise à l’échelle. Par exemple, si vous utilisez un espace d’adressage /16 pour votre plage de routage inter-domaines (CIDR) sans classe, votre cluster peut atteindre un maximum de 250 nœuds.

Chaque nœud prend en charge jusqu’à 250 pods, et cette limite inclut tous les pods temporairement créés pendant les mises à niveau.

Pour plus d’informations, consultez les consignes sur la planification des adresses IP pour CNI Overlay d'Azure.

Autres considérations relatives à l’espace d’adressage IP

Pour connaître l’ensemble complet des considérations relatives à la mise en réseau de cette architecture, consultez AAKS de topologie de réseau de référence. Pour plus d’informations sur la planification de l’adressage IP pour un cluster AKS, consultez Configurer le réseau CNI Azure dans AKS.

Modules complémentaires et fonctionnalités d’évaluation

Kubernetes et AKS évoluent en permanence, avec des cycles de publication plus rapides que des logiciels pour les environnements locaux. Cette architecture de base dépend des fonctionnalités d’évaluation AKS spécifiques et des modules complémentaires AKS. Tenez compte des différences suivantes entre les fonctionnalités en préversion et les modules complémentaires :

L’équipe AKS décrit les fonctionnalités en préversion comme fournies et en cours d'amélioration, car la plupart des fonctionnalités de préversion restent dans cet état pendant quelques mois seulement avant qu’elles ne passent à la phase de disponibilité générale.
AKS add-ons et extensions fournissent des fonctionnalités supplémentaires prises en charge. AKS gère son installation, sa configuration et son cycle de vie.

L’architecture de référence n’inclut pas chaque fonctionnalité ou module complémentaire en préversion. En revanche, il n'inclut que celles qui apportent une valeur ajoutée significative à un cluster à usage général. Au fur et à mesure que ces fonctionnalités sortent de l'évaluation, cette architecture de base est révisée en conséquence. Il existe d’autres fonctionnalités en préversion ou des modules complémentaires AKS que vous souhaiterez peut-être évaluer dans des clusters de préproduction. Ces fonctionnalités peuvent améliorer votre sécurité, votre facilité de gestion ou d'autres exigences. Avec les modules complémentaires non-Microsoft, vous devez les installer et les gérer, ce qui inclut le suivi des versions disponibles et l’installation des mises à jour après la mise à niveau de la version Kubernetes d’un cluster.

Référence d’image de conteneur

Le cluster peut contenir la charge de travail et plusieurs autres images, comme le contrôleur d’entrée. Certaines de ces images peuvent résider dans des registres publics. Tenez compte des points suivants lorsque vous extrayez les images dans votre cluster :

Authentifiez le cluster pour récupérer l'image.
Si vous utilisez une image publique, importez l’image dans un registre de conteneurs qui s’aligne sur votre objectif de niveau de service (SLO). Dans le cas contraire, l'image peut être sujette à des problèmes de disponibilité inattendus. Si l’image n’est pas disponible lorsque vous en avez besoin, des problèmes opérationnels peuvent se produire. Tenez compte des avantages suivants de l’utilisation d’un registre de conteneurs privé, comme Azure Container Registry, au lieu d’un registre public :
- Vous pouvez bloquer les access non autorisés à vos images.
- Vous n'avez pas de dépendances publiques.
- Vous pouvez accéder aux journaux de récupération d'images pour surveiller les activités et diagnostiquer les problèmes de connectivité.
- Vous pouvez tirer parti de l'analyse intégrée des conteneurs et de la conformité des images.
Extrayez des images de registres autorisés. Vous pouvez appliquer cette restriction via Azure Policy. Dans cette implémentation de référence, le cluster extrait uniquement les images de l’instance de Azure Container Registry dédiée qui se déploie avec le cluster.

Configurer le calcul pour le cluster de base

Dans AKS, chaque pool de nœuds est généralement mappé à un groupe de machines virtuelles identiques. Les nœuds sont des machines virtuelles dans chaque pool de nœuds.

Envisagez d’utiliser une taille de machine virtuelle inférieure pour le pool de nœuds système afin de réduire les coûts. Cette implémentation de référence déploie le pool de nœuds système avec trois nœuds D2dv5. Cette taille est suffisante pour répondre à la charge attendue des pods du système. Le disque éphémère du système d’exploitation est de 64 Go.

Lorsque vous planifiez la capacité d’un pool de nœuds utilisateur, tenez compte des recommandations suivantes :

Choisissez des tailles de nœud plus grandes pour accueillir le nombre maximal de pods déployés sur un même nœud. Les nœuds volumineux réduisent l’encombrement des services qui s’exécutent sur tous les nœuds, tels que la surveillance et la journalisation.
Sélectionnez le type de machine virtuelle approprié si vous avez des exigences spécifiques en matière de charge de travail. Par exemple, vous pourriez avoir besoin d'un produit à mémoire optimisée pour certaines charges de travail, ou d'un produit accéléré par le GPU pour d'autres. Pour plus d’informations, consultez Sizes pour les machines virtuelles dans Azure.
Déployez au moins deux nœuds pour que la charge de travail suive un modèle de haute disponibilité avec deux réplicas. AKS vous permet de modifier le nombre de nœuds sans recréer le cluster.
Planifiez les tailles de nœud réelles pour votre charge de travail en fonction des exigences que votre équipe de conception détermine. En fonction des exigences métier, cette architecture utilise la référence SKU D4dv5 pour la charge de travail de production.
Supposons que votre charge de travail consomme jusqu’à 80% de chaque nœud lorsque vous planifiez la capacité de votre cluster. Les 20 % restants sont réservés aux services AKS.
Définissez les pods maximum pour chaque nœud en fonction de votre planification de capacité. Si vous essayez d’établir une base de référence de capacité, commencez par une valeur de 30. Ajustez cette valeur en fonction des exigences de la charge de travail, de la taille du nœud et de vos contraintes d’adresse IP.

Sélectionner un système d’exploitation

La plupart des clusters AKS utilisent le système d’exploitation Linux pour leurs pools de nœuds. Dans cette implémentation de référence, nous utilisons Azure Linux, qui est une distribution Linux légère et renforcée paramétrée pour Azure. Vous pouvez choisir une autre distribution Linux comme Ubuntu si vous préférez ou si Azure Linux ne répond pas à vos besoins. Si vous choisissez un autre système d’exploitation, assurez-vous que le disque du système d’exploitation est dimensionné correctement pour cette image. Certaines distributions nécessitent plus d’espace que Azure Linux. Vous devrez peut-être augmenter la taille du disque pour éviter les problèmes de déploiement ou d’exécution.

Si votre charge de travail est composée de technologies mixtes, vous pouvez utiliser différents systèmes d’exploitation dans différents pools de nœuds. Toutefois, si vous n’avez pas besoin de systèmes d’exploitation différents, nous vous recommandons d’utiliser un seul système d’exploitation pour tous les pools de nœuds de charge de travail afin de réduire la complexité opérationnelle.

Intégrer Microsoft Entra ID pour le cluster

La sécurisation des access vers et depuis le cluster est essentielle. Utilisez la perspective du cluster pour comprendre la différence entre le trafic entrant et sortant.

Inside-out access : envisagez l'accès d'AKS aux composants Azure tels que l'infrastructure réseau, le registre de conteneurs et Key Vault. Autorisez uniquement les ressources auxquelles le cluster est autorisé à accéder.
Accès depuis l'extérieur : Donner aux identités accès au cluster Kubernetes. Autorisez uniquement les entités externes autorisées à accéder au serveur d’API Kubernetes et à l'Azure Resource Manager.

Accès AKS aux composants Azure

Il existe deux façons de gérer AKS pour Azure access via Microsoft Entra ID : principaux de service ou identités managées pour les ressources Azure.

Parmi les deux méthodes de gestion des access AKS pour Azure, nous vous recommandons d’utiliser des identités managées. Avec les principaux de service, vous devez gérer et changer régulièrement les secrets, soit manuellement, soit de manière programmatique. Avec les identités managées, Microsoft Entra ID gère et effectue l’authentification et la rotation en temps opportun des secrets pour vous.

Nous vous recommandons d’activer et d’utiliser des identités managed dans AKS afin que le cluster puisse interagir avec des ressources de Azure externes via Microsoft Entra ID. Si vous n'utilisez pas immédiatement Microsoft Entra ID intégration, vous pouvez l'ajouter ultérieurement.

Par défaut, le cluster utilise deux identités principales : l’identité du cluster et l’identité kubelet. Les composants du plan de contrôle AKS utilisent l’identité de cluster pour gérer les ressources du cluster, notamment les équilibreurs de charge d’entrée et les adresses IP publiques gérées par AKS. L’identité kubelet s’authentifie auprès de Container Registry. Certains modules complémentaires prennent également en charge l'authentification en utilisant une identité gérée.

Vous devez utiliser des identités gérées lorsque le cluster doit tirer des images d'un registre de conteneurs. Cette action nécessite que le cluster obtienne les informations d’identification du Registre, ce que vous effectuez en accordant l'accès de AcrPull à l'identité gérée par kubelet du cluster au registre. Si vous n’utilisez pas d’identité managée, vous pouvez stocker ces informations dans un secret Kubernetes et l’utiliser imagePullSecrets pour la récupérer. Nous vous déconseillons cette approche, car elle introduit des complexités de sécurité, notamment la nécessité de connaître le secret à l’avance et de le stocker dans le pipeline DevOps. Il ajoute également une surcharge opérationnelle, car vous devez changer le secret.

Dans cette architecture, le cluster accède aux ressources Azure que Microsoft Entra ID sécurise et le cluster effectue des opérations qui prennent en charge les identités gérées. Attribuez le contrôle d'accès basé sur les rôles d'Azure (Azure RBAC) et les autorisations aux identités managées du cluster, en fonction des opérations effectuées par le cluster. Le cluster s’authentifie auprès de Microsoft Entra ID, puis l’accès lui est autorisé ou refusé en fonction des rôles qui lui sont attribués. Voici quelques exemples de l'implémentation de référence suivante où les rôles intégrés Azure sont affectés au cluster :

Le rôle Network Contributor gère la capacité du cluster à contrôler le réseau virtuel spoke. Avec cette attribution de rôle, l’identité affectée par le système de cluster AKS peut fonctionner avec le sous-réseau dédié pour le service de contrôleur d’entrée interne et le serveur d’API privée AKS.
Le rôle Contributeur de zone DNS privé gère la capacité du cluster à lier la zone directement au réseau virtuel satellite qui héberge le cluster. Un cluster privé conserve les enregistrements DNS hors de l’Internet public à l’aide d’une zone de private DNS. Mais il est toujours possible de créer un cluster AKS privé avec une adresse DNS publique. Nous vous recommandons d’interdire explicitement cette fonctionnalité en définissant enablePrivateClusterPublicFQDN à false afin d’empêcher la divulgation de l’adresse IP privée de votre plan de gestion. Envisagez d’utiliser Azure Policy pour appliquer l’utilisation de clusters privés sans enregistrements DNS publics.
Le rôle Monitoring Metrics Publisher gère la capacité du cluster à envoyer des métriques à Azure Monitor.
Le rôle AcrPull gère la capacité du cluster à extraire des images des instances container Registry spécifiées.

Accès au cluster

L’intégration de Microsoft Entra simplifie également la sécurité des accès entrants. Par exemple, vous pouvez utiliser kubectl. Dans un premier temps, vous pouvez exécuter la commande az aks get-credentials pour obtenir les informations d'identification du cluster. Microsoft Entra ID authentifie votre identité auprès des rôles Azure autorisés à obtenir les informations d’identification du cluster. Pour plus d’informations, consultez Autorisations des rôles de clusters disponibles.

AKS prend en charge les accès Kubernetes via Microsoft Entra ID en utilisant Microsoft Entra ID comme fournisseur d'identité intégré au RBAC Kubernetes natif ou en utilisant le RBAC Azure natif pour contrôler les accès au cluster. Les sections suivantes détaillent les deux approches.

Associer RBAC Kubernetes à Microsoft Entra ID

Kubernetes prend en charge RBAC via les objets API suivants :

Un ensemble de permissions que vous définissez en utilisant un objet Role ou ClusterRole pour les permissions à l'échelle du cluster.
Liens qui attribuent des utilisateurs et des groupes ayant l’autorisation de réaliser des actions. Définissez les liaisons en utilisant un objet RoleBinding ou ClusterRoleBinding.

Kubernetes dispose de rôles intégrés tels que cluster-admin, edit, et view. Lier ces rôles aux utilisateurs et groupes Microsoft Entra, puis utiliser l’annuaire d’entreprise pour gérer l'accès. Pour plus d’informations, consultez Use Kubernetes RBAC avec l’intégration de Microsoft Entra.

Veillez à inclure les groupes Microsoft Entra pour les accès aux clusters et d'espaces de noms dans vos examens d'accès Microsoft Entra.

Utiliser Azure RBAC pour l’autorisation Kubernetes

Nous vous recommandons d’utiliser Azure RBAC et Azure attributions de rôles pour appliquer des vérifications d’autorisation sur le cluster. Cette approche d’autorisation s’intègre à l’authentification Microsoft Entra. Vous pouvez attribuer des rôles à divers niveaux, comme le groupe de gestion, l’abonnement ou le groupe de ressources. Tous les clusters sous la portée héritent ensuite d’un ensemble cohérent d’attributions de rôles en ce qui concerne les personnes autorisées à accéder aux objets sur le cluster Kubernetes.

Nous déconseillons d'utiliser le RBAC natif de Kubernetes avec ClusterRoleBindings et RoleBindings.

Pour plus d’informations, consultez Azure RBAC pour l’autorisation Kubernetes.

Comptes locaux

AKS prend en charge l’authentification utilisateur native Kubernetes. Nous vous déconseillons d'utiliser cette méthode pour fournir un accès utilisateur aux clusters. Cette méthode est basée sur des certificats et effectuée en externe à votre fournisseur d’identité principal, ce qui rend difficile le contrôle d'accès centralisé des utilisateurs ainsi que la gouvernance. Gérez toujours l'accès à votre cluster à l’aide de Microsoft Entra ID et configurez votre cluster pour interdire explicitement les accès aux comptes locaux.

Dans cette implémentation de référence, l'accès aux comptes de cluster locaux est explicitement interdit lorsque le système déploie le cluster.

Intégrer Microsoft Entra ID pour la charge de travail

Comme pour avoir une identité managée affectée par le système Azure pour l’ensemble du cluster, vous pouvez affecter des identités managées au niveau du pod. Une identité de charge de travail permet à la charge de travail hébergée d'accéder aux ressources via Microsoft Entra ID. Par exemple, supposons que la charge de travail stocke les fichiers dans Azure Storage. Lorsque le pod doit accéder à ces fichiers, il s’authentifie auprès de la ressource en tant qu’identité gérée d'Azure.

Dans cette implémentation de référence, Microsoft Entra Workload ID sur AKS fournit les identités managées pour les pods. Cette approche s’intègre aux fonctionnalités natives kubernetes pour fédérer avec des fournisseurs d’identité externes. Pour plus d'informations, consultez Fédération d'identité de charge de travail.

Sélectionner un modèle de mise en réseau

Important

Le 31 mars 2028, la mise en réseau kubenet pour Azure Kubernetes Service (AKS) sera retirée.

Pour éviter les interruptions de service, vous devez mettre à niveauvers l'interface réseau de conteneur CNI (Container Networking Interface) d'Azureavant cette date, lorsque les charges de travail s'exécutant sur kubenet pour AKS ne seront plus prises en charge.

AKS prend en charge plusieurs modèles de mise en réseau, notamment kubenet, CNI et Azure superposition CNI. Les modèles CNI sont les modèles les plus avancés et offrent des performances élevées. Lorsqu’ils communiquent entre les pods, les performances de CNI sont similaires aux performances des machines virtuelles dans un virtual network. CNI fournit également un contrôle de sécurité amélioré, car il permet l’utilisation de Azure stratégie réseau. Nous recommandons un modèle de réseau basé sur CNI.

Dans le modèle CNI sans superposition, chaque pod obtient une adresse IP à partir de l’espace d’adressage du sous-réseau. Les ressources au sein du même réseau (ou ressources appairées) peuvent accéder aux pods directement via leur adresse IP. La traduction d’adresses réseau (NAT) n’est pas nécessaire pour acheminer ce trafic.

Dans cette implémentation de référence, nous utilisons Azure CNI Overlay. Il alloue uniquement des adresses IP à partir du sous-réseau du pool de nœuds pour les nœuds et utilise une couche de superposition optimisée pour les adresses IP de pod. Étant donné que le CNI Azure Overlay utilise moins d'adresses IP de réseau virtuel que de nombreuses autres approches, nous vous le recommandons pour les déploiements où les adresses IP sont limitées.

Pour plus d’informations sur les modèles, consultez Configurer la mise en réseau de superposition Azure CNI dans AKS et Meilleures pratiques pour la connectivité et la sécurité réseau dans AKS.

Déployer des ressources d’entrée

Les ressources d'entrée de Kubernetes gèrent le routage et la distribution pour le trafic entrant dans le cluster. Il existe deux parties de ressources d'entrée :

L'équilibreur de charge interne géré par AKS : L'é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 les flux entrants.

Cette architecture utilise Azure Load Balancer. Load Balancer se trouve en dehors du cluster dans un sous-réseau dédié aux ressources d’entrée. Il reçoit le trafic d'Application Gateway et cette communication utilise TLS (sécurité de la couche de transport). Pour plus d’informations sur le chiffrement TLS pour le trafic entrant, consultez la section Flux de trafic d’entrée .
Contrôleur d’entrée : Cet exemple utilise Traefik. Il s’exécute dans le pool de nœuds utilisateur du cluster. Il reçoit le trafic du load balancer interne, met fin au protocole TLS et le transfère aux pods de charge de travail via HTTP.

Le contrôleur d'entrée est un composant essentiel du cluster. Tenez compte des points suivants lorsque vous configurez ce composant.

Limitez le contrôleur d'entrée à un champ d'action spécifique dans le cadre de vos décisions de conception. Par exemple, vous pouvez autoriser le contrôleur à interagir uniquement avec les pods exécutant une charge de travail spécifique.
Évitez de placer des répliques sur le même nœud afin de répartir la charge et d'assurer la continuité des opérations en cas de défaillance d'un nœud. Pour ce faire, utilisez podAntiAffinity.
Limitez la planification des pods sur le seul pool de nœuds utilisateur à l’aide de nodeSelectors. Ce paramètre permet d'isoler les charges de travail et les pods système.
Ouvrez les ports et les protocoles qui permettent à des entités spécifiques d'envoyer du trafic au contrôleur d'entrée. Dans cette architecture, Traefik reçoit uniquement le trafic de Application Gateway.
Configurez les paramètres readinessProbe et livenessProbe qui surveillent la santé des pods à l'intervalle spécifié. Le contrôleur d'entrée doit envoyer des signaux qui indiquent la santé des pods.
Envisagez de restreindre les access du contrôleur d'entrée à des ressources spécifiques et de limiter les actions qu'il peut effectuer. Vous pouvez mettre en œuvre cette restriction par le biais des permissions RBAC de Kubernetes. Par exemple, dans cette architecture, Traefik se voit accorder des permissions pour surveiller, obtenir et lister des services et des terminaisons en utilisant des règles dans l'objet Kubernetes ClusterRole.

Note

Choisissez un contrôleur d’entrée approprié en fonction de vos besoins, de votre charge de travail, de l’ensemble de compétences de l’équipe et de la prise en charge des options technologiques. Plus important encore, votre contrôleur d'entrée doit répondre à vos attentes en matière de SLO.

Traefik est une option open source pour un cluster Kubernetes et figure dans cette architecture à des fins d'illustration. Il montre l’intégration de produits non-Microsoft aux services Azure. Par exemple, l’implémentation montre comment intégrer Traefik à Microsoft Entra Workload ID et Key Vault.

Vous pouvez également utiliser Application Gateway Ingress Controller, qui s’intègre bien à AKS. Application Gateway offre des avantages au-delà de son rôle de contrôleur d’entrée. Il sert de point d’entrée virtual network pour votre cluster et peut observer le trafic entrant dans le cluster. Utilisez Application Gateway si votre application nécessite un web application firewall. Il active également la terminaison TLS.

Paramètres du routeur

Le contrôleur d’entrée utilise des itinéraires pour déterminer où envoyer le trafic. Les itinéraires spécifient le port source auquel le trafic est reçu et les informations sur les ports et protocoles de destination.

Voici un exemple de cette architecture :

Traefik utilise le fournisseur Kubernetes pour configurer les itinéraires. Les options annotations, tls et entrypoints indiquent que les routes sont desservies par HTTPS. L’option middlewares spécifie que seul le trafic provenant du sous-réseau Application Gateway est autorisé. Les réponses utilisent l'encodage gzip si le client l'accepte. Comme Traefik effectue la terminaison TLS, la communication avec les services back-end se fait par HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

Sécuriser le flux réseau

Dans cette architecture, le flux réseau comprend les types de trafic suivants :

Trafic d’entrée du client vers la charge de travail qui s’exécute dans le cluster.
Trafic sortant d’un pod ou d’un nœud dans le cluster vers un service externe.
Trafic pod-à-pod entre les pods. Ce trafic inclut la communication entre le contrôleur d’entrée et la charge de travail. Si votre charge de travail est composée de plusieurs applications déployées dans le cluster, la communication entre ces applications entre également dans cette catégorie.
Trafic de gestion entre le client et le serveur d’API Kubernetes.

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

Cette architecture dispose de plusieurs couches de sécurité visant à sécuriser tous les types de trafic.

Flux de trafic d’entrée

L’architecture accepte uniquement les demandes TLS chiffrées du client. TLS v1.2 est la version minimale autorisée avec un ensemble restreint de chiffres. La correspondance stricte de l'indication de nom de serveur (SNI) est activée. Le protocole TLS de bout en bout est configuré via Application Gateway à l’aide de deux certificats TLS différents, comme illustré dans le diagramme suivant.

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

Le client envoie une requête HTTPS au nom de domaine : bicycle.contoso.com. Ce nom est associé à un enregistrement DNS A à l’adresse IP publique de Application Gateway. Ce trafic est chiffré afin de garantir que le trafic entre le navigateur du client et la passerelle ne puisse pas être inspecté ou modifié.
Application Gateway a un pare-feu d'applications web intégré et négocie le TLS pour bicycle.contoso.com, ce qui autorise uniquement les chiffrements sécurisés. Application Gateway est un point de terminaison TLS, ce qui est important, car Application Gateway'web application firewall doit inspecter la demande et la réponse en texte clair. Key Vault stocke le certificat TLS. Le cluster y accède avec une identité managée affectée par l’utilisateur qui s’intègre à Application Gateway. Pour plus d'informations, consultez la terminaison de TLS avec des certificats de Key Vault.

La Passerelle d'Applications traite les règles d’inspection du pare-feu d'applications web et exécute des règles de routage qui transfèrent le trafic au back-end configuré.
Lorsque le trafic passe de Application Gateway au serveur principal, il est chiffré à nouveau avec un autre certificat TLS, qui est un caractère générique pour *.aks-ingress.contoso.com, car il est transféré vers le load balancer interne. Ce nouveau chiffrement permet de s'assurer que le trafic non sécurisé ne circule pas dans le sous-réseau du cluster.
Le contrôleur d’entrée reçoit le trafic chiffré via le load balancer. Le contrôleur est un autre point de terminaison TLS pour *.aks-ingress.contoso.com et redirige le trafic vers les modules de charge de travail via HTTP. Les certificats sont stockés dans Key Vault, et le pilote CSI (Container Storage Interface) les monte dans le cluster. Pour plus d’informations, consultez Ajouter la gestion des secrets.

Vous pouvez mettre en œuvre un trafic TLS de bout en bout à chaque saut dans le module de charge de travail. Assurez-vous de mesurer les performances, la latence et les impacts opérationnels lors de la décision de sécuriser le trafic entre pods. Pour la plupart des clusters monolocataires, avec RBAC du plan de contrôle approprié et des pratiques de cycle de vie de développement logiciel matures, il suffit de chiffrer TLS jusqu'au contrôleur d'entrée et de protéger avec Web Application Firewall. Cette approche minimise les frais généraux liés à la gestion de la charge de travail et les frais généraux liés aux mauvaises performances du réseau. Ce sont vos exigences de charge de travail et de conformité qui déterminent l'endroit où vous effectuez la terminaison TLS.

Flux du trafic de sortie

Dans cette architecture, nous recommandons que tout le trafic de sortie du cluster passe par Azure Firewall. Vous pouvez également utiliser votre propre appliance virtuelle de réseau similaire. Nous vous déconseillons d'autres options de sortie, comme Azure passerelle NAT ou un proxy HTTP car ils ne fournissent pas d'inspection du trafic réseau. Pour le contrôle Zero Trust et la capacité à inspecter le trafic, envoyez tout le trafic de sortie via Azure Firewall. Implémentez cette configuration avec des itinéraires définis par l’utilisateur (UDR). Le tronçon suivant de l’itinéraire est l’adresse IP private de Azure Firewall. Azure Firewall détermine s’il faut bloquer ou autoriser le trafic de sortie en fonction des règles que vous définissez ou des règles intégrées de renseignement sur les menaces.

Une alternative à Azure Firewall consiste à utiliser la fonctionnalité proxy HTTP AKS. Tout le trafic qui quitte le cluster est dirigé vers l'adresse IP du proxy HTTP, qui le redirige ou le laisse tomber.

Pour les deux méthodes, consultez les règles de trafic réseau sortant requises pour AKS.

Note

Si vous utilisez un load balancer public comme point public pour le trafic d’entrée et le trafic de sortie via Azure Firewall à l’aide des UDR, vous pouvez voir un scénario de routage asymmétrique. Cette architecture utilise des équilibreurs de charge internes dans un sous-réseau d’entrée dédié derrière Application Gateway. Ce choix de conception améliore la sécurité et élimine également les problèmes de routage asymétrique. Vous pouvez également acheminer le trafic d'entrée via le pare-feu avant ou après Application Gateway, mais cette approche n'est pas nécessaire pour la plupart des situations, et nous ne le recommandons pas. Pour plus d’informations sur le routage asymétrique, consultez Integrate Firewall avec un Azure standard load balancer.

Une exception au contrôle Zero Trust est lorsque le cluster doit communiquer avec d’autres ressources Azure. Par exemple, le cluster peut avoir besoin d’extraire une image mise à jour à partir du registre de conteneurs ou des secrets de Key Vault. Dans ces scénarios, nous vous recommandons d’utiliser Private Link.

L'avantage d'utiliser Private Link est que des sous-réseaux spécifiques atteignent directement le service, et que le trafic entre le cluster et les services ne passe pas par Internet. Un inconvénient est que Private Link a besoin d’une configuration supplémentaire au lieu d’utiliser le service cible sur son point de terminaison public. En outre, tous les services Azure ou produits ne prennent pas en charge Private Link. Dans ces cas, envisagez d’activer un point de terminaison de service réseau virtuel sur le sous-réseau pour accéder au service.

Si Private Link ou points de terminaison de service ne sont pas une option, vous pouvez accéder à d'autres services via leurs points de terminaison publics et contrôler access par le biais de règles de Azure Firewall et du pare-feu intégré au service cible. Étant donné que ce trafic passe par les adresses IP statiques du pare-feu, vous pouvez ajouter ces adresses à la liste d’autorisation IP du service.

L’un des inconvénients de la connexion à des services Azure via des points de terminaison publics est que Azure Firewall a ensuite besoin de règles supplémentaires pour s’assurer qu’il autorise uniquement le trafic à partir d’un sous-réseau spécifique. Prendre en compte ces adresses lorsque vous envisagez d’utiliser plusieurs adresses IP pour le trafic de sortie avec Azure Firewall. Sinon, vous risquez l'épuisement des ports. Pour plus d’informations sur la planification de plusieurs adresses IP, consultez Créer une Azure Firewall avec plusieurs adresses IP.

Trafic entre pods

Par défaut, un pod peut accepter le trafic de n’importe quel autre pod du cluster. Utilisez Kubernetes NetworkPolicy pour restreindre le trafic réseau entre les pods. Appliquez soigneusement des stratégies, ou vous pouvez avoir une situation où un flux réseau critique est bloqué. Autorisez uniquement des chemins de communication spécifiques, selon les besoins, comme le trafic entre le contrôleur d’entrée et la charge de travail. Pour plus d’informations, consultez les stratégies Network.

Activez la stratégie réseau lorsque vous configurez le cluster, car vous ne pouvez pas l’ajouter ultérieurement. Vous avez le choix entre plusieurs technologies qui mettent en œuvre NetworkPolicy. Nous vous recommandons d'utiliser la stratégie réseau Azure, qui nécessite Azure CNI. Parmi les autres options, citons la stratégie réseau Calico, une option open source bien connue. Envisagez Calico s’il vous faut gérer des stratégies réseau au niveau du cluster. Calico n'est pas couvert par des Azure support standard.

Pour plus d’informations, consultez Differences between Azure network policy engines.

Trafic de gestion

Dans le cadre de l’exécution du cluster, le serveur d’API Kubernetes reçoit le trafic des ressources qui souhaitent effectuer des opérations de gestion sur le cluster, telles que les demandes de création de ressources pour mettre à l’échelle le cluster. Par exemple, ces ressources incluent le pool d’agents de build dans un pipeline DevOps, une instance Azure Bastion dans le sous-réseau Azure Bastion et les pools de nœuds eux-mêmes. Au lieu d’accepter ce trafic de gestion à partir de toutes les adresses IP, nous vous recommandons de configurer un cluster AKS privé.

Pour plus d’informations, consultez Plages d’adresses IP autorisées par le serveur APIDefine.

Nous vous recommandons de déployer votre cluster AKS en tant que cluster privé. Tout le trafic du plan de contrôle et du pool de nœuds reste sur votre réseau privé et n’est pas exposé à l’Internet public. Cette implémentation de référence configure un cluster privé en utilisant l'intégration du réseau virtuel du serveur d’API. Les environnements inférieurs peuvent envisager de détendre cette recommandation de cluster privé pour des raisons pratiques. Toutefois, les clusters AKS de production doivent toujours être déployés en tant que clusters privés pour une base de référence de déploiement sécurisée.

Le trafic privé vers un cluster AKS privé peut provenir du virtual network spoke, des réseaux appairés ou des points de terminaison privés dans des réseaux distants. Bien que les nœuds AKS vivent naturellement dans le spoke, les opérateurs effectuant des tâches d’administration nécessitent un chemin réseau dédié pour atteindre le serveur d’API AKS en privé. Vous pouvez établir cette connectivité de la manière suivante :

Tunnelling : Utilisez Azure Bastion pour ouvrir un tunnel directement sur le serveur d'API du cluster.
Jump-box : Provisionnez un jump-box VM et utilisez Azure Bastion pour vous connecter à celle-ci via SSH ou RDP. À partir de là, l’opérateur effectue des requêtes sur le serveur d’API du cluster par le biais de son adresse IP privée.

Dans l’implémentation de référence, nous utilisons Azure Bastion pour tunneliser vers le serveur d’API AKS lors de l’exécution d’opérations de gestion de cluster. En général, cette approche est plus simple à gérer, moins coûteuse que le déploiement et la gestion d’une machine virtuelle de rebond, et moins complexe à coordonner entre plusieurs opérateurs. Toutefois, vous pouvez choisir d’utiliser une machine virtuelle de rebond si vous avez l’une de ces exigences :

Les opérateurs utilisent des appareils non sécurisés. Une machine virtuelle de jump-box peut offrir un renforcement de la sécurité plus fort si vos appareils clients ne sont pas approuvés.
Les opérateurs se connectent via des réseaux instables. Une machine virtuelle de rebond peut fournir une connexion plus stable au cluster, en particulier pour les opérations de gestion par lots ou longues.
Les opérateurs utilisent des outils de diagnostic avancés. Certains types d’outils de diagnostic, tels que la capture de paquets, peuvent ne pas bien fonctionner avec les approches de tunneling.

Ajouter la gestion des secrets

Stockez les secrets dans un magasin de clés managé, comme Key Vault. L’avantage est qu’un magasin de clés managé gère la rotation des secrets. Il fournit un chiffrement fort et un journal d’audit d’accès. En outre, les secrets de base sont exclus du pipeline de déploiement. Dans cette architecture, un pare-feu pour Key Vault est activé et configuré, et Private Link est utilisé pour se connecter à des ressources Azure, permettant à Key Vault d'accéder aux secrets et aux certificats.

Key Vault est bien intégré à d’autres services Azure. Utilisez la fonctionnalité intégrée de ces services pour accéder aux secrets. Pour plus d’informations sur la façon dont Application Gateway accède aux certificats TLS pour le flux d’entrée, consultez la section Flux de traficIngress.

Le modèle d'autorisation RBAC Azure pour Key Vault vous permet d'assigner les identités de charge de travail au rôle d'utilisateur de secrets Key Vault ou de Lecteur Key Vault, et d'accéder aux secrets. Pour plus d’informations, consultez Access Key Vault à l’aide de Azure RBAC.

Accéder aux secrets du cluster

Vous devez utiliser des identités de charge de travail pour permettre à un pod d’accéder aux secrets d’un magasin spécifique. Pour faciliter le processus de récupération, utilisez un pilote CSI pour le magasin de secrets. Lorsque le module a besoin d'un secret, le pilote se connecte au répertoire spécifié, récupère un secret sur un volume et monte ce volume dans le cluster. Le pod peut ensuite récupérer le secret à partir du système de fichiers du volume.

Le pilote CSI dispose de nombreux fournisseurs à des fins de prise en charge de différents magasins gérés. Cette implémentation utilise le Key Vault avec le pilote CSI du magasin de secrets. Le module complémentaire récupère le certificat TLS de Key Vault et charge le pilote dans le pod qui exécute le contrôleur d’entrée. Cette opération a lieu lors de la création du pod, et le volume stocke à la fois les clés publiques ainsi que les clés privées.

Stockage des charges de travail

Dans cette architecture, la charge de travail est sans état. Si vous devez stocker l’état, nous vous recommandons de le sauvegarder en dehors du cluster. Les instructions relatives à l’état de la charge de travail n’entrent pas dans le cadre de cet article.

Pour plus d’informations, consultez Storage options pour les applications dans AKS.

Gestion des stratégies

Un moyen efficace de gérer un cluster AKS est d'appliquer la gouvernance par le biais de stratégies. Kubernetes met en œuvre des stratégies par l'intermédiaire d'Open Policy Agent (OPA) Gatekeeper. Pour AKS, fournissez des stratégies via Azure Policy. Chaque stratégie s'applique à tous les clusters de son périmètre. OPA Gatekeeper s'occupe de l'application de la stratégie dans le cluster et journalise toutes les vérifications de la stratégie. Les changements de stratégie ne sont pas immédiatement reflétés dans votre cluster, attendez-vous donc à des délais.

Pour gérer vos clusters AKS, vous pouvez utiliser Azure Policy de plusieurs façons :

Empêcher ou restreindre le déploiement de clusters AKS dans un groupe de ressources ou un abonnement. Appliquer des normes pour votre organisation. Par exemple, vous pouvez suivre une convention de dénomination ou spécifier une balise.
Sécurisez votre cluster AKS via Azure Policy pour Kubernetes.

Un exemple courant d’utilisation d’une stratégie concerne la gouvernance et la validation des images conteneur. Les images conteneur peuvent être une source de vulnérabilités, et certaines organisations nécessitent que les images conteneur non approuvées soient validées à l’aide d’un outil d’analyse d’images conteneur, puis approuvées, avant de pouvoir être utilisées dans un cluster de production. Vous pouvez appliquer ce processus à l’aide de Azure Policy et bloquer le déploiement d’images conteneur non approuvées sur le cluster. Pour plus d’informations, consultez le modèle Quarantine.

Lorsque vous définissez des stratégies, appliquez-les en fonction des exigences de la charge de travail. Tenez compte de ces facteurs :

Déterminez s’il faut définir une collection de stratégies, appelées initiatives ou choisir des stratégies individuelles. Azure Policy fournit deux initiatives intégrées : de base et restreinte. Chaque initiative est une collection de stratégies intégrées applicables à un cluster AKS. Nous vous recommandons de sélectionner une initiative and de choisir d’autres stratégies pour le cluster et les ressources, telles que Container Registry, Application Gateway ou Key Vault, qui interagissent avec le cluster. Choisissez les stratégies en fonction des exigences de votre organisation.
Déterminez si vous souhaitez auditer ou refuser l’action. En mode Audit , l’action est autorisée mais marquée comme non conforme. Prévoyez des processus pour vérifier les états de non-conformité à intervalles réguliers et prendre les mesures nécessaires. En mode Refus , l’action est bloquée car elle enfreint la stratégie. Soyez prudent lorsque vous choisissez le mode Refuser, car il peut être trop restrictif pour que la charge de travail fonctionne.
Déterminez si vous avez des zones dans votre charge de travail qui ne doivent pas être conformes par conception. Azure Policy peut spécifier des espaces de noms Kubernetes qui sont exemptés de l’application de politique. Nous vous recommandons d’appliquer toujours des stratégies en mode Audit afin de connaître ces instances.
Déterminez si vous avez des exigences qui ne sont pas couvertes par les stratégies intégrées. Vous pouvez créer une définition de Azure Policy personnalisée qui applique vos stratégies OPA Gatekeeper personnalisées. N’appliquez pas aucune stratégie personnalisée directement au cluster. Pour plus d’informations, consultez Créer et affecter des définitions de stratégie personnalisées.
Déterminez si vous avez des exigences à l’échelle de l’organisation. Si c’est le cas, ajoutez ces stratégies au niveau du groupe d’administration. Votre cluster doit également attribuer ses propres stratégies spécifiques aux charges de travail, même si votre organisation dispose de stratégies génériques.
Déterminez si vous devez affecter des stratégies Azure à des étendues spécifiques. Vérifiez que les stratégies de production sont également validées par rapport à votre environnement de préproduction . Dans le cas contraire, lorsque vous déployez sur votre environnement de production, vous risquez de rencontrer des restrictions supplémentaires inattendues que vous n’avez pas pris en compte dans la préproduction.

Cette implémentation de référence active Azure Policy lors de la création du cluster AKS. L’initiative restrictive est affectée en mode Audit pour obtenir une visibilité sur la non-conformité.

L'implémentation définit également des stratégies supplémentaires qui ne font partie d'aucune initiative intégrée. Ces stratégies sont définies en mode Refus . Par exemple, une stratégie est en place pour s'assurer que les images ne sont tirées que de l'instance Container Registry déployée.

Envisagez de créer vos propres initiatives personnalisées. Regroupez les stratégies applicables à votre charge de travail dans une seule affectation.

Pour observer comment Azure Policy fonctionne à partir de votre cluster, vous pouvez accéder aux journaux des pods pour tous les pods du namespace gatekeeper-system et les journaux des pods azure-policy et azure-policy-webhook dans le namespace kube-system.

Scalabilité des nœuds et des pods

Avec une demande croissante, Kubernetes peut effectuer une extension horizontale en ajoutant davantage de pods aux nœuds existants, via la mise à l’échelle automatique horizontale des pods. Lorsque Kubernetes ne peut plus programmer davantage de pods, le nombre de nœuds doit être augmenté par le biais de l'autoscaling de cluster AKS. Une solution de mise à l’échelle complète doit pouvoir faire évoluer à la fois les réplicas de pods et le nombre de nœuds dans le cluster.

Deux approches sont possibles : la mise à l’échelle automatique ou la mise à l’échelle manuelle.

L'autoscaling et l'approche manuelle nécessitent tous deux que vous surveilliez et définissiez des alertes sur l'utilisation du processeur ou des mesures personnalisées. Pour la mise à l'échelle des pods, l'opérateur de votre application peut augmenter ou diminuer le nombre de répliques de pods en ajustant le ReplicaSet via les API de Kubernetes. Pour la mise à l'échelle du cluster, une méthode consiste à recevoir une notification lorsque le planificateur Kubernetes échoue. Une autre méthode consiste à surveiller les pods en attente au fil du temps. Vous pouvez ajuster le nombre de nœuds via le Azure CLI ou le Azure portal.

Nous vous recommandons d’utiliser l’approche de mise à l’échelle automatique, car certains des mécanismes manuels sont intégrés au générateur de mise à l’échelle automatique.

En règle générale, commencez par tester les performances avec un nombre minimum de pods et de nœuds. Utilisez ces valeurs pour déterminer l’attente de base. Ensuite, utilisez une combinaison de mesures de performance et de mise à l'échelle manuelle pour localiser les goulots d'étranglement et comprendre la réponse de l'application à la mise à l'échelle. Enfin, utilisez ces données pour définir les paramètres de mise à l’échelle automatique.

Autoscaler horizontal de pods

L’autoscaler de pods horizontaux (HPA, Horizontal Pod Autoscaler) est une ressource Kubernetes qui ajuste dynamiquement le nombre de pods.

Dans la ressource HPA, nous vous recommandons de définir le nombre minimal et maximal de réplicas. Ces valeurs limitent les limites de la mise à l'échelle automatique.

Le HPA peut évoluer en fonction de l'utilisation du processeur, de l'utilisation de la mémoire et de mesures personnalisées. Seule l’utilisation du processeur est fournie en mode natif. La définition HorizontalPodAutoscaler spécifie des valeurs cibles pour les mesures. Par exemple, la spécification définit l'utilisation cible du processeur. Lorsque les pods sont en cours d'exécution, le contrôleur HPA utilise l'API Kubernetes Metrics pour vérifier l'utilisation du processeur de chaque pod. Il compare cette valeur à l'utilisation cible et calcule un ratio. Il utilise ensuite ce ratio pour déterminer si les pods sont surallocatés ou sous-allocatés. Il s’appuie sur le planificateur Kubernetes pour affecter de nouveaux pods aux nœuds ou supprimer des pods des nœuds.

Une condition de concurrence peut se produire, par exemple lorsque le HPA effectue une vérification avant qu'une opération de mise à l'échelle ne soit terminée. Ainsi, le résultat peut être un calcul de ratio incorrect. Pour plus d’informations, consultez Cooldown des événements de mise à l’échelle.

Si votre charge de travail est pilotée par des événements, une option open source populaire est Kubernetes event-driven autoscaling (KEDA). Considérez KEDA si une source d’événement, telle que la file d’attente de messages, pilote votre charge de travail plutôt que votre charge de travail liée au processeur ou à la mémoire. KEDA prend en charge de nombreuses sources d'événements ou scalers. Utilisez la liste des sources d’événements que KEDA peut mettre à l’échelle avec les scalers KEDA. La liste inclut le scaler Azure Monitor, qui est un moyen pratique de mettre à l’échelle les charges de travail KEDA en fonction des métriques Azure Monitor.

Autoscaler de cluster

Le cluster autoscaler est un composant complémentaire AKS qui met à l’échelle le nombre de nœuds dans un pool de nœuds. Ajoutez-le pendant le provisionnement du cluster. Vous devez disposer d’un autoscaler de cluster distinct pour chaque pool de nœuds utilisateur.

Le planificateur Kubernetes déclenche l'autoscaler de cluster. Lorsque le planificateur Kubernetes ne parvient pas à planifier un pod en raison de contraintes de ressources, le programme de mise à l’échelle automatique configure automatiquement un nouveau nœud dans le pool de nœuds. De même, l’autoscaler de cluster vérifie la capacité inutilisée des nœuds. Si le nœud ne s’exécute pas à une capacité attendue, les pods sont déplacés vers un autre nœud et le nœud inutilisé est supprimé.

Lorsque vous activez l'autoscaler, définissez le nombre maximum et minimum de nœuds. Les valeurs recommandées dépendent des attentes en matière de performances de la charge de travail, de l’augmentation de volume souhaitée, ainsi que des implications en termes de coût. Le nombre minimal correspond à la capacité réservée pour ce pool de nœuds. Dans cette implémentation de référence, la valeur minimale est fixée à deux en raison de la simplicité de la charge de travail.

Pour le pool de nœuds système, la valeur minimale recommandée est de trois.

Décisions de continuité des activités :

Pour maintenir la continuité des activités, définissez le SLO pour l'infrastructure et votre application. Pour plus d’informations, consultez Recommendations pour définir des cibles de fiabilité. Passez en revue les conditions de contrat de niveau de service (SLA) pour AKS dans l'article SLA pour les services en ligne le plus récent.

Nœuds de cluster

Pour atteindre le niveau minimum de disponibilité des charges de travail, vous devez disposer de plusieurs nœuds dans un pool de nœuds. En cas de défaillance d'un nœud, un autre nœud du même pool de nœuds et du même cluster peut continuer à exécuter l'application. Pour des raisons de fiabilité, nous recommandons trois nœuds pour le pool de nœuds système. Pour le pool de nœuds utilisateur, commencez par deux nœuds au minimum. Si vous avez besoin d’une disponibilité ou d’une capacité supérieure, étendez pour ajouter d’autres nœuds.

Isolez votre application des services système en la plaçant dans un pool de nœuds distinct, appelé pool de nœuds utilisateur. Ainsi, les services Kubernetes s’exécutent sur des nœuds dédiés et ne sont pas en concurrence avec votre charge de travail. Nous vous recommandons d'utiliser des balises, des étiquettes et des taints pour identifier le pool de nœuds et planifier votre charge de travail. Vérifiez que votre pool de nœuds système est marqué par le CriticalAddonsOnly taint pour empêcher les pods d’application d’être déployés sur les pools de nœuds système.

Les tâches d’entretien régulières sur votre cluster, telles que les mises à jour en temps voulu, sont cruciales pour la fiabilité. Nous vous recommandons également de surveiller l'intégrité des modules à l'aide de sondes.

Disponibilité des pods

Spécifiez les besoins en ressources de pod : Nous vous recommandons de spécifier les besoins en ressources de pod dans vos déploiements. Le planificateur peut ensuite planifier comme il se doit le pod. La fiabilité est fortement réduite si vos modules ne peuvent pas être planifiés.
Définissez les budgets d’interruption des pods : Ce paramètre détermine le nombre de réplicas dans un déploiement qui peuvent être interrompus pendant une mise à jour ou une opération de mise à niveau. Pour plus d’informations, consultez Budgets d’interruption de pods.

Configurez plusieurs réplicas dans le déploiement pour la gestion des perturbations telles que les défaillances matérielles. Pour les événements planifiés tels que les mises à jour et les mises à niveau, un budget d’interruption peut vous aider à garantir que le nombre nécessaire de répliques de pods existe pour gérer la charge d’application attendue.
Définissez des quotas de ressources sur les espaces de noms de charge de travail : Le quota de ressources sur un espace de noms permet de s’assurer que les demandes et limites de pod sont correctement définies sur un déploiement. Pour plus d’informations, consultez Imposer des quotas de ressources.

Note

Si vous définissez des quotas de ressources au niveau du cluster, des problèmes peuvent se produire si vous déployez des charges de travail externes qui n’ont pas de demandes et de limites appropriées. Lorsque vous définissez des quotas au niveau de l’espace de noms, il garantit qu’ils s’appliquent uniquement à vos composants de charge de travail.
Définissez les demandes et limites de pod : Définissez des requêtes et des limites pour permettre à Kubernetes d’allouer efficacement des ressources processeur et mémoire aux pods. Il vous offre une densité de conteneur plus élevée sur un nœud. Les requêtes et les limites peuvent également augmenter votre fiabilité tout en réduisant vos coûts en raison d'une meilleure utilisation du matériel.

Pour estimer les limites d'une charge de travail, effectuez des tests et établissez une base de référence. Dans un premier temps, utilisez des valeurs similaires pour les demandes et les limites. Ensuite, ajustez progressivement ces valeurs jusqu’à ce que vous établissiez le seuil qui provoque l’instabilité dans le cluster.

Vous pouvez spécifier des requêtes et des limites dans vos manifestes de déploiement. Pour plus d’informations, consultez Set pod requests and limits.

Zones de disponibilité

Pour vous protéger contre certains types de pannes, utilisez availability zones si la région les prend en charge. Les composants du plan de contrôle et les nœuds des pools de nœuds sont alors redondants interzones, ce qui signifie qu’ils sont répartis entre plusieurs zones. Si une zone entière est indisponible, un nœud situé dans une autre zone de la région reste disponible. Chaque pool de nœuds correspond à un ensemble distinct de machines virtuelles, qui gère les instances de nœuds et leur extensibilité. Le service AKS gère les opérations et la configuration des ensembles d'échelle. Voici quelques considérations à prendre en compte lorsque vous activez plusieurs zones :

Infrastructure entière : Choisissez une région qui prend en charge les zones de disponibilité. Pour plus d’informations, consultez Limitations. Pour bénéficier d'un contrat SLA de disponibilité, vous devez choisir le niveau Standard ou Premium. Le SLA de disponibilité est plus élevé lorsque vous utilisez des zones de disponibilité.
Cluster : Vous ne pouvez définir availability zones que lorsque vous créez le pool de nœuds. Elles ne peuvent pas être modifiées ultérieurement. Les tailles de nœuds doivent être prises en charge dans toutes les zones afin de permettre la distribution attendue. L'ensemble de machines virtuelles sous-jacent fournit la même configuration matérielle dans toutes les zones.

La redondance de zone s’applique non seulement aux pools de nœuds, mais également au plan de contrôle. Le plan de contrôle AKS s'étend sur les zones demandées, comme les pools de nœuds. Si vous n'utilisez pas la prise en charge des zones dans votre cluster, il n'est pas garanti que les composants du plan de contrôle se répartissent entre les zones de disponibilité.
Ressources dépendantes : Pour bénéficier de la résilience grâce à l'utilisation des availability zones, toutes les dépendances de service doivent également prendre en charge les zones. Si un service dépendant ne prend pas en charge les zones, il est possible qu'une défaillance de la zone entraîne la défaillance de ce service.

Par exemple, supposons que votre charge de travail utilise une base de données qui n’est pas résiliente aux zones. Si une défaillance se produit, le nœud AKS peut se déplacer vers une autre zone, mais la base de données ne se déplace pas avec le nœud vers cette zone, de sorte que votre charge de travail est interrompue.

Par souci de simplicité dans cette architecture, AKS est déployé dans une seule région avec des pools de nœuds qui s’étendent sur trois availability zones. D’autres ressources de l’infrastructure, telles que Azure Firewall et Application Gateway, sont également déployées dans la même région avec la prise en charge de plusieurs zones. La géo-réplication est activée pour Container Registry.

Plusieurs régions

Lorsque vous activez les zones de disponibilité, la couverture n'est pas suffisante en cas d'échec improbable d'une région entière. Pour obtenir une plus grande disponibilité, exécutez plusieurs clusters AKS dans différentes régions.

Préférez les régions paired lorsqu'elles sont disponibles. L'utilisation de régions appairées présente l'avantage d'être fiable lors des mises à jour de la plate-forme. Azure s'assure qu’une seule région de la paire est mise à jour à la fois. Certaines régions n'ont pas de paires. Si votre région n'est pas appairée, vous pouvez toujours déployer une solution multirégionale en sélectionnant d'autres régions à utiliser. Envisagez d'utiliser un pipeline d'intégration et de livraison continues (CI/CD), que vous configurez pour orchestrer la récupération en cas de défaillance d'une région. Des outils DevOps spécifiques comme Flux peuvent faciliter les déploiements multirégions.
Indiquez l’emplacement où le service redondant a son instance secondaire si une ressource Azure prend en charge la géoredondance. Par exemple, en activant la géoréplication pour Container Registry, elle réplique automatiquement des images dans les régions sélectionnées Azure. Il fournit également un accès continu aux images même si la région principale subit une panne.
Selon vos besoins, optez pour un routeur de trafic capable de répartir le trafic entre les zones ou régions. Cette architecture déploie Load Balancer, car elle peut distribuer le trafic non web entre les zones. Si vous devez distribuer le trafic entre les régions, envisagez Azure Front Door. Pour d'autres options, consultez Choisir un équilibreur de charge.

Note

La base de référence AKS pour les clusters multirégions, exemple de scénario étend l’architecture de cet article pour inclure plusieurs régions dans une configuration active-active et hautement disponible.

Récupération d’urgence

Dans l’idéal, si une défaillance se produit dans la région primaire, vous pouvez rapidement basculer vers une instance d’une autre région. Vous pouvez précréer un cluster ou attendre de le créer jusqu’à ce qu’il soit nécessaire. Tenez compte des recommandations suivantes :

Utilisez plusieurs régions. Si votre région principale a une région jumelée, utilisez cette paire. Sinon, sélectionnez des régions en fonction de vos exigences en matière de résidence des données et de latence.
Utilisez une charge de travail sans état que vous pouvez répliquer efficacement. Si vous devez stocker l’état dans le cluster, que nous vous déconseillons, veillez à sauvegarder les données fréquemment dans une autre région.
Intégrez la stratégie de récupération, comme la réplication dans une autre région, dans le cadre du pipeline DevOps pour répondre à votre SLO.
Configurez chaque service Azure à l’aide de fonctionnalités qui prennent en charge la récupération d’urgence. Par exemple, dans cette architecture, Container Registry est activé pour la géo-réplication. Si une région tombe en panne, vous pouvez toujours tirer des images de la région répliquée.
Déployez votre infrastructure en tant que code, y compris votre cluster AKS et tout autre composant dont vous avez besoin. Si vous devez déployer dans une autre région, vous pouvez réutiliser les scripts ou les modèles pour créer une instance identique.

Sauvegarde de cluster

Pour de nombreuses architectures, vous pouvez configurer un nouveau cluster et le retourner à l’état d’exploitation via le démarrage du cluster GitOps, suivi du déploiement d’applications. Mais s’il existe un état de ressource critique, comme les cartes de configuration, les travaux et les secrets qui ne peuvent pas être capturés dans votre processus de démarrage, envisagez votre stratégie de récupération. Nous vous recommandons d'exécuter les charges de travail sans état avec Kubernetes. Si votre architecture implique un état basé sur le disque, vous devez également prendre en compte votre stratégie de récupération pour ce contenu.

Lorsque la sauvegarde de cluster doit faire partie de votre stratégie de récupération, vous devez installer une solution qui correspond à vos besoins métier au sein du cluster. Cet agent est responsable de la propagation de l'état des ressources du cluster vers une destination de votre choix et de la coordination des instantanés de volumes persistants basés sur disque Azure.

VMware Velero est un exemple de solution de sauvegarde Kubernetes courante que vous pouvez installer et gérer directement. Vous pouvez également utiliser l’extension de sauvegarde AKS pour fournir une implémentation Velero managée. L’extension de sauvegarde AKS prend en charge la sauvegarde des ressources Kubernetes et des volumes persistants, avec des planifications et une étendue de sauvegarde externalisées en tant que configuration de coffre dans Azure Backup.

L'implémentation de référence n'implémente pas la sauvegarde, ce qui implique des ressources Azure supplémentaires pour gérer, surveiller, acheter et sécuriser. Ces ressources peuvent inclure un compte Azure Storage, un coffre Azure Backup et une configuration, ainsi que la fonctionnalité accès approuvé. Au lieu de cela, GitOps combiné avec l’intention d’exécuter une charge de travail sans état est la solution de récupération.

Choisissez et validez une solution de sauvegarde qui répond à votre objectif métier, qui inclut votre objectif de point de récupération défini et votre objectif de temps de récupération. Définissez votre processus de récupération dans un runbook d'équipe et pratiquez-le pour toutes les charges de travail critiques.

Contrat SLA pour le serveur API Kubernetes

Vous pouvez utiliser AKS en tant que service gratuit, mais ce niveau ne fournit pas de contrat SLA soutenu financièrement. Pour obtenir un contrat SLA, vous devez choisir le niveau Standard. Nous recommandons que tous les clusters de production utilisent le niveau Standard. Réservez le niveau Gratuit pour les clusters de préproduction, et le Premium uniquement pour les charges de travail critiques pour la mission. Lorsque vous utilisez Azure availability zones, le contrat SLA du serveur d’API Kubernetes est supérieur. Vos pools de nœuds et autres ressources sont couverts par leurs propres accords de niveau de service.

Pour plus d’informations sur les contrats SLA spécifiques pour chaque service, consultez SLA pour online services.

Compromis

Il existe un compromis entre le coût et la disponibilité pour le déploiement de l’architecture entre les zones et en particulier les régions. Certaines fonctionnalités de réplication, telles que la géoréplication dans Container Registry, sont disponibles dans les références SKU Premium, ce qui est plus coûteux. Pour les déploiements multirégionaux, le coût augmente également car des frais de bande passante s'appliquent lorsque le trafic se déplace d'une région à l'autre.

En outre, attendez-vous à une petite quantité de latence réseau supplémentaire dans la communication entre les nœuds entre les zones, et une latence plus significative dans la communication entre les régions. Mesurez l'effet de cette décision architecturale sur votre charge de travail.

Tester la conception via des simulations et des basculements forcés

Testez la fiabilité de votre solution en effectuant des tests de basculement forcé avec des pannes simulées. Les simulations peuvent inclure l'arrêt d'un nœud, la mise hors service de toutes les ressources AKS dans une zone particulière pour simuler une défaillance zonale, ou l'invocation d'une défaillance de dépendance externe. Vous pouvez également utiliser Azure Chaos Studio pour simuler différents types de pannes dans Azure et sur le cluster.

Pour plus d’informations, consultez Chaos Studio.

Surveiller et collecter des logs et des mesures

Nous vous recommandons Azure Monitor services de surveillance Kubernetes pour surveiller les performances des charges de travail des conteneurs, car vous pouvez afficher les événements en temps réel. Azure Monitor capture les journaux de conteneur à partir des pods en cours d'exécution et les agrège afin d'être affichés. Il recueille également des informations à partir de l'API de mesures sur l'utilisation de la mémoire et du processeur pour surveiller l'intégrité des ressources et des charges de travail en cours d'exécution. Vous pouvez également utiliser Azure Monitor pour analyser les performances lorsque les pods sont mis à l'échelle. Il inclut la télémétrie qui est essentielle pour la surveillance, l'analyse et la visualisation des données collectées.

Activer la collecte de logs depuis les pods

Le schéma de journal ContainerLogV2 est conçu pour capturer les journaux de conteneur à partir de pods Kubernetes dans une approche simplifiée. Les entrées de journal sont consolidées dans la table ContainerLogV2 dans un espace de travail Log Analytics Azure.

Dans un cluster AKS, il existe deux méthodes principales pour configurer la collecte des journaux de pod. Les deux approches vous permettent de personnaliser les paramètres. Vous pouvez filtrer des espaces de noms, ajuster les intervalles de collecte, activer ou interdire des fonctionnalités spécifiques (comme ContainerLogV2 ou ContainerLogV2-HighScale) et spécifier les flux de données à collecter.

Si vous avez besoin de configurations de supervision centralisées et réutilisables sur plusieurs clusters ou préférez que la configuration du cluster soit externalisée dans des ressources natives Azure, utilisez règles de collecte de données (DCRs). Les règles de collecte de données (DCR) sont des ressources Azure que le plan de contrôle Azure Resource Manager gère de manière native, et vous pouvez les inclure dans des fichiers Bicep. L’implémentation de référence utilise des DCRs.
Vous pouvez également définir la surveillance à l’aide de ConfigMaps, qui sont des objets YAML Kubernetes nonconfidential configurés via le plan de contrôle de l’API Kubernetes. Agent de surveillance Azure qui s’exécute sur les moniteurs de cluster pour les objets ConfigMap. Il utilise des paramètres prédéfinis pour déterminer les données à collecter.

Lorsque les deux méthodes sont activées, les paramètres ConfigMap sont prioritaires sur les contrôleurs de domaine. Évitez de mélanger la configuration ConfigMap et DCR pour la collecte de journaux de conteneur, car cela peut entraîner des problèmes de journalisation difficiles à résoudre.

Alertes et métriques Prometheus

Les pannes et les dysfonctionnements présentent des risques importants pour les applications de charge de travail, ce qui rend essentiel l’identification proactive des problèmes liés à l’intégrité et aux performances de votre infrastructure. Lorsque vous surveillez votre environnement et agissez sur ce que vous apprenez, vous réduisez les interruptions et améliorez la fiabilité de votre solution. Pour anticiper les conditions d’échec potentielles dans votre cluster, activez les règles d’alerte Prometheus recommandées pour Kubernetes.

La plupart des charges de travail hébergées dans des pods émettent des métriques Prometheus. Azure Monitor peut s’intégrer à Prometheus. Vous pouvez afficher les métriques d’application et de charge de travail collectées à partir de conteneurs, de pods, de nœuds et du cluster.

Certaines solutions non-Microsoft s’intègrent à Kubernetes, comme Datadog, Grafana ou New Relic. Ainsi, si votre organisation utilise déjà ces solutions, vous pouvez en tirer parti.

Journaux d'infrastructure Azure et du plan de contrôle Kubernetes

Avec AKS, Azure gère certains des principaux services Kubernetes. Azure implémente les journaux des composants du plan de contrôle AKS en tant que journaux de ressources. Ces options peuvent vous aider à résoudre les problèmes de cluster, et elles ont une densité de logs relativement faible. Nous vous recommandons d’activer les options suivantes sur la plupart des clusters :

ClusterAutoscaler: Obtenez une meilleure visibilité sur les opérations de mise à l’échelle via la journalisation. Pour plus d'informations, consultez Récupérer les journaux et le statut de l'autoscaler de cluster.
KubeControllerManager : obtenez une visibilité accrue sur l'interaction entre Kubernetes et le plan de contrôle Azure.
kube-audit-admin: bénéficiez d’une observabilité sur les activités modifiant votre cluster. Il n'est pas nécessaire d'activer à la fois kube-audit et kube-audit-admin, car kube-audit est un super-ensemble qui inclut également des opérations de lecture non modifiables.
guard : Capturez les audits de Microsoft Entra ID et RBAC d'Azure.

Il peut être utile d’activer d’autres catégories de logs, telles que KubeScheduler ou kube-audit, durant la phase initiale du développement du cycle de vie du cluster ou du workload. La mise à l'échelle automatique du cluster, le placement et la planification des pods, ainsi que d'autres données similaires peuvent vous aider à résoudre les problèmes liés aux opérations du cluster ou de la charge de travail. Toutefois, si vous conservez les journaux de résolution des problèmes étendus à temps plein après la fin de vos besoins de dépannage, vous risquez d’entraîner des coûts inutiles pour ingérer et stocker les données dans Azure Monitor.

Azure Monitor inclut un ensemble de requêtes de journal existantes pour commencer, mais vous pouvez également les utiliser comme base pour créer vos propres requêtes. À mesure que votre bibliothèque augmente, vous pouvez enregistrer et réutiliser des requêtes de journal à l’aide d’un ou plusieurs packs query. Votre bibliothèque personnalisée de requêtes offre une meilleure capacité d'observation sur la santé et les performances de vos clusters AKS. Elle vous aide à atteindre vos objectifs stratégiques.

Pour plus d’informations sur la surveillance des meilleures pratiques pour AKS, consultez Monitor AKS avec Azure Monitor.

Métriques réseau

Les métriques réseau de base au niveau du cluster sont disponibles via les métriques natives de la plateforme et de Prometheus. Vous pouvez utiliser les métriques réseau AKS node pour exposer les métriques réseau au niveau du nœud à l’aide des métriques Prometheus. La plupart des clusters doivent inclure l’observabilité du réseau pour fournir des fonctionnalités de dépannage réseau supplémentaires et détecter une utilisation ou des problèmes réseau inattendus au niveau du nœud.

L’implémentation de référence utilise Azure Monitor, qui collecte également certaines métriques liées au réseau. L’implémentation de référence interdit de collecter directement certaines métriques réseau à partir de Azure Monitor et collecte plutôt les métriques d’observabilité réseau à l’aide d’un espace de travail Azure Monitor avec managed Prometheus.

Pour les charges de travail très sensibles à la perte de paquets TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), à la latence ou à la pression DNS, les mesures du réseau au niveau du pod sont importantes. Dans AKS, vous pouvez accéder à ces métriques détaillées à l’aide de la fonctionnalité Advanced Container Networking Services. La plupart des charges de travail ne nécessitent pas un tel niveau d'observation du réseau. Vous ne devez pas activer l’observabilité réseau avancée, sauf si vos pods demandent un réseau hautement optimisé, avec une sensibilité jusqu’au niveau du paquet.

Optimisation des coûts pour la journalisation

L’implémentation de référence configure la table ContainerLogV2 pour utiliser le plan de base comme point de départ. Microsoft Defender pour les conteneurs et les alertes créées pour l'implémentation de référence n'interrogent pas cette table. Par conséquent, le plan de base est susceptible d'être rentable, car il réduit les coûts d'ingestion.

À mesure que votre volume de journaux et vos exigences de requête évoluent, sélectionnez la solution de tableau la plus rentable économiquement pour vos besoins. Si la solution devient intensive en lecture, où les requêtes analysent fréquemment les données de table, le plan Analytics par défaut peut être plus approprié. Le plan Analytics élimine les frais de requête, ce qui optimise les scénarios où l’activité de requête dépasse les coûts d’ingestion. Lorsque vous surveillez les modèles d’utilisation et ajustez les plans de table en fonction des besoins, vous pouvez obtenir un équilibre entre les coûts et les fonctionnalités de votre solution de supervision.

Pour plus d’informations, consultez Sélectionnez un plan de table basé sur l'utilisation des données dans un espace de travail Log Analytics.

Activer l’auto-guérison

Surveillez l'intégrité des pods en définissant des sondes de vivacité et de préparation. Si Kubernetes détecte un module qui ne répond pas, il le redémarre. Une sonde de vivacité détermine si le module est sain. Si Kubernetes détecte un module qui ne répond pas, il le redémarre. Une sonde de préparation détermine si le pod est prêt à recevoir des requêtes et du trafic.

Note

AKS dispose d’une fonctionnalité de réparation de nœud automatique qui fournit une auto-réparation intégrée pour les nœuds d’infrastructure.

Mises à jour de routine pour les clusters AKS

Une partie des opérations du jour 2 pour les clusters Kubernetes consiste à effectuer des mises à jour de routine de la plateforme et du système d'exploitation. Il y a trois couches de mises à jour à traiter sur chaque cluster AKS :

Version de Kubernetes (comme Kubernetes 1.32.3 à 1.32.7 ou Kubernetes 1.32.7 à 1.33.1), qui peut être associée à des modifications et dépréciations de l’API Kubernetes. Les changements de version à ce niveau affectent l’ensemble du cluster.
L'image du disque dur virtuel (VHD) sur chaque nœud, qui combine les mises à jour du système d'exploitation et les mises à jour des composants AKS. Ces mises à jour sont testées par rapport à la version Kubernetes du cluster. Les changements de version à cette couche sont appliqués au niveau du pool de nœuds et n'affectent pas la version de Kubernetes.
Le processus de mise à jour native du système d'exploitation, tel que Windows Update ou apt. Le fournisseur du système d'exploitation fournit ces mises à jour directement et elles ne sont pas testées par rapport à la version Kubernetes du cluster. Les changements de version au niveau de cette couche affectent un nœud unique et n'affectent pas la version de Kubernetes.

Chacune de ces couches est contrôlée indépendamment. Vous décidez de la manière dont chaque couche est gérée pour les clusters de votre charge de travail. Choisissez la fréquence à laquelle chaque cluster AKS, ses pools de nœuds ou ses nœuds sont mis à jour (la cadence). Choisissez également les jours ou heures à appliquer les mises à jour (votre fenêtre de maintenance). Choisissez si les mises à jour s'installent manuellement, automatiquement ou pas du tout. Tout comme la charge de travail qui s'exécute sur votre cluster a besoin d'une pratique de déploiement sûre, il en va de même pour les mises à jour de vos clusters.

Pour obtenir une perspective complète sur l'application de correctifs et la mise à niveau, consultez les conseils pour les correctifs et mises à niveau d'AKS dans le guide des activités postérieures au jour 2 AKS. Utilisez les informations suivantes pour les recommandations de base relatives à cette architecture.

Infrastructure immuable

Les charges de travail qui exploitent les clusters AKS en tant qu'infrastructure immuable ne mettent pas à jour leurs clusters automatiquement ou manuellement. Définissez la mise à niveau de l'image du node sur none et la mise à niveau automatique du cluster sur none. Dans cette configuration, vous êtes seul responsable de toutes les mises à jour à tous les niveaux.

Quand une mise à jour souhaitée devient disponible, vous devez effectuer les étapes suivantes :

Testez la mise à jour dans un environnement de préproduction et évaluez sa compatibilité sur un nouveau cluster.
Déployez un modèle de réplique de production qui inclut la version AKS mise à jour et les disques durs virtuels du pool de nœuds.
Lorsque le nouveau cluster de production est prêt, videz l’ancien cluster et désaffectez-le.

Une infrastructure immuable avec des déploiements réguliers d'une nouvelle infrastructure est la seule situation dans laquelle un cluster de production ne devrait pas faire l'objet d'une stratégie de mise à niveau sur place. Tous les autres clusters doivent avoir une stratégie de mise à niveau en place.

Mises à niveau sur place

Les charges de travail qui ne gèrent pas les clusters AKS comme une infrastructure immuable doivent régulièrement mettre à jour leurs clusters en cours d’exécution pour traiter les trois couches. Alignez votre processus de mise à jour sur les exigences de votre charge de travail. Utilisez les recommandations suivantes comme point de départ pour concevoir votre processus de mise à jour de routine.

Planifiez la fonctionnalité de maintenance planifiée d’AKS afin de pouvoir contrôler les mises à niveau sur votre cluster. Cette fonctionnalité vous permet d'effectuer les mises à jour, une opération intrinsèquement risquée, à un moment contrôlé afin de réduire l'effet d'une défaillance inattendue.
Configurez les budgets de perturbation des pods afin que votre application reste stable pendant les mises à jour continues. Mais ne configurez pas les budgets de manière à ce qu'ils soient si agressifs qu'ils empêchent les mises à niveau des nœuds de se produire, car la plupart des mises à niveau nécessitent un processus de cordon et de vidange sur chaque nœud.
Confirmez le quota de ressources Azure et la disponibilité des ressources. Les mises à niveau sur place déploient de nouvelles instances de nœuds, appelées nœuds d’augmentation, avant la suppression des anciens nœuds. Cela signifie que Azure quota et l’espace d’adressage IP doivent être disponibles pour les nouveaux nœuds. Une valeur de surcharge de 33 % constitue un bon point de départ pour la plupart des charges.
Testez la compatibilité avec les outils, tels que les maillages de service ou les agents de sécurité que vous avez ajoutés à votre cluster. Testez également vos composants de charge de travail, tels que les contrôleurs d’entrée, les maillages de service et vos pods de charge de travail. Exécutez des tests dans un environnement de préproduction.

Mises à niveau des nœuds sur place

Utilisez le canal de mise à niveau automatique NodeImage pour les mises à niveau de l'image du système d'exploitation du nœud. Ce canal configure votre cluster pour qu'il mette à jour le VHD sur chaque nœud avec des mises à jour spécifiques à chaque nœud. Microsoft teste les mises à jour par rapport à votre version d'AKS. Pour les nœuds Windows, les mises à jour ont lieu environ une fois par mois. Pour les nœuds Linux, les mises à jour se produisent environ une fois par semaine.

Les mises à jour ne modifient jamais votre version d'AKS ou de Kubernetes, de sorte que la compatibilité avec l'API Kubernetes n'est pas un problème.
Lorsque vous utilisez NodeImage comme chaîne de mise à niveau, celle-ci respecte votre fenêtre de maintenance planifiée, que vous devriez fixer à au moins une fois par semaine. Définissez-le quel que soit le système d’exploitation d’image de nœud que vous utilisez pour garantir l’application en temps voulu des mises à jour.
Ces mises à jour comprennent des mises à jour de sécurité, de compatibilité et fonctionnelles au niveau du système d'exploitation, des paramètres de configuration du système d'exploitation et des mises à jour de composants AKS.
Les versions d’images et les numéros de version des composants inclus sont suivis via le suivi des versions d'AKS.

Si les exigences de sécurité de votre cluster requièrent une cadence de patchs plus élevée et que votre cluster peut tolérer les interruptions potentielles, utilisez plutôt la chaîne de mise à niveau SecurityPatch. Microsoft teste également ces mises à jour. Les mises à jour sont publiées uniquement s’il existe des mises à niveau de sécurité que Microsoft considère comme suffisamment importantes pour publier avant la prochaine mise à niveau planifiée de l’image de nœud. Lorsque vous utilisez la chaîne SecurityPatch, vous recevez également les mises à jour que la chaîne NodeImage a reçues. L’option SecurityPatch de canal respecte toujours vos fenêtres de maintenance, alors assurez-vous que votre fenêtre de maintenance ait des intervalles plus fréquents (comme tous les jours ou un jour sur deux) pour prendre en charge ces mises à jour de sécurité non planifiées.

La plupart des clusters qui effectuent des mises à niveau sur place devraient éviter les options de chaîne de mise à niveau des images de nœuds None et Unmanaged.

Mises à jour du cluster sur place

Kubernetes est une plateforme qui évolue rapidement, et les mises à jour régulières apportent d'importants correctifs de sécurité et de nouvelles fonctionnalités. Il est important de rester à jour avec les mises à jour de Kubernetes. Vous devez rester dans les versions deux les plus récentes (N-2). Il est essentiel d'effectuer une mise à niveau vers la dernière version de Kubernetes, car de nouvelles versions sont publiées fréquemment.

La plupart des clusters devraient pouvoir effectuer des mises à jour en place de la version AKS avec suffisamment de prudence et de rigueur. Le risque d'effectuer une mise à niveau sur place de la version AKS peut principalement être atténué grâce à des tests de préproduction suffisants, à la validation des quotas et à la configuration du budget de perturbation des pods. Mais toute mise à niveau sur place peut entraîner un comportement inattendu. Si les mises à niveau sur place sont considérées comme trop risquées pour votre charge de travail, nous vous recommandons d’utiliser un déploiement bleu-vert des clusters AKS au lieu de suivre les recommandations restantes.

Nous vous recommandons d’éviter la fonctionnalité de mise à niveau automatique cluster lorsque vous déployez un cluster Kubernetes pour la première fois. Utilisez une approche manuelle, qui vous donne le temps de tester une nouvelle version de cluster AKS dans vos environnements de préproduction avant que les mises à jour n'atteignent votre environnement de production. Cette approche permet également d’atteindre le plus haut niveau de prévisibilité et de contrôle. Mais vous devez surveiller attentivement les nouvelles mises à jour de la plateforme Kubernetes et adopter rapidement les nouvelles versions dès leur sortie. Il est préférable d'adopter un état d'esprit « rester actuel » sur une approche à long terme.

Warning

Nous ne recommandons pas de patcher ou de mettre à jour automatiquement un cluster AKS de production, même avec des mises à jour de versions mineures, à moins que vous ne testiez d'abord ces mises à jour dans vos environnements inférieurs. Pour plus d’informations, consultez Mise à jour régulière vers la dernière version de Kubernetes et Upgrader un cluster AKS.

Vous pouvez recevoir des notifications lorsqu’une nouvelle version AKS est disponible pour votre cluster à l’aide du système AKS pour Azure Event Grid. L’implémentation de référence déploie ce système Event Grid afin que vous puissiez vous abonner à l’événement Microsoft.ContainerService.NewKubernetesVersionAvailable à partir de votre solution de notification eventstream. Passez en revue les notes de publication AKS pour connaître des problèmes de compatibilité, des modifications de comportement ou des dépréciations de fonctionnalités spécifiques.

Vous pourriez éventuellement atteindre le point de confiance avec les versions de Kubernetes, les versions d'AKS, votre cluster, ses composants au niveau du cluster et la charge de travail, pour explorer la fonctionnalité de mise à niveau automatique. Pour les systèmes de production, il est rare d’aller au-delà patch. En outre, lorsque vous mettez automatiquement à niveau votre version AKS, vérifiez le paramètre de version AKS dans votre infrastructure en tant que code (IaC) afin que les deux ne soient pas synchronisés. Configurez votre fenêtre de maintenance planifiée pour prendre en charge l’opération de mise à niveau automatique.

Surveillance de la sécurité

Surveillez votre infrastructure de conteneurs pour détecter les menaces actives et les risques de sécurité potentiels. Pour plus d’informations, consultez les ressources suivantes :

Microsoft Defender pour les conteneurs identifie et corrige les recommandations de Defender pour le cloud concernant vos images conteneur.
Defender pour conteneurs analyse régulièrement vos images conteneur à la recherche de vulnérabilités.
Defender pour conteneurs génère également des alertes de sécurité en temps réel pour les activités suspectes.
Concepts de sécurité pour les applications et les clusters dans AKS fournit des informations détaillées sur la façon dont la sécurité des conteneurs protège l’ensemble du pipeline complet, de la compilation aux charges de travail des applications exécutées dans AKS.

Opérations sur les clusters et les charges de travail

Pour connaître les considérations relatives aux opérations de cluster et de charge de travail (DevOps), consultez le pilier Principes de conception de l’excellence opérationnelle.

Démarrage du cluster

Après avoir configuré votre cluster, il s'agit d'un cluster opérationnel, mais il peut y avoir d'autres étapes à effectuer avant de pouvoir déployer des charges de travail. Le processus de préparation de votre cluster est appelé initialisation. Le démarrage consiste souvent à déployer des images préalables sur des nœuds de cluster, à créer des espaces de noms et à effectuer d’autres tâches qui répondent aux exigences du cas d’usage de votre organisation.

Pour accélérer la transition d’un cluster nouvellement configuré à un cluster correctement configuré, vous devez définir votre processus de démarrage unique et préparer les ressources pertinentes à l’avance. Par exemple, si vous utilisez un maillage de service comme Linkerd ou Consul Connect, vous déployez généralement le maillage avant que les charges de travail d’application puissent être planifiées. Avant de configurer le cluster, vous devez vérifier que les images du maillage de service existent dans un registre de conteneurs créé précédemment. Cette validation permet d’éviter les retards de déploiement ou les échecs.

Vous pouvez configurer le processus de démarrage en utilisant l'une des méthodes suivantes :

extension de cluster GitOps Flux v2
Pipelines
Auto-configuration avec Flux ou Argo CD, par exemple.

Note

Chacune de ces méthodes fonctionne avec n'importe quelle topologie de cluster, mais nous recommandons l'extension de cluster GitOps Flux v2 pour les flottes en raison de l'uniformité et de la gouvernance plus facile à l'échelle. Lorsque vous ne gérez que quelques clusters, GitOps peut s'avérer trop complexe. Vous pouvez plutôt choisir d’intégrer le processus dans un ou plusieurs pipelines de déploiement afin de garantir que l’amorçage s’effectue. Utilisez la méthode qui correspond le mieux aux objectifs de votre organisation et de votre équipe.

L'un des principaux avantages de l'utilisation de l'extension de cluster GitOps Flux v2 pour AKS est qu'il n'y a effectivement aucun écart entre un cluster provisionné et un cluster bootstrapped. Il configure l’environnement avec une base de gestion solide pour aller de l'avant, et il prend également en charge l’intégration de la configuration initiale en tant que modèles de ressources pour s’aligner sur votre stratégie IaC.

Enfin, lorsque vous utilisez l’extension de cluster GitOps Flux v2, kubectl n’est pas nécessaire pour une partie du processus de démarrage. Vous pouvez réserver des accès basés sur kubectl pour les situations d’urgence nécessitant des réparations. Entre les modèles de définitions de ressources Azure et l'initialisation des manifestes via l’extension GitOps, vous pouvez effectuer toutes les activités de configuration normales sans avoir à utiliser kubectl.

Isoler les responsabilités en matière de charge de travail

Répartissez la charge de travail par équipes et types de ressources afin de gérer individuellement chaque partie.

Commencez par une charge de travail de base contenant les composants fondamentaux, et développez-la par la suite. Une première tâche consiste à configurer le réseau. Configurez des réseaux virtuels pour les réseaux hub-and-spokes et également des sous-réseaux au sein de ces réseaux. Par exemple, un spoke a des sous-réseaux distincts pour les pools de nœuds système et utilisateur, les ressources d’entrée et le serveur d’API AKS privé. Déployez un sous-réseau pour Azure Firewall dans le hub.

Une autre tâche consiste à intégrer la charge de travail de base à Microsoft Entra ID.

Utiliser IaC

Si possible, privilégiez une méthode déclarative idempotente plutôt qu’une approche impérative. Plutôt que d’écrire une séquence de commandes spécifiant des options de configuration, utilisez la syntaxe déclarative qui décrit les ressources et leurs propriétés. L’implémentation de référence utilise Bicep, mais vous pouvez choisir d’utiliser Terraform ou Azure Resource Manager modèles (modèles ARM) à la place.

Veillez à configurer des ressources conformément aux stratégies de gouvernance. Par exemple, lorsque vous sélectionnez la taille des machines virtuelles, restez dans les limites des contraintes de coût et des options de zone de disponibilité pour correspondre aux exigences de votre application. Vous pouvez également utiliser Azure Policy pour appliquer les stratégies de votre organisation pour ces décisions.

Si vous devez écrire une séquence de commandes, utilisez la Azure CLI. Ces commandes couvrent une gamme de services Azure et vous pouvez les automatiser par le biais de scripts. Windows et Linux prennent en charge le Azure CLI. Une autre option multiplateforme est Azure PowerShell. Votre choix dépend de vos compétences.

Stockez et versionnez vos scripts et fichiers modèles dans votre système de contrôle des sources.

CI/CD de charge de travail

Pipelines pour le flux de travail et le déploiement doivent être en mesure de générer et de déployer des applications en continu. Les mises à jour doivent être déployées rapidement et en toute sécurité, et restaurées en cas de problème.

Votre stratégie de déploiement doit inclure un pipeline de livraison continue fiable et automatisé. Déployez automatiquement les modifications apportées aux images de conteneurs de votre charge de travail sur le cluster.

Dans cette architecture, GitHub Actions gère le flux de travail et le déploiement. D’autres options populaires incluent Azure DevOps Services et Jenkins.

Cluster CI/CD

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

Au lieu d’utiliser une approche impérative comme kubectl, utilisez des outils qui synchronisent automatiquement les modifications apportées au cluster et au référentiel. Pour gérer le flux de travail, comme la publication d’une nouvelle version et la validation sur cette version avant le déploiement en production, envisagez un flux GitOps.

Une partie essentielle du flux CI/CD est le démarrage d'un cluster nouvellement provisionné. Une approche GitOps est utile car elle permet aux opérateurs de définir de manière déclarative le processus de bootstrapping dans le cadre de la stratégie IaC et de voir la configuration reflétée automatiquement dans le cluster.

Lorsque vous utilisez GitOps, un agent est déployé dans le cluster pour s'assurer que l'état du cluster est coordonné avec la configuration stockée dans votre référentiel Git privé. Un de ces agents est Flux, qui utilise un ou plusieurs opérateurs dans le cluster pour déclencher des déploiements dans Kubernetes. Flux effectue les tâches suivantes :

Surveille tous les référentiels configurés
Détecte les nouvelles modifications de configuration
Déclenche des déploiements
Met à jour la configuration en cours d’exécution souhaitée en fonction de ces modifications

Vous pouvez également définir des stratégies qui régissent la manière dont les modifications sont déployées.

L’exemple de diagramme suivant montre comment automatiser la configuration du cluster avec GitOps et Flux.

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

Un développeur valide les modifications apportées au code source, comme les fichiers YAML de configuration, qui sont stockés dans un dépôt Git. Les modifications sont ensuite pushées sur un serveur Git.
Flux s'exécute dans un pod aux côtés de la charge de travail. Flux a un accès en lecture seule au dépôt Git pour s'assurer que Flux applique uniquement les modifications telles que demandées par les développeurs.
Flux reconnaît les changements de configuration et les applique en utilisant les commandes kubectl.
Les développeurs n'ont pas de access directes vers l'API Kubernetes via kubectl.

Vous pouvez avoir des stratégies de branche sur votre serveur Git afin que plusieurs développeurs puissent ensuite approuver les changements via une pull request avant que le changement ne soit appliqué à la production.

Bien que vous puissiez configurer GitOps et Flux manuellement, nous vous recommandons gitOps avec l’extension de cluster Flux v2 pour AKS.

Stratégies de déploiement de charges de travail et de clusters

Déployez toute modification, comme les composants d’architecture, la charge de travail et la configuration du cluster, sur au moins un cluster AKS de préproduction. Ce processus simule la modification et peut identifier les problèmes avant leur déploiement en production.

Exécutez des tests et des validations à chaque étape avant de passer à la phase suivante. Cela permet de s'assurer que vous pouvez pousser les mises à jour vers l'environnement de production d'une manière très contrôlée et de minimiser les perturbations dues à des problèmes de déploiement imprévus. Le déploiement doit suivre un modèle similaire à la production, à l’aide du même pipeline GitHub Actions ou des opérateurs Flux.

Les techniques de déploiement avancées, telles que le déploiement bleu-vert, les tests A/B et les déploiements canari, nécessitent des processus supplémentaires et éventuellement des outils supplémentaires. Flagger est une solution open source populaire qui permet de résoudre les scénarios de déploiement avancés.

Gestion des coûts

Commencez par examiner la liste de contrôle pour la conception de l’optimisation des coûts et les recommandations décrites dans le Well-Architected Framework pour AKS. Pour obtenir des recommandations générales sur la charge de travail, consultez la liste de contrôle de révision Design pour l’optimisation des coûts.

Vous trouverez une estimation des coûts pour les composants utilisés dans cette architecture de base dans la calculatrice de prix Azure. Modifiez votre estimation pour inclure les composants requis pour votre cas d’usage.

Envisagez d’utiliser AKS Cost Analysis pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.

Provision

Comprenez d'où viennent vos coûts. Les coûts associés à AKS sont minimes en ce qui concerne le déploiement, la gestion et les opérations du cluster Kubernetes lui-même. Ce qui affecte le coût est les instances de machine virtuelle, les storage, les données de journal et les ressources réseau consommées par le cluster. Vous pouvez choisir des machines virtuelles moins coûteuses pour les pools de nœuds système. La série Ddv5 est un type de machine virtuelle classique pour le pool de nœuds système, et l’implémentation de référence utilise la référence SKU Standard_D2d_v5.
N’utilisez pas la même configuration pour les environnements de développement/test et de production. Les charges de travail de production présentent des exigences supplémentaires à des fins de haute disponibilité et sont généralement plus coûteuses. Cette configuration n’est pas nécessaire dans l’environnement de développement/test.
Intégrez un accord de niveau de service de disponibilité pour les charges de travail de production. Mais il est possible de réaliser des économies pour les clusters conçus pour des charges de travail de type dev/test ou expérimental, pour lesquelles il n'est pas nécessaire de garantir la disponibilité. Par exemple, votre SLO peut être suffisant. En outre, si votre charge de travail la prend en charge, envisagez d’utiliser des pools de nœuds spot dédiés qui exécutent des machines virtuelles spot.

Pour les charges de travail hors production qui incluent des Azure SQL Database ou des Azure App Service dans le cadre de l'architecture de charge de travail AKS, évaluez si vous êtes éligible à utiliser des abonnements Azure Dev/Test et recevez des remises de service.
Provisionnez un cluster avec le nombre minimum de nœuds et permettez à l'autoscaler du cluster de surveiller et de prendre des décisions de dimensionnement au lieu de commencer avec un cluster surdimensionné pour répondre aux besoins de mise à l'échelle.
Définissez les demandes de pod et les limites pour permettre à Kubernetes d’allouer des ressources de nœud avec une densité plus élevée afin d’utiliser la capacité totale des nœuds.
Considérez que lorsque vous activez les diagnostics sur le cluster, cela peut augmenter le coût.
Souscrivez à une réservation d'un an ou de trois ans pour les Instances de Machine Virtuelle Réservées Azure, afin de réduire les coûts des nœuds si votre charge de travail doit être maintenue pendant une longue période. Pour plus d’informations, consultez Économisez les coûts avec les instances de machines virtuelles réservées Azure.
Utilisez des balises lorsque vous créez des pools de nœuds. Les balises sont utiles lorsque vous créez des rapports personnalisés pour suivre les coûts encourus. Vous pouvez utiliser des balises pour suivre les dépenses totales et mapper tout coût à une ressource ou une équipe spécifique. Si le cluster est partagé entre les équipes, créez des rapports de rétrofacturation pour chaque consommateur afin d’identifier les coûts mesurés des services cloud partagés. Pour plus d’informations, consultez Spécifiez une souillure, une étiquette ou une balise pour un pool de nœuds.
Attendez-vous à des coûts de bande passante supplémentaires si votre charge de travail est multirégionale et que vous répliquez des données entre les régions. Pour plus d’informations, consultez Tarification de la bande passante.
Créez des budgets pour rester dans les limites des coûts identifiés par votre organisation. Vous pouvez créer des budgets par le biais de Microsoft Cost Management. Vous pouvez également créer des alertes pour recevoir des notifications lorsque des seuils spécifiques sont dépassés. Pour plus d’informations, consultez Créer un budget à l’aide d’un modèle.

Monitor

Vous pouvez surveiller l’ensemble du cluster et le coût du calcul, du stockage, de la bande passante, des journaux et du pare-feu. Azure fournit les options suivantes pour surveiller et analyser les coûts :

Surveillez vos coûts en temps réel ou selon une planification régulière afin que vous puissiez prendre des mesures avant la fin du mois, lorsque les coûts sont déjà calculés. Surveillez les tendances mensuelles au fil du temps pour rester dans le budget.

Pour prendre des décisions fondées sur des données, déterminez avec précision quelle ressource, à un niveau granulaire, génère le plus de coûts. De plus, comprenez bien les compteurs qui calculent l'utilisation des ressources. Par exemple, en analysant les mesures, vous pouvez déterminer si la plateforme est surdimensionnée. Vous pouvez voir les compteurs d’utilisation dans les métriques Azure Monitor.

Optimize

Suivez les recommandations de Azure Advisor. Explorez d’autres façons d’optimiser :

Activez l'autoscaler du cluster pour qu'il détecte et supprime les nœuds sous-utilisés dans le pool de nœuds.

Important

Apporter des modifications rapides ou fréquentes aux paramètres de mise à l’échelle automatique du cluster, comme le nombre minimal et maximal de nœuds pour un pool de nœuds, afin de contrôler les coûts peut entraîner des résultats inattendus ou contre-productifs. Par exemple, si scale-down-unneeded-time elle est définie sur 10 minutes et que les paramètres de nœud minimum et maximal sont modifiés toutes les cinq minutes en fonction des caractéristiques de la charge de travail, le nombre de nœuds ne diminue jamais. Cela est dû au fait que le calcul du temps inutile pour chaque nœud est réinitialisé lorsque les paramètres de mise à l’échelle automatique du cluster sont actualisés.
Si votre charge de travail la prend en charge, optez pour une référence SKU inférieure pour les pools de nœuds.
Si l’application ne nécessite pas de mise à l’échelle en rafale, envisagez de mettre en place des droits sur le cluster en analysant les métriques de performances au fil du temps.
Si votre charge de travail le permet, ajustez vos pools de nœuds utilisateur à zéro nœud lorsqu'il n'est pas prévu qu'ils s'exécutent. Si aucune charge de travail n’est planifiée pour s’exécuter dans votre cluster, envisagez d’utiliser la fonctionnalité de démarrage/arrêt AKS pour arrêter tout le calcul, ce qui inclut votre pool de nœuds système et le plan de contrôle AKS.

Pour plus d’informations, consultez AKS tarification.

Étapes suivantes

feuille de route AKS sur GitHub
accélérateur de zone d’atterrissage AKS

Architecture avancée de microservices AKS
Architecture des microservices sur AKS
Utiliser Azure Firewall pour protéger un cluster AKS
GitOps pour AKS
Data streaming à l’aide d’AKS

Commentaires

Cette page a-t-elle été utile ?

Partager via

Architecture de base pour un cluster Azure Kubernetes Service (AKS)

Configuration réseau

Calcul informatique en cluster

Gestion des identités

Sécuriser le flux de données

Continuité de l’activité

Operations

Architecture

Topologie du réseau

Hub virtual network

Sous-réseau pour héberger le pare-feu Azure

Sous-réseau pour héberger une passerelle

Sous-réseau pour héberger des Azure Bastion

Réseau virtuel spoke

Sous-réseau pour héberger l'Azure Application Gateway

Sous-réseau pour héberger les ressources d’entrée

Sous-réseau pour héberger les nœuds de cluster

Sous-réseau pour héberger des points de terminaison Azure Private Link

Sous-réseau pour le serveur d’API AKS

Planifier les adresses IP

Adresse IP de l'espace d'adressage du réseau virtuel

Espace d’adressage IP du pod

Autres considérations relatives à l’espace d’adressage IP

Modules complémentaires et fonctionnalités d’évaluation

Référence d’image de conteneur

Configurer le calcul pour le cluster de base

Sélectionner un système d’exploitation

Intégrer Microsoft Entra ID pour le cluster

Accès AKS aux composants Azure

Accès au cluster

Associer RBAC Kubernetes à Microsoft Entra ID

Utiliser Azure RBAC pour l’autorisation Kubernetes

Comptes locaux

Intégrer Microsoft Entra ID pour la charge de travail

Sélectionner un modèle de mise en réseau

Déployer des ressources d’entrée

Paramètres du routeur

Sécuriser le flux réseau

Flux de trafic d’entrée

Flux du trafic de sortie

Trafic entre pods

Trafic de gestion

Ajouter la gestion des secrets

Accéder aux secrets du cluster

Stockage des charges de travail

Gestion des stratégies

Scalabilité des nœuds et des pods

Autoscaler horizontal de pods

Autoscaler de cluster

Décisions de continuité des activités :

Nœuds de cluster

Disponibilité des pods

Zones de disponibilité

Plusieurs régions

Récupération d’urgence

Sauvegarde de cluster

Contrat SLA pour le serveur API Kubernetes

Compromis

Tester la conception via des simulations et des basculements forcés

Surveiller et collecter des logs et des mesures

Activer la collecte de logs depuis les pods

Alertes et métriques Prometheus

Journaux d'infrastructure Azure et du plan de contrôle Kubernetes

Métriques réseau

Optimisation des coûts pour la journalisation

Activer l’auto-guérison

Mises à jour de routine pour les clusters AKS

Infrastructure immuable

Mises à niveau sur place

Mises à niveau des nœuds sur place

Mises à jour du cluster sur place

Surveillance de la sécurité

Opérations sur les clusters et les charges de travail

Démarrage du cluster

Isoler les responsabilités en matière de charge de travail

Utiliser IaC

CI/CD de charge de travail

Cluster CI/CD

Stratégies de déploiement de charges de travail et de clusters