Solución de problemas de administración y clúster de cargas de trabajo de Kubernetes en AKS Arc

Al ejecutar el comando Remove-ClusterNode, el nodo se expulsa del clúster de conmutación por error, pero si no se ejecuta posteriormente Remove-AksHciNode, el nodo seguirá existiendo en CloudAgent.

Puesto que el nodo se quitó del clúster, pero no de CloudAgent, si usa el disco duro virtual para crear un nuevo nodo, aparece un error "Archivo no encontrado". Este problema se produce porque el disco duro virtual está en almacenamiento compartido y el nodo quitado no tiene acceso a él.

Para resolver este problema, quite un nodo físico del clúster y siga estos pasos:

1. Ejecute Remove-AksHciNode para anular el registro del nodo desde CloudAgent.
2. Realice un mantenimiento rutinario, como la creación de una nueva imagen de la máquina.
3. Agregue el nodo de nuevo al clúster.
4. Ejecute Add-AksHciNode para registrar el nodo con CloudAgent.

Con los clústeres grandes, el comando Get-AksHciLogs puede generar una excepción, que no se enumeren los nodos o que no se genere el archivo de salida c:\wssd\wssdlogs.zip.

Esto se debe a que el comando de PowerShell para comprimir un archivo, "Compress-Archive", tiene un límite de tamaño de archivo de salida de 2 GB.

Después de actualizar o escalar verticalmente el clúster de cargas de trabajo, el pod de renovación de certificados se encuentra ahora en un estado de bucle de bloqueos ya que el pod espera un archivo YAML cert-tattoo desde la ubicación /etc/Kubernetes/pki del archivo.

Este problema puede deberse a un archivo de configuración que está presente en las máquinas virtuales del plano de control, pero no en las máquinas virtuales del nodo de trabajo.

Para resolver este problema, copie manualmente el archivo YAML cert-tattoo desde el nodo del plano de control a todos los nodos de trabajo.

1. Copie el archivo YAML de la máquina virtual del plano de control en el clúster de cargas de trabajo en el directorio actual de la máquina host:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Copie el archivo YAML de la máquina host en la máquina virtual del nodo de trabajo. Antes de copiar el archivo, debe cambiar el nombre de la máquina en el archivo YAML por el nombre del nodo en el que lo va a copiar (este es el nombre del nodo para el plano de control del clúster de cargas de trabajo).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Si la información de propietario y grupo del archivo YAML aún no está establecida en la raíz, establézcala:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Repita los pasos 2 y 3 con todos los nodos de trabajo.

Los comandos Aks-Hci de PowerShell no validan la memoria disponible en el servidor host antes de crear los nodos de Kubernetes. Este problema puede dar lugar al agotamiento de la memoria y a que no se inicien las máquinas virtuales.

Actualmente, este error no se controla de manera correcta, por lo que la implementación dejará de responder sin ningún mensaje de error claro. Si la implementación deja de responder, abra el Visor de eventos y busque un mensaje de error relacionado con Hyper-V que indique que no hay suficiente memoria para iniciar la VM.

Al ejecutar Get-AksHciCluster para comprobar el estado de una instalación de AKS Arc en Windows Admin Center, la salida muestra un error: "No se encontró una versión con la versión 1.0.3.10818". Sin embargo, al ejecutar Get-AksHciVersion, se mostró la misma versión instalada. Este error indica que la compilación ha expirado.

Para resolver este problema, ejecute Uninstall-AksHciy, a continuación, ejecute una nueva compilación de AKS Arc.

Al usar la herramienta de administración de clústeres para trasladar una máquina virtual de un nodo (nodo A) a otro nodo (nodo B) del clúster de Azure Stack HCI, es posible que la máquina virtual no se inicie en el nuevo nodo. Después de mover la máquina virtual de nuevo al nodo original, esta no se inicia allí.

Este problema se produce porque la lógica para limpiar la primera migración se ejecuta de forma asincrónica. Como resultado, la lógica de "actualización de la ubicación de la máquina virtual" de Azure Kubernetes Service busca la máquina virtual en la instancia original de Hyper-V en el nodo A y la elimina, en lugar de anular su registro.

Para solucionar este problema, asegúrese de que la máquina virtual se ha iniciado correctamente en el nuevo nodo antes de volver a trasladarla al nodo original.

Al usar PowerShell para crear un clúster con direcciones IP estáticas e intentar aumentar el número de nodos de trabajo en el clúster de carga de trabajo, la instalación se bloquea en "recuento del plano de control en 2, esperando el estado deseado: 3". Después de un período de tiempo, aparece otro mensaje de error: "Error: tiempo de espera agotado para la condición".

Cuando se ejecutó Get-AksHciCluster, se mostró que los nodos del plano de control se crearon y aprovisionaron y estaban en estado Listo. Sin embargo, cuando se ejecutó kubectl get nodes, se mostró que los nodos del plano de control se habían creado, pero no aprovisionado y no estaban en estado Listo.

Si recibe este error, compruebe que las direcciones IP se hayan asignado a los nodos creados mediante el Administrador de Hyper-V o PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

A continuación, compruebe la configuración de red para asegurarse de que quedan suficientes direcciones IP en el grupo para crear más VM.

Los comandos como Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesy todas las interacciones con el clúster de administración pueden devolver "Error: Debe haber iniciado sesión en el servidor (no autorizado)."

Este error puede producirse cuando el archivo kubeconfig ha expirado. Para comprobar si ha expirado, ejecute el siguiente script:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Si este script muestra una fecha anterior a la fecha actual, el archivo kubeconfig ha expirado.

Para mitigar el problema, copie el archivo admin.conf , que está dentro de la máquina virtual del plano de control de administración, en el host de HCI:

• SSH en la máquina virtual del plano de control de administración:

  • Obtenga la dirección IP de la máquina virtual del plano de control de administración:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH en él:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Copie el archivo en la ubicación clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Concesión de acceso a clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Opcional] Cree una copia de seguridad del archivo kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Copie el archivo:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Cuando comprueba el administrador de Hyper-V, las demandas de CPU y memoria elevadas para el clúster de administración se pueden omitir de forma segura. Están relacionados con picos en el uso de los recursos de proceso al aprovisionar clústeres de cargas de trabajo.

Aumentar la memoria o el tamaño de la CPU para el clúster de administración no ha mostrado una mejora significativa y se puede omitir de forma segura.

Verá este problema si sigue los pasos a continuación:

1. Cree un clúster de Kubernetes.
2. Escale el clúster a más de dos nodos.
3. Ejecute el siguiente comando para eliminar un nodo:

kubectl delete node <node-name>

4. Ejecute el siguiente comando para devolver una lista de nodos:

kubectl get nodes

El nodo eliminado no aparece en la salida. 5. Abra una ventana de PowerShell con privilegios administrativos y ejecute el siguiente comando:

get-vm

El nodo eliminado todavía aparece en la lista.

Este error hace que el sistema no reconozca que falta el nodo y, por tanto, no se pondrá en marcha un nuevo nodo.

Si no usa un clúster de administración o carga de trabajo durante más de 60 días, los certificados expiran y debe renovarlos para poder actualizar AKS Arc. Cuando un clúster de AKS no se actualiza en un plazo de 60 días, el token de complemento de KMS y los certificados expiran en los 60 días. El clúster sigue funcionando. Sin embargo, dado que supera los 60 días, debe llamar al soporte técnico de Microsoft para actualizar. Si el clúster se reinicia después de este período, permanecerá en un estado no funcional.

Para resolver el problema, siga estos pasos:

1. Repare el certificado del clúster de administración rotando manualmente el token y, a continuación, reinicie el complemento y el contenedor de KMS.
2. Para reparar los certificados mocctl, ejecute Repair-MocLogin.
3. Repare los certificados del clúster de carga de trabajo rotando manualmente el token y, a continuación, reinicie el complemento y el contenedor de KMS.

Es posible que no se encuentre el clúster de carga de trabajo si los grupos de direcciones IP de dos implementaciones de AKS en Azure Stack HCI son iguales o se superponen. Si implementa dos hosts de AKS y usa la misma configuración de AksHciNetworkSetting para ambos, es posible que PowerShell y Windows no puedan encontrar el clúster de carga de trabajo, ya que el servidor de API tendrá asignada la misma dirección IP en ambos clústeres, lo que provocará un conflicto.

El mensaje de error que recibirá tendrá un aspecto similar al del ejemplo que se muestra a continuación.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

La implementación de un clúster grande puede agotar el tiempo de espera después de dos horas. Sin embargo, se trata de un tiempo de espera estático.

Puede omitir esta repetición de tiempo de espera, ya que la operación se está ejecutando en segundo plano. Use el comando kubectl get nodes para acceder al clúster y supervisar el progreso.

Al intentar activar una implementación de AKS en Azure Stack HCI después de unos días, Kubectl no ejecutó ninguno de sus comandos. El Servicio de administración de claves (KMS) del complemento muestra el mensaje de error rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates.

Se produce un error en el cmdlet Repair-AksHciClusterCerts si el servidor de API está fuera de servicio. Si AKS en Azure Stack HCI no se ha actualizado durante 60 días o más, cuando intente reiniciar el complemento de KMS, no se iniciará. Este error también provoca un error en el servidor de API.

Para corregir este problema, debe rotar manualmente el token y, a continuación, reiniciar el complemento y el contenedor de KMS para obtener la copia de seguridad del servidor de API. Para ello, ejecute los pasos siguientes:

1. Para rotar el token, ejecute el siguiente comando:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Copie el token en la máquina virtual con el siguiente comando. La configuración ip del comando siguiente hace referencia a la dirección IP del plano de control del host de AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Reinicie el complemento y el contenedor de KMS.

   Para obtener el identificador del contenedor, ejecute el siguiente comando:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   La salida debe tener los campos siguientes:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   La salida debería tener un aspecto similar a este ejemplo:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Finalmente, ejecute el comando siguiente para reiniciar el contenedor:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

En una instalación de AKS en Azure Stack HCI con la versión 1.82.0 de la extensión de Windows Admin Center, el clúster de administración se ha configurado con PowerShell y se ha intentado implementar un clúster de carga de trabajo mediante Windows Admin Center. Una de las máquinas tenía instalada la versión 1.0.2 del módulo de PowerShell y las demás tenían instalado el módulo de PowerShell 1.1.3. Error al intentar implementar el clúster de carga de trabajo con el error "No se encuentra un parámetro que coincida con el nombre del parámetro 'nodePoolName'". Este error puede haberse producido debido a un error de coincidencia de versión. A partir de la versión 1.1.0 de PowerShell, el parámetro -nodePoolName <String> se agregó al cmdlet -nodePoolName <String> y, por diseño, este parámetro es ahora obligatorio al usar la versión 1.82.0 de la extensión de Windows Admin Center.

Para solucionar este problema, realice una de las acciones siguientes:

• Use PowerShell para actualizar manualmente el clúster de carga de trabajo a la versión 1.1.0 o posterior.
• Use Windows Admin Center para actualizar el clúster a la versión 1.1.0 o a la versión más reciente de PowerShell.

Este problema no se produce si el clúster de administración se implementa mediante Windows Admin Center, ya que ya tiene instalados los módulos de PowerShell más recientes.

Al implementar AKS en Azure Stack HCI y, a continuación, ejecutar kubectl get pods, los pods del mismo nodo se bloquean en el estado Terminación . La máquina rechaza las conexiones SSH porque es probable que el nodo experimente una demanda de memoria elevada. Este problema se produce porque los nodos de Windows están aprovisionados en exceso y no hay ninguna reserva para los componentes principales.

Para evitar esta situación, agregue los límites de recursos y las solicitudes de recursos para la CPU y memoria a la especificación del pod para asegurarse de que los nodos no se aprovisionen en exceso. Los nodos de Windows no admiten la expulsión en función de los límites de recursos, por lo que deberá calcular cuánto usarán los contenedores y, a continuación, asegurarse de que los nodos tienen cantidades suficientes de CPU y memoria. Para obtener más información, consulte los requisitos del sistema.

El escalado automático del clúster puede producir un error al usar la siguiente directiva de Azure en el clúster de administración de hosts de AKS: "Los clústeres de Kubernetes no deben usar el espacio de nombres predeterminado". Esto sucede porque la directiva, cuando se implementa en el clúster de administración de hosts de AKS, bloquea la creación de perfiles de escalador automático en el espacio de nombres predeterminado. Para corregir este problema, elija una de las siguientes opciones:

• Desinstale la extensión Azure Policy en el clúster de administración de hosts de AKS. Obtenga más información sobre cómo desinstalar Azure Policy extensiones aquí.
• Cambie el ámbito de la directiva de Azure para excluir clústeres de administración de hosts de AKS. Obtenga más información sobre los ámbitos de Azure Policy aquí.
• Establezca el modo de cumplimiento de directivas en "Deshabilitado" para el clúster de administración de hosts de AKS. Obtenga más información sobre el modo de aplicación aquí.

Se trata de un problema conocido con AKS en la actualización de julio de Azure Stack HCI (versión 1.0.2.10723). El error se produce porque el servicio CloudAgent tiene un tiempo de espera durante la distribución de máquinas virtuales entre varios volúmenes compartidos de clúster en el sistema.

Para resolver este problema, debe actualizar a la versión más reciente de AKS en Azure Stack HCI.

Si aprovisiona un clúster de AKS en Azure Stack HCI con cero nodos de Linux o Windows, al ejecutar Get-AksHciCluster, la salida será una cadena vacía o un valor null.

Null es una devolución esperada para cero nodos.

Al apagar un clúster de administración o carga de trabajo durante más de cuatro días, los certificados expiran y no se puede acceder al clúster. Los certificados expiran porque se rotan cada 3-4 días por motivos de seguridad.

Para reiniciar el clúster, debe reparar manualmente los certificados para poder realizar cualquier operación de clúster. Para reparar los certificados, ejecute el siguiente comando Repair-AksHciClusterCerts:

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Al escalar horizontalmente un clúster de cargas de trabajo, las máquinas virtuales Linux y Windows correspondientes se agregaron como nodos de trabajo, pero no se configuraron como máquinas virtuales de alta disponibilidad. Al ejecutar el comando Get-ClusterGroup, la máquina virtual Linux recién creada no se configuró como un grupo de clústeres.

Se trata de un problema conocido. Después de un reinicio, a veces se pierde la capacidad de configurar máquinas virtuales como de alta disponibilidad. La solución alternativa actual es reiniciar wssdagent en cada uno de los nodos de Azure Stack HCI. Esto solo funciona para nuevas máquinas virtuales generadas mediante la creación de grupos de nodos al realizar una operación de escalabilidad horizontal o al crear nuevos clústeres de Kubernetes después de reiniciar en wssdagent los nodos. Sin embargo, tendrá que agregar manualmente las máquinas virtuales existentes al clúster de conmutación por error.

Al reducir verticalmente un clúster, los recursos del clúster de alta disponibilidad están en estado de error mientras se quitan las máquinas virtuales. La solución a este problema es eliminar manualmente los recursos con errores.

Anteriormente, un clúster de AKS implementado en una máquina virtual de Azure funcionaba correctamente, pero después de desactivar el host de AKS durante varios días, el Kubectl comando no funcionaba. Después de ejecutar el comando Kubectl get nodes o Kubectl get services, apareció este mensaje de error: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Este problema se produjo porque el host de AKS se desactivó durante más de cuatro días, lo que ha provocado que los certificados expiren. Los certificados se rotan con frecuencia en un ciclo de cuatro días. Ejecute Repair-AksHciClusterCerts para corregir el problema de expiración de certificados.

En un clúster de cargas de trabajo con direcciones IP estáticas y nodos de Windows, todos los pods de un nodo (incluidos los daemonset pods) se bloquean en un estado ContainerCreating . Al intentar conectarse a ese nodo mediante SSH, se produce un Connection timed out error en la conexión.

Para resolver este problema, use el Administrador de Hyper-V o el Administrador de clústeres de conmutación por error para desactivar la máquina virtual de ese nodo. Después de 5 a 10 minutos, se debe volver a crear el nodo, con todos los pods en ejecución.

Cuando kubelet está bajo presión de disco, recopila imágenes de contenedor sin usar, que pueden incluir imágenes de pausa y, cuando esto sucede, ContainerD no puede extraer la imagen.

Para resolver el problema, siga estos pasos:

1. Conéctese al nodo afectado mediante SSH y ejecute el siguiente comando:

sudo su

2. Para extraer la imagen, ejecute el siguiente comando:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Pasos siguientes

• Introducción a la solución de problemas
• Problemas y errores de red
• Problemas conocidos del almacenamiento