Pod получил CrashLoopBackOff в Kubernetes из-за учетной записи службы GCP

После развертывания с использованием тележек руля у меня возникла ошибка CrashLoopBackOff. ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗРАСТ myproject-myproject-54ff57477d-h5fng 0/1 CrashLoopBackOff 10 24m

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

 Liveness probe failed: Get http://10.16.26.26:8080/status: 
 dial tcp 10.16.26.26:8080: connect: connection refused

Readiness probe failed: Get http://10.16.26.26:8080/status: 
dial tcp 10.16.26.26:8080: connect: connection refused

Наконец, я обнаружил недействительный доступ к моему облачному прокси GCP в журналах, как показано ниже time="2020-01-15T15:30:46Z" level=fatal msg=application_main error="Post https://www.googleapis.com/{....blabla.....}: oauth2: cannot fetch token: 400 Bad Request\nResponse: {\n \"error\": \"invalid_grant\",\n \"error_description\": \"Not a valid email or user ID.\"\n}"

Однако я проверил свой сервисный аккаунт в IAM, у него есть доступ к облачному прокси. Кроме того, я тестировал с использованием тех же учетных данных на моем локальном компьютере, и конечная точка для проверки готовности работала успешно.

Есть ли у кого-нибудь предложения по поводу моей проблемы?


kubernetes google-cloud-platform google-cloud-iam
person Denis    schedule 15.01.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вы можете отключить проверку живучести, чтобы остановить CrashLoopBackoff, выполнить запуск в контейнер и выполнить тестирование оттуда. В идеале вы не должны сохранять конфигурацию для проверки работоспособности и готовности. Не рекомендуется, чтобы проверка жизнеспособности зависела от чего-либо внешнего, она должна просто проверять, активен ли модуль или нет.

person ffran09    schedule 16.01.2020

arrow_upward
0
arrow_downward

Что касается проблемы с предоставлением доступа на GCP - исправьте это, используя адрес электронной почты (строка, которая заканчивается на [email protected]) вместо идентификатора клиента для значения параметра client_id. Названия, установленные Google, сбивают с толку.

Дополнительную информацию и способы устранения неполадок можно найти здесь: google-oautgh-grant.

Что касается проблемы с датчиками:

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

Датчики готовности и живучести могут использоваться параллельно для одного и того же контейнера. Использование обоих может гарантировать, что трафик не достигнет контейнера, который не готов к нему, и что контейнеры будут перезапущены при выходе из строя.

Зонд живучести проверяет, находится ли ваше приложение в работоспособном состоянии в уже запущенном модуле.

Зонд готовности фактически проверит, готов ли ваш под к приему трафика. Таким образом, если конечная точка / path отсутствует, она никогда не будет отображаться как «Выполняется».

яйцо:

          livenessProbe:
            httpGet:
              path: /your-path
              port: 5000
            failureThreshold: 1
            periodSeconds: 2
            initialDelaySeconds: 2
            ports:
              - name: http
              containerPort: 5000

Если конечная точка / index2 не существует, модуль никогда не будет отображаться как «Выполняется».

Убедитесь, что вы правильно настроили проверку живучести и готовности.

Для HTTP-зондирования кубелет отправляет HTTP-запрос на указанный путь и порт для выполнения проверки. Кубелет отправляет зонд на IP-адрес пода, если адрес не переопределен необязательным полем хоста в httpGet. Если в поле схемы установлено значение HTTPS, кубелет отправляет HTTPS-запрос, пропуская проверку сертификата. В большинстве сценариев вы не хотите устанавливать поле хоста. Вот один из сценариев, в котором вы бы это сделали. Предположим, что контейнер прослушивает 127.0.0.1, а поле hostNetwork пода имеет значение true. Затем host в httpGet должен быть установлен на 127.0.0.1.. Убедитесь, что вы это сделали. Если ваш модуль использует виртуальные хосты, что, вероятно, является более распространенным случаем, вам не следует использовать host, а лучше установить заголовок Host в httpHeaders.

Для TCP-зондирования кубелет устанавливает зондированное соединение на узле, а не в модуле, что означает, что вы не можете использовать имя службы в параметре хоста, поскольку кубелет не может его разрешить.

Самое главное, что вам нужно настроить при использовании зондов живучести. Это настройка initialDelaySeconds.

Убедитесь, что у вас открыт порт 80 на контейнере.

Отказ датчика живучести вызывает перезапуск модуля. Вы должны убедиться, что зонд не запускается, пока приложение не будет готово. В противном случае приложение будет постоянно перезапускаться и никогда не будет готово!

Я рекомендую использовать время запуска p99 для initialDelaySeconds.

Взгляните сюда: probes-kubernetes, наиболее распространенные -fails-kubernetes-deployments.

person Malgorzata    schedule 21.01.2020