Мы используем экземпляры облака Google с опцией контейнера, каждую минуту мы видим ошибку ниже в журналах драйверов стека. мы не уверены, для чего эта ошибка.
api_server.cc:184 Неудачный запрос метаданных: сервер ответил ошибочным запросом (400): конечная точка транспорта не подключена
Я думаю, что это выпущенный API службы метаданных облачного экземпляра, где будут доступны сведения об экземпляре. Также в одном из наших случаев использования мы использовали инструмент командной строки gcloud, например (внутри контейнера докеров), инструменту gcloud не требуется доступ к облачным API в течение первых 2-5 минут даже после запуска контейнера докеров. в те 2-5 минут он показывает, что сервисный аккаунт недоступен.
Я хотел бы узнать об этой ошибке, поскольку не могу найти никаких релевантных сведений в поиске Google.
Мы тоже наблюдали подобное поведение. Я отправил в Google следующее электронное письмо:
Привет,
Я заметил некорректное поведение при использовании
gcloud beta compute instances create-with-containerи задавался вопросом, не видели ли вы что-то подобное раньше:У меня есть образ докера (файл Dockerfile ниже), который я создаю и помещаю в реестр контейнеров. В точке входа в контейнер докера я выполняю сценарий, который использует команду gcloud kms для расшифровки зашифрованного текста и gcloud.compute.instances.delete для удаления экземпляра. Если я попытаюсь запустить изображение, используя
gcloud beta compute instances create-with-containerсразу после проталкивания нового изображения. Команда gcloud выдаст сообщение об ошибке, например:"\ u001b [1; 31mERROR: \ u001b [0m (gcloud.kms.decrypt) Требуемое свойство [проект] в настоящее время не установлено. \ r»
"Вы можете установить его для своего текущего рабочего пространства, запустив: \ r"
"\р"
"$ gcloud config установить проект VALUE \ r"
"\р"
"или его можно временно установить с помощью переменной среды [CLOUDSDK_CORE_PROJECT] \ r"
Или
"\ u001b [1; 31mERROR: \ u001b [0m (gcloud.compute.instances.delete) В настоящее время у вас не выбрана активная учетная запись. \ r"
"Пожалуйста, запустите: \ r"
"\р"
"$ gcloud авторизация входа \ r"
"\р"
"для получения новых учетных данных, или если вы уже вошли в систему с помощью \ r"
"другой аккаунт: \ r"
"\р"
"$ gcloud config установить учетную запись ACCOUNT \ r"
"\р"
"для выбора уже аутентифицированной учетной записи для использования. \ r"
Если я подожду ок. 3-4 минуты и запустите тот же образ с той же командой, затем скрипт успешно запустится, как ожидалось. Мне кажется, что есть некоторая задержка с настройкой аутентификации для gcloud - это так? И есть ли у вас рекомендуемый способ смягчить такое поведение?
И получил следующий ответ:
Спасибо за обращение и подробный отчет. Мы обязательно рассмотрим это дальше с нашей стороны, поскольку вполне вероятно, что есть некоторая несогласованность между настройкой учетных записей и запуском контейнера. К сожалению, у меня пока нет хорошего обходного пути, кроме добавления простой команды "сна" перед первым вызовом gcloud из вновь созданного контейнера в виртуальной машине. Я свяжусь с вами, когда узнаю больше или у меня будет решение этой проблемы.