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

Azure Application Gateway
Azure Container Registry
Pare-feu Azure
Azure Kubernetes Service (AKS)
Contrôle d’accès en fonction du rôle Azure

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, mais 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.

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.

Diagramme d’architecture montrant une topologie réseau hub-and-spoke.

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é. Un hub contient toujours un Pare-feu Azure avec des stratégies de pare-feu globales définies par vos équipes informatiques centrales afin d’appliquer une stratégie de pare-feu à l’échelle de l’organisation, Azure Bastion, un sous-réseau de passerelle pour la connectivité VPN et Azure Monitor pour l’observabilité 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 peut communiquer avec un service tiers malveillant susceptible d’exfiltrer des données d’entreprise sensibles. 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 des stratégies Pare-feu Azure pour ce type d’architecture réseau 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.

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

Diagramme montrant la topologie de réseau du cluster AKS.

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.

  • Mettre à 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.

    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. Pour plusieurs charges de travail, vous souhaiterez peut-être isoler les pools de nœuds utilisateur les uns des autres et du pool de nœuds système. 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 chaque fonctionnalité d’évaluation ou module complémentaire, mais uniquement ceux qui ajoutent une valeur significative à un cluster à usage général. À 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.

  • 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 managées pour permettre au cluster d’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 primaires sont utilisées par le cluster, l’identité du cluster et l’identité Kubelet. L’identité du cluster est utilisée par les composants du plan de contrôle AKS pour gérer les ressources du cluster, notamment les équilibreurs de charge d’entrée, les adresses IP publiques gérées par AKS, etc. L’identité Kubelet est utilisée pour l’authentification avec 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. L’une des méthodes consiste à stocker ces informations sous forme d’objet Secrets Kubernetes et d’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 ou ClusterRole 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 ou CluserRoleBinding.

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ôle peuvent même être ajoutées aux étendues de l’abonnement ou du groupe de ressources afin que tous les clusters au sein de l’étendue héritent d’un ensemble cohérent d’attributions de rôle respectant les personnes autorisées à 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é. Il est basé sur un certificat et s’effectue à l’extérieur de votre fournisseur d’identité principal, ce qui rend difficile la gouvernance et le contrôle d’accès utilisateur centralisé. 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 Workload ID, consultez la vue d’ensemble suivante.

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 les réplicas sur le même nœud afin de répartir la charge et de garantir la continuité des activités en cas de défaillance d’un nœud. Pour ce faire, utilisez podAntiAffinity.

  • Limitez la planification des pods sur le seul pool de nœuds utilisateur à l’aide de nodeSelectors. Ce paramètre 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 et livenessProbe 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 importante encore est l’aptitude à répondre à vos attentes en matière de SLO.

Traefik est une option open source très répandue pour un cluster Kubernetes et c’est celle qui a été choisie 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, tlset 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.

Diagramme montrant un flux de trafic de cluster.

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 correspond à la version minimale autorisée avec un ensemble restreint de chiffrements. L’Indication du nom du serveur (SNI) strict 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.

Diagramme montrant une terminaison TLS.

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

  1. 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é.

  2. 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.

  3. À mesure que le trafic se déplace entre Application Gateway et le back-end, il est rechiffré à l’aide d’un autre certificat TLS (générique pour *.aks-ingress.contoso.com), car il est transféré 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.

  4. Le contrôleur d’entrée reçoit le trafic chiffré via l’équilibreur de charge. Le contrôleur constitue un autre point de terminaison TLS pour *.aks-ingress.contoso.com et transfère le trafic vers les pods 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 vous recommandons de transmettre tout le trafic sortant du cluster via Pare-feu Azure ou votre propre appliance virtuelle réseau similaire, via d’autres options telles que la passerelle NAT ou le proxy HTTP. 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, consultez 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.

Notes

AKS prend en charge les modèles réseau kubenet, Azure Container Networking Interface (CNI) et superposition Azure CNI. 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. 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. 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. Azure CNI offre également un contrôle de la sécurité amélioré en permettant l’utilisation de la Stratégie réseau Azure. Il est recommandé d’utiliser la superposition Azure CNI pour les déploiements aux adresses IP limitées, qui allouent uniquement des adresses IP à partir du ou des sous-réseaux du pool de nœuds pour les nœuds et utilisent une couche de superposition hautement optimisée pour les adresses IP de pod. Un modèle réseau basé sur CNI est recommandé.

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. À titre d’exemple, ces ressources incluent le pool d’agents de build d’un pipeline DevOps, un 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 d’API et vos pools de nœuds reste sur le réseau privé uniquement. Il n’est pas exposé sur 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 modifications apportées aux stratégies ne sont pas immédiatement reflétées dans votre cluster, attendez-vous à voir certains 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 d’affectation de noms, 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 permet de spécifier des espaces de noms Kubernetes qui sont dispensés de l’application des stratégies. Nous vous recommandons de continuer d’appliquer des stratégies en mode Audit de façon à avoir connaissance 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.

Les vérifications (HPA) peuvent parfois intervenir avant la fin d’une opération de mise à l’échelle, ce qui constitue une condition de concurrence. 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 trouverez la liste des scalers KEDA pris en charge ici,notamment le scaler Azure Monitor qui permet de mettre à l’échelle les charges de travail KEDA en fonction des métriques 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 assurer la continuité des activités, définissez le Contrat de niveau de service pour l’infrastructure et votre application. Pour plus d’informations sur le calcul du temps d’activité mensuel, consultez SLA pour Azure Kubernetes Service (AKS).

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 teintes est recommandée pour identifier le pool de nœuds afin de planifier votre charge de travail, et pour vous assurer que votre pool de nœuds système est teinté avec CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

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

Vérifier les ressources de pod. 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é est largement dépréciée 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. La définition de ces limites permet à Kubernetes d’allouer efficacement les ressources processeur et/ou mémoire aux pods, et de disposer d’une densité de conteneur supérieure sur un nœud. Les limites permettent également d’accroître la fiabilité en réduisant les coûts moyennant une meilleure utilisation du matériel.

Pour estimer les limites, testez et établissez une ligne de base. 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.

Ces 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

Si votre contrat SLA requiert une durée de bon fonctionnement plus élevée, protégez-vous contre les pannes à l’aide de zones de disponibilité. Vous pouvez 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. Si vous souhaitez acheter un Contrat SLA de durée de fonctionnement, optez pour une région qui prend en charge cette option. Le contrat SLA de durée de fonctionnement est plus intéressant lors de l’utilisation de 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 suffit pas en cas de défaillance de la région entière. Pour une plus haute disponibilité, exécutez plusieurs clusters AKS dans différentes régions.

  • Utilisez des régions jumelées. Envisagez d’utiliser un pipeline CI/CD configuré pour utiliser une région jumelée à des fins de récupération en cas de défaillances de région. L’utilisation de régions jumelées présente un avantage en matière de fiabilité lors des mises à jour. Azure veille à ce qu’une seule région de la paire soit mise à jour à la fois. Certains outils DevOps tels que Flux facilitent les déploiements multirégions.

  • Si une ressource Azure prend en charge la géoredondance, indiquez l’emplacement du serveur secondaire du service redondant. Par exemple, l’activation de la géoréplication pour Azure Container Registry réplique automatiquement les images vers les régions Azure sélectionnées, et fournit un accès continu aux images même en cas de défaillance d’une région.

  • 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.

GitHub logoUne 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 des régions jumelées.

  • 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.

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}(#cluster-bootstrapping) 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 n’implémente pas la sauvegarde, ce qui implique des ressources Azure supplémentaires dans l’architecture pour gérer, surveiller, payer et sécuriser : par exemple, un compte de stockage Azure, une configuration de coffre Sauvegarde Azure et un Accès approuvé. GitOps combiné avec l’intention d’exécuter une charge de travail sans état est la solution de récupération implémentée.

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 ce contrat SLA, vous devez choisir un Niveau Standard. Nous recommandons d’utiliser le niveau Standard pour tous les clusters de production. Réservez des clusters de niveau Gratuit pour les clusters de préproduction. Associé aux zones de disponibilité Azure, le Contrat de niveau de service du serveur d’API Kubernetes passe à 99,95%. Vos pools de nœuds, entre autres ressources, sont couverts par leur propre Contrat de niveau de service.

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. Le coût augmente également en raison des frais de bande passante qui s’appliquent lorsque le trafic transite entre les zones et régions.

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’existe aucune raison d’activer KubeAudit et KubeAuditAdmin, car KubeAudit est également un super-ensemble de KubeAuditAdmin qui inclut également des opérations non modifiables (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 vous aide à activer une observabilité supplémentaire dans l’intégrité et les performances de vos clusters AKS, et à prendre en charge vos objectifs de niveau de service (SLA).

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.

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. La probe Liveness détermine si le pod est sain. S’il ne répond pas, Kubernetes le redémarre. La probe Readiness détermine si le pod est prêt à recevoir des demandes / du trafic.

Notes

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 clusters AKS

Définir une stratégie de mise à jour cohérente avec les exigences commerciales est primordial. Comprendre le niveau de prévisibilité de la date et de l’heure des mises à jour de la version du cluster AKS ou de ses nœuds, et le degré de contrôle souhaité sur les images ou binaires spécifiques à installer sont des aspects fondamentaux qui délimiteront votre plan de mise à jour de cluster AKS. La prévisibilité est liée à deux principales propriétés de mise à jour de cluster AKS qui sont la cadence de mise à jour et la fenêtre de maintenance. Le contrôle concerne le fait que les mises à jour soient installées manuellement ou automatiquement. Les organisations avec des clusters AKS qui ne sont pas sous une régulation de sécurité stricte pourraient envisager des mises à jour hebdomadaires ou même mensuelles, tandis que le reste doit mettre à jour les correctifs étiquetés de sécurité dès qu’ils sont disponibles (quotidiennement). Les organisations qui exploitent des clusters AKS comme une infrastructure immuable ne les mettent pas à jour. Cela signifie, aucune mise à jour automatique ou manuelle n’est effectuée. Au lieu de cela, lorsqu’une mise à jour souhaitée devient disponible, une empreinte de réplica est déployé et seulement lorsque la nouvelle instance d’infrastructure est prête, l’ancienne est vidée, leur donnant le plus haut niveau de contrôle.

Une fois le plan de mise à jour du cluster AKS déterminé, cela peut être facilement mappé sur les options de mise à jour disponibles pour les nœuds AKS et la version du cluster AKS :

  • Nœuds AKS :

    1. Aucune/Mises à jour manuelles : Ceci est pour une infrastructure immuable ou lorsque les mises à jour manuelles sont préférées. Cela permet d’atteindre une plus grande prévisibilité et un contrôle sur les mises à jour des nœuds AKS.
    2. Mises à jour automatiques non surveillées : AKS exécute des mises à jour natives du système d’exploitation. Cela donne de la prévisibilité en configurant des fenêtres de maintenance alignées avec ce qui est bon pour l’entreprise. Cela peut être basé sur les heures de pointe et ce qui est le mieux en termes d’opérations. Le niveau de contrôle est faible puisqu’il n’est pas possible de savoir à l’avance ce qui va être spécifiquement installé dans le nœud AKS.
    3. Mises à jour automatiques de l’image des nœuds : Il est recommandé de mettre à jour automatiquement les images des nœuds AKS lorsque de nouveaux disques durs virtuels (VHD) deviennent disponibles. Concevez des fenêtres de maintenance alignées autant que possible avec les besoins de l’entreprise. Pour les mises à jour de VHD étiquetées de sécurité, il est recommandé de configurer une fenêtre de maintenance quotidienne offrant la plus faible prévisibilité. Les mises à jour régulières de VHD peuvent être configurées avec une fenêtre de maintenance hebdomadaire, toutes les deux semaines ou même mensuellement. Selon que le besoin est pour des VHD étiquetées de sécurité vs des VHD régulières combinées avec la fenêtre de maintenance programmée, la prévisibilité fluctue offrant plus ou moins de flexibilité pour être alignée avec les exigences commerciales. Bien que laisser cela toujours aux exigences commerciales serait idéal, la réalité oblige les organisations à trouver le point d’équilibre. Le niveau de contrôle est faible puisqu’il n’est pas possible de savoir à l’avance quels binaires spécifiques ont été inclus dans un nouveau VHD et pourtant ce type de mises à jour automatiques est l’option recommandée puisque les images sont vérifiées avant de devenir disponibles.

    Remarque

    Pour plus d’informations sur la façon de configurer les mises à jour automatiques des nœuds AKS, veuillez consulter la rubrique Mise à jour automatique des images du système d’exploitation des nœuds.

  • Version du cluster AKS :

    1. Aucune/Mises à jour manuelles : Ceci est pour une infrastructure immuable ou lorsque les mises à jour manuelles sont préférées. Cela permet d’atteindre une plus grande prévisibilité et un contrôle sur les mises à jour de la version du cluster AKS. Cette option est recommandée, puisque cela laisse le plein contrôle en donnant la chance de tester une nouvelle version du cluster AKS (par exemple, de 1.14.x à 1.15.x) dans des environnements inférieurs avant de toucher à la production.
    2. Mises à jour automatiques : Il n’est pas recommandé qu’un cluster de production soit automatiquement corrigé ou mis à jour de quelque manière que ce soit (par exemple, de 1.16.x à 1.16.y) vers une nouvelle version du cluster AKS disponible sans avoir été correctement testé dans des environnements inférieurs. Bien que les sorties en amont de Kubernetes et les mises à jour de la version du cluster AKS soient coordonnées fournissant une cadence régulière, la recommandation est encore d’être défensif avec les clusters AKS en production augmentant la prévisibilité et le contrôle sur le processus de mise à jour. Contre considérez cette configuration pour les environnements inférieurs comme partie de l’Excellence Opérationnelle, permettant des exécutions de tests de routine proactives pour détecter les problèmes potentiels le plus tôt possible.

Maintenez la version Kubernetes à jour avec les versions N-2 prises en charge. La mise à niveau vers la dernière version de Kubernetes est essentielle, car de nouvelles versions sont fréquemment publiées.

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).

La notification d’événements déclenchés par votre cluster, par exemple la disponibilité d’une nouvelle version d’AKS pour votre cluster, peut être obtenue via la rubrique système AKS pour Azure Event Grid. L’implémentation de référence déploie cette rubrique système Event Grid pour vous permettre de vous abonner à l’événement Microsoft.ContainerService.NewKubernetesVersionAvailable à partir de votre solution de notification de flux d’événements.

Mises à jour hebdomadaires

AKS fournit de nouvelles images de nœud avec les dernières mises à jour du système d’exploitation et du CLR. Ces nouvelles images ne sont pas appliquées automatiquement. Vous êtes chargé de déterminer la fréquence à laquelle les images doivent être mises à jour. Il est recommandé de disposer d’un processus de mise à niveau hebdomadaire de l’image de base de vos pools de nœuds. Pour plus d’informations, consultez mise à niveau d’image de nœud Azure Kubernetes Service (AKS) les notes de publication de AKS.

Mises à jour quotidiennes

Entre les mises à niveau d’images, les nœuds AKS téléchargent et installent les correctifs du système d’exploitation et du CLR, individuellement. Une installation peut nécessiter le redémarrage des machines virtuelles de nœud. AKS ne redémarre pas les nœuds en raison de mises à jour en attente. Disposer d’un processus qui surveille les nœuds pour les mises à jour appliquées qui nécessitent un redémarrage et effectue le redémarrage de ces nœuds de manière contrôlée. Kured (démon de redémarrage Kubernetes) constitue une option open source.

Le maintien de la synchronisation de vos images de nœud avec la dernière version hebdomadaire réduit les demandes de redémarrage occasionnelles tout en conservant une position de sécurité renforcée. Le fait de s’appuyer uniquement sur les mises à niveau d’image de nœud garantit la compatibilité AKS et les correctifs de sécurité hebdomadaires. Tandis que l’application de mises à jour quotidiennes résoudra plus rapidement les problèmes de sécurité, ils n’ont pas été testés dans AKS. Dans la mesure du possible, utilisez la mise à niveau d’image de nœud comme stratégie de correctif de sécurité hebdomadaire principale.

Surveillance de la sécurité

Surveillez votre infrastructure de conteneur pour détecter les menaces actives et les risques de sécurité potentiels :

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 :

Notes

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. Un sous-réseau pour le 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 est un modèle Azure Resource Manager (ARM). Une autre est Terraform.

Veillez à configurer les ressources en fonction des stratégies de gouvernance. Par exemple, lors de la sélection des tailles de machines virtuelles appropriées, respectez les contraintes de coût, les options de zone de disponibilité pour répondre aux besoins de votre application.

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épend de l’ensemble de compétences que vous souhaitez.

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

Diagramme montrant une charge de travail 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.

Lors de l’utilisation de 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 dépôt 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 :

Diagramme montrant le flux GitOps.

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

  1. Un développeur valide les modifications apportées au code source, telles que les fichiers de configuration YAML, qui sont stockées dans un référentiel Git. Les modifications sont ensuite transmises à un serveur Git.

  2. Flux s’exécute dans un pod parallèlement à la charge de travail. Flux dispose d’un accès en lecture seule au référentiel Git afin d’appliquer uniquement les modifications demandées par les développeurs.

  3. Flux reconnaît les modifications apportées à la configuration et les applique à l’aide de commandes kubectl.

  4. Les développeurs n’accèdent pas directement à l’API Kubernetes via kubectl.

  5. 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. Vous pourrez ainsi simuler la modification et identifier d’éventuels problèmes avant le déploiement 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

  • Aucun coût n'est associé à AKS au niveau du déploiement, de la gestion et des opérations du cluster Kubernetes. 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 prévue pour durer, vous pouvez opter pour Reserved Virtual Machine Instances pour un ou trois ans afin de 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.

  • Les transferts de données entre les zones de disponibilité d’une région sont payants. Dans le cas d’une charge de travail multirégion ou en présence de transferts entre zones de disponibilité, attendez-vous à un coût de bande passante supplémentaire. Pour plus d’informations, consultez Trafic entre zones et régions de facturation.

  • 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 d’Azure 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.

Superviser

Pour surveiller le coût du cluster dans son intégralité, ainsi que le coût de calcul, collectez également les informations sur les coûts 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 pilotées par les données, identifiez la ressource (niveau granulaire) la plus coûteuse. Veillez également à bien comprendre les compteurs utilisés pour calculer l’utilisation de chaque ressource. En analysant les métriques, vous pouvez déterminer si la plateforme est surdimensionnée par rapport à l’instance. 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.

  • 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 :

En savoir plus sur AKS

Consultez les guides associés suivants :

Consultez les architectures associées suivantes :