Устранение известных проблем и ошибок при настройке сети в AKS Arc

Облачный агент может успешно начать работу при использовании имен путей с пробелами в них.

При использовании 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.

Кластеры, подключенные к Azure Arc для Kubernetes, могут иметь значение для свойства distribution JSON, заданного для пустой строки. Для кластеров, подключенных к AKS Arc, это значение устанавливается во время начальной установки и никогда не изменяется в течение всего времени существования развертывания.

Чтобы воспроизвести проблему, откройте окно Azure PowerShell и выполните следующие команды:

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

Ниже приведен пример выходных данных из этой команды:

{
"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"
}

Устранение проблемы

Если выходные данные для свойства JSON distribution возвращают пустую строку, выполните следующие инструкции, чтобы исправить кластер:

1. Скопируйте следующую конфигурацию в файл с именем patchBody.json:

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

   Внимание

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

2. Из выходных данных JSON, полученных выше, скопируйте идентификатор подключенного кластера. Она должна отображаться в виде длинной строки в следующем формате:

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

3. Выполните следующую команду, чтобы исправить кластер. Значение <cc_arm_id> должно быть идентификатором, полученным на шаге 2.

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

4. Убедитесь, что кластер успешно исправлен, выполнив выполнение az connectedk8s show -g <rg_name> -n <cc_name> , чтобы убедиться, что свойство distribution JSON было правильно задано.

Симптомы

• Прокси-сервер включен в AKS Arc. Служба WSSDAgent зависла в starting состоянии. Отображается следующим образом:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> от узла, в котором агент узла не работает должным образом в системе (даже если wssdagent не удается запустить)
• Curl.exe с узла, на котором агент не удается воспроизвести проблему и зависает: curl.exe https://<computerIP>:6500
• Чтобы устранить проблему, передайте --noproxy флаг в curl.exe. Curl возвращает ошибку из wssdcloudagent. Это ожидается, так как curl не является клиентом GRPC. Curl не зависает, ожидая, когда вы отправляете --noproxy флаг. Поэтому возврат ошибки считается успешным здесь):

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

Скорее всего, параметры прокси-сервера были изменены на неисправный прокси-сервер на узле. Параметры прокси-сервера для AKS Arc — это переменные среды, унаследованные от родительского процесса на узле. Эти параметры распространяются только при запуске новой службы или старых обновлениях или перезагрузках. Возможно, что на узле были установлены неисправные параметры прокси-сервера, и они были распространены в WSSDAgent после обновления или перезагрузки, что привело к сбою WSSDAgent.

Необходимо исправить параметры прокси-сервера, изменив переменные среды на компьютере. На компьютере измените переменные с помощью следующих команд:

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

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

Эта ошибка возникает из-за того, что при каждом запуске pod CAPH выполняется попытка входа в cloudagent и сертификат хранится во временном томе хранилища, который будет очищаться при перезапуске pod. Поэтому при каждом перезапуске модуля pod сертификат уничтожается и выполняется новая попытка входа.

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

Однако при перезапуске контейнера временный каталог не очищается, поэтому файл по-прежнему сохраняется и попытка входа не выполняется, что приводит к тому, что подпрограмма продления не запускается. Это приводит к истечении срока действия сертификата.

Чтобы устранить эту проблему, перезапустите pod CAPH с помощью следующей команды:

kubectl delete pod pod-name

При запуске 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.

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

Эта проблема приводит к тому, что кластер AKS Arc остается в состоянии ScalingControlPlane в течение длительного периода времени.

Воспроизведение

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>

Эта проблема устранена в последних версиях AKS Arc. Мы рекомендуем обновить кластеры AKS Arc до последнего выпуска.

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

Кластер рабочей нагрузки не найден, если пулы IP-адресов двух AKS в локальных развертываниях Azure совпадают или перекрываются. Если развернуть два узла AKS и использовать ту же AksHciNetworkSetting конфигурацию для обоих, PowerShell и Windows Admin Center потенциально не удастся найти кластер рабочей нагрузки, так как сервер API будет назначен один и тот же IP-адрес в обоих кластерах, что приведет к конфликту.

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

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.

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

Выполнение команды Get-AksHciClusterNetwork предоставляет список всех конфигураций виртуальной сети. Однако команда не отображает текущее выделение IP-адресов.

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

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

Get-MocGroup -location MocLocation

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

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

3. Используйте следующую команду, чтобы просмотреть список виртуальных IP-адресов, которые в настоящее время используются:

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

IP-адрес кластера отображается как "Сбой" во время предварительной проверки. Эта предварительная проверка проверяет, что все IPv4-адреса и dns-имена сети доступны в Сети и доступны. Например, неудачное имя IPv4 или сетевое имя может привести к сбою этого теста.

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

1. Выполните следующую команду:

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

2. Убедитесь, что все сетевые имена и IP-адреса находятся в состоянии "в сети".

3. Выполните следующие две команды:

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

   И потом

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

При развертывании 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. Если время ожидания подключения истекает, может произойти разрыв в пути к данным. Дополнительные сведения см. в разделе "Проверка параметров прокси-сервера". Или же может возникнуть разрыв в пути возврата, поэтому следует проверить правила брандмауэра.

Приложения, зависящие от времени NTP, могут запускать сотни ложных оповещений, когда они не синхронизируются. Если кластер выполняется в прокси-среде, возможно, вы не сможете взаимодействовать с сервером NTP по умолчанию, time.windows.com через прокси-сервер или брандмауэр.

Обходное решение

Чтобы обойти эту проблему, обновите конфигурацию сервера NTP на каждом узле nodepool, чтобы синхронизировать часы. Это также позволит задать часы в каждом из модулей pod приложения.

Необходимые компоненты

• Адрес сервера NTP, доступного на каждом узле nodepool.
• Доступ к файлу kubeconfig кластера рабочей нагрузки.
• Доступ к kubeconfig кластера управления.

Шаги

1. Выполните следующую kubectl команду с помощью kubeconfig кластера рабочей нагрузки, чтобы получить список узлов в нем:

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

2. Выполните следующую kubectl команду, чтобы сопоставить имена узлов из предыдущей команды с узлами узла кластера рабочей нагрузки. Запишите соответствующие IP-адреса из выходных данных предыдущей команды.

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

3. Используя выходные данные из предыдущих шагов, выполните следующие действия для каждого узла nodepool, который требует обновления конфигурации NTP:

   1. SSH в виртуальную машину узла nodepool:

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

   2. Убедитесь, что настроенный NTP-сервер недоступен:

      sudo timedatectl timesync-status
      

      Если выходные данные выглядят следующим образом, сервер NTP недоступен и его необходимо изменить:

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

   3. Чтобы обновить NTP-сервер, выполните следующие команды, чтобы задать NTP-сервер в файле конфигурации timesync, который доступен из виртуальной машины 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. Перезапустите службу timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Убедитесь, что сервер NTP доступен:

      sudo timedatectl timesync-status
      

   6. Убедитесь, что часы показывают правильное время:

      date
      

4. Убедитесь, что каждый узел nodepool отображает одно и то же время, выполнив команду из шага 3.f.

5. Если приложение не обновляет время автоматически, перезапустите модули pod.

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

• Обзор устранения неполадок
• Проблемы и ошибки установки
• Известные проблемы с хранилищем