Kubernetes остается самым популярным решением для управления контейнерами. Меняются фреймворки и языки программирования, сменяются эпохи, а «кубер» остается как будто единственным выбором. Дальше все как всегда: эксперты пишут статьи, техноблогеры разрабатывают гайды по настройке, девопсы на форумах расстраиваются, что что-то не работает так, как хотелось бы. И хотя нам довелось настроить не один десяток кластеров, писать очередную пошаговую инструкцию сегодня не будем. Сегодня, в пятницу, держите 5 вредных советов, как заложить под свой кубернетес-кластер мину замедленного действия.

Спойлер: так лучше не делать.

Совет № 1 Используйте все самое новое

Всегда используйте самую свежую версию Kubernetes. Как только в новостях промелькнет информация о новой версии, сразу качайте ее и тут же обновляйтесь! Нам не по пути с ретрогадами, читающими release notes и интересующимися, как там ситуация с совместимостью. Кроме этого, обязательно убедитесь, что в ваши поды попадают контейнеры, собранные из самых-самых свежих образов. Убедиться в этом просто, попросите вашего девопса показать манифесты для текущей конфигурации кластера. Вы увидите нечто такое:

apiVersion: apps/v1

kind: Deployment

metadata:

name: my-deployment

spec:

template:

metadata:

labels:

app: my-super-app

spec:

containers:

- name: super-app

image: docker.io/acme/super-app:latest

Заметили слово «latest»? Все в порядке. Конечно, это не очень информативно, потому что вы не знаете, был сделан образ вчера или год назад, но мы тут не для того, чтобы задавать подобные вопросы. Если кластер после обновления просто перестает работать, то, скорее всего, это девопсы что-то в очередной раз напортачили, 100%.

Совет № 2 Включайте все настройки и конфигурации прямо в контейнер

Ну это, я думаю, совсем очевидно. Контейнеры, которые попадают в ваш кластер, не должны быть универсальными. Вместо этого они должны:

• иметь заранее прописанный IP-адрес;

• содержать все необходимые логины, пароли, ключи и секреты;

• иметь жесткие ссылки на соседние сервисы, с которыми предстоит взаимодействовать.

Вообще, давайте сразу дадим указание разработчикам писать приложения с учетом кубернетес. На всякий случай. Наверное, если однажды кластер придется перестроить или мигрировать на другую площадку, то все перестанет работать. Но, с другой стороны, кубернетес он и в Африке кубернетес, не будем думать о грустном и разберемся с проблемами по мере поступления. Если что, перепишем наше приложение с нуля, какие проблемы. Зато прямо сейчас вы решите все свои вопросы, потому что контейнеры заточены именно под вашу ситуацию, а это не может не радовать.

Совет №3 Управляйте своим кластером только с помощью kubectl

Пока ваши коллеги разрабатывают и согласовывают процедуры внесения изменений в конфигурации своих кластеров, мы решим эту проблему раз и на всегда. Нам подправить нужно буквально одну строчку в конфиге и ждать, пока согласуют эту правку, совсем не хочется, а значит, мы будем самостоятельно вносить все правки на ходу с помощью kubectl. Документировать правки лучше у себя в заметках, и, если потребуется воспроизвести конфигурацию, тут же найдем, что изменилось.

Конечно, эти заметки уже распухли до размера мини-Википедии, а что-то уже и совсем потерялось, но мы же не зря отучились на курсах и с блеском сдали экзамен Certified Kubernetes Administrator (CKA), хоть и с четвертого раза. GitOps? Нет, это что-то для разработчиков. Нам это не требуется, тем более, что с помощью kubectl можно искать ошибки, читать логи, смотреть метрики кластера, а что еще нужно?

И конечно не закладывайте бюджет на внедрение системы мониторинга kubernetes. Не нужно, у нас уже есть все, что требуется буквально «из коробки».

Совет № 4 Создайте один большой кластер для всех ваших нужд

Всякие девопсы-дилетанты разворачивают несколько кубернетес-кластеров для разных нужд: разработка, продакшн, тестирование и т.п. Делают это они только потому, как я думаю, что не понимают концепции namespaces, которая может разделить все необходимые ресурсы между ландшафтами. Пора бы знать, что namespaces решает все проблемы по разделению и делегированию ресурсов, да и с безопасностью тоже будет все в порядке. Но это не точно. Для чего-то же есть еще RBAC, но это мы потом почитаем, как-то больно заумно там. Role, ClusterRole, RoleBinding, ClusterRole – что-то как-то слишком сложно, отложим на потом.

Мы ведь супер профессионалы и проблем точно не будет. Есть небольшая вероятность, что если в кластере будет серьезный сбой, то мы потеряем сразу все. Или, например, хакеры взломают продакшн и попадут, куда не следовало бы. Но какие шансы? Надеюсь, что небольшие.

Совет №5 Не отвлекайтесь на метрики, кубернетес сам справится

Кубернетес – это буквально передний край технологической мысли, поэтому достаточно только заставить его хоть как-то работать, а дальше он сам возьмет на себя решение всех задач. Ну, может быть, не всех. Но масштабирование и распределение нагрузки уж точно. Достаточно просто запустить поды с контейнерами, и проблема будет решена. Кубернетес сам распределит ресурсы сервера между подами, сам обнаружит утечки памяти, ведущие к нестабильной работе, и уж точно не допустит ситуации, когда один под съедает все ресурсы, и кластер просто умирает. Да, в курсе CKA были лабораторные работы заданию лимитов для подов. И даже что-то интересное про мониторинг подов: startup, readiness, liveness. Но это перестраховка, Кубернетес достаточно умен, чтобы решить эти задачи и без нашего участия.

-----

Это, конечно же, вредные советы. Так делать не нужно, если вы хотите обеспечить своему кластеру кубернетес долгую и надежную работу. Но вы бы удивились, сколько людей неукоснительно следует этим советам в своей ежедневной работе и продолжают все равно надеяться на лучшее.

Материал подготовил руководитель группы защиты инфраструктурных ИТ‑решений компании «Газинформсервис» Сергей Полунин, блог Сергея можно почитать по ссылке.