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

Utilisez cette rubrique pour vous aider à résoudre les problèmes liés à la sécurité et à l’identité 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 y place le fichier config. Toutefois, la commande échoue avec l’erreur suivante :

Error: open C:\Users\<user>\.kube\config: The system cannot find the path specified.

Pour reproduire

  1. Installez AksHci.
  2. Créez un cluster cible.
  3. Connectez-vous à l’ordinateur en tant qu’utilisateur administrateur différent (fonctionnalité multi-administrateur).
  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 le renouvellement des certificats de plan de contrôle échoue. 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

Notes

Ce problème est résolu dans la version de septembre 2022 et les versions ultérieures.

Pour 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 similaire au 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 désormais disponible.

Notes

Il existe un bogue connu dans AksHci version 1.0.14.x et 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 de l’authentification : x509 : certificat signé par une autorité inconnue

Vous pouvez voir cette erreur 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 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 Appliance de gestion en supprimant $env:UserProfile.wssd\kvactl\cloudconfig.
  • Exécutez Repair-AksHciCerts.
  • Exécutez Get-AksHciCluster pour case activée qu’il est résolu.

Les journaux du pod de cluster cible ne sont pas accessibles - Erreur à distance : tls : erreur interne

Les journaux du cluster cible ne sont pas accessibles. Lorsque vous essayez d’accéder aux journaux des pods 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

Notes

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 versions ultérieures). Les clusters cibles mis à jour vers cette version ne doivent pas rencontrer ce problème.

Pour 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 du pod cible 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 au suivant :

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 le renouvellement des certificats de plan de contrôle échoue. 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

Notes

Ce problème est résolu dans la version de septembre 2022 et les versions ultérieures.

Pour reproduire

  1. Installez AksHci.
  2. Installez le cluster cible.
  3. Désactivez 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 être retournée avec un message d’erreur similaire au 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 désormais disponible.

Échec du pod KMS et les journaux des pods KMS contiennent des erreurs

Voici quelques-uns des 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 des pods 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 utilisé par la mocclt commande 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 environ 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, connectez-vous à nouveau une fois le certificat arrivé à expiration. Exécutez la commande PowerShell suivante pour vous connecter :

Repair-MocLogin

Supprimer le certificat KVA s’il a expiré au bout de 60 jours

Le certificat KVA expire au bout de 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

Des autorisations Active Directory spéciales sont nécessaires pour les nœuds Azure Stack HCI joints à un domaine

Les utilisateurs qui déploient et configurent Azure Kubernetes Service sur Azure Stack HCI doivent avoir l’autorisation Contrôle total pour créer des objets AD dans le conteneur Active Directory où 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 » introuvables]

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 le retour des journaux. Dans ce cas, l’exécution kubectl logs <pod_name> renvoie « erreur : Vous devez être connecté au serveur (le serveur a demandé au client de fournir des informations d’identification) ». AKS Arc effectue une rotation des 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 lors de la mise à jour des certificats.

Pour atténuer le problème, il existe plusieurs options :

  • Réexécutez 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 l’exécution des charges de travail. Pour redémarrer le serveur d’API, procédez comme suit :

    1. Obtenez les adresses IP de 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 n’est 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