Kubernetes 1.18 на EKS StartupProbe со старым ServiceAccountName

#kubernetes #amazon-eks

#kubernetes #amazon-eks

Вопрос:

У меня есть развертывание, которое отлично работало на K8S 1.17 на EKS. После обновления K8S до 1.18 я попытался использовать startupProbe функцию с простым развертыванием. Все работает, как ожидалось. Но когда я попытался добавить startupProbe в свое производственное развертывание, это не сработало. Кластер просто удаляет startupProbe запись при создании модулей ( startupProbe хотя запись существует в определении объекта развертывания в кластере). Интересно, что когда я меняю serviceAccountName запись на default (вместо моей учетной записи службы приложений) в манифесте развертывания, все работает так, как ожидалось. Итак, теперь вопрос в том, почему у существующих учетных записей служб не может быть проб запуска? Спасибо.

Комментарии:

1. Используете ли вы аннотацию eks.amazonaws.com/role-arn для ServiceAccount? Если да, то есть открытая проблема github по этому поводу.

Ответ №1:

Публикую это как ответ участника сообщества. Не стесняйтесь расширяться.

Проблема

startupProbe не применяется к Pod, если задано serviceAccountName

При добавлении serviceAccountName и startupprob в шаблон модуля в моем развертывании результирующие модули не будут иметь пробника запуска.

По этому поводу есть проблема с github.

Решение

Эта проблема решается здесь, в настоящее время она все еще открыта, и на этот вопрос нет конкретного ответа.

Как упоминалось @mcristina422

Я думаю, это связано со старой версией k8s.io/api используется в webhook. API для проверки запуска был добавлен совсем недавно. Обновление пакетов k8s должно исправить это