Editar

Share via


Corrección de problemas y errores conocidos de seguridad e identidad en AKS Arc

Use este tema para ayudarle a solucionar problemas relacionados con la seguridad y la identidad en AKS Arc.

Get-AksHciCredential produce un error "no se encuentra la ruta de acceso especificada".

Se produce un error en el Get-AksHciCredential cmdlet de PowerShell cuando se ejecuta por un usuario administrador diferente al que se usa para instalar AksHci. El comando crea un directorio .kube y coloca el archivo de configuración en él. Sin embargo, se produce un error en el comando con el siguiente error:

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

Para reproducir

  1. Instale AksHci.
  2. Cree un clúster de destino.
  3. Inicie sesión en la máquina como un usuario administrador diferente (característica multiadministrador).
  4. Ejecute Get-AksHciCredential -Name $clusterName.

Comportamiento esperado

Get-AksHciCredential debe poder crear un directorio .kube en el directorio principal del usuario y colocar el archivo de configuración en ese directorio.

Para solucionar el problema, cree un directorio .kube en el directorio principal del usuario. Use el siguiente comando para crear el directorio:

mkdir "$HOME/.kube"

Después de este paso, Get-AksHciCredential no debe producir un error.

Error "Certificado expirado: no se puede conectar al servidor: x509"

No se puede acceder al clúster de destino cuando los certificados del plano de control no se renuevan. Al intentar llegar al clúster, el kubectl comando muestra el siguiente error:

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

Nota

Este problema se ha corregido en la versión de septiembre de 2022 y versiones posteriores.

Para reproducir

  1. Instale AksHci.
  2. Instale el clúster de destino. 3. Desactive el clúster (VM) durante más de 4 días.
  3. Vuelva a activar el clúster.

Síntomas y mitigación

El clúster de destino no es accesible. Cualquier kubectl comando ejecutado en el clúster de destino devuelve un mensaje de error similar al siguiente:

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

Para solucionar el problema:

  1. Ejecute el siguiente comando para renovar manualmente el certificado generado:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Generar nuevas credenciales:

    Get-AksHciCredential -name <clustername>
    

Después de unos minutos, vuelva a intentar el kubectl comando para ver si el clúster ya está disponible.

Nota

Hay un error conocido en AksHci versión 1.0.14.x y versiones anteriores. Si la máquina virtual del plano de control tiene un patrón de nombre distinto -control-plane-de , es posible que el Update-AksHciClusterCertificates comando no funcione. Para actualizar el certificado, inicie sesión en la máquina virtual del plano de control:

  1. Busque la dirección IP de la máquina virtual del plano de control del clúster de destino.
  2. Ejecute el comando siguiente: ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>.
  3. Enumerar los archivos de tatuaje de certificado: sudo ls /etc/kubernetes/pki/cert-tattoo-*
  4. Genere certificados con cada archivo enumerado por el comando anterior: sudo /usr/bin/cert-tattoo-provision CreateCertsWithAltNames <absolute-path-of-cert-tattoo-file>

Error en el protocolo de enlace de autenticación: x509: certificado firmado por una entidad desconocida

Es posible que vea este error al implementar un nuevo clúster de AKS o agregar un grupo de nodos a un clúster existente.

  1. Compruebe que el usuario que ha ejecutado el comando es el mismo usuario que instaló AKS en Azure Stack o Windows Server. Para obtener más información sobre cómo conceder acceso a varios usuarios, consulte Configuración de varios administradores.
  2. Si el usuario es el mismo y el error persiste, siga estos pasos para resolver el problema:
  • Elimine el certificado antiguo del dispositivo de administración quitando $env:UserProfile.wssd\kvactl\cloudconfig.
  • Ejecute Repair-AksHciCerts.
  • Ejecute Get-AksHciCluster para comprobar que se ha corregido.

No se puede acceder a los registros de pods de clúster de destino: error remoto: tls: error interno

Los registros del clúster de destino no son accesibles. Al intentar acceder a los registros de pod en el clúster de destino, se muestra el siguiente error de TLS:

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

Nota

Se trata de un problema conocido en AksHci versión 1.0.14.x y versiones anteriores. Se ha corregido como parte de la versión 1.0.14.x (versión de septiembre y versiones posteriores). Los clústeres de destino actualizados a esta versión no deben experimentar este problema.

Para reproducir

  1. Instale AksHci.
  2. Instale el clúster de destino.
  3. No actualice el clúster durante 60 días.
  4. Reinicie el clúster.

Síntomas y mitigación

Los registros de pod de destino no deben ser accesibles. Cualquier kubectl comando de registro que se ejecute en el clúster de destino debe devolver un mensaje de error similar al siguiente:

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

Para solucionar el problema:

  1. Ejecute el siguiente comando para renovar manualmente el certificado generado:

    Update-AksHciClusterCertificates  -Name my-workload -fixKubeletCredentials
    
  2. Generar nuevas credenciales:

    Get-AksHciCredential -name <clustername>
    

Plan de control de clúster: certificado expirado: no se puede conectar al servidor: x509

No se puede acceder al clúster de destino cuando los certificados del plano de control no se renuevan. Al intentar llegar al clúster, el kubectl comando genera el siguiente error:

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

Nota

Este problema se ha corregido en la versión de septiembre de 2022 y versiones posteriores.

Para reproducir

  1. Instale AksHci.
  2. Instale el clúster de destino.
  3. Desactive cluster(vms) durante más de 4 días.
  4. Vuelva a activar el clúster.

Síntomas y mitigación

El clúster de destino debe ser inaccesible. Cualquier kubectl comando que se ejecute en el clúster de destino debe devolverse con un mensaje de error similar al siguiente:

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

Para solucionar el problema:

  1. Ejecute el siguiente comando para renovar manualmente el certificado generado:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Generar nuevas credenciales:

    Get-AksHciCredential -name <clustername>
    

Después de unos minutos, vuelva a intentar el kubectl comando para ver si el clúster ya está disponible.

Error en el pod de KMS y los registros de pods de KMS contienen errores

Algunos posibles síntomas de este problema son:

  • kubectl get secrets produce un error interno.
  • kubectl logs <kmspod-name> -n kube-system contiene errores.
  • Se produce un error en el montaje de secretos en volúmenes al intentar crear pods.
  • El servidor de api no se inicia.

Busque errores en los registros de pods de KMS ejecutando el siguiente comando:

kubectl logs <kmspod-name> -n kube-system

Si los registros devuelven un error con respecto a un token no válido en el pod kmS del clúster de administración, ejecute el siguiente comando:

Update-AksHciCertificates

Si se produce un error con respecto a un token no válido en el pod de KMS del clúster de destino, ejecute el siguiente comando:

UpdateAksHciClusterCertificates -name <cluster-name> -fixcloudcredential

Error 'System.Collections.Hashtable.generic_non_zero 1 [Error: El certificado ha expirado: Expirado]'

El certificado mocctl expira si no se usa durante más de 60 días. AKS Arc usa la mocctl herramienta de línea de comandos para comunicarse con MocStack para realizar operaciones relacionadas con Moc. El certificado que usa el mocclt comando para comunicarse con cloudagent expira en 60 días. El mocctl comando renueva el certificado automáticamente cuando se usa cerca de su expiración (después de aproximadamente 42 días). Si el comando no se usa con frecuencia, el certificado expira.

Para reproducir el comportamiento, instale AKS Arc y no se realice ninguna operación que implique el mocctl comando durante 60 días.

Para corregir el problema, vuelva a iniciar sesión una vez que expire el certificado. Ejecute el siguiente comando de PowerShell para iniciar sesión:

Repair-MocLogin

Eliminación del certificado KVA si ha expirado después de 60 días

El certificado KVA expira después de 60 días si no se realiza ninguna actualización.

El comando Update-AksHci y cualquier comando que implique a kvactl producirá el siguiente error.

Error: failed to get new provider: failed to create azurestackhci session: Certificate has expired: Expired

Para resolver este error, elimine el archivo de certificado expirado en \kvactl\cloudconfig e intente de nuevo Update-AksHci en el nodo que tiene el problema de expiración del certificado. Puede usar el comando siguiente:

$env:UserProfile.wssd\kvactl\cloudconfig

Puede encontrar una explicación sobre el problema en Se debe eliminar el certificado KVA si el certificado KVA expiró después de 60 días.

Se necesitan permisos especiales de Active Directory para los nodos de Azure Stack HCI unidos a un dominio

Los usuarios que implementan y configuran Azure Kubernetes Service en Azure Stack HCI deben tener el permiso Control total para crear objetos de AD en el contenedor de Active Directory en el que se crean los objetos de servidor y servicio.

Eleva los permisos del usuario.

Uninstall-AksHciAdAuth produce el error '[Error del servidor (NotFound): no se encuentran los secretos "keytab-akshci-scale-reliability"

Si Uninstall-AksHciAdAuth muestra este error, debe omitirlo por ahora, ya que se solucionará este problema.

This issue will be fixed.

Los registros de kubectl devuelven "error: debe haber iniciado sesión en el servidor (el servidor ha solicitado al cliente que proporcione credenciales)".

Hay un problema con AKS Arc en el que un clúster puede dejar de devolver registros. Cuando esto sucede, la ejecución kubectl logs <pod_name> devuelve "error: debe iniciar sesión en el servidor (el servidor ha solicitado al cliente que proporcione las credenciales)". AKS Arc gira los certificados principales de Kubernetes cada 4 días, pero a veces el servidor de API de Kubernetes no vuelve a cargar inmediatamente su certificado de cliente para la comunicación con kubelet cuando se actualizan los certificados.

Para mitigar el problema, hay varias opciones:

  • Vuelva a ejecutar kubectl logs. Por ejemplo, ejecute el siguiente comando de PowerShell:

    while (1) {kubectl logs <POD_NAME>; sleep 1}
    
  • Reinicie el kube-apiserver contenedor en cada uno de los planos de control de un clúster. Reiniciar el servidor de API no afecta a la ejecución de cargas de trabajo. Para reiniciar el servidor de API, siga estos pasos:

    1. Obtenga las direcciones IP de cada plano de control del clúster:

      kubectl get nodes -o wide
      
    2. Ejecute el siguiente comando:

      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)'
      
  • Opcionalmente, pero no se recomienda para cargas de trabajo de producción, puede pedir kube-apiserver que no compruebe el certificado de servidor del kubelet:

    kubectl logs <POD_NAME> --insecure-skip-tls-verify-backend=true