Revue d’Azure Well-Architected Framework - Azure Kubernetes Service (AKS)
Cet article fournit des meilleures pratiques architecturales pour Azure Kubernetes Service (AKS). Les conseils sont basés sur les cinq piliers de l’excellence de l’architecture :
- Fiabilité
- Sécurité
- Optimisation des coûts
- Excellence opérationnelle
- Efficacité des performances
Nous partons du principe que vous comprenez les principes de conception du système, que vous connaissez bien Azure Kubernetes Service et que vous connaissez bien ses fonctionnalités. Pour plus d’information, consultez Azure Kubernetes Service.
Prérequis
Comprendre les piliers well-architected Framework peut aider à produire une architecture cloud de haute qualité, stable et efficace. Nous vous recommandons de passer en revue votre charge de travail à l’aide de l’évaluation de la révision d’Azure Well-Architected Framework.
Pour le contexte, envisagez d’examiner une architecture de référence qui reflète ces considérations dans sa conception. Nous vous recommandons de commencer par l’architecture de base d’une architecture de cluster et de microservices Azure Kubernetes Service (AKS) sur Azure Kubernetes Service. Passez également en revue l’accélérateur de zone d’atterrissage AKS, qui fournit une approche architecturale et une implémentation de référence pour préparer des abonnements de zone d’atterrissage pour un cluster Azure Kubernetes Service (AKS) évolutif.
Fiabilité
Dans le cloud, nous reconnaissons que des échecs se produisent. Au lieu d’essayer d’empêcher toutes les défaillances, l’objectif est de réduire les répercussions d’une défaillance potentielle au niveau de chaque composant. Utilisez les informations suivantes pour réduire les instances ayant échoué.
Lorsque vous discutez de la fiabilité avec Azure Kubernetes Service, il est important de faire la distinction entre la fiabilité du cluster et la fiabilité de la charge de travail. La fiabilité du cluster est une responsabilité partagée entre l’administrateur du cluster et son fournisseur de ressources, tandis que la fiabilité de la charge de travail est le domaine d’un développeur. Azure Kubernetes Service a des considérations et des recommandations pour ces deux rôles.
Dans la liste de contrôle de conception et la liste des recommandations ci-dessous, les légendes sont effectuées pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.
Check-list pour la conception
- Architecture de cluster : pour les charges de travail critiques, utilisez des zones de disponibilité pour vos clusters AKS.
- Architecture du cluster : planifiez l’espace d’adressage IP pour vous assurer que votre cluster peut effectuer une mise à l’échelle fiable, notamment la gestion du trafic de basculement dans les topologies multi-cluster.
- Architecture de cluster : passez en revue les meilleures pratiques pour surveiller Kubernetes avec Azure Monitor afin de déterminer la meilleure stratégie de supervision pour vos charges de travail.
- Architecture de la charge de travail : assurez-vous que les charges de travail sont conçues pour prendre en charge la mise à l’échelle horizontale et la préparation des applications de rapport et l’intégrité.
- Architectures de cluster et de charge de travail : vérifiez que votre charge de travail s’exécute sur des pools de nœuds utilisateur et choisissez la référence SKU de taille appropriée. Au minimum, incluez deux nœuds pour les pools de nœuds utilisateur et trois nœuds pour le pool de nœuds système.
- Architecture de cluster : utilisez le contrat SLA de temps d’activité AKS pour répondre aux objectifs de disponibilité des charges de travail de production.
Recommandations relatives à la configuration de AKS
Explorez le tableau de recommandations suivant pour optimiser votre configuration AKS pour la fiabilité.
| Recommandation | Avantage |
|---|---|
| Architectures de cluster et de charge de travail : contrôler la planification des pods à l’aide de sélecteurs de nœuds et d’affinité. | Permettent au planificateur Kubernetes d’isoler logiquement les charges de travail par matériel dans le nœud. Contrairement aux tolérances, les pods sans sélecteur de nœud correspondant peuvent être planifiés sur des nœuds étiquetés, ce qui permet aux ressources inutilisées sur les nœuds de consommer, mais donne la priorité aux pods qui définissent le sélecteur de nœud correspondant. Utilisez l’affinité de nœud pour plus de flexibilité, vous permettant de définir ce qui se passe si le pod ne peut pas être mis en correspondance avec un nœud. |
| Architecture du cluster : vérifiez la sélection appropriée du plug-in réseau en fonction de la configuration réseau requise et du dimensionnement du cluster. | Azure CNI est requis pour des scénarios spécifiques, par exemple, des pools de nœuds basés sur Windows, des exigences de mise en réseau spécifiques et des stratégies réseau Kubernetes. Référencez Kubenet et Azure CNI pour plus d’informations. |
| Architectures de cluster et de charge de travail : utilisez le contrat SLA de temps d’activité AKS pour les clusters de niveau production. | Le contrat SLA AKS Uptime garantit : - 99.95%disponibilité du point de terminaison du serveur d’API Kubernetes pour les clusters AKS qui utilisent Azure Zones de disponibilité ou- 99.9% une disponibilité pour les clusters AKS qui n’utilisent pas les zones de disponibilité Azure. |
| Architectures de cluster et de charge de travail : passez en revue les meilleures pratiques pour surveiller Kubernetes avec Azure Monitor afin de déterminer la meilleure stratégie de surveillance pour vos charges de travail. | S/O |
| Architecture de cluster : utilisez des zones de disponibilité pour optimiser la résilience au sein d’une région Azure en distribuant des nœuds d’agent AKS entre des centres de données physiquement distincts. | En répartissant des pools de nœuds entre plusieurs zones, les nœuds d’un pool de nœuds continuent d’être exécutés même si une autre zone a diminué. Si des exigences de colocalité existent, un déploiement AKS basé sur des groupes de machines virtuelles identiques standard dans une seule zone ou des groupes de placement de proximité peut être utilisé pour réduire la latence entre nœuds. |
| Architecture de cluster : adoptez une stratégie multirégion en déployant des clusters AKS déployés dans différentes régions Azure pour optimiser la disponibilité et assurer la continuité de l’activité. | Les charges de travail accessibles sur Internet doivent tirer parti d’Azure Front Door ou d’Azure Traffic Manager pour acheminer le trafic globalement entre les clusters AKS. |
| Architectures de cluster et de charge de travail : définissez les demandes et les limites des ressources pod dans les manifestes de déploiement d’application et appliquez-les avec Azure Policy. | Les limites de ressources processeur et mémoire du conteneur sont nécessaires pour empêcher l’épuisement des ressources dans votre cluster Kubernetes. |
| Architectures de cluster et de charge de travail : conservez le pool de nœuds système isolé des charges de travail d’application. | Les pools de nœuds système nécessitent une référence SKU de machine virtuelle d’au moins 2 processeurs virtuels et 4 Go de mémoire, mais 4 processeurs virtuels ou plus sont recommandés. Consultez Pools de nœuds système et utilisateur pour obtenir des spécifications détaillées. |
| Architectures de cluster et de charge de travail : séparez les applications aux pools de nœuds dédiés en fonction des exigences spécifiques. | Les applications peuvent partager la même configuration et avoir besoin de machines virtuelles compatibles GPU, d’UC ou de machines virtuelles optimisées en mémoire, ou de la possibilité de mettre à l’échelle à zéro. Évitez un grand nombre de pools de nœuds pour réduire la surcharge de gestion supplémentaire. |
| Architecture de cluster : utilisez une passerelle NAT pour les clusters qui exécutent des charges de travail qui effectuent de nombreuses connexions sortantes simultanées. | Pour éviter les problèmes de fiabilité liés aux limitations d’Azure Load Balancer avec un trafic sortant simultané élevé, nous avons plutôt une passerelle NAT pour prendre en charge le trafic de sortie fiable à grande échelle. |
Pour plus de suggestions, consultez Principes du pilier de fiabilité.
Azure Policy
Azure Kubernetes Service offre un large éventail de stratégies Azure intégrées qui s’appliquent à la fois à la ressource Azure comme les stratégies Azure classiques et, à l’aide du module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. Il existe de nombreuses politiques clés liées à ce pilier qui sont résumées ici. Pour une vue plus détaillée, consultez les définitions de stratégie intégrées pour Kubernetes.
Architecture de cluster et de charge de travail
- Les clusters ont la préparation ou les sondes d’intégrité liveness configurées pour votre spécification de pod.
Outre les définitions Azure Policy intégrées, des stratégies personnalisées peuvent être créées pour la ressource AKS et pour le module complémentaire Azure Policy pour Kubernetes. Cela vous permet d’ajouter des contraintes de fiabilité supplémentaires que vous souhaitez appliquer dans votre architecture de cluster et de charge de travail.
Sécurité
La sécurité est l’un des aspects les plus importants de toute architecture. Pour découvrir comment AKS peut renforcer la sécurité de votre charge de travail d’application, nous vous recommandons de passer en revue les principes de conception de sécurité. Si votre cluster Azure Kubernetes Service doit être conçu pour exécuter une charge de travail sensible qui répond aux exigences réglementaires de la norme PCI-DSS 3.2.1 (Payment Card Industry Data Security Standard), passez en revue le cluster réglementé AKS pour PCI-DSS 3.2.1.
Pour en savoir plus sur la prise en charge et les exigences doD Impact Level 5 (IL5) avec AKS, passez en revue les exigences d’isolation d’Azure Government IL5.
Lorsque vous discutez de la sécurité avec Azure Kubernetes Service, il est important de faire la distinction entre la sécurité du cluster et la sécurité des charges de travail. La sécurité du cluster est une responsabilité partagée entre l’administrateur du cluster et son fournisseur de ressources, tandis que la sécurité de la charge de travail est le domaine d’un développeur. Azure Kubernetes Service a des considérations et des recommandations pour ces deux rôles.
Dans la liste de contrôle de conception et la liste des recommandations ci-dessous, les appels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.
Check-list pour la conception
- Architecture du cluster : utilisez des identités managées pour éviter la gestion et la rotation des principes de service.
- Architecture du cluster : utilisez le contrôle d’accès en fonction du rôle Kubernetes (RBAC) avec l’ID Microsoft Entra pour l’accès au moins privilégié et réduisez l’octroi de privilèges d’administrateur pour protéger la configuration et l’accès aux secrets.
- Architecture de cluster : utilisez Microsoft Defender pour conteneurs avec Azure Sentinel pour détecter et répondre rapidement aux menaces sur votre cluster et vos charges de travail s’exécutant sur eux.
- Architecture du cluster : déployez un cluster AKS privé pour garantir que le trafic de gestion de cluster vers votre serveur d’API reste sur votre réseau privé. Vous pouvez également utiliser la liste verte du serveur d’API pour les clusters non privés.
- Architecture de la charge de travail : utilisez un pare-feu d’applications web pour sécuriser le trafic HTTP(S).
- Architecture de la charge de travail : vérifiez que votre pipeline CI/CID est renforcé avec l’analyse prenant en charge les conteneurs.
Recommandations
Explorez le tableau de recommandations suivant pour optimiser votre configuration AKS pour la sécurité.
| Recommandation | Avantage |
|---|---|
| Architecture de cluster : Utiliser l’intégration de Microsoft Entra. | L’utilisation de Microsoft Entra ID permet de centraliser le composant de gestion des identités. Tout changement au niveau du compte d’utilisateur ou de l’état du groupe est automatiquement mis à jour dans l’accès au cluster AKS. Les développeurs et propriétaires d’applications de votre cluster Kubernetes doivent pouvoir accéder à différentes ressources. |
| Architecture du cluster : s’authentifier avec l’ID Microsoft Entra auprès d’Azure Container Registry. | AKS et Microsoft Entra ID active l’authentification avec Azure Container Registry sans utiliser de imagePullSecrets secrets. Pour plus d’informations, consultez l’authentification auprès d’Azure Container Registry à partir d’Azure Kubernetes Service . |
| Architecture du cluster : Sécurisez le trafic réseau vers votre serveur d’API avec un cluster AKS privé. | Par défaut, le trafic réseau entre vos pools de nœuds et le serveur d’API voyage le réseau principal Microsoft ; en utilisant un cluster privé, vous pouvez garantir que le trafic réseau vers votre serveur d’API reste sur le réseau privé uniquement. |
| Architecture du cluster : pour les clusters AKS non privés, utilisez des plages d’adresses IP autorisées par le serveur d’API. | Lorsque vous utilisez des clusters publics, vous pouvez toujours limiter le trafic pouvant atteindre votre serveur d’API clusters à l’aide de la fonctionnalité de plage d’adresses IP autorisée. Incluez des sources telles que les adresses IP publiques de vos agents de build de déploiement, la gestion des opérations et le point de sortie des pools de nœuds (par exemple, Pare-feu Azure). |
| Architecture du cluster : Protégez le serveur d’API avec Microsoft Entra RBAC. | La sécurisation de l’accès au serveur d’API Kubernetes est l’une des choses les plus importantes à faire pour protéger votre cluster. Intégrez le contrôle d’accès en fonction du rôle Kubernetes (RBAC) à l’ID Microsoft Entra pour contrôler l’accès au serveur d’API. Désactivez les comptes locaux pour appliquer l’accès à tous les clusters à l’aide des identités basées sur l’ID Microsoft Entra. |
| Architecture de cluster : utilisez des stratégies réseau Azure ou Calico. | Sécuriser et contrôler le trafic réseau entre les pods d’un cluster. |
| Architecture de cluster : Sécuriser des clusters et des pods avec Azure Policy. | Azure Policy peut aider à appliquer à grande échelle l’application et les protections sur vos clusters de manière centralisée et cohérente. Il est également possible de contrôler quelles fonctions sont accordées aux pods et si quelque chose va à l’encontre de la politique de l’entreprise. |
| Architecture du cluster : Sécuriser l’accès des conteneurs aux ressources. | Limitez l’accès aux actions que les conteneurs peuvent effectuer. Fournissez le plus petit nombre d’autorisations et évitez d’utiliser l’élévation des privilèges or de racine. |
| Architecture de la charge de travail : utilisez un pare-feu d’applications web pour sécuriser le trafic HTTP(S). | Pour analyser le trafic entrant pour détecter des attaques potentielles, utilisez un pare-feu d’applications web tel qu’Azure Web Application Firewall (WAF) sur Azure Application Gateway ou Azure Front Door. |
| Architecture du cluster : contrôler le trafic de sortie du cluster. | Vérifiez que le trafic sortant de votre cluster passe par un point de sécurité réseau tel que Pare-feu Azure ou un proxy HTTP. |
| Architecture du cluster : utilisez le pilote CSI du magasin de secrets et ID de charge de travail Microsoft Entra open source avec Azure Key Vault. | Protégez et faites pivoter des secrets, des certificats et des chaîne de connexion dans Azure Key Vault avec un chiffrement fort. Fournit un journal d’audit d’accès et conserve les secrets principaux hors du pipeline de déploiement. |
| Architecture de cluster : utilisez Microsoft Defender pour conteneurs. | Surveillez et gérez la sécurité de vos clusters, conteneurs et leurs applications. |
Pour plus de suggestions, consultez Principes du pilier de sécurité.
Azure Advisor permet de garantir et d’améliorer le service Azure Kubernetes. Il fournit des recommandations sur un sous-ensemble des éléments répertoriés dans la section de stratégie ci-dessous, telles que les clusters sans RBAC configurés, la configuration Microsoft Defender manquante, l’accès réseau illimité au serveur d’API. De même, il émet des recommandations de charge de travail pour certains éléments de l’initiative de sécurité des pods. Passez en revue les recommandations.
Définitions de stratégies
Azure Policy propose différentes définitions de stratégie intégrées qui s’appliquent à la fois à la ressource Azure et à AKS, comme les définitions de stratégie standard, et à l’aide du module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. La plupart des stratégies de ressources Azure sont disponibles dans audit/refus, mais également dans une variante Déployer s’il n’existe pas.
Il existe de nombreuses politiques clés liées à ce pilier qui sont résumées ici. Pour une vue plus détaillée, consultez les définitions de stratégie intégrées pour Kubernetes.
Architecture du cluster
- stratégies basées sur Microsoft Defender pour le cloud
- Mode d’authentification et stratégies de configuration (ID Microsoft Entra, RBAC, désactivation de l’authentification locale)
- Stratégies d’accès réseau du serveur d’API, y compris le cluster privé
Architecture de cluster et de charge de travail
- Initiatives de sécurité des pods de cluster Kubernetes basées sur Linux
- Inclure des stratégies de capacité de pod et de conteneur telles que AppArmor, sysctl, caps de sécurité, SELinux, seccomp, conteneurs privilégiés, informations d’identification de l’API de cluster de montage automatique
- Montage, pilotes de volume et stratégies de système de fichiers
- Stratégies de mise en réseau de pod/conteneur, telles que le réseau hôte, le port, les adresses IP externes autorisées, les HTTPs et les équilibreurs de charge internes
Les déploiements Azure Kubernetes Service utilisent souvent Azure Container Registry pour les graphiques Helm et les images conteneur. Azure Container Registry prend également en charge un large éventail de stratégies Azure qui couvrent les restrictions réseau, le contrôle d’accès et les Microsoft Defender pour le cloud, qui complètent une architecture AKS sécurisée.
Outre les stratégies intégrées, des stratégies personnalisées peuvent être créées pour la ressource AKS et pour le module complémentaire Azure Policy pour Kubernetes. Cela vous permet d’ajouter des contraintes de sécurité supplémentaires que vous souhaitez appliquer dans votre architecture de cluster et de charge de travail.
Pour plus de suggestions, consultez les concepts de sécurité AKS et évaluez nos recommandations de renforcement de la sécurité en fonction du benchmark CIS Kubernetes.
Optimisation des coûts
L’optimisation des coûts consiste à comprendre vos différentes options de configuration et les bonnes pratiques recommandées pour réduire les dépenses inutiles et améliorer l’efficacité opérationnelle. Avant de suivre les instructions de cet article, nous vous recommandons de consulter les ressources suivantes :
- Principes de conception de l’optimisation des coûts.
- Fonctionnement de la gestion des prix et des coûts dans Azure Kubernetes Service (AKS) par rapport à Amazon Elastic Kubernetes Service (Amazon EKS).
- Si vous exécutez AKS localement ou en périphérie, Azure Hybrid Benefit peut également être utilisé pour réduire davantage les coûts lors de l’exécution d’applications conteneurisées dans ces scénarios.
Lorsqu’il est question d’optimisation des coûts avec Azure Kubernetes Service, il est important de faire la distinction entre le coût des ressources de cluster et le coût des ressources de charge de travail. Les ressources de cluster sont une responsabilité partagée entre l’administrateur de cluster et son fournisseur de ressources, tandis que les ressources de charge de travail sont le domaine d’un développeur. Azure Kubernetes Service a des considérations et des recommandations pour ces deux rôles.
Dans la liste de contrôle de conception et la liste des recommandations, les appels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.
Pour optimiser les coûts du cluster, accédez à la calculatrice de prix Azure et sélectionnez Azure Kubernetes Service dans les produits disponibles. Vous pouvez tester différentes configurations et plans de paiement dans la calculatrice.
Check-list pour la conception
- Architecture de cluster : Utilisez la référence SKU de machine virtuelle appropriée par pool de nœuds et les instances réservées où une capacité à long terme est prévue.
- Architectures de cluster et de charge de travail : Utilisez le niveau et la taille de disque managé appropriés.
- Architecture de cluster : Passez en revue les métriques de performances, en commençant par le processeur, la mémoire, le stockage et le réseau, pour identifier les opportunités d’optimisation des coûts par cluster, nœud et espace de noms.
- Architecture du cluster et de la charge de travail : utilisez des autoscalers pour effectuer une mise à l’échelle lorsque les charges de travail sont moins actives.
Recommandations
Explorez le tableau de recommandations suivant afin d’optimiser votre configuration AKS en termes de coût.
| Recommandation | Avantage |
|---|---|
| Architectures de cluster et de charge de travail : aligner la sélection de référence SKU et la taille du disque managé avec les exigences en matière de charge de travail. | La mise en correspondance de votre sélection à vos demandes de charge de travail garantit que vous ne payez pas pour les ressources inutiles. |
| Architecture du cluster : sélectionnez le type d’instance de machine virtuelle approprié. | La sélection du type d’instance de machine virtuelle appropriée est essentielle, car elle affecte directement le coût d’exécution d’applications sur AKS. Le choix d’une instance hautes performances sans utilisation appropriée peut entraîner un gaspillage de dépenses, tandis que le choix d’une instance moins puissante peut entraîner des problèmes de performances et un temps d’arrêt accru. Pour déterminer le type d’instance de machine virtuelle approprié, tenez compte des caractéristiques de la charge de travail, des besoins en ressources et des besoins de disponibilité. |
| Architecture de cluster : sélectionnez des machines virtuelles basées sur l’architecture Arm. | AKS prend en charge la création de nœuds d’agent Ubuntu Arm64, ainsi qu’une combinaison de nœuds d’architecture Intel et ARM au sein d’un cluster qui peuvent améliorer les performances à moindre coût. |
| Architecture de cluster : sélectionnez Azure Spot Machines Virtuelles. | Les machines virtuelles spot vous permettent de tirer parti de la capacité Azure non utilisée avec des remises significatives (jusqu’à 90 % d’économies par rapport aux tarifs du paiement à l’utilisation). Si Azure a besoin de récupérer de la capacité, l’infrastructure Azure exclut les nœuds spot. |
| Architecture du cluster : sélectionnez la région appropriée. | En raison de nombreux facteurs, le coût des ressources varie selon la région dans Azure. Évaluez les exigences de coût, de latence et de conformité pour vous assurer que vous exécutez votre charge de travail de manière rentable et qu’elle n’affecte pas vos utilisateurs finaux ou créez des frais de mise en réseau supplémentaires. |
| Architecture de la charge de travail : conservez des images petites et optimisées. | La rationalisation de vos images permet de réduire les coûts, car les nouveaux nœuds doivent télécharger ces images. Générez des images d’une manière qui permet au conteneur de démarrer dès que possible afin d’éviter les échecs ou délais d’attente des demandes utilisateur pendant le démarrage de l’application, ce qui peut entraîner le surprovisionnement. |
| Architecture du cluster : activez la mise à l’échelle automatique du cluster pour réduire automatiquement le nombre de nœuds d’agent en réponse à une capacité de ressource excédentaire. | Le scale-down automatique du nombre de nœuds dans votre cluster AKS vous permet d’exécuter un cluster efficace lorsque la demande est faible et de monter en puissance lorsque la demande est retournée. |
| Architecture du cluster : activez l’autoprovision de nœud pour automatiser la sélection de la référence SKU de machine virtuelle. | Node Autoprovision simplifie le processus de sélection de référence SKU et décide, en fonction des besoins en ressources de pod en attente, de la configuration optimale de la machine virtuelle pour exécuter les charges de travail de manière la plus efficace et économique. |
| Architecture de la charge de travail : utilisez l’autoscaler de pod horizontal. | Ajustez le nombre de pods dans un déploiement en fonction de l’utilisation du processeur ou d’autres métriques sélectionnées, qui prennent en charge les opérations de mise à l’échelle du cluster. |
| Architecture de la charge de travail : Utiliser la mise à l’échelle automatique des pods verticaux (préversion). | Rightsize your pods and dynamiquement set requests and limits based on historic usage. |
| Architecture de la charge de travail : utiliser la mise à l’échelle automatique basée sur les événements Kubernetes (KEDA). | Mettre à l’échelle en fonction du nombre d’événements en cours de traitement. Choisissez parmi un catalogue riche de 50 scalers KEDA. |
| Architectures de cluster et de charge de travail : adoptez une discipline financière cloud et une pratique culturelle pour favoriser la propriété de l’utilisation du cloud. | La base de l’activation de l’optimisation des coûts est la répartition d’un cluster d’économies. Une approche des opérations financières (FinOps) est souvent utilisée pour aider les organisations à réduire les coûts du cloud. Il s’agit d’une pratique impliquant la collaboration entre les équipes financières, opérationnelles et d’ingénierie afin de favoriser l’alignement sur les objectifs d’économie de coûts et d’apporter de la transparence aux coûts cloud. |
| Architecture du cluster : inscrivez-vous à des réservations Azure ou à un plan d’épargne Azure. | Si vous prévoyez correctement la capacité, votre charge de travail est prévisible et existe pendant une période prolongée, inscrivez-vous à une réservation Azure ou à un plan d’économies pour réduire davantage vos coûts de ressources. |
| Architecture de cluster : passez en revue les meilleures pratiques pour surveiller Kubernetes avec Azure Monitor afin de déterminer la meilleure stratégie de supervision pour vos charges de travail. | S/O |
| Architecture du cluster : configurez le module complémentaire ANALYSE des coûts AKS. | L’extension de cluster d’analyse des coûts vous permet d’obtenir des informations précises sur les coûts associés à diverses ressources Kubernetes dans vos clusters ou espaces de noms. |
Pour plus de suggestions, consultez Principes du pilier d’optimisation des coûts et Optimiser les coûts dans Azure Kubernetes Service.
Définitions de stratégies
Bien qu’il n’existe aucune stratégie intégrée liée à l’optimisation des coûts, des stratégies personnalisées peuvent être créées pour la ressource AKS et pour le module complémentaire Azure Policy pour Kubernetes. Cela vous permet d’ajouter des contraintes d’optimisation des coûts supplémentaires que vous souhaitez appliquer dans votre architecture de cluster et de charge de travail.
Efficacité du cloud
Rendre les charges de travail plus durables et plus efficaces dans le cloud nécessite de combiner des efforts autour de l’optimisation des coûts, de réduire les émissions de carbone et d’optimiser la consommation d’énergie. L’optimisation du coût de l’application est l’étape initiale pour rendre les charges de travail plus durables.
Découvrez comment créer des charges de travail AKS durables et efficaces, dans des principes d’ingénierie logicielle durable dans Azure Kubernetes Service (AKS).
Excellence opérationnelle
La surveillance et les diagnostics sont cruciaux. Vous pouvez non seulement mesurer les statistiques de performances, mais également utiliser des métriques pour résoudre et corriger rapidement les problèmes. Nous vous recommandons de consulter les principes de conception de l’excellence opérationnelle et le guide des opérations day-2.
Lorsque vous discutez de l’excellence opérationnelle avec Azure Kubernetes Service, il est important de faire la distinction entre l’excellence opérationnelle du cluster et l’excellence opérationnelle de la charge de travail. Les opérations de cluster sont une responsabilité partagée entre l’administrateur du cluster et son fournisseur de ressources, tandis que les opérations de charge de travail sont le domaine d’un développeur. Azure Kubernetes Service a des considérations et des recommandations pour ces deux rôles.
Dans la liste de contrôle de conception et la liste des recommandations ci-dessous, les appels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.
Check-list pour la conception
- Architecture de cluster : utilisez un déploiement basé sur des modèles à l’aide de Bicep, Terraform ou d’autres. Assurez-vous que tous les déploiements sont reproductibles, traceables et stockés dans un référentiel de code source.
- Architecture du cluster : créez un processus automatisé pour vous assurer que vos clusters sont démarrés avec les configurations et déploiements à l’échelle du cluster nécessaires. Cette opération est souvent effectuée à l’aide de GitOps.
- Architecture de la charge de travail : utilisez des processus de déploiement reproductibles et automatisés pour votre charge de travail au sein de votre cycle de vie de développement logiciel.
- Architecture du cluster : activez les paramètres de diagnostic pour vous assurer que les interactions du plan de contrôle ou du serveur d’API principal sont journalisées.
- Architectures de cluster et de charge de travail : passez en revue les meilleures pratiques pour surveiller Kubernetes avec Azure Monitor afin de déterminer la meilleure stratégie de surveillance pour vos charges de travail.
- Architecture de la charge de travail : la charge de travail doit être conçue pour émettre des données de télémétrie pouvant être collectées, qui doivent également inclure des lignes dynamiques et des états de préparation.
- Architectures de cluster et de charge de travail : utilisez des pratiques d’ingénierie chaos qui ciblent Kubernetes pour identifier les problèmes de fiabilité de l’application ou de la plateforme.
- Architecture de la charge de travail : optimisez votre charge de travail pour fonctionner et déployer efficacement dans un conteneur.
- Architectures de cluster et de charge de travail : appliquez la gouvernance des clusters et des charges de travail à l’aide d’Azure Policy.
Recommandations
Explorez le tableau de recommandations suivant pour optimiser votre configuration AKS pour les opérations.
| Recommandation | Avantage |
|---|---|
| Architectures de cluster et de charge de travail : consultez la documentation relative aux bonnes pratiques AKS. | Pour générer et exécuter des applications avec succès dans AKS, il existe des considérations clés à prendre en compte pour comprendre et implémenter. Ces éléments portent sur les fonctionnalités de mutualisation et de planification, la sécurité du cluster et du pod, ou la continuité d'activité et reprise d’activité. |
| Architectures de cluster et de charge de travail : passez en revue Azure Chaos Studio. | Azure Chaos Studio peut aider à simuler des erreurs et à déclencher des situations de récupération d’urgence. |
| Architectures de cluster et de charge de travail : passez en revue les meilleures pratiques pour surveiller Kubernetes avec Azure Monitor afin de déterminer la meilleure stratégie de surveillance pour vos charges de travail. | S/O |
| Architecture de cluster : adoptez une stratégie multirégion en déployant des clusters AKS déployés dans différentes régions Azure pour optimiser la disponibilité et assurer la continuité de l’activité. | Les charges de travail accessibles sur Internet doivent tirer parti d’Azure Front Door ou d’Azure Traffic Manager pour acheminer le trafic globalement entre les clusters AKS. |
| Architecture de cluster : opérationnaliser les clusters et les normes de configuration des pods avec Azure Policy. | Azure Policy peut aider à appliquer à grande échelle l’application et les protections sur vos clusters de manière centralisée et cohérente. Il est également possible de contrôler quelles fonctions sont accordées aux pods et si quelque chose va à l’encontre de la politique de l’entreprise. |
| Architecture de la charge de travail : utilisez des fonctionnalités de plateforme dans votre processus d’ingénierie de mise en production. | Kubernetes et contrôleurs d’entrée prennent en charge de nombreux modèles de déploiement avancés pour l’inclusion dans votre processus d’ingénierie de mise en production. Envisagez des modèles tels que les déploiements bleu-vert ou les versions de canari. |
| Architectures de cluster et de charge de travail : pour les charges de travail critiques, utilisez des déploiements bleu/vert au niveau du tampon. | Automatisez vos domaines de conception stratégiques, y compris le déploiement et les tests. |
Pour plus de suggestions, consultez Principes du pilier de l’excellence opérationnelle.
Azure Advisor émet également des recommandations sur un sous-ensemble des éléments répertoriés dans la section de stratégie ci-dessous, telles que les versions AKS non prises en charge et les paramètres de diagnostic non configurés. De même, il émet des recommandations de charge de travail autour de l’utilisation de l’espace de noms par défaut.
Définitions de stratégies
Azure Policy propose différentes définitions de stratégie intégrées qui s’appliquent à la fois à la ressource Azure et à AKS, comme les définitions de stratégie standard, et à l’aide du module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. La plupart des stratégies de ressources Azure sont disponibles dans audit/refus, mais également dans une variante Déployer s’il n’existe pas.
Il existe de nombreuses politiques clés liées à ce pilier qui sont résumées ici. Pour une vue plus détaillée, consultez les définitions de stratégie intégrées pour Kubernetes.
Architecture du cluster
- Module complémentaire Azure Policy pour Kubernetes
- Stratégies de configuration GitOps
- Stratégies de paramètres de diagnostic
- Restrictions de version AKS
- Empêcher l’appel de commande
Architecture de cluster et de charge de travail
- Restrictions de déploiement d’espaces de noms
Outre les stratégies intégrées, des stratégies personnalisées peuvent être créées pour la ressource AKS et pour le module complémentaire Azure Policy pour Kubernetes. Cela vous permet d’ajouter des contraintes de sécurité supplémentaires que vous souhaitez appliquer dans votre architecture de cluster et de charge de travail.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Nous vous recommandons de passer en revue les principes d’efficacité des performances.
Lorsque vous discutez des performances avec Azure Kubernetes Service, il est important de faire la distinction entre les performances du cluster et les performances de la charge de travail. Les performances du cluster sont une responsabilité partagée entre l’administrateur du cluster et son fournisseur de ressources, tandis que les performances de la charge de travail sont le domaine d’un développeur. Azure Kubernetes Service a des considérations et des recommandations pour ces deux rôles.
Dans la liste de contrôle de conception et la liste des recommandations ci-dessous, les appels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.
Check-list pour la conception
Lorsque vous effectuez des choix de conception pour Azure Kubernetes Service, passez en revue les principes d’efficacité des performances.
- Architectures de cluster et de charge de travail : effectuez et itérer sur un exercice détaillé de plan de capacité qui inclut la référence SKU, les paramètres de mise à l’échelle automatique, l’adressage IP et les considérations relatives au basculement.
- Architecture du cluster : activez la mise à l’échelle automatique du cluster pour ajuster automatiquement le nombre de nœuds d’agent dans les demandes de charge de travail de réponse.
- Architecture du cluster : utilisez le générateur de mise à l’échelle automatique de pod horizontal pour ajuster le nombre de pods dans un déploiement en fonction de l’utilisation du processeur ou d’autres métriques sélectionnées.
- Architectures de cluster et de charge de travail : effectuez des activités de test de charge en cours qui exercicent à la fois le pod et l’autoscaler de cluster.
- Architectures de cluster et de charge de travail : séparez les charges de travail dans différents pools de nœuds, ce qui permet un appel indépendant.
Recommandations
Explorez le tableau de recommandations suivant pour optimiser votre configuration d’Azure Kubernetes Service pour les performances.
| Recommandation | Avantage |
|---|---|
| Architectures de cluster et de charge de travail : développez un plan de capacité détaillé et passez en revue et révisez continuellement. | Après avoir formalisé votre plan de capacité, il doit être fréquemment mis à jour en observant en continu l’utilisation des ressources du cluster. |
| Architecture du cluster : activez la mise à l’échelle automatique du cluster pour ajuster automatiquement le nombre de nœuds d’agent en réponse aux contraintes de ressources. | Cette possibilité d’augmenter ou de réduire automatiquement le nombre de nœuds dans votre cluster AKS vous permet d’exécuter un cluster efficace et économique. |
| Architectures de cluster et de charge de travail : séparez les charges de travail en différents pools de nœuds et envisagez de mettre à l’échelle les pools de nœuds utilisateur. | Contrairement aux pools de nœuds système qui nécessitent toujours des nœuds en cours d’exécution, les pools de nœuds utilisateur vous permettent d’effectuer un scale-up ou un scale-down. |
| Architecture de la charge de travail : utilisez les fonctionnalités avancées du planificateur AKS. | Permet de contrôler l’équilibrage des ressources pour les charges de travail qui en ont besoin. |
| Architecture de la charge de travail : utilisez des métriques de mise à l’échelle de charge de travail significatives. | Toutes les décisions de mise à l’échelle ne peuvent pas être dérivées des métriques processeur ou mémoire. Souvent, les considérations relatives à l’échelle proviennent de points de données plus complexes ou même externes. Utilisez KEDA pour créer un ensemble de règles de mise à l’échelle automatique significatif en fonction des signaux spécifiques à votre charge de travail. |
Pour plus de suggestions, consultez Principes du pilier efficacité des performances.
Définitions de stratégies
Azure Policy propose différentes définitions de stratégie intégrées qui s’appliquent à la fois à la ressource Azure et à AKS, comme les définitions de stratégie standard, et à l’aide du module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. La plupart des stratégies de ressources Azure sont disponibles dans audit/refus, mais également dans une variante Déployer s’il n’existe pas.
Il existe de nombreuses politiques clés liées à ce pilier qui sont résumées ici. Pour une vue plus détaillée, consultez les définitions de stratégie intégrées pour Kubernetes.
Architecture de cluster et de charge de travail
- Limites des ressources processeur et mémoire
Outre les stratégies intégrées, des stratégies personnalisées peuvent être créées pour la ressource AKS et pour le module complémentaire Azure Policy pour Kubernetes. Cela vous permet d’ajouter des contraintes de sécurité supplémentaires que vous souhaitez appliquer dans votre architecture de cluster et de charge de travail.
Ressources supplémentaires
Conseils du Centre d’architecture Azure
- Architecture de la base de référence AKS
- Architecture de microservices avancée sur AKS
- Cluster AKS pour une charge de travail PCI-DSS
- Base de référence AKS pour les clusters multirégions