Questions fréquentes (FAQ) sur AKS

Cet article apporte des réponses à certaines des questions les plus fréquemment posées sur Azure Kubernetes Service (AKS).

Soutien

AKS offre-t-il un contrat de niveau de service ?

AKS fournit des garanties de contrat de niveau de service (SLA) dans le niveau tarifaire Standard avec la fonctionnalité Contrat SLA de durée de bon fonctionnement.

Qu’est-ce que le support de plateforme et qu’inclut-il ?

La prise en charge de la plateforme est un plan de support réduit pour les clusters de version n-3 non pris en charge. La prise en charge de la plateforme inclut uniquement la prise en charge de l’infrastructure Azure.

Pour plus d’informations, consultez la politique de support de la plateforme.

AKS met-il automatiquement à niveau mes clusters non pris en charge ?

Oui, AKS lance des mises à niveau automatiques pour les clusters non pris en charge. Lorsqu’un cluster dans une version n-3 (où n est la dernière version mineure d’AKS prise en charge qui est en disponibilité générale) est sur le point de passer à n-4, AKS met automatiquement à niveau le cluster vers n-2 pour rester dans une stratégie de support AKS.

Pour plus d’informations, consultez Versions Kubernetes prises en charge, Fenêtres de maintenance planifiée et Mises à niveau automatiques.

Puis-je exécuter des conteneurs Windows Server sur AKS ?

Oui, AKS prend également en charge les conteneurs Windows Server. Pour plus d’informations, consultez la FAQ Windows Server sur AKS.

Puis-je appliquer des remises de réservation Azure sur mes nœuds d’agent AKS ?

Les nœuds de l’agent AKS sont facturés en tant que machines virtuelles Azure standard. Si vous avez acheté des réservations Azure pour la taille de machine virtuelle que vous utilisez dans AKS, ces remises sont automatiquement appliquées.

Opérations

Puis-je déplacer ou migrer mon cluster entre des locataires Azure ?

Non. Le déplacement de votre cluster AKS entre locataires n’est actuellement pas pris en charge.

Puis-je déplacer ou migrer mon cluster entre des abonnements ?

Non. Le déplacement de votre cluster AKS d’un abonnement à un autre n’est actuellement pas pris en charge.

Puis-je déplacer mon cluster AKS ou mes ressources d'infrastructure AKS vers d'autres groupes de ressources ou les renommer ?

Non. Le déplacement ou le changement de nom de votre cluster AKS et des ressources associées ne sont pas pris en charge.

Puis-je restaurer mon cluster une fois que je l’ai supprimé ?

Non. Vous ne pouvez pas restaurer votre cluster une fois que vous l’avez supprimé. Quand vous supprimez votre cluster, le groupe de ressources du nœud et toutes ses ressources sont également supprimés.

Si vous souhaitez conserver l’une de vos ressources, déplacez-les vers un autre groupe de ressources avant la suppression de votre cluster. Si vous souhaitez vous protéger contre les suppressions accidentelles, vous pouvez verrouiller le groupe de ressources managé AKS qui héberge vos ressources de cluster en utilisant un Verrouillage du groupe de ressources de nœud.

Puis-je mettre à l’échelle mon cluster AKS jusqu’à zéro ?

Vous pouvez complètement arrêter un cluster AKS en cours d’exécution ou mettre à l’échelle ou mettre à l’échelle automatiquement tout ou partie des pools de nœuds User à zéro.

Vous ne pouvez pas mettre directement à l’échelle des pools de nœuds système sur 0.

Puis-je utiliser les API du groupe de machines virtuelles identiques pour effectuer une mise à l'échelle manuelle ?

Non. Les opérations de mise à l’échelle qui utilisent les API de groupe de machines virtuelles identiques ne sont pas prises en charge. Vous pouvez utiliser les API AKS (az aks scale).

Puis-je utiliser des groupes de machines virtuelles identiques pour mettre à l’échelle manuellement des nœuds sur 0 ?

Non. Les opérations de mise à l’échelle qui utilisent les API de groupe de machines virtuelles identiques ne sont pas prises en charge. Vous pouvez utiliser l’API AKS pour mettre à l’échelle sur zéro des pools de nœuds non système ou arrêter votre cluster à la place.

Puis-je arrêter ou libérer toutes mes machines virtuelles ?

Non. Cette configuration n’est pas prise en charge. Arrêtez votre cluster à la place.

Pourquoi deux groupes de ressources sont-ils créés avec AKS ?

AKS s’appuie sur différentes ressources de l’infrastructure Azure, notamment les groupes de machines virtuelles identiques, réseaux virtuels et disques managés. Ces intégrations vous permettent d’appliquer de nombreuses fonctionnalités essentielles de la plateforme Azure dans l’environnement Kubernetes managé fourni par AKS. Par exemple, vous pouvez utiliser la majorité des types de machines virtuelles Azure directement avec AKS et vous pouvez utiliser Réservations Azure pour recevoir automatiquement des remises sur ces ressources.

Pour permettre cette architecture, chaque déploiement AKS s’étend sur deux groupes de ressources :

1. Vous créez le premier groupe de ressources. Ce groupe contient uniquement la ressource de service Kubernetes. Le fournisseur de ressources AKS crée automatiquement le second groupe de ressources au cours du déploiement. Un exemple du second groupe de ressources est MC_myResourceGroup_myAKSCluster_eastus. Pour obtenir des informations sur la façon de spécifier le nom de ce second groupe de ressources, consultez la section suivante.
2. Le second groupe de ressources, nommé groupe de ressources de nœud, contient toutes les ressources d’infrastructure associées au cluster. Ces ressources incluent les machines virtuelles de nœud Kubernetes, la mise en réseau et le stockage. Par défaut, le nom du groupe de ressources de nœud ressemble à ceci : MC_myResourceGroup_myAKSCluster_eastus. AKS supprime automatiquement le groupe de ressources de nœud quand vous supprimez le cluster. Utilisez ce groupe de ressources uniquement pour les ressources qui partagent le cycle de vie du cluster.

Remarque

La modification d’une ressource sous le groupe de ressources du nœud dans le cluster AKS est une action non prise en charge qui entraîne des échecs d’opération dans le cluster. Vous pouvez empêcher les modifications apportées au groupe de ressources de nœud. Empêcher les utilisateurs de modifier les ressources gérées par le cluster AKS.

Puis-je nommer mon groupe de ressources d’infrastructure AKS comme je le veux ?

Par défaut, AKS nomme le groupe de ressources de nœud MC_resourcegroupname_clustername_location, mais vous pouvez fournir votre propre nom.

Pour spécifier votre propre nom de groupe de ressources, installez la version 0.3.2 ou une version ultérieure de l’extension Azure CLI aks-preview. Lorsque vous créez un cluster AKS à l’aide de la commande az aks create, utilisez le paramètre --node-resource-group et spécifiez un nom pour le groupe de ressources. Si vous utilisez un modèle Azure Resource Manager pour déployer un cluster AKS, vous pouvez définir le nom du groupe de ressources en tirant parti de la propriété nodeResourceGroup.

• Le fournisseur de ressources Azure crée automatiquement le groupe de ressources secondaire.
• Vous pouvez spécifier un nom de groupe de ressources personnalisé uniquement lors de la création du cluster.

Lorsque vous travaillez avec le groupe de ressources de nœud, vous ne pouvez pas :

• Spécifier un groupe de ressources existant pour le groupe de ressources de nœud.
• Spécifier un autre abonnement pour le groupe de ressources de nœud.
• Modifier le nom du groupe de ressources de nœud après avoir créé le cluster.
• Spécifier des noms pour les ressources managées au sein du groupe de ressources de nœud.
• Modifier ni supprimer les étiquettes des ressources managées créées par Azure au sein du groupe de ressources de nœud.

Puis-je modifier les balises et d’autres propriétés des ressources AKS 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 si vous modifiez ou supprimez des balises créées par Azure et d’autres propriétés de ressources dans le groupe de ressources de nœud. AKS vous permet de créer et de modifier des balises personnalisées créées par les utilisateurs finaux et vous pouvez ajouter ces balises lorsque vous créez un pool de nœuds. 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. Une autre option consiste à appliquer des stratégies et à modifier des balises via la ressource AKS elle-même, en particulier via le cluster et les pools de nœuds.

Les balises créées par Azure sont créées pour leurs services Azure respectifs et vous devez toujours les autoriser. Pour AKS, il s’agit des balises aks-managed et k8s-azure. 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).

Remarque

Dans le passé, le nom de balise Owner était réservé à AKS pour gérer l’adresse IP publique affectée sur l’adresse IP front-end de l’équilibreur de charge. À présent, les services utilisent le préfixe aks-managed. Pour les ressources héritées, n’utilisez pas de stratégies Azure pour appliquer le nom de balise Owner. Si vous les utilisez, toutes les ressources de votre déploiement de cluster AKS et les opérations de mise à jour s’interrompent. Cette restriction ne s’applique pas aux ressources nouvellement créées.

Pourquoi puis-je voir les versions Helm avec préfixe gérées par AKS sur mon cluster et pourquoi leur nombre de révisions continue-t-il d’augmenter ?

AKS utilise Helm pour fournir des composants à votre cluster. Vous pouvez ignorer en toute sécurité les versions de Helm avec préfixe aks-managed. L’augmentation continue des révisions sur ces versions Helm est prévue et sécurisée.

Quotas, limites et disponibilité des régions

Quelles régions Azure proposent actuellement AKS ?

Pour obtenir la liste complète des régions disponibles, consultez Régions AKS et disponibilité.

Puis-je répartir un cluster AKS dans plusieurs régions ?

Non. Les clusters AKS sont des ressources régionales et ne peuvent pas s’étendre sur plusieurs régions. Pour obtenir de l’aide pour la création d’une architecture qui inclut plusieurs régions, consultez les meilleures pratiques en matière de continuité d’activité et de reprise d’activité.

Puis-je répartir un cluster AKS dans plusieurs zones de disponibilité ?

Oui, vous pouvez déployer un cluster AKS sur une ou plusieurs zones de disponibilité dans les régions qui les prennent en charge.

Puis-je avoir des machines virtuelles de différentes tailles dans un même cluster ?

Oui, vous pouvez utiliser des tailles de machine virtuelle différentes dans votre cluster AKS en créant plusieurs pools de nœuds.

Quelle est la limite de taille d’une image conteneur dans AKS ?

AKS ne définit pas de limite concernant la taille des images conteneur. Mais plus l’image est grande, plus la demande de mémoire est élevée. Une taille plus grande risque potentiellement de dépasser les limites de ressources ou la mémoire disponible globale des nœuds Worker. Par défaut, la mémoire pour la taille de la machine virtuelle Standard_DS2_v2 pour un cluster AKS est définie sur 7 Gio.

Lorsqu’une image conteneur est excessivement volumineuse, comme dans la plage de téraoctets (To), il est possible que le kubelet ne soit pas en mesure de l’extraire de votre registre de conteneurs vers un nœud en raison du manque d’espace disque.

Pour les nœuds Windows Server, Windows Update n’exécute pas et n’applique pas automatiquement les dernières mises à jour. Vous devez effectuer une mise à niveau sur le cluster et les pools de nœuds Windows Server de votre cluster AKS. Suivez une planification régulière en fonction du cycle de publication de Windows Update et de votre propre processus de validation. Ce processus de mise à niveau crée des nœuds qui exécutent la dernière image et les derniers correctifs Windows Server, puis supprime les anciens nœuds. Pour plus d’informations sur ce processus, consultez Mettre à niveau un pool de nœuds dans AKS.

Les images AKS sont-elles nécessaires pour fonctionner en tant que racine ?

Les images suivantes ont des exigences fonctionnelles pour s’exécuter en tant que racine. Les exceptions doivent être déposées pour toutes les stratégies :

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Sécurité, accès et identité

Puis-je limiter qui a accès au serveur d’API Kubernetes ?

Oui, il existe deux options pour limiter l’accès au serveur d’API :

• Utilisez des Plages d’adresses IP autorisées du serveur d’API si vous souhaitez conserver un point de terminaison public pour le serveur d’API, mais restreindre l’accès à un ensemble de plages d’adresses IP approuvées.
• Utilisez un cluster privé si vous souhaitez limiter le serveur d’API à être accessible uniquement à partir de votre réseau virtuel.

Des mises à jour sécurisées sont-elles appliquées aux nœuds de l’agent AKS ?

AKS corrige les CVE qui ont un correctif de fournisseur chaque semaine. Les CVE sans correctif attendent un correctif de fournisseur avant de pouvoir être corrigés. Les images AKS sont automatiquement mises à jour dans les 30 jours. Nous vous recommandons d’appliquer une image de nœud mise à jour à une cadence régulière pour vous assurer que les dernières images correctives et correctifs du système d’exploitation sont tous appliqués et actuels. Vous pouvez effectuer cette tâche :

• Manuellement, via le portail Azure ou l’interface de ligne de commande Azure.
• En mettant à niveau votre cluster AKS. Le cluster met automatiquement à niveau le cordon et vide les nœuds. Il apporte ensuite un nouveau nœud en ligne avec la dernière image Ubuntu et une nouvelle version de correctif ou une version mineure de Kubernetes. Pour plus d’informations, consultez Mettre à niveau un cluster AKS.
• À l’aide d’une mise à niveau d’image de nœud.

Existe-t-il des menaces de sécurité qui ciblent AKS dont je dois être conscient ?

Microsoft fournit des conseils pour d’autres actions que vous pouvez effectuer pour sécuriser vos charges de travail via des services comme Microsoft Defender pour les conteneurs. Pour découvrir plus d’informations sur une menace de sécurité liée à AKS et Kubernetes, consultez Nouvelles cibles de campagne à grande échelle Kubeflow (8 juin 2021).

AKS stocke-t-il des données client en dehors de la région du cluster ?

Non. Toutes les données sont stockées dans la région du cluster.

Comment puis-je éviter les problèmes de lenteur de définition de propriété d’autorisation lorsque le volume contient plusieurs fichiers ?

Traditionnellement, si votre pod s’exécute en tant qu’utilisateur non racine (et il devrait l’effectuer), vous devez spécifier un paramètre fsGroup dans le contexte de sécurité du pod afin que le volume soit lisible et accessible en écriture par le pod. Pour découvrir plus d’informations sur cette exigence, consultez Configurer un contexte de sécurité pour un pod ou un conteneur.

Un effet secondaire de la définition fsGroup est que lors de chaque montage de volume, Kubernetes doit utiliser les commandes chown() et chmod() de manière récursive pour tous les fichiers et répertoires dans le volume (avec quelques exceptions). Ce scénario se produit même si la propriété du groupe du volume correspond déjà au paramètre fsGroup demandé. Il est possible que cette configuration soit coûteuse pour les volumes plus volumineux avec un grand nombre de petits fichiers, pouvant entraîner un démarrage beaucoup plus long des pods. Ce scénario était un problème connu avant la version 1.20. La solution de contournement consiste à définir le pod pour l’exécuter en tant que racine :

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Le problème a été résolu avec Kubernetes dans la version 1.20. Pour découvrir plus d’informations, consultez Kubernetes 1.20 : Contrôle granulaire des modifications d’autorisation de volume.

Réseau

Comment le plan de contrôle managé communique-t-il avec mes nœuds ?

AKS utilise une communication de tunnel sécurisée pour permettre au api-server et aux kubelets de nœud individuel de communiquer, même sur des réseaux virtuels distincts. Le tunnel est sécurisé via le chiffrement mutuel du protocole TLS. Le tunnel principal actuel que AKS utilise est Konnectivity, antérieurement appelé apiserver-network-proxy. Vérifiez que toutes les règles réseau suivent les règles réseau Azure requises et les noms de domaine complets (FQDN).

Mes pods peuvent-ils utiliser le FQDN du serveur d’API au lieu de l’IP du cluster ?

Oui, vous pouvez ajouter l’annotation kubernetes.azure.com/set-kube-service-host-fqdn aux pods pour définir la variable KUBERNETES_SERVICE_HOST sur le nom de domaine du serveur d’API au lieu de l’IP du service dans le cluster. Cette modification est utile si votre sortie de cluster est effectuée via un pare-feu de couche 7. Par exemple, lorsque vous utilisez Pare-feu Azure avec des règles d’application.

Puis-je configurer les groupe de sécurité réseau avec AKS ?

AKS n’applique pas de groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie aucun des groupes de sécurité réseau associés à ce sous-réseau. AKS modifie uniquement les paramètres du groupe de sécurité réseau de l’interface réseau. Si vous utilisez l’interface réseau de conteneur (CNI), vous devez également veiller à ce que les règles de sécurité dans les groupes de sécurité réseau autorisent le trafic entre les plages de routage CIDR (Classless InterDomain Routing) de nœud et de pod. Si vous utilisez kubenet, vous devez également vous veiller à ce que les règles de sécurité dans les groupes de sécurité réseau autorisent le trafic entre le nœud et le CIDR du pod. Pour plus d’informations, consultez Groupes de sécurité réseau.

Comment fonctionne la synchronisation de temps dans AKS ?

Les nœuds AKS exécutent le service chrony qui extrait le temps à partir de l’hôte local. Les conteneurs qui s’exécutent sur des pods obtiennent le temps des nœuds AKS. Les applications qui s’ouvrent dans un conteneur utilisent le temps à partir du conteneur du pod.

Modules complémentaires, extensions et intégrations

Puis-je utiliser des extensions de machine virtuelle personnalisées ?

Non. AKS est un service géré. La manipulation des ressources IaaS (Infrastructure as a Service) n’est pas prise en charge. Pour installer des composants personnalisés, utilisez les mécanismes et les API Kubernetes. Par exemple, utilisez DaemonSets pour installer tout composant requis.

Quels sont les contrôleurs d’admission Kubernetes qui sont pris en charge par AKS ? Les contrôleurs d’admission peuvent-ils être ajoutés ou supprimés ?

AKS prend en charge les contrôleurs d’admission suivants :

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Actuellement, vous ne pouvez pas modifier la liste des contrôleurs d’admission dans AKS.

Puis-je utiliser des webhooks de contrôleur d’admission dans AKS ?

Oui, vous pouvez utiliser des webhooks de contrôleur d’admission dans AKS. Nous vous recommandons d’exclure les espaces de noms AKS internes qui sont marqués avec l’étiquette control-plane. Exemple :

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS protège via un pare-feu la sortie du serveur d’API pour que l’accessibilité à vos webhooks de contrôleur d’admission soit nécessaire à partir du cluster.

Les webhooks du contrôleur d’admission peuvent-ils influencer kube-system et les espaces de noms AKS internes ?

Pour protéger la stabilité du système et empêcher les contrôleurs d’admission personnalisés d’affecter les services internes dans l’espace de noms kube-system, AKS dispose d’un application d’admission qui exclut automatiquement kube-system et les espaces de noms internes AKS. Ce service veille à ce que les contrôleurs d’admission personnalisés n’affectent pas les services qui s’exécutent dans kube-system.

Si vous avez un cas d’usage critique pour déployer un élément sur kube-system (non recommandé) dans le support de votre webhook d’admission personnalisé, vous pouvez ajouter l’étiquette ou l’annotation suivante afin que l’exécuteur des admissions l’ignore :

• Étiquette : "admissions.enforcer/disabled": "true"
• Annotation : "admissions.enforcer/disabled": true

Azure Key Vault est-il intégré à AKS ?

Le fournisseur Azure Key Vault pour Secrets Store CSI Driver fournit une intégration native d’Azure Key Vault à AKS.

Puis-je utiliser des bibliothèques cryptographiques FIPS avec des déploiements sur AKS ?

Les nœuds activés avec les normes FIPS (Federal Information Processing Standard) sont désormais pris en charge sur les pools de nœuds Linux. Pour plus d’informations, consultez Ajouter un pool de nœuds compatibles FIPS.

Comment les modules complémentaires AKS sont-ils mis à jour ?

Tout correctif, y compris un correctif de sécurité, est automatiquement appliqué au cluster AKS. Tout ce qui est plus grand qu’un correctif, comme les modifications de version majeures ou mineures (qui peuvent avoir des changements cassants pour vos objets déployés), est mis à jour lorsque vous mettez à jour votre cluster si une nouvelle version est disponible. Pour découvrir plus d’informations sur la disponibilité d’une nouvelle version, consultez les notes de publication AKS.

Quel est l’objectif de l’extension Linux AKS que je vois installée sur mes instances de groupes de machines virtuelles identiques Linux ?

L’extension Linux AKS est une extension de machine virtuelle Azure qui installe et configure des outils de monitoring sur des nœuds Worker Kubernetes. L’extension est installée sur tous les nœuds Linux nouveaux et existants. Elle configure les outils de surveillance suivants :

• Node-exporter : collecte les données de télémétrie matérielles à partir de la machine virtuelle et les rend disponibles en utilisant un point de terminaison de métriques. Ensuite, un outil de monitoring, tel que Prometheus, peut supprimer ces métriques.
• Node-problem-detector : Vise à rendre différents problèmes de nœud visibles par les couches en amont de la pile de gestion du cluster. Il s’agit d’une unité système qui s’exécute sur chaque nœud, détecte les problèmes de nœud et les signale au serveur d’API du cluster en tirant parti de Events et NodeConditions.
• ig : est une infrastructure open source basée sur eBPF pour le débogage et l’observation de systèmes Linux et Kubernetes. Il fournit un ensemble d’outils (ou gadgets) qui recueille des informations pertinentes que les utilisateurs peuvent utiliser pour identifier la cause des problèmes de performances, des incidents ou d’autres anomalies. Par ailleurs, son indépendance vis-à-vis de Kubernetes permet aux utilisateurs de l’utiliser aussi pour le débogage de problèmes liés au plan de contrôle.

Ces outils permettent de fournir une observabilité autour de nombreux problèmes liés à l’intégrité des nœuds, tels que :

• Problèmes de démon d’infrastructure : service NTP arrêté
• Problèmes matériels : processeur, mémoire ou disque incorrects
• Problèmes de noyau : blocage du noyau, système de fichiers endommagé
• Problèmes d’exécution de conteneur : démon d’exécution sans réponse

L’extension ne nécessite pas d’accès sortant supplémentaire aux URL, adresses IP ou ports au-delà des exigences de sortie AKS documentées. Elle ne nécessite aucune autorisation spéciale accordée dans Azure. Il utilise kubeconfig pour se connecter au serveur d’API pour envoyer les données de monitoring collectées.

Résoudre les problèmes de cluster

Pourquoi la suppression de mon cluster prend-elle autant de temps ?

La plupart des clusters sont supprimés à la demande de l’utilisateur. Dans certains cas, en particulier lorsque vous apportez votre propre groupe de ressources ou effectuez des tâches inter-ressources, la suppression peut prendre plus de temps ou même échouer. Si vous rencontrez un problème avec les suppressions, revérifiez que vous n’avez pas de verrous sur le groupe de ressources. Assurez-vous également que toutes les ressources en dehors du groupe de ressources sont dissociées du groupe de ressources.

Pourquoi la création ou la mise à jour de mon cluster prend-elle autant de temps ?

Si vous rencontrez des problèmes lors de la création et de la mise à jour de clusters, vérifiez que vous n’avez pas de stratégies ou de contraintes de service affectées qui peuvent peut-être empêcher votre cluster AKS de gérer des ressources telles que des machines virtuelles, des équilibreurs de charge ou des balises.

Si j’ai des pods ou des déploiements dans des états NodeLost ou Inconnu, puis-je encore mettre à niveau mon cluster ?

Vous pouvez, mais nous vous le déconseillons. Effectuez des mises à jour lorsque l’état du cluster est connu et sain.

Si j’ai un cluster avec un ou plusieurs nœuds dans un état non sain, ou s’il est arrêté, puis-je effectuer une mise à niveau ?

Non. Supprimez les nœuds dans un état d’échec ou, dans le cas contraire, à partir du cluster avant d’effectuer la mise à niveau.

J’ai essayé de supprimer mon cluster, mais j’ai vu l’erreur « [Errno 11001] getaddrinfo a échoué. »

La plupart du temps, cette erreur se produit si vous avez un ou plusieurs groupes de sécurité réseau en cours d’utilisation et toujours associés au cluster. Supprimez-les, puis tentez de supprimer à nouveau le cluster.

J’ai exécuté une mise à niveau, mais mes pods se trouvent maintenant dans des boucles d’incident et les sondes de préparation échouent.

Confirmez que votre principal de service n’a pas expiré. Pour découvrir plus d’informations, consultez le principal de service AKS et les informations d’identification de mise à jour AKS.

Mon cluster fonctionnait, mais soudainement, je ne peux pas approvisionner des équilibreurs de charge ou monter des revendications de volume persistant.

Confirmez que votre principal de service n’a pas expiré. Pour découvrir plus d’informations, consultez le principal de service AKS et les informations d’identification de mise à jour AKS.

Cet article apporte des réponses à certaines des questions les plus fréquemment posées sur Azure Kubernetes Service (AKS).

AKS fournit des garanties de contrat de niveau de service (SLA) dans le niveau tarifaire Standard avec la fonctionnalité Contrat SLA de durée de bon fonctionnement.

La prise en charge de la plateforme est un plan de support réduit pour les clusters de version n-3 non pris en charge. La prise en charge de la plateforme inclut uniquement la prise en charge de l’infrastructure Azure.

Pour plus d’informations, consultez la politique de support de la plateforme.

Oui, AKS lance des mises à niveau automatiques pour les clusters non pris en charge. Lorsqu’un cluster dans une version n-3 (où n est la dernière version mineure d’AKS prise en charge qui est en disponibilité générale) est sur le point de passer à n-4, AKS met automatiquement à niveau le cluster vers n-2 pour rester dans une stratégie de support AKS.

Pour plus d’informations, consultez Versions Kubernetes prises en charge, Fenêtres de maintenance planifiée et Mises à niveau automatiques.

Oui, AKS prend également en charge les conteneurs Windows Server. Pour plus d’informations, consultez la FAQ Windows Server sur AKS.

Les nœuds de l’agent AKS sont facturés en tant que machines virtuelles Azure standard. Si vous avez acheté des réservations Azure pour la taille de machine virtuelle que vous utilisez dans AKS, ces remises sont automatiquement appliquées.

Non. Le déplacement de votre cluster AKS entre locataires n’est actuellement pas pris en charge.

Non. Le déplacement de votre cluster AKS d’un abonnement à un autre n’est actuellement pas pris en charge.

Non. Le déplacement ou le changement de nom de votre cluster AKS et des ressources associées ne sont pas pris en charge.

Non. Vous ne pouvez pas restaurer votre cluster une fois que vous l’avez supprimé. Quand vous supprimez votre cluster, le groupe de ressources du nœud et toutes ses ressources sont également supprimés.

Si vous souhaitez conserver l’une de vos ressources, déplacez-les vers un autre groupe de ressources avant la suppression de votre cluster. Si vous souhaitez vous protéger contre les suppressions accidentelles, vous pouvez verrouiller le groupe de ressources managé AKS qui héberge vos ressources de cluster en utilisant un Verrouillage du groupe de ressources de nœud.

Vous pouvez complètement arrêter un cluster AKS en cours d’exécution ou mettre à l’échelle ou mettre à l’échelle automatiquement tout ou partie des pools de nœuds User à zéro.

Vous ne pouvez pas mettre directement à l’échelle des pools de nœuds système sur 0.

Non. Les opérations de mise à l’échelle qui utilisent les API de groupe de machines virtuelles identiques ne sont pas prises en charge. Vous pouvez utiliser les API AKS (az aks scale).

Non. Les opérations de mise à l’échelle qui utilisent les API de groupe de machines virtuelles identiques ne sont pas prises en charge. Vous pouvez utiliser l’API AKS pour mettre à l’échelle sur zéro des pools de nœuds non système ou arrêter votre cluster à la place.

Non. Cette configuration n’est pas prise en charge. Arrêtez votre cluster à la place.

AKS s’appuie sur différentes ressources de l’infrastructure Azure, notamment les groupes de machines virtuelles identiques, réseaux virtuels et disques managés. Ces intégrations vous permettent d’appliquer de nombreuses fonctionnalités essentielles de la plateforme Azure dans l’environnement Kubernetes managé fourni par AKS. Par exemple, vous pouvez utiliser la majorité des types de machines virtuelles Azure directement avec AKS et vous pouvez utiliser Réservations Azure pour recevoir automatiquement des remises sur ces ressources.

Pour permettre cette architecture, chaque déploiement AKS s’étend sur deux groupes de ressources :

1. Vous créez le premier groupe de ressources. Ce groupe contient uniquement la ressource de service Kubernetes. Le fournisseur de ressources AKS crée automatiquement le second groupe de ressources au cours du déploiement. Un exemple du second groupe de ressources est MC_myResourceGroup_myAKSCluster_eastus. Pour obtenir des informations sur la façon de spécifier le nom de ce second groupe de ressources, consultez la section suivante.
2. Le second groupe de ressources, nommé groupe de ressources de nœud, contient toutes les ressources d’infrastructure associées au cluster. Ces ressources incluent les machines virtuelles de nœud Kubernetes, la mise en réseau et le stockage. Par défaut, le nom du groupe de ressources de nœud ressemble à ceci : MC_myResourceGroup_myAKSCluster_eastus. AKS supprime automatiquement le groupe de ressources de nœud quand vous supprimez le cluster. Utilisez ce groupe de ressources uniquement pour les ressources qui partagent le cycle de vie du cluster.

Remarque

La modification d’une ressource sous le groupe de ressources du nœud dans le cluster AKS est une action non prise en charge qui entraîne des échecs d’opération dans le cluster. Vous pouvez empêcher les modifications apportées au groupe de ressources de nœud. Empêcher les utilisateurs de modifier les ressources gérées par le cluster AKS.

Par défaut, AKS nomme le groupe de ressources de nœud MC_resourcegroupname_clustername_location, mais vous pouvez fournir votre propre nom.

Pour spécifier votre propre nom de groupe de ressources, installez la version 0.3.2 ou une version ultérieure de l’extension Azure CLI aks-preview. Lorsque vous créez un cluster AKS à l’aide de la commande az aks create, utilisez le paramètre --node-resource-group et spécifiez un nom pour le groupe de ressources. Si vous utilisez un modèle Azure Resource Manager pour déployer un cluster AKS, vous pouvez définir le nom du groupe de ressources en tirant parti de la propriété nodeResourceGroup.

• Le fournisseur de ressources Azure crée automatiquement le groupe de ressources secondaire.
• Vous pouvez spécifier un nom de groupe de ressources personnalisé uniquement lors de la création du cluster.

Lorsque vous travaillez avec le groupe de ressources de nœud, vous ne pouvez pas :

• Spécifier un groupe de ressources existant pour le groupe de ressources de nœud.
• Spécifier un autre abonnement pour le groupe de ressources de nœud.
• Modifier le nom du groupe de ressources de nœud après avoir créé le cluster.
• Spécifier des noms pour les ressources managées au sein du groupe de ressources de nœud.
• Modifier ni supprimer les étiquettes des ressources managées créées par Azure au sein du 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 si vous modifiez ou supprimez des balises créées par Azure et d’autres propriétés de ressources dans le groupe de ressources de nœud. AKS vous permet de créer et de modifier des balises personnalisées créées par les utilisateurs finaux et vous pouvez ajouter ces balises lorsque vous créez un pool de nœuds. 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. Une autre option consiste à appliquer des stratégies et à modifier des balises via la ressource AKS elle-même, en particulier via le cluster et les pools de nœuds.

Les balises créées par Azure sont créées pour leurs services Azure respectifs et vous devez toujours les autoriser. Pour AKS, il s’agit des balises aks-managed et k8s-azure. 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).

Remarque

Dans le passé, le nom de balise Owner était réservé à AKS pour gérer l’adresse IP publique affectée sur l’adresse IP front-end de l’équilibreur de charge. À présent, les services utilisent le préfixe aks-managed. Pour les ressources héritées, n’utilisez pas de stratégies Azure pour appliquer le nom de balise Owner. Si vous les utilisez, toutes les ressources de votre déploiement de cluster AKS et les opérations de mise à jour s’interrompent. Cette restriction ne s’applique pas aux ressources nouvellement créées.

AKS utilise Helm pour fournir des composants à votre cluster. Vous pouvez ignorer en toute sécurité les versions de Helm avec préfixe aks-managed. L’augmentation continue des révisions sur ces versions Helm est prévue et sécurisée.

Pour obtenir la liste complète des régions disponibles, consultez Régions AKS et disponibilité.

Non. Les clusters AKS sont des ressources régionales et ne peuvent pas s’étendre sur plusieurs régions. Pour obtenir de l’aide pour la création d’une architecture qui inclut plusieurs régions, consultez les meilleures pratiques en matière de continuité d’activité et de reprise d’activité.

Oui, vous pouvez déployer un cluster AKS sur une ou plusieurs zones de disponibilité dans les régions qui les prennent en charge.

Oui, vous pouvez utiliser des tailles de machine virtuelle différentes dans votre cluster AKS en créant plusieurs pools de nœuds.

AKS ne définit pas de limite concernant la taille des images conteneur. Mais plus l’image est grande, plus la demande de mémoire est élevée. Une taille plus grande risque potentiellement de dépasser les limites de ressources ou la mémoire disponible globale des nœuds Worker. Par défaut, la mémoire pour la taille de la machine virtuelle Standard_DS2_v2 pour un cluster AKS est définie sur 7 Gio.

Lorsqu’une image conteneur est excessivement volumineuse, comme dans la plage de téraoctets (To), il est possible que le kubelet ne soit pas en mesure de l’extraire de votre registre de conteneurs vers un nœud en raison du manque d’espace disque.

Pour les nœuds Windows Server, Windows Update n’exécute pas et n’applique pas automatiquement les dernières mises à jour. Vous devez effectuer une mise à niveau sur le cluster et les pools de nœuds Windows Server de votre cluster AKS. Suivez une planification régulière en fonction du cycle de publication de Windows Update et de votre propre processus de validation. Ce processus de mise à niveau crée des nœuds qui exécutent la dernière image et les derniers correctifs Windows Server, puis supprime les anciens nœuds. Pour plus d’informations sur ce processus, consultez Mettre à niveau un pool de nœuds dans AKS.

Les images suivantes ont des exigences fonctionnelles pour s’exécuter en tant que racine. Les exceptions doivent être déposées pour toutes les stratégies :

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Oui, il existe deux options pour limiter l’accès au serveur d’API :

• Utilisez des Plages d’adresses IP autorisées du serveur d’API si vous souhaitez conserver un point de terminaison public pour le serveur d’API, mais restreindre l’accès à un ensemble de plages d’adresses IP approuvées.
• Utilisez un cluster privé si vous souhaitez limiter le serveur d’API à être accessible uniquement à partir de votre réseau virtuel.

AKS corrige les CVE qui ont un correctif de fournisseur chaque semaine. Les CVE sans correctif attendent un correctif de fournisseur avant de pouvoir être corrigés. Les images AKS sont automatiquement mises à jour dans les 30 jours. Nous vous recommandons d’appliquer une image de nœud mise à jour à une cadence régulière pour vous assurer que les dernières images correctives et correctifs du système d’exploitation sont tous appliqués et actuels. Vous pouvez effectuer cette tâche :

• Manuellement, via le portail Azure ou l’interface de ligne de commande Azure.
• En mettant à niveau votre cluster AKS. Le cluster met automatiquement à niveau le cordon et vide les nœuds. Il apporte ensuite un nouveau nœud en ligne avec la dernière image Ubuntu et une nouvelle version de correctif ou une version mineure de Kubernetes. Pour plus d’informations, consultez Mettre à niveau un cluster AKS.
• À l’aide d’une mise à niveau d’image de nœud.

Microsoft fournit des conseils pour d’autres actions que vous pouvez effectuer pour sécuriser vos charges de travail via des services comme Microsoft Defender pour les conteneurs. Pour découvrir plus d’informations sur une menace de sécurité liée à AKS et Kubernetes, consultez Nouvelles cibles de campagne à grande échelle Kubeflow (8 juin 2021).

Non. Toutes les données sont stockées dans la région du cluster.

Traditionnellement, si votre pod s’exécute en tant qu’utilisateur non racine (et il devrait l’effectuer), vous devez spécifier un paramètre fsGroup dans le contexte de sécurité du pod afin que le volume soit lisible et accessible en écriture par le pod. Pour découvrir plus d’informations sur cette exigence, consultez Configurer un contexte de sécurité pour un pod ou un conteneur.

Un effet secondaire de la définition fsGroup est que lors de chaque montage de volume, Kubernetes doit utiliser les commandes chown() et chmod() de manière récursive pour tous les fichiers et répertoires dans le volume (avec quelques exceptions). Ce scénario se produit même si la propriété du groupe du volume correspond déjà au paramètre fsGroup demandé. Il est possible que cette configuration soit coûteuse pour les volumes plus volumineux avec un grand nombre de petits fichiers, pouvant entraîner un démarrage beaucoup plus long des pods. Ce scénario était un problème connu avant la version 1.20. La solution de contournement consiste à définir le pod pour l’exécuter en tant que racine :

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Le problème a été résolu avec Kubernetes dans la version 1.20. Pour découvrir plus d’informations, consultez Kubernetes 1.20 : Contrôle granulaire des modifications d’autorisation de volume.

AKS utilise une communication de tunnel sécurisée pour permettre au api-server et aux kubelets de nœud individuel de communiquer, même sur des réseaux virtuels distincts. Le tunnel est sécurisé via le chiffrement mutuel du protocole TLS. Le tunnel principal actuel que AKS utilise est Konnectivity, antérieurement appelé apiserver-network-proxy. Vérifiez que toutes les règles réseau suivent les règles réseau Azure requises et les noms de domaine complets (FQDN).

Oui, vous pouvez ajouter l’annotation kubernetes.azure.com/set-kube-service-host-fqdn aux pods pour définir la variable KUBERNETES_SERVICE_HOST sur le nom de domaine du serveur d’API au lieu de l’IP du service dans le cluster. Cette modification est utile si votre sortie de cluster est effectuée via un pare-feu de couche 7. Par exemple, lorsque vous utilisez Pare-feu Azure avec des règles d’application.

AKS n’applique pas de groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie aucun des groupes de sécurité réseau associés à ce sous-réseau. AKS modifie uniquement les paramètres du groupe de sécurité réseau de l’interface réseau. Si vous utilisez l’interface réseau de conteneur (CNI), vous devez également veiller à ce que les règles de sécurité dans les groupes de sécurité réseau autorisent le trafic entre les plages de routage CIDR (Classless InterDomain Routing) de nœud et de pod. Si vous utilisez kubenet, vous devez également vous veiller à ce que les règles de sécurité dans les groupes de sécurité réseau autorisent le trafic entre le nœud et le CIDR du pod. Pour plus d’informations, consultez Groupes de sécurité réseau.

Les nœuds AKS exécutent le service chrony qui extrait le temps à partir de l’hôte local. Les conteneurs qui s’exécutent sur des pods obtiennent le temps des nœuds AKS. Les applications qui s’ouvrent dans un conteneur utilisent le temps à partir du conteneur du pod.

Non. AKS est un service géré. La manipulation des ressources IaaS (Infrastructure as a Service) n’est pas prise en charge. Pour installer des composants personnalisés, utilisez les mécanismes et les API Kubernetes. Par exemple, utilisez DaemonSets pour installer tout composant requis.

AKS prend en charge les contrôleurs d’admission suivants :

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Actuellement, vous ne pouvez pas modifier la liste des contrôleurs d’admission dans AKS.

Oui, vous pouvez utiliser des webhooks de contrôleur d’admission dans AKS. Nous vous recommandons d’exclure les espaces de noms AKS internes qui sont marqués avec l’étiquette control-plane. Exemple :

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS protège via un pare-feu la sortie du serveur d’API pour que l’accessibilité à vos webhooks de contrôleur d’admission soit nécessaire à partir du cluster.

Pour protéger la stabilité du système et empêcher les contrôleurs d’admission personnalisés d’affecter les services internes dans l’espace de noms kube-system, AKS dispose d’un application d’admission qui exclut automatiquement kube-system et les espaces de noms internes AKS. Ce service veille à ce que les contrôleurs d’admission personnalisés n’affectent pas les services qui s’exécutent dans kube-system.

Si vous avez un cas d’usage critique pour déployer un élément sur kube-system (non recommandé) dans le support de votre webhook d’admission personnalisé, vous pouvez ajouter l’étiquette ou l’annotation suivante afin que l’exécuteur des admissions l’ignore :

• Étiquette : "admissions.enforcer/disabled": "true"
• Annotation : "admissions.enforcer/disabled": true

Le fournisseur Azure Key Vault pour Secrets Store CSI Driver fournit une intégration native d’Azure Key Vault à AKS.

Les nœuds activés avec les normes FIPS (Federal Information Processing Standard) sont désormais pris en charge sur les pools de nœuds Linux. Pour plus d’informations, consultez Ajouter un pool de nœuds compatibles FIPS.

Tout correctif, y compris un correctif de sécurité, est automatiquement appliqué au cluster AKS. Tout ce qui est plus grand qu’un correctif, comme les modifications de version majeures ou mineures (qui peuvent avoir des changements cassants pour vos objets déployés), est mis à jour lorsque vous mettez à jour votre cluster si une nouvelle version est disponible. Pour découvrir plus d’informations sur la disponibilité d’une nouvelle version, consultez les notes de publication AKS.

L’extension Linux AKS est une extension de machine virtuelle Azure qui installe et configure des outils de monitoring sur des nœuds Worker Kubernetes. L’extension est installée sur tous les nœuds Linux nouveaux et existants. Elle configure les outils de surveillance suivants :

• Node-exporter : collecte les données de télémétrie matérielles à partir de la machine virtuelle et les rend disponibles en utilisant un point de terminaison de métriques. Ensuite, un outil de monitoring, tel que Prometheus, peut supprimer ces métriques.
• Node-problem-detector : Vise à rendre différents problèmes de nœud visibles par les couches en amont de la pile de gestion du cluster. Il s’agit d’une unité système qui s’exécute sur chaque nœud, détecte les problèmes de nœud et les signale au serveur d’API du cluster en tirant parti de Events et NodeConditions.
• ig : est une infrastructure open source basée sur eBPF pour le débogage et l’observation de systèmes Linux et Kubernetes. Il fournit un ensemble d’outils (ou gadgets) qui recueille des informations pertinentes que les utilisateurs peuvent utiliser pour identifier la cause des problèmes de performances, des incidents ou d’autres anomalies. Par ailleurs, son indépendance vis-à-vis de Kubernetes permet aux utilisateurs de l’utiliser aussi pour le débogage de problèmes liés au plan de contrôle.

Ces outils permettent de fournir une observabilité autour de nombreux problèmes liés à l’intégrité des nœuds, tels que :

• Problèmes de démon d’infrastructure : service NTP arrêté
• Problèmes matériels : processeur, mémoire ou disque incorrects
• Problèmes de noyau : blocage du noyau, système de fichiers endommagé
• Problèmes d’exécution de conteneur : démon d’exécution sans réponse

L’extension ne nécessite pas d’accès sortant supplémentaire aux URL, adresses IP ou ports au-delà des exigences de sortie AKS documentées. Elle ne nécessite aucune autorisation spéciale accordée dans Azure. Il utilise kubeconfig pour se connecter au serveur d’API pour envoyer les données de monitoring collectées.

La plupart des clusters sont supprimés à la demande de l’utilisateur. Dans certains cas, en particulier lorsque vous apportez votre propre groupe de ressources ou effectuez des tâches inter-ressources, la suppression peut prendre plus de temps ou même échouer. Si vous rencontrez un problème avec les suppressions, revérifiez que vous n’avez pas de verrous sur le groupe de ressources. Assurez-vous également que toutes les ressources en dehors du groupe de ressources sont dissociées du groupe de ressources.

Si vous rencontrez des problèmes lors de la création et de la mise à jour de clusters, vérifiez que vous n’avez pas de stratégies ou de contraintes de service affectées qui peuvent peut-être empêcher votre cluster AKS de gérer des ressources telles que des machines virtuelles, des équilibreurs de charge ou des balises.

Vous pouvez, mais nous vous le déconseillons. Effectuez des mises à jour lorsque l’état du cluster est connu et sain.

Non. Supprimez les nœuds dans un état d’échec ou, dans le cas contraire, à partir du cluster avant d’effectuer la mise à niveau.

La plupart du temps, cette erreur se produit si vous avez un ou plusieurs groupes de sécurité réseau en cours d’utilisation et toujours associés au cluster. Supprimez-les, puis tentez de supprimer à nouveau le cluster.

Confirmez que votre principal de service n’a pas expiré. Pour découvrir plus d’informations, consultez le principal de service AKS et les informations d’identification de mise à jour AKS.

Confirmez que votre principal de service n’a pas expiré. Pour découvrir plus d’informations, consultez le principal de service AKS et les informations d’identification de mise à jour AKS.