Используйте эту статью, чтобы устранить неполадки, связанные с хранилищем, в AKS Arc.
Настройка утверждений сохраняемого тома приводит к ошибке : "Не удается инициализировать агент. Ошибка: mkdir /var/log/agent: разрешение запрещено"
Эта ошибка с отклоненным разрешением указывает, что класс хранилища по умолчанию может не подходить для рабочих нагрузок Linux, работающих поверх Kubernetes версии 1.19.x или более поздней. Следуя рекомендациям по обеспечению безопасности, многие рабочие нагрузки Linux указывают securityContext fsGroup
параметр для модуля pod. Рабочие нагрузки не запускаются в AKS в Azure Local, так как класс хранилища по умолчанию не указывает fstype (=ext4)
параметр, поэтому Kubernetes не может изменить владение файлами и постоянными томами на fsGroup
основе запрошенной рабочей нагрузки.
Чтобы устранить эту проблему, определите пользовательский класс хранилища, который можно использовать для подготовки PVC.
Модуль pod интерфейса хранилища контейнеров завис в состоянии ContainerCreating
Создан новый кластер рабочей нагрузки Kubernetes с Kubernetes версии 1.16.10, а затем обновлен до версии 1.16.15. После обновления csi-msk8scsi-node-9x47m
модуль pod застрял в состоянии ContainerCreating, и kube-proxy-qqnkr
модуль pod застрял в состоянии завершения, как показано в выходных данных ниже:
Error: kubectl.exe get nodes
NAME STATUS ROLES AGE VERSION
moc-lf22jcmu045 Ready <none> 5h40m v1.16.15
moc-lqjzhhsuo42 Ready <none> 5h38m v1.16.15
moc-lwan4ro72he NotReady master 5h44m v1.16.15
\kubectl.exe get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
5h38m
kube-system csi-msk8scsi-node-9x47m 0/3 ContainerCreating 0 5h44m
kube-system kube-proxy-qqnkr 1/1 Terminating 0 5h44m
Так как kubelet
в итоге в плохом состоянии и больше не может взаимодействовать с сервером API, единственным решением является перезапуск kubelet
службы. После перезапуска кластер переходит в состояние выполнения .
Хранилище дисков, заполненное из журналов аварийного дампа
Хранилище дисков можно заполнить из созданных журналов аварийного дампа. Это связано с истекшим сроком действия сертификата для клиента агента Geneva. Симптомы могут выглядеть так.
- Не удается запустить службы.
- Модули pod Kubernetes, развертывания и т. д. не удается запустить из-за нехватки ресурсов.
Внимание
Эта проблема может повлиять на все новые узлы управления и целевых кластеров, созданные после 18 апреля 2023 г. с 2022 по март 2023 г. Проблема устранена в выпуске 2023-05-09 и более поздних версий.
Эта проблема может повлиять на любую операцию, которая включает выделение места на диске или запись новых файлов, поэтому любая ошибка "недостаточно места на диске или ресурсов" является хорошим указанием. Чтобы проверить, присутствует ли эта проблема на определенном узле, выполните следующую команду оболочки:
clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/
Эта команда сообщает о дисковом пространстве, потребляемом файлами диагностики.
Основная причина
Срок действия сертификата клиента, используемого для проверки подлинности агента Женевы в конечной точке службы, приводит к сбою агента, что приводит к сбою аварийного дампа. Цикл аварийного завершения и повтора агента составляет около 5 секунд при первоначальном запуске, и время ожидания отсутствует. Это означает, что новый файл (около 330 МБ) создается в файловой системе узла каждые несколько секунд, что может быстро использовать хранилище дисков.
Исправление
Рекомендуется обновить до последней версии версии 1.10.18.10425, которая имеет обновленный сертификат. Для этого сначала вручную обновите кластеры рабочей нагрузки до любой поддерживаемой дополнительной версии перед обновлением локального узла Azure.
Дополнительные сведения о выпусках AKS Arc и всех последних новостей AKS в Azure Local, подпишитесь на страницу выпусков AKS.
Если обновление не является параметром, вы можете отключить службу mdsd . Для каждого узла Mariner:
Отключите агент Geneva со следующими командами оболочки:
sudo systemctl disable --now mdsd
Убедитесь, что агент Женевы успешно отключен:
sudo systemctl status mdsd
Удалите накопленные файлы с помощью следующей команды:
sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \; sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
Перезагрузите узел:
sudo reboot
Сбои pod хранилища и журналы говорят, что параметр createSubDir недопустим.
Ошибка может возникнуть, если в развертывании установлен драйвер SMB или NFS CSI, и вы обновляетесь до сборки из более старой версии. Один из параметров, вызываемый createSubDir
, больше не принимается. Если это относится к развертыванию, следуйте приведенным ниже инструкциям, чтобы устранить сбой класса хранилища.
При возникновении этой ошибки модуль хранилища завершает работу, а журналы указывают, что createSubDir
параметр недопустим.
Повторно создайте класс хранилища.
При создании постоянного тома попытка подключения тома завершается сбоем.
После удаления постоянного тома или утверждения постоянного тома в среде AKS Arc создается новый постоянный том для сопоставления с той же общей папкой. Однако при попытке подключения тома сбой подключения и время ожидания pod с ошибкой NewSmbGlobalMapping failed
.
Чтобы обойти сбой подключения нового тома, можно выполнить SSH в узле Windows и запустить Remove-SMBGlobalMapping
и предоставить общую папку, соответствующую тому. После выполнения этой команды попытка подключения тома должна завершиться успешно.