Revue d’Azure Well-Architected Framework - Azure Kubernetes Service (AKS)

  • Article

Cet article fournit les 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 avez une connaissance pratique de 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 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’un cluster Azure Kubernetes Service (AKS) et d’une architecture de microservices 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 les abonnements de zone d’atterrissage pour un cluster Azure Kubernetes Service scalable (AKS).

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 de 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 de recommandations ci-dessous, des rappels 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 : 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 être mis à l’échelle de manière fiable, y compris la gestion du trafic de basculement dans les topologies à plusieurs clusters.
  • Architecture du cluster : Activez Container Insights pour surveiller votre cluster et configurer des alertes pour les événements ayant un impact sur la fiabilité.
  • Architecture de charge de travail : Vérifiez que les charges de travail sont conçues pour prendre en charge la mise à l’échelle horizontale et signaler la préparation et l’intégrité des applications.
  • 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 que vous avez choisi 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 du cluster : Utilisez le contrat SLA de durée de fonctionnement AKS pour atteindre les objectifs de disponibilité pour les 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ôlez la planification des pods à l’aide de sélecteurs de nœud et de l’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 : Assurez-vous que le plug-in réseau est correctement sélectionné 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. Pour plus d’informations, consultez Kubenet et Azure CNI .
Architectures de cluster et de charge de travail : Utilisez le contrat SLA de durée de fonctionnement AKS pour les clusters de niveau production. Le contrat SLA AKS Uptime garantit :
- 99.95% une disponibilité du point de terminaison de serveur de l’API Kubernetes pour les clusters AKS qui utilisent des zones de disponibilité Azure, 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 : Configurez la surveillance du cluster avec Container Insights. Container Insights permet de surveiller l’intégrité et les performances des contrôleurs, des nœuds et des conteneurs disponibles dans Kubernetes via l’API Metrics. L’intégration à Prometheus permet la collecte de métriques d’application et de charge de travail.
Architecture du cluster : Utilisez des zones de disponibilité pour optimiser la résilience au sein d’une région Azure en distribuant les nœuds de l’agent AKS entre des centres de données physiquement distincts. En répartissant des pools de nœuds sur plusieurs zones, les nœuds d’un pool de nœuds continuent de s’exécuter même si une autre zone a été en panne. Si des exigences de colocalité existent, un déploiement AKS basé sur VMSS standard dans une seule zone ou des groupes de placement de proximité peut être utilisé pour réduire la latence entre nœuds.
Architecture du 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 à l’échelle mondiale entre les clusters AKS.
Architectures de cluster et de charge de travail : Définissez des demandes et des limites de ressources pod dans les manifestes de déploiement d’application, et appliquez-les avec Azure Policy. Les limites de ressources de processeur et de mémoire du conteneur sont nécessaires pour éviter l’épuisement des ressources dans votre cluster Kubernetes.
Architectures de cluster et de charge de travail : Gardez 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 vers des 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, de machines virtuelles optimisées pour le processeur ou la mémoire, ou de la possibilité de mettre à l’échelle jusqu’à zéro. Évitez un grand nombre de pools de nœuds pour réduire la surcharge de gestion.
Architecture du cluster : Utilisez une passerelle NAT pour les clusters qui exécutent des charges de travail qui créent de nombreuses connexions sortantes simultanées. Pour éviter les problèmes de fiabilité liés aux limitations de 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 obtenir d’autres suggestions, consultez Principes du pilier de fiabilité.

Azure Policy

Azure Kubernetes Service offre une grande variété de stratégies Azure intégrées qui s’appliquent à 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 un grand nombre de stratégies, et les stratégies clés liées à ce pilier sont résumées ici. Pour obtenir une vue plus détaillée, consultez Définitions de stratégie intégrées pour Kubernetes.

Architecture du cluster et de la charge de travail

  • Les clusters ont des sondes d’intégrité de préparation ou de disponibilité configurées pour vos spécifications de pod.

Outre les définitions de 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 d’une 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 la 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), consultez Cluster réglementé AKS pour PCI-DSS 3.2.1.

Pour en savoir plus sur la prise en charge et les exigences du DoD Impact Level 5 (IL5) avec AKS, passez en revue Azure Government exigences d’isolation 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é de la charge de travail. La sécurité du cluster est une responsabilité partagée entre l’administrateur de 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 de recommandations ci-dessous, des rappels 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 (RBAC) Kubernetes avec Microsoft Entra ID pour l’accès aux privilèges minimum et réduisez l’octroi de privilèges d’administrateur pour protéger la configuration et l’accès aux secrets.
  • Architecture du cluster : Utilisez Microsoft Defender pour les conteneurs avec Azure Sentinel pour détecter et répondre rapidement aux menaces sur votre cluster et les charges de travail qui s’exécutent sur ceux-ci.
  • 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 charge de travail : Utilisez un Web Application Firewall pour sécuriser le trafic HTTP(S).
  • Architecture de 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 du cluster : Utilisez l’intégration Microsoft Entra. L’utilisation de Microsoft Entra ID centralise 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 de cluster : Authentifiez-vous avec Microsoft Entra ID pour Azure Container Registry. AKS et Microsoft Entra ID activent l’authentification avec Azure Container Registry sans utiliser de imagePullSecrets secrets. Pour plus d’informations, consultez Authentifier avec Azure Container Registry à partir de Azure Kubernetes Service.
Architecture de 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 transite par le réseau principal Microsoft ; En utilisant un cluster privé, vous pouvez vous assurer que le trafic réseau vers votre serveur d’API reste sur le réseau privé uniquement.
Architecture de 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 qui peut atteindre le serveur d’API de vos clusters à l’aide de la fonctionnalité de plage d’adresses IP autorisées. 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 (comme Pare-feu Azure).
Architecture de 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 (RBAC) Kubernetes à Microsoft Entra ID pour contrôler l’accès au serveur d’API. Désactivez les comptes locaux pour appliquer tous les accès au cluster à l’aide d’identités basées sur Microsoft Entra ID.
Architecture de cluster : Utilisez des stratégies réseau Azure ou Calico. Sécurisez et contrôlez le trafic réseau entre les pods d’un cluster.
Architecture de cluster : Sécurisez les clusters et les pods avec Azure Policy. Azure Policy pouvez vous aider à appliquer des mesures de mise en œuvre et des protections à grande échelle 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 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 charge de travail : Utilisez un Web Application Firewall pour sécuriser le trafic HTTP(S). Pour analyser le trafic entrant à la recherche d’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 de 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 de cluster : Utilisez le pilote CSI open source ID de charge de travail Microsoft Entra et secrets Store avec Azure Key Vault. Protégez et faites pivoter les secrets, les certificats et les chaînes 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 les conteneurs. Surveillez et maintenez 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 fait des recommandations sur un sous-ensemble des éléments répertoriés dans la section de stratégie ci-dessous, tels que les clusters sans RBAC configurés, la configuration Microsoft Defender manquante, l’accès réseau sans restriction au serveur d’API. De même, il fait des recommandations de charge de travail pour certains des éléments d’initiative de sécurité des pods. Passez en revue les recommandations.

Définitions de stratégies

Azure Policy propose diverses 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 qui utilisent le module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. La plupart des stratégies de ressources Azure sont disponibles à la fois dans audit/refus, mais également dans une variante Déployer si pas existe .

Il existe un grand nombre de stratégies, et les stratégies clés liées à ce pilier sont résumées ici. Pour obtenir une vue plus détaillée, consultez Définitions de stratégie intégrées pour Kubernetes.

Architecture de cluster

  • Microsoft Defender pour les stratégies basées sur le cloud
  • Mode d’authentification et stratégies de configuration (Microsoft Entra ID, RBAC, désactiver l’authentification locale)
  • Stratégies d’accès réseau au serveur API, y compris le cluster privé

Architecture du cluster et de la 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, les caps de sécurité, SELinux, seccomp, conteneurs privilégiés, les 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 des pods/conteneurs, telles que le réseau hôte, le port, les adresses IP externes autorisées, les HTTPs et les équilibreurs de charge internes

Azure Kubernetes Service déploiements utilisent souvent des 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, ce qui complète une architecture AKS sécurisée.

En plus des stratégies intégrées, des stratégies personnalisées peuvent être créées à la fois 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 Concepts de sécurité AKS et évaluez nos recommandations de renforcement de la sécurité en fonction du benchmark Kubernetes CIS.

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 conseils de cet article, nous vous recommandons de passer en revue les ressources suivantes :

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, des 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 parmi les produits disponibles. Vous pouvez tester différents plans de configuration et 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 : Alignez la sélection des références SKU et la taille du disque managé sur les exigences de charge de travail. Le fait de faire correspondre votre sélection à vos demandes de charge de travail garantit que vous ne payez pas pour les ressources inutiles.
Architecture de cluster : Sélectionnez le type de machine virtuelle approprié instance. Il est essentiel de sélectionner le type de machine virtuelle instance approprié, car il a un impact direct sur le coût d’exécution des applications sur AKS. Le choix d’un instance hautes performances sans utilisation appropriée peut entraîner un gaspillage de dépenses, tandis que le choix d’un instance puissant peut entraîner des problèmes de performances et des temps d’arrêt accrus. Pour déterminer le type de machine virtuelle approprié instance, tenez compte des caractéristiques de charge de travail, des besoins en ressources et des besoins en 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 apporter de meilleures 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 inutilisée avec des remises importantes (jusqu’à 90 % par rapport aux prix du paiement à l’utilisation). Si Azure a besoin de la capacité, l’infrastructure Azure supprime les nœuds Spot.
Architecture de 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 économique et qu’elle n’affecte pas vos utilisateurs finaux ou ne crée pas de frais réseau supplémentaires.
Architecture de 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. Créez des images d’une manière qui permet au conteneur de démarrer dès que possible afin d’éviter les échecs de requête utilisateur ou les délais d’expiration pendant le démarrage de l’application, ce qui peut entraîner un surprovisionnement.
Architecture de cluster : Activez cluster Autoscaler pour réduire automatiquement le nombre de nœuds d’agent en réponse à une capacité de ressources excédentaire. La réduction 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 revient.
Architecture de cluster : Activez l’approvisionnement automatique 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 des références 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 la manière la plus efficace et la plus économique.
Architecture de charge de travail : Utilisez le module de mise à l’échelle automatique 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 scale-in du cluster.
Architecture de charge de travail : Utilisez Vertical Pod Autoscaler (préversion). Rightsizez vos pods et définissez dynamiquement les requêtes et les limites en fonction de l’utilisation historique.
Architecture de charge de travail : Utilisez la mise à l’échelle automatique pilotée par les événements ( KEDA) Kubernetes. Mettre à l’échelle en fonction du nombre d’événements en cours de traitement. Choisissez parmi un catalogue riche de plus de 50 scalers KEDA.
Architectures de cluster et de charge de travail : Adoptez une discipline financière et une pratique culturelle cloud 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 économique. Une approche des opérations financières (FinOps) est souvent utilisée pour aider les organisations à réduire les coûts cloud. Il s’agit d’une pratique impliquant la collaboration entre les équipes de finance, d’exploitation et d’ingénierie pour favoriser l’alignement sur les objectifs de réduction des coûts et apporter de la transparence aux coûts cloud.
Architecture de cluster : Inscrivez-vous à Réservations Azure ou à Azure Savings Plan. Si vous avez correctement planifié 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 : Configurez la surveillance du cluster avec Container Insights. Container Insights vous aide à fournir des informations exploitables sur vos clusters ressources inactives et non allouées. Container Insights prend également en charge la collecte de métriques Prometheus et s’intègre à Azure Managed Grafana pour obtenir une vue holistique de votre application et de votre infrastructure.
Architecture de 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 aux différentes 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 à la fois 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

Pour rendre les charges de travail plus durables et plus efficaces dans le cloud, il faut combiner des efforts autour de l’optimisation des coûts, de la réduction des émissions de carbone et de l’optimisation de la consommation d’énergie. L’optimisation du coût de l’application est la première étape pour rendre les charges de travail plus durables.

Découvrez comment créer des charges de travail AKS durables et efficaces, dans 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 les problèmes et les résoudre rapidement. Nous vous recommandons de passer en revue les principes de conception de l’excellence opérationnelle et le guide des opérations du jour 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 des clusters et l’excellence opérationnelle de charge de travail. Les opérations de cluster sont une responsabilité partagée entre l’administrateur de 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, des 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 un modèle à l’aide de Bicep, Terraform ou d’autres. Assurez-vous que tous les déploiements sont reproductibles, traçables et stockés dans un référentiel de code source.
  • Architecture de 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 charge de travail : Utilisez des processus de déploiement reproductibles et automatisés pour votre charge de travail dans le cycle de vie de votre développement logiciel.
  • Architecture de cluster : Activez diagnostics paramètres pour vous assurer que les interactions du plan de contrôle ou du serveur d’API principaux sont enregistrées.
  • Architectures de cluster et de charge de travail : Activez Container Insights pour collecter des métriques, des journaux et des diagnostics pour surveiller la disponibilité et les performances du cluster et des charges de travail qui s’exécutent sur celui-ci.
  • Architecture de charge de travail : La charge de travail doit être conçue pour émettre des données de télémétrie qui peuvent être collectées, ce qui doit également inclure des états de disponibilité et de préparation.
  • Architectures de cluster et de charge de travail : Utilisez des pratiques d’ingénierie du chaos qui ciblent Kubernetes pour identifier les problèmes de fiabilité de l’application ou de la plateforme.
  • Architecture de 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 de 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 meilleures pratiques AKS . Pour créer et exécuter des applications avec succès dans AKS, il existe des considérations clés à 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 vous aider à simuler des erreurs et à déclencher des situations de récupération d’urgence.
Architectures de cluster et de charge de travail : Configurez la surveillance du cluster avec Container Insights. Container Insights permet de surveiller les performances des conteneurs en collectant des métriques de mémoire et de processeur à partir de contrôleurs, de nœuds et de conteneurs disponibles dans Kubernetes via l’API Metrics et les journaux de conteneur.
Architecture de charge de travail : Surveillez les performances des applications avec Azure Monitor. Configurez Application Insights pour la supervision basée sur le code des applications s’exécutant dans un cluster AKS.
Architecture de charge de travail : Configurez le raclage des métriques Prometheus avec Container Insights. Container Insights, qui font partie d’Azure Monitor, fournissent une expérience d’intégration transparente pour collecter les métriques Prometheus. Référence Configurer le raclage des métriques Prometheus pour plus d’informations.
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 à l’échelle mondiale sur des clusters AKS.
Architecture de cluster : Opérationnalisez les normes de configuration des clusters et des pods avec Azure Policy. Azure Policy pouvez vous aider à appliquer des mesures de mise en œuvre et des protections à grande échelle 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 charge de travail : Utilisez les fonctionnalités de plateforme dans votre processus d’ingénierie de mise en production. Kubernetes et les contrôleurs d’entrée prennent en charge de nombreux modèles de déploiement avancés à inclure dans votre processus d’ingénierie de mise en production. Tenez compte des modèles tels que les déploiements bleu-vert ou les versions de canaris.
Architectures de cluster et de charge de travail : Pour les charges de travail stratégiques, utilisez des déploiements bleu/vert au niveau de l’empreinte. Automatisez vos domaines de conception stratégiques, y compris le déploiement et le test.

Pour plus de suggestions, consultez Principes du pilier d’excellence opérationnelle.

Azure Advisor formule également des recommandations sur un sous-ensemble des éléments répertoriés dans la section stratégie ci-dessous, tels que les versions AKS non prises en charge et les paramètres de diagnostic non configurés. De même, il fait des recommandations de charge de travail concernant l’utilisation de l’espace de noms par défaut.

Définitions de stratégies

Azure Policy propose diverses 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 qui utilisent le module complémentaire Azure Policy pour Kubernetes, également au sein du cluster. La plupart des stratégies de ressources Azure sont disponibles à la fois dans audit/refus, mais également dans une variante Déployer si pas existe .

Il existe un grand nombre de stratégies, et les stratégies clés liées à ce pilier sont résumées ici. Pour obtenir une vue plus détaillée, consultez Définitions de stratégie intégrées pour Kubernetes.

Architecture de cluster

  • Azure Policy module complémentaire 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 du cluster et de la charge de travail

  • Restrictions de déploiement d’espaces de noms

En plus des stratégies intégrées, des stratégies personnalisées peuvent être créées à la fois 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 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 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, des 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 faites 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 effectuez une itération 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 de cluster : Activez la mise à l’échelle automatique de cluster pour ajuster automatiquement le nombre de nœuds d’agent dans les demandes de charge de travail en réponse.
  • Architecture de cluster : Utilisez la mise à l’échelle automatique du 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 continues qui exercent à la fois le pod et la mise à l’échelle automatique du cluster.
  • Architectures de cluster et de charge de travail : Séparez les charges de travail en différents pools de nœuds, ce qui permet un appel indépendant.

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration de Azure Kubernetes Service pour les performances.

Recommandation Avantage
Architectures de cluster et de charge de travail : Élaborez un plan de capacité détaillé et examinez et révisez continuellement. Après avoir formalisé votre plan de capacité, il doit être fréquemment mis à jour en observant en permanence l’utilisation des ressources du cluster.
Architecture du cluster : Activez l’autoscaler de 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 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 charge de travail : Utilisez des métriques de mise à l’échelle significatives de la charge de travail. Toutes les décisions de mise à l’échelle ne peuvent pas être dérivées des métriques du processeur ou de la mémoire. Souvent, les considérations relatives à la mise à l’échelle proviennent de points de données plus complexes, voire externes. Utilisez KEDA pour créer un ensemble de règles de mise à l’échelle automatique significatif basé sur des signaux spécifiques à votre charge de travail.

Pour obtenir d’autres suggestions, consultez Principes du pilier d’efficacité des performances.

Définitions de stratégies

Azure Policy propose diverses 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 fournies dans audit/refus, mais également dans une variante Deploy If Not Exists .

Il existe un grand nombre de stratégies, et les stratégies clés liées à ce pilier sont résumées ici. Pour obtenir une vue plus détaillée, consultez Définitions de stratégie intégrées pour Kubernetes.

Architecture du cluster et de la charge de travail

  • Limites des ressources de processeur et de mémoire

En plus des 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 des architectures Azure

Guide du Cloud Adoption Framework

Étapes suivantes