Resolución de problemas al actualizar AKS Arc

Las versiones anteriores de PowerShell no se quitan.

Para solucionar este problema, puede ejecutar este script para desinstalar versiones anteriores de PowerShell.

Después de actualizar o escalar verticalmente el clúster de destino, el pod de renovación de certificados se encuentra ahora en un estado de bucle de bloqueo. Espera un archivo yaml cert-tattoo de la ruta de acceso /etc/Kubernetes/pki. El archivo de configuración está presente en las máquinas virtuales del nodo del plano de control, pero no en las máquinas virtuales del nodo de trabajo.

Para resolver este problema, copie manualmente el archivo de tatuaje del certificado desde el nodo del plano de control a cada uno de los nodos de trabajo.

1. Copie el archivo de la VM del plano de control 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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. Copie el archivo de la máquina host en la VM del nodo de trabajo.

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

3. Vuelva a establecer la información de propietario y grupo de este archivo en root si aún no está establecida en root.

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

4. Repita los pasos 2 y 3 para cada uno de los nodos de trabajo.

Cuando un clúster no se ha actualizado durante más de 60 días, el agente de nodo no se puede iniciar durante un reinicio del agente de nodo debido a la expiración del token. Este error hace que los agentes estén en la fase inicial. Los intentos continuos de unirse a cloudagent pueden agotar el suministro de puertos en el host. El estado del comando siguiente es Starting.

Get-Service wssdagent | Select-Object -Property Name, Status

Comportamiento esperado: el agente de nodo debe estar en la fase inicial, que intenta unirse constantemente al agente en la nube, agotando los puertos.

Para resolver el problema, detenga la ejecución de wssdagent. Dado que el servicio está en la fase de inicio, puede impedir que detenga el servicio. Si es así, elimine el proceso antes de intentar detener el servicio.

1. Confirme que wssdagent está en fase de inicio.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

2. Termine el proceso.

   kill -Name wssdagent -Force
   

3. Detenga el servicio.

   Stop-Service wssdagent -Force
   

Get-Process -Name wssdagent

PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand

1. Repita los pasos 1, 2 y 3 en cada nodo del clúster local de Azure que tenga este problema.

2. Después de confirmar que wssdagent no se está ejecutando, inicie cloudagent si no se está ejecutando.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. Confirme que cloudagent está en funcionamiento.

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. Ejecute el siguiente comando para corregir wssdagent:

   Repair-Moc
   

3. Una vez completado este comando, wssdagent debe estar en estado de ejecución.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

Cuando AKS en Azure Local no se puede actualizar de la versión de mayo a la versión de junio, se espera que AKS en Azure Local vuelva a la versión de mayo y siga funcionando. Pero deja a los agentes MOC en un estado detenido y los intentos manuales de iniciar el agente no los activan.

Pasos para reproducir

1. Instale la versión 1.1.36 del módulo de PowerShell de AKS-HCI.
2. Actualice AKS en Azure Local. Si se produce un error en la actualización, AKS en Azure Local retroceda a mayo, pero los agentes de MOC están inactivos.

Comportamiento esperado

Si se produce un error en la actualización de AKS en Azure Local, la expectativa es que AKS en Azure Local vuelva a la versión anterior y siga funcionando sin problemas.

Síntomas

Error de coincidencia entre la versión de Aks-Hci y la versión de MOC

• Get-AksHciVersion: 1.0.10.10513
• Get-MocVersion: 1.0.11.10707

Error de coincidencia entre Get-MocVersion y la versión de wssdcloudagent.exe

Get-MocVersion indica que la compilación de junio está instalada mientras la versión de wssdcloudagent.exe indica que la compilación may está instalada.

La ruta de acceso de la imagen de los servicios del agente MOC tiene el parámetro id. de implementación

Ejecute el siguiente comando para mostrar la ruta de acceso de la imagen para el agente en la nube:

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

Salida de ejemplo

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

Use el siguiente comando para mostrar la ruta de acceso de la imagen para el agente de nodo: consulta reg "HKLM\System\CurrentControlSet\Services\wssdagent".

Salida de ejemplo

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

Para mitigar el problema, ejecute los siguientes cmdlets de PowerShell:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

Al actualizar, puede perder todas las intolerancias, las etiquetas y los roles personalizados que agregó a los nodos de trabajo. Dado que AKS es un servicio administrado, no se admite la adición de taints, etiquetas y roles personalizados cuando se realizan fuera de los cmdlets de PowerShell proporcionados o Windows Admin Center.

A fin de evitar este problema, ejecute el cmdlet New-AksHciNodePool para crear correctamente un grupo de nodos con intolerancias para los nodos de trabajo.

Si creó un clúster de administración pero no ha implementado un clúster de carga de trabajo en los primeros 60 días, se le bloqueará la creación de uno, ya que ahora está fuera de la directiva. En esta situación, al ejecutar Update-AksHci, el proceso de actualización se bloquea con el error Esperando a que la implementación "Operador de facturación de AksHci" esté lista. Si ejecuta Sync-AksHciBilling, devuelve una salida correcta. Sin embargo, si ejecuta Get-AksHciBillingStatus, el estado de conexión es OutofPolicy.

Si no ha implementado un clúster de carga de trabajo en 60 días, la facturación queda fuera de la directiva.

La única manera de corregir este problema es volver a realizar la implementación con una instalación limpia.

Si los nodos locales de Azure se reinician uno después del otro, algunas de las máquinas virtuales pierden las vNIC conectadas a ellos. Esta pérdida de vNIC hace que las máquinas virtuales pierdan la conectividad de red y el clúster entra en un estado incorrecto.

Pasos de reproducción

1. Reinicie un nodo local de Azure.
2. Espere a que el nodo complete el reinicio. El nodo debe marcarse Up en el clúster de conmutación por error.
3. Reinicie los demás nodos.
4. "Una vez

Comportamiento esperado El estado del clúster debe estar en buen estado. Todas las máquinas virtuales deben tener NIC conectadas a ellas.

Para resolver el problema, use los comandos MOC para agregar la vNIC a la máquina virtual.

1. Obtenga el nombre de vNIC de la máquina virtual.

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

o

mocctl.exe compute vm get --name <vmname> --group <group>

2. Conecte la vNIC a la máquina virtual.

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

o

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>

3. Si se produce un error en el comando vNIC connect, intente desconectar y conectarse de nuevo. A continuación se muestra el comando para la desconexión de vNIC.

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

o

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Los pods se bloquean a la espera de que los pods estáticos tengan una condición lista.

Para liberar los pods y resolver este problema, debe reiniciar kubelet. Para ver el nodo NotReady con los pods estáticos, ejecute este comando:

kubectl get nodes -o wide

Si desea más información sobre el nodo con errores, ejecute el comando siguiente:

kubectl describe node <IP of the node>

Use SSH para iniciar sesión en el nodo NotReady mediante la ejecución del comando siguiente:

ssh -i <path of the private key file> administrator@<IP of the node>

Luego, ejecute este comando para reiniciar kubelet:

/etc/.../kubelet restart

Al ejecutar una actualización en Windows Admin Center, se produce el siguiente error:

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

Este mensaje de error suele producirse cuando AKS en Azure Local se implementa en un entorno que tiene configurado un proxy. Actualmente, Windows Admin Center no admite la instalación de módulos en un entorno de proxy.

Para resolver este error, configure AKS en Azure Local mediante el comando proxy de PowerShell.

Al actualizar clústeres de Kubernetes con un agente de directiva abierta (OPA), como OPA GateKeeper, el proceso puede bloquearse y no poder completarse. Este problema puede producirse porque el agente de directivas está configurado para evitar la extracción de imágenes de contenedor de registros privados.

Para resolver este problema, si actualiza los clústeres implementados con una función de OPA, asegúrese de que las directivas permiten extraer imágenes de Azure Container Registry. Para una actualización de AKS en Azure Local, debe agregar el siguiente punto de conexión en la lista de la directiva: ecpacr.azurecr.io.

La ejecución de una actualización del sistema operativo en un host con una implementación de AKS en Azure Local puede hacer que la implementación entre un estado incorrecto y produzca un error en dos operaciones. Es posible que los servicios NodeAgent de MOC no se inicien en los hosts actualizados. Se produce un error en todas las llamadas MOC a los nodos.

Para reproducir: al actualizar un clúster con una implementación de AKS existente de HCI a HCIv2 OS, se puede producir un error en una operación de AKS como New-AksHciCluster . El mensaje de error indica que los nodos MOC son OutOfCapacity. Por ejemplo:

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

Para resolver este problema, inicie el servicio NodeAgent de MOC wssdagent en los nodos afectados. Esto solucionará el problema y devolverá la implementación a un estado correcto. Ejecute el siguiente comando:

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

Después de ejecutar Update-AksHciCluster, el proceso de actualización se detiene.

Ejecute el comando siguiente para comprobar si hay una máquina con PHASE La eliminación que ejecuta la versión anterior de Kubernetes desde la que va a actualizar.

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

Si hay una máquina con PHASE Eliminación y VERSION coincidencia con la versión anterior de Kubernetes, continúe con los pasos siguientes.

Para solucionar este problema, necesita los siguientes fragmentos de información:

1. Versión de Kubernetes a la que va a actualizar el clúster de cargas de trabajo.
2. Dirección IP del nodo que está bloqueado.

Para encontrar esta información, ejecute el siguiente cmdlet y comando. De forma predeterminada, el cmdlet Get-AksHciCredential escribe kubeconfig en ~/.kube/config. Si especifica una ubicación diferente para el clúster de cargas de trabajo kubeconfig al llamar Get-AksHciCredentiala , deberá proporcionar esa ubicación a kubectl como otro argumento. Por ejemplo, kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

El nodo que debe corregirse debe mostrar STATUS Ready,SchedulingDisabled. Si ve un nodo con este estado, use el INTERNAL-IP de este nodo como valor de dirección IP en el siguiente comando. Use la versión de Kubernetes a la que va a actualizar como valor de versión; debe coincidir con el VERSION valor del nodo con ROLES control-plane,master. Asegúrese de incluir el valor completo de la versión de Kubernetes, incluido v, por ejemplo v1.22.6.

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Después de ejecutar este comando ssh, se deben eliminar los nodos restantes con la versión anterior de Kubernetes y la actualización continuará.

La ejecución de una actualización del sistema operativo en un host con una implementación de AKS en Azure Local puede provocar que la implementación entre un estado incorrecto, lo que hace que el servidor de API del clúster de administración no sea accesible y produzca un error en el día dos operaciones. El kube-vip pod no puede aplicar la configuración de VIP a la interfaz y, como resultado, la DIRECCIÓN VIP no es accesible.

Para reproducir: actualice un clúster con una implementación de SISTEMA operativo de AKS HCI existente de HCI a HCIv2. A continuación, pruebe a ejecutar comandos que intenten llegar al clúster de administración, como Get-AksHciCluster. Se produce un error en las operaciones que intentan llegar al clúster de administración con errores como:

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

Para resolver este problema: reinicie el contenedor kube-vip para que la implementación vuelva a estar en buen estado.

1. Obtenga el identificador del contenedor kube-vip:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

La salida debe ser similar a esta y el identificador del contenedor es el primer valor 4a49a5158a5f8. Por ejemplo:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. Reinicie el contenedor:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Este mensaje de estado aparece al ejecutar el cmdlet Update-AksHci de PowerShell.

Revise las siguientes causas principales para resolver el problema:

• Motivo uno: durante la actualización del operador de facturación de AksHci, el operador se marcó incorrectamente como fuera de la directiva. Para resolver este problema, abra una nueva ventana de PowerShell y ejecute Sync-AksHciBilling. Debería ver que la operación de facturación continúa en los próximos 20-30 minutos.

• Motivo dos: la máquina virtual del clúster de administración puede estar sin memoria, lo que hace que el servidor de API no sea accesible y hace que todos los comandos de Get-AksHciCluster, facturación y actualización agote el tiempo de espera. Como solución alternativa, establezca la máquina virtual del clúster de administración en 32 GB en Hyper-V y reiníciela.

• Motivo tres: el operador de facturación de AksHci puede estar fuera del espacio de almacenamiento, lo que se debe a un error en la configuración de Microsoft SQL. La falta de espacio de almacenamiento puede hacer que la actualización deje de responder. Para solucionar este problema, cambie manualmente el tamaño del pod de facturación pvc mediante los pasos siguientes.

  1. Ejecute el siguiente comando para editar la configuración del pod:

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. Cuando se abra en el Bloc de notas u otro editor un archivo YAML, edite la línea de almacenamiento de 100Mi a 5Gi:

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. Utilice el comando siguiente para comprobar el estado de la implementación de la facturación:

     kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

Al actualizar clústeres desde AKS en La actualización de febrero de 2022 de Azure Local a la actualización de abril de 2022, es posible que la actualización se bloquee durante un período de tiempo indefinido. Puede haber pods bloqueados en el Terminating estado o CrashLoopBackoff .

Es posible que vea que faltan algunos de los recursos de complemento csi de AksHci. Estos pods de recursos implementados mediante o csi-akshcicsi-controller desde el csi-akshcicsi-node daemonset.

El complemento CSI de AksHci en la actualización de febrero de 2022 contenía un cambio en la especificación del controlador CSI que a veces puede dejar los recursos del complemento en un estado no responde durante la actualización. El controlador .spec.fsGroupPolicy CSI se estableció en un nuevo valor aunque sea un campo inmutable. Dado que el campo es inmutable, la especificación del controlador no se actualiza. Una consecuencia de esto es que los otros recursos de complemento csi de AksHci podrían no conciliarse completamente. Se volverían a crear todos los recursos CSI.

Para resolver manualmente el problema, el controlador CSI se puede eliminar manualmente. Una vez que lo haya quitado, el operador en la nube reconcilia el complemento CSI de AksHci en los 10 minutos y vuelve a crear el controlador junto con el resto de los recursos de complemento que faltan.

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

Después de una actualización correcta, el panel de actualización de Windows Admin Center todavía muestra la versión anterior.

Para corregir este problema, actualice el explorador.

La compilación 1.0.1.10628 de JUNIO de AKS en Azure Local crea un número excesivo de secretos de configuración de Kubernetes en el clúster. Se ha mejorado la ruta de acceso de actualización de la versión 1.0.1.10628 de junio a la versión 1.0.2.10723 de julio para limpiar los secretos adicionales de Kubernetes. Sin embargo, en algunos casos durante la actualización, los secretos no se han limpiado y, por tanto, se produce un error en el proceso de actualización.

Si sufre este problema, ejecute los pasos siguientes:

1. Guarde el siguiente script como un archivo y asígnele el nombre fix_leaked_secrets.ps1:

   upgparam (
   [Parameter(Mandatory=$true)]
   [string] $ClusterName,
   [Parameter(Mandatory=$true)]
   [string] $ManagementKubeConfigPath
   )
   
   $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
   "Hostname is: $ControlPlaneHostName"
   
   $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
   $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
   $leakedSecretPath3 = "$ClusterName-kube-vip"
   $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
   $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
   $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
   
   $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
   $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
   
   foreach ($leakedSecretName in $leakedSecretNameList)
   {
   "Deleting secrets with the prefix $leakedSecretName"
   $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
   "Deleted: $output"
   }
   

2. A continuación, ejecute el siguiente comando y utilice el archivo elfix_secret_leak.ps1 que guardó:

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. Por último, use el siguiente comando de PowerShell para repetir el proceso de actualización:

      Update-AksHci
   

Pasos siguientes

• Introducción a la solución de problemas
• Problemas y errores de instalación
• Problemas conocidos de Windows Admin Center

Si sigue experimentando problemas al usar AKS Arc, puede archivar errores a través de GitHub.