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