Устранение неполадок, связанных с управлением Kubernetes и кластером рабочей нагрузки в AKS Arc

При выполнении команды Remove-ClusterNode узел удаляется из отказоустойчивого кластера, но если командлет Remove-AksHciNode не запускается после этого, узел по-прежнему будет существовать в CloudAgent.

Так как узел был удален из кластера, но не из CloudAgent, при использовании виртуального жесткого диска для создания нового узла появится ошибка "Файл не найден". Эта проблема возникает из-за того, что виртуальный жесткий диск находится в общем хранилище, а удаленный узел не имеет к нему доступа.

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

1. Выполните команду Remove-AksHciNode для отмены регистрации узла из CloudAgent.
2. Выполняйте плановое обслуживание, например повторное изображение компьютера.
3. Добавьте узел обратно в кластер.
4. Выполните команду Add-AksHciNode , чтобы зарегистрировать узел в CloudAgent.

В больших кластерах Get-AksHciLogs команда может вызвать исключение, не выполнить перечисление узлов или создать c:\wssd\wssdlogs.zip выходной файл.

Это связано с тем, что команда PowerShell для zip-файла "Compress-Archive" имеет ограничение на размер выходного файла в 2 ГБ.

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

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

Чтобы устранить эту проблему, вручную скопируйте ФАЙЛ YAML татуировки сертификата из узла уровня управления на все рабочие узлы.

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

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` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

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

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

3. Если сведения о владельце и группе в YAML-файле еще не заданы как root, задайте для данных значение root:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Повторите шаги 2 и 3 для всех рабочих узлов.

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

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

При выполнении командлета Get-AksHciCluster для проверки состояния установки AKS Arc в Windows Admin Center выводится сообщение об ошибке: "Выпуск версии 1.0.3.10818 не найден". Однако при запуске Get-AksHciVersion было показано, что установлена та же версия. Эта ошибка означает, что срок действия сборки истек.

Чтобы устранить эту проблему, запустите Uninstall-AksHci, а затем запустите новую сборку AKS Arc.

При использовании средства администрирования кластера для перемещения виртуальной машины с одного узла (узла A) на другой (узел B) в кластере Azure Stack HCI виртуальная машина может не запуститься на новом узле. После перемещения виртуальной машины обратно на исходный узел она также не запустится на нем.

Эта проблема возникает из-за того, что логика очистки первой миграции выполняется асинхронно. В результате логика обновления виртуальной машины Служба Azure Kubernetes находит виртуальную машину на исходном узле Hyper-V на узле A и удаляет ее вместо отмены регистрации.

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

При использовании PowerShell для создания кластера со статическими IP-адресами и последующей попытки увеличить количество рабочих узлов в кластере рабочей нагрузки установка зависает на уровне управления на 2, по-прежнему ожидая желаемого состояния: 3. Через некоторое время появляется другое сообщение об ошибке: "Ошибка: истекло ожидание условия".

При запуске Командлета Get-AksHciCluster показал, что узлы уровня управления были созданы и подготовлены и находились в состоянии Готовности . Однако при kubectl get nodes запуске было показано, что узлы уровня управления были созданы, но не подготовлены и не находились в состоянии Готовности .

Если возникает эта ошибка, убедитесь, что IP-адреса назначены созданным узлам с помощью диспетчера Hyper-V или PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Затем проверьте параметры сети, чтобы убедиться, что в пуле осталось достаточно IP-адресов для создания дополнительных виртуальных машин.

Такие команды, как Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesи все взаимодействия с кластером управления, могут возвращать сообщение "Ошибка: необходимо войти на сервер (не авторизовано)".

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

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

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

Чтобы устранить эту проблему, скопируйте файл admin.conf , который находится на виртуальной машине уровня управления, на узел HCI:

• Подключение по протоколу SSH к виртуальной машине уровня управления:

  • Получите IP-адрес виртуальной машины уровня управления:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • В него входит SSH:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Скопируйте файл в расположение clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Предоставьте доступ к clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Необязательно] Создайте резервную копию файла kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Скопируйте файл:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

При проверка диспетчера Hyper-V высокие требования к ЦП и памяти для кластера управления можно игнорировать. Они связаны с пиками использования вычислительных ресурсов при подготовке кластеров рабочей нагрузки.

Увеличение размера памяти или ЦП для кластера управления не привело к значительному улучшению и может быть безопасно проигнорировано.

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

1. Создание кластера Kubernetes.
2. Масштабируйте кластер до более чем двух узлов.
3. Удалите узел, выполнив следующую команду:

kubectl delete node <node-name>

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

kubectl get nodes

Удаленный узел не указан в выходных данных. 5. Откройте окно PowerShell с правами администратора и выполните следующую команду:

get-vm

Удаленный узел по-прежнему отображается в списке.

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

Если вы не используете кластер управления или рабочей нагрузки дольше 60 дней, срок действия сертификатов истекает, и перед обновлением AKS Arc их необходимо обновить. Если кластер AKS не обновляется в течение 60 дней, срок действия токена подключаемого модуля KMS и сертификатов истекает в течение 60 дней. Кластер по-прежнему работает. Однако, так как срок обновления превышает 60 дней, для обновления необходимо обратиться в службу поддержки Майкрософт. Если кластер перезагрузится по истечении этого периода, он останется в неработоспособном состоянии.

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

1. Восстановите сертификат кластера управления , вручную сменив маркер, а затем перезапустите подключаемый модуль и контейнер KMS.
2. Восстановите сертификаты, mocctl выполнив команду Repair-MocLogin.
3. Восстановите сертификаты кластера рабочей нагрузки , вручную сменив маркер, а затем перезапустите подключаемый модуль и контейнер KMS.

Кластер рабочей нагрузки не найден, если пулы IP-адресов двух развертываний AKS в Azure Stack HCI совпадают или перекрываются. Если развернуть два узла 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.

Время ожидания развертывания большого кластера может истекло через два часа. Однако это статическое время ожидания.

Это время ожидания можно игнорировать, так как операция выполняется в фоновом режиме. Используйте команду , kubectl get nodes чтобы получить доступ к кластеру и отслеживать ход выполнения.

При попытке открыть развертывание AKS в Azure Stack HCI через несколько дней Kubectl не выполнял ни одной из своих команд. В журнале подключаемого модуля службы управления ключами (KMS) отображается сообщение rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificatesоб ошибке .

Если сервер API не работает, командлет Repair-AksHciClusterCerts завершается ошибкой. Если AKS в Azure Stack HCI не обновлялся в течение 60 или более дней, при попытке перезапустить подключаемый модуль KMS он не запустится. Этот сбой также приводит к сбою сервера API.

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

1. Смените маркер, выполнив следующую команду:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Скопируйте маркер на виртуальную машину с помощью следующей команды. Параметр ip в приведенной ниже команде относится к IP-адресу уровня управления узла AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

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

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

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Выходные данные должны отображаться со следующими полями:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Выходные данные должны выглядеть примерно так:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Наконец, перезапустите контейнер, выполнив следующую команду:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

При установке AKS в Azure Stack HCI с расширением Windows Admin Center версии 1.82.0 кластер управления был настроен с помощью PowerShell и предпринята попытка развернуть кластер рабочей нагрузки с помощью Windows Admin Center. На одном из компьютеров был установлен модуль PowerShell версии 1.0.2, а на других — модуль PowerShell 1.1.3. Попытка развернуть кластер рабочей нагрузки завершилась ошибкой "Не удается найти параметр, соответствующий имени параметра nodePoolName". Эта ошибка могла возникнуть из-за несоответствия версий. Начиная с PowerShell версии 1.1.0, -nodePoolName <String> параметр был добавлен в командлет New-AksHciCluster, и по умолчанию этот параметр теперь является обязательным при использовании расширения Windows Admin Center версии 1.82.0.

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

• Используйте PowerShell, чтобы вручную обновить кластер рабочей нагрузки до версии 1.1.0 или более поздней.
• Используйте Windows Admin Center, чтобы обновить кластер до версии 1.1.0 или до последней версии PowerShell.

Эта проблема не возникает, если кластер управления развертывается с помощью Windows Admin Center так как на нем уже установлены последние модули PowerShell.

При развертывании AKS в Azure Stack HCI, а затем запуске kubectl get podsмодули pod в том же узле зависают в состоянии Завершения . Компьютер отклоняет SSH-подключения, так как на узле, скорее всего, возникает высокая потребность в памяти. Эта проблема возникает из-за чрезмерной подготовки узлов Windows и отсутствия резерва для основных компонентов.

Чтобы избежать этой ситуации, добавьте ограничения ресурсов и запросы ресурсов для ЦП и памяти в спецификацию pod, чтобы убедиться, что узлы не будут подготовлены чрезмерно. Узлы Windows не поддерживают вытеснение на основе ограничений ресурсов, поэтому следует оценить, сколько будут использовать контейнеры, а затем убедиться, что на узлах достаточно ресурсов ЦП и памяти. Дополнительные сведения см. в статье Требования к системе.

Автоматическое масштабирование кластера может завершиться ошибкой при использовании следующей политики Azure в кластере управления узлами AKS: "Кластеры Kubernetes не должны использовать пространство имен по умолчанию". Это происходит потому, что политика при реализации в кластере управления узлами AKS блокирует создание профилей автомасштабирования в пространстве имен по умолчанию. Чтобы устранить эту проблему, выберите один из следующих вариантов:

• Удалите расширение Политика Azure в кластере управления узлами AKS. Дополнительные сведения об удалении расширений Политика Azure см. здесь.
• Измените область политики Azure, чтобы исключить кластеры управления узлами AKS. Дополнительные сведения об областях Политика Azure см. здесь.
• Установите для кластера управления узлами AKS режим принудительного применения политики в значение "Отключено". Дополнительные сведения о режиме принудительного применения см. здесь.

Это известная проблема с обновлением AKS в Azure Stack HCI за июль (версия 1.0.2.10723). Ошибка возникает из-за того, что время ожидания службы CloudAgent истекает во время распределения виртуальных машин по нескольким общим томам кластера в системе.

Чтобы устранить эту проблему, необходимо выполнить обновление до последнего выпуска AKS в Azure Stack HCI.

При подготовке кластера AKS в Azure Stack HCI с нулевыми узлами Linux или Windows при запуске Get-AksHciCluster выходные данные будут иметь пустую строку или значение NULL.

Null — это ожидаемое значение возвращаемого значения для нулевых узлов.

При завершении работы кластера управления или рабочей нагрузки более четырех дней срок действия сертификатов истекает, и кластер становится недоступным. Срок действия сертификатов истекает, так как они сменяются каждые 3–4 дня по соображениям безопасности.

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

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

При масштабировании кластера рабочей нагрузки соответствующие виртуальные машины Linux и Windows были добавлены в качестве рабочих узлов, но не были настроены как высокодоступные виртуальные машины. При выполнении команды Get-ClusterGroup только что созданная виртуальная машина Linux не была настроена в качестве группы кластеров.

Это известная проблема. После перезагрузки возможность настройки виртуальных машин как высокодоступных иногда теряется. В настоящее время обходным решением является перезапуск wssdagent на каждом из узлов Azure Stack HCI. Это работает только для новых виртуальных машин, созданных путем создания пулов узлов при выполнении операции горизонтального увеличения масштаба или при создании новых кластеров Kubernetes после перезапуска wssdagent на узлах. Однако вам придется вручную добавить существующие виртуальные машины в отказоустойчивый кластер.

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

Кластер AKS, развернутый на виртуальной машине Azure, ранее работал нормально, но после отключения узла AKS в течение нескольких дней Kubectl команда не работала. После выполнения Kubectl get nodes команды или Kubectl get services появилось следующее сообщение об ошибке: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Эта проблема возникла из-за того, что узел AKS был отключен дольше четырех дней, что привело к истечению срока действия сертификатов. Сертификаты часто сменяются в течение четырехдневного цикла. Запустите Repair-AksHciClusterCerts , чтобы устранить проблему с истечением срока действия сертификата.

В кластере рабочей нагрузки со статическими IP-адресами и узлами Windows все модули pod в узле (включая daemonset модули pod) зависают в состоянии ContainerCreating . При попытке подключиться к узлу по протоколу SSH подключение завершается ошибкой Connection timed out .

Чтобы устранить эту проблему, отключите виртуальную машину этого узла с помощью диспетчера Hyper-V или диспетчера отказоустойчивости кластеров. Через 5–10 минут узел должен быть повторно создан, и все модули pod будут запущены.

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

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

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

sudo su

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

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Дальнейшие действия

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