Référence de configuration du cluster AKS

Pour obtenir l’ID d’abonnement, cliquez sur Tous les services dans la barre de navigation à gauche. Puis cliquez sur Abonnements. Allez au nom de l’abonnement que vous souhaitez associer à votre cluster Kubernetes et copiez l'ID d’abonnement.

Pour obtenir l’ID client, allez sur le portail Azure, puis cliquez sur Azure Active Directory, puis cliquez sur Enregistrements d’applications, puis cliquez sur le nom du principal de service. L’ID client est indiqué sur la page de détails de l’enregistrement de l’application comme ID d’application (client).

Vous ne pouvez pas récupérer la valeur du secret client après sa création, donc si vous n’avez pas déjà de valeur de secret client, vous devrez créer un nouveau secret client.

Pour obtenir un nouveau secret client, allez sur le portail Azure, puis cliquez sur Azure Active Directory, puis cliquez sur Enregistrements d’applications, puis cliquez sur le nom du principal de service.

Puis cliquez sur Certificats et secrets et cliquez sur Nouveau secret client. Cliquez sur Ajouter. Puis copiez la Valeur du nouveau secret client.

Microsoft fournit plusieurs clouds pour se conformer aux lois régionales, qui sont disponibles pour votre utilisation:

Les versions Kubernetes disponibles sont récupérées dynamiquement depuis l’API Azure.

Un groupe de ressources est un conteneur qui contient des ressources liées pour une solution Azure. Le groupe de ressources peut inclure toutes les ressources de la solution, ou seulement celles que vous souhaitez gérer en tant que groupe. Vous décidez comment vous souhaitez allouer des ressources aux groupes de ressources en fonction de ce qui a le plus de sens pour votre organisation. En général, ajoutez des ressources qui partagent le même cycle de vie au même groupe de ressources afin de pouvoir les déployer, les mettre à jour et les supprimer facilement en tant que groupe.

Utilisez un groupe de ressources existant ou saisissez un nom de groupe de ressources et un groupe sera créé pour vous.

Utiliser un groupe de ressources contenant un cluster AKS existant créera un nouveau groupe de ressources. Azure AKS n’autorise qu’un seul cluster AKS par groupe de ressources.

Pour des informations sur la gestion des groupes de ressources, consultez la documentation Azure.

Le nom d’utilisateur utilisé pour créer une connexion SSH aux nœuds Linux.

Le nom d’utilisateur par défaut pour les nœuds AKS est azureuser.

La clé utilisée pour créer une connexion SSH aux nœuds Linux.

Les balises de cluster peuvent être utiles si votre organisation utilise des balises comme moyen d’organiser les ressources à travers plusieurs services Azure. Ces balises ne s’appliquent pas aux ressources au sein du cluster.

Les équilibreurs de charge Azure prennent en charge à la fois les SKU standard et de base (unités de gestion des stocks).

Pour une comparaison des équilibreurs de charge standard et de base, consultez la documentation officielle d’Azure. Microsoft recommande l’équilibreur de charge standard.

L’équilibreur de charge standard est requis si vous avez sélectionné une ou plusieurs zones de disponibilité, ou si vous avez plus d’un pool de nœuds.

Tous les pods dans un cluster AKS peuvent envoyer et recevoir du trafic sans limitations, par défaut. Pour améliorer la sécurité, vous pouvez définir des règles qui contrôlent le flux de trafic. La fonctionnalité de politique réseau dans Kubernetes vous permet de définir des règles pour le trafic entrant et sortant entre les pods dans un cluster.

Azure fournit deux façons de mettre en œuvre la politique réseau. Vous choisissez une option de politique réseau lorsque vous créez un cluster AKS. L’option de politique ne peut pas être modifiée après la création du cluster :

Vous pouvez également choisir de ne pas avoir de politique réseau.

Pour plus d’informations sur les différences entre les politiques réseau Azure et Calico et leurs capacités, consultez la documentation AKS.

Entrez un préfixe DNS unique pour le FQDN du serveur API Kubernetes de votre cluster.

Il existe deux plugins réseau : kubenet et Azure CNI.

Le plugin Kubernetes kubenet est la configuration par défaut pour la création de clusters AKS. Lorsque kubenet est utilisé, chaque nœud du cluster reçoit une adresse IP routable. Les pods utilisent le NAT pour communiquer avec d’autres ressources en dehors du cluster AKS. Cette approche réduit le nombre d’adresses IP que vous devez réserver dans votre espace réseau pour les pods.

Avec le plugin de mise en réseau Azure CNI (avancé), les pods bénéficient d’une connectivité complète au réseau virtuel et peuvent être atteints directement via leur adresse IP privée depuis les réseaux connectés. Ce plugin nécessite plus d’espace d’adresses IP.

Pour plus d’informations sur les différences entre kubenet et Azure CNI, consultez la documentation AKS.

Lorsqu’il est activé, le produit complémentaire de routage d’application HTTP facilite l’accès aux applications déployées sur le cluster AKS. Elle déploie deux composants : un contrôleur Ingress Kubernetes et un contrôleur External-DNS.

Pour plus d’informations, consultez la documentation AKS.

Vous pouvez sécuriser l’accès au serveur API Kubernetes en utilisant des plages d’adresses IP autorisées.

Le serveur API Kubernetes expose l’API Kubernetes. Ce composant fournit l’interaction pour les outils de gestion, tels que kubectl. AKS fournit un plan de contrôle de cluster à locataire unique avec un serveur API dédié. Par défaut, le serveur API se voit attribuer une adresse IP publique, et vous devez contrôler l’accès à celui-ci en utilisant RBAC basé sur Kubernetes ou Azure.

Pour sécuriser l’accès au plan de contrôle AKS et au serveur API, qui sont autrement accessibles au public, vous pouvez activer et utiliser des plages d’IP autorisées. Ces plages d’IP autorisées ne permettent qu’aux plages d’adresses IP définies de communiquer avec le serveur API.

Cependant, même si vous utilisez des plages d’adresses IP autorisées, vous devez toujours utiliser RBAC Kubernetes ou RBAC Azure pour autoriser les utilisateurs et les actions qu’ils demandent.

La surveillance des conteneurs vous offre une visibilité sur les performances en collectant des métriques de mémoire et de processeur à partir des contrôleurs, des nœuds et des conteneurs disponibles dans Kubernetes via l’API des métriques. Les journaux des conteneurs sont également collectés. Après avoir activé la surveillance, les métriques et les journaux sont automatiquement collectés pour vous via une version conteneurisée de l’agent Log Analytics pour Linux. Les métriques sont écrites dans le magasin de métriques et les données de journal sont écrites dans le magasin de journaux associé à votre espace de travail Log Analytics.

Le groupe de ressources contenant l’espace de travail Log Analytics. Vous devez créer au moins un espace de travail pour utiliser les journaux Azure Monitor.

Les données collectées par les journaux Azure Monitor sont stockées dans un ou plusieurs espaces de travail Log Analytics. L’espace de travail définit l’emplacement géographique des données, les droits d’accès définissant quels utilisateurs peuvent accéder aux données, et les paramètres de configuration tels que le niveau de prix et la conservation des données.

Vous devez créer au moins un espace de travail pour utiliser les journaux Azure Monitor. Un seul espace de travail peut être suffisant pour toutes vos données de surveillance, ou vous pouvez choisir de créer plusieurs espaces de travail en fonction de vos besoins. Par exemple, vous pourriez avoir un espace de travail pour vos données de production et un autre pour les tests.

Pour plus d’informations sur les journaux Azure Monitor, consultez la documentation Azure.

En général, les nœuds de travail AKS n’obtiennent pas d’IP publiques, peu importe si le cluster est privé. Dans un cluster privé, le plan de contrôle n’a pas de point de terminaison public.

Rancher peut se connecter à un cluster AKS privé de deux manières.

La première façon de s’assurer que Rancher fonctionne sur le même NAT que les nœuds AKS.

La deuxième façon est d’exécuter une commande pour enregistrer le cluster avec Rancher. Une fois le cluster provisionné, vous pouvez exécuter la commande affichée depuis n’importe où où vous pouvez vous connecter à l’API Kubernetes du cluster. Cette commande est affichée dans une fenêtre contextuelle lorsque vous provisionnez un cluster AKS avec un point de terminaison API privé activé.

Pour plus d’informations sur la connexion à un cluster privé AKS, consultez la documentation AKS.

L’interface Azure permet aux utilisateurs de spécifier si un Pool de Nœuds Principal repose sur system (normalement utilisé pour les plans de contrôle) ou user (ce qui est généralement nécessaire pour Rancher).

Pour les Pools de Nœuds Principaux, vous pouvez spécifier le Mode, le Système d’exploitation, le Nombre et la Taille.

Les pools de nœuds système nécessitent toujours des nœuds en cours d’exécution, donc ils ne peuvent pas être réduits en dessous d’un nœud. Au moins un pool de nœuds système est requis.

Pour les pools de nœuds suivants, l’interface utilisateur de Rancher impose par défaut l’Utilisateur. Les pools de nœuds utilisateurs vous permettent de réduire à zéro nœud. Les pools de nœuds utilisateurs n’exécutent aucune partie du plan de contrôle Kubernetes.

AKS n’expose pas les nœuds qui exécutent les composants du plan de contrôle Kubernetes.

Les zones de disponibilité sont des emplacements physiques uniques au sein d’une région. Chaque zone est composée d’un ou plusieurs centres de données équipés d’une alimentation, d’un refroidissement et d’un réseau indépendants.

Toutes les régions ne prennent pas en charge les zones de disponibilité. Pour une liste des régions Azure avec des zones de disponibilité, consultez la documentation Azure.

Choisissez une taille pour chaque VM dans le pool de nœuds. Pour des détails sur chaque taille de VM, consultez cette page.

Les nœuds dans le pool de nœuds peuvent avoir des disques gérés ou éphémères.

Les disques éphémères du système d’exploitation sont créés sur le stockage local de la machine virtuelle et ne sont pas sauvegardés sur le stockage Azure distant. Les disques éphémères du système d’exploitation fonctionnent bien pour les charges de travail sans état, où les applications tolèrent les échecs individuels de VM, mais sont plus affectées par le temps de déploiement de la VM ou le réimaging des instances de VM individuelles. Avec un disque éphémère du système d’exploitation, vous bénéficiez d’une latence en lecture et en écriture plus faible et d’un réimaging de VM plus rapide.

Les disques gérés par Azure sont des volumes de stockage au niveau des blocs qui sont gérés par Azure et utilisés avec les machines virtuelles Azure. Les disques gérés sont conçus pour une disponibilité de 99,999%. Les disques gérés atteignent cela en vous fournissant trois répliques de vos données, permettant une grande durabilité.

La taille en Go pour le disque de chaque nœud.

Le nombre de nœuds dans le pool de nœuds. Le nombre maximum de nœuds peut être limité par votre abonnement Azure.

Le nombre maximum de pods par nœud est par défaut de 110 avec un maximum de 250.

Lorsque l’auto-scaling est activé, vous devrez entrer un nombre minimum et maximum de nœuds.

Lorsque l’auto-scaling est activé, vous ne pouvez pas mettre à l’échelle manuellement le pool de nœuds. L’échelle est contrôlée par l’autoscaler AKS.