Cette architecture de référence fournit une architecture d’infrastructure de base recommandée pour déployer un cluster Azure Kubernetes Service (AKS) sur Azure. Elle utilise nos principes de conception et repose sur nos meilleures pratiques architecturales d’Azure Well-Architected Framework pour guider une équipe interdisciplinaire ou plusieurs équipes distinctes telles que la mise en réseau, la sécurité et l’identité grâce à ce déploiement d’infrastructure à usage général.
Cette architecture n'est pas axée sur une charge de travail. Elle se concentre plutôt sur le cluster AKS lui-même. Les informations ci-dessous sont la base de référence minimale recommandée pour la plupart des clusters AKS. Elle s’intègre aux services Azure qui fournissent une observabilité, une topologie de réseau qui prend en charge une croissance multirégionale et sécurise le trafic dans le cluster.
L’architecture cible est influencée par vos besoins métier, et peut donc varier dans différents contextes d’application. Elle doit être considérée comme votre point de départ pour les phases de préproduction et de production.
Une implémentation de cette architecture est également disponible sur GitHub : Implémentation de référence de base d’Azure Kubernetes Service (AKS). Vous pouvez l’utiliser comme point de départ alternatif et la configurer en fonction de vos besoins.
Remarque
Cette architecture de référence implique une connaissance de Kubernetes et de ses concepts. Si vous devez actualiser vos connaissances, consultez la section En savoir plus sur AKS pour les ressources.
Configuration de la mise en réseau
Topologie du réseau
Planifier les adresses IP
Déployer les ressources d’entrée
Sécuriser le flux de données
Continuité de l’activité
Extensibilité
Disponibilité des clusters et des nœuds
Disponibilité et prise en charge multirégion
Topologie du réseau
Cette architecture utilise une topologie hub-and-spoke. La topologie hub-and-spoke est déployée dans des réseaux virtuels distincts connectés par peering. Cette topologie présente notamment les avantages suivants :
Gestion séparée. Permet d’appliquer la gouvernance et d’adhérer au principe de privilège minimum. Elle prend également en charge le concept de zone d'atterrissage Azure avec séparation des tâches.
Elle réduit l’exposition directe des ressources Azure à l’Internet public.
Les organisations utilisent souvent des topologies hub-and-spoke régionales. Les topologies de réseau hub-and-spoke peuvent être étendues à l’avenir et fournir l’isolation de la charge de travail.
Toutes les applications web doivent nécessiter un service de pare-feu d’applications web (WAF) pour les aider à régir le flux de trafic HTTP.
Un choix naturel pour les charges de travail qui s’étendent sur plusieurs abonnements.
L’architecture est alors extensible. Pour prendre en charge de nouvelles fonctionnalités ou charges de travail, vous pouvez ajouter de nouveaux spokes plutôt que de redéfinir la topologie de réseau.
Certaines ressources, pare-feu et DNS notamment, peuvent être partagées entre les réseaux.
S’aligne sur les zones d’atterrissage à l’échelle de l’entreprise Azure.
Téléchargez un fichier Visio de cette architecture.
Pour plus d’informations, consultez topologie de réseau hub-and-spoke dans Azure.
Pour passer en revue les modifications apportées à la conception réseau incluse dans des conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Hub
Le réseau virtuel hub est le point central de connectivité et d’observabilité. Dans cette architecture, le hub contient les composants suivants :
- Un pare-feu Azure 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.
- Un sous-réseau de passerelle pour la connectivité VPN.
- Azure Monitor pour l'observation du réseau.
Au sein du réseau, trois sous-réseaux sont déployés.
Sous-réseau pour héberger Pare-feu Azure
Pare-feu Azure est un pare-feu en tant que service. L’instance de pare-feu sécurise le trafic réseau sortant. Sans cette couche de sécurité, ce trafic pourrait communiquer avec un service tiers malveillant susceptible d'exfiltrer des données sensibles sur la charge de travail. Azure Firewall Manager vous permet de déployer et de configurer de manière centralisée plusieurs instances de Pare-feu Azure et de 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 espace réservé pour une passerelle VPN ou 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 Bastion pour accéder en toute sécurité aux ressources Azure sans exposer les ressources sur Internet. Ce sous-réseau est réservé à la gestion et aux opérations.
Spoke
Le réseau virtuel spoke contient le cluster AKS et d’autres ressources associées. Le spoke comprend quatre sous-réseaux :
Sous-réseau pour héberger Azure Application Gateway
Azure Application Gateway est un équilibreur de charge du trafic web de couche 7. L’implémentation de référence utilise la référence SKU Application Gateway v2 qui active le pare-feu d’applications web (WAF). WAF protège le trafic entrant contre les attaques courantes du trafic web, y compris les bots. L’instance présente une configuration IP frontale publique qui reçoit les demandes de l’utilisateur. 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 traite les ressources d’entrée 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 Azure Kubernetes Service (AKS).
Sous-réseau pour héberger les nœuds de cluster
AKS gère deux groupes de nœuds distincts (ou pools de nœuds). Le pool de nœuds système héberge les pods qui exécutent les principaux services de cluster. Le pool de nœuds utilisateur exécute votre charge de travail et le contrôleur d’entrée pour permettre une communication entrante vers la charge de travail.
Sous-réseau pour héberger des points de terminaison Private Link
Des connexions Azure Private Link sont créées pour Azure Container Registry et Azure Key Vault. Ces services sont donc accessibles 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é et peuvent également être placés dans le réseau virtuel hub. Dans l’implémentation de base, ils sont déployés sur un sous-réseau dédié au sein du réseau virtuel spoke. Cette approche réduit le trafic transitant par la connexion réseau appairée, conserve les ressources appartenant au cluster dans le même réseau virtuel et vous permet d’appliquer des règles de sécurité granulaires au niveau du sous-réseau à l’aide de 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.
L’espace d’adressage du réseau virtuel doit être suffisamment grand pour contenir tous les sous-réseaux. Compte pour toutes les entités qui recevront le trafic. Les adresses IP de ces entités seront allouées à partir de l’espace d’adressage du sous-réseau. Tenez compte de ces points.
Mises à niveau
AKS met régulièrement à jour les nœuds pour s’assurer que les machines virtuelles sous-jacentes sont à jour en termes de fonctionnalités de sécurité et autres correctifs système. Lors d’un processus de mise à niveau, AKS crée un nœud qui héberge temporairement les pods, tandis que le nœud de mise à niveau est fermé et vidé. Ce nœud temporaire reçoit une adresse IP à partir du sous-réseau du cluster. Veillez à disposer d'un espace d'adressage suffisant pour ces adresses IP de nœuds temporaires.
Pour les pods, vous pouvez avoir besoin d’adresses supplémentaires selon votre stratégie. Pour les mises à jour propagées, vous avez besoin d’adresses pour les blocs temporaires qui exécutent la charge de travail lors de la mise à jour des pods réels. Si vous utilisez la stratégie de remplacement, les pods sont supprimés et de nouveaux pods sont créés. Ainsi, les adresses associées aux anciens pods sont réutilisées.
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 aurez besoin de quatre fois le nombre d’adresses pour tous les nœuds faisant l’objet du scale-out.
Dans cette architecture, chaque pod peut être contacté directement. Dès lors, chaque pod a besoin d’une adresse individuelle. La scalabilité du pod a un impact sur le calcul d’adresse. Cette décision dépend du nombre de pods que vous souhaitez augmenter.
Adresses Azure Private Link
Facteur des adresses requises pour communiquer avec d’autres services Azure via Azure Private Link. Dans cette architecture, deux adresses sont affectées pour les liens vers Azure Container Registry et Key Vault.
Certaines adresses sont réservées à Azure. Elles ne peuvent pas être affectées.
La liste précédente n’est pas exhaustive. Si votre conception présente d’autres ressources qui auront un impact sur le nombre d’adresses IP disponibles, prenez en compte ces adresses.
Cette architecture est conçue pour une charge de travail unique. Dans un cluster AKS de production, le pool de nœuds système doit toujours être séparé 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. Ce choix peut entraîner un plus grand nombre de sous-réseaux de taille inférieure. 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.
Pour obtenir la liste complète des éléments à prendre en compte dans le cadre de cette architecture, consultez Topologie de réseau de base AKS.
Pour plus d’informations sur la planification IP pour un cluster AKS, consultez Planifier l’adressage IP pour votre cluster.
Pour passer en revue les considérations relatives à la planification des adresses IP incluses dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Modules complémentaires et fonctionnalités d’évaluation
Kubernetes et AKS sont des produits en constante évolution, avec des cycles de mise en production plus rapides que des logiciels pour des environnements locaux. Cette architecture de base dépend de la sélection des fonctionnalités d’évaluation AKS et des modules complémentaires AKS. La différence entre les deux est la suivante :
- L’équipe AKS décrit les fonctionnalités d’évaluation comme fournies et à améliorer. La raison en est que la plupart des fonctionnalités d’évaluation restent dans cet état pendant quelques mois seulement avant de passer à la phase de mise en production générale (GA).
- Les extensions et modules complémentaires AKS fournissent des fonctionnalités supplémentaires prises en charge. Leurs installation, configuration et cycle de vie sont gérés par AKS.
Cette architecture de base n'inclut pas toutes les fonctionnalités d'évaluation ni tous les modules complémentaires. Seuls ceux qui apportent une valeur ajoutée significative à un cluster à usage général sont inclus. À mesure que ces fonctionnalités sortiront de la préversion, cette architecture de base sera révisée en conséquence. Il existe des fonctionnalités d’évaluation ou des modules complémentaires AKS supplémentaires que vous souhaiterez peut-être évaluer dans des clusters de préproduction qui augmentent votre sécurité, votre facilité de gestion ou répondent à d’autres exigences. Avec des modules complémentaires tiers, vous devez les installer et les gérer, 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 les extrayez dans votre cluster.
Le cluster est authentifié pour extraire l’image.
Si vous utilisez une image publique, envisagez de l’importer dans votre registre de conteneurs qui s’aligne avec votre SLO. Dans le cas contraire, l’image peut faire l’objet de problèmes de disponibilité inattendus. Ces problèmes peuvent entraîner des problèmes opérationnels si l’image n’est pas disponible lorsque vous en avez besoin. Voici quelques-uns des avantages liés à l’utilisation de votre registre de conteneurs 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 d’extraction d’image pour surveiller les activités et trier les problèmes de connectivité.
- Tirez parti de l’analyse de conteneur intégrée et de la conformité des images.
Azure Container Registry (ACR) constitue une option.
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 extrait uniquement les images de l’ACR qui est déployé dans le cadre de l’architecture.
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. Cela permet de réduire l’empreinte des services qui s’exécutent sur tous les nœuds, tels que la surveillance et la journalisation.
Si vous avez des charges de travail spécifiques, sélectionnez le type de machine virtuelle approprié. Par exemple, vous pourriez avoir besoin d'une UGS à mémoire optimisée pour certaines charges de travail, ou d'une UGS à accélération GPU pour d'autres. Pour en savoir plus sur les familles de machines virtuelles disponibles dans Azure, consultez la rubrique Tailles des machines virtuelles dans Azure.
Déployez au moins deux nœuds. La charge de travail disposera 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.
La taille réelle des nœuds de votre charge de travail dépend des exigences déterminées par l’équipe de conception. En fonction des besoins de l’entreprise, nous avons choisi DS4_v2 pour la charge de travail de production. Pour réduire les coûts, il est possible d’opter pour DS3_v2, ce qui correspond à la recommandation minimale.
Lorsque vous planifiez la capacité de votre cluster, partez du principe que votre charge de travail peut consommer jusqu’à 80 % de chaque nœud ; les 20% restants étant 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 ligne de 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.
Intégrer Microsoft Entra ID pour le cluster
Sécuriser l’accès au cluster est impératif. En matière de sécurité, réfléchissez en termes de cluster :
- Accès de l’intérieur. Accès AKS aux composants Azure tels que l’infrastructure réseau, Azure Container Registry et Azure Key Vault. Autorisez les seules ressources auxquelles le cluster est autorisé à accéder.
- Accès de l’extérieur. Octroi aux identités de l’accè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.
Les identités managées sont recommandées. Avec les principaux de service, vous êtes responsable de la gestion et de la rotation des 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.
Il est recommandé d'activer les identités gérées afin que le cluster puisse interagir avec les ressources Azure externes via Microsoft Entra ID. Ce paramètre est à activer lors de la création du cluster. Même si Microsoft Entra ID n’est pas utilisé immédiatement, vous pouvez 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. L'identité du cluster est utilisée par les composants du plan de contrôle de l'AKS pour gérer les ressources du cluster, notamment les équilibreurs de charge d'entrée, les IP publiques gérées par l'AKS, etc. L'identité du kubelet est utilisée pour s'authentifier auprès d'Azure Container Registry (ACR). Certains modules complémentaires prennent également en charge l’authentification à l’aide d’une identité managée.
À titre d’exemple, nous allons nous pencher sur l’utilisation des identités managées quand le cluster doit tirer (pull) 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 Kubernetes Secrets et utiliser imagePullSecrets
pour récupérer le secret. Une telle approche est déconseillée en raison de la complexité qu’elle présente en matière de sécurité. Vous devez connaître au préalable le secret et le divulguer via le pipeline DevOps. La surcharge opérationnelle liée à la gestion de la rotation du secret constitue une autre raison. Au lieu de cela, autorisez l’accès AcrPull
à l’identité managée kubelet du cluster à votre registre. Cette approche répond à ces problèmes.
Dans cette architecture, le cluster accède aux ressources Azure qui sont sécurisées par Microsoft Entra ID et effectue des opérations qui prennent en charge les identités managées. Attribuez le contrôle d’accès en fonction du rôle Azure (RBAC Azure) et les autorisations aux identités managées du cluster en fonction des opérations que ce dernier devra effectuer. 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 ont été attribués. Voici quelques exemples de cette implémentation de référence avec attribution des rôles intégrés Azure au cluster :
- Contributeur de réseau. Capacité du cluster à contrôler le réseau virtuel spoke. Cette attribution de rôle permet au système de cluster AKS attribué à l’identité d’utiliser le sous-réseau dédié pour les services de contrôleur d’entrée interne.
- Publication des métriques de surveillance. Capacité du cluster à envoyer des métriques à Azure Monitor.
- AcrPull. Capacité du cluster à tirer (pull) des images des registres de conteneurs Azure spécifiés.
Accès au cluster
L’intégration Microsoft Entra simplifie également la sécurité pour l’accès de l’extérieur. Supposons qu’un utilisateur souhaite recourir à kubectl. En guise d’étape initiale, il exécute la commande az aks get-credentials
pour obtenir les informations d’identification du cluster. Microsoft Entra ID authentifie l’identité de l’utilisateur auprès des rôles Azure qui sont autorisés à accéder aux informations d’identification du cluster. Pour plus d’informations, consultez Autorisations des rôles de cluster disponibles.
AKS permet l’accès Kubernetes avec 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 Kubernetes natif. L’autre consiste à utiliser le contrôle RBAC Azure natif pour contrôler l’accès au cluster. Elles sont toutes les deux détaillées ci-dessous.
Associer Kubernetes RBAC à Microsoft Entra ID
Kubernetes prend en charge le contrôle d’accès en fonction du rôle (RBAC) à l’aide de ce qui suit :
Jeu d’autorisations. Défini par un objet
Role
ouClusterRole
pour les autorisations au niveau du cluster.Liaisons qui attribuent des utilisateurs et des groupes autorisés à effectuer les actions. Définies par un objet
RoleBinding
ouClusterRoleBinding
.
Kubernetes possède plusieurs rôles intégrés tels que cluster-admin, edit, view, etc. Liez ces rôles aux utilisateurs et groupes Microsoft Entra pour utiliser le répertoire d’entreprise afin de 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.
Assurez-vous que vos groupes Microsoft Entra utilisés pour l’accès aux clusters et aux espaces de noms sont inclus dans vos révisions d’accès Microsoft Entra.
Utiliser Azure RBAC pour l’autorisation Kubernetes
Au lieu d’utiliser le RBAC natif Kubernetes (ClusterRoleBindings et RoleBindings), pour l’autorisation avec l’authentification Microsoft Entra intégrée, une autre option que nous recommandons consiste à utiliser Azure RBAC et les attributions de rôle Azure pour appliquer des vérifications d’autorisation sur le cluster. Ces attributions de rôles peuvent même être ajoutées aux portées du groupe de gestion, de l'abonnement ou du groupe de ressources afin que tous les clusters sous la portée héritent d'un ensemble cohérent d'attributions de rôles en ce qui concerne qui a les permissions d'accéder aux objets sur le cluster Kubernetes.
Pour plus d’informations, consultez Azure RBAC pour l’autorisation Kubernetes.
Comptes locaux
AKS prend en charge l’authentification utilisateur Kubernetes native. L’accès utilisateur aux clusters à l’aide de cette méthode n’est pas conseillé. Elle est basée sur des certificats et est réalisée en dehors de votre fournisseur d'identité principal, ce qui rend difficile le contrôle d'accès et la gouvernance centralisés des utilisateurs. Gérez toujours l’accès à votre cluster à l’aide de Microsoft Entra ID et configurez votre cluster pour désactiver explicitement l’accès au compte local.
Dans cette implémentation de référence, l’accès par le biais de comptes de cluster locaux est explicitement désactivé lors du déploiement du 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 auprès de la ressource en tant qu’identité managée Azure.
Dans cette implémentation de référence, les identités managées pour les pods sont fournies via Microsoft Entra Workload ID sur AKS. Elles s’intègrent aux fonctionnalité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.
Déployer des ressources d’entrée
Les ressources d’entrée Kubernetes acheminent et distribuent le trafic entrant vers le cluster. Les ressources d’entrée se répartissent en deux :
Équilibreur de charge interne. Managé par AKS. Cet équilibreur de charge expose le contrôleur d’entrée via une adresse IP statique privée. Il fait office de point de contact unique recevant les flux entrants.
Dans cette architecture, Azure Load Balancer est utilisé. Il est placé à l’extérieur du cluster, dans un sous-réseau dédié aux ressources d’entrée. Il reçoit le trafic provenant d’Azure Application Gateway et la communication se fait via TLS. Pour plus d’informations sur le chiffrement TLS du trafic entrant, consultez Flux de trafic d’entrée.
Contrôleur d’entrée. Nous avons choisi 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. Prenez en compte les points suivants lors de la configuration de ce composant.
En termes de conception, optez pour une étendue dans laquelle le contrôleur d’entrée est autorisé à fonctionner. 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é de l'activité en cas de panne 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 isole la charge de travail et les pods système.Ouvrez les ports et protocoles permettant à des entités spécifiques d’envoyer le trafic vers le contrôleur d’entrée. Dans cette architecture, Traefik reçoit uniquement le trafic provenant d’Azure Application Gateway.
Le contrôleur d’entrée doit envoyer des signaux indiquant l’intégrité des pods. Configurez les paramètres
readinessProbe
etlivenessProbe
qui surveilleront l’intégrité des pods à l’intervalle spécifié.Envisagez de restreindre l’accès du contrôleur d’entrée à des ressources spécifiques et la possibilité d’effectuer certaines actions. Cette restriction peut être implémentée par le biais d’autorisations RBAC Kubernetes. Par exemple, dans cette architecture, Traefik s’est vu attribuer des autorisations pour surveiller, obtenir et répertorier des services et points de terminaison à l’aide de règles dans l’objet Kubernetes
ClusterRole
.
Notes
Le choix du contrôleur d’entrée approprié est motivé par les exigences de la charge de travail, les compétences de l’opérateur et la supportabilité des options informatiques. 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 est choisi dans cette architecture à des fins d'illustration. Elle met en lumière l’intégration de produits tiers aux services Azure. Par exemple, l’implémentation montre comment intégrer Traefik avec Microsoft Entra Workload ID et Azure Key Vault.
Un autre choix possible est le contrôleur d’entrée Azure Application Gateway qui est bien intégré 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. Si vous avez une application qui nécessite un pare-feu d’applications web (WAF), Application Gateway est un bon choix, car il est intégré avec un WAF. De même, il offre la possibilité d’effectuer une terminaison TLS.
Pour passer en revue la conception d’entrée utilisée dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
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. annotations
, tls
et entrypoints
indiquent que les itinéraires seront traités via HTTPS. middlewares
indique que seul le trafic provenant du sous-réseau Azure Application Gateway est autorisé. Sous réserve d’acceptation du client, les réponses utilisent l’encodage gzip. Traefik se chargeant de la terminaison TLS, la communication avec les services principaux se fait via 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 ce contexte, le workflow réseau peut être classé comme suit :
Trafic d’entrée. Entre le client et la charge de travail s’exécutant dans le cluster.
Trafic de sortie. Entre un pod ou nœud du cluster vers un service externe.
Trafic pod à pod. Communication entre pods. Ce trafic inclut la communication entre le contrôleur d’entrée et la charge de travail. En outre, si votre charge de travail comprend plusieurs applications déployées sur le cluster, la communication entre ces applications entre dans cette catégorie.
Trafic de gestion. Trafic entre le client et le serveur d’API Kubernetes.
Téléchargez un fichier Visio de cette architecture.
Cette architecture dispose de plusieurs couches de sécurité visant à sécuriser tous les types de trafic.
Flux de trafic d’entrée
L’architecture accepte uniquement les demandes TLS chiffrées du client. TLS v1.2 est la version minimale autorisée avec un ensemble restreint de chiffres. La correspondance stricte de l'indication de nom de serveur (SNI) est activée. Le chiffrement TLS de bout en bout est configuré par le biais d’Application Gateway à l’aide de deux certificats TLS distincts, comme illustré sur cette image.
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é via un enregistrement DNS A à l’adresse IP publique d’Azure Application Gateway. Ce trafic est chiffré pour éviter que le trafic entre le navigateur client et la passerelle ne soit inspecté ou modifié.Application Gateway dispose d’un pare-feu d’applications web (WAF) intégré et se charge de la négociation TLS pour
bicycle.contoso.com
, autorisant ainsi les seuls chiffrements sécurisés. Application Gateway est un point de terminaison TLS requis pour traiter les règles d’inspection WAF et exécuter des règles d’acheminement qui transfèrent le trafic vers le serveur principal configuré. Le certificat TLS est stocké dans Azure Key Vault. Il est accessible à l’aide d’une identité managée attribuée par l’utilisateur et intégrée à Application Gateway. Pour plus d'informations sur cette fonctionnalité, consultez Terminaison TLS avec certificats Key Vault.Lorsque le trafic passe de l'Application Gateway au backend, il est à nouveau chiffré avec une autre certification TLS (caractère générique pour
*.aks-ingress.contoso.com
) lors de son transfert vers l'équilibreur de charge interne. Ce re-chiffrement permet de veiller à ce que le trafic non sécurisé ne soit pas acheminé vers 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 certificats sont stockés dans Azure Key Vault et montés dans le cluster à l’aide du pilote CSI (Container Storage Interface). Pour plus d’informations, consultez Ajouter la gestion des secrets.
Vous pouvez implémenter le trafic TLS de bout en bout à tous les tronçons menant au pod de charge de travail. Lorsque vous décidez de sécuriser le trafic de pod à pod, veillez à mesurer les performances, la latence et l’impact opérationnel. Pour la plupart des clusters monolocataires, avec RBAC de plan de contrôle et des pratiques de cycle de vie de développement logiciel mature, il est suffisant d’opter pour un chiffrement TLS par le biais du contrôleur d’entrée et d’une protection avec pare-feu d’applications web (WAF). Cela réduira la surcharge liée à la gestion des charges de travail et à l’impact sur les performances du réseau. Vos exigences en matière de charge de travail et de conformité déterminent où vous effectuez la terminaison TLS.
Flux du trafic de sortie
Dans cette architecture, nous recommandons que tout le trafic sortant du cluster passe par la pare-feu Azure ou par votre propre appliance réseau virtuelle similaire, au lieu d'utiliser d'autres options de sortie telles que la passerelle NAT ou le proxy HTTP qui ne permettent pas d'inspecter le trafic réseau. Pour un contrôle Confiance Zéro et la possibilité d’inspecter le trafic, l’intégralité du trafic de sortie transite via le pare-feu Azure. Vous pouvez implémenter ce choix à l’aide d’itinéraires définis par l’utilisateur (UDR). Le tronçon suivant de l’itinéraire correspond à l’adresse IP privée du pare-feu Azure. C’est ici que le pare-feu Azure décide s’il convient de bloquer ou d’autoriser le trafic de sortie. Cette décision repose sur les règles spécifiques définies dans le pare-feu Azure ou les règles de renseignement sur les menaces intégrées.
Une alternative à l’utilisation de Pare-feu Azure consiste à utiliser la fonctionnalité Proxy HTTP d’AKS. Tout le trafic sortant du cluster est défini en premier sur l’adresse IP du proxy HTTP, qui décide de transférer le trafic ou de le supprimer.
Avec l’une ou l’autre méthode, passez en revue les règles de réseau de sortie requises pour AKS.
Notes
Si vous utilisez un équilibreur de charge public comme point public pour le trafic entrant et sortant via le Pare-feu Azure à l’aide d’itinéraires définis par l’utilisateur (UDR), vous verrez peut-être 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 d’entrée via votre Pare-feu Azure avant ou après votre Application Gateway, mais cette approche n’est pas nécessaire ou recommandée pour la plupart des situations. Pour plus d’informations sur le routage asymétrique, consultez Intégrer un pare-feu Azure avec Azure Standard Load Balancer.
Il y a exception au contrôle Confiance Zéro lorsque le cluster doit communiquer avec d’autres ressources Azure. Par exemple, le cluster doit extraire une image mise à jour à partir du registre de conteneurs ou des secrets d’Azure Key Vault. L’approche recommandée consiste à utiliser Azure Private Link. L’avantage est que des sous-réseaux spécifiques atteignent le service directement au lieu du trafic entre le cluster et les services qui transitent par Internet. Cela étant, Azure Private Link implique une configuration supplémentaire plutôt que d’utiliser le service cible sur son point de terminaison public. Qui plus est, tous les services ou références SKU Azure ne prennent pas en charge Azure Private Link. Si tel est le cas, envisagez d’activer un point de terminaison de service de réseau virtuel sur le sous-réseau afin d’accéder au service.
S’il ne vous est pas possible d’utiliser Azure Private Link ou des points de terminaison de service, vous pouvez accéder à d’autres services via leurs points de terminaison publics et en contrôler l’accès via les règles du Pare-feu Azure et le pare-feu intégré au service cible. Ce trafic ayant vocation à transiter via l’adresse IP statique du pare-feu, ces adresses peuvent être ajoutées à la liste d’adresses IP autorisées du service. Cela étant, le Pare-feu Azure doit disposer de règles supplémentaires pour s’assurer que seul le trafic provenant d’un sous-réseau spécifique est autorisé. Tenez compte de ces adresses lorsque vous planifiez plusieurs adresses IP pour le trafic de sortie avec Pare-feu Azure, sinon vous pourriez subir un épuisement des ports. Pour plus d'informations sur la planification de plusieurs adresses IP, voir Restreindre et contrôler le trafic sortant.
Pour passer en revue des considérations de sortie spécifiques à Windows utilisées dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Trafic de pod à pod
Par défaut, un pod peut accepter le trafic de n’importe quel autre pod du cluster. Kubernetes NetworkPolicy
permet de limiter le trafic réseau entre pods. Appliquez judicieusement les stratégies pour éviter tout blocage de flux critique. 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 le cluster est approvisionné, car elle ne peut pas être ajoutée ultérieurement. En matière de technologies implémentant NetworkPolicy
, plusieurs options s’offrent à vous. Recommandée, la stratégie réseau Azure requiert Azure Container Networking Interface (CNI). Consultez la remarque ci-dessous. D’autres options incluent 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 la stratégie réseau Azure et les stratégies Calico et leurs fonctionnalités.
Remarque
AKS prend en charge plusieurs modèles de réseau, notamment kubenet, Azure Container Networking Interface (CNI) et Azure CNI Overlay. Les modèles CNI sont les modèles les plus avancés, et un modèle CNI est nécessaire pour activer la Stratégie réseau Azure. Les deux modèles CNI sont très performants, avec des performances entre pods au même niveau que les machines virtuelles d’un réseau virtuel. Un modèle réseau basé sur CNI est recommandé.
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. NAT n’est pas nécessaire pour acheminer ce trafic.
Azure CNI offre également un contrôle de sécurité renforcé car elle permet d'utiliser la stratégie réseau d'Azure. Il est recommandé d'utiliser Azure CNI Overlay pour les déploiements avec contraintes d'adresses IP, 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 des pods.
Pour plus d’informations sur les modèles, consultez Choix d’un modèle réseau CNI à utiliser et Comparer les modèles réseau kubenet et Azure CNI.
Trafic de gestion
Dans le cadre de l’exécution du cluster, le serveur d’API Kubernetes reçoit le trafic des ressources qui souhaitent effectuer des opérations de gestion sur le cluster, telles que les requêtes de création de ressources ou la mise à l’échelle du cluster. Les exemples de ces ressources incluent le pool d'agents de construction dans un pipeline DevOps, une instance Azure Bastion dans le sous-réseau Bastion, et les pools de nœuds eux-mêmes. Plutôt que d’accepter ce trafic de gestion à partir de toutes les adresses IP, utilisez les plages d’adresses IP autorisées AKS pour autoriser uniquement le trafic à partir de vos plages d’adresses IP autorisées vers le serveur d’API.
Pour plus d’informations, consultez Définir des plages d’adresses IP autorisées du serveur d’API.
Pour une couche de contrôle supplémentaire, au coût d’une complexité supplémentaire, vous pouvez approvisionner 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 uniquement sur le réseau privé et n'est jamais exposé à Internet. Pour plus d’informations, consultez Clusters privés AKS.
Ajouter la gestion des secrets
Stockez les secrets dans un magasin de clés géré, notamment Azure Key Vault. Un tel magasin permet de gérer la rotation des secrets, d’offrir un chiffrement renforcé, de fournir un journal d’audit d’accès et de conserver les principaux secrets en dehors du pipeline de déploiement. Dans cette architecture, le pare-feu Azure Key Vault est activé et configuré avec des connexions de liaison privée aux ressources dans Azure qui doivent accéder aux secrets et certificats.
Azure Key Vault s’intègre parfaitement aux autres services Azure. Utilisez la fonctionnalité intégrée de ces services pour accéder aux secrets. Pour obtenir un exemple sur la façon dont Azure Application Gateway accède aux certificats TLS pour le flux d’entrée, consultez la section Flux de trafic d’entrée.
Le modèle d’autorisation RBAC Azure pour Key Vault vous permet d’affecter les identités de charge de travail à l’utilisateur de secrets Key Vault ou à l’attribution de rôle Lecteur Key Vault, et d’accéder aux secrets. Pour plus d’informations, consultez Accéder à Azure Key Vault à l’aide de RBAC.
Accès aux secrets de cluster
Vous devez utiliser des identités de charge de travail pour permettre à un pod d’accéder aux secrets d’un magasin spécifique. Pour faciliter le processus de récupération, utilisez un pilote Secrets Store CSI. Lorsque le pod requiert un secret, le pilote se connecte au magasin spécifié, récupère le 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. Dans cette implémentation, nous avons choisi Azure Key Vault avec le pilote Secrets Store CSI à l’aide du module complémentaire pour récupérer le certificat TLS à partir d’Azure Key Vault et le charger dans le pod exécutant le contrôleur d’entrée. Cette opération intervient lors de la création du pod, et le volume stocke les clés publiques et privées.
Stockage de charge de travail
La charge de travail utilisée dans cette architecture se présente sans état. S’il vous faut en stocker l’état, nous vous conseillons de le conserver 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 sur les options de stockage, consultez Options de stockage pour les applications dans Azure Kubernetes Service (AKS).
Gestion des stratégies
Une façon efficace de gérer un cluster AKS est d’appliquer la gouvernance à travers des stratégies. Kubernetes implémente les stratégies via l’opérateur OPA Gatekeeper. Pour AKS, les stratégies sont remises via Azure Policy. Chaque stratégie est appliquée à tous les clusters compris dans son étendue. La mise en œuvre d’Azure Policy est finalement gérée par l’opérateur OPA Gatekeeper dans le cluster et toutes les vérifications de stratégies sont journalisées. Les changements de stratégie ne sont pas immédiatement répercutés dans votre cluster, il faut donc s'attendre à des retards.
Deux scénarios différents sont fournis par Azure Policy pour la gestion de vos clusters AKS :
- Empêcher ou restreindre le déploiement de clusters AKS dans un groupe de ressources ou un abonnement en évaluant les normes de votre organisation. Par exemple, suivez une convention de dénomination, spécifiez une balise, etc.
- 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 :
Souhaitez-vous définir une collection de stratégies (appelée initiative) 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. Il est recommandé de sélectionner une initiative et de choisir des stratégies supplémentaires pour le cluster et les ressources (ACR, Application Gateway, Key Vault et autres) qui interagissent avec le cluster, conformément aux 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 elle est marquée comme étant Non conforme. Disposez-vous de processus qui vérifient régulièrement les états non conformes et prennent les mesures nécessaires ? En mode Refus, l’action est bloquée, car elle enfreint la stratégie. Ce mode doit être choisi avec prudence, car il peut s’avérer 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. Il est recommandé de continuer à appliquer les stratégies en mode Audit afin d'être au courant de ces instances.
Parmi vos exigences, y en a-t-il 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 en savoir plus sur la création de stratégies personnalisées, consultez Créer et attribuer des définitions de stratégie 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 aussi affecter des stratégies spécifiques en fonction de sa charge de travail, même si l’organisation a des stratégies génériques.
Les stratégies Azure sont affectées à des étendues spécifiques. Vérifiez que les stratégies de production sont également validées par rapport à votre environnement de préproduction. Autrement, lorsque vous déploierez dans votre environnement de production, vous risquez de rencontrer des restrictions supplémentaires inattendues qui n’ont pas été prises en considération en préproduction.
Dans cette implémentation de référence, Azure Policy est activé pendant la création du cluster AKS et affecte l’initiative restrictive en mode Audit pour accéder aux informations de 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 garantir que les images sont extraites uniquement de l’ACR déployé. Envisagez de créer vos propres initiatives personnalisées. Regroupez les stratégies applicables à votre charge de travail dans une seule affectation.
Pour observer la façon dont Azure Policy fonctionne dans votre cluster, vous pouvez accéder aux journaux de tous les pods de l’espace de noms gatekeeper-system
ainsi qu’aux journaux des pods azure-policy
et azure-policy-webhook
de l’espace de noms kube-system
.
Pour passer en revue des considérations Azure Policy relatives à Windows incluses dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Scalabilité des nœuds et des pods
Face à une demande croissante, Kubernetes peut effectuer un scale-out en ajoutant des pods aux nœuds existants moyennant la mise à l’échelle automatique de pods horizontaux (HPA). Lorsque des modules supplémentaires ne peuvent plus être planifiés, le nombre de nœuds doit être augmenté via la mise à l’échelle automatique du 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.
La méthode manuelle ou par programmation implique que vous surveilliez et définissiez des alertes en matière d’utilisation du processeur ou des métriques personnalisées. Pour la mise à l’échelle de pod, l’opérateur d’application peut augmenter ou diminuer le nombre de réplicas de pod en ajustant ReplicaSet
par le biais des API Kubernetes. Pour la mise à l’échelle de cluster, vous pouvez être averti 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.
La mise à l’échelle automatique est l’approche recommandée, car certains mécanismes manuels sont intégrés à l’autoscaler.
En guise d’approche générale, commencez par tester les performances avec un nombre minimal de pods et de nœuds. Utilisez ces valeurs pour déterminer l’attente de base. Utilisez ensuite une combinaison de métriques de performances 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 le scénario de réglage des performances à l’aide d’AKS, consultez Scénario de réglage 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, il est recommandé de définir le nombre de réplicas minimal et maximal. Ces valeurs déterminent les limites de mise à l’échelle automatique.
La ressource HPA peut évoluer en fonction de l’utilisation du processeur et de la mémoire, ainsi que des métriques personnalisées. Seule l’utilisation du processeur est prête à l’emploi. La définition HorizontalPodAutoscaler spécifie les valeurs cibles de ces métriques. Par exemple, la spécification définit une utilisation du processeur cible. Lors de l’exécution des pods, le contrôleur HPA utilise l’API Métriques Kubernetes 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ù HPA vérifie avant qu'une opération de mise à l'échelle ne soit terminée. Il peut en résulter un calcul de ratio incorrect. Pour plus d’informations, consultez Ralentissement des événements de mise à l’échelle.
Si votre charge de travail est basée sur les événements, KEDA constitue une option open source populaire. Envisagez KEDA si votre charge de travail est basée sur une source d’événement, comme une file d’attente de messages, plutôt que liée au processeur ou à la mémoire. KEDA prend en charge de nombreuses sources d’événements (ou scalers). Vous pouvez trouver la liste des scalers KEDA pris en charge ici, y compris le scaler Azure Monitor, qui est un moyen pratique de mettre à l'échelle les charges de travail KEDA en fonction 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. Il est à ajouter lors de l’approvisionnement du cluster. Vous devez disposer d’un autoscaler de cluster distinct pour chaque pool de nœuds utilisateur.
L’autoscaler de cluster est déclenché par le planificateur Kubernetes. 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 un 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 de nœuds maximal et minimal. 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 définie sur 2 en raison simplicité de la charge de travail.
Pour le pool de nœuds système, la valeur minimale recommandée correspond à 3.
Pour passer en revue des considérations de mise à l’échelle incluses dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Décisions de continuité des activités :
Pour maintenir la continuité des activités, définissez l'objectif de niveau de service (SLO) pour l'infrastructure et votre application. Pour en savoir plus sur les SLO, reportez-vous à la section Recommandations pour la définition des objectifs de fiabilité. Examinez les conditions du contrat SLA pour Azure Kubernetes Service dans le dernier document sur les accords de niveau de service pour les services en ligne.
Nœuds de cluster
Pour atteindre le niveau de disponibilité minimal des charges de travail, plusieurs nœuds sont nécessaires dans un pool de nœuds. Si un nœud échoue, un autre nœud du pool du même cluster peut continuer d’exécuter l’application. À des fins de fiabilité, trois nœuds sont recommandés pour le pool de nœuds système. Pour le pool de nœuds utilisateur, commencez avec au moins deux nœuds. Pour plus de disponibilité, approvisionnez davantage de nœuds.
Isolez votre ou vos applications des services système en les 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. L'utilisation de balises, d'étiquettes et de taints est recommandée pour identifier le pool de nœuds afin de planifier votre charge de travail, et s'assurer que votre pool de nœuds système est entaché du taint CriticalAddonsOnly.
La maintenance régulière de votre cluster (mises à jour en temps opportun notamment) est essentielle en termes de fiabilité. Il est recommandé de surveiller également l’intégrité des pods par le biais de probes.
Disponibilité de pod
Spécifiez les ressources requises pour les modules. En matière de déploiements, il est vivement recommandé de spécifier les besoins en ressources de pod. Le planificateur peut ensuite planifier comme il se doit le pod. La fiabilité sera considérablement réduite si les pods ne peuvent pas être planifiés.
Définir des budgets d’interruption de pod. Ce paramètre détermine le nombre de réplicas d’un déploiement pouvant être interrompus 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 permet de s’assurer de la présence du nombre de réplicas de pods requis pour gérer la charge d’application attendue.
Définir des quotas de ressources sur les espaces de noms de charge de travail. Le quota de ressources sur un espace de noms permet de s’assurer que les requêtes et les limites de pod sont correctement définies sur un déploiement. Pour plus d’informations, consultez Appliquer des quotas de ressources.
Notes
La définition de quotas de ressources au niveau du cluster peut provoquer un problème lors du déploiement de charges de travail tierces ne disposant pas de demandes ou limites appropriées.
Définir des demandes et limites de ressources. 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. Ajustez ensuite progressivement ces valeurs jusqu’à établir un seuil susceptible de provoquer une instabilité dans le cluster.
Les requêtes et les limites peuvent être spécifiées 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, vous devez utiliser 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é. Les opérations et configuration du groupe identique sont gérées par le service AKS. Voici quelques considérations liées à l’activation multizone :
Infrastructure entière. Choisissez une région qui prend en charge les zones de disponibilité. Pour plus d’informations, consultez Limitations et disponibilité de la région. 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. Les zones de disponibilité peuvent uniquement être définies lors de la création du pool de nœuds et ne sont ensuite pas modifiables. 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 d’une zone à l’autre.
La prise en charge multizone s’applique non seulement aux pools de nœuds, mais également au plan de contrôle. Le plan de contrôle AKS englobe les zones demandées, comme les pools de nœuds. Si vous n’utilisez pas la prise en charge des zones dans votre cluster, la répartition des composants du plan de contrôle entre les zones de disponibilité n’est pas garantie.
Ressources dépendantes. Pour bénéficier d’une offre zonale complète, toutes les dépendances de service doivent également prendre en charge les zones. Si un service dépendant ne prend pas en charge les zones, une défaillance de zone peut entraîner un échec du service.
Par exemple, un disque managé est disponible dans la zone où il est approvisionné. En cas de défaillance, le nœud peut se déplacer vers une autre zone, mais le disque managé ne se déplace pas avec le nœud vers cette zone.
Par souci de simplicité, dans cette architecture, AKS est déployé dans une seule région avec des pools de nœuds couvrant les zones de disponibilité 1, 2 et 3. D’autres ressources d’infrastructure, telles que le pare-feu Azure et Application Gateway, sont déployées dans la même région avec prise en charge multizone. La géoréplication est activée pour Azure Container Registry.
Plusieurs régions
L'activation des zones de disponibilité ne suffira pas dans le cas improbable où toute la région tomberait en panne. Pour une plus haute 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. Notez que certaines régions ne sont pas appariées. 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 CI/CD configuré 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.
Si une ressource Azure prend en charge la géo-redondance, indiquez l'emplacement où le service redondant aura son instance secondaire. Par exemple, l'activation de la géo-réplication pour Azure Container Registry répliquera automatiquement les images vers les régions Azure sélectionnées, et fournira un accès continu aux images même si la région principale subit une panne.
Selon vos besoins, optez pour un routeur de trafic capable de répartir le trafic entre les zones ou régions. Cette architecture déploie Azure Load Balancer, car il permet de distribuer le trafic non web entre les zones. S’il vous faut répartir le trafic entre les régions, envisagez Azure Front Door. Pour d’autres considérations, consultez Choisir un équilibreur de charge.
Notes
Nous avons étendu cette architecture de référence pour inclure plusieurs régions au sein d'une configuration active/active et hautement disponible. Pour plus d’informations sur cette architecture de référence, consultez la Base de référence AKS pour les clusters multirégions.
Une implémentation de l’architecture multirégion est disponible sur GitHub : Azure Kubernetes Service (AKS) pour le déploiement dans plusieurs régions. Vous pouvez l’utiliser comme point de départ et la configurer en fonction de vos besoins.
Récupération d'urgence
En cas de défaillance dans la région primaire, vous devez être en mesure de 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.
Une charge de travail sans état peut être répliquée efficacement. S’il vous faut stocker l’état dans le cluster (ce qui est déconseillé), veillez à sauvegarder fréquemment les données dans la région jumelée.
Intégrez la stratégie de récupération, telle que la réplication vers une autre région, au pipeline DevOps pour atteindre vos objectifs de niveau de service (SLO).
Lors de l’approvisionnement de chaque service Azure, choisissez des fonctionnalités qui prennent en charge la récupération d’urgence. Par exemple, dans cette architecture, Azure Container Registry est activé à des fins de géoréplication. En cas de défaillance d’une région, vous pouvez toujours extraire des images depuis la région répliquée.
Déployez votre infrastructure en tant que code, y compris votre cluster AKS ainsi que 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, l’approvisionnement d’un nouveau cluster et son retour à l’état d’exploitation peuvent être effectués via GitOps Démarrage du cluster et suivis du déploiement des applications. Toutefois, s’il existe un état critique des ressources, tel que des cartes de configuration, des travaux et potentiellement des secrets qui, pour une raison quelconque, ne peuvent pas être capturés dans votre processus de démarrage, envisagez votre stratégie de récupération. Nous recommandons généralement d’exécuter des charges de travail sans état dans Kubernetes, mais si votre architecture implique un état sur disque, vous devez également prendre en compte votre stratégie de récupération pour ce contenu.
Lorsque la sauvegarde de cluster doit faire partie de votre stratégie de récupération, vous devez installer une solution qui correspond aux besoins de votre entreprise au sein du cluster. Cet agent sera responsable de l’envoi (push) de l’état des ressources du cluster vers une destination de votre choix et de la coordination des captures instantanées de volume persistantes basées sur Azure Disk.
Velero de VMware est un exemple de solution de sauvegarde Kubernetes courante que vous pouvez installer et gérer directement. Vous pouvez également utiliser l’extension de sauvegarde AKS pour fournir une implémentation Velero managée. L’extension de sauvegarde AKS prend en charge la sauvegarde des ressources Kubernetes et des volumes persistants, avec des planifications et une étendue de sauvegarde externalisées en tant que configuration de coffre dans Sauvegarde Azure.
L'implémentation de référence ne met pas en œuvre la sauvegarde, ce qui impliquerait des ressources Azure supplémentaires dans l'architecture à gérer, surveiller, payer et sécuriser. Ces ressources pourraient inclure un compte Azure Storage, la configuration du coffre-fort Azure Backup & et l'accès de confiance. Au lieu de cela, GitOps combiné avec l'intention d'exécuter une charge de travail sans état est la solution de récupération mise en œuvre.
Choisissez et validez une solution qui répond à votre objectif d’entreprise, y compris votre objectif de point de récupération (RPO) et votre objectif de temps de récupération (RTO) défini. Définissez ce processus de récupération dans un runbook d’équipe et pratiquez-le pour toutes les charges de travail vitales pour l’entreprise.
Contrat SLA de Serveur d’API Kubernetes
AKS peut être utilisé en tant que service gratuit, mais ce niveau ne propose 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 charges de travail critiques uniquement. 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 SLA. Pour en savoir plus sur les accords de niveau de service spécifiques à chaque service, consultez les accords de niveau de service 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éoréplication dans Azure Container Registry, sont disponibles dans les références SKU Premium, ce qui s’avère plus coûteux. Pour les déploiements multirégionaux, le coût augmentera également en raison des frais de bande passante qui sont appliqués lorsque le trafic se déplace d'une région à l'autre.
En outre, attendez-vous à plus de latence réseau en termes de communication des nœuds entre les zones ou régions. Mesurez l’impact de cette décision architecturale sur votre charge de travail.
Tester la conception avec des simulations et des basculements forcés
Garantissez la fiabilité par le biais d’un test de basculement forcé avec pannes simulées, telles que l’arrêt d’un nœud, en arrêtant toutes les ressources AKS dans une zone donnée pour simuler une défaillance zonale ou l’appel d’une dépendance externe défaillante. Azure Chaos Studio peut également être utilisé pour simuler différents types de pannes dans Azure et sur le cluster.
Pour plus d’informations, consultez Azure Chaos Studio.
Surveiller et collecter des métriques
Azure Monitor Container Insights est l’outil recommandé pour surveiller les performances des charges de travail de conteneur, 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. Elle collecte également des informations à partir de l’API Métriques sur l’utilisation de la mémoire et du processeur afin de surveiller l’intégrité des ressources et charges de travail en cours d’exécution. Vous pouvez également l’utiliser pour surveiller les performances à mesure que les pods évoluent. Il comprend la collecte des données de télémétrie critiques pour la surveillance, la surveillance et la visualisation des données collectées pour identifier les tendances, et configurer des alertes pour être informé de manière proactive des problèmes critiques.
La plupart des charges de travail hébergées dans des pods émettent des métriques Prometheus. Container Insights peut s’intégrer à Prometheus pour afficher les métriques d’application et de charge de travail qu’il collecte à partir de nœuds et de Kubernetes.
Il existe certaines solutions tierces s’intégrant à Kubernetes, notamment Datadog, Grafana ou New Relic, dont vous pouvez tirer parti si votre organisation les utilise déjà.
Avec AKS, Azure gère certains services Kubernetes principaux et les journaux des composants du plan de contrôle AKS sont implémentés dans Azure en tant que journaux de ressources. Il est recommandé que la plupart des clusters aient les éléments suivants activés à tout moment, car ils peuvent vous aider à résoudre les problèmes de cluster et ont une densité de journal relativement faible :
- Connexion au ClusterAutoscaler à des fins d’observabilité des opérations de mise à l’échelle. Pour plus d’informations, consultez Récupérer les journaux et l’état de la mise à l’échelle automatique des clusters.
- KubeControllerManager pour observer l’interaction entre Kubernetes et le plan de contrôle Azure.
- KubeAuditAdmin pour observer les activités qui modifient votre cluster. Il n'y a aucune raison d'activer à la fois KubeAudit et KubeAuditAdmin, car KubeAudit est un surensemble de KubeAuditAdmin qui inclut également les opérations de non-modification (lecture).
- Guard capture les audits Microsoft Entra ID et Azure RBAC.
D’autres catégories de journaux, telles que KubeScheduler ou KubeAudit, peuvent être très utiles pour permettre au cours du développement précoce du cycle de vie du cluster ou de la charge de travail, où la mise à l’échelle automatique du cluster, la planification du placement des pods. et des données similaires peuvent aider à résoudre les problèmes liés aux opérations de cluster ou de charge de travail. Conserver les journaux de résolution des problèmes étendus à temps plein, une fois les besoins de dépannage terminés, peut être considéré comme un coût inutile pour l’ingestion et le stockage 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. À mesure que votre bibliothèque augmente, vous pouvez enregistrer et réutiliser des requêtes de journal à l’aide d’un ou plusieurs packs de requêtes. Votre bibliothèque personnalisée de requêtes permet d'observer davantage l'intégrité et les performances de vos clusters AKS et vous aide à atteindre vos objectifs de niveau de service (SLO).
Pour plus d’informations sur nos meilleures pratiques de supervision pour AKS, consultez Superviser Azure Kubernetes Service (AKS) avec Azure Monitor.
Pour passer en revue des considérations de surveillance spécifiques à Windows incluses dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Mesures du réseau
Les mesures de réseau de base au niveau du cluster sont disponibles via la plateforme native et les mesures Prometheus. Le module complémentaire Network Observability peut également être utilisé pour exposer les mesures de réseau au niveau des nœuds. La plupart des clusters devraient utiliser le module complémentaire Network Observability pour fournir des capacités supplémentaires de dépannage du réseau et pour détecter une utilisation inattendue du réseau ou des problèmes au niveau des nœuds.
Pour les charges de travail très sensibles à la perte de paquets TCP ou UDP, à la latence ou à la pression DNS, il est important de disposer de mesures réseau au niveau du pod. Dans AKS, ce niveau de détail est fourni par l'offre d'observabilité réseau avancée. La plupart des charges de travail ne nécessitent pas un tel niveau d'observabilité du réseau, et vous ne devez installer le module complémentaire d'observabilité avancée du réseau que si vos modules exigent un réseau hautement optimisé, avec une sensibilité jusqu'au niveau des paquets.
Activer la réparation spontanée
Surveillez l’intégrité des pods en définissant des probes Liveness et Readiness. Si un pod ne répond pas, Kubernetes le redémarre. Une sonde de vivacité détermine si le module est sain. S’il ne répond pas, Kubernetes le redémarre. Une sonde de préparation détermine si le pod est prêt à recevoir des requêtes/du trafic.
Remarque
AKS offre une réparation spontanée intégrée des nœuds d’infrastructure à l’aide de la fonctionnalité de réparation automatique de des nœuds.
Mises à jour de routine pour les clusters AKS
Une partie des opérations de jour-2 pour les clusters Kubernetes consiste à effectuer des mises à jour de la plateforme et du système d’exploitation de routine. Il y a trois niveaux de mises à jour qui doivent être adressés 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 pourrait inclure des changements d’API Kubernetes et des dépréciations. Les changements de version à ce niveau affectent l’ensemble du cluster.
- L’image 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 à ce niveau 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 lui-même (Windows Update, apt, etc.). Ces mises à jour sont fournies directement par le fournisseur du système d’exploitation et ne sont pas spécifiquement testées par rapport à la version Kubernetes du cluster. Les changements de version à ce niveau affectent un seul nœud et n’affectent pas la version de Kubernetes.
Chacune de ces couches est contrôlée de manière indépendante, et vous devez décider de la manière dont chacune est gérée pour les clusters de votre charge de travail. Vous devez décider de la fréquence de mise à jour de chaque cluster AKS, de ses pools de nœuds ou de ses nœuds (la cadence) et des jours ou heures auxquels les mises à jour doivent être appliquées (votre fenêtre de maintenance). Vous décidez si les mises à jour sont installées manuellement, automatiquement ou même pas du tout. Tout comme votre charge de travail exécutée sur votre cluster nécessite une pratique de déploiement sécurisée, il en va de même pour les mises à jour de vos clusters.
Pour une perspective complète sur les correctifs et les mises à niveau, veuillez consulter la section Azure Kubernetes Service patch and upgrade guidance dans le guide des opérations de jour-2 AKS. Continuez ci-dessous pour des recommandations de base en ce qui concerne cette architecture.
Infrastructure immuable
Les charges de travail qui exploitent les clusters AKS comme une infrastructure immuable ne mettent pas à jour leurs clusters - ni des mises à jour automatiques ni manuelles ne sont effectuées. La mise à niveau de l’image du nœud doit être définie sur None
et la mise à niveau automatique du cluster définie sur none
. Dans cette configuration, vous êtes seul responsable de toutes les mises à jour à tous les niveaux. Lorsqu’une mise à jour souhaitée devient disponible, vous devez tester la mise à jour dans un environnement de pré-production et évaluer sa compatibilité sur un nouveau cluster. Ensuite, une réplique de production est déployée, incluant la version mise à jour d’AKS et les VHD des pools de nœuds. Lorsque le nouveau cluster de production est prêt, l’ancien cluster est vidé et finalement mis hors service.
L’infrastructure immuable avec des déploiements réguliers de nouvelles infrastructures est la seule situation dans laquelle une stratégie de mise à niveau en place ne doit pas être appliquée à un cluster de production. 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 comme une infrastructure immuable doivent régulièrement mettre à jour leurs clusters en cours d’exécution, en adressant les trois niveaux. 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.
- Utilisez la fonctionnalité de maintenance planifiée d’AKS pour programmer et contrôler les mises à jour sur votre cluster. Cette fonctionnalité vous permet d’effectuer ces mises à jour, une opération intrinsèquement risquée, à un moment contrôlé pour réduire l’impact d’une défaillance inattendue.
- Configurez les budgets de perturbation des pods de sorte que votre application reste stable pendant les mises à jour progressives. Cependant, ne configurez pas les budgets de manière trop agressive au point de bloquer les mises à niveau des nœuds, car la plupart des mises à niveau nécessitent un processus de cordon et de vidage sur chaque nœud.
- Validez le quota de ressources Azure et la disponibilité des ressources. Les mises à niveau en place déploient de nouvelles instances de nœuds (connues sous le nom de nœuds de surcharge) 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é ajoutés à votre cluster) et les composants de votre charge de travail (tels que les contrôleurs d’entrée, les maillages de services et les pods de votre charge de travail) dans un environnement de pré-production.
Mises à niveau en place pour les nœuds
Utilisez le canal de mise à niveau automatique NodeImage
pour les mises à niveau des images de système d’exploitation des nœuds. Ce canal configure votre cluster pour mettre à jour le VHD sur chaque nœud avec des mises à jour au niveau du nœud qui sont testées par Microsoft par rapport à votre version AKS. Pour les nœuds Windows, ces mises à jour sont effectuées environ une fois par mois. Pour les nœuds Linux, ces mises à jour se produisent environ une fois par semaine.
- Ces mises à niveau ne changent jamais votre version AKS ou Kubernetes, donc la compatibilité de l’API Kubernetes n’est pas une préoccupation avec ces mises à niveau.
- Utiliser
NodeImage
comme canal de mise à niveau respecte votre fenêtre de maintenance planifiée, qui doit être définie au moins une fois par semaine, quel que soit le système d’exploitation de l’image du nœud, pour assurer une application en temps opportun. - Ces mises à jour incluent 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 des composants AKS.
- Les versions des images et leurs numéros de version de composant inclus peuvent être suivis à l’aide du suivi des versions AKS.
Si les exigences de sécurité de votre cluster nécessitent une cadence de correctifs plus agressive et que votre cluster peut tolérer les interruptions potentielles, utilisez alors le canal de mise à niveau SecurityPatch
à la place. Ces mises à jour sont également testées par Microsoft, et elles ne sont publiées que s’il y a des mises à jour de sécurité que Microsoft a jugé suffisamment importantes pour accélérer la publication avant la prochaine mise à niveau programmée de l’image du nœud. Lorsque vous utilisez le canal SecurityPatch
, vous recevrez également les mises à jour que le canal NodeImage
a reçues. L’option du canal SecurityPatch
respecte toujours vos fenêtres de maintenance, alors assurez-vous que votre fenêtre de maintenance a des intervalles plus fréquents (comme quotidiennement ou tous les deux jours) pour prendre en charge ces mises à jour de sécurité inattendues.
La plupart des clusters effectuant des mises à niveau en place devraient éviter les options de canal de mise à niveau d’image de nœud None
et Unmanaged
.
Mises à jour en place du cluster
Kubernetes est une plateforme en évolution rapide, et les mises à jour régulières apportent des correctifs de sécurité importants ainsi que de nouvelles fonctionnalités. Il est important de rester à jour avec les mises à jour de Kubernetes. Vous devriez rester dans les deux versions les plus récentes (N-2). La mise à niveau vers la dernière version de Kubernetes est essentielle, car de nouvelles versions sont fréquemment publiées.
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 de réaliser une mise à niveau en place de la version AKS peut être principalement atténué par des tests suffisants en pré-production, une validation des quotas et une configuration des budgets de perturbation des pods. Cependant, toute mise à niveau en place peut avoir un comportement inattendu. Si les mises à niveau en place sont jugées trop risquées pour votre charge de travail, nous vous recommandons d’utiliser une approche de déploiement Blue-green de clusters AKS au lieu de suivre les recommandations restantes.
Nous recommandons d’éviter la fonctionnalité de mise à niveau automatique du cluster lorsque vous déployez un cluster Kubernetes pour la première fois. Utilisez une approche manuelle, qui vous donne le temps de tester une nouvelle version du 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. Cependant, vous devez être diligent quant à la surveillance des nouvelles mises à jour de la plateforme Kubernetes et à l’adoption rapide des nouvelles versions lorsqu’elles sont publiées. Il est préférable d’adopter une mentalité de « rester à jour » plutôt qu’une approche de support à long terme (LTS).
Avertissement
Nous ne recommandons pas de corriger ou de mettre automatiquement à jour un cluster AKS de production, même avec des mises à jour mineures, à moins que ces mises à jour n’aient été testées dans vos environnements inférieurs au préalable. Pour plus d’informations, consultez Effectuer des mises à jour régulières vers la dernière version de Kubernetes et Mettre à niveau un cluster Azure Kubernetes Service (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. Examinez également les notes de version AKS pour des préoccupations spécifiques de compatibilité, des changements de comportement ou des dépréciations de fonctionnalités.
Vous pourriez finalement atteindre un niveau 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
. De plus, avec la mise à niveau automatique de votre version AKS, soyez conscient du paramètre de version AKS de votre infrastructure en tant que code pour le cluster AKS afin qu’ils ne se désynchronisent pas. Configurez votre fenêtre de maintenance planifiée pour prendre en charge cette opération de mise à niveau automatique.
Surveillance de la sécurité
Surveillez votre infrastructure de conteneur pour détecter les menaces actives et les risques de sécurité potentiels :
- Activez Microsoft Defender pour les conteneurs afin d’identifier et d’appliquer les recommandations de Defender pour le cloud relatives à vos images conteneur.
- Microsoft Defender pour les conteneurs analyse régulièrement vos images conteneur à la recherche de vulnérabilités.
- Microsoft Defender pour les conteneurs génère également des alertes de sécurité en temps réel en cas d’activités suspectes.
- Pour plus d’informations sur le durcissement de la sécurité appliqué aux ordinateurs hôtes de machines virtuelles AKS, consultez Durcissement de la sécurité dans le système d’exploitation hôte.
Opérations de cluster et de charge de travail (DevOps)
Voici quelques éléments à prendre en compte. Pour plus d'informations, consultez le pilier Excellence opérationnelle.
Démarrage de cluster
Une fois l’approvisionnement terminé, votre cluster est opérationnel, mais il peut encore vous rester des étapes à effectuer avant le déploiement des charges de travail. Le processus de préparation de votre cluster, appelé « amorçage » (bootstrapping), peut comprendre des actions telles que le déploiement d’images prérequises sur des nœuds de cluster, la création d’espaces de noms et tout ce qui répond aux exigences de votre cas d’usage ou de votre organisation.
Pour réduire l’écart entre un cluster provisionné et un cluster correctement configuré, les opérateurs de cluster doivent réfléchir à quoi ressemblera leur processus d’amorçage unique et préparer les ressources appropriées à l’avance. Par exemple, s’il est important d’exécuter Kured sur chaque nœud avant le déploiement des charges de travail d’application, l’opérateur de cluster doit s’assurer qu’un ACR contenant l’image Kured cible existe avant de provisionner le cluster.
Utilisez l’une des méthodes suivantes pour configurer le processus d’amorçage :
- Extension de cluster GitOps Flux v2
- Pipelines
- Auto-configuration avec un outil comme Flux ou Argo CD
Remarque
Chacune de ces méthodes fonctionne avec n’importe quelle topologie de cluster, mais l’extension de cluster GitOps Flux v2 est recommandée pour les flottes en raison de son uniformité et d’une plus grande facilité de gouvernance à grande échelle. Si vous n’exécutez que quelques clusters, GitOps peut vous sembler trop complexe. Vous pouvez alors opter pour l’intégration de ce 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’extension de cluster GitOps Flux v2 pour AKS est l’absence d’écart entre un cluster provisionné et un cluster amorcé. Elle définit l’environnement avec une base de gestion solide à l’avenir, et elle prend également en charge l’inclusion de ce démarrage en tant que modèles de ressources pour s’aligner sur votre stratégie IaC.
Enfin, lors de l’utilisation de l’extension, kubectl
n’est requis pour aucune partie du processus d’amorçage et l’accès basé sur kubectl
peut être réservé aux situations d’urgence couvertes par la garantie. Entre les modèles pour les définitions de ressources Azure et l'amorçage des manifestes via l'extension GitOps, toutes les activités de configuration normales peuvent être effectuées 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. La première tâche consiste à configurer la mise en réseau. Approvisionnez des réseaux virtuels hub-and-spoke et des sous-réseaux au sein de ces réseaux. Par exemple, le spoke dispose de sous-réseaux distincts pour les pools de nœuds système et utilisateur, et de ressources d’entrée. Déployez un sous-réseau pour la pare-feu Azure dans le hub.
Une autre partie peut consister à intégrer la charge de travail de base à Microsoft Entra ID.
Utiliser l'infrastructure en tant que code (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. Une option consiste à utiliser les modèles de Bicep ou d'Azure Resource Manager. Une autre est Terraform.
Veillez à configurer les ressources en fonction des stratégies de gouvernance. Par exemple, lorsque vous sélectionnez la taille des machines virtuelles, restez dans les limites des contraintes de coût et des options de zone de disponibilité pour correspondre aux exigences de votre application. Vous pouvez également utiliser Azure Policy pour appliquer les stratégies de votre organisation pour ces décisions.
Si vous devez écrire une séquence de commandes, utilisez Azure CLI. Ces commandes couvrent un éventail de services Azure et peuvent être automatisées par le biais de scripts. Azure CLI est pris en charge sur Windows et Linux. Azure PowerShell constitue une autre option multiplateforme. Votre choix dépendra de l'ensemble de vos compétences.
Stockez et gérez les fichiers de version et de modèle dans votre système de contrôle de code source.
Charge de travail - CI/CD
Les pipelines de workflow et de déploiement doivent pouvoir créer et déployer des applications en continu. Les mises à jour doivent être déployées en toute sécurité et rapidement, puis restaurées en cas de problème.
Votre stratégie de déploiement doit inclure un pipeline de livraison continue automatisé (CD) fiable. Les modifications apportées à vos images de conteneur de charge de travail doivent être déployées automatiquement sur le cluster.
Dans cette architecture, nous avons choisi GitHub Actions pour gérer le workflow et le déploiement. Il existe d’autres options parmi lesquelles Azure DevOps Services 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 (publication d’une nouvelle version, puis validation de cette dernière avant déploiement en production, par exemple), envisagez un flux GitOps.
L’un des éléments essentiels du flux CI/CD est l’amorçage d’un cluster nouvellement provisionné. Une approche GitOps est utile à cette fin, car elle permet aux opérateurs de définir de manière déclarative le processus d’amorçage 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 ces modifications sont déployées.
Voici un exemple montrant 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 parallèlement à 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 modifications apportées à la configuration et les applique à l’aide de commandes kubectl.
Les développeurs n’accèdent pas directement à l’API Kubernetes via kubectl.
Dotez-vous de stratégies de branche sur votre serveur Git. Ainsi, plusieurs développeurs peuvent approuver une modification via une demande de tirage (pull request) avant son application en production.
Bien que GitOps et Flux puissent être configurés manuellement, l’extension de cluster GitOps avec Flux v2 est recommandée pour AKS.
Stratégies de déploiement de charge de travail et de cluster
Déployez toute modification (composants d’architecture, charge de travail, configuration de cluster) dans 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/validations à chaque étape avant de passer à la suivante pour vous assurer que vous êtes en mesure de transmettre des mises à jour à l’environnement de production de manière hautement contrôlée et de réduire les interruptions liées à des problèmes de déploiement imprévus. Ce déploiement doit suivre un modèle similaire à celui de production et utiliser les mêmes pipelines GitHub Actions ou opérateurs Flux.
Les techniques de déploiement avancées, telles que le déploiement Blue-Green, les tests A/B et les versions Canary requièrent un processus, voire des outils supplémentaires. Flagger est une solution open source qui facilite la résolution de vos scénarios de déploiement avancés.
la gestion des coûts ;
Commencez par passer en revue la liste de contrôle de conception de l’optimisation des coûts et la liste des recommandations décrites dans le Well Architected Framework pour AKS. Utilisez la calculatrice de prix Azure pour estimer les coûts des services utilisés dans l’architecture. D’autres meilleures pratiques sont décrites dans la section Optimisation des coûts de Microsoft Azure Well-Architected Framework.
Envisagez d’activer l’analyse des coûts AKS pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.
Pour passer en revue les considérations relatives à la gestion des coûts spécifiques aux charges de travail Windows incluses dans les conteneurs Windows sur une architecture de référence de ligne de base AKS, consultez l’article complémentaire.
Provisionner
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. Le coût est influencé par les instances de machine virtuelle, 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 référence SKU DS2_v2 est un type de machine virtuelle classique 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.
Pour les charges de travail de production, ajoutez un Contrat SLA de durée de fonctionnement. Il est cependant possible de réaliser des économies sur les clusters conçus pour les charges de travail dev/test ou expérimentales ne nécessitant pas de garantie en matière de disponibilité. Par exemple, le SLO est suffisant. En outre, si votre charge de travail les prend en charge, envisagez d’utiliser des pools de nœuds Spot dédiés exécutant des machines virtuelles Spot.
Pour les charges de travail hors production incluant Azure SQL Database ou Azure App Service dans le cadre de l’architecture de charge de travail AKS, voyez si vous êtes éligible pour utiliser les abonnements de développement/test Azureafin de bénéficier de remises sur les services.
Plutôt que d’utiliser un cluster trop grand pour répondre aux besoins de mise à l’échelle, configurez un cluster avec un nombre minimal de nœuds et activez la mise à l’échelle automatique de ce cluster pour surveiller et orienter les décisions de dimensionnement.
Définissez les demandes et les limites de pod de manière à autoriser Kubernetes à allouer des ressources de nœud avec une densité plus élevée afin d’adapter le matériel à la capacité.
L’activation des diagnostics sur le cluster peut en augmenter le coût.
Si votre charge de travail est censée exister pendant une longue période, vous pouvez vous engager sur des instances de machines virtuelles réservées d'une durée d'un ou trois ans pour réduire les coûts des nœuds. Pour plus d’informations, consultez Machines virtuelles réservées.
Utilisez des balises lorsque vous créez des pools de nœuds. Les balises sont utiles pour créer des rapports personnalisés et suivre les coûts engagés. Les balises permettent de suivre l’intégralité des dépenses et de mapper les coûts à 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.
Si votre charge de travail est multirégionale et que vous répliquez des données entre les régions, attendez-vous à des coûts de bande passante supplémentaires si vous répliquez entre les régions. Pour plus d’informations, consultez Tarification de la bande passante.
Créez des budgets pour respecter les contraintes de coût identifiées par l’organisation. Pour ce faire, 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, ainsi que les coûts de calcul, de stockage, de bande passante, de pare-feu et de journaux. Azure propose différents tableaux de bord permettant de surveiller et d’analyser les coûts :
Idéalement, surveillez le coût en temps réel ou du moins régulièrement afin d’agir avant la fin du mois, lorsque les coûts sont déjà calculés. Surveillez également la tendance mensuelle au fil du temps pour ne pas dépasser le budget.
Pour prendre des décisions fondées sur des données, déterminez avec précision quelle ressource (à un niveau granulaire) est la plus coûteuse. Veillez également à bien comprendre les compteurs utilisés pour calculer l’utilisation de chaque ressource. 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 de cluster pour détecter et supprimer les nœuds sous-utilisés dans le pool de nœuds.
Important
La modification intensive des paramètres de mise à l’échelle automatique du cluster (par exemple, les paramètres de nœud min/max pour un pool de nœuds) pour des raisons financières 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 de nœud min/max sont modifiés toutes les cinq minutes en fonction des caractéristiques de la charge de travail, le nombre de nœuds ne $$$cessera jamais de fonctionner. Cela est dû au fait que le calcul des heures non nécessaires pour chaque nœud sera réinitialisé en raison de l'actualisation des paramètres de mise à l’échelle automatique du 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, mettez à l’échelle vos pools de nœuds utilisateur sur 0 nœud quand ils ne sont pas susceptibles de s’exécuter. Par ailleurs, si aucune charge de travail n’est planifiée pour être exécutée dans votre cluster, envisagez d’utiliser la fonctionnalité de démarrage/arrêt d’AKS pour arrêter tout le calcul, ce qui inclut votre pool de nœuds système et le plan de contrôle AKS.
Pour plus d’informations sur les coûts, consultez Tarification AKS.
Étapes suivantes
Continuez à découvrir l’architecture de référence AKS :
- Pour en savoir plus sur l'hébergement de microservices dans l'architecture de référence AKS, consultez Architecture avancée de microservices AKS (Azure Kubernetes Service).
- Pour déployer la base de référence AKS dans plusieurs régions, consultez Base de référence AKS pour les clusters multirégions.
- Pour déployer la base de référence AKS dans un environnement PCI-DSS 3.2.1, consultez Cluster régulé par AKS pour PCI-DSS 3.2.1.
- Si vous souhaitez en savoir plus sur les considérations relatives à l’ajout de conteneurs Windows à l’architecture de référence, consultez l’article complémentaire : Conteneurs Windows sur l’architecture de référence de ligne de base AKS
En savoir plus sur AKS
- Pour consulter la feuille de route du produit AKS, consultez la feuille de route publique d'Azure Kubernetes Service sur GitHub.
- Si vous avez besoin d’un rappel concernant Kubernetes, suivez les parcours d’apprentissage Introduction à Kubernetes et Développer et déployer des applications sur Kubernetes.
Ressources associées
Consultez les guides associés suivants :
- Révision d’Azure Well-Architected Framework pour Azure Kubernetes Service (AKS)
- L’accélérateur de zone d’atterrissage AKS, qui est une implémentation à l’échelle de l’entreprise basée sur cette architecture. L'accélérateur vous aide à configurer votre environnement Azure de manière cohérente et reproductible à l'aide d'Infrastructure-As-Code (IaC) pour un déploiement d'Azure Kubernetes Service (AKS).
- Guide des opérations Jour 2 Azure Kubernetes Service (AKS)
Consultez les architectures associées suivantes :