Устранение неполадок с кластером управления 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-файла с расширением "Сжатие-архив" имеет ограничение размера выходного файла в 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-файле еще не заданы для корневого каталога, задайте для нее сведения:

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.

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

Эта проблема возникает, так как логика очистки первой миграции выполняется асинхронно. В результате логика обновления виртуальной машины Служба 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-AksHciCertificatesUpdate-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 , который находится в виртуальной машине уровня управления, в локальный узел Azure:

• 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 совпадают или перекрываются. Если развернуть два узла AKS и использовать ту же конфигурацию для обоих, PowerShell и Windows Admin Center потенциально не смогут найти кластер рабочей нагрузки, так как сервер API будет назначен один и тот же AksHciNetworkSetting 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 через несколько дней не 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об ошибке.

Командлет Repair-AksHciClusterCerts завершается ошибкой, если сервер API отключен. Если AKS в локальной среде Azure не обновлено в течение 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 с расширением 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, так как он уже имеет последние установленные модули PowerShell.

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

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

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

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

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

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

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

Значение NULL является ожидаемым возвратом для нулевых узлов.

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

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

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

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

Это известная проблема. После перезагрузки возможность настройки виртуальных машин как высокодоступная иногда теряется. Текущее решение — перезапустить wssdagent на каждом из локальных узлов Azure. Это работает только для новых виртуальных машин, созданных путем создания пулов узлов при выполнении горизонтальной операции или при создании кластеров 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>

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

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