Спасибо за статью. Жду продолжения с более сложными примерами.
А можно ли как-то сделать такое автоматизированно? : чтобы для каждой команды генерился базовый дашборд, но команды разработки могли бы сами его дополнять дополнительными графиками. При этом, чтобы была возможность перегенерить существующие, не сломав добавленные руками.
Насчет «спирали страха автоматизации» и Puppet/Chief. По-моему, как раз автоматическая pull-модель этих инструментов внушала страх что-то сделать руками: через полчаса пришел puppet apply и всё вернул как было.
Хаос появился как раз с популяризацией Ansible, которая обусловлена более низким порогом вхождения: вместо единой конфигурации имеем множество «ролей», которые позволяют обособленно делать различные изменения с одним и тем же инстансом.
Ну обычное LT ядро от CentOS. На момент обновления ядер — было последним. Несколько месяцев им. Ставим то, что не глючит. У поздних 3x были проблемы с XFS (тормозило спонтанно на k8s нодах) и тоже самое было на 5.x ядрах последних от CentOS + еще были какие-то глюки. Оставили то, что позволяло спать спокойно.
Для меня является недостатком то, что необходимо писать такую логику.
Чтобы откатить настройки роли, нужно смерджить в гит или нажать специальную кнопку в CI-системе, которая откатит состояние на предыдущий коммит.
Или самое тупое: подготовить заранее PR для отката.
Atomic в Helm 2 появился чуть ли не после выхода Helm 3, ЕМНИП. Не проверяли — проще было сразу перейти на Helm 3 и выпилить все tiller'ы из всех нэймспейсов.
А что будет в случае проблем после обновления, но если его заметили в следующий день, т.е. в воскресенье?
Обычно если что-то не заметили сразу, то это не является чем-то сильно критичным.
У нас есть дашборды, показывающие «где что болит» и детальные дашборды по разным компонентам куба. Пропустить «большой косяк» довольно сложно, а мелкие косяки могут починить и ночные админы, либо утром сами починим, если не критично.
Деплой и настройка дженкинса автоматизировано?
Я не большой спец по Дженкинсу, недавно стало писать под него. Может я неправильно понял вопрос.
Дженкинс у нас только для Ops-проектов и руками завести пайплайн раз в 2 недели не проблема
ИМХО, у ansible недостатков много
Почти полностью согласен. Производительность Kubespray довольно ужасна, хотим слезть с него.
Как с безопасностью?
Довольно много работаем над этим. Не всё идеально, но лучше чем обычно (что я вижу в других компаниях). Подробности раскрыть не могу.
Про визуализацию мониторинга через Ранчер ничего не скажу. Сам Ранчер нам не интересен — его фичи либо уже у нас есть, либо не интересны. Графана — стандарт индустрии, хорошая документация и все ее умеют. Она была до Кубера и наверное будет когда его не станет :) Хотелось бы чтобы она просто не тормозила хотя бы на топовых компах на той же community Kubernetes Dashboard.
С самим Docker проблем нет. Есть вопросы к скорости развития самого Docker: он просто не развивается и долгожданных нужных фич вроде лимитирования по IOPS, cgroups v2 — мы до сих пор не получили. В среднем сейчас 40-70 подов на ноду (до 100 иногда доходит).
Мы ревьювим чарты, да. Дашборд готовят разработчики. Документация — на воли совести создателя сервиса. Не страшно если ее вообще нет: infrastructure as a code.
Спасибо за статью! Отлично подходит как справочник-напоминалка и для тех, кто это уже всё настраивал :)
Вы не поверите, но у нас почти все разработчики еще и в DevOps-практики умеют :)
Спасибо за статью. Жду продолжения с более сложными примерами.
А можно ли как-то сделать такое автоматизированно? : чтобы для каждой команды генерился базовый дашборд, но команды разработки могли бы сами его дополнять дополнительными графиками. При этом, чтобы была возможность перегенерить существующие, не сломав добавленные руками.
Автор точно не гуманитарий :)
Хаос появился как раз с популяризацией Ansible, которая обусловлена более низким порогом вхождения: вместо единой конфигурации имеем множество «ролей», которые позволяют обособленно делать различные изменения с одним и тем же инстансом.
Чтобы откатить настройки роли, нужно смерджить в гит или нажать специальную кнопку в CI-системе, которая откатит состояние на предыдущий коммит.
Или самое тупое: подготовить заранее PR для отката.
Мы каким-то разным ансиблом пользуемся )
Систему тюним при заливке при помощи Ansible: там штук 50 sysctl меняем.
kubelet'ы тоже тюним — их опции выстраданы годами.
Обычно если что-то не заметили сразу, то это не является чем-то сильно критичным.
У нас есть дашборды, показывающие «где что болит» и детальные дашборды по разным компонентам куба. Пропустить «большой косяк» довольно сложно, а мелкие косяки могут починить и ночные админы, либо утром сами починим, если не критично.
Я не большой спец по Дженкинсу, недавно стало писать под него. Может я неправильно понял вопрос.
Дженкинс у нас только для Ops-проектов и руками завести пайплайн раз в 2 недели не проблема
Почти полностью согласен. Производительность Kubespray довольно ужасна, хотим слезть с него.
Довольно много работаем над этим. Не всё идеально, но лучше чем обычно (что я вижу в других компаниях). Подробности раскрыть не могу.
Просто чтобы живые имена подов не показывать, я выбрал такой ns.
Про визуализацию мониторинга через Ранчер ничего не скажу. Сам Ранчер нам не интересен — его фичи либо уже у нас есть, либо не интересны. Графана — стандарт индустрии, хорошая документация и все ее умеют. Она была до Кубера и наверное будет когда его не станет :) Хотелось бы чтобы она просто не тормозила хотя бы на топовых компах на той же community Kubernetes Dashboard.
С самим Docker проблем нет. Есть вопросы к скорости развития самого Docker: он просто не развивается и долгожданных нужных фич вроде лимитирования по IOPS, cgroups v2 — мы до сих пор не получили. В среднем сейчас 40-70 подов на ноду (до 100 иногда доходит).