Utilisez cette rubrique pour vous aider à résoudre les problèmes liés à la sécurité et aux identités dans AKS Arc.
Get-AksHciCredential échoue avec l’erreur « Impossible de trouver le chemin spécifié »
L’applet Get-AksHciCredential
de commande PowerShell échoue lorsqu’elle est exécutée par un utilisateur administrateur différent de celui utilisé pour installer AksHci. La commande crée un répertoire .kube et place le fichier config dans celui-ci. Toutefois, la commande échoue avec l’erreur suivante :
Error: open C:\Users\<user>\.kube\config: The system cannot find the path specified.
Opérations à reproduire
- Installez AksHci.
- Créez un cluster cible.
- Connectez-vous à l’ordinateur en tant qu’utilisateur administrateur différent (fonctionnalité multi admin).
- Exécutez
Get-AksHciCredential -Name $clusterName
.
Comportement attendu
Get-AksHciCredential
doit pouvoir créer un répertoire .kube dans le répertoire de base de l’utilisateur et placer le fichier de configuration dans ce répertoire.
Pour contourner le problème, créez un répertoire .kube dans le répertoire de base de l’utilisateur. Utilisez la commande suivante pour créer le répertoire :
mkdir "$HOME/.kube"
Après cette étape, Get-AksHciCredential
ne doit pas échouer.
Erreur « Certificat expiré - Impossible de se connecter au serveur : x509 »
Le cluster cible n’est pas accessible lorsque les certificats du plan de contrôle ne sont pas renouvelés. Lorsque vous essayez d’atteindre le cluster, la kubectl
commande affiche l’erreur suivante :
certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z
Remarque
Ce problème est résolu dans la version de septembre 2022 et ultérieure.
Opérations à reproduire
- Installez AksHci.
- Installez le cluster cible. 3. Désactivez le cluster (machines virtuelles) pendant plus de 4 jours.
- Réactivez le cluster.
Symptômes et atténuation
Le cluster cible est inaccessible. Toute kubectl
commande exécutée sur le cluster cible retourne un message d’erreur semblable à celui suivant :
certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z
Pour résoudre le problème :
Exécutez la commande suivante pour renouveler manuellement le certificat généré :
Update-AksHciClusterCertificates -Name my-workload -cluster -fixKubeletCredentials
Générez de nouvelles informations d’identification :
Get-AksHciCredential -name <clustername>
Après quelques minutes, réessayez la kubectl
commande pour voir si le cluster est maintenant disponible.
Remarque
Il existe un bogue connu dans AksHci version 1.0.14.x et versions antérieures. Si la machine virtuelle du plan de contrôle a un modèle de nom autre que -control-plane-
, la Update-AksHciClusterCertificates
commande peut ne pas fonctionner. Vous devez mettre à jour le certificat en vous connectant à la machine virtuelle du plan de contrôle :
- Recherchez l’adresse IP de la machine virtuelle du plan de contrôle du cluster cible.
- Exécutez la commande suivante :
ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>
- Répertoriez les fichiers de tatouage de certificat :
sudo ls /etc/kubernetes/pki/cert-tattoo-*
- Générez des certificats à l’aide de chaque fichier répertorié par la commande précédente :
sudo /usr/bin/cert-tattoo-provision CreateCertsWithAltNames <absolute-path-of-cert-tattoo-file>
Échec de la négociation d’authentification : x509 : certificat signé par une autorité inconnue
Cette erreur peut s’afficher lors du déploiement d’un nouveau cluster AKS ou de l’ajout d’un pool de nœuds à un cluster existant.
- Vérifiez que l’utilisateur qui a exécuté la commande est le même utilisateur que celui qui a installé AKS sur Azure Stack ou Windows Server. Pour plus d’informations sur l’octroi de l’accès à plusieurs utilisateurs, consultez Configurer plusieurs administrateurs.
- Si l’utilisateur est le même et que l’erreur persiste, suivez les étapes ci-dessous pour résoudre le problème :
- Supprimez l’ancien certificat de l’appliance de gestion en supprimant
$env:UserProfile.wssd\kvactl\cloudconfig
. - Exécutez
Repair-AksHciCerts
. - Exécutez
Get-AksHciCluster
pour vérifier qu’il est résolu.
Les journaux des pods de cluster cible ne sont pas accessibles - erreur distante : tls : erreur interne
Les journaux de cluster cible ne sont pas accessibles. Lorsque vous essayez d’accéder aux journaux de pod dans le cluster cible, l’erreur TLS suivante s’affiche :
Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error
Remarque
Il s’agit d’un problème connu dans AksHci version 1.0.14.x et versions antérieures. Elle est corrigée dans le cadre de la version 1.0.14.x (version de septembre et ultérieure). Les clusters cibles mis à jour vers cette version ne doivent pas rencontrer ce problème.
Opérations à reproduire
- Installez AksHci.
- Installez le cluster cible.
- Ne mettez pas à niveau le cluster pendant 60 jours.
- Redémarrer le cluster.
Symptômes et atténuation
Les journaux des pods cibles ne doivent pas être accessibles. Toute kubectl
commande de journal exécutée sur le cluster cible doit retourner avec un message d’erreur similaire à ce qui suit :
Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error
Pour résoudre le problème :
Exécutez la commande suivante pour renouveler manuellement le certificat généré :
Update-AksHciClusterCertificates -Name my-workload -fixKubeletCredentials
Générez de nouvelles informations d’identification :
Get-AksHciCredential -name <clustername>
Plan de contrôle du cluster - Certificat expiré - Impossible de se connecter au serveur : x509
Le cluster cible n’est pas accessible lorsque les certificats du plan de contrôle ne sont pas renouvelés. Lorsque vous essayez d’atteindre le cluster, la kubectl
commande génère l’erreur suivante :
certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z
Remarque
Ce problème est résolu dans la version de septembre 2022 et ultérieure.
Opérations à reproduire
- Installez AksHci.
- Installez le cluster cible.
- Désactivez le cluster (vms) pendant plus de 4 jours.
- Réactivez le cluster.
Symptômes et atténuation
Le cluster cible doit être inaccessible. Toute kubectl
commande exécutée sur le cluster cible doit retourner avec un message d’erreur similaire à ce qui suit :
certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z
Pour résoudre le problème :
Exécutez la commande suivante pour renouveler manuellement le certificat généré :
Update-AksHciClusterCertificates -Name my-workload -cluster -fixKubeletCredentials
Générez de nouvelles informations d’identification :
Get-AksHciCredential -name <clustername>
Après quelques minutes, réessayez la kubectl
commande pour voir si le cluster est maintenant disponible.
Échec du pod KMS et les journaux des pods KMS contiennent des erreurs
Voici quelques symptômes possibles de ce problème :
kubectl get secrets
échoue avec une erreur interne.kubectl logs <kmspod-name> -n kube-system
contient des erreurs.- Le montage des secrets échoue dans les volumes lorsque vous essayez de créer des pods.
- Le serveur d’API ne parvient pas à démarrer.
Recherchez les erreurs dans les journaux de pod KMS en exécutant la commande suivante :
kubectl logs <kmspod-name> -n kube-system
Si les journaux retournent une erreur concernant un jeton non valide dans le pod KMS du cluster de gestion, exécutez la commande suivante :
Update-AksHciCertificates
En cas d’erreur concernant un jeton non valide dans le pod KMS du cluster cible, exécutez la commande suivante :
UpdateAksHciClusterCertificates -name <cluster-name> -fixcloudcredential
Erreur « System.Collections.Hashtable.generic_non_zero 1 [Erreur : Le certificat a expiré : Expiré] »
Le certificat mocctl expire s’il n’est pas utilisé pendant plus de 60 jours. AKS Arc utilise l’outil mocctl
en ligne de commande pour communiquer avec MocStack pour effectuer des opérations liées à Moc. Le certificat que la mocclt
commande utilise pour communiquer avec cloudagent expire dans 60 jours. La mocctl
commande renouvelle automatiquement le certificat lorsqu’il est utilisé près de son expiration (après ~42 jours). Si la commande n’est pas utilisée fréquemment, le certificat expire.
Pour reproduire le comportement, installez AKS Arc et aucune opération impliquant la mocctl
commande n’est effectuée pendant 60 jours.
Pour résoudre le problème, reconnectez-vous une fois le certificat expiré. Exécutez la commande PowerShell suivante pour vous connecter :
Repair-MocLogin
Supprimer le certificat KVA s’il a expiré après 60 jours
Le certificat KVA expire après 60 jours si aucune mise à niveau n’est effectuée.
Update-AksHci
, et toute commande impliquant kvactl
, génèrent l’erreur suivante.
Error: failed to get new provider: failed to create azurestackhci session: Certificate has expired: Expired
Pour résoudre cette erreur, supprimez le fichier de certificat expiré dans \kvactl\cloudconfig
, puis réessayez Update-AksHci
sur le nœud concerné par le problème d’expiration du certificat. Vous pouvez utiliser la commande suivante :
$env:UserProfile.wssd\kvactl\cloudconfig
Voici un article sur ce problème : KVA certificate needs to be deleted if KVA Certificate expired after 60 days
Les autorisations Active Directory spéciales sont nécessaires pour les nœuds locaux Azure joints à un domaine
Les utilisateurs qui déploient et configurent Azure Kubernetes Service sur Azure Local doivent disposer d’une autorisation Contrôle total pour créer des objets AD dans le conteneur Active Directory dans lequel sont créés les objets de serveur et de service.
Élever les autorisations de l’utilisateur.
Uninstall-AksHciAdAuth échoue avec l’erreur « [Erreur du serveur (NotFound) : secrets « keytab-akshci-scale-reliability » introuvable]
Si Uninstall-AksHciAdAuth affiche cette erreur, vous devez l’ignorer pour le moment, car ce problème va être résolu.
This issue will be fixed.
les journaux kubectl retournent « erreur : vous devez être connecté au serveur (le serveur a demandé au client de fournir des informations d’identification) »
Il existe un problème avec AKS Arc dans lequel un cluster peut arrêter de retourner des journaux. Lorsque cela se produit, l’exécution kubectl logs <pod_name>
retourne « erreur : vous devez être connecté au serveur (le serveur a demandé au client de fournir des informations d’identification) ». AKS Arc fait pivoter les certificats Kubernetes principaux tous les 4 jours, mais parfois le serveur d’API Kubernetes ne recharge pas immédiatement son certificat client pour la communication avec kubelet lorsque les certificats sont mis à jour.
Pour atténuer le problème, il existe plusieurs options :
Réexécuter
kubectl logs
. Par exemple, exécutez la commande PowerShell suivante :while (1) {kubectl logs <POD_NAME>; sleep 1}
Redémarrez le
kube-apiserver
conteneur sur chacun des plans de contrôle d’un cluster. Le redémarrage du serveur d’API n’a pas d’impact sur les charges de travail en cours d’exécution. Pour redémarrer le serveur d’API, procédez comme suit :Obtenez les adresses IP pour chaque plan de contrôle de votre cluster :
kubectl get nodes -o wide
Exécutez la commande suivante :
ssh -i (get-akshciconfig).Moc.sshPrivateKey clouduser@<CONTROL_PLANE_IP> 'sudo crictl stop $(sudo crictl ps --name kube-apiserver -o json | jq -r .containers[0].id)'
Si vous le souhaitez, mais pas recommandé pour les charges de travail de production, vous pouvez demander
kube-apiserver
de ne pas vérifier le certificat de serveur du kubelet :kubectl logs <POD_NAME> --insecure-skip-tls-verify-backend=true