Modifier

Partager via


Résoudre les problèmes de sécurité et d’identité connus et les erreurs dans AKS Arc

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

  1. Installez AksHci.
  2. Créez un cluster cible.
  3. Connectez-vous à l’ordinateur en tant qu’utilisateur administrateur différent (fonctionnalité multi admin).
  4. 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

  1. Installez AksHci.
  2. Installez le cluster cible. 3. Désactivez le cluster (machines virtuelles) pendant plus de 4 jours.
  3. 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 :

  1. Exécutez la commande suivante pour renouveler manuellement le certificat généré :

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. 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 :

  1. Recherchez l’adresse IP de la machine virtuelle du plan de contrôle du cluster cible.
  2. Exécutez la commande suivante : ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>
  3. Répertoriez les fichiers de tatouage de certificat : sudo ls /etc/kubernetes/pki/cert-tattoo-*
  4. 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.

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

  1. Installez AksHci.
  2. Installez le cluster cible.
  3. Ne mettez pas à niveau le cluster pendant 60 jours.
  4. 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 :

  1. Exécutez la commande suivante pour renouveler manuellement le certificat généré :

    Update-AksHciClusterCertificates  -Name my-workload -fixKubeletCredentials
    
  2. 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

  1. Installez AksHci.
  2. Installez le cluster cible.
  3. Désactivez le cluster (vms) pendant plus de 4 jours.
  4. 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 :

  1. Exécutez la commande suivante pour renouveler manuellement le certificat généré :

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. 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 :

    1. Obtenez les adresses IP pour chaque plan de contrôle de votre cluster :

      kubectl get nodes -o wide
      
    2. 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