Bien démarrer avec le registre de clusters

Améliorez la résilience des fonctions réseau natives cloud avec le registre de clusters Azure Operator Service Manager (AOSM).

Historique des documents

• Créé et publié pour la première fois : 26 juillet 2024
• Mise à jour pour la haute disponibilité : 16 octobre 2024
• Mise à jour pour la GC : 5 novembre 2024

Dépendances des fonctionnalités

Cette fonctionnalité nécessite l’environnement minimal suivant :

• Version minimale de l’API ARM d’AOSM : 2023-09-01
• Première version, pas de haute disponibilité pour l’extension Kubernetes de fonction réseau : 1.0.2711-7
• Première version, avec haute disponibilité pour l’extension Kubernetes de fonction réseau : 2.0.2810-144
• Première version, avec GC pour l’extension kubernetes de fonction réseau : 2.0.2860-160

Vue d’ensemble du Registre de clusters

Le registre de clusters AOSM (Azure Operator Service Manager) permet d’avoir une copie locale des images conteneur dans le cluster Nexus K8s. Quand la fonction réseau conteneurisée (CNF) est installée avec le registre de clusters activé, les images conteneur sont extraites du magasin d’artefacts AOSM distant, et enregistrées dans ce registre de cluster local. À l’aide d’un webhook de mutation, le registre de clusters intercepte automatiquement les demandes d’images et remplace le chemin d’accès au registre local pour éviter les modifications de package de l’éditeur. Avec le registre de clusters, l’accès CNF aux images conteneur persiste malgré la perte de connectivité au magasin d’artefacts distant.

Principaux cas d’usage et avantages

Les fonctions réseau natives cloud (CNF) doivent avoir accès aux images conteneur, non seulement durant le déploiement initial à l’aide du magasin d’artefacts AOSM, mais également pour maintenir la fonction réseau opérationnelle. Voici certains de ces scénarios :

• Redémarrages de pod : l’arrêt et le démarrage d’un pod peuvent entraîner l’extraction par un nœud de cluster des images conteneur du registre.
• Opérations du Scheduler Kubernetes : durant les affectations de pods à des nœuds, selon les règles de profil du Scheduler, si les images conteneur ne sont pas mises en cache localement sur le nouveau nœud, le nœud extrait les images conteneur du registre.

Avantages de l’utilisation du registre de clusters AOSM :

• Fournit les images locales nécessaires pour empêcher l’interruption CNF où la connectivité au magasin d’artefacts AOSM est perdue.
• Diminue le nombre d’extractions d’images sur le magasin d’artefacts AOSM, car chaque nœud de cluster extrait désormais uniquement les images du registre local.
• Résout les problèmes liés aux URL de Registre incorrectes, en utilisant un webhook de mutation pour remplacer le chemin URL du registre local approprié.

Fonctionnement du registre de clusters

Le registre de clusters AOSM est activé à l’aide de l’extension Arc K8s NFO (Network Function Operator). L’interface CLI suivante montre comment le registre de clusters est activé sur un cluster Nexus K8s.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Quand la fonctionnalité de registre de clusters est activée dans l’extension Arc K8s Network Function Operator, toutes les images conteneur déployées à partir du magasin d’artefacts AOSM sont accessibles localement dans le cluster Nexus K8s. L’utilisateur peut choisir la taille du stockage persistant pour le registre de clusters.

Remarque

Si l’utilisateur ne fournit aucune entrée, un volume persistant par défaut de 100 Go est utilisé.

Composants du registre de cluster

La fonctionnalité Registre de cluster déploie des pods d’assistance sur le cluster de périphérie cible pour aider l’extension NFO.

Rapprochement des composants

• Ce pod principal s’occupe de réconcilier les objets de ressources personnalisés (CRO) du composant créés par K8sBridge avec l’aide du fournisseur de ressources Microsoft.Kubernetes (RP), du relais hybride et de l’agent Arc s’exécutant sur le cluster.

Webhook de mutation de pod

• Ces pods implémentent des webhooks d’admission de mutation Kubernetes, qui servent une instance de l’API de mutation. L’API de mutation effectue deux opérations :
  • Elle modifie le chemin d’accès au registre d’images à l’adresse IP du registre local, en remplaçant le magasin d’artefacts AOSM Azure Container Registry (ACR).
  • Elle crée un CR d’artefact sur le cluster en périphérie.

Rapprochement d’artefacts

• Ce pod rapproche les CRO d’artefacts créés par le webhook de mutation.

Registre

• Ce pod stocke et récupère des images conteneur pour CNF.

Garbage Collection du registre de cluster

L’extension de cluster AOSM exécute un travail de garbage collection d’arrière-plan (GC) pour nettoyer régulièrement les images conteneur. Cette tâche s’exécute selon une planification, vérifie si l’utilisation du registre de cluster a atteint le seuil spécifié et, le cas échéant, lance le processus de GC. La planification et le seuil de la tâche sont configurés par l’utilisateur final. Toutefois, par défaut, la tâche s’exécute une fois par jour à un seuil d’utilisation de 0 %.

Nettoyer les manifestes d’images en mémoire

AOSM gère les références entre les ressources propriétaires des pods et les images consommées dans le registre de cluster. Au lancement du processus de nettoyage des images, les images qui ne sont liées à aucun pod sont identifiées. Elles font l’objet d’une suppression réversible pour être retirées du registre de cluster. Ce type de suppression réversible ne libère pas immédiatement de l’espace de stockage du registre de cluster. La suppression effective des fichiers relatifs aux images dépend du Garbage Collection du registre de distribution CNCF décrit ci-dessous.

Remarque

La référence entre le propriétaire d’un pod et ses images conteneur permet de vérifier qu’AOSM ne supprime pas des images par erreur. Par exemple, si un pod replicaset tombe en panne, AOSM ne déréférence pas les images conteneur. AOSM déréférence uniquement les images conteneur quand le jeu de réplicas est supprimé. Le même principe s’applique aux pods gérés par les travaux et les DaemonSets Kubernetes.

Distribution du Garbage Collection CNCF

AOSM configure le registre de cluster à l’aide du registre de distribution CNCF open source. AOSM s’appuie donc sur les fonctionnalités de Garbage Collection fournies par Garbage Collection | Distribution CNCF. Globalement, il suit le processus standard en 2 phases, « marquage et balayage », pour supprimer les fichiers relatifs aux images afin de libérer de l’espace de stockage dans le registre.

Remarque

Pour permettre le bon fonctionnement de ce processus, le registre de cluster doit être en mode lecture seule. Si des images sont chargées alors que le registre n’est pas en mode lecture seule, il existe un risque que les couches d’images soient supprimées par erreur, ce qui endommage l’image. Le registre nécessite un verrouillage en mode lecture seule pour une durée pouvant aller jusqu’à 1 minute. AOSM diffère donc les autres déploiements NF quand le registre de cluster est en mode lecture seule.

Paramètres de configuration du Garbage Collection

Les paramètres suivants configurent la planification et le seuil de la tâche de garbage collection.

• global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
• global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
• Pour plus de détails sur la configuration, veuillez vous référer aux dernières Instructions d’installation de l’extension de la fonction réseau

Considérations sur la haute disponibilité et la résilience

L’extension de fonction réseau d’AOSM s’appuie sur un webhook mutant et un registre de périphérie pour prendre en charge les fonctionnalités clés.

• Intégration de charts Helm sans nécessiter de personnalisation du chemin d’accès des images.
• Un registre de clusters local pour accélérer les opérations des pods et activer la prise en charge en mode déconnecté. Ces composants essentiels doivent bénéficier d’une haute disponibilité et d’une haute résilience.

Résumé des modifications pour la haute disponibilité

Avec la haute disponibilité, les pods de registre de cluster et de webhook prennent désormais en charge un jeu de réplicas avec un minimum de trois réplicas et un maximum de cinq réplicas. La configuration de la clé du jeu de réplicas est la suivante :

• Une stratégie de mise à niveau de déploiement progressif est utilisée.
• Des PodDisruptionBudgets (PDB) sont utilisés pour la disponibilité pendant les interruptions volontaires.
• L’anti-affinité de pod est utilisée pour répartir uniformément les pods entre les nœuds.
• La sonde de préparation est utilisée pour vérifier que les pods sont prêts avant de traiter le trafic.
• Les pods de charge de travail AOSM sont affectés seulement au pool de nœuds système.
• Les pods sont mis à l’échelle horizontalement sous la charge processeur et mémoire.

Réplicas

• Un cluster exécutant plusieurs copies ou réplicas d’une application fournit le premier niveau de redondance. Le registre de clusters et le webhook sont définis comme « kind:deployment » avec un minimum de trois réplicas.

DeploymentStrategy

• Une stratégie rollingUpdate est utilisée pour aider à réaliser des mises à niveau sans temps d’arrêt et à prendre en charge le déploiement progressif des applications. La configuration par défaut de maxUnavailable autorise l’arrêt d’un seul pod à la fois, jusqu’à ce que suffisamment de pods soient créés pour satisfaire à la stratégie de redondance.

Budget d’interruption des pods

• Un budget d’interruption de stratégie (PDB) protège les pods contre les interruptions volontaires et est déployé en même temps que les objets Deployment, ReplicaSet ou StatefulSet. Pour les pods d’opérateur AOSM, un budget d’interruption de stratégie avec un paramètre minAvailable défini sur 2 est utilisé.

Anti-affinité des pods

• L’anti-affinité de pod contrôle la distribution des pods d’application sur plusieurs nœuds de votre cluster. Avec la haute disponibilité, l’anti-affinité de pod AOSM utilisant les paramètres suivants :
  • Un mode de planification est utilisé pour définir dans quelle mesure la règle est appliquée strictement.
    • requiredDuringSchedulingIgnoredDuringExecution(Hard) : les pods doivent être planifiés de façon à satisfaire la règle définie. Si aucune topologie répondant aux exigences de la règle n’est disponible, le pod n’est pas planifié.
    • preferredDuringSchedulingIgnoredDuringExecution(Soft) : ce type de règle exprime une préférence pour la planification des pods, mais n’applique pas une exigence stricte. Si des topologies répondant aux critères de préférence sont disponibles, Kubernetes planifie le pod. Si aucune topologie de ce type n’est disponible, le pod peut néanmoins être planifié sur d’autres nœuds qui ne satisfont pas à la préférence.
  • Un sélecteur d’étiquette est utilisé pour cibler des pods spécifiques pour lesquels l’affinité est appliquée.
  • Une clé de topologie est utilisée pour définir les besoins du nœud.
• L’emplacement des nœuds Nexus est réparti uniformément entre les zones par conception : la répartition des pods entre les nœuds apporte donc également une redondance zonale.
• Les pods d’opérateur AOSM utilisent une anti-affinité légère avec un poids de 100 et une clé de topologie basée sur les noms d’hôte de nœud est utilisée.

Stockage

• Étant donné que le registre de périphérie AOSM a plusieurs réplicas répartis entre les nœuds, le volume persistant doit prendre en charge le mode d’accès ReadWriteMany (RWX). Le volume « partagé par Nexus » de la revendication de volume persistant est disponible sur les clusters Nexus et prend en charge le mode d’accès RWX.

Surveillance via des sondes de préparation

• AOSM utilise des sondes de préparation HTTP pour savoir quand un conteneur est prêt à accepter du trafic. Un pod est considéré comme prêt quand tous les conteneurs sont prêts. Quand un pod n’est pas prêt, il est supprimé des équilibreurs de charge du service.

Pool de nœuds système

• Tous les pods de l’opérateur AOSM sont affectés au pool de nœuds système. Ce pool empêche les pods d'application mal configurés ou douteux d'avoir un impact sur les pods système.

Mise à l’échelle horizontale

• Dans Kubernetes, un HorizontalPodAutoscaler (HPA) met automatiquement à jour une ressource de charge de travail dans le but de mettre automatiquement à l’échelle la charge de travail en fonction de la demande. Les pods de l’opérateur AOSM ont les paramètres de stratégie HPA suivants configurés :
  • Un minimum de trois réplicas.
  • Un maximum de cinq réplicas.
  • Une targetAverageUtilization de 80 % pour le processeur et la mémoire.

Limites des ressources

• Des limites de ressources sont utilisées pour empêcher une surcharge des ressources sur les nœuds où les pods AOSM s’exécutent. AOSM utilise deux paramètres de ressource pour limiter la consommation de processeur et de mémoire.
  • Demande de ressource : la quantité minimale qui doit être réservée pour un pod. Cette valeur doit être définie sur l’utilisation des ressources sous une charge normale pour votre application.
  • Limite de ressources : la quantité maximale qu’un pod doit utiliser ; si l’utilisation atteint la limite, il est arrêté. Tous les conteneurs d’un opérateur AOSM sont configurés avec une demande de limite appropriée pour le processeur et la mémoire.

Limitations connues de la haute disponibilité

• Les clusters Nexus AKS (NAKS) avec un seul nœud actif dans le pool d’agents système ne conviennent pas pour la haute disponibilité. La topologie de production Nexus doit utiliser au moins trois nœuds actifs dans le pool d’agents système.
• La classe de stockage Partagé par Nexus est un service de stockage NFS (Network File System). Ce service de stockage NFS est disponible par Réseau de services cloud (CSN). Tout cluster Nexus Kubernetes attaché au CSN peut approvisionner du volume persistant à partir de ce pool de stockage partagé. Le pool de stockage est actuellement limité à une taille maximale de 1 Tio pour Network Cloud (NC) 3.10, tandis que NC 3.12 présente une option de 16 Tio.
• L’anti-affinité de pod traite seulement du placement initial des pods, de la mise à l’échelle ultérieure et de la réparation des pods ; elle suit la logique de planification Kubernetes standard.

Forums Aux Questions (FAQ)

Puis-je utiliser le registre de clusters AOSM avec une application CNF déjà déployée ?

Si une application CNF est déjà déployée sans registre de clusters, les images conteneur ne sont pas disponibles automatiquement. Le registre de clusters doit être activé avant le déploiement de la fonction réseau avec AOSM.

Puis-je changer la taille de stockage après un déploiement ?

La taille de stockage ne peut pas être modifiée après le déploiement initial. Nous vous recommandons de configurer la taille du volume en la multipliant par 3 ou par 4 par rapport à la taille de départ.

Puis-je répertorier les fichiers actuellement stockés dans le référentiel de cluster ?

La commande suivante peut être utilisée pour répertorier les fichiers dans un format lisible par l’homme :

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Cette commande devrait générer des résultats similaires aux éléments suivants :

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0