Устранение проблем и ошибок во время установки AKS Arc

Это сообщение об ошибке появляется после запуска Install-AksHci.

Если вы не используете Приватный канал, чтобы устранить эту проблему, выполните следующие действия:

1. Откройте PowerShell и запустите Uninstall-AksHci.
2. Откройте портал Azure и перейдите к группе ресурсов, которую вы использовали при выполненииInstall-AksHci.
3. Проверьте наличие всех подключенных ресурсов кластера, которые отображаются в отключенном состоянии и включают имя, отображаемое как случайно созданный GUID.
4. Удалите эти ресурсы кластера.
5. Закройте сеанс PowerShell и откройте новый сеанс перед повторным запуском Install-AksHci .

Эта ошибка может быть вызвана процессом установки, пытающимся нарушить политику Azure, установленную в подписке Azure или группе ресурсов, предоставленной во время процесса подключения Azure Arc. Эта ошибка может возникать для пользователей, которые определили политики Azure на уровне подписки или группы ресурсов, а затем попытаются установить AKS на локальном компьютере Azure, который нарушает Политика Azure.

Чтобы устранить эту проблему, ознакомьтесь с сообщением об ошибке, чтобы понять, какие Политика Azure, заданные администратором Azure, были нарушены, а затем измените политику Azure, сделав исключение для политики Azure. Дополнительные сведения об исключениях политик см. в разделе Политика Azure структура исключения.

Ранее установленный компонент остается в состоянии сбоя и не очищен. Вы можете получать следующую ошибку:

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]

Или вы можете увидеть:

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]

Чтобы устранить эту проблему, вручную очистите роль кластера. Ресурс можно удалить из диспетчера отказоустойчивого кластера, выполнив следующий командлет PowerShell: Remove-ClusterResource -name <resource name>

Командлет Install-AksHci завершается ошибкой "Ошибка GetRelease, возвращаемая вызовом API: ошибка скачивания файла: несоответствие хэша".

1. Откройте PowerShell и запустите .Uninstall-AksHci
2. Повторите установку.
3. Если проблема сохраняется, используйте -concurrentDownloads параметр с Set-AksHciConfig и задайте для него число меньше, чем значение по умолчанию 10, прежде чем повторить установку. Сокращение числа одновременных скачиваемых файлов может помочь конфиденциальным сетям успешно завершить скачивание больших файлов. Этот параметр является функцией предварительной версии.

После развертывания при перезагрузке локальных узлов Azure отчет AKS показал сбой состояния выставления счетов.

Чтобы устранить эту проблему, следуйте инструкциям, чтобы вручную повернуть маркер и перезапустить подключаемый модуль KMS.

После запуска Install-AksHci установка остановлена и отображается следующее сообщение об ошибке:

\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.]

Существует несколько причин, по которым установка может завершиться ошибкой waiting for API server .

В следующем разделе описаны возможные причины и решения этой ошибки.

Причина 1. Неправильной конфигурации IP-шлюза, если вы используете статические IP-адреса и получили следующее сообщение об ошибке, убедитесь, что конфигурация IP-адреса и шлюза правильна.

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 [ ]

Чтобы проверить правильность конфигурации IP-адреса и шлюза, выполните следующую команду:

ipconfig /all

В отображаемых параметрах конфигурации подтвердите конфигурацию. Вы также можете попытаться выполнить связь с IP-шлюзом и DNS-сервером.

ping <DNS server>

Если эти методы не работают, используйте New-AksHciNetworkSetting для изменения конфигурации.

Причина 2. Неправильный DNS-сервер, если вы используете статические IP-адреса, убедитесь, что DNS-сервер правильно настроен. Чтобы проверить DNS-адрес сервера узла, используйте следующую команду:

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

Убедитесь, что DNS-сервер совпадает с адресом, используемым при запуске New-AksHciNetworkSetting , выполнив следующую команду:

Get-MocConfig

Если DNS-сервер был неправильно настроен, переустановите AKS на локальном компьютере Azure с правильным DNS-сервером. Дополнительные сведения см. в статье "Перезапустить", "Удалить" или переустановить Служба Azure Kubernetes в локальной среде Azure.

Проблема устранена после удаления конфигурации и перезапуска виртуальной машины с новой конфигурацией.

Install-AksHci Не удалось выполнить эту ошибку, так как к другому процессу осуществляется mocstack.cabдоступ.

Чтобы устранить эту проблему, закройте все открытые окна PowerShell, а затем откройте новое окно PowerShell снова.

Не удается получить доступ к файлу, так как он используется другим процессом.

Эту проблему можно устранить, перезапустив сеанс PowerShell. Закройте окно PowerShell и повторите попытку install-AksHci.

Install-AksHci Не удалось выполнить эту ошибку, так как диапазоны пула IP, предоставленные в AKS в локальной конфигурации Azure, были отключены на 1 в CIDR и могут привести к сбою CloudAgent. Например, если у вас есть подсеть 10.0.0.0/21 с диапазоном адресов 10.0.0.0–10.0.7.255, а вы используете начальный адрес 10.0.0.1 или конечный адрес 10.0.7.254, это приведет к аварийному завершению CloudAgent.

Чтобы обойти эту проблему, запустите New-AksHciNetworkSetting и используйте любой другой допустимый диапазон IP-адресов для пула ВИРТУАЛЬНЫх IP-адресов и пула узлов Kubernetes. Убедитесь, что используемые значения не отключаются от 1 в начале или конце диапазона адресов.

При запуске Install-AksHci в установке с одним узлом установка работала, но при настройке отказоустойчивого кластера установка завершается ошибкой. Однако связь с облачным агентом показала, что CloudAgent доступен.

Чтобы убедиться, что все узлы могут разрешать DNS CloudAgent, выполните следующую команду на каждом узле:

Resolve-DnsName <FQDN of cloudagent>

Когда приведенный выше шаг завершается успешно на узлах, убедитесь, что узлы могут получить доступ к порту CloudAgent, чтобы убедиться, что прокси-сервер не пытается заблокировать это подключение и порт открыт. Для этого выполните следующую команду на каждом узле:

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

Ошибка возникает из-за ошибки с скачиванием.

Если вы получите эту ошибку, используйте последнюю версию Microsoft Edge или Google Chrome и повторите попытку.

Эта ошибка возникает после запуска Set-AksHciRegistration в AKS на локальной установке Azure. Ошибка указывает, что поставщики ресурсов Kubernetes не зарегистрированы для клиента, вошедшего в систему.

Чтобы устранить эту проблему, выполните действия Azure CLI или PowerShell ниже.

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

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

Регистрация занимает около 10 минут. Чтобы отслеживать процесс регистрации, используйте следующие команды.

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 зависает перед Waiting for azure-arc-onboarding to complete истечением времени ожидания:

• Субъект-служба используется в AKS в локальной регистрации Azure (Set-AksHciRegistration).
• Установленная версия модулей PowerShell az.Accounts (2.7.x).

Az.Accounts 2.7.x Версии удаляют ServicePrincipalSecret и CertificatePassword PSAzureRmAccountв, которые используются AKS в локальной среде Azure для подключения Azure Arc.

Для воспроизведения:

1. Установите Az.Accounts версию модулей PowerShell (>= 2.7.0).
2. Set-AksHciRegistration использование субъекта-службы.
3. Install-AksHci.

Ожидаемое поведение:

1. AkS в локальной установке Azure зависает Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding Модули pod попадают в цикл сбоя.
3. Ошибка Azure-arc-onboarding pod со следующей ошибкой:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Для разрешения этой проблемы:

Удалите модули Az.Accounts с версиями 2.7.x. выполните следующий командлет:

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

Эта ошибка возникает, когда локальная служба Azure выходит за пределы политики. Состояние подключения в кластере может отображаться, но в журнале событий отображается предупреждение Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Чтобы устранить эту ошибку, убедитесь, что кластер зарегистрирован в Azure с помощью командлета Get-AzureStackHCI PowerShell, доступного на компьютере. На панели Windows Admin Center также отображаются сведения о состоянии регистрации Azure в кластере.

Если кластер уже зарегистрирован, то следует просмотреть поле LastConnected в выходных данных Get-AzureStackHCI. Если в поле указано более 30 дней, следует попытаться разрешить ситуацию с помощью командлета Sync-AzureStackHCI.

Вы также можете проверить, имеет ли каждый узел кластера необходимую лицензию с помощью следующего командлета:

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

Если проблема не устранена после выполнения командлета Sync-AzureStackHCI , обратитесь в службу поддержки Майкрософт.

Эта проблема возникает, так как сбой установки может привести к утечке ресурсов, которые необходимо очистить до повторной установки.

Если установка завершается сбоем с помощью Install-AksHci, перед повторной запуском Install-AksHci выполните команду Uninstall-AksHci.

Эти ошибки можно активировать при запуске Install-AksHci без запуска Set-AksHciConfig .

Чтобы устранить ошибку, запустите uninstall-akshci и закройте все окна PowerShell. Откройте новый сеанс PowerShell и перезапустите процесс установки AKS в локальной среде Azure, выполнив установку AKS в Azure Local с помощью PowerShell.

Командлет Set-AksHciConfig PowerShell завершается ошибкой:

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

Если вы используете AKS с прокси-сервером, возможно, вы использовали неправильный URL-адрес при настройке требуемого значения URL-адреса прокси-сервера HTTPS. При настройке AKS с прокси-сервером url-адреса HTTP-прокси и URL-адреса HTTPS обычно требуются оба значения для совместного использования одного и того же URL-адреса с префиксом HTTP.

Если это может быть в вашей среде, попробуйте выполнить следующие действия по устранению рисков.

1. Закройте окно PowerShell и откройте новый.
2. New-AksHciNetworkSetting Снова запустите и New-AksHciProxySetting командлеты. При выполнении New-AksHciProxySetting-https задайте параметр с тем же значением URL-адреса, префиксированного HTTP, для которых задано -httpзначение.
3. Запустите и перейдите Set-AksHciConfig .

При развертывании AKS в Локальной среде Azure развертывание может истекть в разных точках процесса в зависимости от того, где произошла ошибка. Необходимо просмотреть сообщение об ошибке, чтобы определить причину и место ее возникновения.

Например, в следующей ошибке точка, в которой произошла ошибка, находится в 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"}

Это означает, что физический локальный узел Azure может разрешить имя URL-адреса скачивания, msk8s.api.cdp.microsoft.comно узел не может подключиться к целевому серверу.

Чтобы устранить эту проблему, необходимо определить, где произошла разбивка в потоке подключения. Ниже приведены некоторые шаги, чтобы попытаться устранить проблему с узла физического кластера:

1. Проверка ping целевого DNS-имени: ping msk8s.api.cdp.microsoft.com.
2. Если вы получите ответ обратно и не истекает время ожидания, то базовый сетевой путь работает.
3. Если время ожидания подключения истекает, может произойти разрыв в пути к данным. Дополнительные сведения см. в разделе "Проверка параметров прокси-сервера". Или же может возникнуть разрыв в пути возврата, поэтому следует проверить правила брандмауэра.

При запуске Set-AksHciConfig может возникнуть следующая ошибка:

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.

Эта ошибка обычно происходит в результате изменения маркера безопасности пользователя (из-за изменения членства в группе), изменения пароля или использования пароля с истекшим сроком действия. В большинстве случаев проблему можно устранить, если выполнить выход из системы компьютера, а затем войти в нее снова. Если проблема по-прежнему завершается сбоем, вы можете подать проблему в GitHub AKS Azure Local.

Ожидается, что агенты Moc будут хранить только последние 100 журналов агента. Они должны удалить старые журналы. Однако смена журнала не происходит, и журналы продолжают накапливаться, потребляя дисковое пространство.

Для воспроизведения: Install AksHci и запуска кластера до тех пор, пока число журналов агента не превышает 100. Во время создания журнала nth агенты должны удалить журнал n-100th, если они существуют.

Чтобы решить эту проблему, выполните указанные ниже действия.

1. Измените файлы logconf агента облака и агентов узлов. Логагент облачного агента находится по адресу:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Logconfig агента узла находится по адресу:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Измените значение Limit на 100 и Слоты на 100 и сохраните файлы конфигурации.

3. Перезапустите агент облака и агенты узла, чтобы зарегистрировать эти изменения.

Эти шаги запускают смену журнала только после создания 100 новых журналов из перезапуска агента. Если во время перезапуска уже есть журналы агента, смена журнала начнется только после создания журналов n+100.

При использовании Set-AksHciConfig для указания -imageDir, -workingDir-cloudConfigLocationили -nodeConfigLocation параметров с именем пути, содержащим пробел, напримерD:\Cloud Share\AKS HCI, служба кластера облачных агентов не сможет начаться со следующего (или аналогичного) сообщения об ошибке:

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'

Чтобы обойти эту проблему, используйте путь, который не включает пробелы, например C:\CloudShare\AKS-HCI.

Эта ошибка может возникать при неправильной настройке инфраструктуры.

Для устранения ошибки сделайте следующее.

1. Проверьте конфигурацию сервера DNS узла и параметры шлюза:

   1. Убедитесь, что DNS-сервер настроен правильно. Чтобы проверить адрес DNS-сервера узла, выполните следующую команду:

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

   2. Чтобы проверить правильность конфигурации IP-адреса и шлюза, выполните команду ipconfig/all.
   3. Попробуйте проверить связь с IP-шлюзом и DNS-сервером.

2. Проверьте службу CloudAgent, чтобы убедиться, что она запущена:

   1. Проверьте связь со службой CloudAgent, чтобы убедиться, что она доступна.
   2. Убедитесь, что все узлы могут разрешать DNS CloudAgent, выполнив следующую команду на каждом узле:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. После успешного выполнения предыдущего шага на узлах убедитесь, что узлы могут установить связь через порт CloudAgent, чтобы проверить, не пытается ли прокси-сервер заблокировать это подключение и открыт ли порт. Для этого запустите выполнение следующей команды на каждом узле: .

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

   4. Чтобы проверить, запущена ли служба кластера для отказоустойчивого кластера, можно также выполнить следующую команду:

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

Обычно это означает, что объект имени кластера (CNO), представляющий базовый отказоустойчивый кластер в службах домен Active Directory (AD DS), не имеет разрешений на создание объекта виртуального компьютера (VCO) в подразделении или в контейнере, где находится кластер.

Если вы не являетесь администратором домена, вы можете попросить указать разрешения CNO для подразделения или предварительной подготовки виртуальной машины для универсальной службы кластера облачного агента.

Если вы являетесь администратором домена, возможно, что у подразделения или контейнера нет необходимых разрешений. Например, режим принудительного применения, представленный в KB5008383, может быть включен в Active Directory. Прежде чем пытаться переустановить, попробуйте выполнить указанные ниже действия.

1. Перейдите к Пользователи и компьютеры Active Directory.
2. Щелкните правой кнопкой мыши подразделение или контейнер, где находится кластер.
3. Выберите "Делегирование элемента управления", чтобы открыть мастер делегирования элементов управления.
4. Нажмите кнопку "Далее> добавить ", чтобы открыть окно выбора пользователей, компьютеров или групп .
5. Выберите нужную группу или пользователей, которым требуется делегировать элемент управления > " ОК".
6. Нажмите кнопку "Создать пользовательскую задачу", чтобы делегировать> переход на страницу "Тип объекта Active Directory".
7. Выберите только следующие объекты в папке> Select Computer objects> Select Computer Select Create selected objects in this folder and Delete selected objects in this folder> Click Next , чтобы перейти на страницу "Разрешения".
8. Выберите "Создать все дочерние объекты" и удалить все дочерние объекты из списка разрешений > нажмите кнопку "Далее>готово"

Если переустановка завершается ошибкой, повторите приведенные выше действия, выполнив следующие изменения в шагах 7 и 8.

• Шаг 7. Выберите эту папку, существующие объекты в этой папке и создание новых объектов в этой папке> нажмите кнопку "Далее".
• Шаг 8. Выбор пункта "Чтение", "Запись", "Создать все дочерние объекты" и "Удалить все дочерние объекты" из списка разрешений > нажмите кнопку "Далее>" нажмите кнопку "Готово".

Эта ошибка может возникать при запуске Install-AksHci.

Дополнительные сведения можно получить, выполнив $error = Install-AksHci и затем $error[0].Exception.InnerException.

Команды PowerShell Aks-Hci не проверяют доступную память на сервере узла перед созданием узлов Kubernetes. Эта проблема может привести к нехватке памяти и виртуальным машинам, которые не запускались. Этот сбой в настоящее время не обрабатывается корректно, и развертывание перестанет отвечать без четкого сообщения об ошибке.

Если у вас есть развертывание, которое перестает отвечать, откройте Просмотр событий и проверьте сообщение об ошибке, связанное с Hyper-V, указывающее, что недостаточно памяти для запуска виртуальной машины.

Эта ошибка может возникать при наличии нескольких клиентов в учетной записи Azure.

Используется $tenantId = (Get-AzContext).Tenant.Id для задания правильного клиента. Затем включите этот клиент в качестве параметра при запуске Set-AksHciRegistration.

При попытке развернуть кластер AKS на виртуальной машине Azure установка зависла Waiting for pod 'Cloud Operator' to be ready..., а затем завершилась сбоем и истекло через два часа. Попытки устранить неполадки, проверив шлюз и DNS-сервер, показали, что они работают надлежащим образом. Проверка конфликтов IP-адресов или MAC-адресов не найдена. Журналы не отображали пул ВИРТУАЛЬНЫх IP-адресов. Было ограничение на извлечение образа контейнера с использованием sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 времени ожидания tls, а не несанкционированного доступа.

Чтобы устранить эту проблему, выполните следующие действия.

1. Начните развертывать кластер.
2. При развертывании кластера подключитесь к виртуальной машине кластера управления через SSH, как показано ниже:

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

3. Измените максимальный параметр единицы передачи (MTU). Не стесняйтесь вносить изменения; Если изменение было слишком поздно, развертывание завершается ошибкой. Изменение параметра MTU помогает разблокировать извлечение образа контейнера.

sudo ifconfig eth0 mtu 1300

4. Чтобы просмотреть состояние контейнеров, выполните следующую команду:

sudo docker ps -a

После выполнения этих действий вытягивание образа контейнера должно быть разблокировано.

Эта ошибка означает, что IP-адрес облачной службы не является частью сети кластера и не соответствует ни одной из сетей кластера, имеющих включенную client and cluster communication роль.

Чтобы устранить эту проблему, запустите Get-ClusterNetwork , где Role равно ClusterAndClient. Затем на одном из узлов кластера выберите имя, адрес и маску адресов, чтобы убедиться, что IP-адрес, указанный для -cloudServiceIP параметра New-AksHciNetworkSetting , соответствует одной из отображаемых сетей.

Enable-AksHciArcConnection может подключить кластер AKS к Azure, но в нем показано следующее предупреждение, когда клиент использует субъект-службу для проверки подлинности:

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

Текущее поведение подключения Arc — включить пользовательские расположения по умолчанию. Чтобы включить пользовательские расположения, действие GetServicePrincipals выполняется в контексте пользователя Azure, вошедшего в систему. Если у пользователя (или имени субъекта-службы) нет достаточных разрешений для этого, команда выдает предупреждение о том, что эти разрешения не существуют, и поэтому функция "Пользовательские расположения" не будет включена.

Если вы не хотите включить пользовательские расположения, вы можете безопасно игнорировать это предупреждение, так как это не влияет на подключение кластера к Arc. С другой стороны, если требуется включить настраиваемые расположения, необходимо предоставить пользователю необходимые разрешения (или имя субъекта-службы).

Следующие шаги

• Обзор устранения неполадок
• Известные проблемы с Windows Admin Center
• Устранение неполадок с кластерами Kubernetes

Если вы продолжаете столкнуться с проблемами при использовании AKS Arc, вы можете отправлять ошибки через GitHub.