Абсолютно правильное замечание и Вы так же полностью правы. Суть обработки сигнала SIGTERM приложением в том, чтобы оно не продолжало работать до принудительной остановки контейнера а завершилось самостоятельно с обработкой соединений. А хук в данном случае - это про ожидание обновления сетевых настроек на ноде.
Теперь про PreStop, Артемий в докладе говорит все правильно, сеть, в силу асинхронной природы куба, не перенастроится мгновенно, этот лаг стоит покрыть в простейшем случае слипом. При установке продолжительности слипа стоит помнить, что grace period в этот момент уже идет и при условном дефолте в 30 сек не стоит ставить слип на эти же 30 сек, т.к. куб завершит контейнер принудительно и gracefull shutdown таким способом мы точно не получим, 5-10 сек в абсолютном большинстве случаев достаточно. Вот в этой статье вопрос работы хука раскрыт более подробно и с примерами, рекомендую к прочтению.
Ну и да, это не косяк в кубере, а скорее "фича", как я писал выше (и как говорится в приведенном Вами докладе), состояние нод обновляется асинхронно и в обозримом будущем такое поведение никуда не исчезнет, а нам с этим как-то жить и обеспечивать доступность приложений)
Абсолютно правильное замечание и Вы так же полностью правы. Суть обработки сигнала SIGTERM приложением в том, чтобы оно не продолжало работать до принудительной остановки контейнера а завершилось самостоятельно с обработкой соединений. А хук в данном случае - это про ожидание обновления сетевых настроек на ноде.
Теперь про PreStop, Артемий в докладе говорит все правильно, сеть, в силу асинхронной природы куба, не перенастроится мгновенно, этот лаг стоит покрыть в простейшем случае слипом. При установке продолжительности слипа стоит помнить, что grace period в этот момент уже идет и при условном дефолте в 30 сек не стоит ставить слип на эти же 30 сек, т.к. куб завершит контейнер принудительно и gracefull shutdown таким способом мы точно не получим, 5-10 сек в абсолютном большинстве случаев достаточно. Вот в этой статье вопрос работы хука раскрыт более подробно и с примерами, рекомендую к прочтению.
Ну и да, это не косяк в кубере, а скорее "фича", как я писал выше (и как говорится в приведенном Вами докладе), состояние нод обновляется асинхронно и в обозримом будущем такое поведение никуда не исчезнет, а нам с этим как-то жить и обеспечивать доступность приложений)