Architecture de référence pour un cluster Azure Kubernetes Service (AKS)

Azure Application Gateway

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 de référence pour l'infrastructure de base recommandée qui déploie un cluster Azure Kubernetes Service (AKS). Il utilise nos principes de conception et s'appuie sur les meilleures pratiques architecturales d'AKS, issues du cadre Azure Well-Architected Framework. Cet article permet de guider plusieurs groupes interdisciplinaires distincts, comme les équipes de mise en réseau, de sécurité et d'identité, lorsqu'ils déploient cette infrastructure à usage général.

Cette architecture n'est pas axée 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. Elle s'intègre aux services Azure qui assurent l'observabilité, fournissent une topologie de réseau qui prend en charge la croissance multirégionale et sécurisent le trafic à l'intérieur du cluster.

Les exigences de votre métier influencent l'architecture cible et celle-ci peut varier entre différents 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 écosystème puissant qui va plus loin que les technologies Azure et Microsoft. Lorsque vous déployez un cluster AKS, vous assumez de nombreuses décisions sur la manière dont votre cluster doit être conçu et exploité. L’exécution d’un cluster AKS implique une combinaison de composants propriétaires provenant de divers fournisseurs, y compris Microsoft, et de composants open-source de l’écosystème Kubernetes. Le contexte change fréquemment et vous devrez peut-être revoir régulièrement les décisions. En adoptant Kubernetes, vous reconnaissez que votre charge de travail a besoin de ses fonctionnalités et que l’équipe de charge de travail est prête à investir en permanence.

Vous pouvez utiliser une implémentation de cette architecture sur GitHub : AKS baseline reference implementation. Utilisez-la comme point de départ alternatif et configurez l'architecture de référence en fonction de vos besoins.

Remarque

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

Topologie du réseau

Cette architecture utilise une topologie de réseau en hub et spoke. Déployez le hub et les spoke dans des réseaux virtuels distincts qui sont connectés par le biais d'un peering de réseau virtuel. Cette topologie présente plusieurs avantages. Utilisez cette topologie pour :

Permettre une gestion séparée. Vous pouvez appliquer la gouvernance et respecter le principe du moindre privilège. Elle prend également en charge le concept de zone d'atterrissage Azure avec séparation des tâches.
Minimiser l'exposition directe des ressources Azure à l'internet public.
Fournissez des topologies régionales de type « hub » et « spoke ». Vous pouvez étendre les topologies de réseau hub et spoke à l'avenir et fournir une isolation de la charge de travail.
Utilisez un service de pare-feu d'application Web 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 spoke au lieu de revoir la topologie du réseau.
Prenez en charge le partage des ressources, telles qu'un pare-feu et des zones DNS (Domain Name System), entre les réseaux.
S'aligner sur la zone d'atterrissage d'Azure à l'échelle de l'entreprise.

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

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

Pour plus d'informations sur les modifications de la conception du réseau incluses dans l'architecture de référence de base des conteneurs Windows sur AKS, consultez Conteneurs Windows sur AKS.

Réseau virtuel hub

Le réseau virtuel hub est le point central de connectivité et d’observabilité. Dans cette architecture, le hub contient :

Azure Firewall avec des stratégies de pare-feu globales, définies par vos équipes informatiques centrales pour appliquer la stratégie de pare-feu à l'échelle de l'organisation.
Azure Bastion pour l'accès à distance aux machines virtuelles (VM).
Un sous-réseau de passerelle pour la connectivité VPN.
Azure Monitor pour l'observation du réseau.

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

Sous-réseau pour héberger Pare-feu Azure

Le pare-feu Azure est un service de pare-feu géré. L'instance de pare-feu Azure 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 de pare-feu Azure et gérer les stratégies de pare-feu Azure pour ce type d'architecture de réseau virtuel hub.

Sous-réseau pour héberger une passerelle

Ce sous-réseau est un emplacement pour une passerelle VPN ou une passerelle Azure ExpressRoute. La passerelle assure la connectivité entre les routeurs de votre réseau local et ceux du réseau virtuel.

Sous-réseau pour héberger Azure bastion

Ce sous-réseau est un espace réservé pour Azure Bastion. Vous pouvez utiliser Azure Bastion pour accéder en toute sécurité aux ressources Azure sans exposer les ressources à Internet. Ce sous-réseau est réservé à la gestion et aux opérations.

Réseau virtuel Spoke

Le réseau virtuel 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 Azure Application Gateway

Application Gateway est un équilibreur de charge du trafic Web qui fonctionne à la couche 7. L'implémentation de référence utilise l'UGS Application Gateway v2 qui active le pare-feu Azure Web Application Firewall. Web Application Firewall sécurise le trafic entrant contre les attaques courantes du 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 requiert un sous-réseau dédié.

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

Pour acheminer et distribuer le trafic, Traefik est le contrôleur d'entrée qui remplit les ressources d'entrée de Kubernetes. Les équilibreurs de charge internes Azure existent dans ce sous-réseau. Pour plus d’informations, consultez Utiliser un équilibreur de charge 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 les points de terminaison de la liaison privée Azure.

Créez des liaisons privées pour Azure Container Registry et Azure Key Vault afin que les utilisateurs puissent accéder à ces services au moyen d'un point de terminaison privé au sein du réseau virtuel spoke. 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 réseau virtuel hub. Dans l'implémentation de base, les points de terminaison sont déployés sur un sous-réseau dédié au sein du réseau virtuel spoke. Cette approche permet de réduire le trafic qui passe par la connexion au réseau peering. Elle permet de conserver les ressources appartenant 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 en utilisant des groupes de sécurité réseau.

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

Planifier les adresses IP

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

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

Votre réseau virtuel Azure, utilisé pour les ressources telles que les nœuds de cluster, les points de terminaison privés et Application Gateway.
Le cluster utilise une superposition Azure CNI, qui alloue des adresses IP aux pods à partir d’un espace d’adressage distinct de votre réseau virtuel Azure.

Espace d’adressage IP du réseau virtuel

L’espace d’adressage de votre réseau virtuel Azure 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 ces entités à partir de l'espace d'adressage du sous-réseau. Tenez compte de ces points lorsque vous planifiez les adresses IP de votre réseau virtuel Azure.

Mises à niveau : AKS met régulièrement à jour les nœuds pour s’assurer que les machines virtuelles sous-jacentes sont à jour en ce qui concerne les fonctionnalités de sécurité et autres patches 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 à partir du sous-réseau du cluster. Veillez à disposer d'un espace d'adressage suffisant pour ces adresses IP de nœuds temporaires.

Dans cette architecture, les pods se voient attribuer des adresses IP à partir de l’espace d’adressage des pods de la superposition Azure CNI, y compris lors des mises à jour propagées. Cette approche réduit le nombre global d’adresses IP utilisées à partir de votre réseau virtuel Azure par rapport à d’autres approches de mise en réseau Kubernetes.
Extensibilité : tenez compte du nombre de nœuds système et utilisateur et de leur limite d’extensibilité maximale. Supposons que vous souhaitez effectuer un scale-out de 400 %. Vous avez besoin de quatre fois le nombre d'adresses pour tous ces nœuds scale-out.

Étant donné que cette architecture utilise la superposition Azure CNI, l’extensibilité de vos pods n’affecte pas l’espace d’adressage de votre réseau virtuel.
Addresses Private Link : facteur des adresses requises pour communiquer avec d’autres services Azure via Azure Private Link. Cette architecture dispose de deux adresses attribuées pour les liens vers Container Registry et Key Vault.
Adresses IP réservées : Azure réserve certaines adresses pour ses utilisations. Elles ne peuvent pas être affectées.

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. Vous obtiendrez ainsi un plus grand nombre de sous-réseaux de taille plus réduite. En outre, la ressource d’entrée peut être plus complexe et il est possible que vous ayez donc besoin de plusieurs contrôleurs d’entrée qui nécessitent des adresses IP supplémentaires.

Espace d’adressage IP du pod

La superposition Azure CNI affecte des adresses IP aux pods à l’aide d’un espace d’adressage dédié, qui est distinct de celui que vous utilisez dans votre réseau virtuel. Utilisez un espace d’adressage IP qui ne chevauche pas votre réseau virtuel ou 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.

Chaque nœud reçoit un espace d’adressage /24 pour ses pods. Il est donc important de s’assurer que l’espace d’adressage du pod est suffisamment grand pour permettre 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 CIDR, 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 en savoir plus, consultez les instructions relatives à la planification des adresses IP pour la superposition Azure CNI

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

Pour obtenir la liste complète des considérations relatives aux réseaux à prendre en compte dans le cadre de cette architecture, consultez Topologie de réseau de base AKS. Pour en savoir plus sur la planification de l’adressage IP pour un cluster AKS, consultez Planifier l’adressage IP pour votre cluster.

Pour plus d'informations sur les considérations relatives à la planification des adresses IP incluses dans l'architecture de référence des conteneurs Windows sur AKS, voir Conteneurs Windows sur AKS.

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

Kubernetes et AKS évoluent en permanence, avec des cycles de publication plus rapides que les logiciels pour environnements locaux. Cette architecture de base dépend de la sélection des fonctionnalités d’évaluation AKS et des modules complémentaires AKS. Voici la différence entre les deux :

L'équipe d'AKS décrit les fonctionnalités d'avant-première comme expédiées et en cours d'amélioration, car de nombreuses fonctionnalités d'avant-première restent dans cet état pendant quelques mois seulement avant de passer à la phase de disponibilité générale (GA).
Les modules complémentaires et les extensions d'AKS fournissent des fonctionnalités supplémentaires prises en charge. AKS gère leur installation, leur configuration et leur cycle de vie.

Cette architecture de base n'inclut pas toutes les fonctionnalités d'évaluation ni tous les modules complémentaires. 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 d'évaluation ou modules complémentaires AKS que vous pourriez vouloir é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 maintenir, y compris 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

En plus de la charge de travail, le cluster peut contenir plusieurs autres images, telles que le contrôleur d’entrée. Certaines de ces images peuvent résider dans des registres publics. Tenez compte de ces points lorsque vous tirez les images dans votre cluster.

Authentifiez le cluster pour tirer l'image.
Importez une image publique dans le registre de conteneurs qui s'aligne sur votre objectif de niveau de service (SLO), si vous utilisez une image publique. 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, cela peut entraîner des problèmes opérationnels. Voici quelques avantages de l'utilisation d'un registre de conteneurs privé, comme Azure Container Registry, au lieu d'un registre public :
- Vous pouvez bloquer l’accès non autorisé à vos images.
- Vous n'avez pas de dépendances publiques.
- Vous pouvez accéder aux journaux de pull d'images pour surveiller les activités et trier 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 par le biais d’Azure Policy. Dans cette implémentation de référence, le cluster ne tire des images que de l'instance de Container Registry qui se déploie.

Configurer le calcul pour le cluster de base

Dans AKS, chaque type de nœud est 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 DS2_v2. Cette taille est suffisante pour répondre à la charge attendue des pods système. Le disque du système d'exploitation est de 512 Go.

Voici quelques points à prendre en compte pour le pool de nœuds utilisateur :

Choisissez des tailles de nœud supérieures pour regrouper le nombre maximal de pods définis sur un nœud. Les nœuds de grande taille minimisent l'empreinte des services qui s'exécutent sur tous les nœuds, tels que la surveillance et le journal.
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 Tailles des machines virtuelles sur Azure.
Déployez au moins deux nœuds. La charge de travail dispose ainsi d’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 la taille réelle des nœuds pour votre charge de travail en fonction des exigences déterminées par votre équipe de conception. Sur la base des exigences de l'entreprise, cette architecture utilise DS4_v2 pour la charge de travail de production. Pour réduire les coûts, vous pouvez réduire la taille à DS3_v2, qui est la recommandation minimale.
Lors de la planification de la capacité de votre cluster, partez du principe que votre charge de travail consomme jusqu'à 80 % de chaque nœud. Les 20 % restants sont réservés aux services AKS.
Définissez le nombre maximal de pods par nœud en fonction de votre planification de capacité. Si vous essayez d'établir une base 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 d’utiliser une autre distribution Linux, notamment Ubuntu, si vous préférez, ou si vous avez des exigences auxquelles Azure Linux ne peut pas répondre.

AKS prend également en charge les pools de nœuds qui exécutent le système d’exploitation Windows Server. Certains aspects d’un cluster qui exécute Windows présentent des exigences particulières. Pour en savoir plus sur l’architecture du pool de nœuds Windows, consultez Exécution de conteneurs Windows sur AKS.

Si vous avez une charge de travail composée d’une combinaison de technologies, vous pouvez utiliser différents systèmes d’exploitation dans différents pools de nœuds. Toutefois, si vous n’avez pas besoin de plusieurs systèmes d’exploitation pour votre charge de travail, nous vous recommandons d’utiliser un seul système d’exploitation pour tous les pools de nœuds de votre charge de travail.

Intégrer Microsoft Entra ID pour le cluster

Sécuriser l’accès au cluster est impératif. Pensez-y du point de vue du cluster lorsque vous faites des choix en matière de sécurité :

Accès de l’intérieur. Tenez compte de l'accès de l'AKS aux composants Azure tels que l'infrastructure réseau, le Container Registry et Key Vault. Autorisez uniquement les ressources auxquelles le cluster doit pouvoir accéder.
Accès de l’extérieur. Fournissez un accès aux identités au cluster Kubernetes. Autorisez les seules entités externes autorisées à accéder au serveur d’API Kubernetes et Azure Resource Manager.

Accès AKS à Azure

Il existe deux façons de gérer l’accès AKS à Azure par le biais de Microsoft Entra ID : les principaux de service ou les identités managées pour les ressources Azure.

Parmi les deux méthodes de gestion de l'accès AKS à Azure, nous recommandons les identités gérées. Avec les mandants de service, vous devez gérer et faire pivoter les secrets, soit manuellement, soit par programme. Avec les identités managées, Microsoft Entra ID gère et effectue l’authentification et la rotation des secrets pour vous en temps voulu.

Nous vous recommandons d'activer et d'utiliser les identités gérées afin que le cluster puisse interagir avec les ressources Azure externes par le biais de Microsoft Entra ID. Même si vous n'utilisez pas l'intégration Microsoft Entra ID dans l'immédiat, vous pourrez l'incorporer ultérieurement.

Par défaut, deux identités principales sont utilisées par le cluster : l'identité du cluster et l'identité du kubelet. Les composants du plan de contrôle AKS utilisent l'identité du cluster pour gérer les ressources du cluster, notamment les équilibreurs de charge d'entrée et les IP publiques gérées par AKS. L'identité du 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 implique que le cluster récupère les informations d’identification du registre. Si vous n'utilisez pas d'identité gérée, vous pouvez stocker ces informations sous la forme d'un objet secret Kubernetes et utiliser imagePullSecrets pour récupérer le secret. Nous ne recommandons pas cette approche en raison de la complexité de la sécurité. Non seulement vous devez avoir une connaissance préalable du secret, mais vous devez également stocker ce secret dans le pipeline DevOps. Une autre raison pour laquelle nous ne recommandons pas cette approche est la surcharge opérationnelle liée à la gestion de la rotation du secret. Au lieu de cela, autorisez l’accès AcrPull à l’identité managée kubelet du cluster à votre registre. Cette approche répond à ces préoccupations.

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 un contrôle d'accès Azure basé sur les rôles (Azure RBAC) et des permissions aux identités géré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 cette implémentation de référence où des rôles intégrés Azure sont attribués au cluster :

Rôle de contributeur réseau. Gère la capacité du cluster à contrôler le réseau virtuel spoke. Avec cette attribution de rôle, l'identité attribuée au système du cluster AKS peut travailler avec le sous-réseau dédié pour le service de contrôleur d'entrée interne.
Rôle d'éditeur de mesures de surveillance. Gère la capacité du cluster à envoyer des mesures à Azure Monitor.
Rôle AcrPull. Gère la capacité du cluster à tirer des images des instances Azure Container Registry spécifiées.

Accès au cluster

L’intégration Microsoft Entra simplifie également la sécurité pour l’accès de l’extérieur. 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é par rapport aux rôles Azure autorisés à obtenir les informations d'identification du cluster. Pour plus d’informations, consultez Autorisations des rôles de cluster disponibles.

AKS prend en charge l'accès à Kubernetes en utilisant Microsoft Entra ID de deux manières. La première consiste à utiliser Microsoft Entra ID en tant que fournisseur d'identité intégré au système RBAC natif de Kubernetes. L'autre méthode utilise le système Azure RBAC natif pour contrôler l'accès au cluster. Les sections suivantes détaillent les deux approches.

Associer le système RBAC de Kubernetes à Microsoft Entra ID

Kubernetes prend en charge le système RBAC par le biais de :

Un ensemble de permissions que vous définissez en utilisant un objet Role ou ClusterRole pour les permissions à l'échelle du cluster.
Des liaisons qui attribuent des utilisateurs et des groupes qui ont la permission d'effectuer les actions. Définissez les liaisons en utilisant un objet RoleBinding ou ClusterRoleBinding.

Kubernetes dispose de certains rôles intégrés tels que cluster-admin, edit et view. Liez ces rôles aux utilisateurs et groupes Microsoft Entra afin d'utiliser l'annuaire d'entreprise pour gérer l'accès. Pour plus d’informations, consultez Utiliser le contrôle d’accès en fonction du rôle (RBAC) Kubernetes avec l’intégration Microsoft Entra.

Veillez à inclure les groupes Microsoft Entra pour l'accès au cluster et à l'espace de noms dans vos révisions d'accès Microsoft Entra.

Utiliser Azure RBAC pour l’autorisation Kubernetes

Au lieu d'utiliser le RBAC natif de Kubernetes, ClusterRoleBindings et RoleBindings pour l'autorisation avec l'authentification intégrée de Microsoft Entra, nous vous recommandons d'utiliser Azure RBAC et les attributions de rôles Azure. Cette approche permet d'appliquer les contrôles d'autorisation sur le cluster. Vous pouvez même attribuer ces rôles au niveau du groupe de gestion, de l'abonnement ou du groupe de ressources. Tous les clusters sous la portée héritent alors d'un ensemble cohérent d'attributions de rôles en ce qui concerne les personnes ayant les permissions d'accéder aux objets sur le cluster Kubernetes.

Pour plus d'informations, voir Azure RBAC pour l'autorisation Kubernetes.

Comptes locaux

AKS prend en charge l’authentification utilisateur Kubernetes native. Nous ne vous recommandons pas d'utiliser cette méthode pour fournir un accès utilisateur aux clusters. Cette méthode est basée sur des certifications et exécutée en dehors de votre fournisseur d'identité principal, ce qui rend votre contrôle d'accès utilisateur centralisé et votre gouvernance difficiles. Gérez toujours l'accès à votre cluster en utilisant Microsoft Entra ID, et configurez votre cluster pour désactiver explicitement l'accès aux comptes locaux.

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

Intégrer Microsoft Entra ID pour la charge de travail

À l’instar d’une identité managée affectée par le système Azure pour le cluster entier, vous pouvez attribuer 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, la charge de travail stocke les fichiers dans Stockage Azure. Lorsqu'il doit accéder à ces fichiers, le pod s'authentifie par rapport à la ressource en tant qu'identité gérée Azure.

Dans cette mise en œuvre de référence, Microsoft Entra ID de la charge de travail sur AKS fournit les identités gérées pour les pods. Cette approche s'intègre aux capacités natives de Kubernetes pour se fédérer avec des fournisseurs d'identité externes. Pour plus d'informations sur la fédération Microsoft Entra ID, voir Fédération d'identité de la charge de travail.

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

AKS prend en charge plusieurs modèles de mise en réseau, notamment kubenet, CNI et la superposition Azure CNI. Les modèles CNI sont les modèles les plus avancés et sont très performants. Lors de la communication entre les pods, les performances de CNI sont similaires à celles des machines virtuelles dans un réseau virtuel. CNI offre également un meilleur contrôle de la sécurité car il permet d'utiliser la stratégie réseau Azure. 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 du même réseau (ou des ressources appairées) peuvent accéder aux pods directement par le biais de leur adresse IP. La traduction d'adresses réseau (NAT) n'est pas nécessaire pour le routage de ce trafic.

Dans cette implémentation de référence, nous utilisons une superposition Azure CNI, qui alloue uniquement des adresses IP du sous-réseau du pool de nœuds pour les nœuds et utilise une couche de recouvrement hautement optimisée pour les IP de pods. Étant donné que la superposition Azure CNI utilise moins d’adresses IP de réseau virtuel que beaucoup d’approches, nous la recommandons pour les déploiements limités en adresses IP.

Pour plus d'informations sur les modèles, voir Choisir un modèle de réseau d'interface réseau de conteneur à utiliser et Comparer les modèles de réseau kubenet et Azure Container Networking Interface.

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 par le biais d'une adresse IP statique privée. Il fait office de point de contact unique recevant les flux entrants.

Cette architecture utilise Azure Load Balancer. L'équilibreur de charge se trouve à l'extérieur du cluster dans un sous-réseau dédié aux ressources ingress. Il reçoit le trafic de Application Gateway et cette communication se fait par le biais de la sécurité de la couche de transport (TLS). Pour plus d'informations sur le chiffrement TLS pour le trafic entrant, voir Flux de trafic entrant.
Le 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 provenant de l’équilibreur de charge interne, arrête TLS, et le transmet 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 lors de la configuration de 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 ne reçoit que le trafic en provenance d'Application Gateway.
Configurez les paramètres readinessProbe et livenessProbe qui surveillent l'intégrité des pods à l'intervalle spécifié. Le contrôleur d'entrée doit envoyer des signaux qui indiquent l'intégrité des pods.
Envisagez de restreindre l’accès du contrôleur d’entrée à des ressources spécifiques et la possibilité d’effectuer certaines actions. 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.

Remarque

Choisissez un contrôleur d'entrée approprié en fonction de vos besoins, de votre charge de travail, des 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 avec les services Azure. Par exemple, la mise en œuvre montre comment intégrer Traefik avec Microsoft Entra ID de charge de travail et Key Vault.

Vous pouvez également utiliser Application Gateway Ingress Controller, qui s'intègre bien avec AKS. Outre ses fonctionnalités de contrôleur d’entrée, il offre d’autres avantages. Par exemple, Application Gateway agit comme un point d’entrée du réseau virtuel de votre cluster. Il peut observer le trafic entrant dans le cluster. Utilisez Application Gateway si vous avez une application qui nécessite un pare-feu d'application Web. De plus, Application Gateway vous permet d'effectuer la terminaison TLS.

Pour plus d'informations sur la conception de l'entrée pour les conteneurs Windows sur AKS dans l'architecture de référence de base, voir Conteneurs Windows sur AKS.

Paramètres de 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 du réseau comprend

Le trafic entrant du client vers la charge de travail qui s'exécute dans le cluster.
Le trafic de sortie d'un pod ou d'un nœud dans le cluster vers un service externe.
Le trafic de 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.
Le trafic de gestion entre le client et le serveur 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. TLS de bout en bout est configuré via Application Gateway en utilisant deux certificats TLS différents, comme le montre 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 d'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 dispose d'un pare-feu d'application Web intégré et négocie la liaison TLS pour bicycle.contoso.com, en n'autorisant que les algorithmes de chiffrement sécurisés. La passerelle d'applications est un point de terminaison TLS, ce qui est important car le pare-feu de l'application Web de la passerelle d'applications doit inspecter la réponse en texte clair. Key Vault stocke la certification TLS. Le cluster y accède avec une identité gérée attribuée à l'utilisateur et intégrée à Application Gateway. Pour plus d'informations, consultez Arrêt de TLS avec des certificats Key Vault.

Application Gateway traite les règles d'inspection du pare-feu de l'application Web et exécute les règles de routage qui redirigent le trafic vers le back-end configuré.
Lorsque le trafic passe de l'Application Gateway au back-end, il est à nouveau chiffré à l'aide d'un autre certificat TLS, qui est un caractère générique pour *.aks-ingress.contoso.com, lors de son transfert vers l'équilibreur de charge 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 l’équilibreur de charge. 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 certifications sont stockées dans Key Vault et le pilote de l'interface de stockage de conteneurs (CSI) 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. Veillez à mesurer les performances, la latence et les effets opérationnels lorsque vous décidez de sécuriser le trafic de pod à pod. Pour la plupart des clusters à locataire unique, avec un plan de contrôle RBAC 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 le protéger avec un pare-feu d'application Web. 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. Votre charge de travail et vos exigences de conformité dictent l'endroit où vous effectuez la terminaison TLS.

Flux du trafic de sortie

Dans cette architecture, nous recommandons que tout le trafic sortant du cluster communique à travers le pare-feu Azure. Vous pouvez également utiliser votre propre appareil virtuel de réseau similaire. Nous ne recommandons pas l'utilisation d'autres options de sortie, telles que Azure NAT Gateway ou un proxy HTTP, car elles n'assurent pas l'inspection du trafic réseau. Pour le contrôle de la confiance zéro et la possibilité d'inspecter le trafic, tout le trafic sortant du cluster passe par le pare-feu. Vous pouvez mettre en œuvre cette configuration avec des routes définies par l'utilisateur (UDR). Le tronçon suivant de l'itinéraire est l'adresse IP privée de pare-feu Azure. Le pare-feu Azure décide de bloquer ou d'autoriser le trafic sortant. Cette décision est basée sur les règles spécifiques que vous définissez dans pare-feu Azure ou sur les règles intégrées de renseignement sur les menaces.

Une alternative à pare-feu Azure est d'utiliser la fonctionnalité de proxy HTTP d'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 l'une ou l'autre méthode, passez en revue les règles de trafic réseau de sortie requises pour AKS.

Remarque

Si vous utilisez un équilibreur de charge public comme point public pour le trafic entrant et le trafic sortant via le pare-feu à l'aide d'UDR, vous risquez d'être confronté à une situation de routage asymé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, en plus d’améliorer la sécurité, élimine les soucis de routage asymétrique. Vous pouvez également acheminer le trafic entrant via Firewall avant ou après Application Gateway, mais cette approche n'est pas nécessaire dans la plupart des situations et nous ne la recommandons pas. Pour plus d'informations sur le routage asymétrique, consultez Intégrer pare-feu Azure avec un équilibreur de charge standard Azure.

Une exception au contrôle de la confiance zéro est lorsque le cluster doit communiquer avec d'autres ressources Azure. Par exemple, le cluster peut avoir besoin de tirer une image mise à jour du Container Registry ou des secrets de Key Vault. Dans ces scénarios, nous vous recommandons d'utiliser la liaison privée. L'avantage 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 l'internet. L'inconvénient est que la liaison privée nécessite une configuration supplémentaire au lieu d'utiliser le service cible via son point de terminaison public. Par ailleurs, tous les services ou produits Azure ne prennent pas en charge la liaison privée. Dans ce cas, envisagez d'activer un point de terminaison de service de réseau virtuel sur le sous-réseau pour accéder au service.

Si la liaison privée ou les points de terminaison des services ne sont pas envisageables, vous pouvez accéder à d'autres services via leurs points de terminaison publics et contrôler l'accès via les règles du pare-feu Azure et le pare-feu intégré au service cible. Comme ce trafic passe par les adresses IP statiques du pare-feu, vous pouvez ajouter ces adresses à la liste des adresses IP autorisées du service. L'inconvénient est que pare-feu Azure a alors besoin de plus de règles pour s'assurer qu'il n'autorise que le trafic provenant d'un sous-réseau spécifique. Tenez compte de ces adresses lorsque vous prévoyez plusieurs adresses IP pour le trafic de sortie avec le pare-feu Azure. Sinon, vous risquez d'épuiser les ports. Pour plus d'informations sur la planification de plusieurs adresses IP, voir Créer un pare-feu Azure avec plusieurs adresses IP.

Pour en savoir plus sur les considérations d'egress spécifiques à Windows dans l'architecture de référence de base des conteneurs Windows sur AKS, voir Conteneurs Windows sur AKS.

Trafic de pod à pod

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 judicieusement les stratégies, sinon vous risquez de vous retrouver dans une situation où un flux réseau critique est bloqué. Selon vos besoins, autorisez uniquement des chemins de communication spécifiques, comme le trafic entre le contrôleur d’entrée et la charge de travail. Pour plus d’informations, consultez Stratégies réseau.

Activez la stratégie réseau lorsque vous provisionnez le cluster, car vous ne pourrez pas l'ajouter ultérieurement. Vous avez le choix entre plusieurs technologies qui mettent en œuvre NetworkPolicy. Nous vous recommandons la stratégie réseau Azure, qui nécessite Azure Container Networking Interface (CNI). Pour plus d'informations, consultez la note suivante. 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 le support Azure standard.

Pour plus d'informations, consultez Différences entre les moteurs de stratégie de réseau Azure.

Trafic de gestion

Dans le cadre de l'exécution du cluster, le serveur API Kubernetes reçoit du trafic de ressources qui veulent effectuer des opérations de gestion sur le cluster, telles que des requêtes de création de ressources pour mettre le cluster à l'échelle. Ces ressources sont par exemple le pool d'agents de construction 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 en provenance de toutes les adresses IP, utilisez la fonctionnalité Plages d'IP autorisées par l'AKS pour autoriser uniquement le trafic en provenance de vos plages d'IP autorisées vers le serveur API

Pour plus d'informations, voir Définir des plages d'adresses IP autorisées pour le serveur API.

Pour un autre niveau de contrôle, au prix d'une complexité accrue, vous pouvez provisionner un cluster AKS privé. En utilisant un cluster privé, vous pouvez vous assurer que le trafic réseau entre votre serveur API et vos pools de nœuds reste sur le réseau privé uniquement et n'est jamais exposé à Internet. Pour plus d'informations, voir Clusters privés AKS.

Ajouter la gestion des secrets

Stockez les secrets dans une base de stockage de clés gérée, telle que Key Vault. L'avantage est qu'une réserve de clés gérée gère la rotation des secrets. Il fournit un chiffrement puissant et un journal d'audit des accès. En outre, les secrets de base ne sont pas pris en compte dans le pipeline de déploiement. Dans cette architecture, un pare-feu Key Vault est activé et configuré, et la liaison privée est utilisée lors de la connexion à partir de ressources dans Azure qui doivent accéder aux secrets et aux certificats.

Key Vault est bien intégré aux autres services Azure. Utilisez la fonctionnalité intégrée de ces services pour accéder aux secrets. Pour plus d'informations sur la manière dont Application Gateway accède aux certifications TLS pour le flux d'entrée, consultez la section Flux de trafic d'entrée.

Le modèle de permission Azure RBAC pour Key Vault vous permet d'affecter les identités de charge de travail à l'attribution de rôle Utilisateur de secrets de Key Vault ou Lecteur de Key Vault, et d'accéder aux secrets. Pour plus d'informations, consultez la section Accéder à Key Vault à l'aide de RBAC.

Accéder aux secrets des clusters

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 d'extraction, utilisez un pilote CSI de magasin de secrets. Lorsque le module a besoin d'un secret, le pilote se connecte au magasin spécifié, récupère un secret sur un volume et monte ce volume dans le cluster. Le pod peut ensuite obtenir 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 pilote CSI Key Vault with secrets store. Le module complémentaire récupère la certification TLS à partir 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 module, et le volume stocke les clés publiques et privées.

Stockage de charge de travail

Dans cette architecture, la charge de travail est sans état. Si vous devez stocker un état, nous vous recommandons de le faire persister 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 Options de stockage 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, mettez en œuvre des stratégies par l'intermédiaire d'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 pour :

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.

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

Voulez-vous définir une collection de stratégies, également appelées initiatives, ou choisir des stratégies individuelles ? Azure Policy propose 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 et 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.
Voulez-vous opter pour l’Audit ou le Refus de l’action ? En mode audit, l'action est autorisée mais signalé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 ce mode, car il peut être trop restrictif pour le fonctionnement de la charge de travail.
Y a-t-il des parties de votre charge de travail qui ne doivent pas être conformes de façon délibérée ? Azure Policy a la capacité de spécifier des espaces noms Kubernetes qui sont exemptés de l'application de la stratégie. Nous vous recommandons de continuer à appliquer des stratégies en mode Audit afin d'être au courant de ces cas.
Avez-vous des exigences qui ne sont pas couvertes par les stratégies intégrées ? Vous pouvez créer une définition Azure Policy personnalisée qui applique vos stratégies d’opérateur OPA Gatekeeper personnalisées. N’appliquez pas aucune stratégie personnalisée directement au cluster. Pour plus d'informations, reportez-vous à la section Créer et affecter des définitions de stratégies personnalisées.
Avez-vous 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.
Attribuez-vous des stratégies Azure à des portées spécifiques ? Assurez-vous que les stratégies de production sont également validées par rapport à votre environnement de préproduction. Sinon, lors du déploiement dans votre environnement de production, vous risquez de rencontrer des restrictions supplémentaires inattendues que vous n'avez pas prises 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 attribué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 le fonctionnement d'Azure Policy depuis votre cluster, vous pouvez accéder aux journaux des pods pour tous les pods de l'espace noms gatekeeper-system et aux journaux des pods azure-policy et azure-policy-webhook de l'espace noms kube-system.

Pour plus d'informations sur les considérations d'Azure Policy spécifiques à Windows, consultez l'article sur la gestion des stratégies des conteneurs Windows sur AKS.

Scalabilité des nœuds et des pods

Avec l'augmentation de la demande, Kubernetes peut se mettre à l'échelle en ajoutant plus de pods aux nœuds existants, grâce à l'autoscaling horizontal 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 être en mesure de mettre à l’échelle les réplicas de pod, ainsi que 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 Azure CLI ou le portail Azure.

Nous recommandons l'approche autoscaling car certains de ces mécanismes manuels sont intégrés dans l'autoscaler.

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. Pour plus d'informations sur un scénario d'optimisation des performances à l'aide d'AKS, consultez Scénario d'optimisation des performances : Transactions commerciales distribuées.

Autoscaler de pods horizontaux

L’autoscaler de pods horizontaux (HPA) est une ressource Kubernetes qui met à l’échelle le nombre de pods.

Dans la ressource HPA, nous vous recommandons de définir le nombre minimum et maximum de répliques. 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 d'origine. 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 surutilisés ou sous-utilisés. Il s’appuie sur le planificateur Kubernetes pour affecter de nouveaux pods aux nœuds ou supprimer des pods des nœuds.

Il peut y avoir une condition de course où le HPA vérifie avant qu'une opération de mise à l'échelle ne se termine. Il peut en résulter un calcul de ratio incorrect. Pour plus d'informations, consultez la section Refroidissement 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). Envisagez KEDA si une source d'événements, telle qu'une file d'attente de messages, est le lecteur de votre charge de travail, plutôt que votre charge de travail soit 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 dans les scalers KEDA. La liste inclut le scaler Azure Monitor, qui est un moyen pratique de mettre à l'échelle les charges de travail KEDA sur la base des mesures Azure Monitor.

Autoscaler de cluster

L’autoscaler de cluster est un module complémentaire AKS qui met à l’échelle le nombre de nœuds d’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, l’autoscaler approvisionne 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 à la 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.

Pour plus d'informations sur les considérations de mise à l'échelle spécifiques à Windows incluses dans cette architecture de référence de base, consultez l'article sur les conteneurs Windows sur AKS.

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 Recommandations pour définir des objectifs de fiabilité. Examinez les conditions du contrat SLA (Service Level Agreement) pour AKS dans le dernier article SLA pour les services en ligne.

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. Pour plus de disponibilité, approvisionnez davantage de 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. Assurez-vous que le pool de nœuds de votre système est entaché de la mention CriticalAddonsOnly taint.

L'entretien régulier de votre cluster, comme les mises à jour opportunes, est essentiel à sa fiabilité. Nous vous recommandons également de surveiller l'intégrité des modules à l'aide de sondes.

Disponibilité de pod

Spécifiez les ressources requises pour les modules : Nous vous recommandons de spécifier les ressources requises pour les pods 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 de perturbation des pods : Ce paramètre détermine le nombre de répliques d'un déploiement qui peuvent tomber en panne lors d'un événement de mise à jour ou de mise à niveau. Pour plus d’informations, consultez Budgets d’interruption de pod.

Au sein du déploiement, configurez plusieurs réplicas afin de gérer les interruptions, 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 aider à garantir que le nombre requis 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 la charge de travail : Le quota de ressources sur un espace de noms permet de s'assurer que les requêtes et les limites de pods sont correctement définies sur un déploiement. Pour plus d’informations, consultez Appliquer des quotas de ressources.

Remarque

Si vous définissez des quotas de ressources au niveau du cluster, des problèmes peuvent survenir si vous déployez des charges de travail tierces pour lesquelles les requêtes et les limites ne sont pas appropriées.

Définissez les requêtes et les limites des pods : Définir des requêtes et des limites permet à Kubernetes d'allouer efficacement les ressources processeur et mémoire aux pods, et vous permet d'avoir une densité de conteneurs 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, réglez progressivement ces valeurs jusqu'à ce que vous établissiez un seuil susceptible de provoquer une 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 Définir des demandes et limites de pod.

Zones de disponibilité et prise en charge multirégion

Pour vous protéger contre certains types de pannes, utilisez des zones de disponibilité si la région les prend en charge. Les composants du plan de contrôle et les nœuds des pools de nœuds peuvent alors être répartis entre les 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 groupe de machines virtuelles identiques distinct qui gère les instances de nœuds et la scalabilité. Le service AKS gère les opérations et la configuration des jeux d'échelle. Voici quelques considérations à prendre en compte lorsque vous activez plusieurs zones :

Toute l'infrastructure : 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 contrat SLA de disponibilité est plus important lorsque vous utilisez des zones de disponibilité.
Cluster : Vous ne pouvez définir des zones de disponibilité 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. Le groupe de machines virtuelles identiques sous-jacent fournit la même configuration matérielle entre les zones.

La prise en charge de zones multiples s'applique non seulement aux pools de nœuds, mais aussi 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 pleinement de la prise en charge des zones, tous les services dépendants 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, un disque géré est disponible dans la zone où il a été approvisionné. En cas de panne, le nœud peut être déplacé vers une autre zone, mais le disque géré n'est pas déplacé avec le nœud vers cette zone.

Pour simplifier cette architecture, AKS est déployé dans une région unique avec des pools de nœuds couvrant les zones de disponibilité 1, 2 et 3. D'autres ressources de l'infrastructure, telles que le pare-feu Azure et Application Gateway, sont également déployées dans la même région avec une prise en charge de plusieurs zones. La géo-réplication est activée pour Container Registry.

Plusieurs régions

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

Préférez les régions appariées 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 veille à ce qu’une seule région de la paire soit mise à jour à la fois. Certaines régions n'ont pas d'appairage. 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. Certains outils DevOps tels que Flux facilitent 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éo-redondance. Par exemple, en activant la géo-réplication pour Container Registry, il réplique automatiquement les images vers les régions Azure sélectionnées. Cela permet également de continuer à accéder 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 un équilibreur de charge parce qu'il peut répartir le trafic non web entre les zones. Si vous avez besoin de distribuer le trafic entre les régions, envisagez Azure Front Door. Pour d'autres options, voir Choisir un équilibreur de charge.

Remarque

L'architecture de référence de l'AKS pour les clusters multirégions étend l'architecture de cet article pour inclure plusieurs régions dans une configuration active/active et hautement disponible.

Récupération d’urgence

Si une panne survient dans la région principale, vous pouvez idéalement créer rapidement une nouvelle instance dans une autre région. Voici quelques recommandations :

Utilisez plusieurs régions. Si votre région principale a une région appairé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 de l'état dans le cluster, ce que nous ne recommandons pas, assurez-vous de sauvegarder fréquemment les données dans une autre région.
Intégrez la stratégie de récupération, telle que la réplication vers une autre région, dans le cadre du pipeline DevOps afin de respecter votre SLO.
Provisionnez chaque service Azure en utilisant des fonctionnalités qui prennent en charge la reprise après sinistre. 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 approvisionner un nouveau cluster et le remettre en état de fonctionnement par le biais d'un amorçage de cluster basé sur les opérations Git, suivi d'un déploiement d'applications. Mais s'il existe des ressources critiques, telles que des mappages de configuration, des travaux et des secrets qui ne peuvent pas être capturés dans le cadre de votre processus d'amorçage, réfléchissez à votre stratégie de récupération. Nous vous recommandons d'exécuter les charges de travail sans état dans 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 du 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 chargé de pousser l'état des ressources du cluster vers une destination de votre choix et de coordonner les instantanés de volumes persistants basés sur le 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 mise en œuvre gérée de Velero. 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 Sauvegarde Azure.

L'implémentation de référence ne met pas en œuvre la sauvegarde, qui implique des ressources Azure supplémentaires à gérer, surveiller, acheter et sécuriser. Ces ressources peuvent inclure un compte Azure Storage, un coffre-fort et une configuration Azure Backup, ainsi que la fonctionnalité d'accès sécurisé. Au lieu de cela, les opérations Git combinées 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 commercial, y compris l'objectif de point de récupération et l'objectif de temps de récupération que vous avez définis. 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 n'offre pas de SLA soutenu financièrement. Pour obtenir un contrat SLA, vous devez choisir le niveau Standard. Nous recommandons d’utiliser le niveau Standard pour tous les clusters de production. Réservez le niveau Free aux clusters de préproduction et le niveau Premium aux seules charges de travail critiques. Lorsque vous utilisez des zones de disponibilité Azure, le contrat SLA du serveur API Kubernetes est plus élevé. 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 à chaque service, reportez-vous à la rubrique Contrats SLA pour les services en ligne.

Compromis

Le déploiement de l’architecture entre les zones et les régions notamment impose un compromis en termes de coût et de disponibilité. Certaines fonctionnalités de réplication, telles que la géo-réplication dans Container Registry, sont disponibles dans les SKU premium, ce qui est plus cher. 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 latence supplémentaire du réseau dans la communication des nœuds entre les zones ou les régions. Mesurez l'effet de cette décision architecturale sur votre charge de travail.

Tester la conception avec 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 journaux et des métriques

Nous vous recommandons Azure Monitor container insights pour surveiller les performances des charges de travail des conteneurs, car vous pouvez afficher les événements en temps réel. Elle capture les journaux de conteneur à partir des modules en cours d’exécution et les agrège pour les afficher. 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 l'aperçu des conteneurs pour surveiller les performances au fur et à mesure que les pods évoluent. Il inclut la télémétrie qui est essentielle pour la surveillance, l'analyse et la visualisation des données collectées. Container insights identifie les tendances et vous permet de configurer des alertes pour recevoir des notifications proactives sur les problèmes critiques.

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 Azure Log Analytics.

La plupart des charges de travail hébergées dans des pods émettent des métriques Prometheus. Container insights peut s'intégrer à Prometheus. Vous pouvez consulter les mesures de l'application et de la charge de travail collectées à partir des nœuds et de Kubernetes.

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.

Avec AKS, Azure gère certains des services de base de Kubernetes. Azure met en œuvre les journaux des composants du plan de contrôle AKS en tant que journaux de ressources. Nous vous recommandons d'activer les options suivantes sur la plupart des clusters. Les options peuvent vous aider à dépanner les problèmes de cluster, et elles ont une densité de journaux relativement faible.

ClusterAutoscalerLes options suivantes peuvent vous aider à résoudre les problèmes de la grappe et ont une densité de journaux relativement faible: : gagner en observabilité dans les opérations de mise à l'échelle avec le journal. Pour plus d’informations, consultez Récupérer les journaux et l’état de la mise à l’échelle automatique des clusters.
KubeControllerManager : gagner en observabilité dans l'interaction entre Kubernetes et le plan de contrôle Azure.
kube-audit-adminLa journalisation permet d'observer les activités qui modifient votre cluster. Il n'y a aucune raison d'activer à la fois kube-audit et kube-audit-admin. kube-audit : est un surensemble de kube-audit-admin qui inclut également les opérations de lecture non modifiées.
guard : capturer les audits Microsoft Entra ID et Azure RBAC.

Il peut être utile d'activer d'autres catégories de journaux, telles que KubeScheduler ou kube-audit, au cours des premières phases de développement du cluster ou du cycle de vie de la charge de travail. 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. Mais si vous conservez les journaux de dépannage étendus à plein temps après la fin de vos besoins de dépannage, vous risquez d'encourir des coûts inutiles pour ingérer et stocker les données dans Azure Monitor.

Bien qu’Azure Monitor inclue un ensemble de requêtes de journal existantes pour commencer, vous pouvez également les utiliser comme base pour aider à créer vos propres requêtes. Au fur et à mesure que votre bibliothèque s'agrandit, vous pouvez enregistrer et réutiliser les requêtes de journaux en utilisant un ou plusieurs packs de requêtes. Votre bibliothèque personnalisée de requêtes offre une meilleure observabilité de l'intégrité et des performances de vos clusters AKS. Elle vous aide à atteindre vos objectifs stratégiques.

Pour plus d'informations sur nos meilleures pratiques de surveillance pour AKS, voir Surveiller AKS avec Azure Monitor.

Pour plus d'informations sur les considérations de surveillance spécifiques à Windows, voir Conteneurs Windows sur AKS.

Mesures du réseau

Des mesures de réseau de base, au niveau du cluster, sont disponibles via la plateforme native et les mesures Prometheus. Vous pouvez utiliser davantage l’observabilité réseau AKS 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 résolution des problèmes 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 Container Insights, qui collecte également certaines métriques liées au réseau. L’implémentation de référence désactive la collecte de métriques à partir d’Insights de conteneur Azure Monitor et collecte plutôt les métriques d’observabilité réseau à l’aide d’un espace de travail Azure Monitor avec Prometheus managé.

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 trouver ce niveau de détail avec la fonctionnalité d’observabilité réseau avancée. 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 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 le plan de table le plus économique 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. En surveillant les modèles d’utilisation et en ajustant 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électionner un plan de table en fonction de l’utilisation des données dans un espace de travail Log Analytics.

Activer la réparation spontanée

Surveillez l'intégrité des pods en définissant des sondes de liveness et de readiness. 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.

Remarque

AKS dispose d'une fonctionnalité de réparation automatique des nœuds 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 :

La version de Kubernetes (par exemple, Kubernetes 1.30.3 à 1.30.7 ou Kubernetes 1.30.7 à 1.31.1), qui peut s'accompagner de modifications et de 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 natif 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 de mise à jour de chaque cluster AKS, de ses pools de nœuds ou de ses nœuds (la cadence). Choisissez également les jours ou les heures d'application des 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 une perspective complète sur les correctifs et les mises à jour, consultez les conseils sur les correctifs et les mises à jour de l'AKS dans le guide des opérations du jour 2 de l'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 nœud 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. Lorsqu'une mise à jour que vous souhaitez devient disponible, vous devez la tester dans un environnement de préproduction et évaluer sa compatibilité sur un nouveau cluster. Ensuite, déployez un cachet réplica de production qui inclut la version AKS mise à jour et les VHD de pool de nœuds. Lorsque le nouveau cluster de production est prêt, l'ancien cluster est vidé et finit par être mis hors service.

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 en place

Les charges de travail qui n'exploitent pas les clusters AKS en tant qu'infrastructure immuable doivent régulièrement mettre à jour leurs clusters en cours d'exécution, afin de prendre en compte 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.

Programmez la fonctionnalité de maintenance planifiée d'AKS afin de pouvoir contrôler les mises à niveau de 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 de sorte que votre application reste stable pendant les mises à jour progressives. 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, connues sous le nom de nœuds de pointe, avant que les anciens nœuds ne soient supprimés. Cela signifie que le quota Azure et l’espace d’adresses IP doivent être disponibles pour les nouveaux nœuds. Une valeur de surcharge de 33 % est un bon point de départ pour la plupart des charges de travail.
Testez la compatibilité avec les outils, tels que les maillages de services ou les agents de sécurité que vous avez ajoutés à votre cluster. Testez également les composants de votre charge de travail, tels que les contrôleurs d'entrée, les maillages de services et les pods de charge de travail. Effectuez des tests dans un environnement de préproduction.

Mises à niveau en place pour les nœuds

Utilisez la chaîne de mise à niveau automatique NodeImage pour les mises à niveau de l'image du système d'exploitation du nœud. Cette chaîne configure votre cluster pour qu'il mette à jour le VHD sur chaque nœud avec des mises à jour au niveau du 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, ces mises à jour ont lieu 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 de l'image du nœud que vous utilisez pour garantir une application opportune.
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 des images et les numéros de version des composants inclus font l'objet d'un suivi à l'aide du système de suivi des versions 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 ne sont publiées que s'il existe des mises à niveau de sécurité que Microsoft juge suffisamment importantes pour les publier avant la prochaine mise à jour programmée de l'image du 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 de la chaîne SecurityPatch honore toujours vos fenêtres de maintenance. Veillez donc à ce que votre fenêtre de maintenance comporte des intervalles plus fréquents (par exemple, tous les jours ou tous les deux jours) afin de prendre en charge ces mises à jour de sécurité inattendues.

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 en place du cluster

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 deux versions les plus récentes ou 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 de version d'AKS sur place peut la plupart du temps ê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 jugées trop risquées pour votre charge de travail, nous vous recommandons d'utiliser une approche de 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 du cluster lors du premier déploiement d'un cluster Kubernetes. 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 à jour » plutôt qu'une approche de support à long terme.

Avertissement

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, voir Mettre régulièrement à jour vers la dernière version de Kubernetes et Mettre à niveau un cluster AKS.

Vous pouvez recevoir des notifications lorsqu’une nouvelle version d’AKS est disponible pour votre cluster en utilisant le sujet système AKS pour Azure Event Grid. La mise en œuvre de référence déploie ce sujet système Event Grid afin que vous puissiez vous abonner à l’événement Microsoft.ContainerService.NewKubernetesVersionAvailable depuis votre solution de notification de flux d’événements. Consultez les notes de mise à jour d'AKS pour connaître les problèmes de compatibilité spécifiques, les changements de comportement ou les dépréciations de fonctionnalités.

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 serait rare de passer au-delà de patch. Par ailleurs, lors de la mise à niveau automatique de votre version d'AKS, vérifiez également le paramètre de version d'AKS de votre infrastructure en tant que code (IaC) pour votre cluster afin qu'ils ne se désynchronisent pas. Configurez votre fenêtre de maintenance planifiée pour prendre en charge l'opération de mise à niveau automatique.

Supervision de la sécurité

Surveillez votre infrastructure de conteneurs pour détecter les menaces actives et les risques de sécurité potentiels. Voici quelques ressources :

Microsoft Defender for Containers pour identifier et remédier aux recommandations de Defender for Cloud pour vos images de conteneurs.
Defender for Containers analyse régulièrement vos images de conteneurs à la recherche de vulnérabilités.
Defender for Containers génère également des alertes de sécurité en temps réel en cas d'activités suspectes.
Les concepts de sécurité d'AKS pour les applications et les clusters détaillent des informations sur la façon dont la sécurité des conteneurs protège l'ensemble du pipeline de bout en bout, de la construction aux charges de travail des applications exécutées dans AKS.

Opérations sur les clusters et les charges de travail

Pour 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 de cluster

Après avoir effectué le provisionnement, vous disposez d'un cluster fonctionnel, mais il se peut que vous ayez encore quelques étapes requises avant de pouvoir déployer des charges de travail. Le processus de préparation de votre cluster est appelé bootstrapping. L'amorçage peut consister à déployer des images prérequises sur les nœuds du cluster, à créer des espaces de noms et à effectuer d'autres tâches qui répondent aux exigences du cas d'utilisation de votre organisation.

Pour réduire l'écart entre un cluster provisionné et un cluster correctement configuré, les opérateurs de clusters doivent réfléchir à leur propre processus de bootstrapping. Ils doivent préparer les ressources nécessaires à l'avance. Par exemple, s'il est important que Kured fonctionne sur chaque nœud avant de déployer des charges de travail, l'opérateur de cluster doit vérifier qu'une instance de Container Registry contenant l'image Kured cible existe déjà avant de provisionner le cluster.

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.

Remarque

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 pourriez plutôt opter pour l'intégration du processus dans un ou plusieurs pipelines de déploiement afin de garantir l'amorçage. 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. Elle met en place l'environnement avec une base de gestion solide pour le transfert, et elle permet également d'inclure ce bootstrapping en tant que modèles de ressources pour s'aligner sur votre stratégie IaC.

Enfin, lorsque vous utilisez l'extension, kubectl n'est requis pour aucune partie du processus de démarrage. Vous pouvez réserver l'accès basé sur kubectl aux situations de dépannage d'urgence. Entre les modèles pour les définitions de ressources Azure et le bootstrapping des manifestes via l'extension GitOps, vous pouvez effectuer toutes les activités de configuration normales sans avoir besoin d'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.

Dans un premier temps, utilisez une charge de travail de base contenant les composants fondamentaux à des fins de création. Une première tâche consiste à configurer le réseau. Provisionnez des réseaux virtuels pour le hub et les spoke, ainsi que des sous-réseaux au sein de ces réseaux. Par exemple, un spoke dispose de sous-réseaux distincts pour les pools de nœuds système et utilisateur et les ressources d'entrée. Déployez un sous-réseau pour la pare-feu Azure dans le hub.

Une autre tâche consiste à intégrer la charge de travail de base avec 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. Vous pouvez utiliser Bicep, les modèles du gestionnaire de ressources Azure (modèles ARM) ou Terraform.

Veillez à provisionner les ressources selon les stratégies gouvernantes. 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 Azure CLI. Ces commandes couvrent une gamme de services Azure et vous pouvez les automatiser à l'aide de scripts. Windows et Linux prennent en charge Azure CLI. Azure PowerShell constitue une autre option multiplateforme. 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.

Charge de travail - CI/CD

Les pipelines pour le workflow et le déploiement doivent pouvoir construire et 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 workflow et le déploiement. D'autres options populaires incluent Azure DevOps et Jenkins.

Cluster - CI/CD

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

Plutôt qu’une approche impérative comme kubectl, optez pour des outils qui synchronisent automatiquement les modifications de cluster et de référentiel. Pour gérer le workflow, 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 du cluster pour déclencher des déploiements dans Kubernetes. Flux effectue les tâches suivantes :

Il surveille tous les référentiels configurés.
Il détecte toutes les modifications de configuration.
Il déclenche des déploiements.
Il met à jour la configuration 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.

Voici un exemple qui montre comment automatiser la configuration du cluster avec GitOps et Flux :

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

Un développeur apporte des modifications au code source, comme les fichiers YAML de configuration, qui sont stockés dans un référentiel 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 référentiel Git pour s'assurer que Flux n'applique que les modifications 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 d'accès direct à 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 recommandons l'extension de cluster GitOps with Flux v2 pour AKS.

Stratégies de déploiement de charge de travail et de cluster

Déployez tout changement, tel que les composants de l'architecture, la charge de travail et la configuration du cluster sur au moins un cluster AKS de préproduction. Cela permet de simuler le changement et d'identifier les problèmes avant qu'ils ne soient déployés en production.

Exécutez des tests et des validations à chaque étape avant de passer à la 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 devrait suivre un schéma similaire à celui de la production, en utilisant le même pipeline d'actions GitHub ou les mêmes opérateurs Flux.

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

Gestion des coûts

Commencez par examiner la liste de contrôle de la conception de l'optimisation des coûts et la liste des recommandations présentées dans Well-Architected Framework for AKS. Utilisez le calculateur de prix Azure pour estimer les coûts des services que vous utilisez dans l'architecture. Pour d'autres meilleures pratiques, consultez Optimisation des coûts.

Envisagez d'utiliser l'analyse des coûts AKS pour une répartition granulaire des coûts de l'infrastructure du cluster par des constructions spécifiques à Kubernetes.

Pour en savoir plus sur les considérations de gestion des coûts spécifiques à Windows, voir Conteneurs Windows sur AKS.

Approvisionner

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, ce sont les instances de machines virtuelles, le stockage, 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 DS2_v2 est un type de machine virtuelle typique pour le pool de nœuds système.
N’utilisez pas la même configuration pour les environnements dev/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.
Ajoutez un contrat SLA 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, le SLO est suffisant. De plus, si votre charge de travail le permet, 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 Azure SQL Database ou Azure App Service dans le cadre de l'architecture de charge de travail AKS, évaluez si vous pouvez utiliser les abonnements Azure Dev/Test pour bénéficier de remises sur les services.
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 requêtes et les limites des pods pour permettre à Kubernetes d'allouer des ressources de nœuds avec une densité plus élevée afin que vous utilisiez le matériel au maximum de ses capacités.
Considérez que lorsque vous activez les diagnostics sur le cluster, cela peut augmenter le coût.
Engagez-vous sur des instances de machines virtuelles Azure réservées d'un an ou de trois ans pour réduire les coûts des nœuds si votre charge de travail doit exister pendant une longue période. Pour plus d'informations, reportez-vous à la section Réduisez vos coûts grâce aux Instances de machines virtuelles Azure réservées.
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. En outre, si le cluster est partagé entre équipes, créez des rapports de facturation interne par consommateur pour identifier les coûts contrôlés pour les services cloud partagés. Pour plus d’informations, consultez Spécifier une teinte, une balise ou une étiquette 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 afin de recevoir des notifications lorsque certains seuils sont dépassés. Pour plus d’informations, consultez Créer un budget en utilisant 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 propose des options pour surveiller et analyser les coûts :

Idéalement, surveillez vos coûts en temps réel ou au moins à intervalles réguliers. Vous pouvez ainsi prendre des mesures avant la fin du mois, lorsque les coûts sont déjà calculés. Suivez également les tendances mensuelles au fil du temps afin de respecter votre 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. Les compteurs d’utilisation peuvent être consultés dans les métriques Azure Monitor.

Optimiser

Agissez sur les recommandations proposées par Azure Advisor. Il existe d’autres modes d’optimisation :

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

La modification agressive des paramètres de l'autoscaler de cluster, tels que les paramètres de nœuds minimum et maximum pour un pool de nœuds, afin d'influer sur les coûts peut avoir des résultats contre-productifs. Par exemple, si scale-down-unneeded-time est défini sur 10 minutes et que les paramètres minimum et maximum des nœuds sont modifiés toutes les cinq minutes en fonction des caractéristiques de la charge de travail, le nombre de nœuds ne diminuera jamais. En effet, le calcul du temps non nécessaire pour chaque nœud est réinitialisé en raison de l'actualisation des paramètres de l'autoscaler de cluster.
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 rapide, envisagez de dimensionner le cluster à la taille appropriée en analysant les métriques de performances au fil du temps.
Si votre charge de travail le permet, réduisez vos pools de nœuds utilisateur à 0 nœud lorsqu'il n'est pas prévu qu'ils fonctionnent. De même, s'il n'y a plus de travail prévu dans votre cluster, envisagez d'utiliser la fonctionnalité de démarrage/arrêt d'AKS pour arrêter tout le calcul, y compris votre pool de nœuds système et le plan de contrôle d'AKS.

Pour plus d’informations sur les coûts, consultez Tarification AKS.

Partager via

Architecture de référence pour un cluster Azure Kubernetes Service (AKS)

Configuration de la mise en réseau

Calcul de cluster

Gestion des identités

Sécuriser le flux de données

Continuité de l’activité

Opérations

Topologie du réseau

Réseau virtuel hub

Sous-réseau pour héberger Pare-feu Azure

Sous-réseau pour héberger une passerelle

Sous-réseau pour héberger Azure bastion

Réseau virtuel Spoke

Sous-réseau pour héberger 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 les points de terminaison de la liaison privée Azure.

Planifier les adresses IP

Espace d’adressage IP 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 à Azure

Accès au cluster

Associer le système RBAC de 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 de routeur

Sécuriser le flux réseau

Flux de trafic d’entrée

Flux du trafic de sortie

Trafic de pod à pod

Trafic de gestion

Ajouter la gestion des secrets

Accéder aux secrets des clusters

Stockage de charge de travail

Gestion des stratégies

Scalabilité des nœuds et des pods

Autoscaler de pods horizontaux

Autoscaler de cluster

Décisions de continuité des activités :

Nœuds de cluster

Disponibilité de pod

Zones de disponibilité et prise en charge multirégion

Plusieurs régions

Récupération d’urgence

Sauvegarde de cluster

Contrat SLA pour le serveur API Kubernetes

Compromis

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

Surveiller et collecter des journaux et des métriques

Mesures du réseau

Optimisation des coûts pour la journalisation

Activer la réparation spontanée

Mises à jour de routine pour les clusters AKS

Infrastructure immuable

Mises à niveau en place

Mises à niveau en place pour les nœuds

Mises à jour en place du cluster

Supervision de la sécurité

Opérations sur les clusters et les charges de travail

Démarrage de cluster

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

Utiliser IaC

Charge de travail - CI/CD

Cluster - CI/CD

Stratégies de déploiement de charge de travail et de cluster

Gestion des coûts

Approvisionner

Monitor

Optimiser

Étapes suivantes