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

Старые версии PowerShell не удаляются.

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

После обновления или увеличения масштаба целевого кластера модуль обновления сертификата теперь находится в состоянии цикла сбоя. Ожидается файл татуировки yaml сертификата из пути /etc/Kubernetes/pki. Файл конфигурации присутствует на виртуальных машинах узла уровня управления, но не на рабочих виртуальных машинах узла.

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

1. Скопируйте файл из виртуальной машины уровня управления в текущий каталог хост-компьютера.

   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. Скопируйте файл с хост-компьютера на виртуальную машину рабочего узла.

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

3. Задайте сведения о владельце и группе в этом файле в корневом каталоге, если он еще не установлен в корневой каталог.

   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. Повторите шаги 2 и 3 для каждого рабочего узла.

Если кластер не был обновлен более 60 дней, агент узла не может запуститься во время перезапуска агента узла из-за истечения срока действия маркера. Эта ошибка приводит к тому, что агенты будут находиться на начальном этапе. Непрерывные попытки присоединиться к cloudagent могут исчерпать поставки портов на узле. Состояние следующей команды — "Запуск".

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

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

Чтобы устранить проблему, остановите работу wssdagent. Так как служба находится на начальном этапе, она может предотвратить остановку службы. Если да, убьете процесс перед попыткой остановить службу.

1. Убедитесь, что wssdagent находится на начальном этапе.

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

2. Убить процесс.

   kill -Name wssdagent -Force
   

3. Остановить службу.

   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. Повторите шаги 1, 2 и 3 на каждом узле локального кластера Azure, который имеет эту проблему.

2. Убедившись, что wssdagent не запущен, запустите cloudagent, если он не запущен.

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

1. Убедитесь, что cloudagent работает и работает.

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

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

   Repair-Moc
   

3. После завершения этой команды wssdagent должен находиться в состоянии выполнения.

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

Если AKS в Azure Local не удается обновить с майского выпуска до июньского выпуска, ожидается, что AKS на локальном сайте Azure должен вернуться к выпуску в мае и продолжить работу. Но он оставляет агенты MOC в остановленном состоянии, и вручную пытается запустить агент не активировать их.

Шаги для воспроизведения

1. Установите модуль POWERShell AKS-HCI версии 1.1.36.
2. Обновите AKS в локальной среде Azure. Если обновление завершается сбоем, AKS в Azure Local возвращается в мае, но агенты MOC отключены.

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

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

Симптомы

Несоответствие между версией Aks-Hci и версией MOC

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

Несоответствие между Версией Get-MocVersion и wssdcloudagent.exe

Get-MocVersion указывает, что сборка июня установлена во время установки wssdcloudagent.exe версии, указывающей, что сборка Май установлена.

Путь к образу службы агента MOC имеет параметр идентификатора развертывания

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

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

Пример результата

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

Используйте следующую команду, чтобы показать путь изображения для агента узла: reg query "HKLM\System\CurrentControlSet\Services\wssdagent"

Пример результата

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

Чтобы устранить проблему, выполните следующие командлеты 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'

При обновлении вы можете потерять все пользовательские тоны, роли и метки, добавленные на рабочие узлы. Так как AKS — это управляемая служба, добавление пользовательских параметров, меток и ролей при выполнении за пределами предоставленных командлетов PowerShell или Windows Admin Center не поддерживается.

Чтобы обойти эту проблему, запустите командлет New-AksHciNodePool , чтобы правильно создать пул узлов с запятыми для рабочих узлов.

Если вы создали кластер управления, но не развернули кластер рабочей нагрузки в течение первых 60 дней, вы будете заблокированы для создания кластера, так как теперь она не используется. В этой ситуации при запуске Update-AksHci процесс обновления блокируется ошибкой Ожидания развертывания "Оператор выставления счетов AksHci" для готовности. Если вы запускаете Sync-AksHciBilling, он возвращает успешные выходные данные. Однако при запуске Get-AksHciBillingStatus состояние подключения — OutofPolicy.

Если вы не развернули кластер рабочей нагрузки в 60 дней, выставление счетов выходит из политики.

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

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

Шаги для воспроизведения

1. Перезагрузите один локальный узел Azure.
2. Дождитесь завершения перезагрузки узла. Узел должен быть помечен Up в отказоустойчивом кластере.
3. Перезагрузите другие узлы.
4. повторяйся"

Ожидаемое поведение Состояние кластера должно быть работоспособным. Все виртуальные машины должны быть подключены к ним сетевые адаптеры.

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

1. Получите имя виртуальной карты для виртуальной машины.

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

or

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

2. Подключите виртуальную карту к виртуальной машине.

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

or

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

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

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

or

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

Модули pod зависли в ожидании готовности статических модулей pod.

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

kubectl get nodes -o wide

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

kubectl describe node <IP of the node>

Используйте SSH для входа в узел NotReady, выполнив следующую команду:

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

Затем, чтобы перезапустить kubelet, выполните следующую команду:

/etc/.../kubelet restart

При запуске обновления в Windows Admin Center произошла следующая ошибка:

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.

Это сообщение об ошибке обычно возникает при развертывании AKS в локальной среде с настроенным прокси-сервером. В настоящее время Windows Admin Center не поддерживает установку модулей в прокси-среде.

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

При обновлении кластеров Kubernetes с помощью агента открытой политики (OPA), например OPA GateKeeper, процесс может зависать и не удается завершить. Эта проблема может возникнуть, так как агент политики настроен для предотвращения извлечения образов контейнеров из частных реестров.

Чтобы устранить эту проблему, при обновлении кластеров, развернутых с помощью OPA, убедитесь, что политики позволяют извлекать образы из Реестр контейнеров Azure. Для обновления AKS в локальном обновлении Azure необходимо добавить в список политик следующую конечную точку: ecpacr.azurecr.io.

Запуск обновления ОС на узле с akS в локальном развертывании Azure может привести к тому, что развертывание введет плохое состояние и завершится сбоем двух операций. Службы MOC NodeAgent могут не запускаться на обновленных узлах. Все вызовы MOC к узлам завершаются сбоем.

Для воспроизведения: при обновлении кластера с существующим развертыванием AKS из HCI в ОС HCIv2 операция AKS, например New-AksHciCluster может завершиться ошибкой. Сообщение об ошибке указывает, что узлы MOC являются OutOfCapacity. Например:

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]

Чтобы устранить эту проблему, запустите службу Moc NodeAgent wssdagent на затронутых узлах. Это позволит устранить проблему и вернуть развертывание в хорошее состояние. Выполните следующую команду:

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

После запуска Update-AksHciCluster процесс обновления останавливается.

Выполните следующую команду, чтобы проверить наличие компьютера с PHASE удалением, на котором выполняется предыдущая версия Kubernetes, из которой выполняется обновление.

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

Если есть компьютер с PHASE удалением и VERSION сопоставлением предыдущей версии Kubernetes, выполните следующие действия.

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

1. Версия Kubernetes, до которой выполняется обновление кластера рабочей нагрузки.
2. IP-адрес узла, зависающего.

Чтобы найти эти сведения, выполните следующий командлет и команду. По умолчанию командлет Get-AksHciCredential записывает kubeconfig в ~/.kube/config. Если при вызове Get-AksHciCredentialуказать другое расположение кластера рабочей нагрузки kubeconfig, необходимо указать это расположение в kubectl в качестве другого аргумента. Например, kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Должен отображаться STATUS Ready,SchedulingDisabledузел, который должен быть исправлен. Если узел отображается с таким состоянием, используйте INTERNAL-IP этот узел в качестве значения IP-адреса в следующей команде ниже. Используйте версию Kubernetes, обновляемую до значения версии; это значение должно совпадать со значением VERSION ROLES control-plane,masterузла. Не забудьте включить полное значение для версии Kubernetes, включая v, например v1.22.6.

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

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

Запуск обновления ОС на узле с AKS в локальном развертывании Azure может привести к тому, что развертывание введет плохое состояние, которое отрисовывает сервер API кластера управления недоступен и завершается сбоем двухдневных операций. Модуль kube-vip pod не может применить конфигурацию ВИРТУАЛЬНОГО IP-адреса к интерфейсу, и в результате виртуальный IP-адрес недоступен.

Чтобы воспроизвести: обновите кластер с существующим развертыванием ОС HCI AKS с HCI до HCIv2. Затем попробуйте выполнить команды, которые пытаются достичь кластера управления, Get-AksHciClusterнапример. Все операции, которые пытаются достичь кластера управления, завершались ошибкой, например:

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

Чтобы устранить эту проблему, перезапустите kube-vip контейнер, чтобы вернуть развертывание в хорошее состояние.

1. kube-vip Получите идентификатор контейнера:

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

Выходные данные должны выглядеть примерно так, при этом идентификатор контейнера является первым значением 4a49a5158a5f8. Например:

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

1. Перезапустите контейнер:

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

Это сообщение о состоянии отображается при запуске командлета Update-AksHci PowerShell.

Просмотрите следующие первопричины, чтобы устранить проблему:

• Причина одна: во время обновления оператора выставления счетов AksHci оператор неправильно помечает себя как неполную. Чтобы устранить эту проблему, откройте новое окно PowerShell и запустите Sync-AksHciBilling. Вы увидите, что операция выставления счетов продолжится в течение следующих 20–30 минут.

• Причина 2. Виртуальная машина кластера управления может быть не в памяти, что приводит к тому, что сервер API недоступен и делает все команды из Get-AksHciCluster, выставления счетов и обновления, истекает время ожидания. В качестве обходного решения задайте виртуальную машину кластера управления 32 ГБ в Hyper-V и перезагрузите ее.

• Причина 3. Оператор выставления счетов AksHci может быть вне места хранения, что связано с ошибкой в параметрах конфигурации Microsoft SQL. Отсутствие места в хранилище может привести к остановке реагирования на обновление. Чтобы обойти эту проблему, вручную измените размер модуля pod pvc выставления счетов, выполнив следующие действия.

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

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

  2. Когда блокнот или другой редактор открывается с файлом YAML, измените строку хранилища с 100Mi до 5Gi:

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

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

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

При обновлении кластеров из AKS в локальном обновлении Azure за февраль 2022 г. до обновления за апрель 2022 г. обновление может зависать в течение неопределенного периода времени. Могут быть модули pod, застрявшие в любом Terminating CrashLoopBackoff или состоянии.

Возможно, некоторые из ресурсов надстройки AksHci CSI отсутствуют. Эти модули pod ресурсов, развернутые с помощью csi-akshcicsi-controller управляющей программы или из этого csi-akshcicsi-node набора.

Надстройка CSI AksHci в обновлении за февраль 2022 г. содержит изменение спецификации драйвера CSI, которое иногда может оставить ресурсы надстройки в неответственном состоянии во время обновления. Драйвер .spec.fsGroupPolicy CSI был установлен на новое значение, даже если это неизменяемое поле. Так как поле неизменяемо, спецификация драйвера не обновляется. Следствием этого является то, что другие ресурсы надстройки AksHci CSI могут не полностью примириться. Все ресурсы CSI будут повторно созданы.

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

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

После успешного обновления панель мониторинга обновления Windows Admin Center по-прежнему отображает предыдущую версию.

Обновите браузер, чтобы устранить эту проблему.

Сборка AKS 1.0.1.10628 в Azure Local создает избыточное количество секретов конфигурации Kubernetes в кластере. Путь обновления от выпуска 1.0.1.10628 до выпуска 1.0.2.10723 был улучшен для очистки дополнительных секретов Kubernetes. Однако в некоторых случаях во время обновления секреты по-прежнему не были очищены, и поэтому процесс обновления завершается сбоем.

При возникновении этой проблемы выполните следующие действия.

1. Сохраните приведенный ниже скрипт в виде файла с именем 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. Затем выполните следующую команду, используя сохраненный файл fix_secret_leak.ps1 :

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

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

      Update-AksHci
   

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

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

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