Concepts de base de Kubernetes pour Azure Kubernetes Service (AKS)

Cet article décrit les concepts de base d’Azure Kubernetes Service (AKS), un service Kubernetes managé que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle sur Azure. Il vous aide à découvrir les composants d’infrastructure de Kubernetes et à mieux comprendre le fonctionnement de Kubernetes dans AKS.

Présentation de Kubernetes

Kubernetes est une plateforme évoluant rapidement qui gère les applications basées sur les conteneurs, ainsi que leurs composants de mise en réseau et de stockage. Kubernetes est centré sur les charges de travail d’application et non pas sur les composants de l’infrastructure sous-jacente. Kubernetes fournit une approche déclarative des déploiements, assortie d’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 l’orchestration et la gestion de la disponibilité des composants d’application. Kubernetes prend en charge les applications sans état et avec état.

En tant que plateforme ouverte, Kubernetes vous permet de créer des applications avec vos langages de programmation, système d’exploitation, bibliothèques ou bus de messagerie préférés. Les outils d’intégration et de livraison continues (CI/CD) existants peuvent s’intégrer à Kubernetes dans le cadre de la planification et du déploiement de versions.

AKS fournit un service Kubernetes managé qui réduit la complexité des tâches de déploiement et de gestion de base. 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 d’un cluster Kubernetes

Un cluster Kubernetes comprend deux composants :

• Le plan de contrôle, qui fournit les services Kubernetes de base et l’orchestration des charges de travail d’applications, et
• Des nœuds, qui exécutent vos charges de travail d’application.

Plan de contrôle

Quand vous créez un cluster AKS, la plateforme Azure crée et configure automatiquement son plan de contrôle associé. Ce plan de contrôle monolocataire est fourni gratuitement en tant que ressource Azure managée dissociée de l’utilisateur. Vous payez uniquement pour les nœuds attachés au cluster AKS. Le plan de contrôle et ses ressources se trouvent uniquement sur la région dans laquelle le cluster a été créé.

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

Composant	Description
kube-apiserver	Le serveur d’API expose les API Kubernetes sous-jacentes et fournit l’interaction pour les outils de gestion, comme kubectl ou le tableau de bord Kubernetes.
etcd	etcd est un magasin de clés-valeurs à haute disponibilité au sein de Kubernetes, qui aide à maintenir l’état de votre cluster et de votre configuration Kubernetes.
kube-scheduler	Quand vous créez ou que vous mettez à l’échelle des applications, le planificateur détermine les nœuds qui peuvent exécuter la charge de travail et démarre les nœuds identifiés.
kube-controller-manager	Le gestionnaire de contrôleurs surveille une série de contrôleurs plus petits qui effectuent des actions comme la réplication des pods et la gestion des opérations sur les nœuds.

Gardez à l’esprit que vous ne pouvez pas accéder directement au plan de contrôle. Le plan de contrôle Kubernetes et les mises à niveau des nœuds sont orchestrés via Azure CLI ou le portail Azure. Pour résoudre les problèmes éventuels, vous pouvez consulter les journaux du plan de contrôle en utilisant Azure Monitor.

Nœuds

Pour exécuter vos applications et les services de prise en charge, vous avez besoin d’un nœud Kubernetes. Chaque cluster AKS a au moins un nœud, une machine virtuelle exécutant les composants des nœuds Kubernetes et le runtime de conteneurs.

Les nœuds incluent les composants Kubernetes principaux suivants :

Composant	Description
kubelet	Cet agent Kubernetes traite les requêtes d’orchestration du plan de contrôle, et gère la planification et l’exécution des conteneurs demandés.
kube-proxy	Le proxy gère la mise en réseau virtuelle sur chaque nœud, le routage du trafic réseau et la gestion de l’adressage IP pour les services et les pods.
Runtime de conteneur	Le runtime de conteneurs permet aux applications conteneurisées de s’exécuter et d’interagir avec d’autres ressources, comme le réseau virtuel ou le stockage. Pour plus d’informations, consultez Configuration du runtime de conteneurs.

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, comme un SSD hautes performances ou un HDD classique. Planifiez la taille du nœud en fonction des besoins de vos applications en termes de processeur et de mémoire ou de stockage hautes performances. Augmentez le nombre de nœuds dans votre cluster AKS afin de répondre à la demande. Pour plus d’informations sur la mise à l’échelle, consultez Options de mise à l’échelle pour les applications dans AKS.

Dans AKS, l’image de machine virtuelle pour les nœuds de votre cluster est basée sur Ubuntu Linux, Azure Linux ou Windows Server 2022. Quand vous créez un cluster AKS ou augmentez le nombre de nœuds, la plateforme Azure crée et configure automatiquement le nombre demandé de machines virtuelles. Les nœuds agents étant facturés en tant que machines virtuelles standard, les remises dont vous bénéficiez sur la taille de machine virtuelle que vous utilisez, y compris les réservations Azure, sont automatiquement appliquées.

Pour les disques managés, la taille et les performances des disques sont attribuées en fonction de la référence SKU de la machine virtuelle et du nombre de processeurs virtuels sélectionnés. Pour plus d’informations, consultez Dimensionnement du disque du système d’exploitation par défaut.

Configuration du système d’exploitation

AKS prend en charge Ubuntu 22.04 et Azure Linux 2.0 comme systèmes d’exploitation de nœud pour les clusters utilisant Kubernetes versions 1.25 et ultérieures. Ubuntu 18.04 peut également être spécifié lors de la création d’un pool de nœuds pour Kubernetes versions 1.24 et antérieures.

AKS prend en charge Windows Server 2022 comme système d’exploitation par défaut pour les pools de nœuds Windows dans les clusters utilisant Kubernetes 1.25 et ultérieur. Windows Server 2019 peut également être indiqué lors de la création du pool de nœuds pour Kubernetes versions 1.32 et antérieures. Windows Server 2019 est mis hors service après que la version 1.32 de Kubernetes ait atteint sa fin de vie et ne sera pas pris en charge dans les versions ultérieures. Pour plus d’informations sur cette mise hors service, consultez les notes de publications AKS.

Configuration du runtime de conteneur

Un runtime de conteneur est un logiciel qui exécute des conteneurs et gère des images conteneur sur un nœud. Le runtime permet d’abstraire les appels système ou les fonctionnalités spécifiques au système d’exploitation pour exécuter des conteneurs sur Linux ou Windows. Pour les pools de nœuds Linux, containerd est utilisé sur Kubernetes versions 1.19 et ultérieures. Pour les pools de nœuds Windows Server 2019 et 2022, containerd est généralement disponible et constitue la seule option de runtime dans Kubernetes versions 1.23 et ultérieures. À compter de mai 2023, Docker est mis hors service et n’est plus pris en charge. Pour plus d’informations sur cette mise hors service, consultez les notes de publications AKS.

Containerd est un runtime de conteneur principal conforme à la norme OCI (Open Container Initiative) qui fournit l’ensemble minimal de fonctionnalités requises pour exécuter des conteneurs et gérer des images sur un nœud. Avec des nœuds basés sur containerd et des pools de nœuds, le kubelet communique directement avec containerd en utilisant le plugin CRI (Container Runtime Interface), ce qui élimine des tronçons supplémentaires dans le flux de données en comparaison de l’implémentation CRI de Docker. Par conséquent, vous constatez une meilleure latence au démarrage du pod et une moindre utilisation des ressources (processeur et mémoire).

Containerd fonctionne sur chaque version en disponibilité générale de Kubernetes dans AKS, dans chaque version de Kubernetes à compter de la version 1.19, et prend en charge toutes les fonctionnalités Kubernetes et AKS.

Limitations/différences de containerd

• Pour containerd, nous vous recommandons d’utiliser crictl pour remplacer Docker CLI afin de résoudre les problèmes relatifs aux pods, aux containers et aux images conteneur sur les nœuds Kubernetes. Pour plus d’informations sur crictl, consultez Utilisation générale et Options de configuration du client.

  • Containerd n’offre pas toutes les fonctionnalités de Docker CLI. Il est uniquement disponible pour la résolution des problèmes.
  • crictl offre une vue des conteneurs plus adaptée à Kuberbetes, avec des concepts comme les pods, etc.

• Containerd configure la journalisation en utilisant le format de journalisation normalisé cri. Votre solution de journalisation doit prendre en charge le format de journalisation cri, comme Azure Monitor pour conteneurs.

• Vous ne pouvez plus accéder au moteur Docker, /var/run/docker.sock, ni utiliser Docker-in-Docker (DinD).

  • Si vous extrayez actuellement des journaux d’applications ou des données de surveillance à partir du moteur Docker, utilisez à la place Container Insights. AKS ne prend pas en charge l’exécution de commandes hors bande sur les nœuds d’agent qui pourraient provoquer une instabilité.
  • Nous vous déconseillons de créer des images ou d’utiliser directement le moteur Docker. Kubernetes ne connaît pas pleinement les ressources consommées, et ces méthodes présentent de nombreux problèmes, détaillés ici et ici.

• Lors de la création d’images, vous pouvez continuer à utiliser normalement votre workflow de build Docker actuel, sauf si vous générez des images dans votre cluster AKS. Dans ce cas, envisagez de passer à l’approche recommandée pour la création d’images à l’aide de tâches ACR ou d’une option de cluster plus sécurisée comme Docker Buildx.

Réservations de ressources

AKS utilise des ressources de nœud pour aider la fonction de nœud dans le cadre de votre cluster. Cette utilisation peut créer un écart entre les ressources totales du nœud et les ressources allouables dans AKS. Souvenez-vous de cette information au moment de définir les demandes et les limites des pods déployés par l’utilisateur.

Pour trouver la ressource allouable d’un nœud, vous pouvez utiliser la commande kubectl describe node :

kubectl describe node [NODE_NAME]

Pour conserver les fonctionnalités et les performances des nœuds, AKS réserve deux types de ressources, processeur et mémoire, sur chaque nœud. Lorsque le nœud gagne en taille dans les ressources, la réservation de ressources augmente en raison d’une plus grande quantité de pods déployés par l’utilisateur et nécessitant une gestion. Gardez à l’esprit que les réservations de ressources ne peuvent pas être modifiées.

UC

Le processeur réservé dépend du type de nœud et de la configuration du cluster, ce qui peut rendre le processeur moins allouable en raison de l’exécution de fonctionnalités supplémentaires. Le tableau suivant montre la réservation du processeur en millicores :

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

Mémoire

La mémoire réservée dans AKS correspond à la somme de deux valeurs :

AKS 1.29 et les versions ultérieures

1. Le démon kubelet a la règle d’éviction memory.available<100 Mi par défaut. Cette règle garantit qu’un nœud a toujours à tout moment au moins 100 Mi allouables. Quand un hôte se trouve en dessous du seuil de mémoire disponible, kubelet déclenche l’arrêt d’un des pods en cours d’exécution et libère de la mémoire sur la machine hôte.

2. Un taux de réservations de mémoire est défini en fonction de la valeur la plus petite entre : 20 Mo * nombre maximal de pods pris en charge sur le nœud + 50 Mo ou 25 % des ressources de mémoire système totales.

   Exemples :

   • Si la machine virtuelle fournit 8 Go de mémoire et que le nœud prend en charge jusqu’à 30 pods, AKS réserve 20 Mo * 30 pods max. + 50 Mo = 650 Mo pour kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Si la machine virtuelle fournit 4 Go de mémoire et que le nœud prend en charge jusqu’à 70 pods, AKS réserve 25 % * 4 Go = 1 000 Mo pour kube-reserved, car la valeur est inférieure à 20 Mo * 70 pods max. + 50 Mo = 1 450 Mo.

   Pour plus d’informations, consultez Configurer le nombre maximal de pods pour un cluster AKS.

Versions AKS antérieures à 1.29

1. Le démon kubelet a par défaut la règle d’éviction memory.available<750 Mi. Cette règle garantit qu’un nœud a toujours à tout moment au moins 750 Mi allouables. Quand un hôte est en dessous du seuil de mémoire disponible, kubelet déclenche l’arrêt d’un des pods en cours d’exécution et libère de la mémoire sur la machine hôte.
2. Une vitesse régressive des réservations de la mémoire pour que le démon kubelet fonctionne correctement (kube-reserved).
   • 25 % des 4 premiers Go de mémoire
   • 20 % des 4 Go suivants de mémoire (jusqu’à 8 Go)
   • 10 % des 8 Go suivants de mémoire (jusqu’à 16 Go)
   • 6 % des 112 Go suivants de mémoire (jusqu’à 128 Go)
   • 2 % de la mémoire supérieure à 128 Go

Les règles d’allocation de mémoire et de processeur sont conçues avec les objectifs suivants :

• Maintenez l’intégrité des nœuds d’agent, avec quelques blocs de système d’hébergement critiques pour l’intégrité du cluster.
• Faire en sorte que le nœud indique moins de mémoire et de processeur allouable qu’il ne le ferait s’il ne faisait pas partie d’un cluster Kubernetes.

Par exemple, si un nœud offre 7 Go, il signalera 34 % de la mémoire non-allouable incluant le seuil d’éviction dur de 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

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 de processeur et de mémoire pour gérer les fonctions du système d’exploitation.

Pour connaître les meilleures pratiques associées, consultez la section Meilleures pratiques relatives aux fonctionnalités de base du planificateur dans AKS.

Pools de nœuds

Les nœuds d’une même configuration sont regroupés dans des pools de nœuds. Chaque cluster Kubernetes contient au moins un pool de nœuds. Vous définissez le nombre et la taille initiaux des nœuds quand vous créez un cluster AKS, qui crée un nœud de pools 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 à niveau un cluster AKS sur le 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, les conteneurs en cours d’exécution sont planifiés sur d’autres nœuds du pool de nœuds jusqu’à ce que tous les nœuds soient mis à niveau.

Pour plus d’informations, consultez Créer des pools de nœuds et Gérer les pools de nœuds.

Dimensionnement du disque de système d’exploitation par défaut

Lorsque vous créez un cluster ou que vous ajoutez un nouveau pool de nœuds à un cluster existant, le nombre de processeurs virtuels détermine par défaut la taille du disque du système d'exploitation. Le nombre de processeurs virtuels est basé sur la référence SKU de la machine virtuelle. Le tableau suivant liste les tailles de disque de système d’exploitation par défaut pour chaque référence SKU de machine virtuelle :

Cœurs de référence SKU de machine virtuelle (processeurs virtuels)	Niveau du disque de système d’exploitation par défaut	IOPS provisionnées	Débit approvisionné (Mbits/s)
1 à 7	P10/128G	500	100
8 à 15	P15/256G	1100	125
16 à 63	P20/512G	2300	150
64+	P30/1024G	5 000	200

Sélecteurs de nœud

Dans un cluster AKS avec plusieurs pools de nœuds, il peut être nécessaire d’indiquer au planificateur Kubernetes le 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 des nœuds Windows Server. Vous utilisez des sélecteurs de nœud pour définir différents paramètres, comme le système d’exploitation des nœuds, afin de contrôler où un pod doit être planifié.

L’exemple de base suivant planifie une instance NGINX sur un nœud Linux en utilisant le sélecteur de nœud "kubernetes.io/os": linux :

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Pour plus d’informations, consultez Meilleures pratiques relatives aux fonctionnalités avancées du planificateur dans AKS.

Groupe de ressources de nœud

Quand vous créez un cluster AKS, vous spécifiez un groupe de ressources Azure où créer les ressources du cluster. En plus de ce groupe de ressources, le fournisseur de ressources AKS crée et gère un groupe de ressources distinct appelé groupe de ressources de nœud. Le groupe de ressources contient les ressources d’infrastructure suivantes :

• Groupes de machines virtuelles identiques et machines virtuelles pour chaque nœud dans les pools de nœuds
• Réseau virtuel pour le cluster
• Stockage pour le cluster

Un nom par défaut est affecté au groupe de ressources de nœud selon le format suivant : MC_nomGroupeDeRessources_nomDuCluster_emplacement. Lors de la création du cluster, vous pouvez spécifier le nom affecté à votre groupe de ressources de nœud. Quand vous utilisez un modèle Azure Resource Manager, vous pouvez définir le nom en utilisant la propriété nodeResourceGroup. Quand vous utilisez Azure CLI, vous utilisez le paramètre --node-resource-group avec la commande az aks create, comme illustré dans l’exemple suivant :

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

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 une fois que le cluster a été créé.
• Vous ne pouvez pas spécifier des noms pour les ressources managées au sein du groupe de ressources de nœud.
• Vous ne pouvez pas modifier ni supprimer les étiquettes des ressources managées créées par Azure au sein du groupe de ressources de nœud.

La modification de balises créées par Azure sur des ressources dépendant du groupe de ressources du nœud dans le cluster AKS est une action non prise en charge, qui rompt l’objectif de niveau de service (SLO). Si vous modifiez ou que vous supprimez des étiquettes créées par Azure ou d’autres propriétés de ressources dans le groupe de ressources de nœud, vous pouvez obtenir des résultats inattendus, comme des erreurs de mise à l’échelle et de mise à niveau. AKS gère le cycle de vie de l’infrastructure dans le groupe de ressources de nœud, de sorte que toute modification fait passer votre cluster dans un état non pris en charge. Pour plus d'informations, consultez AKS offre-t-il un contrat de niveau de service ?

AKS vous permet de créer et de modifier des étiquettes qui sont propagées aux ressources du groupe de ressources de nœud, et vous pouvez ajouter ces étiquettes lors de la création ou de la mise à jour du cluster. Vous pouvez créer ou modifier des étiquettes personnalisées, par exemple pour affecter une unité opérationnelle ou un centre de coûts. Vous pouvez aussi créer des stratégies Azure avec une étendue sur le groupe de ressources managé.

Pour réduire le risque que des modifications dans le groupe de ressources de nœud affectent vos clusters, vous pouvez activer le verrouillage du groupe de ressources de nœud pour appliquer un refus d’affectation à vos ressources AKS. Pour plus d’informations, consultez Groupe de ressources complètement managé (préversion).

Pods

Kubernetes utilise des pods pour exécuter des instance de votre application. Un pod représente une instance unique de votre application.

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

Quand vous créez un pod, vous pouvez définir des demandes de ressources pour une certaine quantité de processeur ou de mémoire. Le planificateur de Kubernetes essaie de répondre à cette demande en planifiant les pods afin qu’ils s’exécutent sur un nœud avec des ressources disponibles. Vous pouvez également spécifier des limites de ressources maximales qui empêchent un pod de consommer trop de ressources de calcul à partir du nœud sous-jacent. Notre meilleure pratique recommandée est d’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, consultez Kubernetes pods (Pods Kubernetes) et Kubernetes pod lifecycle (cycle de vie des pods Kubernetes).

Un pod est une ressource logique, mais les charges de travail s’exécutent sur les conteneurs. Les pods sont généralement des ressources éphémères et jetables. Il manque aux pods planifiés individuellement une partie des caractéristiques de haute disponibilité et de redondance de Kubernetes. Au lieu de cela, les contrôleurs Kubernetes, comme le contrôleur de déploiement, déploient et gèrent les pods.

Déploiements et manifestes YAML

Un déploiement représente des pods identiques, gérés par le contrôleur de déploiement Kubernetes. Un déploiement définit le nombre de réplicas de pods à créer. Le planificateur Kubernetes veille à ce que les pods supplémentaires soient 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 changer la configuration des pods, l’image de conteneur ou le stockage attaché.

Le contrôleur de déploiement gère le cycle de vie du déploiement et effectue les actions suivantes :

• Purge et termine un nombre donné de réplicas.
• Crée des réplicas à partir de la nouvelle définition de déploiement.
• Poursuit le processus jusqu’à ce que tous les réplicas du déploiement soient mis à jour.

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

Vous ne souhaitez pas interrompre les décisions de gestion avec un processus de mise à jour si votre application nécessite un nombre minimal d’instances disponibles. Les budgets d’interruption de pods permettent de définir le nombre de réplicas dans un déploiement pouvant être retirés pendant une mise à niveau d’un nœud ou une mise à jour. Par exemple, si vous avez cinq réplicas dans votre déploiement, vous pouvez définir une interruption de pods de quatre pour permettre la suppression ou la replanification d’un seul réplica à la fois. Comme dans le cas des limites de ressources des pods, notre meilleure pratique recommandée est de définir des budgets d’interruption de pod sur les applications qui nécessitent la présence continue d’un nombre minimal de réplicas.

Les déploiements sont généralement créés et gérés avec kubectl create ou kubectl apply. Vous pouvez créer un déploiement en définissant un fichier manifeste au format YAML. L’exemple suivant montre un fichier manifeste de déploiement de base pour un serveur web NGINX :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Voici la répartition des spécifications de déploiement dans le fichier manifeste YAML :

Caractéristique	Description
.apiVersion	Spécifie le groupe d’API et la ressource d’API que vous souhaitez utiliser lors de la création de la ressource.
.kind	Spécifie le type de ressource que vous voulez créer.
.metadata.name	Spécifie le nom du déploiement. Cet exemple de fichier YAML exécute l’image nginx à partir de Docker Hub.
.spec.replicas	Spécifie le nombre de pods à créer. Cet exemple de fichier YAML crée trois pods dupliqués.
.spec.selector	Spécifie les pods qui seront affectés par ce déploiement.
.spec.selector.matchLabels	Contient une carte de paires {clé, valeur} qui permet au déploiement de rechercher et de gérer les pods créés.
.spec.selector.matchLabels.app	Doit correspondre à .spec.template.metadata.labels.
.spec.template.labels	Spécifie les paires {key, value} attachées à l’objet.
.spec.template.app	Doit correspondre à .spec.selector.matchLabels.
.spec.spec.containers	Spécifie la liste des conteneurs appartenant au pod.
.spec.spec.containers.name	Spécifie le nom du conteneur spécifié sous forme d’étiquette DNS.
.spec.spec.containers.image	Spécifie le nom de l’image conteneur.
.spec.spec.containers.ports	Spécifie la liste des ports à exposer à partir du conteneur.
.spec.spec.containers.ports.containerPort	Spécifie le nombre de ports à exposer sur l’adresse IP du pod.
.spec.spec.resources	Spécifie les ressources de calcul requises par le conteneur.
.spec.spec.resources.requests	Spécifie la quantité minimale de ressources de calcul requises.
.spec.spec.resources.requests.cpu	Spécifie la quantité minimale d’UC requise.
.spec.spec.resources.requests.memory	Spécifie la quantité minimale de mémoire requise.
.spec.spec.resources.limits	Spécifie la quantité minimale de ressources de calcul requises. Le kubelet applique cette limite.
.spec.spec.resources.limits.cpu	Spécifie la quantité maximale d’UC autorisée. Le kubelet applique cette limite.
.spec.spec.resources.limits.memory	Spécifie la quantité maximale de mémoire autorisée. Le kubelet applique cette limite.

Vous pouvez également créer des applications plus complexes en incluant des services, comme des équilibreurs de charge, dans le manifeste YAML.

Pour plus d’informations, consultez la section Déploiements Kubernetes.

Gestion des packages avec Helm

Helm est couramment utilisé pour gérer les applications dans Kubernetes. Vous pouvez déployer des ressources en créant et en utilisant des graphiques Helm publics existants qui contiennent une version empaquetée d’un code d’application et de manifestes YAML Kubernetes. Ces graphiques Helm peuvent être stockés localement ou dans un référentiel distant comme un référentiel de graphiques Helm Azure Container Registry.

Pour utiliser Helm, installez le client Helm sur votre ordinateur, ou utilisez le client Helm dans Azure Cloud Shell. Recherchez ou créez des graphiques Helm, puis installez-les sur votre cluster Kubernetes. Pour plus d’informations, consultez la section Installer des applications existantes avec Helm dans AKS.

Ressources StatefulSet et ressources DaemonSet

Le contrôleur de déploiement utilise le planificateur Kubernetes et exécute des réplicas sur n’importe quel nœud disponible avec des ressources disponibles. Bien que cette approche soit suffisante pour les applications sans état, le contrôleur de déploiement n’est pas idéal pour les applications qui nécessitent les spécifications suivantes :

• Une convention d’affectation de noms ou un stockage persistant.
• Un réplica sur certains nœuds au sein d’un cluster.

Cependant, il existe deux ressources Kubernetes qui vous permettent de gérer ces types d’applications : les StatefulSets et les DaemonSets.

Les StatefulSets maintiennent l’état des applications au-delà du cycle de vie d’un pod individuel. Les DaemonSets garantissent une instance en cours d’exécution sur chaque nœud tôt dans le processus de démarrage de Kubernetes.

Ressources StatefulSet

Le développement d’applications modernes est souvent destiné à des applications sans état. Pour les applications avec état, comme celles qui incluent des composants de base de données, vous pouvez utiliser StatefulSets. Comme pour les déploiements, StatefulSet crée et gère au moins un pod identique. Les réplicas d’un StatefulSet suivent une approche séquentielle et sans perte de données des opérations de déploiement, de mise à l’échelle, de mise à niveau et d’arrêt. Avec une ressource StatefulSet, la convention de nommage, les noms de réseau et le stockage persistent quand les réplicas sont replanifiés.

Vous pouvez définir l’application au format YAML en utilisant kind: StatefulSet. À partir de là, le contrôleur StatefulSet gère le déploiement et la gestion des réplicas requis. Les données sont écrites dans un stockage persistant, fourni par Disques managés Azure ou par Azure Files. Avec une ressource StatefulSet, le stockage permanent sous-jacent demeure, même quand la ressource est supprimée.

Pour plus d’informations, consultez la section Kubernetes StatefulSets.

Ressources DaemonSet

Dans le cadre d’une supervision ou d’une collecte de journaux spécifique, vous pouvez être amené à exécuter un pod sur tous les nœuds ou sur un ensemble de nœuds sélectionnés. Vous pouvez utiliser DaemonSets pour un déploiement sur un ou plusieurs pods identiques. Le contrôleur DaemonSet garantit que chaque nœud spécifié exécute une instance du pod.

Le contrôleur DaemonSet peut planifier des pods sur des nœuds tôt dans le processus de démarrage du cluster, avant que le planificateur Kubernetes par défaut ne démarre. Cette possibilité garantit que les pods dans un état DaemonSet sont démarrés avant que les pods traditionnels dans un déploiement ou un StatefulSet ne soient planifiés.

À l’image des StatefulSets, vous pouvez définir un DaemonSet dans le cadre d’une définition YAML en utilisant kind: DaemonSet.

Pour plus d’informations, consultez la section Kubernetes DaemonSets.

Espaces de noms

Les ressources Kubernetes, comme les pods et les déploiements, sont regroupées logiquement en espaces de noms pour diviser un cluster AKS, et pour créer, visualiser ou gérer l’accès à des ressources. Par exemple, vous pouvez créer des espaces de noms pour séparer les groupes métier. Les utilisateurs ne peuvent interagir qu’avec les ressources appartenant aux espaces de noms qui leur sont attribués.

Les espaces de noms suivants sont disponibles quand vous créez un cluster AKS :

Espace de noms	Description
default	Espace de noms dans lequel sont créés par défaut les pods et les déploiements quand aucun espace de noms n’est fourni. Dans les environnements plus petits, vous pouvez déployer les applications directement dans l’espace de noms par défaut sans provoquer la création de séparations logiques supplémentaires. Quand vous interagissez avec l’API Kubernetes, comme avec kubectl get pods, l’espace de noms par défaut est utilisé si aucun n’est spécifié.
kube-system	Espace de noms où se trouvent les ressources principaless, telles que les fonctionnalités réseau, comme le DNS et le proxy, ou bien le tableau de bord Kubernetes. En règle générale, vous ne déployez pas vos propres applications dans cet espace de noms.
kube-public	Généralement non utilisé, mais vous pouvez l’utiliser pour rendre les ressources visibles dans l’ensemble du cluster et consultables par tous les utilisateurs.

Pour plus d’informations, consultez la section Espace de noms Kubernetes.

Étapes suivantes

Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez les articles suivants :

• Identité et accès AKS
• Sécurité AKS
• Réseaux virtuels AKS
• Stockage AKS
• Mise à l'échelle AKS