Questions fréquentes (FAQ) sur AKS

AKS fournit des garanties SLA dans le niveau tarifaire Standard avec la fonctionnalité SLA de durée de fonctionnement.

Le support de plateforme est un plan de support réduit des clusters en version « N-3 » non pris en charge. Le support de 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. Si un cluster en version N-3 (où N est la dernière version mineure d’AKS en disponibilité générale prise en charge) est sur le point de passer à une version N-4, AKS met automatiquement à niveau le cluster vers la version 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 pas pris en charge actuellement.

Non, le déplacement de votre cluster AKS entre abonnements n’est pas pris en charge actuellement.

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

Non, vous ne pouvez pas restaurer votre cluster après l’avoir 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 de supprimer votre cluster. Si vous voulez une protection contre les suppressions accidentelles, vous pouvez verrouiller le groupe de ressources géré par AKS hébergeant vos ressources de cluster en utilisant le Verrouillage de groupe de ressources du 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 avec 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 avec les API de groupe de machines virtuelles identiques ne sont pas prises en charge. Vous pouvez utiliser l’API AKS pour mettre à l’échelle les pools de nœuds non-système sur 0 ou sinon arrêter votre cluster.

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

AKS s’appuie sur différentes ressources de l’infrastructure Azure, notamment des Virtual Machine Scale Sets, des réseaux virtuels et des 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, la plupart des machines virtuelles Azure peuvent être directement utilisées avec AKS. En outre, les Réservations Azure permettent de bénéficier automatiquement de 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. Vous devez utiliser ce groupe de ressources uniquement pour les ressources qui partagent le cycle de vie du cluster.

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. Quand vous créez un cluster AKS à l’aide de la commande [az aks create][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 à l’aide 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 lorsque vous créez le cluster.

Lorsque vous travaillez avec le groupe de ressources de nœud, n’oubliez pas que 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 une fois que le cluster a été créé.
• 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. Vous pouvez ajouter ces balises lors de la création d’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 à créer des stratégies Azure avec une étendue sur le groupe de ressources managé.

Les balises créées par Azure sont liées à leurs services Azure respectifs et doivent toujours être autorisées. 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).

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 qui ne peuvent pas s’étendre sur plusieurs régions. Consultez les meilleures pratiques relatives à la continuité d’activité et reprise d’activité pour obtenir des conseils sur la façon de créer une architecture qui comprend plusieurs régions.

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 différentes tailles de machines virtuelles 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. Toutefois, il est important de comprendre que plus l’image est grande, plus la demande en 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 trop volumineuse, dans la plage To par exemple, kubelet peut ne pas être en mesure de l’extraire de votre registre de conteneurs vers un nœud en raison d’un 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. Suivez une planification régulière basée sur le cycle de mise à jour de Windows et votre propre processus de validation pour effectuer une mise à niveau sur le cluster ou le ou les pools de nœuds Windows Server dans votre cluster AKS. Ce processus de mise à niveau crée des nœuds qui exécutent la dernière image et les derniers correctifs de 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 « Exécuter en tant que racine » et les exceptions doivent être classées pour toute stratégie :

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

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

AKS corrige les CVE qui ont un « correctif fournisseur » chaque semaine. Les CVE qui n’ont pas été corrigés sont en attente d’un correctif du fournisseur avant de pouvoir être corrigés. Les images AKS sont automatiquement mises à jour dans un délai de 30 jours. Nous vous recommandons d’appliquer une image de nœud mise à jour à intervalles réguliers pour veiller à ce que les images corrigées et les correctifs de système d’exploitation les plus récents soient tous appliqués et à jour. Pour ce faire, vous pouvez utiliser l’une des méthodes suivantes :

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

Microsoft fournit des conseils sur les actions supplémentaires possibles pour sécuriser vos charges de travail à l’aide de services comme Microsoft Defender pour les conteneurs. Voici la menace de sécurité relative à AKS et Kubernetes que vous devez connaître :

• Une nouvelle campagne à grande échelle cible Kubeflow (8 juin 2021).

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

En règle générale, si votre pod s’exécute en tant qu’utilisateur non racine (ce qui est normalement le cas), vous devez spécifier un fsGroup dans son contexte de sécurité pour lui permettre d’accéder au volume en lecture et en écriture. Cette exigence est détaillée ici.

Un effet secondaire de la définition de fsGroup est que chaque fois qu’un volume est monté, Kubernetes doit chown() et chmod() de manière récursive tous les fichiers et répertoires à l’intérieur du volume (avec quelques indiquées ci-dessous). Ce scénario se produit même si la propriété du groupe du volume correspond déjà au fsGroup demandé. Cela peut coûter cher pour des volumes plus importants avec beaucoup de petits fichiers, ce qui peut causer un ralentissement au démarrage du pod. Ce scénario relevait d’un problème connu avant la version v1.20 et la solution de contournement consiste à définir l’exécution du pod 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 version 1.20. Pour 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 serveur d’API et aux kubelets de nœuds individuels de communiquer même sur des réseaux virtuels distincts. Le tunnel est sécurisé via le chiffrement mTLS. Le tunnel principal actuel utilisé par AKS est Konnectivity, précédemment appelé apiserver-network-proxy. Vérifiez que toutes les règles réseau suivent les règles réseau et les FQDN requis par Azure.

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. Cela est utile dans les cas où la sortie de votre cluster se fait avec un pare-feu de couche 7, par exemple, quand vous utilisez le Pare-feu Azure avec des règles d’application.

AKS n’applique pas les groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie pas les NSG associés à ce sous-réseau. AKS modifie uniquement les paramètres des groupes de sécurité réseau des interfaces réseau. Si vous utilisez CNI, vous devez également vous assurer que les groupes de sécurité réseau autorisent le trafic entre les plages CIDR du nœud et du Pod. Si vous utilisez kubenet, vous devez également vous assurer que les groupes de sécurité réseau autorisent le trafic entre les plages CIDR du nœud et du pod. Pour plus d’informations, consultez Groupes de sécurité réseau.

Les nœuds AKS exécutent le service « chrony » qui extrait l’heure de localhost. Les conteneurs s’exécutant sur des pods obtiennent l’heure des nœuds AKS. Les applications lancées à l’intérieur d’un conteneur utilisent l’heure à partir du conteneur du pod.

Non, AKS est un service géré et la manipulation des ressources IaaS n’est pas prise en charge. Pour installer des composants personnalisés, utilisez les mécanismes et les API Kubernetes. Par exemple, utilisez des DaemonSets pour installer les composants nécessaires.

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. Il est recommandé d’exclure les espaces de noms AKS internes, qui sont signalés par l’étiquette control-plane. Par exemple :

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

AKS protège par un pare-feu la sortie du serveur d’API. Vous devez donc accéder aux webhooks du contrôleur d’admission à partir du cluster.

Pour maintenir la stabilité du système et empêcher les contrôleurs d’admission personnalisés d’avoir un impact sur les services internes de kube-system, l’espace de noms AKS comprend un exécuteur d’admission, qui exclut automatiquement les espaces de noms kube-system et AKS internes. Ce service garantit que les contrôleurs d’admission personnalisés n’affecteront pas les services exécutés dans kube-system.

Si vous avez un cas d’usage critique dans lequel déployer un élément sur kube-system (non recommandé) couvert par votre webhook d’admission personnalisé, vous pouvez ajouter l’étiquette ou l’annotation suivante pour que l’exécuteur d’admission l’ignore.

Étiquette : "admissions.enforcer/disabled": "true" ou annotation : "admissions.enforcer/disabled": true

Fournisseur Azure Key Vault pour le pilote Secrets Store CSI offre une intégration native d’Azure Key Vault dans AKS.

Les nœuds compatibles FIPS sont maintenant pris en charge sur les pools de nœuds basés sur 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 majeure ou mineure (qui peuvent avoir des changements cassants de vos objets déployés), est mis à jour lorsque vous mettez à jour votre cluster si une nouvelle mise en production est disponible. Pour savoir quand une nouvelle mise en production est disponible, consultez les notes de publication d’AKS.

L’extension AKS Linux est une extension de machine virtuelle Azure qui installe et configure des outils de supervision 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 des données de télémétrie matérielle de la machine virtuelle et les rend disponibles à l’aide d’un point de terminaison de métriques. Ensuite, un outil de surveillance, tel que Prometheus, peut extraire 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 des problèmes de nœud et les signale au serveur d’API du cluster à l’aide d’Events et de NodeConditions.
• ig : infrastructure open source avec eBPF pour le débogage et l’observation des systèmes Linux et Kubernetes. Elle fournit un ensemble d’outils (ou gadgets) conçus pour collecter des informations pertinentes qui permettent aux utilisateurs d’identifier la cause de problèmes de performances, d’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 peuvent proposer 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 en panne
• Problèmes matériels : processeur, mémoire ou disque défectueux
• Problèmes de noyau : blocage du noyau, système de fichiers endommagé
• Problèmes liés au runtime de conteneur : démon d’exécution qui ne répond pas

L’extension ne nécessite aucun 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. Elle utilise kubeconfig pour se connecter au serveur d’API afin d’envoyer les données de surveillance 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-RG, la suppression peut prendre plus de temps, voire échouer. Si vous rencontrez un problème avec les suppressions, vérifiez que le groupe de ressources ne contient aucun verrou, que toutes les ressources en dehors du groupe sont dissociées, et ainsi de suite.

Si vous rencontrez des problèmes liés à la création et à la mise à jour des opérations de cluster, assurez-vous que vous n’avez aucune stratégie ou contrainte de service affectée qui peut empêcher votre cluster AKS de gérer les ressources telles que les machines virtuelles, les équilibreurs de charge, les balises, etc.

Vous pouvez, mais nous vous le déconseillons. Vous devriez effectuer les mises à niveau lorsque l’état du cluster est connu et sain.

Non, supprimez tout nœud du en état d’échec ou autre dans le cluster avant la mise à niveau.

Le plus souvent, cette erreur se produit si vous avez un ou plusieurs groupes de sécurité réseau (NSG) encore en cours d’utilisation qui sont associés au cluster. Supprimez-les, puis réessayez la suppression.

Vérifiez que votre principal de service n’a pas expiré. Consultez Principal de service AKS et Informations d’identification pour la mise à jour d’AKS.

Vérifiez que votre principal de service n’a pas expiré. Consultez Principal de service AKS et Informations d’identification pour la mise à jour d’AKS.