Forum aux questions sur Azure Kubernetes Service (AKS)

Article
11/06/2023

Cet article aborde les questions fréquemment posées sur Azure Kubernetes Service (AKS).

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

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 limiter qui a accès au serveur d’API Kubernetes ?

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.

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

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

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 fournisseur » chaque semaine. Les CVE sans correctif attendent un « correctif fournisseur » pour 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.

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

Nœuds Windows Server

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.

Existe-t-il des menaces de sécurité relatives à AKS que je dois connaître ?

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

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

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

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

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 :

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.
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 cluster uniquement pour les ressources qui partagent le cycle de vie du cluster.

Notes

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 du nœud en bloquant la modification par les utilisateurs des ressources gérées par le cluster AKS.

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

Oui. Par défaut, AKS nomme le groupe de ressources de nœud MC_resourcegroupname_clustername_location, mais vous pouvez également entrer 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 à 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. Consultez des informations supplémentaires dans la section suivante.

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. 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 plus d'informations, consultez AKS offre-t-il un contrat de niveau de service ?

Remarque

Auparavant, le nom de balise « Owner » était réservé à AKS pour la gestion de l’adresse IP publique affectée sur l’adresse IP front-end de l’équilibreur de charge. À présent, les services suivent l’utilisation du préfixe aks-managed. Pour les ressources héritées, évitez d’utiliser des stratégies Azure dans le cadre de l’application du nom de balise « Propriétaire ». Si vous les utilisez, toutes les ressources de votre déploiement de cluster AKS et les opérations de mise à jour s’interrompent. Cette recommandation ne s’applique pas aux ressources nouvellement créées.

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

Les webhooks de contrôleur d’admission peuvent-ils avoir un impact sur les espaces de noms kube-system et AKS internes ?

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

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

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

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

Oui, les conteneurs Windows Server sont disponibles dans AKS. Pour exécuter des conteneurs Windows Server dans AKS, vous créez un pool de nœuds qui exécute Windows Server en tant que système d’exploitation invité. Les conteneurs Windows Server peuvent utiliser uniquement Windows Server 2019. Pour commencer, consultez Créer un cluster AKS avec un pool de nœuds Windows Server.

La prise en charge des pools de nœuds dans Windows Server comprend certaines limitations qui font partie du projet amont Windows Server dans Kubernetes. Pour plus d’informations sur ces limitations, consultez Limitations des conteneurs Windows Server dans AKS.

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

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

Le niveau tarifaire Gratuit n’est associé à aucun Contrat de niveau de service, mais son objectif de niveau de service s’élève à 99,5 %. Il peut arriver que des problèmes de connectivité temporaires surviennent en cas de mise à niveau, de nœuds Underlay non sains, de maintenance de la plateforme, d’application inondant le serveur d’API de demandes, etc. Pour les charges de travail stratégiques et de production, ou si votre charge de travail ne tolère pas les redémarrages du serveur d’API, nous vous recommandons d’utiliser le niveau Standard qui inclut un contrat SLA de durée de fonctionnement.

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.

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

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

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

Désolé... Le déplacement des clusters entre des abonnements n’est pas pris en charge pour le moment.

Puis-je déplacer mes clusters AKS de l’abonnement Azure actuel vers un autre abonnement ?

Le déplacement de votre cluster AKS et des ressources associées entre des abonnements Azure n’est 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 ?

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

Pourquoi la suppression de mon cluster est-elle si longue ?

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.

Pourquoi la mise à jour/création de mon cluster est-elle si longue ?

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.

Est-ce que je peux restaurer mon cluster après l’avoir supprimé ?

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. Un exemple du second groupe de ressources est MC_myResourceGroup_myAKSCluster_eastus.

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.

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

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. La prise en charge de la plateforme n’inclut aucun élément lié à ce qui suit :

Fonctionnalités et composants Kubernetes
Création d’un cluster ou d’un pool de nœuds
Correctifs logiciels
Résolution des bogues
Correctifs de sécurité
Composants mis hors service

Pour plus d’informations sur les restrictions, consultez la politique de prise en charge de la plateforme.

AKS s’appuie sur les versions et les correctifs de Kubernetes, qui est un projet Open Source qui ne prend en charge qu’une fenêtre glissante de trois versions mineures. AKS ne peut garantir un support complet que lorsque ces versions sont en cours de maintenance vers une version amont. Plus aucun patch amont n’étant produit, AKS peut laisser ces versions non corrigées ou les dupliquer. En raison de cette limite, le support de plateforme ne prend aucun élément en charge s’appuyant sur Kubernetes en amont.

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

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. La mise à niveau automatique d’un cluster inclus dans le support de plateforme vers une version prise en charge est activée par défaut.

Par exemple, Kubernetes v1.25 est mis à niveau vers la version v1.26 lors de la publication de la version v1.29 en disponibilité générale. Pour réduire les interruptions, configurez les fenêtres de maintenance. Pour plus d’informations sur les canaux de mise à niveau automatique, consultez Mise à niveau automatique.

Si j'ai des pods/déploiements à l'état 'NodeLost' ou 'Unknown', puis-je quand même mettre à niveau mon cluster ?

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

Si j'ai un cluster avec un ou plusieurs nœuds à l’état Unhealthy (non sain) ou shut down (arrêté), puis-je effectuer une mise à niveau ?

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

J'ai lancé une suppression de cluster, mais l'erreur `[Errno 11001] getaddrinfo failed` s’affiche

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.

J'ai effectué une mise à niveau, mais maintenant mes pods se retrouvent dans des boucles de plantage, et les readiness probes échouent.

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

Mon cluster fonctionnait, mais, tout à coup, il ne peut plus approvisionner LoadBalancers, monter des revendications de volume persistant (PVC), etc.

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

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, ce qui vous permet d’économiser les coûts de calcul respectifs. Vous pouvez également choisir de mettre à l’échelle manuellement ou automatiquement la totalité ou une partie des pools de nœuds User sur 0, en conservant uniquement la configuration de cluster nécessaire.

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 à l’aide des API du groupe de machines virtuelles identiques ne sont pas prises en charge. Utilisez les API AKS (az aks scale).

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

Non, les opérations de mise à l’échelle à l’aide des API du 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 arrêter votre cluster à la place.

Puis-je arrêter ou désallouer toutes mes machines virtuelles ?

Bien qu’AKS dispose de mécanismes de résilience capable de gérer une telle configuration et de récupérer à partir de celle-ci, cette configuration n’est pas prise en charge. Arrêtez votre cluster à la place.

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

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

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

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

Qu’est-ce que le mode transparent d’Azure CNI par rapport au mode pont ?

À partir de la version 1.2.0, Azure CNI utilise le mode transparent comme valeur par défaut pour les déploiements de CNI sous Linux à location unique. Le mode transparent remplace le mode pont. Dans les sections suivantes sur le mode Pont et le mode Transparent, nous abordons plus en détail les différences entre les deux modes, ainsi que les avantages et les limitations du mode Transparent dans Azure CNI.

Mode pont

Le mode Pont d’Azure CNI crée un pont L2 nommé « azure0 » de façon « Just-In-Time ». Toutes les interfaces de paire veth des pods côté hôte sont connectées à ce pont. La communication pod à pod interne à une machine virtuelle et le reste du trafic transitent par ce pont. Le pont est un appareil virtuel de couche 2 qui, à lui seul, ne peut rien recevoir ni transmettre, sauf si vous lui associez un ou plusieurs appareils réels. Pour cette raison, eth0 de la machine virtuelle Linux doit être converti en un pont subordonné à « azure0 », ce qui crée une topologie de réseau complexe au sein de la machine virtuelle Linux. En tant que symptôme, CNI devait gérer d’autres fonctions réseau, telles que les mises à jour du serveur DNS.

Bridge mode topology

L’exemple suivant montre à quoi ressemble la configuration de la route IP en mode Pont. Quel que soit le nombre de pods dont dispose le nœud, il n’y a toujours que deux itinéraires. Le premier itinéraire indique que le trafic (à l’exception du local sur azure0) transite vers la passerelle par défaut du sous-réseau via l’interface avec l’ip « src 10.240.0.4 », qui est l’adresse IP principale du nœud. Le deuxième indique l’espace de pod « 10.20.x.x » au noyau pour que le noyau décide.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Mode transparent

Le mode transparent adopte une approche directe pour configurer la mise en réseau de Linux. Dans ce mode, Azure CNI ne modifie pas les propriétés de l’interface eth0 dans la machine virtuelle Linux. Cette approche de la modification des propriétés de mise en réseau de Linux permet de réduire les problèmes complexes de « corner case » (cas pathologiques) que les clusters pourraient rencontrer avec le mode Pont. En mode Transparent, Azure CNI crée et ajoute des interfaces de paire veth des pods côté hôte qui sont ajoutées au réseau hôte. La communication pod à pod interne à une machine virtuelle se fait via des itinéraires IP que CNI ajoute. Essentiellement, la communication pod à pod se fait sur la couche 3, et les règles d’acheminement L3 acheminent le trafic des pods.

Transparent mode topology

L’exemple suivant montre une configuration de route IP en mode Transparent. L’interface de chaque pod obtient une route statique attachée afin que le trafic ayant la même adresse IP de destination que le pod soit envoyé directement à l’interface de la paire veth coté hôte du pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Avantages du mode Transparent

Permet d’atténuer la condition de concurrence parallèle au DNS conntrack et d’éviter les problèmes de latence de cinq secondes du DNS sans qu’il soit nécessaire de configurer un DNS local de nœud (vous pouvez toujours utiliser un DNS local de nœud pour des raisons de performance).
Élimine le mode pont de CNI à latence DNS initiale de cinq secondes présenté ici en raison de la configuration du pont « juste-à-temps ».
L’un des corner case en mode Pont est qu’Azure CNI ne peut pas continuer à mettre à jour les listes de serveurs DNS personnalisés que les utilisateurs ajoutent à un réseau virtuel ou à une carte réseau. Ce scénario a pour conséquence que CNI ne prend en compte que la première instance de la liste de serveurs DNS. Ce problème est résolu en mode Transparent, car CNI ne modifie pas les propriétés eth0. En savoir plus.
Permet de mieux gérer le trafic UDP et d’atténuer les tempêtes par saturation UDP lorsque le délai d’attente du protocole ARP expire. En mode Pont, lorsque le pont ne connaît pas l’adresse MAC du pod de destination dans la communication pod à pod interne à la machine virtuelle, il en résulte, de par sa conception, une tempête de paquets envoyés vers tous les ports. Ce problème est résolu en mode Transparent, car il n’y a pas d’appareils L2 sous le chemin d’accès. En savoir plus.
Le mode Transparent est plus performant dans la communication pod à pod interne à une machine virtuelle en matière de débit et de latence par rapport au mode Pont.

Comment éviter que le paramètre de propriété d’autorisation ralentisse les problèmes lorsque le volume contient plusieurs fichiers ?

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.

Puis-je utiliser des bibliothèques cryptographiques FIPS avec des déploiements sur 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.

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

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.

Comment fonctionne la synchronisation de l’heure dans AKS ?

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.

Comment les extensions AKS sont-elles mises à 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 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.

Quel est l’objectif de l’extension AKS Linux que je vois installée sur mes instances de Virtual Machine Scale Sets Linux ?

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.