Résoudre les problèmes liés à l’extension de registre connecté
Cet article décrit certains messages d’erreur courants que vous pouvez recevoir lorsque vous installez ou mettez à jour l’extension de registre connecté pour des clusters Kubernetes avec Arc.
Comment l’extension de registre connecté est-elle installée ?
L’extension de registre connecté est publiée sous la forme d’un chart Helm et installée par Helm V3. Tous les composants de l’extension de registre connecté sont installés dans l’espace de noms connected-registry. Vous pouvez utiliser les commandes suivantes pour vérifier l’état de l’extension.
# get the extension status
az k8s-extension show --name <extension-name>
# check status of all pods of connected registry extension
kubectl get pod -n connected-registry
# get events of the extension
kubectl get events -n connected-registry --sort-by='.lastTimestamp'
Erreurs courantes
Erreur : impossible de réutiliser un nom en cours d’utilisation
Cette erreur signifie que le nom d’extension que vous avez spécifié existe déjà. Si le nom est déjà utilisé, vous devez en utiliser un autre.
Erreur : impossible de créer du contenu dans l’espace de noms connected-registry, car il est en cours d’arrêt
Cette erreur se produit quand une opération de désinstallation n’est pas terminée et qu’une autre opération d’installation est déclenchée. Vous pouvez exécuter la commande az k8s-extension show pour vérifier l’état de provisionnement de l’extension et vous assurer que l’extension a été désinstallée avant d’effectuer d’autres actions.
Erreur : le téléchargement a échoué car le chemin du chart est introuvable
Cette erreur se produit quand vous spécifiez la mauvaise version d’extension. Vous devez vous assurer que la version spécifiée existe. Si vous souhaitez utiliser la dernière version, vous n’avez pas besoin de spécifier --version.
Scénarios courants
Scénario 1 : l’installation échoue, mais n’affiche pas de message d’erreur
Si la création ou la mise à jour de l’extension génère un message d’erreur, vous pouvez inspecter l’emplacement où la création a échoué en exécutant la commande az k8s-extension list :
az k8s-extension list \
--resource-group <my-resource-group-name> \
--cluster-name <my-cluster-name> \
--cluster-type connectedClusters
Solution : redémarrer le cluster, inscrire le fournisseur de services ou supprimer et réinstaller le registre connecté
Pour corriger ce problème, essayez les méthodes suivantes :
Redémarrez votre cluster Kubernetes avec Arc.
Inscrivez le fournisseur de services KubernetesConfiguration.
Forcez la suppression et réinstallez l’extension de registre connectée.
Scénario 2 : la version ciblée du registre connecté n’existe pas
Quand vous essayez d’installer l’extension de registre connecté pour cibler une version spécifique, vous recevez un message d’erreur indiquant que la version du registre connecté n’existe pas.
Solution : réinstaller une version de registre connecté prise en charge
Réinstallez d’installer l’extension. Veillez à utiliser une version prise en charge du registre connecté.
Problèmes courants
Problème : création de l’extension bloquée dans l’état en cours d’exécution
Possibilité 1 : problème lié à la revendication de volume persistant (PVC)
- Vérifier l’état de la revendication de volume persistant du registre connecté
kubectl get pvc -n connected-registry -o yaml connected-registry-pvc
La valeur de phase sous status doit être bound. Si pending s’affiche toujours, supprimez l’extension.
- Vérifiez si la classe de stockage désirée figure dans votre liste de classes de stockage :
kubectl get storageclass --all-namespaces
- Si ce n’est pas le cas, recréez l’extension et ajoutez ceci :
--config pvc.storageClassName=”standard”`
- Il peut également s’agir d’un problème lié au manque d’espace pour la revendication de volume persistant. Recréez l’extension avec le paramètre suivant :
--config pvc.storageRequest=”250Gi”`
Possibilité 2 : chaîne de connexion incorrecte
- Vérifiez les journaux du pod de registre connecté :
kubectl get pod -n connected-registry
- Copiez le nom du pod de registre connecté (par exemple : « connected-registry-8d886cf7f-w4prp »), puis collez-le dans la commande suivante :
kubectl logs -n connected-registry connected-registry-8d886cf7f-w4prp
- Si vous voyez le message d’erreur suivant, la chaîne de connexion du registre connecté est incorrecte :
Response: '{"errors":[{"code":"UNAUTHORIZED","message":"Incorrect Password","detail":"Please visit https://aka.ms/acr#UNAUTHORIZED for more information."}]}'
- Vérifiez qu’un fichier protected-settings-extension.json a été créé.
cat protected-settings-extension.json
- Si nécessaire, régénérez protected-settings-extension.json.
cat << EOF > protected-settings-extension.json
{
"connectionString": "$(az acr connected-registry get-settings \
--name myconnectedregistry \
--registry myacrregistry \
--parent-protocol https \
--generate-password 1 \
--query ACR_REGISTRY_CONNECTION_STRING --output tsv --yes)"
}
EOF
- Mettez à jour l’extension pour inclure la nouvelle chaîne de connexion.
az k8s-extension update \
--cluster-name <myarck8scluster> \
--cluster-type connectedClusters \
--name <myconnectedregistry> \
-g <myresourcegroup> \
--config-protected-file protected-settings-extension.json
Problème : extension créée, mais le registre connecté n’est pas dans un état « En ligne »
Possibilité 1 : registre connecté précédent non désactivé
Ce scénario se produit généralement lorsqu’une extension de registre connecté précédente a été supprimée et qu’une autre extension a été créée pour le même registre connecté.
- Vérifiez les journaux du pod de registre connecté :
kubectl get pod -n connected-registry
- Copiez le nom du pod de registre connecté (par exemple : « connected-registry-xxxxxxxxx-xxxxx »), puis collez-le dans la commande suivante :
kubectl logs -n connected-registry connected-registry-xxxxxxxxx-xxxxx
- Si vous voyez le message d’erreur suivant, le registre connecté doit être désactivé :
Response: '{"errors":[{"code":"ALREADY_ACTIVATED","message":"Failed to activate the connected registry as it is already activated by another instance. Only one instance is supported at any time.","detail":"Please visit https://aka.ms/acr#ALREADY_ACTIVATED for more information."}]}'
- Exécutez la commande suivante pour désactiver le registre connecté :
az acr connected-registry deactivate -n <myconnectedregistry> -r <mycontainerregistry>
Après quelques minutes, le pod de registre connecté doit être recréé et l’erreur doit disparaître.
Activation de la journalisation
- Exécutez la commande [az acr connected-registry update] pour mettre à jour l’extension de registre connecté avec le niveau de consignation du débogage :
az acr connected-registry update --registry mycloudregistry --name myacrregistry --log-level debug
Vous pouvez appliquer les niveaux de consignation suivants pour faciliter la résolution des problèmes :
Debug fournit des informations détaillées à des fins de débogage.
Information fournit des informations générales à des fins de débogage.
Warning indique des problèmes potentiels qui ne sont pas encore des erreurs, mais qui peuvent devenir des erreurs si aucune mesure n’est prise.
Erreur consigne les erreurs qui empêchent une opération de se terminer.
None désactive la journalisation, de sorte qu’aucun message de journal n’est écrit.
Ajustez le niveau de consignation selon les besoins pour résoudre le problème.
La sélection active fournit davantage d’options pour ajuster la verbosité des journaux lors du débogage de problèmes liés à un registre connecté. Les options suivantes sont disponibles :
Le niveau de consignation du registre connecté est propre aux opérations du registre connecté et détermine la gravité des messages gérés par le registre connecté. Ce paramètre permet de gérer le comportement de journalisation du registre connecté lui-même.
--log-level définit le niveau de consignation sur l’instance. Le niveau de consignation détermine la gravité des messages gérés par l’enregistreur. En définissant le niveau de consignation, vous pouvez filtrer les messages inférieurs à une certaine gravité. Par exemple, si vous définissez le niveau de consignation sur « warning », l’enregistreur gère les avertissements, les erreurs et les messages critiques, mais il ignore les messages d’information et de débogage.
Le niveau de consignation az cli contrôle la verbosité des messages de sortie pendant le fonctionnement de l’interface Azure CLI. Azure CLI (az) fournit plusieurs options de verbosité pour les niveaux de consignation, que vous pouvez ajuster pour contrôler la quantité d’informations de sortie pendant son fonctionnement :
--verbose augmente la verbosité des journaux. Cette option fournit des informations plus détaillées que le paramètre par défaut, ce qui peut être utile pour identifier les problèmes.
--debug active les journaux de débogage complets. Les journaux de débogage fournissent les informations les plus détaillées avec, en plus de toutes les informations du niveau « verbose », des détails pour diagnostiquer les problèmes.