Resolución de problemas y errores durante una instalación de AKS Arc

Este mensaje de error aparece después de ejecutar Install-AksHci.

Si no usa Private Link, para resolver este problema, siga estos pasos:

1. Abra PowerShell y ejecute Uninstall-AksHci.
2. Abra Azure Portal y vaya al grupo de recursos que usó al ejecutar Install-AksHci.
3. Compruebe si hay recursos de clúster conectados que aparezcan en estado Desconectado e incluya un nombre que se muestra como un GUID generado aleatoriamente.
4. Elimine estos recursos del clúster.
5. Cierre la sesión de PowerShell y abra una nueva antes de volver a ejecutar Install-AksHci.

Este error puede deberse al proceso de instalación que intenta infringir una directiva de Azure establecida en la suscripción de Azure o en el grupo de recursos proporcionado durante el proceso de incorporación de Azure Arc. Este error puede producirse para los usuarios que han definido directivas de Azure en un nivel de suscripción o grupo de recursos y, a continuación, intentar instalar AKS en Azure Local que infringe una directiva de Azure.

Para resolver este problema, lea el mensaje de error para comprender qué conjunto de Azure Policy ha infringido el administrador de Azure y, a continuación, modifique la directiva de Azure mediante la realización de una excepción a la directiva de Azure. Para más información sobre las excepciones de las directivas, consulte el artículo sobre la estructura de las exenciones de directivas de Azure.

Una característica instalada previamente permanece en estado de error y no se ha borrado. Puede ver el siguiente error:

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

O bien, es posible que aparezca:

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

Para resolver este problema, limpie manualmente el rol de clúster. Para quitar el recurso del administrador de clústeres de conmutación por error, ejecute el siguiente cmdlet de PowerShell: Remove-ClusterResource -name <resource name>.

El Install-AksHci cmdlet produce un error "GetRelease devuelto por la llamada API: Error de descarga de archivo: Error de coincidencia de hash".

1. Abra PowerShell y ejecute Uninstall-AksHci.
2. Vuelva a intentar una instalación.
3. Si el problema persiste, use el -concurrentDownloads parámetro con Set-AksHciConfig y establézcalo en un número inferior al predeterminado 10 antes de reintentar una instalación. Reducir el número de descargas simultáneas puede ayudar a las redes confidenciales a completar descargas de archivos grandes correctamente. Este parámetro es una característica en vista previa.

Después de la implementación, al reiniciar los nodos locales de Azure, el informe de AKS mostró un estado de error para la facturación.

Para resolver este problema, siga las instrucciones para girar manualmente el token y reiniciar el complemento de KMS.

Después de ejecutar Install-AksHci, la instalación se detuvo y mostró el siguiente mensaje de error:

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
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.]

Hay varios motivos por los que podría producirse un error en la instalación con el error waiting for API server.

En la sección siguiente se describen las posibles causas y soluciones para este error.

Motivo 1: Configuración incorrecta de la puerta de enlace IP Si usa direcciones IP estáticas y recibió el siguiente mensaje de error, confirme que la configuración de la dirección IP y la puerta de enlace son correctas.

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

Para comprobar si tiene la configuración adecuada para la dirección IP y la puerta de enlace, ejecute el siguiente comando:

ipconfig /all

En los valores de configuración mostrados, confirme la configuración. También puede intentar hacer ping a la puerta de enlace IP y al servidor DNS.

ping <DNS server>

Si estos métodos no funcionan, use New-AksHciNetworkSetting para cambiar la configuración.

Motivo 2: Servidor DNS incorrecto Si usa direcciones IP estáticas, confirme que el servidor DNS está configurado correctamente. Para comprobar la dirección del servidor DNS del host, use el siguiente comando:

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

Para confirmar que la dirección del servidor DNS sea la misma que la que se usa al ejecutar New-AksHciNetworkSetting, ejecute el comando siguiente:

Get-MocConfig

Si el servidor DNS se ha configurado incorrectamente, vuelva a instalar AKS en Azure Local con el servidor DNS correcto. Para más información, consulte Reinicio, eliminación o reinstalación de Azure Kubernetes Service en Azure Local .

El problema se resolvió después de eliminar la configuración y reiniciar la VM con una nueva configuración.

Install-AksHci produjo este error porque otro proceso está accediendo a mocstack.cab.

Para resolver este problema, cierre todas las ventanas de PowerShell abiertas y vuelva a abrir una nueva ventana de PowerShell.

No se puede acceder al archivo porque otro proceso lo está utilizando.

Para resolver este problema, puede reiniciar la sesión de PowerShell. Cierre la ventana de PowerShell e inténtelo de nuevo en Install-AksHci.

Install-AksHci error con este error porque los intervalos del grupo de DIRECCIONES IP proporcionados en la configuración de AKS en Azure Local se han desactivado en 1 del CIDR y pueden provocar que CloudAgent se bloquee. Por ejemplo, si tiene la subred 10.0.0.0/21 con un intervalo de direcciones 10.0.0.0 - 10.0.7.255 y, a continuación, usa la dirección de inicio 10.0.0.1 o una dirección final 10.0.7.254, esto haría que CloudAgent se bloqueara.

Para solucionar este problema, ejecute New-AksHciNetworkSetting y use cualquier otro intervalo de direcciones IP válido para el grupo de DIRECCIONES VIP y el grupo de nodos de Kubernetes. Asegúrese de que los valores que use no estén desactivados en 1 al principio o al final del intervalo de direcciones.

Al ejecutar Install-AksHci en una instalación de un solo nodo, la instalación ha funcionado, pero al configurar el clúster de conmutación por error, se produce un error en la instalación con el mensaje de error. Sin embargo, al hacer ping al agente en la nube se mostró que CloudAgent era accesible.

Para asegurarse de que todos los nodos pueden resolver el DNS de CloudAgent, ejecute el siguiente comando en cada nodo:

Resolve-DnsName <FQDN of cloudagent>

Cuando el paso anterior se realice correctamente en los nodos, asegúrese de que los nodos puedan llegar al puerto CloudAgent para comprobar que un proxy no está intentando bloquear esta conexión y que el puerto está abierto. Para ello, ejecute el siguiente comando en cada nodo:

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

El error se deriva de un error con la descarga.

Si recibe este error, debe usar la versión más reciente de Microsoft Edge o Google Chrome e intentarlo de nuevo.

Este error aparece después de ejecutar Set-AksHciRegistration en una instalación de AKS en Azure Local. El error indica que los proveedores de recursos de Kubernetes no están registrados para el inquilino que está conectado en este momento.

Para resolver este problema, ejecute los pasos siguientes de la CLI de Azure o PowerShell:

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

El registro tarda aproximadamente 10 minutos en completarse. Para supervisar el proceso de registro, use los comandos siguientes.

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci deja de funcionar en Waiting for azure-arc-onboarding to complete de que se supere el tiempo de expiración cuando:

• Una entidad de servicio se usa en AKS en el registro local de Azure (Set-AksHciRegistration).
• Está instalada la versión de los módulos Az.Accounts de PowerShell (2.7.x).

Az.Accounts 2.7.x las versiones quitan y ServicePrincipalSecret CertificatePassword en PSAzureRmAccount, que usa AKS en Azure Local para la incorporación de Azure Arc.

Pasos de reproducción:

1. Instale la versión (>= 2.7.0) de los módulos de PowerShell de Az.Accounts.
2. Set-AksHciRegistration mediante una entidad de servicio.
3. Install-AksHci.

Comportamiento esperado:

1. La instalación de AKS en Azure Local se bloquea en Waiting for azure-arc-onboarding to complete.
2. Los pods de Azure-arc-onboarding entran en un bucle de bloqueo.
3. Error de los pods de Azure-arc-onboarding:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Para solucionar este problema:

Desinstale los módulos Az.Accounts con las versiones 2.7.x. y ejecute el siguiente cmdlet:

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

Este error se produce cuando Azure Local está fuera de la directiva. El estado de conexión en el clúster puede mostrar que está conectado, pero el registro de eventos muestra el mensaje de advertencia que indica Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Para resolver este error, compruebe que el clúster está registrado en Azure mediante el cmdlet de PowerShell Get-AzureStackHCI que está disponible en la máquina. En el panel de Windows Admin Center también se muestra información de estado sobre el registro de Azure del clúster.

Si el clúster ya está registrado, debería ver el campo LastConnected en la salida de Get-AzureStackHCI. Si el campo muestra que han pasado más de 30 días, debe intentar resolver la situación mediante el cmdlet Sync-AzureStackHCI.

También puede validar si cada nodo del clúster tiene la licencia necesaria mediante el siguiente cmdlet:

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Si el problema no se resuelve después de ejecutar el cmdlet Sync-AzureStackHCI, debe comunicarse con el soporte técnico de Microsoft.

Este problema se produce porque una instalación con errores puede dejar recursos que se deben limpiar antes de poder realizar otra instalación.

Si se produce un error en la instalación mediante Install-AksHci, debe ejecutar Uninstall-AksHci antes de volver a ejecutar Install-AksHci.

Puede desencadenar estos errores cuando se ejecuta Install-AksHci sin ejecutar Set-AksHciConfig primero.

Para resolver el error, ejecute y uninstall-akshci cierre todas las ventanas de PowerShell. Abra una nueva sesión de PowerShell y reinicie el proceso de instalación de AKS en Azure Local siguiendo la instalación de AKS en Azure Local mediante PowerShell.

Se Set-AksHciConfig produce un error en el cmdlet de PowerShell:

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

Si usa AKS con un servidor proxy, es posible que haya usado la dirección URL incorrecta al establecer el valor de dirección URL de proxy HTTPS necesario. Los valores de DIRECCIÓN URL del proxy HTTP y DE PROXY HTTPS son necesarios al configurar AKS con un servidor proxy, pero es habitual que ambos valores compartan la misma dirección URL con prefijo HTTP.

Si este podría ser el caso en su entorno, pruebe los pasos de mitigación siguientes:

1. Cierre la ventana de PowerShell y abra una nueva.
2. Vuelva a ejecutar los New-AksHciNetworkSetting cmdlets y New-AksHciProxySetting . Al ejecutar New-AksHciProxySetting, establezca el -https parámetro con el mismo valor de dirección URL con prefijo HTTP establecido para -http.
3. Ejecute Set-AksHciConfig y continúe.

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.

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.

Normalmente, 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 sigue produciendo un error, puede presentar un problema en GitHub AKS Azure Local issues (Problemas locales de AkS de GitHub).

Se espera que los agentes de MOC conserven solo los últimos 100 registros. Se supone que eliminan los anteriores. Sin embargo, no se produce la rotación de registros y los registros se acumulan, lo que consume espacio en disco.

Para reproducir Install AksHci y tener un clúster en funcionamiento hasta que el número de registros del agente supere los 100. En el momento de la creación del enésimo registro, se espera que los agentes eliminen el ncentésimo n centésimo registro, si existen.

Para resolver el problema:

1. Modifique los archivos logconf del agente de la nube y de los agentes de los nodos. El archivo logconfig del agente de la nube se encuentra en:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   El archivo logconfig del agente del nodo se encuentra en:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Cambie el valor tanto de Límite como de Ranuras a 100 y guarde los archivos de configuración.

3. Reinicie el agente de la nube y los agentes de los nodos para registrar estos cambios.

Estos pasos no inician la rotación de registros hasta que se hayan generado 100 registros nuevos desde el reinicio del agente. Si ya hay n registros de agente en el momento del reinicio, la rotación de registros no se iniciará hasta que se generen n+100 registros.

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.

Este error puede producirse cuando hay una configuración incorrecta de la infraestructura.

Siga estos pasos para resolver este error:

1. Compruebe la configuración del servidor DNS del host y la configuración de la puerta de enlace:

   1. Confirme que el servidor DNS está configurado correctamente. Para comprobar la dirección del servidor DNS del host, ejecute el siguiente comando:

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. Para comprobar si la dirección IP y la configuración de la puerta de enlace son correctas, ejecute el comando ipconfig/all.
   3. Intente hacer ping a la puerta de enlace IP y al servidor DNS.

2. Compruebe el servicio CloudAgent para asegurarse de que se esté ejecutando:

   1. Haga ping al servicio CloudAgent para asegurarse de que sea accesible.
   2. Asegúrese de que todos los nodos pueden resolver el DNS de CloudAgent ejecutando el siguiente comando en cada nodo:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Cuando el paso anterior se realice correctamente en los nodos, asegúrese de que los nodos puedan llegar al puerto CloudAgent para comprobar que un proxy no está intentando bloquear esta conexión y que el puerto está abierto. Para ello, ejecute el siguiente comando en cada nodo:

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. Para comprobar si el servicio de clúster se está ejecutando para un clúster de conmutación por error, también puede ejecutar el siguiente comando:

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

Esto suele indicar que el objeto de nombre de clúster (CNO) que representa el clúster de conmutación por error subyacente en Servicios de dominio de Active Directory (AD DS) no tiene permisos para crear un objeto de equipo virtual (VCO) en la unidad organizativa (UO) o en el contenedor donde reside el clúster.

Si no es administrador de dominio, puede pedir a uno que conceda los permisos de CNO a la unidad organizativa o preconfigurar un VCO para el servicio de clúster genérico del agente en la nube.

Si es administrador de dominio, es posible que la unidad organizativa o el contenedor no tengan los permisos necesarios. Por ejemplo, el modo de cumplimiento, introducido en KB5008383, puede habilitarse en Active Directory. Pruebe lo siguiente antes de intentar una reinstalación.

1. Vaya a Usuarios y equipos de Active Directory.
2. Haga clic con el botón derecho en la unidad organizativa o el contenedor donde reside el clúster.
3. Seleccione Delegar control... para abrir el Asistente para delegación de controles.
4. Haga clic en Siguiente> haga clic en Agregar... para abrir la ventana Seleccionar usuarios, equipos o grupos.
5. Seleccione su elección de grupo o usuarios a los que desea delegar el control > Haga clic en Aceptar.
6. Seleccione Crear una tarea personalizada para delegar> Haga clic en Siguiente para pasar a la página Tipo de objeto de Active Directory.
7. Seleccione Solo los siguientes objetos en la carpeta> Seleccionar objetos> de equipo Seleccione Crear objetos seleccionados en esta carpeta y Eliminar objetos seleccionados en esta carpeta> Haga clic en Siguiente para pasar a la página Permisos.
8. Seleccione Crear todos los objetos secundarios y Eliminar todos los objetos secundarios en la lista de permisos > Haga clic en Finalizar siguiente>.

Si se produce un error en una reinstalación, vuelva a intentarlo con los siguientes cambios en los pasos 7 y 8:

• Paso 7: Seleccione esta carpeta, los objetos existentes en esta carpeta y la creación de nuevos objetos en esta carpeta> Haga clic en Siguiente.
• Paso 8: Seleccione Leer, Escribir, Crear todos los objetos secundarios y Eliminar todos los objetos secundarios de la lista de permisos > Haga clic en Siguiente> clic en Finalizar.

Puede recibir este error al ejecutar Install-AksHci.

Para obtener más información, ejecute $error = Install-AksHci y, a continuación, $error[0].Exception.InnerException.

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 las máquinas virtuales no se inicien. 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.

Se puede producir este error si tiene varios inquilinos en su cuenta de Azure.

Use $tenantId = (Get-AzContext).Tenant.Id para establecer el inquilino correcto. A continuación, incluya este inquilino como parámetro mientras ejecuta Set-AksHciRegistration.

Al intentar implementar un clúster de AKS en una máquina virtual de Azure, la instalación se atascó en Waiting for pod 'Cloud Operator' to be ready...y, a continuación, se produjo un error y se agotó el tiempo de espera después de dos horas. Con las soluciones de problemas mediante la comprobación de la puerta de enlace y el servidor DNS se detectó que funcionaban correctamente. No se encontraron ninguna comprobación de los conflictos de direcciones IP o MAC. Los registros no mostraron el grupo de VIP. Había una restricción para extraer la imagen de contenedor mediante sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 que devolvía un tiempo de espera de seguridad de la capa de transporte (TLS) en lugar de No autorizado.

Para resolver este problema, siga estos pasos:

1. Empiece a implementar el clúster.
2. Cuando se implementa el clúster, conéctese a la máquina virtual del clúster de administración mediante SSH, como se muestra a continuación:

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. Cambie la configuración de la unidad de transmisión máxima (MTU). No dudes en hacer el cambio; Si realiza el cambio demasiado tarde, se produce un error en la implementación. La modificación de la configuración de MTU ayuda a desbloquear la extracción de la imagen de contenedor.

sudo ifconfig eth0 mtu 1300

4. Para ver el estado de los contenedores, ejecute el comando siguiente:

sudo docker ps -a

Después de realizar estos pasos, se debe desbloquear la extracción de imágenes de contenedor.

Este error indica que la dirección IP del servicio en la nube no forma parte de la red del clúster y no coincide con ninguna de las redes de clúster que tienen habilitado el rol client and cluster communication.

Para resolver este problema, ejecute Get-ClusterNetwork donde Role es igual a ClusterAndClient. A continuación, en uno de los nodos de clúster, seleccione el nombre, la dirección y la máscara de dirección para comprobar que la dirección IP proporcionada para el parámetro -cloudServiceIP de New-AksHciNetworkSetting coincide con una de las redes mostradas.

Enable-AksHciArcConnection puede conectar un clúster de AKS a Azure, pero muestra la siguiente advertencia cuando el cliente usa una entidad de servicio para la autenticación:

WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS on Azure Local cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

El comportamiento actual de la incorporación de Arc es habilitar ubicaciones personalizadas de forma predeterminada. Para habilitar ubicaciones personalizadas, la acción GetServicePrincipals se realiza en el contexto del usuario de Azure que ha iniciado sesión. Si el usuario (o SPN) no tiene permisos suficientes para poder hacerlo, el comando emite una advertencia de que estos permisos no existen y, por tanto, no se habilitará la característica Ubicaciones personalizadas.

Si no desea que las ubicaciones personalizadas estén habilitadas, puede omitir esta advertencia de forma segura, ya que esto no afecta a la incorporación de clústeres a Arc. Por otro lado, si necesita habilitar ubicaciones personalizadas, debe conceder los permisos necesarios al usuario (o SPN).

Pasos siguientes

• Introducción a la solución de problemas
• Problemas conocidos de Windows Admin Center
• Solución de problemas de clústeres de Kubernetes

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