Concepts - Bases de Kubernetes pour Azure Kubernetes Services (AKS) - Azure Kubernetes Service (2023)

Le développement d'applications continue d'évoluer vers une approche basée sur les conteneurs, ce qui augmente notre besoin d'orchestrer et de gérer les ressources. En tant que plate-forme leader, Kubernetes fournit une planification fiable des charges de travail des applications tolérantes aux pannes. Azure Kubernetes Service (AKS), une offre Kubernetes gérée, simplifie encore le déploiement et la gestion des applications basées sur des conteneurs.

Cet article présente :

• Composants de base de l'infrastructure Kubernetes :
  • avion de contrôle
  • nœuds
  • pools de nœuds
• Ressources de charge de travail :
  • gousses
  • déploiements
  • ensembles
• Comment regrouper des ressources dansespaces de noms.

Qu'est-ce que Kubernetes ?

Kubernetes est une plate-forme en évolution rapide qui gère les applications basées sur des conteneurs et leurs composants de mise en réseau et de stockage associés. Kubernetes se concentre sur les charges de travail des applications, et non sur les composants d'infrastructure sous-jacents. Kubernetes fournit une approche déclarative des déploiements, soutenue par un ensemble robuste d'API pour les opérations de gestion.

Vous pouvez créer et exécuter des applications modernes, portables et basées sur des microservices, en utilisant Kubernetes pour orchestrer et gérer la disponibilité des composants de l'application. Kubernetes prend en charge les applications sans état et avec état à mesure que les équipes progressent dans l'adoption d'applications basées sur des microservices.

En tant que plate-forme ouverte, Kubernetes vous permet de créer vos applications avec votre langage de programmation, système d'exploitation, bibliothèques ou bus de messagerie préféré. Les outils d'intégration continue et de livraison continue (CI/CD) existants peuvent s'intégrer à Kubernetes pour planifier et déployer des versions.

AKS fournit un service Kubernetes géré qui réduit la complexité des tâches de déploiement et de gestion de base, comme la coordination des mises à niveau. La plateforme Azure gère le plan de contrôle AKS et vous ne payez que pour les nœuds AKS qui exécutent vos applications.

Architecture de cluster Kubernetes

Un cluster Kubernetes est divisé en deux composants :

• Avion de contrôle: fournit les principaux services Kubernetes et l'orchestration des charges de travail des applications.
• Nœuds: exécutez vos charges de travail d'application.

Avion de contrôle

Lorsque vous créez un cluster AKS, un plan de contrôle est automatiquement créé et configuré. Ce plan de contrôle est fourni gratuitement en tant que ressource Azure gérée abstraite de l'utilisateur. Vous ne payez que pour les nœuds attachés au cluster AKS. Le plan de contrôle et ses ressources résident uniquement dans la région où vous avez créé le cluster.

Le plan de contrôle comprend les principaux composants Kubernetes suivants :

AKS fournit un plan de contrôle à locataire unique, avec un serveur d'API dédié, un planificateur, etc. Vous définissez le nombre et la taille des nœuds, et la plateforme Azure configure la communication sécurisée entre le plan de contrôle et les nœuds. L'interaction avec le plan de contrôle se produit via les API Kubernetes, telles quekubectlou le tableau de bord Kubernetes.

Bien que vous n'ayez pas besoin de configurer des composants (comme unetcdstore) avec ce plan de contrôle géré, vous ne pouvez pas accéder directement au plan de contrôle. Les mises à niveau du plan de contrôle et des nœuds Kubernetes sont orchestrées via Azure CLI ou le portail Azure. Pour résoudre les problèmes éventuels, vous pouvez consulter les journaux du plan de contrôle via les journaux Azure Monitor.

Pour configurer ou accéder directement à un plan de contrôle, déployez un cluster Kubernetes autogéré à l'aide deFournisseur d'API de cluster Azure.

Pour les meilleures pratiques associées, voirMeilleures pratiques pour la sécurité des clusters et les mises à niveau dans AKS.

Pour plus d'informations sur la gestion des coûts AKS, voirPrincipes de base des coûts AKSetTarification pour AKS.

Nœuds et pools de nœuds

Pour exécuter vos applications et les services de support, vous avez besoin d'un Kubernetesnœud. Un cluster AKS comporte au moins un nœud, une machine virtuelle (VM) Azure qui exécute les composants du nœud Kubernetes et l'environnement d'exécution du conteneur.

La taille de la machine virtuelle Azure pour vos nœuds définit les processeurs, la mémoire, la taille et le type de stockage disponible (tel qu'un SSD hautes performances ou un disque dur standard). Planifiez la taille du nœud selon que vos applications peuvent nécessiter de grandes quantités de processeur et de mémoire ou un stockage hautes performances. Augmentez le nombre de nœuds dans votre cluster AKS pour répondre à la demande. Pour plus d'informations sur la mise à l'échelle, voirOptions de mise à l'échelle pour les applications dans AKS.

Dans AKS, l'image VM des nœuds de votre cluster est basée sur Ubuntu Linux,Azure Linuxou Windows Server 2019. Lorsque vous créez un cluster AKS ou augmentez le nombre de nœuds, la plateforme Azure crée et configure automatiquement le nombre de machines virtuelles demandé. Les nœuds d'agent sont facturés comme des machines virtuelles standard, de sorte que toute remise sur la taille de la machine virtuelle (y comprisRéservations Azure) sont automatiquement appliqués.

Pour les disques managés, la taille et les performances par défaut du disque seront attribuées en fonction du SKU de VM et du nombre de vCPU sélectionnés. Pour plus d'informations, voirDimensionnement par défaut du disque du système d'exploitation.

Si vous avez besoin d'une configuration et d'un contrôle avancés sur l'environnement d'exécution et le système d'exploitation de votre conteneur de nœud Kubernetes, vous pouvez déployer un cluster autogéré à l'aide deFournisseur d'API de cluster Azure.

Réservations de ressources

AKS utilise des ressources de nœud pour aider le nœud à fonctionner dans le cadre de votre cluster. Cette utilisation peut créer un écart entre les ressources totales de votre nœud et les ressources allouables dans AKS. N'oubliez pas ces informations lors de la définition des demandes et des limites pour les pods déployés par l'utilisateur.

Pour trouver les ressources allouables d'un nœud, exécutez :

nœud de description kubectl [NODE_NAME]

Pour maintenir les performances et les fonctionnalités des nœuds, AKS réserve des ressources sur chaque nœud. À mesure qu'un nœud grandit en ressources, la réservation de ressources augmente en raison d'un besoin accru de gestion des pods déployés par l'utilisateur.

Deux types de ressources sont réservées :

• CPU
  Le CPU réservé dépend du type de nœud et de la configuration du cluster, ce qui peut réduire le CPU allouable en raison de l'exécution de fonctionnalités supplémentaires.

  Cœurs de processeur sur l'hôte	1	2	4	8	16	32	64
  Kube-réservé (millicores)	60	100	140	180	260	420	740

• Mémoire
  La mémoire utilisée par AKS comprend la somme de deux valeurs.

  1. Kubeletdémon
     LeKubeletdémon est installé sur tous les nœuds de l'agent Kubernetes pour gérer la création et la résiliation des conteneurs.

     Par défaut sur AKS,Kubeletdémon a lemémoire.disponible<750Mirègle d'éviction, garantissant qu'un nœud doit toujours avoir au moins 750Mi allouables à tout moment. Lorsqu'un hôte est en dessous de ce seuil de mémoire disponible, leKubeletse déclenchera pour mettre fin à l'un des pods en cours d'exécution et libérer de la mémoire sur la machine hôte.

  2. Un taux dégressif de réservations mémoirepour que le démon kubelet fonctionne correctement (cube réservé).

     • 25% des 4 premiers Go de mémoire
     • 20 % des 4 Go de mémoire suivants (jusqu'à 8 Go)
     • 10 % des 8 Go de mémoire suivants (jusqu'à 16 Go)
     • 6 % des 112 Go de mémoire suivants (jusqu'à 128 Go)
     • 2 % de toute mémoire supérieure à 128 Go

Les règles d'allocation de mémoire et de CPU sont conçues pour effectuer les opérations suivantes :

• Gardez les nœuds d'agent sains, y compris certains pods du système d'hébergement essentiels à la santé du cluster.
• Faire en sorte que le nœud signale moins de mémoire allouable et de processeur qu'il ne le ferait s'il ne faisait pas partie d'un cluster Kubernetes.

Les réservations de ressources ci-dessus ne peuvent pas être modifiées.

Par exemple, si un nœud offre 7 Go, il signalera 34 % de mémoire non allouable, y compris le seuil d'éviction ferme de 750 Mi.

0,75 + (0,25*4) + (0,20*3) = 0,75 Go + 1 Go + 0,6 Go = 2,35 Go / 7 Go = 33,57 % réservés

En plus des réservations pour Kubernetes lui-même, le système d'exploitation du nœud sous-jacent réserve également une quantité de ressources CPU et mémoire pour maintenir les fonctions du système d'exploitation.

Pour les meilleures pratiques associées, voirMeilleures pratiques pour les fonctionnalités de base du planificateur dans AKS.

Groupes de nœuds

Les nœuds d'une même configuration sont regroupés enpools de nœuds. Un cluster Kubernetes contient au moins un pool de nœuds. Le nombre initial de nœuds et la taille sont définis lorsque vous créez un cluster AKS, ce qui crée unpool de nœuds par défaut. Ce pool de nœuds par défaut dans AKS contient les machines virtuelles sous-jacentes qui exécutent vos nœuds d'agent.

Vous mettez à l'échelle ou mettez à niveau un cluster AKS par rapport au pool de nœuds par défaut. Vous pouvez choisir de mettre à l'échelle ou de mettre à niveau un pool de nœuds spécifique. Pour les opérations de mise à niveau, l'exécution des conteneurs est planifiée sur d'autres nœuds du pool de nœuds jusqu'à ce que tous les nœuds soient mis à niveau avec succès.

Pour plus d'informations sur l'utilisation de plusieurs pools de nœuds dans AKS, consultezCréer et gérer plusieurs pools de nœuds pour un cluster dans AKS.

Sélecteurs de nœud

Dans un cluster AKS avec plusieurs pools de nœuds, vous devrez peut-être indiquer au planificateur Kubernetes quel pool de nœuds utiliser pour une ressource donnée. Par exemple, les contrôleurs d'entrée ne doivent pas s'exécuter sur les nœuds Windows Server.

Les sélecteurs de nœud vous permettent de définir divers paramètres, comme le système d'exploitation du nœud, pour contrôler où un pod doit être planifié.

L'exemple de base suivant planifie une instance NGINX sur un nœud Linux à l'aide du sélecteur de nœud"kubernetes.io/os": linux:

genre : PodapiVersion : v1metadata : nom : nginxspec : conteneurs : - nom : image myfrontend : mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine nodeSelector : "kubernetes.io/os": linux

Pour plus d'informations sur la façon de contrôler où les modules sont planifiés, consultezMeilleures pratiques pour les fonctionnalités avancées du planificateur dans AKS.

Groupe de ressources de nœud

Lorsque vous créez un cluster AKS, vous devez spécifier un groupe de ressources dans lequel créer la ressource de cluster. Outre ce groupe de ressources, le fournisseur de ressources AKS crée et gère également un groupe de ressources distinct appelé groupe de ressources de nœud. Legroupe de ressources de nœudcontient les ressources d'infrastructure suivantes :

• Les groupes de machines virtuelles identiques et les machines virtuelles pour chaque nœud dans les pools de nœuds
• Le réseau virtuel du cluster
• Le stockage pour le cluster

Le groupe de ressources de nœud reçoit un nom par défaut, tel queMC_myResourceGroup_myAKSCluster_eastus. Lors de la création du cluster, vous avez également la possibilité de spécifier le nom attribué à votre groupe de ressources de nœud. Lorsque vous supprimez votre cluster AKS, le fournisseur de ressources AKS supprime automatiquement le groupe de ressources de nœud.

Le groupe de ressources de nœud présente les limitations suivantes :

• Vous ne pouvez pas spécifier un groupe de ressources existant pour le groupe de ressources de nœud.
• Vous ne pouvez pas spécifier un autre abonnement pour le groupe de ressources de nœud.
• Vous ne pouvez pas modifier le nom du groupe de ressources de nœud après la création du cluster.
• Vous ne pouvez pas spécifier de noms pour les ressources gérées dans le groupe de ressources de nœud.
• Vous ne pouvez pas modifier ou supprimer les balises créées par Azure des ressources gérées dans le groupe de ressources de nœud.

Si vous modifiez ou supprimez des balises créées par Azure et d'autres propriétés de ressource dans le groupe de ressources de nœud, vous pouvez obtenir des résultats inattendus, tels que des erreurs de mise à l'échelle et de mise à niveau. Comme AKS gère le cycle de vie de l'infrastructure dans le groupe de ressources de nœud, toute modification déplacera votre cluster vers unétat non pris en charge.

Un scénario courant dans lequel les clients souhaitent modifier des ressources consiste à utiliser des balises. AKS vous permet de créer et de modifier des balises qui sont propagées aux ressources du groupe de ressources de nœud, et vous pouvez ajouter ces balises lorsquecréation ou mise à jourla grappe. Vous souhaiterez peut-être créer ou modifier des balises personnalisées, par exemple, pour affecter une unité commerciale ou un centre de coûts. Cela peut également être réalisé en créant des stratégies Azure avec une étendue sur le groupe de ressources gérées.

Modifier toutBalises créées par Azuresur les ressources sous le groupe de ressources de nœud dans le cluster AKS est une action non prise en charge, qui rompt l'objectif de niveau de service (SLO). Pour plus d'informations, voirAKS propose-t-il un contrat de niveau de service ?

Pour réduire le risque de modifications du groupe de ressources de nœud affectant vos clusters, vous pouvez activer le verrouillage du groupe de ressources de nœud pour appliquer une affectation de refus à vos ressources AKS. Plus d'informations peuvent être trouvées dansConfiguration de cluster dans AKS.

Gousses

Kubernetes utilisegoussespour exécuter une instance de votre application. Un pod représente une instance unique de votre application.

Les pods ont généralement un mappage 1:1 avec un conteneur. Dans les scénarios avancés, un pod peut contenir plusieurs conteneurs. Les pods multi-conteneurs sont programmés ensemble sur le même nœud et permettent aux conteneurs de partager des ressources associées.

Lorsque vous créez un module, vous pouvez définirdemandes de ressourcespour demander une certaine quantité de ressources CPU ou mémoire. Le planificateur Kubernetes essaie de répondre à la demande en planifiant les pods pour qu'ils s'exécutent sur un nœud avec des ressources disponibles. Vous pouvez également spécifier des limites maximales de ressources pour empêcher un pod de consommer trop de ressources de calcul du nœud sous-jacent. La meilleure pratique consiste à inclure des limites de ressources pour tous les pods afin d'aider le planificateur Kubernetes à identifier les ressources nécessaires et autorisées.

Pour plus d'informations, voirUn module KubernetesetCycle de vie du pod Kubernetes.

Un pod est une ressource logique, mais les charges de travail d'application s'exécutent sur les conteneurs. Les pods sont généralement des ressources éphémères et jetables. Les pods planifiés individuellement manquent certaines des fonctionnalités de haute disponibilité et de redondance de Kubernetes. Au lieu de cela, les pods sont déployés et gérés par KubernetesContrôleurs, comme le contrôleur de déploiement.

Déploiements et manifestes YAML

UNdéploiementreprésente des pods identiques gérés par le contrôleur de déploiement Kubernetes. Un déploiement définit le nombre de podles répliquescréer. Le planificateur Kubernetes garantit que des pods supplémentaires sont planifiés sur des nœuds sains si des pods ou des nœuds rencontrent des problèmes.

Vous pouvez mettre à jour les déploiements pour modifier la configuration des pods, l'image de conteneur utilisée ou le stockage attaché. Le contrôleur de déploiement :

• Vide et termine un nombre donné de répliques.
• Crée des répliques à partir de la nouvelle définition de déploiement.
• Continue le processus jusqu'à ce que toutes les répliques du déploiement soient mises à jour.

La plupart des applications sans état dans AKS doivent utiliser le modèle de déploiement plutôt que de planifier des pods individuels. Kubernetes peut surveiller la santé et l'état du déploiement pour s'assurer que le nombre requis de réplicas s'exécutent dans le cluster. Lorsqu'ils sont planifiés individuellement, les pods ne sont pas redémarrés s'ils rencontrent un problème et ne sont pas replanifiés sur des nœuds sains si leur nœud actuel rencontre un problème.

Vous ne voulez pas perturber les décisions de gestion avec un processus de mise à jour si votre application nécessite un nombre minimum d'instances disponibles.Budgets de perturbation des podsdéfinir le nombre de répliques d'un déploiement pouvant être supprimées lors d'une mise à jour ou d'une mise à niveau de nœud. Par exemple, si vous avezcinq (5)réplicas dans votre déploiement, vous pouvez définir une interruption de pod de4 (quatre)pour autoriser la suppression ou la reprogrammation d'un seul réplica à la fois. Comme pour les limites de ressources de pod, la meilleure pratique consiste à définir des budgets d'interruption de pod sur les applications qui nécessitent qu'un nombre minimum de répliques soient toujours présentes.

Les déploiements sont généralement créés et gérés aveckubectl créeroukubectl appliquer. Créez un déploiement en définissant un fichier manifeste au format YAML.

L'exemple suivant crée un déploiement de base du serveur Web NGINX. Le déploiement spécifietrois (3)répliques à créer et nécessite un port80être ouvert sur le conteneur. Les demandes de ressources et les limites sont également définies pour le processeur et la mémoire.

apiVersion : apps/v1kind : Deploymentmetadata : nom : nginxspec : répliques : 3 sélecteur : matchLabels : application : modèle nginx : métadonnées : étiquettes : application : spécification nginx : conteneurs : - nom : image nginx : mcr.microsoft.com/oss/nginx /nginx:1.15.2-alpine ports : - containerPort : 80 ressources : requêtes : cpu : 250m mémoire : 64Mi limites : cpu : 500m mémoire : 256Mi

Voici une ventilation des spécifications de déploiement dans le fichier manifeste YAML :

Des applications plus complexes peuvent être créées en incluant des services (tels que des équilibreurs de charge) dans le manifeste YAML.

Pour plus d'informations, voirDéploiements Kubernetes.

Gestion des packages avec Helm

Barreest couramment utilisé pour gérer les applications dans Kubernetes. Vous pouvez déployer des ressources en créant et en utilisant Helm public existantgraphiquesqui contiennent une version packagée du code d'application et des manifestes YAML Kubernetes. Vous pouvez stocker des chartes Helm localement ou dans un référentiel distant, tel qu'unDépôt de charte Azure Container Registry Helm.

Pour utiliser Helm, installez le client Helm sur votre ordinateur ou utilisez le client Helm dans leAzure Cloud Shell. Recherchez ou créez des chartes Helm, puis installez-les sur votre cluster Kubernetes. Pour plus d'informations, voirInstaller des applications existantes avec Helm dans AKS.

StatefulSets et DaemonSets

À l'aide du planificateur Kubernetes, le contrôleur de déploiement exécute des répliques sur n'importe quel nœud disponible avec des ressources disponibles. Bien que cette approche puisse être suffisante pour les applications sans état, le contrôleur de déploiement n'est pas idéal pour les applications qui nécessitent :

• Une convention de dénomination persistante ou un stockage.
• Un réplica doit exister sur chaque nœud sélectionné dans un cluster.

Cependant, deux ressources Kubernetes vous permettent de gérer ces types d'applications :

• Ensembles avec étatmaintenir l'état des applications au-delà d'un cycle de vie de pod individuel, tel que le stockage.
• Ensembles de démonsgarantir une instance en cours d'exécution sur chaque nœud, au début du processus d'amorçage Kubernetes.

Ensembles avec état

Le développement d'applications modernes vise souvent des applications sans état. Pour les applications avec état, comme celles qui incluent des composants de base de données, vous pouvez utiliserEnsembles avec état. Comme les déploiements, un StatefulSet crée et gère au moins un pod identique. Les réplicas dans un StatefulSet suivent une approche séquentielle élégante du déploiement, de la mise à l'échelle, de la mise à niveau et de la résiliation. La convention de dénomination, les noms de réseau et le stockage persistent lorsque les réplicas sont replanifiés avec un StatefulSet.

Définissez l'application au format YAML à l'aide detype : StatefulSet. À partir de là, le contrôleur StatefulSet gère le déploiement et la gestion des répliques requises. Les données sont écrites dans un stockage persistant, fourni par Azure Managed Disks ou Azure Files. Avec StatefulSets, le stockage persistant sous-jacent reste, même lorsque le StatefulSet est supprimé.

Pour plus d'informations, voirEnsembles d'états Kubernetes.

Les répliques d'un StatefulSet sont planifiées et exécutées sur n'importe quel nœud disponible dans un cluster AKS. Pour vous assurer qu'au moins un pod de votre ensemble s'exécute sur un nœud, vous utilisez plutôt un DaemonSet.

Ensembles de démons

Pour une collecte ou une surveillance de journaux spécifiques, vous devrez peut-être exécuter un pod sur tous les nœuds ou sur certains nœuds. Vous pouvez utiliserEnsemble de démonsdéployer sur un ou plusieurs pods identiques, mais le contrôleur DaemonSet s'assure que chaque nœud spécifié exécute une instance du pod.

Le contrôleur DaemonSet peut planifier des pods sur des nœuds au début du processus de démarrage du cluster, avant le démarrage du planificateur Kubernetes par défaut. Cette capacité garantit que les pods d'un DaemonSet sont démarrés avant la planification des pods traditionnels d'un Deployment ou StatefulSet.

Comme StatefulSets, un DaemonSet est défini dans le cadre d'une définition YAML à l'aidegenre: DaemonSet.

Pour plus d'informations, voirEnsembles de démons Kubernetes.

Espaces de noms

Les ressources Kubernetes, telles que les pods et les déploiements, sont logiquement regroupées dans unespace de nomspour diviser un cluster AKS et créer, afficher ou gérer l'accès aux ressources. Par exemple, vous pouvez créer des espaces de noms pour séparer les groupes d'activité. Les utilisateurs peuvent uniquement interagir avec les ressources dans les espaces de noms qui leur sont attribués.

Lorsque vous créez un cluster AKS, les espaces de noms suivants sont disponibles :

Pour plus d'informations, voirEspaces de noms Kubernetes.

Prochaines étapes

Cet article couvre certains des composants de base de Kubernetes et comment ils s'appliquent aux clusters AKS. Pour plus d'informations sur les concepts de base de Kubernetes et AKS, consultez les articles suivants :

• Accès et identité Kubernetes / AKS
• Sécurité Kubernetes/AKS
• Réseaux virtuels Kubernetes / AKS
• Stockage Kubernetes/AKS
• Échelle Kubernetes/AKS