Как установить MaxRevisionTimeoutSeconds в Knative?

Я развернул службу, использующую Cloud run на gke, которая использует Knative в качестве абстракции по сравнению с k8s. По умолчанию MaxRevisionTimeoutSeconds установлено на 600 сек в конфигурации по умолчанию Knative , но согласно этому PR, это можно настроить.

Я ничего не нашел в официальной документации Knative, может ли кто-нибудь мне помочь?

ОБНОВЛЕНИЕ:

Покопавшись еще немного в исходном коде и документации. Похоже, что MaxRevisionTimeoutSeconds определен в resource=ConfigMap/config-defaults. Поэтому нужно обновить его с помощью специального значения.

Из это похоже, мы можем использовать что-то под названием operator для изменения ресурса ConfigMap, но это не сработало, вероятно, потому что gcp не использует оператор для установки компонентов Knative. В любом случае я продолжил установку оператора, а затем использовал resource=knativeserving, чтобы перезаписать настройки по умолчанию. Но это также не сработало, когда я попытался повторно развернуть службу.

Следующее решение - напрямую отредактировать значения config-defaults с помощью kubectl edit. Я даже пытался это сделать, но столкнулся со странным поведением. После редактирования файла YAML, когда я использовал kubectl describe для проверки измененного значения, он иногда показывает измененное значение, иногда показывает старое значение, а иногда даже не показывает эту конкретную пару «ключ-значение» в YAML. Кроме того, он не работает при повторном развертывании службы после внесения этого изменения.

Если бы кто-нибудь мог мне с этим помочь, было бы здорово.


person Srijan Singh    schedule 14.06.2020    source источник


Ответы (1)


MaxRevisionTimeoutSeconds - это глобальный параметр кластера, который устанавливает максимальное значение для TimeoutSeconds для каждой версии. Это значение существует для того, чтобы администраторы кластера могли установить верхнюю границу времени, в течение которого один HTTP-запрос может находиться в системе. Знание верхней границы может быть полезно при настройке параметров постепенного завершения работы компонентов маршрутизации HTTP, чтобы предотвратить потерю запросов во время обновлений.

Возможно, Cloud Run на GKE переопределил эти конфигурации, чтобы они могли обновлять базовые компоненты Istio и Knative по предсказуемому расписанию. (Если у вас 10% бюджета на обновление и требуется 10 м для слива компонента, ваше минимальное время обновления, вероятно, составляет около 110 м с учетом дополнительного времени планирования / загрузки изображений / запуска.)

person E. Anderson    schedule 14.06.2020
comment
Да, они заменили это конкретное значение на 900 в configmap / config-defaults. Есть ли способ увеличить этот лимит, скажем, до 1500? - person Srijan Singh; 14.06.2020
comment
@ AhmetB-Google Я пробовал это, как упоминалось в обновлении. Но это не работает. Мне нужно специальное разрешение? В настоящее время я являюсь администратором и редактором Cloud Run. - person Srijan Singh; 15.06.2020
comment
Даже после получения роли администратора GKE изменения настроек по умолчанию не работают. Каждый раз, когда я редактирую файл yaml, он возвращается к значениям по умолчанию, установленным gcp. Я понятия не имею, почему он не позволяет gke / run admin изменять его. - person Srijan Singh; 16.06.2020
comment
Спасибо за сообщение, я буду следить за этим на нашей стороне. - person Ahmet Alp Balkan; 17.06.2020
comment
Я не смогу публиковать здесь обновления. Если вы хотите быть в курсе, подумайте о том, чтобы открыть проблему в Google Cloud Issue Trackers. - person Ahmet Alp Balkan; 25.06.2020