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

Question

После развертывания с использованием рулевых тележек я получил ошибку 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, у нее есть доступ к облачному прокси-серверу. Кроме того, я проверил с использованием тех же учетных данных в моем локальном компьютере, и конечная точка для проверки готовности работала успешно.

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

Answer 1

Касательно проблемы с предоставлением доступа на GCP - исправьте это, используя адрес электронной почты (строка, заканчивающаяся ...@developer.gserviceaccount.com) вместо идентификатора клиента для значения параметра client_id. Заданное Google название дает путаницу.

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

Касательно проблемы с пробниками:

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

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

Проверка жизнеспособности проверяет, находится ли ваше приложение в исправном состоянии в уже работающий модуль.

Датчик готовности фактически проверит, готов ли ваш модуль к получению трафика c. Таким образом, если конечная точка / path отсутствует, она никогда не будет отображаться как Running

egg:

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

Если конечная точка / index2 не будет существовать, pod никогда не появится as Running.

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

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

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

Наиболее важная вещь, которую необходимо настроить при использовании проб живучести , Это настройка initialDelaySeconds.

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

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

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

Взгляните сюда: probes-kubernetes , самый распространенный, не может-kubernetes-развертываний .

Answer 2

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