Corrección de problemas conocidos y errores al configurar una red en AKS Arc

Es posible que el agente en la nube no se inicie correctamente al usar nombres de ruta de acceso con espacios en ellos.

Cuando se usa Set-AksHciConfig para especificar los parámetros -imageDir, -workingDir, -cloudConfigLocation o -nodeConfigLocation con un nombre de ruta de acceso que contiene un carácter de espacio, como D:\Cloud Share\AKS HCI, el servicio de clúster del agente en la nube no se iniciará y aparecerá el siguiente mensaje de error (u otro parecido):

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Como solución alternativa a este problema, use una ruta de acceso que no incluya espacios, por ejemplo, C:\CloudShare\AKS-HCI.

Los clústeres conectados a Azure Arc para Kubernetes pueden tener el valor de la propiedad distribution JSON establecida en una cadena vacía. En el caso de los clústeres conectados a AKS Arc, este valor se establece durante la instalación inicial y nunca se modifica durante la vigencia de la implementación.

Para reproducir el problema, abra una ventana de Azure PowerShell y ejecute los siguientes comandos:

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

A continuación se muestra un ejemplo de salida de este comando:

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

Para resolver el problema

Si la salida de la propiedad JSON distribution devuelve una cadena vacía, siga estas instrucciones para aplicar revisiones al clúster:

1. Copie la siguiente configuración en un archivo denominado patchBody.json:

   {
      "properties": {
        "distribution": "aks_management"
      }
   }
   

   Importante

   Si el clúster es un clúster de administración de AKS, el valor debe establecerse aks_managementen . Si es un clúster de cargas de trabajo, debe establecerse en aks_workload.

2. En la salida JSON que obtuvo anteriormente, copie el identificador del clúster conectado. Debería aparecer como una cadena larga en el formato siguiente:

   "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

3. Ejecute el siguiente comando para aplicar revisiones al clúster. El <cc_arm_id> valor debe ser el identificador obtenido en el paso 2:

   az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"
   

4. Compruebe que el clúster se ha revisado correctamente mediante la ejecución az connectedk8s show -g <rg_name> -n <cc_name> de para asegurarse de que la propiedad distribution JSON se ha establecido correctamente.

Síntomas:

• Proxy habilitado en AKS Arc. El servicio WSSDAgent está bloqueado en el starting estado. Se muestra como el siguiente:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> desde el nodo en el que se produce un error en el agente de nodo hacia el agente en la nube funciona correctamente en el sistema (incluso cuando wssdagent no se inicia)
• Curl.exe del nodo en el que el agente produce errores hacia el agente en la nube reproduce el problema y se bloquea: curl.exe https://<computerIP>:6500
• Para corregir el problema, pase la --noproxy marca a curl.exe. Curl devuelve un error de wssdcloudagent. Esto se espera porque curl no es un cliente GRPC. Curl no se queda atascado esperando al enviar la --noproxy marca. Por lo tanto, devolver un error se considera correcto aquí):

curl.exe --noproxy '*' https://<computerIP>:65000

Es probable que la configuración del proxy se haya cambiado a un proxy defectuoso en el host. La configuración de proxy para AKS Arc son variables de entorno que se heredan del proceso primario en el host. Esta configuración solo se propaga cuando se inicia un nuevo servicio o se reinicia uno anterior. Es posible que la configuración de proxy defectuoso se haya establecido en el host y se propagó a WSSDAgent después de una actualización o reinicio, lo que ha provocado un error en WSSDAgent.

Tendrá que corregir la configuración del proxy cambiando las variables de entorno en la máquina. En el equipo, cambie las variables con los siguientes comandos:

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

Reinicie la máquina para que el administrador de servicios y WSSDAgent recojan el proxy fijo.

Este error se produce porque cada vez que se inicia el pod CAPH, se intenta iniciar un inicio de sesión en cloudagent y el certificado se almacena en el volumen de almacenamiento temporal, que se limpiará en los reinicios del pod. Por lo tanto, cada vez que se reinicia un pod, se destruye el certificado y se realiza un nuevo intento de inicio de sesión.

Un intento de inicio de sesión inicia una rutina de renovación, que renueva el certificado cuando se acerca a la expiración. El pod CAPH decide si se necesita un inicio de sesión si el certificado está disponible o no. Si el certificado está disponible, no se intenta iniciar sesión, suponiendo que la rutina de renovación ya esté ahí.

Sin embargo, en un reinicio del contenedor, no se limpia el directorio temporal, por lo que el archivo todavía se conserva y no se realiza el intento de inicio de sesión, lo que provoca que la rutina de renovación no se inicie. Esto conduce a la expiración del certificado.

Para mitigar este problema, reinicie el pod CAPH mediante el siguiente comando:

kubectl delete pod pod-name

Al ejecutar Set-AksHciConfig, puede encontrar el siguiente error:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

En la mayoría de los casos, este error es consecuencia de un cambio en el token de seguridad del usuario (debido a un cambio en la pertenencia a grupos), un cambio de contraseña o una contraseña expirada. En la mayoría de los casos, el problema se puede corregir cerrando sesión en el equipo y volviendo a iniciarla. Si el error todavía se produce, puede crear una incidencia de soporte técnico a través de Azure Portal.

Este problema hace que un clúster de AKS Arc permanezca en estado ScalingControlPlane durante un período de tiempo prolongado.

Pasos de reproducción

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

Este problema se ha corregido en versiones recientes de AKS Arc. Se recomienda actualizar los clústeres de AKS Arc a la versión más reciente.

Para mitigar este problema, póngase en contacto con el soporte técnico para revisar manualmente el estado de los nodos del plano de control para quitar la condición MachineOwnerRemediatedCondition del estado de la máquina a través de kubectl.

Es posible que no se encuentre el clúster de cargas de trabajo si los grupos de direcciones IP de dos implementaciones de AKS en Azure Local son iguales o se superponen. Si implementa dos hosts de AKS y usa la misma AksHciNetworkSetting configuración para ambos, PowerShell y Windows Admin Center podrían no encontrar el clúster de cargas de trabajo porque al servidor de API se le asignará 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.

Para resolver el problema, elimine uno de los clústeres y cree una nueva configuración de red del clúster de AKS que tenga una red no superpuesta con los demás clústeres.

Al ejecutar el comando Get-AksHciClusterNetwork se proporciona una lista de todas las configuraciones de red virtual. Sin embargo, el comando no muestra la asignación actual de las direcciones IP.

Para averiguar qué direcciones IP están actualmente en uso en una red virtual, siga estos pasos:

1. Para obtener el grupo, ejecute el siguiente comando:

Get-MocGroup -location MocLocation

2. Para obtener la lista de direcciones IP que están actualmente en uso y la lista de direcciones IP virtuales disponibles o usadas, ejecute el siguiente comando:

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. Use el comando siguiente para ver la lista de direcciones IP virtuales que están actualmente en uso:

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

Una dirección IP del clúster se muestra como "Error" durante la comprobación previa. Esta comprobación previa comprueba que todas las direcciones IPv4 y los nombres de red DNS estén en línea y sean accesibles. Por ejemplo, un nombre IPv4 o de red con error puede provocar un error en esta prueba.

Para resolverlo, realice los pasos siguientes:

1. Ejecute el siguiente comando:

   Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
   

2. Asegúrese de que todos los nombres de red y las direcciones IP estén en un estado en línea.

3. Ejecute los siguientes dos comandos:

   Stop-ClusterResource -name "Cluster IP Address x.x.x.x"
   

   Y entonces

   Start-ClusterResource -name "Cluster IP Address x.x.x.x"
   

Al implementar AKS en Azure Local, la implementación puede agotar el tiempo de espera en distintos puntos del proceso en función de dónde se produjo la configuración incorrecta. Tiene que revisar el mensaje de error para establecer la causa y dónde ocurrió.

Por ejemplo, en el siguiente error, el punto en el que se produjo la configuración incorrecta está en Get-DownloadSdkRelease -Name "mocstack-stable":

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Esto indica que el nodo físico de Azure Local puede resolver el nombre de la dirección URL de descarga, msk8s.api.cdp.microsoft.com, pero el nodo no se puede conectar al servidor de destino.

Para resolver este problema, tiene que determinar dónde se produjo la interrupción en el flujo de conexión. Estos son algunos pasos para intentar resolver el problema desde el nodo físico del clúster:

1. Haga ping al nombre DNS de destino: haga ping a msk8s.api.cdp.microsoft.com.
2. Si recibe una respuesta sin que se agote el tiempo de espera, la ruta de acceso de red básica funciona.
3. Si se agota el tiempo de espera de la conexión, podría haber una interrupción en la ruta de los datos. Para obtener más información, consulte Comprobación de la configuración de un proxy. O bien, puede que haya una interrupción en la ruta devuelta, por lo que debería revisar las reglas del firewall.

Las aplicaciones que dependen del tiempo NTP pueden desencadenar cientos de alertas falsas cuando están sin sincronización a tiempo. Si el clúster se ejecuta en un entorno de proxy, es posible que los grupos de nodos no puedan comunicarse con el servidor NTP predeterminado, time.windows.com, a través del proxy o el firewall.

Solución alternativa

Para solucionar este problema, actualice la configuración del servidor NTP en cada nodo de grupo de nodos para sincronizar los relojes. Al hacerlo, también se establecerán los relojes en cada uno de los pods de la aplicación.

Requisitos previos

• Dirección de un servidor NTP al que se puede acceder en cada nodo de grupo de nodos.
• Acceso al archivo kubeconfig del clúster de cargas de trabajo.
• Acceso al clúster de administración kubeconfig.

Pasos

1. Ejecute el comando siguiente kubectl mediante el clúster de cargas de trabajo kubeconfig para obtener una lista de nodos en él:

   kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
   

2. Ejecute el comando siguiente kubectl para correlacionar los nombres de nodo del comando anterior con los nodos de grupo de nodos del clúster de carga de trabajo. Tome nota de las direcciones IP pertinentes de la salida del comando anterior.

   kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>
   

3. Con la salida de los pasos anteriores, ejecute los pasos siguientes para cada nodo de grupo de nodos que necesite su configuración NTP actualizada:

   1. SSH en una máquina virtual de nodo de grupo de nodos:

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
      

   2. Compruebe que el servidor NTP configurado no es accesible:

      sudo timedatectl timesync-status
      

      Si la salida tiene este aspecto, el servidor NTP no es accesible y debe cambiarse:

      Server: n/a (time.windows.com)
      Poll interval: 0 (min: 32s; max 34min 8s)
      Packet count: 0
      

   3. Para actualizar el servidor NTP, ejecute los siguientes comandos para establecer el servidor NTP en el archivo de configuración de timesync en uno al que sea accesible desde la máquina virtual nodepool:

      # make a backup of the config file
      sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak
      
      # update the ntp server
      NTPSERVER="NEW_NTP_SERVER_ADDRESS"
      sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf
      
      # verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
      sudo cat /etc/systemd/timesyncd.conf 
      

   4. Reinicie el servicio timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Compruebe que el servidor NTP es accesible:

      sudo timedatectl timesync-status
      

   6. Compruebe que el reloj muestra la hora correcta:

      date
      

4. Asegúrese de que cada nodo de grupo de nodos muestra la misma hora ejecutando el comando del paso 3.f.

5. Si la aplicación no actualiza su tiempo automáticamente, reinicie sus pods.

Pasos siguientes

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