Хуки и init-контейнеры в Kubernetes

Одна из задач DevOps-специалиста может заключаться в обеспечении деплоев в Kubernetes без простоя для разработчиков. Реализовать эту задачу бывает трудно, а все потому, что есть много вариантов завершения работы программных приложений и освобождения этими приложениями использованных ресурсов. Но особые трудности могут возникнуть с Nginx. На практике при последовательном развертывании этих подов активные соединения могут прерываться до успешного завершения. Почему так происходит?

Дело в том, что Kubernetes, прежде чем завершить работу пода, не ждет, пока Nginx-соединения исчерпают себя. Полностью избавиться от даунтайма можно посредством pre-stop хука и путем внедрения соответствующей функциональности:

Ниже — nginx-killer.sh:

Другая очень полезная парадигма заключается в использовании init-контейнеров для обработки запуска конкретных программных приложений. Это действительно полезно, особенно в тех случаях, когда у вас в распоряжении ресурсоемкий процесс миграции БД, который надо запускать до момента запуска приложения. Для данного процесса, кстати, можно указать более высокий ресурсный лимит, не устанавливая такой лимит для основного программного приложения.

Еще одна распространенная схема — доступ к секретам в init-контейнере, который предоставляет главному модулю соответствующие учетные данные. Что это дает? Например, предотвращение несанкционированного доступа к секретам из основного модуля приложения.

Напоследок приведем пару строк из официальной документации Kubernetes:

«Init-контейнеры осуществляют безопасный запуск пользовательского кода либо утилит, которые, в обратном случае, понизят безопасность образа контейнера программного приложения. Соответственно, если хранить ненужные инструменты отдельно, будет ограничена поверхность атаки образа контейнера».

Источник — https://medium.com/gumgum-tech/5-things-we-overlooked-when-putting-our-first-app-on-kubernetes-58583c1783e4.