Python работает в Docker, но не в Kubernetes, размещенном в кластере Raspberry Pi под управлением Ubuntu 20 - PullRequest
0 голосов
/ 02 августа 2020

Вот такая ситуация.

Попытка запустить Python Flask API в Kubernetes, размещенном в кластере Raspberry Pi, узлы работают под управлением Ubuntu 20. API помещен в контейнер Docker на узел управления Raspberry Pi для учета различий в архитектуре (ARM).

Когда API и Mon go запускаются за пределами K8s на Raspberry Pi, просто используя команду Docker run, API работает правильно; однако, когда API применяется в качестве развертывания в Kubernetes, модуль API для API завершается с ошибкой CrashLoopBackoff, а в журналах отображается 'standard_init_ linux. go: 211: exe c пользовательский процесс вызвал ошибку формата exe c "'

Исследования показывают, что ошибка формата exe c может быть связана с проблемами, связанными со сборкой для различных архитектур ЦП. Однако, создав образ Docker на Raspberry Pi и успешно запустив API на архитектуре, я не уверен, что это могло быть источником проблемы.

Прошло два дня, и все попытки были не смогли. Кто-нибудь может помочь?

1 Ответ

1 голос
/ 02 августа 2020

Исправлено; однако что-то кажется неправильным.

Развертывание Kubernetes всегда развертывалось на одном узле. Я подключился к этому узлу и запустил контейнер Docker, но он не запустился; возникнет «ошибка формата exe c». Итак, похоже, это была проблема c узла.

Я скопировал API и Dockerfile на узел и запустил Docker build для создания образа. Теперь он работает. Это не имеет смысла, поскольку в образе Docker должно быть все необходимое для запуска.

Возможно, это потому, что предыдущая сборка образа для x86 (машина разработки) осталась в этих узлах Docker кеш / репозиторий. Возможно, изображение на узле не перезаписано новыми изображениями с тем же именем и номером версии (номер версии не увеличивался). Казалось бы, это так, поскольку время раскрутки изображения на удаленном узле очень быстрое, что говорит о том, что новое изображение не копируется на удаленный узел. Скорее всего, так оно и есть.

Я все равно отправлю это, так как это может быть полезно.

Редактировать: позвольте мне уточнить еще кое-что, root этой проблемы в конечном итоге вызвано отсутствием общего хранилища изображений в кластере. Образы вручную копировались на каждый RPI (под управлением ARM64) с портативного компьютера (без ARM64), и этот ручной процесс вызывал проблему.

Создание образа на портативном компьютере основано на базовом образе, несовместимом с ARM64; это было вручную скопировано во все RPI в кластере. Это вызвало ошибку формата Exe c.

При построении образа на RPI был получен базовый образ, поддерживающий ARM64; однако эту сборку нужно было выполнить для всех RPI, потому что в кластере не было центрального репозитория, из которого Kubernetes мог бы перетаскивать недавно созданные ARM64-совместимые образы на другие узлы RPI в кластере.

Решение: общий репозиторий

Надеюсь, это поможет.

...