Как стать автором
Обновить
9
2
Александр Качмашев @DarthCorsair

Делаю инфраструктуру для разработчиков

Отправить сообщение

Вот да, такого рода магию я и имел виду. Ради интереса: а maxUnavailable=0 и общий случай minAvailable=replicas вы отлавливаете?

Не-а, т.е. если реплик больше 1, то вписывается minAvailable: 1 и все. Всем хватает, особенно в свете работы всяких HPA (хотя, конечно, корректнее будет сказать: никто не жаловался 😆)

Допустим, я продуктовый разработчик, что я делаю чтобы тупо выкатить новую версию? А если я хочу поменять количество реплик, или настройки HPA, или настройки readiness probe?

values.yaml 😅 есть внутренняя дока и примеры как что вписывается и куда (ну и ещё, конечно же, ctrl-c,ctrl-v из соседнего проекта). чтобы выкатить новую версию обычно используют --set и передают imageTag

Начинаешь разбираться, смотришь на события и видишь, что ReplicaSet старательно пыьается создавать поды, а validation webhook не менее старательно их отбивает

врать не буду, такое тоже иногда бывает. классический пример: квота на ресурсы CPU кончилась в неймспейсе, а квота на количество деплойментов в порядке. но от такого обычно спасает helm upgrade --wait, которой таску выкатки закончит провалом, и kubectl get events, который такое показывает.

а про PDB maxUnavailable=0 или minAvailable=1 при поде-синглтоне: оно работает нормально и все вроде ОК, но когда приходит пора апгрейдить кластер, процесс становится нетривиальным

вот с этой штукой мы в чарте подложили себе соломинку - если replicas: 1, то мы не создаем объект pdb 😀

Понял. Это, в целом, рабочая схема, но не очень гуманно по отношению к продуктовым разработчикам (хелм – это текстовый шаблонизатор поверх ямла, и работает он примерно так же хорошо, как можно ожидать)

А у нас на этот счет тоже есть "помощник", я про него рассказывал на devoops 2022 - https://youtu.be/HOIkjDIesWs. Если видео не захочется смотреть: мы написали мегачарт, который позволяет деплоить любое из наших приложений (отдельные чарты под разные opensource statefulset у нас тоже есть, но их пишет одна команда, а остальные переиспользуют)

и может выйти боком для инфраструктуры, если в кластер шаловливые ручки выкатят что-то неожиданное.

А здесь нас закрывает свои authorization и admission webhook (про них чуть детальнее рассказывал на Highload, как раз 2 декабря :)). В наш общий чарт вписано только то, что точно можно использовать, и то, некоторые из параметров в values закрыты проверками в нашем портале для разработчиков (т.е. только специально обученный человек может выписать для cервиса права на использование какого-нибудь флажочка, например, hostNetwork, для системы мониторинга)

Привет. Прекрасно, что такие истории факапов помогают людям преодолеть себя и вести дискуссию :)

Версию кубернетисов вы как обновляете? Тоже тушите кластера на пару дней? А на проде?

Нет, конечно же, все это автоматизировано, как и написано в статье - пару-тройку дней летит обновление\фикс, который дрейнит ноды и все само переезжает.

Заодно потеряли ивенты, и вообще все изменения в кластере. Под помер, а убрать его из эндпоинтов нельзя.

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

Настолько серьезная, что API server скорее всего будет адски тупить в это время.

Да, на него нагрузка сильно увеличивается, но наши API-server даже не поперхнулись в этой части.

Э? Поды в etcd, вообще говоря, не ходят. Кьюблет взаимодействует с API сервером, а тот уже ходит в etcd.

Calico с режимом хранения информации прямо в ETCD ходит, как раз и перевозили на kubernetes API (https://docs.tigera.io/calico/latest/operations/datastore-migration)

Эээ? Ну допусти ноды у вас железные, ваше право, но почему нет какого-нибудь ансибля, или парапета, или что там сейчас любят железячные админы, который придет и снесет все выступающее возвращая ноду в первозданное состояние? А операционку на нодах вы как обновляете когда там RCA находят?

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

Ну, собственно, и вот, бегать по нодам и пришлось, только не в нормальном рабочем режиме, а в состоянии "шеф, все пропало!"

Я там в начале статьи писал, что у нас несколько разных конфигураций нод (где-то rpm-based, где-то deb, какие-то ноды выделены под общую нагрузку, а какие-то под особенную), поэтому вариант пройтись "руками" ( запускал условный `ansible hostname1,hostname32 -i inv.yml -m shell -a 'systemctl stop kubelet && systemctl stop containerd && sedgrepawk && ip netns delete...'`) все еще подходит чтобы достаточно достоверно провериить что оно работает для всех кейсов, после чего и был за 5 минут написан нормальный плейбук, который потом и полетел по серверам :)

Registry это который container registry?

Да, это был container registry. Постараюсь такие моменты в будущем отмечать, потому что внутри привыкли, что registry это всегда про контейнеры, а все остальные registry у нас больше repository

У вас приложение катятся прямо как Deployments и StatefulSets?

У нас разработчики все выкатывают с помощью helm в котором да, фактически чистые Deployment и STS

Нахрена столько нод в стейджинге? У вас деньги лишние, что ли? Или откуда там такая нагрузка?

Нод столько, как раз чтобы экономить :D. Нагрузка там от разработчиков, тестировщиков и прочих причастных к приложениям. В препроде меньше нод чем в стейдже, потомучто он не пользуется у нас большой популярностью, к сожалению, и это как раз хочется исправить, чтобы однажды наш stage и правда был тем самым dev, который не страшно уложить. Мы потом выключали также кластера k8s в pre и prod, и там не было никаких проблем и тонны вопросов "ну чо, кагда?", потому что pre и prod в нескольких экземплярах в отличии от stage

А в завершение – извините, если критика прозвучало слишком резко, и здорово, что вы написали так подробно и с таймлайнами. Опыт, он так и приобретается, с упавшими кластерами, сегфолтами, а иногда и звонками роботети в два часа ночи. Удачи вам!

Объективная критика не может быть резкой. Спасибо за такой объемный и детальный комент, такое всегда полезно 🤜🤛

dragonfly с нами два года уже. отлично себя показывает. но вот на таких проверках наши новые узкие места)

все так, дельный совет. у нас dragonfly пир как раз в каждом слое и вот он немного не справился из-за необходимости скачать почти 5000 образов разом. добавили в них ресурсов

У нас там были базы данных. Просто стейдж у нас всего в одном ДЦ и он выключился весь, а препрод и прод в нескольких и там мы тоже выключали куберы, но уже после замены сети, чтобы не совмещать. Все приложения, в том числе и базы, нормально пережили это приключение)

Да, когда сервисы с ноды на ноду переезжают сами без лишних вмешательств, нужно придумывать новые способы занять руки и свободные вечера 😅

VMWare рекомендует ставить пакет open-vm-tools. Он есть в репозиториях всех современных дистрибутивов. Вся статья сведется к одной команде.

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Зарегистрирован
Активность

Специализация

DevOps, Product Manager
Lead